Re: Summary: Annotation Syntax Proposals

On 20/01/2021 08:34, Miel Vander Sande wrote:
> - I would stay away from { } because of the connotation with graphs in 
> N3 and Trig and some of the constructs in SPARQL. All of them have 
> complete triple statements that include a subject. IMO the use of * or | 
> doesn't really make that super clear.
> 
> Trig          :a { :x :y :z } but I can't write :a { :y :z }
> N3            :a :b { :x :y :z } but I can't write :a :b { :y :z }
> SPARQL  WHERE { :x :y :z } but I can't write WHERE { :y :z }
> RDF* .     :a :b :c *{ :y :z } but I can't write :a :b :c *{ :x :y :z }
> 
> If you want to stick to something like that, *[ ] would be more uniform 
> (but that would probably cause issues with blanknode parsing )

Yes - [ ] based ones are harder because of predicateObjectLists and ANON.

"[" does have the right aspect of "same subject". If there a combination 
that involves "[" to help here?

[|...|]

"|" is fairly unencumbered. I'm not sure why it isn't in PN_LOCAL_ESC.


* is trailing character in prefix names (as "\*") and SPARQL property paths

In Turtle, while unusual, this is legal:

   :s :abc\* :o .

   :s :abc\*[] .

and *[ already occurs in SPARQL.

     :s :p*[] .

so while not impossible (its tokenzing so left-to-right, longest wins; 
in the SPARQL case it results in the current parsing) it's cluttered.

(though noting the idea that the CG is working on "RDF star" and RDF* is 
the original input).

The extra character in the close may be unnecessary though nested 
[]-structures exist so visually a different end might be desirable.


A visual issue with [ ] based syntax is that [] and [ ... ] are already 
in use for grouping. The original suggestion was [[ .. ]] but, in 
current Turtle, adjacent "]]" is possible as two separate tokens so this 
specific choice could impact existing data.

<s> :weather [ :temperature [ :value 25 ; :units :Celsius ]] .

In N3, [] can be property so "[[" (predicateObjectList, bnode property) 
is possible.

Having a safe, impossible-at-the-moment token for the start avoids any 
possible impact on existing data if the end is not a clash.

Keywords are a bigger space of impossible-at-the-moment tokens but 
Turtle data isn't in that style.

> - Another (minor) concern I have about annotations in a fourth position 
> is that it breaks the pattern introduced by all other syntaxes (with the 
> exception Trig).

This is addition convenience syntax to do two things: assert the triple 
and triple(s) about that triple.

Other convenience syntax:

:s :p [ :a :b ; :c :d ] .

or

:s :p ( :a :b :c :d ) .

> They all note things down in three (= triples) or four 
> (= quads) parts, shorthand syntax included.
> 
> << :subject :predicate :object >>  :source :URL  . -> 3 parts
> {| :subject :predicate :object |}  :source :URL  . -> 3 parts
> 
> :subject :predicate :object {| :source :URL |} . -> 4 parts
> :subject :predicate :object @{ :source :URL } .-> 4parts
> 
> N-Triples/N-Quads are indeed something else, but let's not ignore the 
> patterns they have already introduced.  Also, Turtle is superset of 
> N-Triples,

And that remains true.

Annotation syntax is not replacing <<>>. It is "as well as". It's in the 
test suite - the NT-star tests are duplicated as Turtle-star tests.

     Andy

> Trig & N3 are supersets of Turtle and N-Quads is a superset 
> of N-Triples - shouldn't we guarentee that future RDF* extensions of 
> these syntaxes remain feasible (eg. getting into shorthand hell) and 
> without diverging too much from these superset relations. Something that 
> has four parts reads like a quad to me. But this is just personal 
> preference.
> 
> 
> 
> Op wo 20 jan. 2021 om 00:51 schreef Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>>:
> 
> 
>     On 2021-01-20 4:10 am, Andy Seaborne wrote:
>      > + Is nesting allowed in the annotationBlock? that is, be able to add
>      > annotations to the extra triples inside the annotation block?
>      > (Technical consequence: if not, then the Turtle grammar has to have
>      > more changes to exclude this possibility by having versions of some
>      > grammar rules with and without the annotation syntax, and also in
>     the
>      > grammar rules a production uses. Annotation is part of
>      > predicateObjectList.
>      >
>      > Nesting requires a delimiter style - mark the start and end of the
>      > annotation block.
> 
>     Has the RDF* group agreed that nesting should be supported in
>     general? I
>     would consider this feature rather unnecessary. Allowing multiple
>     levels
>     of annotations (i.e. reification of reified triples) puts extra burden
>     on developers who then need to create UIs and other algorithms around
>     those cases. And how many of the users are going to understand these
>     constructs?
> 
>     Holger
> 
> 
>

Received on Wednesday, 20 January 2021 13:06:33 UTC