Skip to content
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

New method: flip #315

Closed
matentzn opened this issue Sep 21, 2022 · 7 comments · Fixed by #346
Closed

New method: flip #315

matentzn opened this issue Sep 21, 2022 · 7 comments · Fixed by #346
Assignees

Comments

@matentzn
Copy link
Collaborator

@kevinscharper noted in monarch-initiative/monarch-app#721 that if you are not careful and "blindly apply" a mapping file to a dataset, you may end up applying it the wrong way. For example, Mondo SSSOM mappings have Mondo IDs in as subject_id and external ID's such as OMIM as object_ids.

I propose the development of a flip method that allows to swap subject and object. This is not just about "flipping IDs", you have to

  • make sure that all subject and object specific fields are flipped accordingly, and
  • skos:broadMatch gets flipped to skos:narrowMatch etc.

This method could be useful, I think, because it allows us to centralise the logic by which we permit flipping. For example, we can simply ignore cases where flipping would be clearly wrong, or the "inverse" properties are not known.

@cmungall
Copy link
Collaborator

Yes, flip and also normalizing to a canonical subject or object Id space

@matentzn
Copy link
Collaborator Author

@hrshdhgd from a priority perspective this comes after oak-synonimizer and monarch-initiative/mondo-ingest#78.

@gouttegd
Copy link
Contributor

I second this proposal and was actually about to open a ticket to request such a feature.

Being able to automatically “flip” a mapping set would be helpful for the Uberon/CL-to-taxon-specific-ontology mappings, if we plan (as was the idea) to allow for them to be managed either on the Uberon/CL side or on the taxon-specific side, because we might then have to deal with mapping sets that are in a different “direction” (Uberon-maintained mappings would likely be using Uberon terms as subjects and the foreign terms as objects, whereas externally maintained mappings would likely be the other way round).

@matentzn
Copy link
Collaborator Author

Its in the high priority issues and will be addressed before end of March I think

@gouttegd
Copy link
Contributor

Do we agree on how the semapv:crossSpecies*Match predicates should be inverted?

For me, it should be:

  • A semapv:crossSpeciesExactMatch B -> B semapv:crossSpeciesExactMatch A
  • A semapv:crossSpeciesNarrowMatch B -> B semapv:crossSpeciesBroadMatch A
  • A semapv:crossSpeciesBroadMatch B -> B semapv:crossSpeciesNarrowMatch A
  • A semapv:crossSpeciesCloseMatch B -> cannot invert, drop

Makes sense?

@matentzn
Copy link
Collaborator Author

We have a draft document for this here: https://mapping-commons.github.io/sssom/chaining_rules/

Feel free to review and give feedback!

@gouttegd
Copy link
Contributor

Proposal to add rules for these predicates: mapping-commons/sssom#261

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants