the "semantic sugar" approach

Don't worry, this is NOT yet another approach ! On the contrary, it is 
an attempt to reconcile the different approaches currently on the table.

This thought arose from

* the email I just sent about Antoine Zimmermann's semantics [1], and
* a discussion on github about ill-formed literals [2].

Currently, some RDF implementations used native datatypes to represent 
literals. For example, the literal "42"^^xsd:integer is /not/ 
represented internally by the pair of  strings ("42", 
"http://www.w3.org/2001/XMLSchema#integer"), but by a native int. This 
has a number of advantages (more compact to store, more efficient to 
compute with), but it also comes with limitations:
* ill-formed integers, such as "foo"^^xsd:integers, can not be 
represented (although they are /syntactically/ valid) ;_
_* syntactically distinct integers such as "42"^^xsd:integers and 
"042"^^xsd:integers become undistinguishable ;
* as a consequence, these implementation do not always round trip: 
graphs may come out slightly different from how they came in.

Is it wrong to implement RDF that way, then? Semantically, the three 
limitations above make perfect sense(!). If we consider that these 
implementations work at the D-entailment level rather than at the strict 
abstract syntax level, then they can be argued to be perfectly complying 
with the spec (that's basically my argument in [2]).


Now, let's consider the two options on the right ("triple-terms" and 
"edge-statements") of the synthetic table that I posted earlier [3], and 
if we extend their semantics using f az-RDF-reification semantics (see 
my summary in [1]). Then we could imagine an implementation of RDF 1.2 
which would, internally, represent

     << :e | :s :p :o >> :a :b.

NOT using triple-terms or edge-statements, but simply as

     :e rdf:nameOf [
         rdf:subject :s ;
         rdf:predicate :p ;
         rdf:object :o ;
         :a :b ;
     ].

(e.g. exactly as proposed in the sugar+ approach).

This is acceptable since the latter is entailed by the former (under 
az-RDF-reification semantics). Similarly to the implementations working 
at the D-entailement level (as illustrated above), these implementations 
could be considered to work at the az-RDF-reification-entailment level. 
They would not perfectly round-trip, but what they would produce would 
always be a consequence of what they were given (just like with the 
D-entailment case above).

Granted, the two cases differ in some aspects, but I find the parallel 
interesting: implementations that do not want to extend the abstract 
syntax could have a nice and compliant way out of it, just like 
implementations that do not want to support ill-formed integers.

   pa

[1] https://www.w3.org/mid/7133d1bc-3618-43e2-96cd-d815536ff1d6@w3.org

[2] https://github.com/w3c/rdf-concepts/issues/60

[3] 
https://htmlpreview.github.io/?https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.html