Proposed extensions to "display relationships in class hierarchy" view

[cmungall]

The new "Display relationships in class hierarchy" option is great!

This is generally fantastic, but sometimes this can be confusing when used with all OPs, e.g. it's a bit unintuitive to see this for "X has-part some Y" axioms are many are trained to read the hierarchy as going from "bigger/broader" to "smaller/narrower". Also I suspect that for some classes we end up with explosions of paths to roots which may slow things down for some people, but have not fully investigated

Can we have the ability to have this work for a select set of object properties? We could also have this be driven by annotations on the OP. That way OLS could use it too (it's currently hardcoded just to include part-of). cc @simonjupp.

It would be useful to have a visual indicator of the relationship type.

E.g. see http://amigo.geneontology.org/amigo/term/GO:0097194

We have GIFs for each of the relation glyphs that we show (cc @kltm) e.g.
http://amigo.geneontology.org/static/images/negatively_regulates.gif

These could also be shared in OLS etc.

I can see how that would be harder to implement, so one possibility is to just include as text, e.g.

• apoptoptic process
  • <--[part of] execution phase of apoptosis

Another thing I am not sure how to approach is inclusion of these in the inferred view. Currently the "display relationships" only works for the asserted view, which makes a certain amount of sense. This view is derived from the reasoner API which just gives you the direct named superclasses. But I like to tell people to live in the inferred view, so they don't get confused when hierarchies look flatter than they expect. So it would be great if relationships could be shown here in a way that preserves overall coherency. Thoughts @dosumis @balhoff?

[matthewhorridge]

Can we have the ability to have this work for a select set of object properties? We could also have this be driven by annotations on the OP.

Yes, makes sense. A common set of annotation properties would be great. I think I would prefer the just the presence of the annotation assertion to indicate inclusion... i.e. the value of the assertion could be anything that's useful for the project in question.

It would be useful to have a visual indicator of the relationship type.

Okay will think about a solution to this based on your comments. Is there a common set of glyphs that could be used? e.g. circle, square, up-arrow, down-arrow etc.? These could be combined with colors and initials etc. It would be possible to have a default yaml config file embedded in Protege for certain property IRIs. Could also be part of ODK ;)

So it would be great if relationships could be shown here in a way that preserves overall coherency.

Definitely. On the todo list!

[matentzn]

I would also like to add that currently, if you have this situation

A sub B
B sub C
X sub R some A

The hierarchy is rendered as:

• C
  • B
    • A
      • X (imagine blue line)
• X

which is confusing in ontologies that are not built on a string isa backbone (there are many 'strays' under the root). Would it make sense to simply show:

• C
  • B
    • A
      • X (imagine blue line)

when the feature is active? @cmungall

[cmungall]

meh, those ontologies should declare superclasses

however, a general edge-label-independent transitive reduction checkbox would be useful for many ontologies like go, uberon, etc. This would handle your scenario as just one case.

[matentzn]

@cmungall You know what my background is, but to play devils advocate here: why should this be necessary? I mean to have a superclass for everything? What is the argument we give to groups that, say, just build a partonomy?

[cmungall]

• renders terribly in browsers that follow OWL standards (but the counter-argument is that we should be following some relatonal graph standard)
• you don't know what kind of thing you are talking about (except sometimes domain/range constraints may give a sufficient inference)
  • how do we fit it into obo core?
  • you will generally have problems axiomatizing, e.g. won't get benefits of disjointness. I know the people making these ontologies that they don't know what this means, but these are the kinds of ontologies that benefit from this kind of axiomatization, and one of us will end up refactoring anyway
  • will cause shex violations when you try and incorporate into Noctua (since we have strict closed world checks on types, e.g. occurs-in must be some kind of anatomical structure). Historically most of the ontologies that have lacked explicit subClassOfs have been model organism ontologies that are required to be added to the noctua import chain to support contextual information for a particular MOD

[matthias-samwald]

The original feature request by @cmungall would still be extremely valuable. I don't think glyphs are a big priority, but being able to display relationships in the other / expected direction within the hierarchy would be much needed!

[matthias-samwald]

For my own purposes I took a deep-dive into the Protege codebase and changed the direction of relationships shown in the class tree. I think this direction should be default, since it produces more intuitive results for most ontologies. The fork: https://github.com/matthias-samwald/protege (this is just a quick hack and I cannot claim to have fully wrapped my mind around OWL API, so no guarantees).

Regarding glyphs and customizability, I think this would be best handled by a specific annotation property that can be used to annotate object properties. Instead of using custom gifs, I think using Unicode glyphs/strings specified in such an annotation property would be a very powerful and simple solution.

BTW I think it would also make sense to be able to display class relations that are made through annotation properties in the tree view, not only relations based on existential restrictions on object properties.

[matthias-samwald]

@matthewhorridge Would there be a better / more performant way to use OWL API? If SubClassOf(A ObjectSomeValuesFrom(p B))...

Your original code retrieves all A for given class B

         axiom.getSuperClass().asConjunctSet().stream()
                 .filter(ce -> ce instanceof OWLObjectSomeValuesFrom)
                 .map(ce -> ((OWLObjectSomeValuesFrom) ce))
                 .filter(svf -> !svf.getProperty().isAnonymous())
                 .filter(svf -> svf.getFiller().equals(currentParentClass))
                 .filter(svf -> relationships.contains(svf.getProperty().asOWLObjectProperty()))
                 .findFirst().ifPresent(c -> {
                OWLClass child = axiom.getSubClass().asOWLClass();
                results.add(child);
                child2RelationshipMap.put(child, c.getProperty());

My seemingly functional but probably not optimal code replacement, retrieving all B for a given class A:

            axiom.getSuperClass().asConjunctSet().stream()
                 .filter(ce -> ce instanceof OWLObjectSomeValuesFrom)
                 .map(ce -> ((OWLObjectSomeValuesFrom) ce))
                 .filter(svf -> !svf.getProperty().isAnonymous())
                 .filter(svf -> relationships.contains(svf.getProperty().asOWLObjectProperty()))
                 .filter(svf -> !svf.getFiller().isAnonymous() )
                 .filter(svf -> !svf.getFiller().equals(currentParentClass))      // without this we get spurious self-relations -- why?
                 .findFirst().ifPresent(c -> {
                OWLClass child = c.getFiller().asOWLClass();
                results.add(child);
                child2RelationshipMap.put(child, c.getProperty());