obophenotype
Provide Uberon mappings as canonical SSSOM files
While we maintain bridge files for uses related to OWL logical integration, we frequently need more simple mappings for integrating external ontologies into Uberon, i.e. skos or semapv cross-species mappings. While we can obtain some mappings using OAK (using the oboInOwl:hasDBXref property) they have a few undesirable properties like a lot a good number of proxy merges (Uberon:nerve maps to Xenopus:nerve AND Xenopus:peripheral_nerve).
This is not the same as (but related to) @gouttegd effort to moving the maintainance of mappings to SSSOM format. This is about sharing the final set with the community.
All such proxy merged functions in uberon should be intentional (and rare). Uberon takes the position that in xao there are no nerves that are not peripheral. The so called cranial nerves are not nerves. Ideally we would open issues on external trackers for all such proxy merges
On Sat, Mar 11, 2023 at 4:04 AM Nico Matentzoglu @.***> wrote:
While we maintain bridge files for uses related to OWL logical integration, we frequently need more simple mappings for integrating external ontologies into Uberon, i.e. skos or semapv cross-species mappings. While we can obtain some mappings using OAK (using the oboInOwl:hasDBXref property) they have a few undesirable properties like a lot a good number of proxy merges (Uberon:nerve maps to Xenopus:nerve AND Xenopus:peripheral_nerve).
This is not the same as (but related to) @gouttegd https://github.com/gouttegd effort to moving the maintainance of mappings to SSSOM format. This is about sharing the final set with the community.
— Reply to this email directly, view it on GitHub https://github.com/obophenotype/uberon/issues/2833, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOOATJWPRC6TEQYKIWLW3RS3FANCNFSM6AAAAAAVXOHNAU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Made a new issue for the proxy merge review and issue suggestion you made @cmungall: https://github.com/obophenotype/uberon/issues/2834
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
PR #3061 generates a SSSOM version of the mappings as part of the bridge generation process. For now this is an intermediate file (generated in src/ontology/tmp) that is not published, but this could easily be changed.
More people are asking for this, we should really do it. The final set is built as part of the normal release pipeline, all we need to do is to treat it as a release product rather than as a temporary file.
Do we need another mappings folder just off the repo root which contains the generated mappings in ODK? Especially for those ontologies that release on GitHub rather than as attachments to GitHub releases?
It would also be nice to get some basic "justification" stuff in there. Maybe as a second step.
Do we need another mappings folder just off the repo root which contains the generated mappings in ODK?
That’s a discussion to be had on the ODK repo. I wouldn’t say we need that, but that’s certainly one of the things that the ODK could help standardise (so that if you know that a given ontology follows the ODK workflows, then you know that you can find its mappings in mappings/).
It would also be nice to get some basic "justification" stuff in there.
Not sure what you mean here. Justification for the decision to publish the Uberon mappings? Well, because as I’ve said some people want them, and ideally they don’t want to have to extract them from the ontology.
Or are you referring to the mapping_justification of the Uberon mappings? For now, they are all semapv:UnspecifiedMatching, because they are derived from xrefs and we cannot know what was the justification for those xrefs.
With #3249, the “meta“ mapping set will be available as a release artefact under the name Uberon.sssom.tsv.
With the default PURL redirection already in place, that artefact will be accessible at http://purl.obolibrary.org/obo/uberon/uberon.sssom.tsv, as soon as the next Uberon release happens.