- From: Olaf Hartig <olaf.hartig@liu.se>
- Date: Mon, 2 Sep 2019 15:57:00 +0000
- To: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
- CC: Richard Cyganiak <richard@cyganiak.de>
Hi Richard, On söndag 1 september 2019 kl. 13:33:36 CEST Richard Cyganiak wrote: > [...] > Let me state the problem with Turtle* a bit more explicitly. > > A Turtle file is (if we ignore base and prefix mappings) a set of blocks of > triples, where the triples in each block share the same subject. > > It is common practice to group all triples that share the same subject into > such a block. > > If Turtle*'s new features (nested triples) are used, this practice is no > longer possible. > > If a triple t is used as the subject of another triple, then t cannot be > grouped together with other triples that share the same subject. Instead, t > needs to be removed from the block, or repeated outside of the block. I got that, and I agree that the issue you are pointing out is indeed a downside of the current approach to define the Turtle* syntax. > If there was a way to change Turtle* so that it visually still looks like > nested triples, but at the same time retains Turtle's ability to group > triples with same subject into a single block (even if some of these > triples are annotated), then I would likely prefer that change over my > straw man proposal. But I cannot think of such a way. Me neither :-( > > 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? > > 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. > > 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? > > I could think of a number of ways of handling this situation. Before I > propose one, I'd like some clarification on the use cases for triples of > that shape. I'll start a new thread for that. Okay. Thanks, Olaf > Thanks, > Richard > > > 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 > >> > >> 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 Monday, 2 September 2019 15:57:29 UTC