Re: [w3c/rdf-turtle] Grammar updates for triple terms and occurrences. (PR #51)

> Here is the essence of the approach that I was trying to illustrate using the examples in my last email [1]: An RDF graph in RDF1.1 is a set of <s,p,o> triples, but in RDF1.2 it is a set of <s,p,o,id> 4-tuples. Additionally, each such 4-tuple (present in an RDF graph) is either "asserted" or "reified" (and never both at the same time). So, the general form is: :id (rdf:asserts | rdf:reifies) <<( :s :p :o )>> . 

I don’t see how associating an identifier with each triple helps. The many-to-one use case has multiple reifiers/identifiers for a given triple, and of course, many triples exist within the graph without being explicitly reified, making the identifier superfluous.

> RDF1.1 is simple because it uses only a single kind of artifact – triples. IMO, RDF1.2 should retain that simplicity by using only a single kind of artifact – 4-tuples. Trying to have two kinds of artifacts – "type" triples and "occurrence" of "type" triples – takes away that simplicity. 
> 
> The use of a foo(s,p,o) function to generate the id for an (RDF1.1-style) triple is suggested only for backward compatibility (e.g., bringing RDF1.1 data into RDF1.2) and to avoid, whenever possible, burdening the data creators with the task of creating an id for such a 4-tuple. The id in every 4-tuple, whether explicitly created by user or generated as foo(s,p,o), can be used as subject or object in another 4-tuple if needed, as long as no direct (e.g., <id, id, p, o> ) or indirect (e.g., <id1, id2, p1, o1>, <id2, id1, p2, o2>) circularity is involved.

A foo(s,p,o) function to generate an identifier suffers from the very problem that RDF Dataset Canonicalization addresses, because blank nodes are not sufficiently stable to use to create a unique identifier. There may be two triples with the same subject and predicate but different blank node objects, which you can’t really distinguish from each other without examining the context of other triples using the same blank node.

Gregg

Received on Tuesday, 30 July 2024 22:43:44 UTC