- From: David Booth <david@dbooth.org>
- Date: Wed, 03 Jul 2013 13:08:24 -0400
- CC: "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
I am satisfied with this resolution. David On 07/03/2013 10:33 AM, Eric Prud'hommeaux wrote: > 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. >
Received on Wednesday, 3 July 2013 17:08:52 UTC