search

NCATSTranslator / ReasonerAPI

NCATS Biomedical Translator Reasoners Standard API
35 stars 28 forks source link

Supporting data sources refinements in TRAPI schema #451

Open mbrush opened 1 year ago

mbrush commented 1 year ago

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 commented 1 year ago

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

karafecho commented 1 year ago

@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!