- 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