Re: owl:sameAs/referential opacity Re: Can RDFstar be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)

> On 20. Nov 2020, at 00:03, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 
> On 11/19/20 5:04 PM, thomas lörtsch wrote:
>> 
>>> On 19. Nov 2020, at 19:06, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>> 
>>> I think there is still a problem in this discussion with underdefined
>>> foundational terms, notably "triple type".
>>> 
>>> There are two documents that, in my opinion, provide foundations for RDF*. 
>>> There is the original technical report "Foundations of an Alternative Approach
>>> to Reification in RDF" and there is RDF* and SPARQL* at
>>> https://w3c.github.io/rdf-star/rdf-star-cg-spec.html.  The term "triple type"
>>> does not occur in the former and only occurs in the latter without definition.
>>> 
>>> Please can we only use technical terms that are defined in one of these
>>> documents or that have an accompanying definition that is based on terms in
>>> one of the above documents?
>> I understand that my sometimes quite naive inquieries must be frustrating to follow for people that are fluent in the terminology and understand properly what they are talking about. I’m trying to understand what RDF* is not on its own, with the terms the paper and the spec use, but in comparison to RDF reification. Pat in an earlier mail in this thread, cites the published semantics document (https://www.w3.org/TR/rdf11-mt/#reification):
>> 
>> "The subject of a reification is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object."
>> 
>> I understand that what I called in a misguided stylistic attempt an "actual assertion" and then a "triple occurrence"  and sometimes a "triple token" is what the RDF spec calls "a concrete realization of an RDF triple". OTOH I understand the term "triple type" as referring to the same concept that the RDF spec calls "a triple considered as an abstract object".  Is that good enough as a shared vocabulary or is it not clear if terms from the RDF spec are appropriate to describe concepts of RDF*?
>> 
>> I take it from Pierre-Antoines last answer (thanks for your patience, pa!) that the subject of an RDF* annotation is  what the RDF spec calls "a triple considered as an abstract object". That is a description that I can wrap my head around and work with. I hope it’s right.
>> 
>> Thomas
> 
> 
> If there is already terminology in the RDF documents that fits, then why not
> use that.
> 
> For example, triple is a core term of RDF, consisting of three components in
> the abstract syntax document.  If you mean triple, just say "triple".  If you
> want to call out that the triple is in some RDF graph, just say that.  If you
> want to refer to a triple in some system that manipulates RDF triples, then
> just say that this is what you mean.
> 
> If you mean an occurrence of a triple in some document, then say that. 
> 
> 
> So if you wanted to say something about RDF reification you would say that the
> RDF triples:
> 
> <X rdf:type rdf:Statement > <X rdf:subject ex:a >  < X rdf:predicate ex:b> <X
> rdf:object ex:c>
> 
> where X is either a blank node or an IRI, is the X reification of the RDF triple
> 
> <ex:a ex:b ex:c>
> 
> Note that I'm using curies as standins for IRIs which is strictly speaking not
> kosher but can easily be fixed up.
> 
> 
> You could then define an extended Turtle syntax that permitted (extended)
> triples as subjects or objects of (a.k.a., embedded in) other (extended)
> triples and define a mapping from this extended syntax to RDF graphs that
> replaced each occurrence of an extended triple embedded in another extended
> triple by a fresh blank node B and added the B reification of the triple to
> the resultant graph and worked as in regular RDF otherwise.  (Note that the
> replacement has to be done from the inside out so as not to create new
> occurrences of embedded triples.)  This results in something similar to RDF*,
> which could perhaps be called RDF-fresh.
> 
> Changing how the replacement is done gives different behaviour.  Two
> interesting variations are to have an injective mapping from triples to either
> blank nodes or IRIs and use the results of this mapping instead of the fresh
> blank node above.  (You want the blank nodes to not occur elsewhere in the
> graph and you almost certainly want the IRIs to not occur elsewhere in the
> graph.)  I believe that the first variant here is the original RDF*.  The
> second variant is mostly referentially opaque.  An even more opaque variant
> can be obtained by using a fresh IRI for each occurrence.

This sounds intriguing for several reasons but I still don’t understand how it works. You gave an example for simple entailment a few weeks ago on this thread [0]. That seemed clear to me first but then I seem to miss a step.
 
If I got it right, under simple entailment the graph < :a :b :c > entails the graph < _:x :b :c > because from the existance of ':a' we can entail the existance of "something". 
And if I got it right again, in this discussion referential transparence means that the resource is referencable in the interpretation domain and therefor available to entailments whereas under referential opaqueness it doesn’t get interpreted and is not visible in the domain.

But how does all this translate to the Superman scenario?
Given that

 ex:ClarkKent owl:sameAs ex:Superman

why is it that the graph

 _:b rdf:subject ex:ClarkKent 

entails

 _:b rdf:subject ex:Superman
 
whereas

 ex:X rdf:subject ex:ClarkKent 

doesn’t entail

 ex:X rdf:subject ex:Superman

???


Properly parapharsing your example from [0] would give that

 ex:X rdf:subject ex:ClarkKent 

doesn’t entail

 ex:Y rdf:subject ex:Superman // Y instead of X

- which I understand - but is that the question here? 
Isn’t the entailment that 

 ex:X rdf:subject ex:Superman    // X again

the entailment that the RDF* semantics proposal tries to suppress?


Thomas


> This gives something to talk about that doesn't underdefined terms like triple
> token and triple type but nonetheless distinguishes between a triple and an
> occurrence of a triple in a document.
> 
> peter

[0] https://lists.w3.org/Archives/Public/public-rdf-star/2020Oct/0085.html

Received on Saturday, 21 November 2020 12:56:09 UTC