Re: Summary: Annotation Syntax Proposals

A) looks indeed nice and I tried it in EYE (but no commit) and everything
in N3 still works fine and A) gives

$ echo -e "PREFIX : <http://example.org/test#>\n:s :p :o  *{ :y :z } ." |
eye --nope --quiet - --pass 2> /dev/null
PREFIX : <http://example.org/test#>

:s :p :o.
<<:s :p :o>> :y :z.

Jos

-- https://josd.github.io/ <http://josd.github.io/>


On Tue, Jan 19, 2021 at 9:57 PM thomas lörtsch <tl@rat.io> wrote:

> Thanks, Andy!
>
> I wonder if the following are possible:
>
> A)   :s :p :o  *{ :y :z } .
> B)   :s :p :o  *{ :y :z }* .
> C)   :s :p :o  {* :y :z *} .
>
> Richard passingly proposed A a few weeks ago, together with the IMO rather
> convincing argument that it’s called RDF* after all.
>
> Personally I like A.
>
> Given the very peculiar semantics of RDF* I’d strongly prefer if it didn’t
> use "@" but left that character for a semantics that treated attributed
> triples as belonging to the interpretation, not the syntax.
>
> I tend to have difficulties reading {| … |} when the font size is small
> and generally I’m glad about every character I don’t have to type (or read).
>
> Thomas
>
>
>
> > On 19. Jan 2021, at 19:10, Andy Seaborne <andy@apache.org> wrote:
> >
> > This is the action for issue 84.
> >
> > Annotation syntax is additional syntax, for Turtle-star, to make it more
> convenient to write a triple and also add triples about that triple. It
> generates multiple triples.
> >
> > A convenient way to write both:
> >
> > :s :p :o .
> > << :s :p :o >> :q .z .
> >
> > It does not allow Turtle to say something that could not be said with
> the fundamental <<>> syntax.
> >
> > The proposals are of the form:
> >
> > :s :p :o annotationBlock? .
> >
> > where the annotation block is some syntax and a predicateObjectList
> (Turtle grammar rule [7]) with <<>> as the subject.
> >
> >
> > == Proposals
> >
> > There have been several proposals, as well as more possibilities noted
> without advocacy.
> >
> >
> > They fall into 2 categories: both have start-end delimiters and allow
> nesting, with different delimiters for start and for end.
> >
> >
> > Type 1: Use { } with a introduction character.
> >
> > Simple { } would work in Turtle because {} aren't used anywhere else but
> using the same syntax for SPARQL and N3 would be visually unclear.
> >
> > So type 1 syntax uses an introduction character which as "@" - others
> have been suggested.
> >
> > Example:
> >
> > :subject :predicate :object @{ :source :URL } .
> >
> > :subject :predicate :object @{ :source :URL ;
> >                               :author "Alice"
> >                             } .
> >
> >
> > :subject :predicate :object @{ :source :URL ;
> >                               :author "Alice" @{ :saidBy "Bob" }
> >                             } .
> >
> > "@{" is a new token in the grammar (no white space between the two
> characters.
> >
> >
> > Type 2: Use distinctive enclosing delimiting pair, each is a new token.
> >
> > One suggestion that works is "{|" ...  "|}"
> >
> > "|" is one of several possible choices to go with "{", "}"
> >
> >
> > :subject :predicate :object {| :source :URL |} .
> >
> > :subject :predicate :object {| :source :URL ;
> >                               :author "Alice"
> >                            |} .
> >
> >
> > :subject :predicate :object {| :source :URL ;
> >                               :author "Alice" {| :saidBy "Bob" |}
> >                            |} .
> >
> >
> > == Requirements and notes
> >
> > There are some requirements and constraints on the syntax design. Some
> are technically necessary and some are desirable. Visual appearance is also
> a factor.
> >
> >
> > + SPARQL basic graph pattern matching uses a similar syntax to Turtle -
> it is "turtle with variables". Annotation syntax should fit naturally to
> being added to SPARQL so that it looks like Turtle.
> >
> > SPARQL uses many extras characters not used for syntax in Turtle. These
> can be double up for annotation syntax (it appears to be technically
> possible) but it leaves the question of whether it is visually clear.
> >
> > + 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.
> >
> > + Other Turtle syntax
> >
> > Turtle allows predicateObjectLists and objectLists.
> >
> > A consequence of the annotationBlock is:
> >
> > :s :p1 :o1 annotationBlock1? ;
> >   :p2 :o2 annotationBlock2? .
> >
> > :s :p :o1 annotationBlock1? , :o2 annotationBlock2? .
> >
> > + RDF Collections (Turtle lists)
> >
> > There has been no proposal for annotation of elements combined with list
> convenience syntax.
> >
> > + Alignment to other languages
> >
> > TriG and N3 are languages that share syntax features with Turtle.
> >
> > Fitting into TriG is quite natural.
> >
> > Of note in N3 is that "{ ... }" is already a language feature - a
> "formula".  It contains a number of N3-triples. It can go in the subject,
> predicate or object position.
> >
> > N3 CG work: https://w3c.github.io/N3/spec/
> >
> > Formula rule in the grammar:
> > https://w3c.github.io/N3/spec/#grammar-production-formula
> >
> > + Non-requirement
> >
> > Annotation syntax is for Turtle-star, not N-Triples/N-Quads, in a
> similar way that the syntax "[ :p 123 ]" is not part of N-triples.
> >
> >
> >
> >
>
>
>