How to deal with imports?

[henrietteharmse]

As part of indexing OLS creates a node for each term in its underlying graph. When an ontology imports terms from another ontology, OLS will create a new node for that term for that ontology. This mean that if a term is imported into N ontologies in OLS, that term is duplicated N+1 (assuming the imported ontology is in OLS) times in OLS. The effect of this is that if the imported term is updated in the imported ontology and re-indexed by OLS, this change is not reflected in the N ontologies importing this term.

A concrete example of this is biological process (GO:0008150). This is a term is used in a number ontologies in OLS as illustrated in the image above.

This is how OLS currently works. However, we may want to change it to have a term only once OLS where we assume updating it can only be done via the defining ontology, not downstream ontologies. The potential advantage of this is that if term is updated in the imported ontology and re-indexed by OLS, the update will reflect in downstream ontologies.

A few questions to ponder in this regard are:

1. Will it be desirable for downstream ontologies whenever a change is made to an imported term that the change is seamlessly reflected on OLS for their ontology?
2. What to do in the case where the defining ontology is not available on OLS? We could then potentially revert back to having the term duplicated for each ontology that imports it. But, then we need to be able to deal with the case where the defining ontology is made available at a later stage on OLS.
3. How should OLS deal with the situation where an imported term is deprecated?

Is there any other issues we need to think of in this regard?

[jamesamcl]

@matentzn @dosumis

[cmungall]

Great to see OLS tackling this. Users are frequently bewildered by our odd ontology practice and expect to see something that clearly separates ontologies rather than current mishmashes.

Some challenges with implementing this:

How do you know who the authority is? Some ontologies foster IDs from other ontologies. I don't think this is good practice, and OBO is gradually moving away from this, but is exists. E.g. BFO terms owned by RO (https://oborel.github.io/obo-relations/ro-and-bfo/#ro-relations-with-bfo-ids)

We are working towards solution, e.g. a standard AP, but for now this is a hard problem

Second, how do you distinguish intentional axiom injections from the kinds of problematic axiom injection? There is as yet no consensus on if and when axiom injection should be done (see OBOFoundry/OBOFoundry.github.io#1443). But for now, if you were to exclude axioms about C from non-authoritative sources many graphs would be fragmented.

If a workaround for these issues can be found then I am all for this. Maybe this is as simple as having opt-in opt-out for each ontology, with the ability to tag the exceptions in the ontology.

The solution for 1 may inform 2, but I think so long as a URL can be formed it is fine to show dangling classes. However, don't show them at the root like Protege does please!

For 3 an ideal scenario would involve versioning, and just like I can pin pypi dependencies I should be able to pin ontology version dependencies, and if I make a mistake and release an ontology that references a class that is obsoleted within my pinned range, that is on me. However, I appreciate this may be prohibitive on the back end.

I welcome this direction though. We need ontologies to work more like software, modular, but no copypasta mishmashes

[matentzn]

One note about the fostering: These can't be that many.. Maybe we can require fostered terms to have the isDefinedBy AP and push this through at least on all the main OBO ontologies. I started a thread to inquire where and how this is happening here: OBOFoundry/OBOFoundry.github.io#1923.

[cmungall]

I would like to move towards a system where OLS and other portals can load base files, and instead of showing dangling entries as ugly dangling root nodes, intelligently hide them until the user asks, and then resolve using the canonical full ontology. See information-artifact-ontology/ontology-metadata#118

[matentzn]

I agree being able to do this would be really important, but it wont work for all use cases - application ontologies etc. All ontologies should have a clearly visible button like "look at this term in its context" (obviously not called that), even if they are not using base. But if there is a base release, OLS should be able to deal with it. @udp this would basically come down to this:

Given you are looking at an ontology O1 in its "base" form and given an axiom AX1:

O1:A rdfs:subClassOf O2:R some O3:B

1. OLS should reroute O3:B (the clickable link I mean) to ols/O3/B, i.e. leaving the context of O1
2. Loading the label from O3:B from the context of O3 (since the label wont be in O1) which is used for rendering on the website
3. Same with O2:R (loading the label from O2)

@cmungall suggests that the axioms is hidden in the default view, which I don't really agree with - I think loading the canonical label is fine, at least for the kinds of axioms presented by OLS.

[cmungall]

@cmungall suggests that the axioms is hidden in the default view, which I don't really agree with - I think loading the canonical label is fine, at least for the kinds of axioms presented by OLS.

Agree 100% - I was thinking of a particular narrow case, of part-of axioms that cross ontologies, where it's hard to show these in a pure native view. See #604

[matentzn]

Ah ok, you mean the hierarchical view - yes that is a difficulty I did not consider. Needs a moment of thought, but most likely this is about wiring the roots and leaves. The issue you shared is a bit important to get right I think.

[rajaram5]

It is still better to show a particular concept is reused in another ontology. In this way users can see how well aligned different ontological views are.

[cmungall]

I like how ols shows the rough equivalent of the protege usage tab in the lower right. This can continue, but if all such components in ols have a clear visual effect ndicator of internal vs external this will be v helpful