- 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