-
Notifications
You must be signed in to change notification settings - Fork 24
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
Comments
Interesting! |
@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.. |
@matentzn I share your skepticism, which is why I added my comment:
Matching syntaxes could be another standard unto itself :) |
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. |
shouldn't 'has representation' go in IAO or RO? |
Thumbs up for this issue. I am watching to see if a solution will be agreed
here. There are a lot of this kind of examples in data elements mapping,
such as a person's age in year, or in days. Might be off the topic here...
but I am interested in following up with this.
Thanks,
Asiyah
…On Mon, Jun 7, 2021, 22:24 Melissa Haendel ***@***.***> wrote:
shouldn't 'has representation' go in IAO or RO?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPEPIP332LE3S2M6A4MADTRV5MRANCNFSM4YPVUXIA>
.
|
@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]. |
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. |
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. |
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 askos:exactMatch
toMIXS: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
The text was updated successfully, but these errors were encountered: