W3C home > Mailing lists > Public > public-rdf-comments@w3.org > July 2013

Re: Turtle includes Notation3 and SPARQL prefix and base directives

From: David Booth <david@dbooth.org>
Date: Wed, 03 Jul 2013 13:08:24 -0400
Message-ID: <51D45A88.2060100@dbooth.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:57 UTC