Re: PrEfIx and BaSe should be removed from Turtle

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.
>

I don't agree.     Removing them would do a disservice to the future 
users of Turtle.

To be clear: it's a "coin-toss" non-technical decision whether to 
require the @-sign.   It doesn't have a significant impact on 
implementation difficulty; has no impact on expressive power, etc. It's 
just a question of style and tradition.

As a question of style, I think the @ is ugly and annoying.    "@" means 
a lot of different things, usually somewhat related to the notion of 
"at".    sandro "at" w3.org.    comment reply directed "at" sandro.    
In Turtle it already has another meaning, for language tags: "chat" "at" 
fr.  Okay, that's not a good fit for "at" -- but it's still another 
meaning for "@".    How are people supposed to read "@prefix"?   Like 
it's a  chat message directed at the prefix processor?

Historically, the @ was there because Tim didn't want to claim the 
barewords in the language for keywords.   He wanted to allow for 
prefix-less terms, I believe.    But the "a" keyword already violates 
that, and Turtle isn't going to allow prefix-less terms. (I pushed for 
that at one point and the WG had zero interest.)   So that reason has no 
weight -- there's no longer a technical reason to have @.

Now we come to tradition.  Here we have dueling traditions of N3/Turtle 
with the @-sign and SPARQL (and kind of every other language) without 
the @-sign.   On the one hand, we have lots of people using N3 and 
Turtle.  On the other hand, we have lots of people using SPARQL.   
SPARQL is a W3C Recommendation while N3 and Turtle are not.   SPARQL is 
perhaps used more internally, while N3 and Turtle are published in the open.

Some people say, "but they are different" -- SPARQL is a database 
interface language, Turtle is a data format, so they can and should be 
arbitrarily different -- but I don't find this compelling at all.  I 
think it makes perfect sense to say Turtle and SPARQL (and TriG) are 
composed of the same pieces, put together in the obvious ways for the 
obvious purposes.  To say that two of the pieces (the directives with 
and without @-sign) serve the exact same purpose but are not 
interchangeable seems to me to be an obvious design flaw.

We can't just remove the @-sign, because there's lots of Turtle using it 
already, but I see no reason not to allow a slow migration to begin.

Bottom line:*I think it's burden on users to have to keep track of 
arbitrary and meaningless syntactic differences between closely related 
languages.*   There's a burden to changing, but I believe Turtle will 
have far more users in the future than it has today.

As I said on the call, this is not a do-or-die thing, of course.   I 
don't think we need to spend a lot of time arguing about it.   Folks did 
ask me to state my reasons, though, so I've done that.   If we require 
@-signs in Turtle, I believe it will be a mistake.    (Not the first, 
not the last, ...  :-)

(Closely related, I think TriG (beyond the directives) needs to be a 
subset of the SPARQL quad pattern syntax, allowing the GRAPH keyword and 
not requiring braces around the default graph.  I mention it here 
because the arguments are very similar.)

      -- Sandro

>
>     <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.
>