Re: Why does RDF* allow triples as objects?

> On 3. Sep 2019, at 22: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.

RDF is symmectric with respect to IRIs and asymmetric with respect to literals. In my intuition RDF* (nested) statements are a lot more similar to IRIs than they are to literals (especially, but not only in PG mode). Therefor I lean to symmmetry with respect to the principle of least surprise.

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

Parsimony is a two edged sword: having more rules to follow and more constraints to consider is not very parsimonious. If those rules and constraints are not well justified they may rather lead to an even deeper feeling that RDF is arcane and incomprehensible.

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

I don’t think that following RDF standard reification is a useful goal. RDF standard reification is far from elegant. It covers the edge case of modelling triples with triples and there hardly can be an elegant solution for that. One of the useful aspects of RDF* is precisely that it provides a more intuitive syntactic alternative to RDF standard reification. Being able to map RDF* style reification it to RDF standard reification semantically is important but on the syntax level  it’s not a worthwile goal IMO but rather leading into the wrong direction.

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

All these aspects IMO of reification are important but if they will be resolved does not depend on the question of symmetry in RDF* nodes. Also I tend to belief that questions of naturalness and intuitiveness in modelling are more important and carry more weight than any of these reification related issues.

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

One simple example would be two historic events, described in some detail in RDF* nested statements, one leading to the other:

   A* ex:ledTo B*

Please forgive me the laziness of not working out A* and B* but I think you get the idea. To me this is enough reason to enable symmetry.

In another mail Richard mentioned concerns about interface construction. I would need more than just that remark to consider GUI construction etc. I do find intuitiveness and readability in Turtle an important criterion but I don’t see a problem there (at least so far, without a larger example at hand).

Lastly it usually doesn’t pay to prolongue earlier mistakes like that allowing literals only in object position. If there is no profound disadvantage to symmetry - and so far I don’t see that - I clearly am in favor of it.


Best,
Thomas




> Best,
> Olaf

Received on Wednesday, 4 September 2019 13:34:25 UTC