mapping terms with different syntax for values

[wdduncan]

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:

https://github.com/tdwg/gbwg/issues/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]

Interesting!

[matentzn]

@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]

@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]

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]

@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]

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

[linikujp]

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 https://github.com/mapping-commons/SSSOM/issues/52#issuecomment-856388020, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPEPIP332LE3S2M6A4MADTRV5MRANCNFSM4YPVUXIA .

[ddooley]

@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]

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]

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]

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.