- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Mon, 15 Aug 2011 14:11:38 +0200
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Gavin Carothers <gavin@topquadrant.com>, RDF Working Group WG <public-rdf-wg@w3.org>
* Richard Cyganiak <richard@cyganiak.de> [2011-08-15 11:24+0100] > On 15 Aug 2011, at 05:36, Gavin Carothers wrote: > > On Sat, Aug 13, 2011 at 12:08 PM, Richard Cyganiak <richard@cyganiak.de> wrote: > >> Gavin, > >> > >> On 12 Aug 2011, at 19:14, RDF Working Group Issue Tracker wrote: > >>> New Turtle: > >>> > >>> Allowed: > >>> @prefix bob: http://example.org/bob/ . > >>> bob:goldfish\u002F1 > >> > >> Is that allowed? Section 4.3 [1] says that all the backslash escapes are only allowed inside strings and IRI_REF. I don't see anything that allows them inside prefixed names. > > > > Then section 4.3 doesn't agree with the grammar: > > > > http://www.w3.org/TR/turtle/#term-turtle2-PN_CHARS_BASE > > > > One of them gets to give. > > \u and \U escapes shouldn't be allowed in prefixed names. This has been discussed on the list before. Prefixed names are syntactic sugar to make reading and writing of IRIs easier. Escapes like \u0021 are neither easy to read nor easy to write, so they defeat the purpose of prefixed names. > > > Specific example: > > > > @prefix turtleDocLoc: <http://www.w3.org/TR/2011/WD-turtle-20110809/> > > > > turtleDocLoc:examples/example1.ttl > > > > It's very surprising not to be able to write that. > > If you know about XML prefixes, then it isn't surprising. > > > You can get around > > it by using @base a lot more, or by defining a LOT of prefixes. :\ > > Neither solution is very readable. > > If you have a lot of IRIs that don't share a common base, then you'll end up having a lot of <full_absolute_IRIs> in your file. What's so strange about that? It's no different from HTML. > > I think there is consensus in the group that we should not add extensions to Turtle at this point. We should just standardize it as it is already implemented (modulo SPARQL alignment). > > Personally I am very strongly opposed to extending Turtle in ways that are incompatible with SPARQL. I agree with keeping SPARQL and Turtle compatible so I'll address SPARQL: SPARQL has already changed from processing escape sequences before lexing to after lexing. Previously legal SPARQL strings like PREFIX <http://example.org/> ex: ASK { ?s ex:ab\u0063d ?o } become illegal if SPARQL doesn't accept escaping in prefixed names. Do such strings exist in the wild? Probably not as they weren't useful to utter (because they were unescaped before lexing). But the argument about backward compatibility swings in favor of SPARQL allowing them in prefixed names. Another argument for escaping is that identifier names (e.g. in biology) have things like ':' and '$' in them. Prefixes add a huge amount to the readability of SPARQL and Turtle. Forcing a query or data writer to abandon the logical prefix because there's an illegal localname character is an equally huge impediment to usability. Escape sequences in strings and IRIs are of limited use as one can embed the all legal IRI and string chars in those productions with the help of the specialized escapes \\[nrtb]. Disallowing escape sequences in SPARQL (and maintaining the status quo in Turtle) means we have to justify to the users why the escaping rules they can apply to strings and IRIs aren't applicable to prefixed names where they'd be most useful. We've taken no oath to not extend Turtle in useful ways. We have a rare opportunity to make these languages more useful, consistent and intuitive. > Best, > Richard -- -ericP
Received on Monday, 15 August 2011 12:11:57 UTC