Re: PrEfIx and BaSe should be removed from Turtle

On 05/16/2013 12:43 PM, Andy Seaborne wrote:
> I'm happy with this.

+1

> From a clean slate, using @ for directives is undesirable because it
> clashes with tokenization of language tags.

Hmmm.  A directive _starts_ with @.  No other statement can start with
@ as @lang always follows a " if it is a language tag.  Prefix is closer
to ambiguous.  Think of prefix: is a valid IRI if prefix is defined
as a prefix. So, prefix: <iriref> still parses as <subject> <predicate>

Besides, on a typically formatted looking Turtle document, grep ^@ is a
perfect way to find all directives.

> But we aren't starting from a clean slate and I have not been keen on
> this at any stage.  "Mostly harmless" is the best is can say about it.
> It can break existing parsers on new data which I consider to be more
> cost than any benefit arising.

Reading by old parsers is one of my big worries. I just updated the
SWI-Prolog version to be compliant with the current spec (planning to
write a report shortly). The writer still writes the old syntax. Even
this doesn't seem to be completely compliant, because the old one parsed
the code below as three triples with a xsd:decimal typed object, while
this is now a syntax error (correct?)

 <s> <p> 1.,2.,3. .

The SWI-Prolog Turtle writer by default tries to do a good job at
producing a document that is pleasant to the human eye. At the moment,
it often has to revert to <iriref> syntax because the local name is
invalid (often because it contains a '.'). I would definitely like to
use the extended prefix:local syntax to enhance readability. I just fear
the complaints and confusion from people using older releases of
RDF/Turtle software :-(

That is why I asked before for a name/version indication, so at least I
can add a comment stating this is a Turtle version X document. If we had
a version directive, old parsers would have been able to tell the users
they cannot handle the file, which is a lot better than the syntax 
errors that you will get now.

Thinking of it, it might not be too late to add a directive that tells
us which of the various closely related formats a file complies to. Note
that many of these formats cannot easily be distinguished by looking at
the data because there is a realistic intersection of valid documents
between them. Think of the list below ...

   - ntriples (test syntax and new specification)
   - n3
   - quads
   - old Turtle
   - (new) Turtle
   - TriG

 Cheers --- Jan

> Gavin - thank you for collecting the information into one place.
>
>      Andy
>
> On 16/05/13 03:48, Gavin Carothers wrote:
>>
>>
>> <https://gist.github.com/gcarothers/5589022#prefix-and-base-should-be-removed-from-turtle>PrEfIx
>>
>>   and BaSe should be removed from Turtle
>>
>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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, 16 May 2013 11:24:42 UTC