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/

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?

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".

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

entity mapping in JSKOS is pretty much Concept Mapping https://gbv.github.io/jskos/#concept-mappings, no?

Yes, it was not included in the taxonomy so I was unsure, but entity mapping (RDA) is concept mapping (JSKOS). So only mapping specification is somehow unclear, the paradigm seems to be different from JSKOS use cases.