Re: PrEfIx and BaSe should be removed from Turtle (process issue)

(removing the non-wg lists and persons)

Process issue: as I learned a few weeks ago, in relation to another 
charter, per

http://www.w3.org/2005/10/Process-20051014/policies#Votes

a Working Group is perfectly entitled to conduct a formal vote by email. 
In view of our time pressure, maybe this is one of those cases when we 
should not use telco time; indeed, I think all arguments pro and con 
have been already said and we should just close the issue in one way or 
other.

Doing it this way (or not) is of course the chairs' decision.

Ivan


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

-- 
Ivan Herman, W3C
Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
http://www.ivan-herman.net/foaf#me