Orri, Mitko I think I have found a bug. I use two of your incarnations: dbpedia and my local version...
Look at the following Query: PREFIX prop: <http://dbpedia.org/property/> PREFIX res: <http://dbpedia.org/resource/> SELECT ?lat ?long FROM <http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&should-sponge=&query=%0D%0ACONSTRUCT+%7B%0D%0A++++%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FBudapest%3E+%3Fp+%3Fo.%0D%0A%7D%0D%0AWHERE+%7B%0D%0A++++%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FBudapest%3E+%3Fp+%3Fo.%0D%0A%7D%0D%0A&format=application%2Frdf%2Bxml> WHERE { res:Budapest prop:latitude ?lat; prop:longitude ?long. } The long (and ugly:-) URI goes to your server on dbpedia and makes a CONSTRUCT request. If you take this URI and put it into the browser address line it is correct. However, the query goes wrong. The interesting thing is that as soon as I put this into the /sparql dialogue box the pull down menus for the return formats change and gives a choice of N3 or RDF/XML. The request itself goes wrong. Note that the same query works properly in Joseki (yes, I also run Joseki on my machine so I can check the queries on different endpoints:-). My feeling is that you parse the query and see the keyword CONSTRUCT which switches a mode in your query processor. Which is *wrong* if the CONSTRUCT is inside a URI... Another bug, I think. If, in the long URI, I replace each '&' for a '&', then the dbpedia.org server reports an error that there is no query in the URI. I have the impression that you do *not* recognize the & in a URI. I think this is wrong; actually, a bunch validators *require* the usage of & in a URI when, eg, part of an HTML file... Cheers Ivan -- Ivan Herman, W3C Semantic Web Activity Lead URL: http://www.w3.org/People/Ivan/ PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
smime.p7s
Description: S/MIME Cryptographic Signature
