Re: PrEfIx and BaSe should be removed from Turtle

I agree with Sandro's bottom line: "*I think it's burden on users to 
have to keep track of arbitrary and meaningless syntactic differences 
between closely related languages.*", and I think that should be the 
W3C's overriding concern.  It is an embarrassment and an annoyance to 
have this obvious design flaw between the two languages (Turtle and SPARQL).

I previously argued for fixing SPARQL in this regard, but it would be 
much more expedient to change Turtle, since it will probably be a few 
years before SPARQL could be changed.

Bottom line: Please align Turtle and SPARQL syntax one way or another.

David

On 05/22/2013 12:43 PM, Sandro Hawke wrote:
> 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.
>>
>

Received on Saturday, 25 May 2013 02:41:43 UTC