search

NCATS-Tangerine / rhea-beacon

Knowledge Beacon wrapper for the Rhea Annotated Reactions database (https://www.rhea-db.org)
MIT License
0 stars 0 forks source link

Querying for statements by RHEA ID returns empty lists #16

Open cmungall opened 5 years ago

cmungall commented 5 years ago

This is the target of some statements RHEA:23268

Yet this is empty https://kba.ncats.io/beacon/rhea/statements?s=RHEA%3A23268

lhannest commented 5 years ago

This isn't actually a bug. @RichardBruskiewich and I have been planning on switching from source/target filters to subject/object filters. I expected this API change to roll out quicker, and pre-emptively developed the beacons to that future specification. Reactions are always the objects of statements, so it works if you do this:

https://kba.ncats.io/beacon/rhea/statements?t=RHEA:23268

RichardBruskiewich commented 5 years ago

@lhannest of course, one would have to know that reactions are objects of statements, to discover them! I guess not having to know this would have been the virtue of the source versus target system. Namely, source should discover the existence of the reaction either as a subject or an object.

I suppose if the the searches are "enlightened" with respect to predicates, this won't be an issue, but it end users of the API's will have to be aware of this reality.

lhannest commented 5 years ago

We can make the arguments self-documenting, instead of "s" and "o" (or "t" as it is now) we should use "subject_ids" and "object_ids".

I suppose it's unfortunate that the client would have to make two queries with the subject/object semantics to perform the source/target function. The rhea kmap shows that there are statements with reactions as subjects after all. It just so happens that RHEA:23268 isn't in any of these. But https://kba.ncats.io/beacon/rhea/statements?s=RHEA:22384 does return records.

RichardBruskiewich commented 5 years ago

This seems to be a use case which argues against locking down the semantics of the call too tightly with "subject" and "object" versus "source" and "target".

BTW, the reason that short "s" and "t" letters are used as parameters is that these arguments are array arguments, which in some implementations, are expressed by duplication in GET calls, i.e.

      endpoint?s=<arg1>&s=<arg2>&s=<arg3> etc.

Having long parameter names would bloat the URL length.