Turtle includes Notation3 and SPARQL prefix and base directives

This message is a response to the following Turtle Candidate
Recommendation comments: 11, 12, 18, 37)
  http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#c11
  http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#c12
  http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#c18
  http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#c37

* Gavin Carothers <gavin@carothers.name> [2013-05-15 19:48-0700]
>  <https://gist.github.com/gcarothers/5589022#prefix-and-base-should-be-removed-from-turtle>PrEfIx
> and BaSe should be removed from Turtle

After extensive discussion in lists and telecons, the RDF Working
Group conducted a WG poll (below), the results of which lead the WG to
preserve this feature and to no-longer consider it At-Risk.
<https://www.w3.org/2013/meeting/rdf-wg/2013-05-29#Turtle> The
rationale is that we will migrate to using the SPARQL form but for
backward-compatibility, serializers should use the Notation3 form
until there has been wide deployment of new Turtle parsers.

<https://www.w3.org/2002/09/wbs/46168/at-sign/results> was a
member-visible poll of Working Group members. The anonymized results
are here (apologies, the poll didn't ask permission to share people's
positions):
┌────────────────┬───────────────────────────────────────────┐
│Should we allow │                                           │
│  or disallow   │                                           │
│PREFIX and BASE │                 Comments                  │
│     (case      │                                           │
│ insentiive) in │                                           │
│    Turtle?     │                                           │
├────────────────┼───────────────────────────────────────────┤
│Strong          │                                           │
│preference for  │                                           │
│disallowing     │                                           │
│PREFIX and BASE,│                                           │
│but can live    │                                           │
│with allowing   │                                           │
├────────────────┼───────────────────────────────────────────┤
│Strong          │                                           │
│preference for  │                                           │
│allowing PREFIX │Arguments detailed in http://lists.w3.org/ │
│and BASE, but   │Archives/Public/public-rdf-wg/2013May/0229 │
│can live with   │                                           │
│disallowing     │                                           │
├────────────────┼───────────────────────────────────────────┤
│Slight          │                                           │
│preference for  │The comments list unscientifically suggests│
│disallowing     │more "against" than "for".                 │
│PREFIX and BASE │                                           │
├────────────────┼───────────────────────────────────────────┤
│                │Personally, I think they're a bit ugly.    │
│                │However, if we were going to do that, I    │
│                │would vote for having 'a' also be mixed    │
│                │case to be consistent. I would also like to│
│Slight          │see an optional '.' after base/prefix, as  │
│preference for  │this is a common source of errors IMO.     │
│disallowing     │Perhaps rules such as the following would  │
│PREFIX and BASE │help make it more consistent:              │
│                │                                           │
│                │[4] prefixID ::= '@'? [Pp][Rr][Ee][Ff][Ii] │
│                │[Xx] PNAME_NS IRIREF "."?                  │
│                │[5] base ::= '@'? [Bb][Aa][Ss][Ee] IRIREF  │
│                │"."?                                       │
├────────────────┼───────────────────────────────────────────┤
│Slight          │                                           │
│preference for  │                                           │
│disallowing     │                                           │
│PREFIX and BASE │                                           │
├────────────────┼───────────────────────────────────────────┤
│                │                                           │
│No opinion      │                                           │
│                │                                           │
├────────────────┼───────────────────────────────────────────┤
│Slight          │                                           │
│preference for  │                                           │
│allowing PREFIX │                                           │
│and BASE        │                                           │
├────────────────┼───────────────────────────────────────────┤
│Strong          │                                           │
│preference for  │                                           │
│allowing PREFIX │Compatibility between SPARQL and Turtle is │
│and BASE, but   │a huge boost to both languages.            │
│can live with   │                                           │
│disallowing     │                                           │
├────────────────┼───────────────────────────────────────────┤
│Slight          │                                           │
│preference for  │                                           │
│allowing PREFIX │                                           │
│and BASE        │                                           │
├────────────────┼───────────────────────────────────────────┤
│Slight          │                                           │
│preference for  │                                           │
│disallowing     │                                           │
│PREFIX and BASE │                                           │
├────────────────┼───────────────────────────────────────────┤
│                │I'm in doubt. I don't like potential       │
│                │incompatibilities with passing PREFIX to an│
│                │old parser. OTOH I'm tired to explain the  │
│                │"@prefix here and PREFIX there" difference.│
│                │No doubt it would be perfect to tweak      │
│                │SPARQL from the very beginning to have     │
│                │@prefix/@base there (maybe by treating @ as│
│Slight          │a "command prompt", so it would be @select │
│preference for  │etc. at top level and the ability of       │
│allowing PREFIX │inlining data).                            │
│and BASE        │                                           │
│                │It's always good when a data language is a │
│                │strict subset of the processing language   │
│                │(remember LISP), but it's too late to      │
│                │change either Turtle or SPARQL. So let it  │
│                │be prefix/@prefix variation, and I'll      │
│                │continue to serialize data with @prefix and│
│                │start to accept both.                      │
├────────────────┼───────────────────────────────────────────┤
│No opinion      │                                           │
│                │                                           │
├────────────────┼───────────────────────────────────────────┤
│Strong          │                                           │
│preference for  │                                           │
│allowing PREFIX │                                           │
│and BASE, but   │                                           │
│can live with   │                                           │
│disallowing     │                                           │
├────────────────┼───────────────────────────────────────────┤
│Strong          │                                           │
│preference for  │                                           │
│allowing PREFIX │                                           │
│and BASE, but   │                                           │
│can live with   │                                           │
│disallowing     │                                           │
├────────────────┼───────────────────────────────────────────┤
│Slight          │                                           │
│preference for  │                                           │
│allowing PREFIX │                                           │
│and BASE        │                                           │
├────────────────┼───────────────────────────────────────────┤
│Slight          │The spec should make it clear which form is│
│preference for  │preferred and all examples should use that │
│allowing PREFIX │form                                       │
│and BASE        │                                           │
└────────────────┴───────────────────────────────────────────┘


> 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.
>  <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 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 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 Wednesday, 3 July 2013 14:34:30 UTC