mapping_set_id in RDF should be subject instead of literal object

[nichtich]

Converting this minimal, empty mapping set

# mapping_set_id: https://example.org/mappings
# license: https://creativecommons.org/licenses/by/4.0/
subject_id	predicate_id	object_id	mapping_justification

results in

@prefix dct: <http://purl.org/dc/terms/> .
@prefix sssom: <https://w3id.org/sssom/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

[] a sssom:MappingSet ;
    dct:license "https://creativecommons.org/licenses/by/4.0/"^^xsd:anyURI ;
    sssom:mapping_set_id "https://example.org/mappings"^^xsd:anyURI .

but it should be

@prefix dct: <http://purl.org/dc/terms/> .
@prefix sssom: <https://w3id.org/sssom/> .

<https://example.org/mappings> a sssom:MappingSet ;
    dct:license <https://creativecommons.org/licenses/by/4.0/> .

[cthoyt]

agreed!

here's where RDF serialization happens:

sssom-py/src/sssom/writers.py

Lines 274 to 283 in c99be4d

	def to_rdf_graph(msdf: MappingSetDataFrame) -> Graph:
	"""Convert a mapping set dataframe to an RDF graph."""
	doc = to_mapping_set_document(msdf)
	graph = rdflib_dumper.as_rdf_graph(
	element=doc.mapping_set,
	schemaview=SchemaView(SCHEMA_YAML),
	# TODO Use msdf.converter directly via https://github.com/linkml/linkml-runtime/pull/278
	prefix_map=msdf.converter.bimap,
	)
	return graph

this means that we're currently constrained to RDF getting produced by an upstream implementation from LinkML, and we can't actually change any of that from the SSSOM-py codebase at the moment. The question is whether the LinkML definition of the SSSOM data mdoel is configurable to accomplish what you suggested (I don't personally know)

[nichtich]

FYI sssom-js now supports RDF export as described above.

[gouttegd]

The question is whether the LinkML definition of the SSSOM data mdoel is configurable to accomplish what you suggested

All that would be needed is to define the mapping_set_id and license slots to be EntityReference rather than URI.

Not keen on making such a change in post-SSSOM 1.0, though.

[matentzn]

All that would be needed is to define the mapping_set_id and license slots to be EntityReference rather than URI.
Not keen on making such a change in post-SSSOM 1.0, though.

I wonder now.. Especially the Linked Data folks will be fuming when they realise mapping_set_id is not a resource identifier / entity reference.. Would you prefer the introduction of a new slot to do the same thing, just as an entity reference?

[gouttegd]

Would you prefer the introduction of a new slot to do the same thing, just as an entity reference?

What I would prefer:

• The mapping_set_id slot remains a URI-typed slot (with clarification that – at least in SSSOM 1.1 – it is expected to be an absolute URI, as discussed elsewhere).
• When serialising to RDF, the mapping_set_id slot is rendered as a subject of all the triples representing the set metadata (as in the second example shown in the original message).
• Of course, when de-serialising from RDF, we apply the opposite logic, that is, the mapping_set_id slot is to be taken from the subject of the ... a sssom:MappingSet triple.

The reason I’d prefer that is that it would only affect the RDF serialisation. In particular, SSSOM/TSV would in no way be impacted by this (and all current SSSOM/TSV files would remain valid).

By contrast, if we make mapping_set_id an EntityReference, then this:

# mapping_set_id: https://example.org/mappings

would become invalid, because we have this requirement that all EntityReference-typed slots MUST be rendered as CURIEs in SSSOM/TSV.

[gouttegd]

⏫ The problem with the above suggestion (treating mapping_set_id as an entity reference only in the context of RDF serialisation) is that it would require SSSOM-Py to stop relying entirely on the LinkML runtime as far as RDF is concerned.

As noticed by @cthoyt , for now SSSOM-Py produces RDF simply by calling rdflib_dumper.as_rdf_graph, which is very convenient but would never allow to treat mapping_set_id differently. SSSOM-Py would need to implement its own RDF serialisation logic.

(This would not be an issue for SSSOM-Java and SSSOM-JS, since those implementations never had any LinkML runtime to rely on in the first place!)

So in fine, the choice is between:

(A) making mapping_set_id an EntityReference, which would break all existing sets in SSSOM/TSV format because the value of mapping_set_id would now have to be a CURIE, but which would allow SSSOM-Py to produce the desired RDF output without any change to its RDF serialisation code (assuming rdflib_dumper.as_rdf_graph automatically does The Right Thing™️ when dealing with EntityReference-typed slots, which I sure hope it does);

(B) keeping mapping_set_id a (absolute) URI that, as a special case, must be rendered as a subject in RDF – which would not break any existing set but would mean more work for SSSOM-Py.

As I already said, I am in favour of (B). It would be different if we were not already nearly one year after the publication of SSSOM 1.0, but now, the idea of breaking existing sets just to make life easier for SSSOM-Py developers is, in my opinion, unacceptable.

[nichtich]

SSSOM-Py would need to implement its own RDF serialisation logic.

Fortunately not, when creating RDF via an existing JSON-LD processor (#592).

[gouttegd]

Nice. Then I see even less reason to make mapping_set_id an entity reference (option A), if there is a (reasonably) easy way for SSSOM-Py to implement option B.

[matentzn]

This ticket is now fully subsumed by the RDF serialisation spec right? As long as no one presses to type mapping_set_id as entity reference, there is nothing else here that needs special attention.

[gouttegd]

The proposed spec does exactly what is requested here (specify that mapping_set_id must be represented as the RDF subject resource).

But I’d keep this ticket open since we are here on the repo for the SSSOM-Py implementation, not the repo for the spec. And SSSOM-Py will need some special attention to implement the newly specified behaviour.