Escaping double quotes in a Fuseki SPARQL query?

Question

Is it possible to use double quotes as part of a URI in a SPARQL query using Fuseki? I'm working off of a DBpedia dataset and it has some URIs like:

<http://dbpedia.org/resource/"Crocodile"_Dundee>

I've tried:

PREFIX dbo: <http://dbpedia.org/ontology/> SELECT ?summary WHERE { <http://dbpedia.org/resource/\"Crocodile\"_Dundee> dbo:abstract ?summary }" localhost:3030/knowledge/query

PREFIX dbo: <http://dbpedia.org/ontology/> SELECT ?summary WHERE { <http://dbpedia.org/resource/%22Crocodile%22_Dundee> dbo:abstract ?summary }" localhost:3030/knowledge/query

but continue to get the following error:

Encountered " "<" "< "" at line 1, column 68.
Was expecting one of:
<IRIref> ...

Answer 1

After some more reading and experimentation, the issue was because I was not properly setting the Content-Type header. It needs to be set to application/sparql-query, and then you can use percent-encoding (though it is discouraged by the SPARQL spec), like so:

curl -i -X POST -d 'PREFIX dbo: <http://dbpedia.org/ontology/> SELECT ?summary WHERE { <http://dbpedia.org/resource/%22Crocodile%22_Dundee> dbo:abstract ?summary }' localhost:3030/knowledge/query  --header "Content-Type: application/sparql-query"

Unfortunately I still could not get escaped double quotes to work.

As a bonus, this also lets you use ampersands (&) in queries:

curl -i -X POST -d 'PREFIX dbo: <http://dbpedia.org/ontology/> SELECT ?uri WHERE { { ?alias_uri rdfs:label "Gibson Dunn & Crutcher"@en; dbo:wikiPageRedirects ?uri . } UNION { ?uri rdfs:label "Gibson Dunn & Crutcher"@en NOT EXISTS {  ?uri dbo:wikiPageRedirects ?nil } } } ' localhost:3030/knowledge/query --header "Content-Type: application/sparql-query"

Answer 2

There are two problems here:

1. Double quotes are not allowed in URIs (RFC 3986).
2. When you send %22 as a query string in a HTTP URL, the other end will decode that and get "

hence using POST and putting the query in the body avoids the problems (or encode the % itself getting send %2522).

Using --data-binary not -d is safer yet.