-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide Uberon mappings as canonical SSSOM files #2833
Comments
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
<#2833>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMMOOATJWPRC6TEQYKIWLW3RS3FANCNFSM6AAAAAAVXOHNAU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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. |
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 |
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 It would also be nice to get some basic "justification" stuff in there. Maybe as a second step. |
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
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 |
With #3249, the “meta“ mapping set will be available as a release artefact under the name With the default PURL redirection already in place, that artefact will be accessible at |
Aweeeesome! |
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.
The text was updated successfully, but these errors were encountered: