Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting data sources refinements in TRAPI schema #451

Open
mbrush opened this issue Aug 16, 2023 · 2 comments
Open

Supporting data sources refinements in TRAPI schema #451

mbrush opened this issue Aug 16, 2023 · 2 comments

Comments

@mbrush
Copy link
Collaborator

mbrush commented Aug 16, 2023

Data-derived KPs that ingest and analyze instance-level data from several sources to generate statistical correlation edges recently raised some questions about applying the refactored RetrievalSource model to their use case. In particular, ICEES often draws from 10+ data sources to generate their edges - and is concerned about having to create separate RetrievalSource objects for all of them. For more background/context, see the Biolink issue here. Also, 'Scenario 2' at the end of the Spec doc is particularly relevant to this issue (imagine this example if there were 12 different supporting data sources)

In the short term, ICEES are going to drop representation of supporting data sources from their TRAPI messages, and rely on the ICEES-KP wiki to point users to their underlying data sources. Longer term (Post Sept release), we should consider how we might amend the RetrievalSource schema and/or implementation Guidance to more concisely support this use case. Specifically:

  1. Consider if we need to capture supporting data sources in TRAPI messages in the first place. It may be sufficient to rely on wiki pages for the data derived KPs that utilize these data sources to describe and link out to them .
  2. If we want to capture this info in TRAPI messages, consider if we could allow for multiple infores ids within a single RetievalSource object - in particular in cases where there are a large number of supporting data sources to report.
  3. Make sure that users are provided with sufficient info/context around these supporting data sources to understand how they are used to generate edges reported by ICEES and other KPs.
@capasfield
Copy link
Collaborator

This can wait til after September. It may resolve itself and it is not pressing.

@karafecho
Copy link

@capasfield : Unfortunately, this issue will not resolve itself, but rather requires discussion. 'Tis true that it is not pressing, however, and can wait until after the September release. I think Matt is planning to add it to the agenda for a TRAPI WG meeting. @mbrush: I don't typically attend the TRAPI WG meetings, so please let me know when you will be discussing the issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants