search

NCATS-Tangerine / translator-knowledge-beacon

NCATS Translator Knowledge Beacon Application Programming Interface plus Sample code
MIT License
7 stars 2 forks source link

proposal: replace exactMatches service with call to statements API #13

Open goodb opened 7 years ago

goodb commented 7 years ago

set a predicate parameter to reflect something like 'owl:sameAs' to retrieve mappings.

this would reduce the number of services in the API and make it clear that we would like to see evidence and provenance for these relationships - just like any other relationship returned by a service.

mellybelly commented 7 years ago

It would be nice to have the ability to leverage various tools/inquiries to declare "trustworthy-ness" or probability of actual equivalency within a given context for set of declared equivalency relationships or other associations. one source's equivlencies are not the same as another, and most do not provide semantics for a dbxref.

jmcmurry commented 7 years ago

It may be useful to broadcast the ability of any given beacon to map identifiers in a class (eg. genes), and then within that class providers (eg. NCBIGene, Ensembl, HGNC ...) and then within that, which specific entities. For Monarch's part, our cliques can be queried like so: https://scigraph-data-dev.monarchinitiative.org/scigraph/dynamic/clique/NCBIGene:6622 and the source of the mappings is in isDefinedBy

RichardBruskiewich commented 7 years ago

My concern with tossing out the exactmatches api call and simply relying on the statements api call, is that discovery of equivalent concepts will be restricted to local beacons, thus losing the synergy of discovery across beacons.

goodb commented 7 years ago

I don't understand that comment regarding limiting to local beacons (what is a local beacon? aren't they all viewed as distributed?). If Beacon 1 provides an exactMatches service that produces {InputX exactMatch Y} relations, and Beacon 2 provides a Statements service that produces {InputX exactMatch Y relations}, what is the difference? In both cases, the equivalent cliques can be created.

As I indicated in the original proposal, I do think this development would favor the addition of a parameter in the call to getStatements to indicate what predicates to retrieve. When exactMatches behavior was expected, this would be indicated with a filter on e.g. owl:equivalentClass relations - thus saving some unneeded calls. I suspect that filter would be useful in other contexts as well.

RichardBruskiewich commented 7 years ago

Sorry.. poorly worded. What I meant by "local" above is that each knowledge beacon may have a list of equivalent concepts, but how will statements be reliably retrieved from all other knowledge beacons if those equivalent concept ids are not exported to the system ("blackboard")? The beacon 2 statement retrieval is only limited to export relations that match the inputX concept id. InputX may be a direct reference to a concept beacon 2 knows about, or just in the list of equivalent concepts beacon 2 knows about - either way, yes... it knows which relationship statements to return.

However, what if there is a beacon 3 which doesn't know about InputX but (only) knows about an InputZ, but it happens be the case that beacon 1 or beacon 2 know that InputZ is equivalent to InputX in their own internal lists of equivalent concepts? Unless InputZ is exported (from beacon 1 or 2), and used by the system to call beacon 3, then beacon 3 will never return relations related (by concept equivalence) to InputX.

The core issue here is the synergy of sharing equivalent concept lists across knowledge beacons, such that a complete list of statements linked to any of the known equivalent concepts can be returned.