W3C home > Mailing lists > Public > public-rdf-star@w3.org > November 2020

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

From: thomas lörtsch <tl@rat.io>
Date: Thu, 19 Nov 2020 23:04:31 +0100
Cc: public-rdf-star@w3.org
Message-Id: <051B9070-3D05-4150-B1EA-43F765022706@rat.io>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>


> 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



> peter
> 
> 
> On 11/19/20 10:12 AM, Pierre-Antoine Champin wrote:
>> On 19/11/2020 12:41, thomas lörtsch wrote:
>> 
>>>> On 18. Nov 2020, at 15:07, Pierre-Antoine Champin
>>>> <pierre-antoine.champin@ercim.eu> wrote:
>>>> 
>>>> On 17/11/2020 23:18, thomas lörtsch wrote:
>>>> 
>>>>> Just a quick check:
>>>>> 
>>>>>> On 17. Nov 2020, at 18:11, Pierre-Antoine Champin
>>>>>> <pierre-antoine.champin@ercim.eu> wrote:
>>>>> […]
>>>>> 
>>>>>>> +
>>>>>>> 
>>>>>>> Both "modes" used side by side would solve this problem:
>>>>>>> 
>>>>>>>     << :a :b :c >> :denies :d .
>>>>>>>     :a :b :c {| :exclaims :e |}
>>>>>>> 
>>>>>> No, because his concrete syntax would produce exactly the same abstract
>>>>>> syntax as your previous example -- at least in my understanding, but I
>>>>>> trust that Olaf would agree (see
>>>>>> https://github.com/w3c/rdf-star/issues/9#issuecomment-708608422).
>>>>>> 
>>>>>>  From the very beginning, embedded triples in RDF* are totally
>>>>>> identified by their subject+predicate+object, there is now way to
>>>>>> distinguish different mentions (tokens) of the same triple.
>>>>> You mean
>>>>>>>     :a :b :c {| :d :e |}
>>>>> is meant to annotate all triple tokens of type
>>>>>     :a :b :c .
>>>>> everywhere, anywhere?
>>>> As Peter pointed out in his reply, RDF* does not have any notion of
>>>> "triple token", only that of "triple type" (so to speak).
>>>> 
>>>> So the example above is not "meant to annotate all triple tokens", but
>>>> meant to annotate this one triple (type).
>>> This answer doesn’t help me as in my terminology "triple" and "triple
>>> (type)" refer to very different things.
>> Yes, that's why I put "type" in parenthesis.
>>>   Let’s try another terminology: types of triples versus occurrences of
>>> triples. A triple of type
>>>     :a :b :c .
>>> can occurr in different graphs. Graphs are defined as sets of triples and
>>> therefor any triple can occurr only once per graph.
>> 
>> Yes.
>> 
>>> Imagine the following RDF* graph, consisting of only one annotated statement:
>>> 
>>>     :a :b :c {| :d :e |}
>>> 
>>> Does the annotation ':d :e' annotate
>>> 1) that specific occurrence of ':a :b :c' in the same graph or
>>> 2) some occurrence of ':a :b :c' but it doesn’t define which or
>>> 3) any occurrence of ':a :b :c' in all graphs ?
>>> 
>>> I assume it’s option 2 but I’m not sure.
>> 
>> For me the answer is:
>> 
>> 4) it annotates the triple type itself
>> 
>> And annotating the type is not the same thing as annotating one or several
>> occurrences -- just like annotating a set is not the same as annotating one
>> or several of its elements...
>> 
>>> 
>>> Thomas
>>> 
>>> 
>>>>>> As I understand, this was a deliberate design choice.
>>>>> And with what rationale?
>>>> I can't talk for Olaf. My guess is that it was deemed simpler, and
>>>> sufficient for most use cases.
>>>> 
>>>> Maybe also it was considered as the less disruptive change to RDF.
>>>> Consider the following Turtle:
>>>> 
>>>>    :a :b :c, :x.
>>>>    :a :b :c, :y.
>>>> 
>>>> The two occurrences of ":a :b :c" in that concrete syntax are "squashed"
>>>> into the same triple in the abstract syntax. RDF itself does not
>>>> distinguish different tokens of the same triple. Why should RDF*?
>>>> 
>>>> Finally, if you want to track different "utterances" of the same triple,
>>>> nothing prevents you to write
>>>> 
>>>> :a :b :c {|
>>>>    :utterance [ :by :alice; :on "2020-11-10" ],
>>>>      [ :by :bob; :on "2020-11-13" ]
>>>> |}
>>>> 
>>>>> 
>>>>> Thomas
>>>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
> 
Received on Thursday, 19 November 2020 22:04:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 19 November 2020 22:04:54 UTC