Four of five SSSOM data publications don't follow the specification

[nichtich]

Searching for real world examples of SSSOM data publications on Zenodo.org listed 5 publications so far. I've tried to parse each of them with sssom-py, only one could be processed:

1. https://zenodo.org/records/13851334 - broken header
2. https://zenodo.org/records/8371883 - not TSV but CSV
3. https://zenodo.org/records/8428561- not TSV but CSV
4. https://zenodo.org/records/10936294 - ok
5. https://zenodo.org/records/11082039 - missing (external) metadata block

Looks like SSSOM/TSV is mainly used as write-only format in existing data publications, without actual reuse.

[matentzn]

Very important discussion. My experience is that people publish their mappings in SSSOM often to fulfill some externally provided requirement (say, to make a grant authority happy), or end up cherry picking some of the sssom columns/attributes to enhance their existing model without the intention to publish fully compatible SSSOM. I think as is usually the case either FAIR, true reuse is an afterthought. The best way imo to encourage the publication of standard compliant mappings are useful tools: if they can't read a file because it's not formatted correctly, users are more inclined to complain (and the mapping owner is also more inclined to format the mapping to be able to use the tool).

My inclination is to invest into a large scale mapping browser like OxO which require mappings to be formatted correctly in order to show (and therefore promote) them - similar to what OLS does for ontologies.

[nichtich]

The best way imo to encourage the publication of standard compliant mappings are useful tools

Yes, SSSOM Validator is a great contribution (running at https://sss-om-validate.streamlit.app/)!

[matentzn]

Thanks but what I mean is more tools that are consumer, not maintainer, facing..

[gouttegd]

https://zenodo.org/records/10936294 - ok

In fact even that file is not compliant either – the wikidata: prefix is not declared. SSSOM-Py does not complain because it somehow “knows” that prefix, but the specification is clear that only a handful of prefixes can be dispensed from being declared in a prefix map – SSSOM sets must be self-sufficient and not rely on the fact that a given implementation may know more prefixes than those mandated by the specification.

[gouttegd]

And it is also missing the mapping_justification slot – not sure why SSSOM-Py does not flag that, but again the spec is clear, that slot is mandatory.

[matentzn]

When you say sssom-py does not complain I assume you mean when running a random command like "convert"? Because it should complain when you use "validate"!

[gouttegd]

Ah yes, I only tried convert, forgot about the validate command, my bad!

Well, validate does complain about the missing declaration for the wikidata: prefix. It does not complain about the missing mapping_justification slot.

[nichtich]

The list of known publications has been extended but only two valid examples found so far. In addition the list of data sets at mapping-commons does not look much better:

fars_obo_omop.cpath.sssom.tsv: mapping_set_id must be Uri: fars_obo_omop
fars_obo_omop_invert.cpath.sssom.tsv: mapping_set_id must be Uri: fars_obo_omop_invert
hp_doid_pistoia.sssom.tsv: mapping_set_id must be Uri: hp_doid_pistoia
ma_uberon_pat_impc.sssom.tsv: mapping_set_id must be Uri: ma_uberon_pat_impc
mondo_hasdbxref_hp.sssom.tsv: Unknown or invalid CURIE at line 16: http://purl.obolibrary.org/obo/mondo.owl
mondo_hasdbxref_icd10cm.sssom.tsv: Unknown or invalid CURIE at line 17: https://www.icd10data.com/
mondo_hp_lexical.sssom.tsv: Unknown or invalid CURIE at line 16: http://purl.obolibrary.org/obo/hp.owl
mondo.sssom.tsv: VALID
mp_doid_pistoia.sssom.tsv: mapping_set_id must be Uri: mp_doid_pistoia
mp_hp_eye_impc.sssom.tsv: mapping_set_id must be Uri: mp_hp_eye_impc
mp_hp_hwt_impc.sssom.tsv: mapping_set_id must be Uri: mp_hp_hwt_impc
mp_hp_mgi_all.sssom.tsv: VALID
mp_hp_owt_impc.sssom.tsv: mapping_set_id must be Uri: mp_hp_owt_impc
mp_hp_pat_impc.sssom.tsv: mapping_set_id must be Uri: mp_hp_pat_impc
mp_hp_pistoia.sssom.tsv: mapping_set_id must be Uri: mp_hp_pistoia
mp_hp_xry_impc.sssom.tsv: mapping_set_id must be Uri: mp_hp_xry_impc
obo_omop.cpath.sssom.tsv: mapping_set_id must be Uri: cpath_obo_omop
obo_omop_invert.cpath.sssom.tsv: mapping_set_id must be Uri: cpath_obo_omop_invert
omop2obo_condition.sssom.tsv: Missing Mapping slot: subject_id at line 35920
omop2obo_drug_exposure.sssom.tsv: Missing Mapping slot: subject_id at line 9063
omop2obo_measurement.sssom.tsv: Missing Mapping slot: subject_id at line 12910
ordo_doid_pistoia.sssom.tsv: mapping_set_id must be Uri: ordo_doid_pistoia
ordo_mp_pistoia.sssom.tsv: mapping_set_id must be Uri: ordo_mp_pistoia
pato_hp_pat_impc.sssom.tsv: mapping_set_id must be Uri: pato_hp_pat_impc

The errors Unknown or invalid CURIE first made me wonder but mapping set slot subject_source is defined with type EntityReference and according to SSSOM specification this "MUST be serialised in CURIE syntax". http://purl.obolibrary.org/obo/mondo.owl is not a CURIE. Even if both CURIE and URI would be allowed, the spec would need to explicitly address https://www.w3.org/TR/2010/NOTE-curie-20101216/#sec_2.2.

Specifications for particular attribute values or other content MAY be written to allow either CURIEs or IRIs (or URIs, etc.). The specifications for such languages MUST provide rules for disambiguation in situations where the same string could be interpreted as either a CURIE or an IRI.

tl;dr: only four of 46 SSSOM data sets in the wild strictly follow the SSSOM 1.0 specification. The rest is only usable after intellectual inspection and manual cleanup, if at all. This makes current SSSOM 1.0 impractical for any serious data exchange. Some common errors might be recoverable from with more lax rules in SSSOM 1.1 (e.g. make mapping_set_id, allow SSSOM/CSV, recommend to ignore invalid mapping_set_id...).

[nichtich]

I expected an absolute URI or IRI but xsd:anyURI allows for relative IRI Reference in fact. Unfortunately the use of relative references requires a base to become an URI/IRI, so part of the metadata is shifted out of the SSSOM file to its context. I would welcome to only allow absolute IRI or at least RECOMMEND the use of absolute values because relative values easily resolve to file:// IRIs unless some other base is tracked all way long via means outside of the scope of SSSOM specification.

[gouttegd]

Unfortunately the use of relative references requires a base to become an URI/IRI, so part of the metadata is shifted out of the SSSOM file to its context.

Yes, I fully agree that relative URIs make little sense, especially since there is no concept of “base” in SSSOM.

It would be possible to add a sssom_base slot and say that relative URIs must be resolved relatively to sssom_base, but I would see that as a frankly unwelcome complication.

I’d rather propose two possible ways out for SSSOM 1.1:

(A) Recommend (“SHOULD”) that all URI-typed slots be expected to contain absolute URIs, but SSSOM parsers MUST still accept relative URIs (possibly with a warning).

This is the easiest solution for implementers, which automatically guarantees backwards compatibility with existing 1.0 sets.

(B) Mandate that in SSSOM 1.1 all URI-typed slots MUST contain absolute URIs only.

This is the cleanest solution, but it means that implementations that want to support both 1.0 and 1.1(+) sets must be ready to treat URI-typed slots differently depending on which version a set declares itself to be compliant with.

That is, if a set does not have a sssom_version slot, then it is a 1.0 set and parsers must accept any form of URI in URI-typed slots; if the set has a sssom_version=1.1 slot, then it is a 1.1 set and parsers must reject relative URIs in URI-typed slots.

[nichtich]

Yes, sssom_base makes no sense. Neither publishing SSSOM files with relative IRI References. I'd prefer (B) to not encourage the use of relative IRI References. As consumer of SSSOM files with relative IRI References I have three options:

1. ignore the slots (possibly with a warning, possibly removing relevant and required information)
2. reject these files, effectively not supporting this feature of SSSOM 1.0
3. enrich these slots with a base URI, given as additional parsing option

I'd go for 2 by default, but for 3 if a base URI is explicitly given as parsing option. This parsing option would enable SSSOM 1.0 mode, so both sssom_version=1.1 and relative IRI References together, result in an error (Option B).

[gouttegd]

reject these files, effectively not supporting this feature of SSSOM 1.0

I don’t understand why you couldn’t simply accept the URIs as they are (relative URIs), when consuming a 1.0 set?

both sssom_version=1.1 and relative IRI References together, result in an error (Option B).

Yes, that’d be the idea with option B.

[nichtich]

I don’t understand why you couldn’t simply accept the URIs as they are (relative URIs), when consuming a 1.0 set?

Relative URIs are no URIs but they are URI references to be mapped to a full URI. "simply accept" without base URI means to throw away for any use case that requires URIs. I see no value in adding an internal flag "this slot should be an URI but actually it isn't" to any tool processing SSSOM.

[matentzn]

I dealt with the MH mappings and CPATH ones (not yet fixed but will be I am sure), if you can be bothered to share issues with me of other broken SSSOM files, I will get them all fixed.

[nichtich]

Thanks! Updated analysis Looks much better