Re: RDF*/SPARQL* syntax

I share Richards concerns about the usability impact on idiomatic 
patterns of usage.

I don't think that his suggestion is exclusive though.
More complex case may not be able to be written in a compact fashion.

We already have a similar situation with blank nodes; if a blank node is 
a shared object, then the graph can't be serialized only using [].

    Andy

On 08/08/2019 12:50, Olaf Hartig wrote:
> Hi Richard,
> 
> That's an interesting issue that you raise!
> 
> Before I respond, let me emphasize that I am not religious about what
> the Turtle*/SPARQL* serialization syntax looks like as long as it serves
> the purpose.   ...and if it does not have the issue that you point out
> for the current serialization syntax, then great.
> 
> Now, I understand that the alternative you outline was meant to make
> your point. However, let's consider it as an alternative proposal.
> 
> Then, this proposal indeed seems to have some advantages over the
> serialization syntax as it is now. On the other hand, the current
> serialization syntax is visually less different from the abstract
> syntax. I mean, your proposed serialization syntax does not look like
> nested triples anymore. Perhaps that's not necessary?
> 
> Even if it is not, there are some features of (nested) RDF* triples that
> I cannot immediately picture how they may be captured in the alternative
> serialization syntax you outline:
> 
> 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?
> 
> 2/ What about (nested) RDF* triples that have a triple in their object
> position? For instance, consider the following RDF* triple:
> 
> ( :a, :b, (:c, :d, :e) ) .
> 
> Using Turtle* as defined at the moment, this triple would be serialized
> as follows:
> 
> :a :b <<:c :d :e>> .
> 
> How would you represent this triple in the alternative serialization
> syntax that you have outlined?
> 
> 
> Thanks,
> Olaf
> 
> 
> On Wed, 2019-08-07 at 16:55 +0100, Richard Cyganiak wrote:
>>
>>> On 5 Aug 2019, at 15:16, Olaf Hartig <olaf.hartig@liu.se> wrote:
>>>
>>> On Mon, 2019-07-08 at 11:09 +0100, Richard Cyganiak wrote:
>>>> [...]
>>>> 4. I have concerns about the RDF*/SPARQL* syntax that I'd like to
>>>> discuss at some point.
>>>
>>> What are these concerns?
>>>
>>> Are these concerns related to the abstract syntax (nested triples and
>>> nested triple patterns)
>>
>> No, the abstract syntax as proposed seems quite sensible and parsimonious to me.
>>
>>> or to the Turtle* serialization format?
>>
>> The concerns are related to the Turtle* and SPARQL* serialisation syntaxes. My concern for SPARQL* is bigger than for Turtle* as queries are more often written by hand.
>>
>> In these syntaxes, a triple :s :p :o annotated with property-value :annoP :annoV is:
>>
>>      <<:s :p :o>> :annoP :annoV.
>>
>> In Turtle, a common and important idiom is to use the common-subject abbreviation:
>>
>>      :resource1 a :SomeType;
>>          :p1 :o1;
>>          :p2 :o2;
>>          :p3 :o3;
>>          .
>>
>> Similarly in SPARQL:
>>
>>      ?resource a :SomeType;
>>          :p1 :o1;
>>          :p2 ?value2;
>>          :p3 ?value3
>>
>> The design of the Turtle*/SPARQL* syntax is such that it cannot coexist with this important idiom. To add an RDF*/SPARQL* annotation to either of the snippets above, one has to rip the snippet apart, undoing the common-subject abbreviation. For example:
>>
>>      ?resource a :SomeType;
>>          :p1 :o1.
>>      <<?resource :p2 ?value2>> :annoP ?annoV
>>      ?resource :p3 ?value3

Double statement of the triple is possible to get round this: 
(observation not advocacy!)

      :resource a :SomeType;
          :p1 :o1 ;
          :p2 :value2 ;
          :p3 :value3 .
      <<:resource :p2 :value2>> :annoP ?annoV.


>>
>> This involves a lot of unnecessary typing and syntactic repetition. The result suffers from poor readability and does not make the intent visually clear.
>>
>> There are various alternative syntaxes that would not share these shortcomings. As a straw man:
>>
>>      ?resource a :SomeType;
>>          :p1 :o1;
>>          :p2 ?value2 <<:annoP ?annoV>>;
>>          :p3 ?value3
>>
>> Sp what I would like to see is a different way of extending Turtle and SPARQL with nested triples and nested triple patterns that does play better with idiomatic Turtle and SPARQL.
>>
>> Richard
> 
>

Received on Friday, 9 August 2019 13:17:35 UTC