- From: Peter Ansell <ansell.peter@gmail.com>
- Date: Thu, 4 Jul 2013 09:00:12 +1000
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: Gavin Carothers <gavin@carothers.name>, 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>, Gregory Williams <greg@evilfunhouse.com>
- Message-ID: <CAGYFOCT7k=J_Tq3mPvwD5SHUT+wO8_v6YsWuCZHjEvwJzzs-jQ@mail.gmail.com>
On 4 July 2013 00:33, Eric Prud'hommeaux <eric@w3.org> 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. > > -- > -ericP > I am satisfied with this resolution to the issue of whether to allow the new SPARQL directives as valid Turtle. Since the group has chosen to allow the case-insensitive SPARQL Operators to be valid in Turtle, what is the response to my query about whether @prefix and @base are to be case-insensitive in the new Turtle to match the new directives [1]. One of the anonymized comments above recommended that they be changed to be case-insensitive with a change to the grammar, along with making the dot after both versions optional. Given that Turtle will still not have copy and paste support of Turtle documents to SPARQL given the SPARQL grammar does not allow mixing of prefix/base and triples as Turtle does, I would like the grammar changed to make both directives case-insensitive and make the period optional in both versions. Existing parsers won't support the new directives immediately anyway, so they could just as easily be modified at this stage to support all of the variations: │ │[4] prefixID ::= '@'? [Pp][Rr][Ee][Ff][Ii] │ │ │[Xx] PNAME_NS IRIREF "."? │ │ │[5] base ::= '@'? [Bb][Aa][Ss][Ee] IRIREF │ │ │"."? Thanks, Peter [1] http://lists.w3.org/Archives/Public/public-rdf-comments/2012Nov/0005.html
Received on Wednesday, 3 July 2013 23:00:40 UTC