Minimal spec - The 'Simple' part of the SSS

[joeflack4]

Overview

There's been a variety of situations where I've tried to explain or get people to use SSSOM, and sometimes it can be confusing for them. At the moment, there is a particular working group that wants to add mapping metadata to some data structures. They looked at SSSOM, but it looked too complex to them. We should emphasize that the core part of SSSOM is indeed simple, and I think maybe make it one of the first things that someone entirely unfamiliar with SSSOM sees when looking at the docs.

Details

I chatted w/ Nico and these are the parts of the spec that should be in the most minimal / simple format:

• subject_id
• predicate_id
• object_id
• mapping_justification

I would even daresay that mapping_justification should be listed as optional there as well.

Additional info

It might also be good to suggest some predicate_ids that people can use, with examples. For example, it can be confusing to pick between skos:narrower and skos:narrowMatch, and to know what to choose for your subject/object if all you want to say is "a is a narrower case than b".

Related: https://mapping-commons.github.io/sssom/5star-mappings/

[graybeal]

Couldn’t agree more. I think one of the more challenging bits is being required to come up with a reason for every mapping. Who does that, even among experts? But I think that argument was lost long ago in the spec, no?

I would be especially enthusiastic to have a really good basic example spreadsheet that embeds self-explanatory documentation. A large percentage of beginners would instantly grok the paradigm without any further instruction needed.

We don’t have a SSSOM validation tool yet, do we? (Just wondering how I would know if an example I made was valid.)

[saubin78]

Very good point. I was actually looking for instructions in the documentation regarding mandatory elements both at mapping and mapping set levels. Looking at the detailed specifications, I relied on the cardinality info.
At mapping set level :

• mapping_set_id
• license

This is fine but we may also want at least one information regarding provenance, maybe who (person/organisation) responsible for publishing the mapping set, probably creator_id.

At mapping level:

• subject_id
• predicate_id
• object_id
• mapping_justification

Regarding mapping_justification, I have mixed feelings, especially after reading #211 . You say here that this is made "to explain how the mapping came into being" (not the reason for the mapping) which is crucial as it can make the difference between fully automatically computed mappings (low value) vs. manually, curated mappings (high value, unreproducible).
As we will necessarily face cases where this information is not known (republishing existing mappings created by others is a very probable case), I felt that the option "sempav:UnspecifiedMapping" was reasonable.
But I see that thoughts have evolved since then... This may be discussed more largely with mapping users. A good topic for a workshop ;-)

[matentzn]

There is a workshop right now being organised by @ylefranc and @jonquet that covers all of what you are debating here (it is not SSSOM specific, but covers much the same bases).

@graybeal We use validation, also in GitHub actions! see for example here