W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: ISSUE-19: Should TURTLE allow triples like "[ :p 123 ]." as SPARQL does ?

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
Message-ID: <1301838745.19994.10.camel@waldron>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:41 GMT