Have a look at coli-conc, JSKOS and Cocoda

[nichtich]

Our project has been creating standards and tools for management and exchange of concordances between library knowledge organization systems since 2015. Somehow we both managed to ignore each other despite the large overlap of our goals. The only reference to both I found is at the minutes of EUDAT Conference September 2022.

I create an issue to align SSSOM and JSKOS data format. To avoid some confusion the core elements of our work are:

• coli-conc: the project
• JSKOS: the data format (broader than SSSOM)
• JSKOS API: Web API to access terminology data and mappings, implemented for multiple backends
• JSKOS Server: Reference implementation of JSKOS API, our main backend
• Cocoda: web application to manage and create mappings

Main use cases are classifications and authority files from libraries, museums and related cultural heritage institutions. Our main database contains ~380.000 curated mappings collected from multiple mapping projects.

By the way we also run the Basic Register of Thesauri, Ontologies & Classifications (BARTOC) (probably the most comprehensive catalog of vocabularies) on the same technology stack and we will be happy to integrate data from terminologies and applications using SSSOM.

[matentzn]

@nichtich Very interesting, super odd we have not come across coli-conc during our literature review! It is good to know that some other efforts are trying to bring some order into the chaotic reality of entity mappings out there! I checked out your format, and it should be fairly easy to add converters to https://github.com/mapping-commons/sssom-py.

I am not too concerned about overlapping standards - I am happy that multiple groups try to promote principled approaches for collecting mappings. Building adapters is easy. Getting people to actually provide mappings in any kind of standard format is the real challenge!

I like your server, we will definitely check it out. Thank you for bringing JSKOS to our attention!

[nichtich]

By the way, there is also a TSV/CSV format for JSKOS but this is less strictly standardized so we may better align the tabular formats of SSSOM and JSKOS to a common format. By now the difference is:

• subject_id = fromNotation but I am not sure whether SSSOM TSV uses semantic prefixes in this field. How is HP:0009124 converted to an URI? JSKOS further supports more complex mapping rules, e.g. to support whitespace in ids or to map id 361.3 to URI http://dewey.info/class/361.3/e23/
• object_id = toNotation
• creator = creator
• subject_label = prefLabel
• predicate_id = type but without skos: prefix e.g. close instead of skos:close
• object_label not supported in JSKOS CSV
• mapping_justification not supported in JSKOS CSV

[matentzn]

Excellent, yes, this looks pretty straight forward.

If you scroll through the tutorial (https://mapping-commons.github.io/sssom/tutorial/) you will get a better sense I think. We require the subject_id etc to be a resource identifier which we internally represent as a CURIE. The corresponding curie map is supplied in the header of the TSV file (see tutorial).

We do not support wildcards (I assume this is what you mean by "whitespace" in your comment), as we are strictly enforcing CURIE format https://www.w3.org/TR/2010/NOTE-curie-20101216/

[nichtich]

On mapping identifiers @matentzn wrote in mapping-commons/sssom-py#342 (comment):

SSSOM (TSV) lacks mapping identifiers? We manage JSKOS mappings in a database (see api endpoint) so unique identifier for each mapping (=row in SSOM TSV) are important)

There were long debates about this. Basically you have two options:

1. Ever mapping gets a unique ID. This is very nice for provenance and makes the mapping easier to use.
2. Every mapping has a primary key that is comprised of multiple slots/columns. So basically, if a mapping is defined by subject_id, predicate_id and object_id (primary key), you do not need a specific named key. The advantage for this is that the exact same mapping coming from different sources can be recognised as being the same.

We also discussed the two options of mapping identifiers and came up with

• each mapping should have an URI for provenance
• every mapping gets two identifiers calculated from URIs of participating concept URIs ("mapping members identifier"), and URIs of participating concept URIs plus mapping type ("mapping content identifier"), respectively.

See examples at https://coli-conc.gbv.de/api/mappings, field uri (based in UUID when mapping is saved to database) and identifiers (derived from mapping members/content).

[matentzn]

Thanks, I can see these:

"identifier": [
      "urn:jskos:mapping:content:691890e36f3916efa9ed2b0521f8126f7badb3e6",
      "urn:jskos:mapping:members:612f100f6b711d210a047eb6e2646428961162a7"
    ],

I think an automatically calculated mapping identifier would be pretty nice to have. I am not sure if I understand the need for a manually curated mapping identifier though. Can we separate these two discussions entirely?

[nichtich]

There is no manually curated mapping identifier. If you use Cocoda and save a mapping into our mapping database, it get's a unique URI such as https://coli-conc.gbv.de/api/mappings/e249d7b0-21bd-4292-a9ce-0f77fc03c0c7. If someone else creates another mapping between the same concepts, it gets another URI but same identifier "urn:jskos:mapping:members:e8ae261f3a32a16a0ceef3065ab2d31fbe24a19c". If both mappings also have same mapping type (aka property_id), both also get same identifier "urn:jskos:mapping:content:935d6ed85b3c43cb676e5bbaf3d868c974e3a5e9".

[matentzn]

Yes, something like this does make sense to me as well.

The way you understand the sssom ecosystem at the moment, would we:

1. add an identifier slot to the data model, and declare it as "generated" or some such (but not required for now - that will cause a stir)
2. add a piece of code to sssom-py that will generate mapping identifiers (sssom generate-identifiers ...) using a scheme like the one you are proposing?

It will cause a bit of roccus to generate non-semantic web identifiers though (i personally love the urn's), but that is a separate issue