Re: basing RDF-star on RDF reification

Dear Peter,

I have been meaning to respond to this email for a while -- sorry for 
the long delay.

I don't see much difference between your proposal below and the one in 
the CG-report. More details below:

On 07/11/2022 15:59, Peter F. Patel-Schneider wrote:
> I think the working group should consider basing the definition of 
> RDF-star on RDF reification.  Although the semantics of RDF 
> reification are under-constrained they can be used to provide a 
> meaning for embedded triples.  This has several beneficial effects.  
> First, RDF reification becomes more useful. Second, RDF systems that 
> do not support RDF-star directly can act as if they do by creating RDF 
> graphs that are the mapping of RDF-star graphs.  Third, RDF-star 
> becomes a simple syntactical extension to RDF.  Fourth, only a little 
> machinery is needed to define RDF-star.  Fifth, variations of embedded 
> triples can be created and made to fit correctly with both RDF-star 
> embedded triples and RDF reification even without any extension to RDF.
>
>
>
> The basis of this definition of RDF-star is that embedded triples are 
> a shorthand for RDF reification, which some added triples to account 
> for their desired meaning.  These additions can be modified if a 
> different desired meaning of embedded triples is used in RDF-star.  
> Some of this definition is shared with various existing proposals for 
> defining RDF-star.
>
> Start with the abstract syntax of embedded triples and RDF-star graphs 
> as defined in RDF-star documents.
So, this proposal still relies on an RDF-star abstract syntax that 
extends the abstract syntax of RDF, right?
>
>
> Define a mapping L on RDF literals and IRIs as follows:
> For an RDF literal t with lexical form l, optional language tag t, and 
> datatype d, L(l) is the RDF literal with datatype xsd:string and 
> lexical form "l"^^<d> or "l"@t^^<d>, as appropriate.
> For an IRI i, L(i) is the RDF literal with datatype xsd:string and 
> lexical form i.
>
> This mapping only works correctly if RDF IRIs cannot be confused with 
> the mappings of RDF literals.  If this is not correct then use instead 
> the lexical form enclosed in angle brackets.
this is basically the mapping L defined at 
https://www.w3.org/2021/12/rdf-star.html#mapping

>
>
> Given a set of recognized datatypes, the mapping * from RDF-star 
> graphs to RDF
> graphs is defined as follows:
>
> Pick some embedded triple ( s, p, o ) such that none of s, p, and o 
> are triples, replace all occurrences of the triple by a fresh blank 
> node b, and add the triples
>
>   ( b, rdf:type, rdf:Statement )
>   ( b, rdf:subject, s )
>   ( b, rdf:stated-subject, L(s) ) if s is not a blank node
>   ( b, rdf:predicate, p )
>   ( b, rdf:stated-predicate, L(p) )
>   ( b, rdf:object, o ) if o is not a malformed literal
>   ( b, rdf:stated-object, L(o) )  if o is not a blank node
>
> Finish when there are no embedded triples left.

and this is very similar to the unstar mapping defined at 
https://www.w3.org/2021/12/rdf-star.html#mapping ,
with two main differences

- your proposal reuses the reification vocabulary, while the CG proposal 
defines a brand new vocabulary for this mapping. I don't think that this 
is a significant change -- although I get your point about making RDF 
reification more useful.

- your proposal does not "escape" the "reification vocabulary" in the 
original graph -- which the CG proposal does. Did you omit it on 
purpose? This could have strange cons

(aside remark: the "if o is not a malformed literal" was found to make 
the semantics non-monotonic, so we should probably not keep it: 
https://github.com/w3c/rdf-star/issues/262 )

>
>
> An RDF-star graph G1 entails an RDF-star graph G2 in RDF-star iff G1* 
> entails G2* in RDF.

this is also how it is defined in the CG report (modulo the differences 
between the mappings): 
https://www.w3.org/2021/12/rdf-star.html#entailment-of-rdf-star-graphs


   best

>
>
>
> Yours sincerely,
>
> Peter F. Patel-Schneider
>
>
>
>