- From: Sandro Hawke <sandro@w3.org>
- Date: Sun, 03 Apr 2011 09:52:25 -0400
- To: Alex Hall <alexhall@revelytix.com>
- Cc: Steve Harris <steve.harris@garlik.com>, Peter Frederick Patel-Schneider <pfps@research.bell-labs.com>, andy.seaborne@epimorphics.com, richard@cyganiak.de, public-rdf-wg@w3.org, sysbot+tracker@w3.org
On Sat, 2011-04-02 at 13:54 -0400, Alex Hall wrote:
> On Fri, Apr 1, 2011 at 8:39 PM, Steve Harris <steve.harris@garlik.com>
> wrote:
>
> On 2011-04-01, at 16:45, Alex Hall wrote:
>
> > On Fri, Apr 1, 2011 at 11:22 AM, Peter Frederick
> > Patel-Schneider <pfps@research.bell-labs.com> wrote:
> > From: Andy Seaborne <andy.seaborne@epimorphics.com>
> > Subject: Re: ISSUE-19: Should TURTLE allow triples
> > like "[ :p 123 ]." as SPARQL does ?
> >
> > Date: Fri, 1 Apr 2011 10:08:14 -0500
> >
> > > http://www.w3.org/TR/sparql11-query/#grammar
> > >
> > > [21] TriplesBlock ::=
> > > TriplesSameSubject ( '.' TriplesBlock? )?
> > > [32] TriplesSameSubject ::=
> > > VarOrTerm PropertyListNotEmpty | TriplesNode
> > PropertyList
> > > [34] PropertyList ::=
> > > PropertyListNotEmpty?
> > > [38] TriplesNode ::=
> > > Collection | BlankNodePropertyList
> > > [39] BlankNodePropertyList ::=
> > > '[' PropertyListNotEmpty ']'
> > >
> > > A lot of this is to exclude "[] ."
> > >
> > > http://www.sparql.org/query-validator.html ==>
> > >
> > > http://www.sparql.org/query-validator?query=PREFIX
> > +%3A+%3Chttp%3A%2F%2Fexample%2F%3E%0D%0A%0D%0ASELECT
> > +%3Fbook+%3Ftitle%0D%0AWHERE%0D%0A+++{+[+%3Ap+123
> > +]+}%0D%
> > 0A&languageSyntax=SPARQL&outputFormat=sparql&linenumbers=true
> > >
> > > Andy
> >
> >
> >
> > Ah, now I see it. Tricky.
> >
> > The extra complexity and lack of uniformity is a
> > strong point against
> > this syntax.
> >
> > peter
> >
> >
> > I see your point here. The name 'TriplesNode' implies a
> > production that generates a [node, triples] tuple, so the
> > triples always get added to the enclosing BGP and the node
> > can be added to a surrounding triple context if present.
> > That is extra complexity, and doesn't allow you to write
> > anything that you couldn't before.
> >
> >
> > But it does allow you to write statements about a blank node
> > without having to give that node a label, even if nothing
> > else in the graph refers to that node. A common example
> > from OWL:
> >
> >
> > [ a owl:AllDifferent; owl:distinctMembers (:a :b :c) ] .
>
>
> I do think that we should add this form, but not for this
> reason, what's wrong with
>
>
> [] a owl:AllDifferent; owl:distinctMembers (:a :b :c) .
>
>
> In this case?
>
> Fair enough, there's nothing wrong with this. For some reason the
> first example just looks more natural to me. Possibly because
> surrounding the statements in brackets gives a nice visual delimiter
> to the anonymous resource being described; possibly because I'm
> accustomed to seeing square brackets appearing in the object position
> of a triple and not the subject. Even though I know your example is
> valid syntax, it just didn't occur to me to write it that way. But
> that's a personal preference and I wouldn't push for its inclusion on
> those grounds alone.
To make your preference, which I share, slightly more objective:
Turtle square brackets allow one to write data in a subject-oriented
style instead of triple-oriented style. This is something we've been
talking about for JSON, a little. It's the only way native JSON or XML
allows data to be written, which I take a solid evidence it's a style
that is relatively natural and comfortable to people.
So, Turtle lets you write either way -- triple or subject oriented.
Except at the top level. That's what ISSUE-19 is about. I say "yes" to
ISSUE-19 because I think when you're working in a subject-oriented
style, you shouldn't have to step out of it just because you're at the
top level.
-- Sandro
Received on Sunday, 3 April 2011 13:52:54 UTC