Re: RDF 2.0 Wishlist - Legal RDF which I can't SPARQL

On 29 Jul 2010, at 12:20, Mischa Tuffield wrote:

> Hi All, 
> I know this is a known problem, but I have been bitten by the fact that there are legal RDF documents which I can't query using the SPARQL query language. And perhaps this should be looked at any future revision of RDF or SPARQL. 
> The issue arises because turtle doesn't forbid the use of certain characters, for example the backtick " ` " (%60), where as SPARQL does forbid it. Which means that I can write legal turtle, import it into my triplestore, but I wont be able to ever query that data via SPARQL.
> For example, the following turtle is legal : 
> <`uri> a foaf:Document . 
> <`uri> foaf:primaryTopic  <`uri#me> .
> But I cant write the following SPARQL query: 
> SELECT * WHERE { <`uri> ?p ?o}
> I thought this was due to the fact that the RDF spec [1] was written before the RFC which defined URIs [2], but I can't find a link to an RDF spec which pre dates 1998.

RDF core was working in parallel with the IRI [1] work. URIRef [2] (as I understand it) was trying to anticipate what IRIs would be. URIRef and IRI are pretty close (but see below), and I think the general recommendation is that you should read 'URIRef' as 'IRI'.

SPARQL syntax is defined in terms of IRIs, although I'm not sure syntax is identical (it uses ([^<>"{}|^`\]-[#x00-#x20])*), but it seems close enough.

Looking at the IRI spec ` is not permitted, however URIRef does allow it. 'Pretty close', but not close enough. Turtle, it seems, is in the URIRef camp.

It also doesn't seem to be permitted in URIs, [3] which makes URIRef feel like it's outside the mainstream.

Personally I would follow IRI and fix turtle. Why should RDF have its own URL/URI/IRI-ish syntax?

As for "`Cross-Selling`%20Within%20the%20Dating,%20Adult%20Dating%20Arena.php'", that does work when encoded.

Disclaimer: I may have got some or all of this wrong. Do not trust my assertions regarding the RFCs.


[1] <>
[2] <>
[3] <>

Received on Thursday, 29 July 2010 12:52:07 UTC