Re: RDF* vs RDF vs named graphs

On 02/12/2020 01:33, thomas lörtsch wrote:
>> Features that have been stable from the very beginning (e.g. "abstract" triples rather than triple occurrences)
> How do you support this claim?
from Olaf Hartig and Bryan Thompson: Foundations of an Alternative 
Approach to Reification in RDF. In CoRR abs/1406.3399, Jun. 2014 
(https://arxiv.org/pdf/1406.3399.pdf)

Definition 1:

   Assume pairwise disjoint sets I (all IRIs), B (blank nodes), and L 
(literals).
   Let T* be an (infinite) set of tuples that is defined recursively as 
follows:

     1.T* includes all RDF triples, i.e.,T* ⊇ (I ∪ B)× I ×(I ∪ B ∪ L); and
     2. if t ∈ T* and t' ∈ T*, then (t, p, o) ∈ T*, (s, p, t) ∈ T* and 
(t, p, t') ∈ T*
         for all s ∈ (I ∪ B), p ∈ I, and o ∈(I ∪ B ∪ L).
   Any tuple (s, p, o)∈ T* is an RDF* triple. A set of RDF* triples is 
called an RDF* graph.

According to this definition, there is no way to distinguish two triples 
with the same subject, predicate and object... They are one and the 
same. So they can not represent triple occurrences, they can only 
represent "abstract" triples.

That being said, I grant you that the example in that same paper, is 
poorly chosen:

:bob foaf:name "Bob" .
     <<:bob foaf:age 23>>
         dct:creator <http://example.com/crawlers#c1>;
dct:source <http://example.net/listing.html>.

This modelling is brittle, because it breaks as soon as you have two 
occurrences of the same triple. That's unfortunate.

 From this, you may conclude that the example rules, and that the 
definition is broken. Or, that the definition rules, and that the 
example is broken (or at least, brittle). Traditionally (in scientific 
litterature or standards), definitions win over examples...

Furthermore, it is not too hard to fix the example to match the 
definition (add an intermediate node to represent the occurrence). The 
opposite would be trickier -- and would break all existing implementations.

With that, I rest my case ;)

Received on Wednesday, 2 December 2020 21:03:04 UTC