Re: Comment on Path / PName clash and Turtle impact

On Fri, 2012-07-13 at 15:14 +0100, Andy Seaborne wrote:
> David,
> 
> The SPARQL and RDF working groups have been working to align SPARQL and 
> Turtle syntax. The area of prefixed names is the main area of alignment.
> 
> The SPARQL Working Group has decided not to take the approach you 
> propose of adopting a different syntax for prefixed names specifically 
> for property paths. The syntax of prefix names in SPARQL and in Turtle 
> (at last call [1]) is the same.
> 
> The set of characters requiring escapes is the RFC 3986 'gen-delims' and 
> 'sub-delims' except that there has been a change to allow the ":" 
> character to be included unescaped into a prefix name in line with 
> Turtle because the Open Graph Protocol uses this style and also it is 
> the approach taken in URN schemes.
> 
> We hope that this reply responds your comment and would be grateful if 
> you would acknowledge the response by sending a reply to this mailing list.

Apologies for the very late reply, I do not actively follow this list.

Fair enough; as mentioned I see triple syntax alignment as a good thing,
but not an overriding concern.  In my opinion the WG has lost its way
and is ruining Turtle without any regard for *Turtle* implementers, so I
will likely never be implementing the new spec as-is.  I will adopt
appropriate changes, such as more allowable prefix characters,
piece-wise as needed.  Most of them are fine.

I should have mentioned in my formal comment that PREFIX and BASE are
also inappropriate - even more so, actually.  It is ridiculous to have
to two completely different syntaxes for the same directives in Turtle.
The triple compatibility argument is a half decent one, but a Turtle
document is not a SPARQL document anyway, they have different top level
term syntaxes.  Ramming SPARQL term syntax into Turtle just messes up
what, once upon a time, was an elegant little RDF syntax, for no good
reason.  Is it really necessary to turn the Turtle spec into a
design-by-committee eyesore?  If implementations want to implement this,
they can, but it clearly does not belong in the Turtle spec.
Essentially we have fragments of SQL in Turtle now, which is crazy.  The
only thing having these rules in the Turtle grammar does is encourage
implementations to produce documents that are not backwards compatible.
This violates the "permissive reading, strict writing" principle, so I
likely won't be implementing that either.

For what it's worth, every single Turtle implementer I have discussed
this with on IRC and private email feels the same way, understandably.
Turtle is not SPARQL, and there are plenty of implementations of the
former that aren't also implementations of the latter.  I think it is
inappropriate for the WG to dismiss the former so flippantly.

Thanks,

-dr