Skip to content

Supporting data sources refinements in TRAPI schema #451

@mbrush

Description

@mbrush

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions