Display complete info for an ontology class, including synonym types and axiom annotations

[cmungall]

Currently the amigo term info page is only showing a subset of information about a term. We lack some properties such as synonyms (the 4 synonym types are flattened into a single synonym field), and we lack axiom annotations (for example, definition xrefs and synonym xrefs). We also lack axiom constructs such as equivalent classes.

To achieve this, the plan is:

1. Define obograph JSON format: Standardize json payload for Class information #58
2. Extend owltools to be able to return an obograph json blob for any class - Extend golr loader to populate JSON blobs for ontology classes owlcollab/owltools#160
3. Extend ont-config.yaml to populate this blob when loading ontology_class documents - Support obographs in ontology documents #474 (awaiting merge)
4. Write javascript code that can render blob as html

[cmungall]

The actual info could be rendered in a number of different ways, I think the OLS gets this just right. It shows the important info front and center, and makes the advanced info (e.g equivalence axioms available to the side).

Not sure if there is any js code we could reuse @simonjupp?

[kltm]

IIRC, we have some stuff already for rendering col 16 artifacts from the owltools loader.

https://github.com/geneontology/amigo/blob/master/javascript/lib/amigo/handlers/owl_class_expression.js
https://github.com/geneontology/amigo/blob/master/javascript/lib/amigo/handlers/owl_class_expression.js.tests

Code needs to be modernized a bit...

As well, there's a fair number of various renderers associated with the class-expression and bbop-graph-noctua libraries in noctua.

It would be good if we could coordinate on all of this.

[cmungall]

I think that may be fairly hardwired to annotation extensions.

What I have in mind for rendering could be done entirely by logic-free mustache templates. The only question is on the rendering of xrefs and other hyperlinkable entities (see parallel monarch ticket), the desire behavior may depend on the context in which the component is deployed. Could be done with call backs, but I would be inclined to keep it simple: perhaps the embedding app can enrich the json with hyperlinks, and the render code can be dumb.

[kltm]

The amigo c16 code is more to highlight that we're starting to get a lot of special little blobs that are requiring handling and it would be good to start narrowing it down a bit.

Some things will be a a little annoying to do in AmiGO templates, but nothing that we haven't done before (mustache render, then injection).

[simonjupp]

FYI for the more complex OWL axiom rendering OLS generates HTML snippets server side using an OWL HTML renderer developed by Nick Drummond many years ago https://github.com/co-ode-owl-plugins/ontology-browser/tree/master/owlhtml/src/main/java/org/coode/html/renderer