[rdf12-semantics] Feedback (Part 2) W3C Candidate Recommendation Snapshot (07 April 2026)

Dear RDF & SPARQL Working Group members,

this is my second feedback for the RDF 1.2 Semantics, which extends my 
first feedback by some additional points.


RDF 1.2 Semantics Tests
https://w3c.github.io/rdf-tests/rdf/rdf12/rdf-semantics/
--------------------------------------------------------

* 14) The following test documents, used in some tests as actions, 
contain a redundant prefix "xsd": "lowercase-language-string.ttl", 
"lowercase-dir-language-string.ttl". (Their "uppercase" variants in the 
same tests don't contain the prefix.)

* 15) The tests "triple-terms-propositions" and "reifies-range" can only 
be positive entailments for the RDFS entailment regime, because the 
result graphs contain instanceship triples for class rdfs:Proposition. 
The test metadata should say so for "entailmentRegime".


RDF 1.2 Semantics
https://www.w3.org/TR/2026/CR-rdf12-semantics-20260407/
-------------------------------------------------------

* 16) §5, Definition of a simple interpretation, calling IT the 
"_extension_ mapping for triples in I": I suggest not to use the term 
"extension mapping" but to simply call IT "the mapping for triples in 
I". My reason: Simple entailment already uses the term "extension 
mapping" for the property extension IEXT, but IEXT maps from a domain 
object (the property) to a set of pairs of individuals, intended as the 
extension relation of that property, and it is also meant to be separate 
from the property individual itself. Analog for the class extension 
mapping ICEXT of RDFS interpretations. But IT maps from a 3-tuple of 
domain objects to an individual domain object. Not only has this mapping 
a very a different form compared to IEXT and ICEXT, it also isn't about 
any kind of extension set. And generally I would avoid to (again) 
overload the term "extension", because the RDF Semantics already has two 
very different uses of the term, so that would be a third one.

* 17) §7, value space of a datatype: The document states (already does 
so in RDF 1.1): "The value space of a datatype is the range of the 
lexical-to-value mapping." I think it would be useful to add a 
clarifying sentence here that the value space of a datatype may contain 
values for which there is no corresponding string in the lexical space. 
Or to put it differently, that the lexical-to-value mapping for a 
datatype is _not_ required to be surjective. That may already be implied 
by the use of the term "range", but being clear about it would be nice. 
An example for an existing datatype with this property is owl:real, 
defined by OWL 2 (see https://www.w3.org/TR/owl2-syntax/, Sec. 4.1), 
whose value space consists of the entire set of real numbers. For 
owl:real, it would be technically impossible to have a surjective 
lexical-to-value-mapping, as the cardinality of the real numbers is 
uncountably infinite, whereas the lexical space of any datatype can at 
most be as large as that of the set of all strings, which is countably 
infinite. Also note that owl:real is defined as part of the datatype map 
(would today be the set of recognized datatypes) of the OWL 2 RDF-Based 
Semantics, which is defined as a proper semantic extension of the RDF 
(1.0) Semantics (see https://www.w3.org/TR/owl2-rdf-based-semantics, 
Definition 4.1 in Sec. 4.1 for the OWL 2 RDF-Based Datatype Map, and 
Sec. 3.3 for the table of datatype IRIs). A future version of the OWL 
RDF-Based Semantics would then naturally be based on the RDF 1.2 
Semantics (or higher), and such an update should be made easily possible.


Best regards,
Michael

Received on Sunday, 31 May 2026 16:19:17 UTC