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

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


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
>>> <> 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
>>>>> <> 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
>>>>>  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 18:07:09 UTC