Re: PrEfIx and BaSe should be removed from Turtle

On May 16, 2013, at 1:50 PM, Eric Prud'hommeaux <eric@w3.org> wrote:

> * Gregg Kellogg <gregg@greggkellogg.net> [2013-05-16 11:42-0700]
>> A +1 from me too. What bothers me more about the SPARQL variations is that it is _illegal_ for them to have a trailing ".", something I think SPARQL is too lax about in general. However, to get a syntax error if it is used is unfortunate.
>> 
>> If we were to encourage a change to SPARQL in the future, I would say that keywords MAY have a proceeding @, and that a trailing "." is legal (but not required) after declarations.
> 
> I'm a puzzled by why folks think that Turtle rather than SPARQL is the norm. If I were learning SQL, I'd find "SELECT" much more intuitive than "@SELECT". (AndyS alluded to that in a SPARQL example.) The use of '@'s in a language which doesn't have general keyword extensibility is very hard to justify.

SPARQL really has two antecedents (IMO): SQL and Notation-3. It is also more flexible when it comes to syntax, so I think it's a more appropriate place to have flexibility. While I typically use all-caps for SPARQL keywords, I would find that annoying in Turtle. FWIW, I really don't care much about using "@" for keywords in SPARQL, but it would be a way to bring it more in line with Turtle, this I suggested it be optional. I think keeping Turtle a more strict and concise representation of data promotes better data. Allowing a trailing "." after declarations in SPARQL would prevent a different source of copy/paste errors.

Gregg

> I'm pretty sure the only reason we're so sure that SPARQL should be the one to bend is that we haven't looked at this from the perspecitve of people new to both Turtle and SPARQL. I understand an argument like "it's too late and the community doesn't want to make a painful change, regardless of impact", but to make a principled argument that keywords should have '@'s requires at least some story about how that syntax burden would have a corresponding benefit.
> 
> 
>> Gregg Kellogg
>> gregg@greggkellogg.net
>> 
>> On May 15, 2013, at 7:48 PM, Gavin Carothers <gavin@carothers.name> wrote:
>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Selected Messages and Threads (From outside of WG)
>>> 
>>> Yes, I read all the threads again, just a few are included here.
>>> 
>>> Supporting
>>> 
>>> David Booth 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.
>>> 
>>> In opposition
>>> 
>>> Gregory Williams 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 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 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.
>>> 
>> 
> 
> -- 
> -ericP

Received on Thursday, 16 May 2013 23:01:34 UTC