Uberon should make use of xrefs in other ontologies

[cmungall]

Historically uberon was the only SOT for mappings, but we have not kept the mapping pipelines up to date and there are now sometimes mappings curated in external AOs (e.g. XAO #2796).

We should add a step to include these. I suggest a periodic slurp into the edit file where they will be visible to editors rather than just at release time.

Before doing we should make sure there are checks in place to avoid introducing non 1-1 mappings. The SOP is that if on running a slurp the editor finds these, to raise an issue on either this tracker (if uberon mapping is questionable) or external AO tracker.

This could be done as part of a boomer-like workflow but this is probably overkill.

perhaps the script that generates bridge files for CL can be adapted (in contrast to Uberon, CL treats many upstreams as SOT).

Or it might be easiest to do in OAK. Basically just query the upstream for X-to-Uberon and flip that into

id: UBERON:...
xref: X:....

[gouttegd]

Of note, FlyBase has switched (for a few months already) to maintaining and providing its mappings with Uberon/CL under the forms of a SSSOM mapping set, and the idea with @matentzn was to slowly generalise the use of SSSOM mapping sets up to the point where they could replace cross-references entirely. Especially now that we (finally) have dedicated mapping predicates to represent cross-species mappings (semapv:crossSpeciesExactMatch and related).

So what I’d propose here would be that, for each foreign ontology (FO):

1. we first check whether the FO provides a SSSOM mapping set (FlyBase is the only one to do so right now, as far as I know; but other ontologies should be encouraged to jump on the bandwagon);
2. if not, extract the cross-references from the FO and use them to create a SSSOM mapping set (it is hoped that this would only be temporary, until the FO switches to SSSOM);
3. generate the bridge files from the mapping set.

Also, independently of the generation of bridge files, we would collect all the mapping sets and convert them into a “mapping” component (containing annotations of the form AnnotationAssertion(semapv:crossSpeciesExactMatch UBERON:XXXXXXX FBbt:YYYYYYYY)) that is imported into Uberon. That way the mapping annotations will be visible to editors, without having to actually insert the annotations directly into the edit file.

Optionally, the collected mapping sets could also be converted to a second component where the mapping are converted to cross-references (annotations of the form AnnotationAssertion(oboInOwl:hasDbXref UBERON:XXXXXXX "FBbt:YYYYYYYY")). This would be for backwards compatibility only, in case some consumers of Uberon have workflows that are specifically dependent on cross-references and are not ready to use either SSSOM or the semapv:* mapping predicates.

[gouttegd]

Regarding the question of the “source of truth” for the mappings to each foreign ontology:

I think that we should have an agreement with each foreign ontology as to which side is going to provide the mappings (whether they are provided as a SSSOM mapping set or as cross-references), rather than trying to merge Uberon-maintained mappings with foreign-maintained mappings and raise an issue when we find clashes.

That is, we reach out to the maintainers of each foreign ontology and ask them if they want to manage their Uberon/CL mappings on their side. If they do, we delete all the cross-references we may currently have in Uberon/CL, and we use instead what they provide (as explained in the previous message). If they don’t, then we keep maintaining the mappings on the Uberon/CL side¹, and we don’t even try to fetch any mapping set or cross-references from them.

--

Footnotes

1. Whether the mappings are maintained on the foreign side or on the Uberon/CL side does not imply anything about who will actually maintain the mappings, it just says which repository will be the source of truth. The maintainers of a foreign ontology could very well decide that they will maintain the mapping themselves, but they will do so on Uberon/CL (if they happen to also be Uberon/CL contributors). ↩

[gouttegd]

Of note, we should keep in mind that there is also the case of foreign ontologies that provide so-called “complex mappings” – mappings that for some reason are too complex to be expressed as cross-references or as a SSSOM mapping set (one of the “S” in SSSOM stands for “simple” after all).

In such a case, it’s the responsibility of the foreign ontology to directly provide a bridge file ready to use.

Currently, this is the case of (at least) MBA/DMBA.

[github-actions]

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.

[gouttegd]

Since #3061 we have all the needed infrastructure in place to use externally provided mappings, whether those mappings are provided directly as a SSSOM set (as is the case for the FBbt-provided mappings) or as cross-references (as is the case for the ZFA-provided mappings).

[github-actions]

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.