RichardBruskiewich
commented
5 years ago Hi @lhannest,
As you know, when the original system was designed, we fixed the "seed" concept (the "source") but it could match either the subject or the object, thus making the task of "category" filtering of the "other" (a.k.a. "target") concept clear.
I guess now though, like you say, we now publish the kmap, and our /statements endpoint is somewhat generalized, so queries are likely to be more informed and more precisely templated than before, woyj the need to blindly "fish" for a statement hit in either direction less critical. And, as you say, the "category" constraints are likely to be very deliberate and have a specific direction relative to predicates of interest.
Unless @cmungall thinks about an objective reason not to make your proposed change (from bidirectional "source"/"target" matches to predicate enforced directional "subject"/"object" kind of filtering) I'm cautiously in agreement with the change.
Not sure how to version this, though... our iterations on the Beacon API since the start of the hackathon has been a bit less disciplined, it seems. We need to take stock of the impact of these iterations on our "beacon" writing community, which include more developers now than just us!
@RichardBruskiewich @cmungall Now that the source filters are not required, should the source and target filters be functionally equivalent? Or, should the target filters only apply if the source filters apply?
Alternatively we could get rid of them entirely, and replace them with subject and object filters. That makes more sense to me anyway, since the predicates are almost always directed. With the kmap one could easily figure out whether they should be filtering on the subject or object, anyway. The source and target filters are much more difficult to implement than subject and object filters would be.