Re: basing RDF-star on RDF reification

There are two differences, and they make a difference.

First, and much less important, is the use of the RDF reification vocabulary, 
which reduces the number of new IRIs needed and connects embedded triples to 
standard RDF reification.

Second, and much more important, is that there is no escaping.   This means 
that embedded triples are strictly syntactic sugar, i.e., there is no semantic 
difference between:

<<a b c>> e f .

<<a b c>> g h .

and

_:x1 rdf:subject a .

_:x1 rdf:stated-subject "a"^^xsd:string .

_:x1 rdf:predicate b .

_:x1 rdf:stated-predicate "b"^^xsd:string .

_:x1 rdf:object c .

_:x1 rdf:stated-object "c"^^xsd:string .

_:x1 e f .

_:x1 g h .

This makes it possible to infer embedded triples without using the embedded 
triple syntax and also makes it possible have variations of opacity, e.g., 
creating entities that are just like embedded triples but whose predicates are 
transparent by not incorporating the rdf:stated-predicate triple.


peter



for a, b, c, e, and f IRIs.

On 12/9/22 03:01, Pierre-Antoine Champin wrote:
> 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
>>
>>
>>
>>

Received on Saturday, 10 December 2022 19:02:29 UTC