Re: Why does RDF* allow triples as objects?

Richard,

On Wed, 2019-09-04 at 19:57 +0100, Richard Cyganiak wrote:
> Olaf,
> 
> My original question was: Why does RDF* allow triples as objects,
> given that its main use cases of property annotation and PG
> interoperability don't require it?
> 
> Let me try to restate the answer you have given me, as I now
> understand it: The starting point for RDF*/Turtle*/SPARQL* was not
> any particular use case, but rather an idea about the abstract
> syntax: using triples as a sort of literal to express triples about
> triples. This idea yields a simple yet expressive abstract syntax
> that turns out to be able to address, at least in part, a number of
> interesting use cases, including property annotation and PG
> interoperability. It also provides a more pleasing account of RDF
> reification. Triples as objects are natural in this abstract syntax,
> and maximise the overlap with RDF reification, thus making RDF* more
> interesting.

Yes, that sums it up quite nicely.

> My reaction to this: RDF* has the problem that it *almost* addresses
> a number of interesting use cases, but it addresses none of them
> completely.

Do you have any specific use cases in mind that RDF* is supposed to
address but doesn't do so completely?

> Since it tries to cater to multiple different use cases, it gets
> pulled into different directions. The devil is in the details, and it
> will not be possible for RDF* to be everything to everyone.
> Eventually some hard decisions will need to be made.

Probably yes.

Thanks,
Olaf


> Users, implementers and researchers are likely to have different
> priorities.
> 
> Richard
> 
> 
> 
> 
> > On 3 Sep 2019, at 21:03, Olaf Hartig <olaf.hartig@liu.se> wrote:
> > 
> > Richard,
> > 
> > On tisdag 3 september 2019 kl. 14:06:31 CEST Richard Cyganiak
> > wrote:
> > > > On 2 Sep 2019, at 17:37, Olaf Hartig <olaf.hartig@liu.se>
> > > > 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:
> > 
https://lists.w3.org/Archives/Public/public-rdf-star/2019Aug/0001.html

> > 
> > 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 
> > triple.
> > 
> > > - 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 
> > here).
> > 
> > > - IRIs as statement identifiers
> > 
> > Correct, that's another difference (but I don't see a practical
> > benefit of this 
> > feature).
> > 
> > > 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.
> > 
> > Best,
> > Olaf
> 
>

Received on Thursday, 19 September 2019 11:22:23 UTC