consider always adding equivalentClass/sameAs, or as a parameter

[nlwashington]

When we do a subClassQuery, we can get many children that are equivalentClass...but these don't show up when doing a query with a depth of 1. and i think that we can't currently OR relationship types.

To figure out which of the nodes are equivalent/sameAs, we'd have to do an iterative query on the results of the initial query. OR you'd have to implement the ability to allow the user to submit a list of relationship types.

For example:
http://geoffrey.crbs.ucsd.edu:9000/scigraph/graph/neighbors/HP:0000795?depth=1&blankNodes=false&relationshipType=subClassOf&direction=INCOMING
you see both urethral atresia(HP:0000068) and urethra atresia(MP:0003591) as subclasses.
but if i query HP:0000068, you can see that they are equivalent.

so, how can we get a graph of all the children of a term, including the equivalences?

[nlwashington]

tagging @kshefchek @cmungall

[cmungall]

Do I have this right?

Asserted:

1 B SubClassOf A
2 B EquivalentTo C

Entailed:

3 C SubClassOf A
4 B EquivalentTo C
5 C EquivalentTo B
6 B SubClassOf C
7 C SubClassOf B

6+7 may seem unintuitive until you consider that SubClassOf has interpretation subset-or-equal-to. I believe when we materialize inferences in SG we ignore reflexive SubClassOf entailments and only add proper direct entailments (todo: add to docs). Another way of thinking about this is that we only add entailed SubClassOf axioms of depth=1 (formally the depth is the number of 'hops' using the owlapi reasoner api getDirectInferredSuperClasses method, cc @hdietze).

Given this, is the problem as follows?

Desired:
children(depth=1 t=SubClass A) = {B,C}
Current:
chilren(depth=1 t=SubClass A) = {B,C}

so all good there

however the challenge is interpreting the semantics of this:
children(depth=1 t=SubClass B)
Currently the answer set is {}

7 is a valid entailment, so there is an argument that the return set should be {C}. However, I think this is awkward. I prefer to keep the current method of storing entailed subclasses, and keeping these as depth=1.

However, from a UI perspective this is awkward as we need to do 2 queries to get what we want.

One compromise would be to have a maxDepth parameter, the client calls maxDepth=1, and SG is smart enough to know that depth=0 for any relation is the set of equivalent classes. This makes mathematical sense but is perhaps clunky from a developer perspective.

Can this wait til monday?

[jnguyenx]

@cmungall Can you please provide a small ontology test? Like having 2 cliques and a relation between them?

[jmcmurry]

Are the recent improvements here adequate to close https://github.com/monarch-initiative/monarch-app/issues/895?

[jnguyenx]

There are still some bugs, but they should get fixed with the next graph
load.

In my opinion you can close the monarch-app ticket.

On Thu, Oct 1, 2015 at 12:45 PM, Julie McMurry notifications@github.com
wrote:

Are the recent improvements here adequate to close
monarch-initiative/monarch-app#895
https://github.com/monarch-initiative/monarch-app/issues/895?

—
Reply to this email directly or view it on GitHub
#135 (comment).

[cmungall]

Reopening.

This does not return anything:

https://scigraph-data.monarchinitiative.org/scigraph/graph/neighbors/HGNC%3A6081?depth=1&blankNodes=false&relationshipType=RO%3A0002205&direction=OUTGOING&entail=true&project=*

This does:

https://scigraph-data.monarchinitiative.org/scigraph/graph/neighbors/NCBIGene:3630?depth=1&blankNodes=false&relationshipType=RO%3A0002205&direction=OUTGOING&entail=true&project=*

The results should be identical, as HGNC%3A6081 and NCBIGene:3630 have an equivalence edge between them

[deepakunni3]

It looks like this issue was never resolved. Going by the examples in the message above, we still have no results when the CURIE is not a clique leader.

@kshefchek What needs to happen here? Something I can look at?

[kshefchek]

It's not on my radar -- the main consideration is that clique merging is an optional post processor, and the node label and what edges are used in the merge are done via configuration https://github.com/SciGraph/SciGraph/wiki/Post-processors#usage, so we would need to add this to the service configuration as well.