- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 3 Jul 2013 10:33:56 -0400
- To: Gavin Carothers <gavin@carothers.name>
- Cc: RDF-WG WG <public-rdf-wg@w3.org>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>, David Booth <david@dbooth.org>, David Robillard <d@drobilla.net>, Peter Ansell <ansell.peter@gmail.com>, Gregory Williams <greg@evilfunhouse.com>
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:31 UTC