- From: David Booth <david@dbooth.org>
- Date: Thu, 16 May 2013 09:35:25 -0400
- To: Gavin Carothers <gavin@carothers.name>
- CC: RDF-WG WG <public-rdf-wg@w3.org>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>, David Robillard <d@drobilla.net>, Peter Ansell <ansell.peter@gmail.com>, Gregory Williams <greg@evilfunhouse.com>
I actually agree with Gavin on this. Although I want a single compatible syntax between Turtle and SPARQL, I think the fault lies with SPARQL syntax on this issue, and SPARQL syntax is the one that should be fixed to allow "@prefix" consistent with Turtle, rather than changing Turtle to align with SPARQL. This does mean that we (as a community) will have to wait until the next version of SPARQL for this to be fixed, but I think that's better than adding this wart to Turtle. Better to put this wart in SPARQL, :) and then eventually deprecate "PREFIX" in favor of "@prefix". David On 05/15/2013 10:48 PM, Gavin Carothers wrote: > > <https://gist.github.com/gcarothers/5589022#prefix-and-base-should-be-removed-from-turtle>PrEfIx > and BaSe should be removed from Turtle > > PREFIX and BASE were added as features at risk to Turtle before CR. > Designed to make it easier to copy and paste between Turtle and SPARQL > they have proven controversial. As they are a controversial addition to > a settled language they should be removed. > > > <https://gist.github.com/gcarothers/5589022#rationale>Rationale > > The FPWD for the Turtle document published by this working group > included the following: > > Turtle is already a reasonably settled serialization of RDF. Many > implementations of Turtle already exist, we are hoping for feedback > from those existing implementers and other people deciding that now > would be a good time to support Turtle. There are still a few rough > edges that need polishing, and better alignment with the SPARQL > triple patterns. The working group does not expect to make any large > changes to the existing syntax. > > The laudable goal of reducing copy and paste errors in both Turtle and > SPARQL is not strong enough to change a settled serialization. > > None of the arguments in support of the feature deal with what > serialization should be preferred. Introducing the feature also creates > issues with the existing @prefix and @base syntax and if they should or > should not require a trailing period. Again, there is no clear guidance > for serializers. This feature also introduces the first case insensitive > keyword in Turtle all other Turtle keywords are case sensitive. > > Lastly, the goal of full copy and paste between SPARQL and Turtle will > not be achieved only by adding this feature. A range of other issues > exist preventing this. > > > <https://gist.github.com/gcarothers/5589022#actions>Actions > > * Remove "Feature at Risk" box > * Remove grammar rules 5s, 6s > * Update grammar rule 3 to read |prefixID | base| > * Change grammar note 1 to "All keywords are case sensitive" > > The grammar at that point requires no magical understanding of case > rules as all rules express the case of their keywords. > > > <https://gist.github.com/gcarothers/5589022#ways-forward-for-those-that-like-copying-and-pasting-prefixbase>Ways > forward for those that like copying and pasting PREFIX/BASE > > I'd direct your attention to the conformance section of the Turtle > document. http://www.w3.org/TR/turtle/#conformance "This specification > does not define how Turtle parsers handle non-conforming input > documents." That note is not there by mistake. > > > <https://gist.github.com/gcarothers/5589022#selected-messages-and-threads-from-outside-of-wg>Selected > Messages and Threads (From outside of WG) > > Yes, I read all the threads again, just a few are included here. > > > <https://gist.github.com/gcarothers/5589022#supporting>Supporting > > David Booth david@dbooth.org <mailto:david@dbooth.org> > http://www.w3.org/mid/516EAFDF.50708@dbooth.org > > Copy and paste between Turtle and SPARQL is /very/ common, particularly > in debugging. Having to change the prefix syntax back and forth is a > significant and pointless waste of time. Please find a path to a single > compatible syntax. > > > <https://gist.github.com/gcarothers/5589022#in-opposition>In > opposition > > Gregory Williams greg@evilfunhouse.com <mailto:greg@evilfunhouse.com> > 2013-03-01: > http://www.w3.org/mid/C52BE515-076D-4D10-82D0-27FD757F2F48@EVILFUNHOUSE.COM > > I'd like to take this opportunity to provide feedback on the inclusion > of SPARQL BASE and PREFIX syntax in the new Turtle grammar. I think this > is a mistake, adding complexity for both users and implementors. I'm > sympathetic to the desire to align syntax for triples between Turtle and > SPARQL, but don't believe the alignment is necessary or recommended for > the top-level language syntax (as the need for backwards compatibility > with pre-REC Turtle means that alignment requires two different syntaxes > for the same declarations). > > David Robillard d@drobilla.net <mailto:d@drobilla.net> 2012-10-08: > http://lists.w3.org/Archives/Public/public-rdf-comments/2012Aug/0028.html > > For what it's worth, as a Turtle implementer I am opposed to this > change. It is ugly and inconsistent with the language, clearly an import > that does not belong. > > While it is unfortunate that SPARQL did not use the @directive > convention from N3, Turtle does not contain SELECT and such either. > While triple copying and pasting between the languages is desirable > (even if it has polluted Turtle with path grammar and horrific escaping > rules), the directives between the two languages are not compatible. > > I do not consider messing up the Turtle specification in this way > appropriate. If implementations want to support this as an extension, > they may. I won't. > > Peter Ansell ansell.peter@gmail.com <mailto:ansell.peter@gmail.com> > 2013-04-28 > http://www.w3.org/mid/CAGYFOCQKfygwogHQj_b7=nW1CrxM4aq5XUdgJg4nx4uaUSKZFw@mail.gmail.com > > I am sorry, but I completely disagree that changing a fundamental part > of an established syntax as part of its long-delayed "standardisation" > process can be rationalised by saying that hypothetical future users > will appreciate it and it doesn't matter what a community of current > users think. >
Received on Thursday, 16 May 2013 13:35:57 UTC