Re: Adaptation of the semantics

On 21/03/2021 11:20, Peter F. Patel-Schneider wrote:
>
> On 3/19/21 12:35 PM, Pierre-Antoine Champin wrote:
>> (I realise that I originally only included Peter in my reply;
>>  reposting my reply here for archiving; sorry Peter for the duplicate)
>>
>> Dear Peter,
>>
>> On 11/03/2021 23:55, Peter F. Patel-Schneider wrote:
>> > Turtle* processing can be simple in just about any scheme if the 
>> output is an RDF* graph. There is no need for a Turtle* system to 
>> canonicalize RDF* graphs on input, nor is there are need for Turtle* 
>> systems to canonicalize on output.
>> >
>> > If it is possible to encode an embedded predicate in Turtle* then 
>> it is possible to have two structurally different Turtle* documents 
>> for the same RDF* graph.  But this is already possible in RDF - 
>> consider all the shorthands, particularly for containers and 
>> collections.
>> I should have been more careful with the wording. My point was indeed 
>> not about *parsing* Turtle*, but more about *storing* the result of 
>> this parsing in an RDF-star-aware system.
>> >
>> > It is true that a complete triple* store becomes somewhat more 
>> complex in this case, but only if the system wants to store all 
>> embedded triples directly.  Storing embedded triples directly is 
>> likely to help in SPARQL* performance, but any complete triple* store 
>> (let alone a performative one) is already quite complex so a bit more 
>> complexity isn't going to be noticeable.
>>
>> I am not so sure about that. From what I understand, most (if not 
>> all) implementers of RDF* chose to represent embedded triples 
>> directly. I'm guessing there is a reason.
>>
>> >
>> > So I don't see that the claim of making Turtle* processing easier 
>> is correct.
>> >
>> > In my mind important properties are what results are returned, not 
>> the form of these results.  Here is where hidden predicates have a 
>> role.   A basic question, I think, is whether it is possible for an 
>> RDF graph to entail an RDF* graph containing an embedded triple.
>>
>> In the current semantics: yes, since the mapping defines an 
>> *equivalent* RDF graph for any RDF* graph.
>>
>> In the new proposal: yes, since G1 U G2 entails G (where (G1, G2) = 
>> unstar(G)). However, no RDF graph can be *equivalent* to G (if G 
>> contains embedded triples).
>
> I should have been more precise - A basic question, I think, is 
> whether it is possible for an *accessible* RDF graph (i.e., one that 
> users can create) to entail an RDF* graph containing an embedded 
> triple. Using hidden IRIs makes this not possible.

Indeed. And I still consider this as a feature rather than a bug.

Note that you argued previously that it was not difficult for native 
implementations to reconstruct embedded triples from their "expanded" 
description. I agree that the overhead *during parsing* is acceptable. 
But the problem is that implementations need to do this *continuously*, 
monitoring any change to the graph. If you add triples one by one (e.g. 
_:b rdf:subject :s, then _:b rdf:predicate :p, then _:b rdf:object :o), 
at some point, boom, an embedded triple must be generated. Unless of 
course an embedded triple with the same subject, predicate and object 
already existed, in which case they need to be merged... And what 
happens when one of these triples is removed? This, I expect, is not 
trivial to develop, and a nightmare to maintain.

>> >
>> > A slightly less basic question is whether SPARQL* results can 
>> return RDF triples that arise from embedded triples
>>
>> But why should any RDF triple necessarily arise from embedded 
>> triples?? According to the abstract syntax, they are terms, just 
>> like, e.g., datatyped literals. Their internal structure should not 
>> have to "leak" into the graph (in simple entailment, at least).
> But why not?  There is no need for embedded triples to be a new thing 
> in the semantics.

Well, if embedded triples are a new thing the abstract syntax, there 
need to be some addition to the semantics as well, don't you agree? 
(even if that addition is done as currently, through some kind of mapping)

Of course, the next question you may ask is "is there a need for 
embedded triples to be a new thing in the abstract syntax?"...

My belief is that the extended abstract syntax is what makes RDF-star 
valuable, because this additional abstraction makes it possible for 
implementers to handle embedded triples in a more efficient way than 
"unfolded" reifications. It is more than just a convenient way (<< .. 
 >>) to represent reification in Turtle and SPARQL.

   pa