- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Sat, 23 Apr 2011 15:27:41 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-wg@w3.org
* Andy Seaborne <andy.seaborne@epimorphics.com> [2011-04-23 17:33+0100] > (resent with note of ISSUE-1 for trackbot) > > RDF-WG ISSUE-1 > http://www.w3.org/2011/rdf-wg/track/issues/1 > > > I've gathered the differences together into a live document > > http://www.w3.org/2011/rdf-wg/wiki/Diff_SPARQL_Turtle#Relevant_RDF_WG_Decisions > > > And added a new one: Turtle and SPARQL treat \u escape processing > differently because they happen at different times in the parsing process. +1 I've had a hard time defending the fact that one can't simply escape characters in PNames (SPARQL's QNames). This comes up in DB dumps, e.g. PREFIX p: <http://foo.example/db/People#> . SELECT ?who ?dept WHERE { ?who p:deptName\u002CdeptCity ?dept } SPARQL says \u002C is substituted with ',' *before* parsing (and ',' isn't valid in local names). We could potentially simplify the story for Turtle users by adding unicode escape sequences (I called them UCHARs) to qnames. I hacked this up in a grammar called turtleEsc http://w3.org/brief/MjM0 . It validates strings like: @prefix α: <http://foo.example/bar#> . <ab\u00E9xy> \u03B1:p "ab\u0022cd" . and is, IMO, pretty easy to explain to users. The downside is that we lose grammar control over folks adding chars like [<> ] to IRIs (i.e. left to semantic validation) but I believe it's still better than making PNames un-escapable. > Andy > > -- -ericP
Received on Saturday, 23 April 2011 19:28:11 UTC