Re: Turtle implementation report for RDF::Trine

On 07/15/2013 01:23 PM, Gregory Williams wrote:
> On Jul 4, 2013, at 11:01 AM, Gregory Williams <greg@evilfunhouse.com> wrote:
>
>> However, this response does not address the second part of my comment, which was an objection to the needless complexity surrounding the grammar rules for the DOT following prefix/base statements. I didn't find much relevant about this issue in the mailing list archive (though very well could have missed it), and so am not sure if this was discussed within the WG before the decision was made. I'm not sure how believing that this is a "frustrating transition but hope that it will lead to improved user experience in the long run" aligns with requiring users in the near term to remember two different grammar rules. Why not have "@prefix" and "PREFIX" (similarly for "@base" and "BASE") be simply a syntactic variation with no difference in the grammar?
>
> Eric,
>
> I see at [1] that this comment has been marked as resolved, despite my quoted response above indicating that I didn't believe the second part of my comment had been addressed at all. Can this please be fixed, or another comment line be created for this issue?
>
> thanks,
> .greg
>
>
> [1] http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#c18
>

Greg, my apologies on behalf of Eric and the Working Group for 
incorrectly marking this as resolved, and for not responding earlier 
about the DOT rules.   I agree those rules look odd/confusing, but 
hopefully when I explain our reasoning it will make sense.

The reasoning is this: we expect Turtle to be written in one of two 
styles: old-style and new-style.     (We have another open comment about 
what to call them - perhaps Turtle 1.0 and Turtle 1.1 - but I'll call 
them "old" and "new" for now.)

Old-style is what works in non-updated parsers.    We suggest systems 
keep generating output in this style for a little while longer, until 
nearly all deployed software has been updated to handle the upcoming 
Turtle REC.   People can watch the Implementation Report to judge when 
this is.   For old-style Turtle, we don't want to make the DOT optional 
because if one left out the DOT, the file wouldn't be parsed by old 
parsers, defeating the purpose of using old-style Turtle.   (Meanwhile, 
while we expect the *parsers* to migrate to new-style turtle, we 
understand there will be old-style *files* floating around for the 
foreseeable future. That's why we made the new-style an extension of the 
old style, so all new parsers can always handle old files they come across.)

New-style is Turtle with the various extensions we've added, including 
SPARQL-style PREFIX and BASE.   The idea here is to allow users to 
cut-and-paste their PREFIX lines (which are often long and inscrutable) 
between Turtle and SPARQL, and perhaps train their fingers to write it 
that particular way.   Here, if we made DOT optional, someone who used 
the DOT in Turtle would find SPARQL systems rejecting their PREFIX 
declaration, since SPARQL doesn't require allowing the DOT.

Of course, Turtle and SPARQL systems are free to extend the language by 
allowing a DOT after PREFIX and BASE, but unless there is coordination 
among extensions like this, we believe it will confuse users and reduce 
interoperability, because some users will think it's allowed since it 
works in their system.

Does that make sense?    We can make new Turtle parsers handle any 
variant, but in practice we expect to have only two: the one that's 
compatible with old turtle parsers and the one that's compatible with 
SPARQL parsers.    Hopefully old turtle parsers will die out soon, and 
we'll be left with just one style.    If we make the DOT rules more 
flexible, we end up making the compatibility situation actually more 
complex.

Please reply and let us know if this response addresses your concern.   
If not, would you mind starting a new thread (not "replying" to this 
email), and we'll track it as an issue about DOT instead of PREFIX and BASE?

Thanks again for your patience and help ironing out these details.

       -- Sandro

Received on Tuesday, 3 September 2013 17:55:16 UTC