Re: PrEfIx and BaSe should be removed from Turtle

On 5/26/13 10:06 AM, Sandro Hawke wrote:
> On 05/25/2013 03:19 PM, Kingsley Idehen wrote:
>> 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
>
> Obviously I concur.      Anybody want to take a strawpoll of SPARQL 
> folks and see how they feel about adding @prefix to SPARQL?  I imagine 
> several would be appalled by the idea, but I could be wrong.

They shouldn't be irked if the change is going to be on the Turtle side, 
driven by the goal of SPARQL alignment.

>
> If we add PREFIX to Turtle, there's a question about how we talk about 
> it and present it editorially.   Do we say @prefix is the older form 
> and that PREFIX is preferred now?

Yes.

>   Which do we use in examples?

Newer.

>
> There's also the question of the dot at end of the declaration. People 
> have said that with PREFIX we MUST NOT allow the dot at the end of the 
> line because SPARQL doesn't allow it. 

Yes. Even more so if SPARQL alignment is the goal.

> The fear is that if we allow a dot there in Turtle, then when people 
> cut/paste to SPARQL they'll have to remove those dots.

Yes, and that's a major headache. I write a lot of SPARQL and Turtle and 
I feel that pain zillions of times a day.

> An alternative is to see whether SPARQL implementors would be willing 
> to change their grammars to allow an optional dot at the end of the 
> prefix and base directives.  Technically that would be an extension to 
> SPARQL 1.0/1.1.   Perhaps it would become part of 1.2.  It seems 
> harmless to me, but perhaps I'm missing something.

For us me can implement that quickly. I can't speak for other though.

>
> As a major SPARQL vendor, how would you feel about (1) adding @prefix 
> and/or (2) allowing an optional dot at the end of the PREFIX directive?

No problem, as per comments above.

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