SSSOM example uses invalid SSSOM

[nichtich]

The example given at Assembly refers to an invalid SSSOM file:

import semra.io

# load mappings from any standardized SSSOM file as a file path or URL, via `pandas.read_csv`
sssom_url = "https://w3id.org/biopragmatics/biomappings/sssom/biomappings.sssom.tsv"
mappings = semra.io.from_sssom(sssom_url)

File https://w3id.org/biopragmatics/biomappings/sssom/biomappings.sssom.tsv currently lacks a SSSOM MappingSet header so it can only be parsed as valid SSSOM with external metadata to specify at least required fields mapping_set_id and license.

Function from_sssom could be extended an documented to

• support mapping_set_id with default value derived from path (URL or file:// - URI)-
• support license with default value

mappings = semra.io.from_sssom(sssom_url, license="https://creativecommons.org/licenses/by/4.0/")

[cthoyt]

@nichtich thanks for the feedback. I already started a PR to make this example work, but I'm going to go more deeply into making sure that the data model is more aligned with SSSOM. Right now, SeMRA requires name for each mapping set, but not an ID. This is not the same as as SSSOM, which requires an ID, but title is optional.

[nichtich]

FYI: I'm creating a mapping between SSSOM data model and JSKOS data model

• implementation in sssom-js, see lib/jskos.js
• full list of slots and fields compared:
  • SSSOM Mapping corresponds to JSKOS Concept Mapping
  • SSSOM MappingSet corresponds to JSKOS Registry

I'd say JSKOS is a much larger superset of SSSOM except for Negative mappings (predicate_modifier) and information about mapping strategy. Some JSKOS features not supported by SSSOM:

• labels have language tags and there can be multiple labels
• there can be one-to-many mappings with multiple target concepts combined by AND (e.g. alchemy = chemistry + magic)

In addition, JSKOS is JSON(-LD) so no need to have a special parser for TSV plus YAML header and you get RDF for free.

For SeMRA it may worth to consider supporting a superset of SSSOM as well, so mapping set id should be optional but when SSSOM is parsed, missing mapping set id is invalid according to SSSOM specification.

[cthoyt]

That's great! If you ever want to hop on a call to talk through the JSKOS-SSSOM mapping then I'm happy to help. I know that the issue mapping-commons/sssom#359, mapping-commons/sssom#361, and mapping-commons/sssom#436 would probably be helpful for you.

For SeMRA it may worth to consider supporting a superset of SSSOM as well, so mapping set id should be optional but when SSSOM is parsed, missing mapping set id is invalid according to SSSOM specification.

This is a good point too. In #61, I started working towards that. I'll introduce an optional mapping set ID soon and just make sure that when it's missing and we're writing to SSSOM, that something meaningful gets put there.