Re: PrEfIx and BaSe should be removed from Turtle

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