How should mappings be handled?

[jamesamcl]

I think the general consensus in the SSSOM community is that mappings should be moved out of ontologies (hasDbXref) and into external SSSOM files, because (1) it would allow mappings to be updated without updating the ontology, (2) SSSOM has richer semantics than the mapping annotations currently used in ontologies, and (3) mappings are subjective and there is not always one "correct" mapping for a term. @matentzn please correct me if I am wrong about any of this.

If this happens, OLS will start to lose a lot of mapping links between terms which are extremely important for users to navigate between ontologies. I think there are two possibilities for fixing this:

1. OLS integration with OXO. We had this in OLS3. However mappings were only shown "on demand" when you clicked on the mappings tab as it had to query the OXO API each time, rather than being included in results from the OLS API which I think ideally they should be.

2. OLS loading SSSOM files. We could add a mappings section to the OLS config next to ontologies and load them as part of the OLS "linker" stage. Then they would be materialised in the OLS database.

Just throwing some ideas out there and very interested to hear what you think @henrietteharmse

[henrietteharmse]

I very much agree and support the removal of mappings from ontologies. And yes, this will cause dbXrefs to be lost from OLS.
Solution 2 will give comparable behaviour.

[henrietteharmse]

In implementing this we need to take into consideration different ontology editors will have different timescales and approaches to implementing SSSOM. Some may choose to role out SSSOM in 1 go, or in iterations, or (GASP!) not at all. Thus, we are going to have to live with a mixture of ontologies using both dbXref and SSSOM, or only dbXrefs or only SSSOM for some time. I think also for a specific term in a specific ontology it will prudent to assume a mixture of SSSOM and dbXref mappings may be used.

Taking this mixture of use into consideration, I think a sensible strategy will be to give preference to SSSOM where a SSSOM mapping exists for a given ontology from term A to term B. Where a SSSOM mapping from term A to term B is NOT available, we should still include the mapping if it is available on the given ontology as dbXref.

OLS should clearly distinguish between SSSOM mappings and other mappings such as dbXref, exactMatch etc defined in the ontology. As an example, lets consider EFO_0000408 shown below. If both SSSOM mappings and dbXrefs/exactMatch are supplied for this term, it should show a SSSOM mappings section as well as dbXrefs/exactMatch sections, but the dbXrefs/exactMatch sections should only include those mappings that are not given as SSSOM mappings.

Thoughts @haideriqbal @jamesamcl @matentzn @rombaum @okoepler?

[matentzn]

I would love a clear separation! However, SSSOM is not SSSOM, you can basically provide a valid SSSOM mapping which is in essence just a skos:exactMatch statement with a hazy "semapv:UndefinedMatching" justification. Just putting this out there. My overall preference would be this:

1. OLS does what it currently does (I think this is good enough for 95%)
2. OLS cultivates its own mapping commons where it can both pull known existing SSSOM files and extract mappings from ontologies, assign confidence scores etc
3. All those "cultivated" sssom files with OLS preferences make their way into ontotools (either via OLS or OxO, that does not matter for this specific task)
4. A little widget ala OxO 2 UI is shown on each OLS page with all the mappings, including the ones in the ontology, with associated SSSOM metadata.

The long term ideal strategy would be to

1. Have a mapping server ala sssom-api pulling in all mappings in the mapping commons
2. Have an independent mapping service ala oxo2 to browse this
3. Have a widget system that allows to embed SSSOM mapping served from the api directly on the OLS page

Now I know this is all a bit much to stem, but anything that rolls the process towards this will be a great victory.