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

Proposal for accommodating complex mappings #36

Closed
matentzn opened this issue Aug 22, 2020 · 1 comment
Closed

Proposal for accommodating complex mappings #36

matentzn opened this issue Aug 22, 2020 · 1 comment
Labels

Comments

@matentzn
Copy link
Collaborator

Note: all comments in the following apply to both subject and object fields.

The normal mapping case is when one term in a source set (subject) is mapped to exactly one term in the target set (object).
There are, however, many cases where we need to map sets of terms (subject and/or object), for example:

UBERON:Eye+NCBITaxon:Xenopus->XAO:Eye
MP:adiposeTissuePhenotype+PATO:abnormal->HP:AbnormallyAdiposeTissue
MP:X due to DO:1 -> HP:Y due to MONDO:1

This is can become a complicated mess, but I suggest the following:

  1. We allow pipe separated term lists for both subject_id and object_id. These lists are considered in the order given.
  2. We introduce a new (optional) field called object_pattern which is, by default, none (which means everything in subject_id is considered to be a single identifier pertaining to one term). Now if someone wishes to create a complex mapping, they would write a complex expression like RO:001 some (%s and (RO:002 some %s)) or simply %s and %s (see how we did this in a different context using templates). The filler terms (%s) are filled one by one with terms from the pipe seperated list in subject_id, which materialises the expression, for example, as an owl_class_expression.
  3. We introduce a new (optional) field called object_pattern_type, which is, if NOT set, interpreted to be a "class expression in manchester syntax" (so there is no need to set it). This could be used in the future to accomodate other kinds of patterns as well (there are complex expressions for example in the RBOX that are not class expressions, but maybe someone wants to use this to map non-owl patterns as well).

Does this make sense?

@cmungall @kshefchek @mellybelly @diatomsRcool @balhoff

@matentzn
Copy link
Collaborator Author

Superceded by #108

@matentzn matentzn closed this as not planned Won't fix, can't repro, duplicate, stale Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant