Re: PrEfIx and BaSe should be removed from Turtle

On 5/24/13 10:41 PM, David Booth wrote:
> 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.

+1

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


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen