- From: David Booth <david@dbooth.org>
- Date: Wed, 03 Jul 2013 21:58:21 -0400
- To: "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
Sorry, I forgot the [RESOLVED] subject earlier. On 07/03/2013 01:08 PM, David Booth wrote: > 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 Thursday, 4 July 2013 01:58:48 UTC