-
Notifications
You must be signed in to change notification settings - Fork 29
Description
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:
- 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 .
- 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.
- 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.