Re: RDF*/SPARQL* syntax

Hi Olaf,

> On 2 Sep 2019, at 16:57, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
>>> 1/ What about RDF* triples that consist of multiple levels of nesting?
>>> For instance, consider the following RDF* triple:
>>> 
>>> ( ((:a, :b, :c), :d, :e), :f, :g ) .
>>> 
>>> Using the Turtle* syntax as it is defined at the moment, this triple
>>> would be serialized as follows:
>>> 
>>> << <<:a :b :c>> :d :e >> :f :g .
>>> 
>>> How would you represent this triple in the alternative serialization
>>> syntax that you have outlined?
>> 
>> In my straw man syntax, this triple would be written as:
>>    :a :b :c <<:d :e <<:f :g>> >>.
> 
> Mmh. While I understand how this would work, I think that expressions of this 
> form can be confusing as a serialization syntax for nested RDF* triples. I 
> mean, this expression also looks like something that is nested, but the way 
> this expression uses nesting is a very different one from the notion of 
> nesting of triples that we have in abstract syntax of the RDF* data model.

When you say this, you gloss over an important aspect of the RDF* data model: the fact that the notation "<<:a :b :c>> :d :e" in Turtle* expresses two triples, not one:

    ((:a :b :c) :d :e)
    (:a :b :c)

If the notation would only express the former triple, then there would indeed be a clean and direct correspondence between concrete and abstract syntax.

But the notation also expresses the latter triple, and that aspect of the abstract syntax is not hinted at in the concrete syntax at all.

In the alternative straw man syntax, one cannot write the expression for the composite triple without first writing the expression for its inner constituent triple:

    :a :b :c <<:d :e>>

This makes quite obvious that the ":a :b :c" triple is part of the graph too.

In that sense, the nesting in the alternative syntax captures the constraint of the RDF* data model better than the nesting of Turtle*.

Richard