Re: Adaptation of the semantics

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.

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.

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.


A slightly less basic question is whether SPARQL* results can return RDF 
triples that arise from embedded triples even if no RDF graph can entail an 
RDF* graph containing an embedded triple.  If the answer is no, then hidden 
triples are not allowed because the pattern ?s ?p ?o. returns all triples, 
unless there is special treatment of these predicates.  It might be reasonable 
to just make these hidden triples not be targets for matching by query 
variables.   (One problem with this is that it doesn't handle generalized RDF 
triples with blank nodes as predicates.)

peter


On 3/11/21 1:34 PM, Pierre-Antoine Champin wrote:
> On 11/03/2021 18:28, Peter F. Patel-Schneider wrote:
>
>> I don't see this as much of an advance.
>>
>>
>> The semantics now uses two graphs and also uses a hidden predicate.
>>
>>
>> As far as I can see, the reason to use a hidden predicate is to prevent 
>> RDF* graphs with embedded triples from beng equivalent to an RDF graph.  
>> I'm not in favour of this attribute of RDF*, as it prevents the 
>> construction of variations on embedded triples.
> Note that the new proposal does not use hidden predicate to describe the 
> internal structure of an embedded triple. So you can now builld something 
> that is very similar to (the "expanded description of) an embedded triple -- 
> how is it not a "variation on embedded triples"?
>
> What you can not do is to assemble a "proper" embedded triple by using those 
> predicates. In my view, this is a feature of RDF-star, not a bug. Similarly, 
> [ rdf:value "42"; rdf:type xsd:integer ] is quite similar to the literal 
> "42"^^xsd:integer, but it is not that literal. Requiring RDF systems to 
> recognized that literal whenever it is described like that would be a big 
> hurdle for implementers.
>
>> As far as I can see, the reason to use two graphs is to hide the triples 
>> generated by embedded triples from SPARQL.
>>
>> So there are two hiding operations.  Are two really needed?
>
> You are right, in a way they are two hiding operations. But they play 
> different roles.
>
> * using 2 graphs instead of one avoids embedded triples to entail their 
> "expanded" representation (i.e. the 7 triples generated in G2 for that 
> embedded triple) -- that way, SPARQL-star engines (but also RDF-star systems 
> supporting simple entailment) do not need to construct the "expanded" 
> representation for every embedded triple they contain.
>
> * using a hidden IRI avoids the "expanded" representation to entail the 
> embedded triple (more precisely, the complete expanded representation DOES 
> entail the embedded triple, but it can not be serialized) -- that way, 
> Turtle-star parsers are not required to analyze all "reification" triples to 
> re-construct "expanded".
>
> So to sum it up, the first hiding operation is for the sake of SPARQL-star, 
> the second one is for the sake of Turtle-star.
>
>   pa
>
>>
>>
>> peter
>>
>>
>>
>> On 3/5/21 1:00 PM, Pierre-Antoine Champin wrote:
>>>
>>> Hi all,
>>>
>>> I just pushed a pull-request adapting the semantics:
>>>
>>> https://github.com/w3c/rdf-star/pull/127
>>>
>>> I believe it has some advantages over the current version:
>>>
>>>   * it does not rely anymore on "hidden" predicates (see issue #101
>>>     <https://github.com/w3c/rdf-star/issues/101>)
>>>   * it does not have the "merging" issue warned about in ยง6.3.1
>>> <https://w3c.github.io/rdf-star/cg-spec/2021-02-18.html#combining-rdf-star-graphs> 
>>>
>>>   * I think that it allows us to align SPARQL query semantics with simple
>>>     entailment (as newly defined)
>>>   * I think that it allows the Interpolation Lemma
>>>     <https://www.w3.org/TR/rdf11-mt/#dfn-interpolation> to extend to RDF-star
>>>
>>> (I didn't formally prove the last two items, hence "I think"...)
>>>
>>> The trick is that we do not map anymore RDF-star graphs to a single, 
>>> semantically equivalent RDF graph.
>>> Instead, we map it to a pair of RDF graphs, which can be thought of as a 
>>> "lower and upper bound" of the RDF-star graph, in terms of entailment. The 
>>> semantics of the RDF-star graph is defined through the semantics of its 
>>> "bounds", reusing RDF semantics as is (as we currently do).
>>>
>>> In this new semantics, a strict RDF-star graph (i.e. one that contains 
>>> embedded triples) has no exactly equivalent RDF graph, so it still can not 
>>> be conveyed exactly using RDF syntaxes (but we do not rely anymore on 
>>> hidden predicates for that). However, either of the two "bounds" can be 
>>> used to approximate the RDF-star graph in legacy RDF. The "lower bound" 
>>> will produce correct but incomplete inferences. The "upper bound" will 
>>> produce complete inferences, with a few spurious (but generally harmless) 
>>> ones.
>>>
>>> I am curious to get some feedback on this.
>>>
>>>
>>
>

Received on Thursday, 11 March 2021 22:56:10 UTC