Generalize use of SSSOM for mappings to external resources

[gouttegd]

This PR generalises the use of SSSOM for most mappings to foreign ontologies and external resources, instead of using it only for mappings with Uberon and CL.

It also changes the way the Uberon/CL mappings are edited. Previously, they were maintained in an ad-hoc TSV file (similar but not identical to the SSSOM/TSV format) which was transformed at build time into a bona fide SSSOM/TSV file. This seemed like a good idea at the time we switched those mappings to SSSOM, but I now think this is an unneeded complication and that it is much simpler to maintain those mappings in the SSSOM/TSV format directly.

So, we now have a handful of SSSOM/TSV files in src/mappings:

• common.sssom.tsv: intended for mappings with foreign OBO ontologies, such as Uberon, CL, GO, CARO, BSPO, etc.;
• door.sssom.tsv: for mappings with the Database of Odorant Responses
• larvalbrain.sssom.tsv: for mappings with Larvalbrain.org;
• flybrain.sssom.tsv: for mappings with the FlyBrain Neuron Database

At release time, all those sets are combined into a single fbbt.sssom.tsv set, which is published alongside the other release artefacts. Also, the entire set is used to create the src/components/mappings_xrefs.owl component, which contains xref annotations for all the mappings (this component replaces both the exact_mappings.owl component, which contained xrefs for the mappings with Uberon/CL, and the larvalbrain_fascicles.owl and larvalbrain_compartments.owl components, which contained xrefs for the mappings with larvalbrain.org).

[gouttegd]

@Clare72 Just checking with you that you are happy with using SSSOM for all those mappings.

The one drawback of using SSSOM is that the mappings can no longer be edited directly within Protégé (by adding, removing, or editing hasDbXref annotations), the SSSOM/TSV file has to be edited separately in a standard text editor.

I have not touched the mappings with VFB (in the VFB_xrefs.owl), since those are already automatically generated by the scripts/VFB_xrefs.py script. For consistency, it would be easy to modify that script to make it generate a SSSOM/TSV file instead of a ROBOT template. Let me know if you want me to do that.

[Clare72]

Yes, I think the end result (release files) will be the same after this update, so happy to maintain as a tsv. I have some notes somewhere on the mapping exactness (for larvalbrain and flybrain) and might review at some point, but not super important. There are some more mappings that go in via dosdp - externalAnatomyLinkouts.yaml. Feel free to migrate these (or not). I don't think there is any real benefit to switching the VFB xrefs (they are not really 'mappings' anyway - just a hack to get links to show up on FlyBase).

[gouttegd]

There are some more mappings that go in via dosdp - externalAnatomyLinkouts.yaml. Feel free to migrate these (or not).

Ah, I somehow missed those. Since they are already maintained as TSV, it makes sense to migrate them to SSSOM/TSV, I’ll do that now.