Re: Why does RDF* allow triples as objects?


On tisdag 3 september 2019 kl. 14:06:31 CEST Richard Cyganiak wrote:
> > On 2 Sep 2019, at 17:37, Olaf Hartig <> wrote:
> > 
> > The reason why I defined RDF* in the way I did (i.e., allowing triples not
> > only in the subject position but also in the object position) was based
> > on several thoughts.
> > 
> > One of which was along the same lines of William's comment. Now, regarding
> > your response to this comment, I don't think that introducing the possible
> > asymmetry regarding the use of triples within RDF* triples can be
> > justified by the fact that RDF has the same kind of asymmetry for
> > literals.
> You appeal to a symmetry that is absent from RDF to justify a symmetry in
> RDF*.

I don't think so. I appeal to a symmetry that gives users of the RDF*-specific 
features the greatest possible flexibility, which is independent of whether 
symmetry of other aspects of RDF is present or absent from RDF.
> I appeal to parsimony. Make the minimal addition to RDF that addresses the
> use cases. If that minimal addition is asymmetric, so be it. RDF is
> asymmetric and it works.

I understand, and I am not against sacrificing some of the aforementioned 
flexibility if doing so brings a clear benefit. A more convenient format for 
writing SPARQL* queries would be such a benefit.

> > Another thought was that I wanted RDF* to be as close as possible to RDF
> > reification. In RDF reification, the triples that talk about a reified
> > triple may contain as their object the IRI or bnode used for the
> > reification of the reified triple. For instance, the following is an RDF
> > reification version of William's> 
> > example:
> > :bob :believes _:b1 .
> > 
> > _:b1  rdf:type  rdf:Statement .
> > _:b1  rdf:subject  :moon .
> > _:b1  rdf:predicate :consistsOf .
> > _:b1  rdf:object  :greenCheese .
> So you say you wanted RDF* to be close to RDF reification, and since RDF
> reification allows statements to appear in the object position, RDF* allows
> it too.

Yes, as close as possible.

> But RDF* falls well short of the goal to be close to RDF reification.

It depends on the notion of "close." Of course, they are not equivalent. 
However, only because they are not equivalent does not mean we cannot and 
should not aim to make RDF* as close as possible to RDF reification.

> It cannot express any of the following (except by using RDF reification
> directly):
> - annotations of triples that are not in the graph

You may have seen my idea of introducing two modes of using RDF*/SPARQL*: the 
"Property Graph mode" (PG mode, for short) and the "separate-assertions mode" 
(SA mode); see:

Now, the limitation you mention holds only for PG mode. When using RDF* in SA 
mode, it is possible to annotate a triple without implicitly asserting this 

> - multiple instances of the same triple with different annotations

Agreed, that's a limitation (although I am not sure how important such a 
feature is in practice--but this question is irrelevant for our discussion 

> - IRIs as statement identifiers

Correct, that's another difference (but I don't see a practical benefit of this 
> I'm not saying that addressing any of these items in RDF* is important or
> even desirable, but I don't understand why triples-as-objects *was*
> important enough to include in RDF*, while these other items were not
> important enough.

The fact that RDF* does not have these other features (the latter two, in 
particular) is an inherent consequence of the fundamental idea of RDF*; 
namely, the idea to use a triple itself when talking about this triple in 
other triples. Forbidding users to have triples as objects is an extra 
restriction that may or may not be added on top of this fundamental idea. My 
choice was not to add this restriction for the sake of greater flexibility and 
to be closer to RDF reification (even if equivalence cannot be achieved).

> I can think of clear use cases for some of these items
> that are difficult to address with RDF* as it stands, while I have trouble
> thinking of a use case that requires triples-as-objects.

There may be use cases that require describing a relationship between two 
triples, which can be captured naturally by an RDF* triple that has one of the 
triples as its subject and the other as object.

Considering RDF* triples that contain only one RDF* triple (either as subject 
or as object), I agree that there is no use case that would strictly require 
triples as object. However, there may be cases in which it seems more natural 
to the domain modeler to define the metadata predicates such that the 
referenced triples are in the object position; of course, this can be highly 
subjective. William's earlier example might be considered such a case.


Received on Tuesday, 3 September 2019 20:04:28 UTC