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

[RESOLVED] Re: Turtle includes Notation3 and SPARQL prefix and base directives

From: David Booth <david@dbooth.org>
Date: Wed, 03 Jul 2013 21:58:21 -0400
Message-ID: <51D4D6BD.5000408@dbooth.org>
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

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