Re: basing RDF-star on RDF reification

There is a distinct difference in the ability to create variations of embedded 
triples in the two proposals.

In my proposal variations created using the standard RDF reification 
interoperate with embedded triples in the expected manner - one can infer a 
more-transparent version of reification from the embedded triple.  For example 
making literals transparent can be done by dropping the stated- triples for 
literals.  You do need to explicitly state the reification triples, of course.

This is not the case in the CG proposal because any explicit use of the unstar 
vocabulary in the RDF graph is modified before embedded triples are expanded.


peter


On 12/16/22 07:49, Pierre-Antoine Champin wrote:
>
>
> On 13/12/2022 16:45, Peter F. Patel-Schneider wrote:
>> As far as the Community Group proposal for RDF-star and SPARQL-star goes, 
>> there is no need to ever use the mapping unless you are determining 
>> RDF-star entailment.   Even then, the mapping just specifies what the 
>> results are so any method of getting to these results is fine.  SPARQL-star 
>> uses a different mechanism entirely so the mapping is not needed in SPARQL.
>>
>> As far as my proposal goes, when determining entailment all that counts is 
>> the final result so there is again no need to use the mapping for 
>> determining entailment.  Of course, it is possible to use the mapping, as 
>> in my proposal embedded triples are purely syntactic sugar.
> In other words, you advocate for Turtle-star and (the surface syntax of) 
> SPARQL-star, but leaving RDF and the semantics of SPARQL untouched. Right?
>>   This allows current software to correctly process embedded triples 
>> without any change to the software.
>
> Well, they still need a turtle-star parser. But granted, that's a minor 
> change compared to implementing a new abstract syntax and semantics.
>
> You state that "there is no need to use the mapping for determining 
> entailment". I have to comment on this, but will do so in a separate email 
> -- this one is already very long.
>
>>
>> In my proposal there is no need to extend SPARQL to handle embedded triples 
>> - all that is needed is to use the mapping to expand embedded triples and 
>> then use SPARQL as it currently exists.  (It could be useful to invert the 
>> mapping on the results of CONSTRUCT queries.)  Of course there is no need 
>> to implement embedded triples in SPARQL this way - any way that comes up 
>> with the same results is allowable - so in the end there is no need to use 
>> the mapping in my proposal either.
>>
>>
>> The Community Group proposal has a particular form of referential 
>> transparency/opacity - blank nodes are transparent and everything else is 
>> opaque (even "01"^^xsd:int is different from "1"^^xsd:int).  There is no 
>> way change this.
>
> There is no way to change this for quoted triples, but someone wishing for 
> full transparency could still use standard reification, as they would in 
> your proposal. About which...
>
>>
>> In my proposal embedded triples have the same referential 
>> transparency/opacity but other stances are possible by constructing the 
>> appropriate reification and associated triples.
>
> ... I don't understand this claim. If << a b c >> is syntactic sugar for
>
>   _: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 .
>
> then it is semantically opaque, and there is no way to change this either. 
> If you want a version without the rdf-stated-* predicates, you can't use the 
> << ... >> syntactic sugar anymore, you have to spell it out explicitly -- 
> just like you could in the CG's proposal.
>
> Or are you suggesting that << ... >> is interpreted differently in different 
> contexts ?
>
>
> On 15/12/2022 18:00, Peter F. Patel-Schneider wrote:
>> As far as I can tell, neither RDF standard reification nor RDF-star 
>> embedded triples are tied to either types or occurrences and taking about 
>> types vs occurrences is not helpful.
>>
>>
>> What you do get in RDF-star is a kind of uniqueness, namely that the basic 
>> idea in RDF-star is that there is only one embedded triple with the 
>> syntactically same subject, predicate, and object.   But this is not really 
>> supported in the RDF-star semantics,
> I have to disagree with you here, see below.
>> which is based on a mapping to regular RDF.  This mapping does not produce 
>> uniqueness or even identity of embedded triples.  A semantics that supports 
>> the uniqueness of embedded triples would have to extend the RDF semantics 
>> in a significant manner.
>
> Sure, since the RDF 1.1 semantics has no way to force uniqueness, you could 
> say that the mapping "does not produce uniqueness". Namely, the following 
> RDF 1.1 graph :
>
>   _:x unstar:subject :s, unstar:predicate :p, unstar:object :o, ....
>   _:y unstar:subject :s, unstar:predicate :p, unstar:object :o, ...
>
> of course, nothing in the RDF 1.1 semantics forces _:x and _:y to denote the 
> same thing.
>
> However, there is absolutely no way for the unstar mapping to produce such a 
> graph from any RDF-star graph as defined by the CG report. So I argue that 
> the RDF-star semantics /does /support the unicity of quoted triples. It does 
> so without extending the RDF 1.1 semantics, because it is based on that 
> semantics + the unstar mapping.
>
> Of course, this means that any implementation storing RDF-star graphs in the 
> unstared version would have to be careful to not produce invalid RDF-star 
> graphs when combining them. This is also explained the the CG report [2].
>
>   pa
>
> [1] https://www.w3.org/2021/12/rdf-star.html#rdf-star-semantics
> [2] https://www.w3.org/2021/12/rdf-star.html#combining-rdf-star-graphs
>
>