Re: Why does RDF* allow triples as objects?

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.

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

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