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

mapping terms with different syntax for values #52

Open
wdduncan opened this issue Mar 2, 2021 · 11 comments
Open

mapping terms with different syntax for values #52

wdduncan opened this issue Mar 2, 2021 · 11 comments

Comments

@wdduncan
Copy link

wdduncan commented Mar 2, 2021

For the DWC-MIXS mappings (see repo), we are finding terms that map in sense that they are about the same thing, but the specification for the syntax of the values is different. An example of this is depth. In DWC, the unit and the scalar are in separate fields, but in MIxS the scalar and unit are in one field (e.g. "3 meters"). See this ticket:

tdwg/gbwg#28

Do we want to develop mappings between to capture differences in the value syntax? FWIW, I think DWC:depth should be mapped as a skos:exactMatch to MIXS:depth. The differing value syntax is an ETL/implementation issue. However, it might still be nice to have a vocabulary for capturing such differences.

cc @cmungall @raissameyer @pbuttigieg

@matentzn
Copy link
Collaborator

matentzn commented Mar 3, 2021

Interesting!

@matentzn
Copy link
Collaborator

@wdduncan do you think we should solve this on SSSOM level? If so, any suggestion how? While I absolutely see the value, I am sceptical about how to do this, other than providing a new sub-hierarchy of annotation properties..

@wdduncan
Copy link
Author

@matentzn I share your skepticism, which is why I added my comment:

FWIW, I think DWC:depth should be mapped as a skos:exactMatch to MIXS:depth. The differing value syntax is an ETL/implementation issue. However, it might still be nice to have a vocabulary for capturing such differences.

Matching syntaxes could be another standard unto itself :)

@ddooley
Copy link

ddooley commented Mar 10, 2021

Just a note that in OBI a few of us pushed for and got a data property has representation that enables one to hold these syntactically encoded strings, as a precursor to actually parsing them into parts.

@wdduncan
Copy link
Author

wdduncan commented Jun 8, 2021

@matentzn I don't think this is necessary out of scope: mapping has both a semantic and syntactic dimension. For example, the DarwinCore to MIxS working group is capturing syntactic differences by adding syntax predicate column (see file here).

@mellybelly
Copy link

shouldn't 'has representation' go in IAO or RO?

@linikujp
Copy link

linikujp commented Jun 8, 2021 via email

@ddooley
Copy link

ddooley commented Jun 8, 2021

@mellybelly I'm open to that idea of moving the data property to IAO or RO. It would be neat if RO took on ALL OBOFoundry relations. When we introduced it I recall not having the impression that IAO relations were being developed, but since that time IAO is being curated by OBI/IAO team jointly (i.e. same telecons). [separate thread I guess].

@matentzn
Copy link
Collaborator

matentzn commented Jun 8, 2021

We should discuss this in person @wdduncan once. Its again too complex for a GitHub issue discussion. Maybe we can use a pattern using UO in conjunction with #43 to solve this problem as well;

@ddooley
Copy link

ddooley commented Jun 8, 2021

This is analogous to exact semantic match on IAO "data item" but different measurement system syntax that comes forth in various ontologies via 'has quantity', 'has unit', 'has representation', 'has value specification' etc.

@matentzn
Copy link
Collaborator

Still a bit queasy about this feature, but there seems to be some pressure. I think the idea of this ticket is now fully subsumed by @cmungall #61 if no one complains until the workshop, I will close this issue here in favour of the other. Basically #61 proposes to define a function that need to be applied to instances of a class/field prior to interpreting the matching predicate.

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

No branches or pull requests

5 participants