Feature request: Subclass + Equivalent
matentzn opened this issue · 17 comments
It would be great to have a single service that allows me to retrieve all classes that are equivalent and superclass / equivalent and subclass at once (subClassEq, superClassEq). I think the best way to realised this would be to extend the superclasses / subclasses services with a flag = includeEquivalent.
👍
@matentzn would you want the equivalent classes merged into the subClassOf list, or instead provided separately under another key (equivalentClass)?
I think the latter could work well, as we could have one query type and two ways to process. @Robbie1977 - what would you prefer?
It seems like there's no reason to lose information, so we might as well include both keys rather than merge.
I merged this, but if you strongly prefer the results all under subclass/superclass, please reopen.
Either is fine; whatever makes sense in more general usage.
+1 for both keys
When querying with a named class, I expected this to return that class. It doesn't. It would be useful if it did.
I chatted with @matentzn about this yesterday. I think he had the opposite expectation. I think I could be persuaded either way, but then would it go in the list of equivalents? If you only were getting subclasses but not returning equivalents, should it be in the list of subclasses?
It does not matter to me at all; i would just like this to be consistent.
IMHO, if you look at the response of a given query, you can always union the @id, subclassOf: and equivalentClasses: fields of the resulting yaml to get everything you want; so in some sense, you get the class back you are querying for.
Whatever we do, lets make it sensible for the general audience, not just a particular use case; I am more interested to know whether equivalent classes are included in the subclasses; if they are not, you cant really justify adding the class itself because the semantics of subClassOf: [] is going to be strictly sub...
I'm inclined to NOT return the queried term. I think this is cleaner.
Is another parameter overload? The current sublass method pertains to what I would call STRICT subclassing.
so lets say in this case:
O1:
A = B
C sub A
M1: the owlerySubclassOfA() query should return:
subs: [C]
M2: owlerySubclassOfA(includeEquivalents=true) should return:
subs: [C]
equivs: [B]
and M3: owlerySubclassOfA(includeEquivalents=true,includeSelf=true) should return:
subs: [C]
equivs: [B,A]
This would accommodate for all use cases. What do you guys think?
I must admit that I tend to agree with @hlapp here. I was just trying to reconcile a user request (from virtual fly brain, @dosumis, @Robbie1977: "please return self explicitly") with the resource investment of extending the API in a principled manner. David and Robbie will have to fend for themselves now if they disagree with the 3-query-result-field-union solution.
I think with the current implementation, it’s just one query, and the client can inject the query term into the results if they want.