Re: PrEfIx and BaSe should be removed from Turtle

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.

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?    Which do we use in examples?

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

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?

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

Received on Sunday, 26 May 2013 14:06:23 UTC