Re: Adaptation of the semantics

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.
>>
>>
>