Re: the "semantic sugar" approach

Oops. There was a mistake:

On 30/01/2024 22:49, Pierre-Antoine Champin wrote:
>
> 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 ;
>     ].
>
should have been

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

Thanks to Thomas Lörtsch for catching this.

> (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

>