ich habe es mir spaßeshalber angeschaut,
die Fehlermeldung findet schnell den Bug
https://taskman.eionet.europa.eu/issues/14711
zu einer anderen Abfragestelle http://semantic.eea.europa.eu/sparql
die ist allgemein besser, hinsichtlich Content-Type offensichtlich, aber kommt auch mit deiner kompletten Query klar, was bei ec.europa.eu noch in anderer Hinsicht Probleme macht
Vorteil von semantic.eea.europa.eu ist auch, dass dort keine zusätzlichen Parameter benötigt werden, die du hier im String options hast,
das läuft leider so wie gepostet schief, daraus wird
…url?dataset=rapex&format=rdf&limit=10?query=…
auch ohne diese beiden Probleme scheint ec.europa.eu (im Gegensatz zu semantic.eea.europa.eu) mit langen Querys mit Namespace gar nicht zurechtzukommen,
http://semantic.eea.europa.eu/sparql?query=PREFIX++gn%3A+++<http%3A%2F%2Fwww.geonames.org%2Fontology%23>
PREFIX++rdfs%3A+<http%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23>
PREFIX++v%3A++++<http%3A%2F%2Fwww.w3.org%2F2006%2Fvcard%2Fns%23>
PREFIX++rapex%3A+<http%3A%2F%2Fec.europa.eu%2Fsemantic_webgate%2Fdataset%2Frapex%2Fresource%2F>
PREFIX++owl%3A++<http%3A%2F%2Fwww.w3.org%2F2002%2F07%2Fowl%23>
PREFIX++rdf%3A++<http%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23>
SELECT++%3Fs+%3Fp+%3Fo
WHERE
++{+%3Fs+%3Fp+%3Fo+}
LIMIT+++1
ist mit den unnötigen Prefixes von dir eine korrekte Query für semantic.eea.europa.eu, geht im Browser
dagegen funktioniert
http://ec.europa.eu/semantic_webgate/query/sparql?dataset=rapex&format=rdf&limit=10&query=PREFIX++gn%3A+++<http%3A%2F%2Fwww.geonames.org%2Fontology%23>
PREFIX++rdfs%3A+<http%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23>
PREFIX++v%3A++++<http%3A%2F%2Fwww.w3.org%2F2006%2Fvcard%2Fns%23>
PREFIX++rapex%3A+<http%3A%2F%2Fec.europa.eu%2Fsemantic_webgate%2Fdataset%2Frapex%2Fresource%2F>
PREFIX++owl%3A++<http%3A%2F%2Fwww.w3.org%2F2002%2F07%2Fowl%23>
PREFIX++rdf%3A++<http%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23>
SELECT++%3Freport
WHERE
++{+%3Freport+rdf%3Atype+rapex%3Areport+.
++++%3Freport+rapex%3Aid+%3Fid
++++FILTER+(+%3Fid+%3D+"report-2010-022"+)
++}
schon im Browser nicht (XML-Verarbeitungsfehler: Kein Element gefunden)
edit: interessant dass hier im Forum keine URL daraus wird, zu lang oder auch schon irgendein Fehler erkannt?..
wenn man im WebClient von ec.europa.eu eine Query ausführt kommt milderes a la
http://ec.europa.eu/semantic_webgate/query/sparql?dataset=rapex&format=html&limit=10&query=SELECT%20?report%20WHERE%20{%20%20%20%20%20%20?report%20a%20rapex:report%20.%20%20%20%20%20%20%20%20%20%20?report%20rapex:id%20?id%20FILTER(?id%20=%20'report-2010-022')%20.%20}
heraus (edit: auch keine URL hier)
ich habe noch eine Weile versucht, das mit QueryFactory zu buildern, welcher aber fehlende Prefixe gar nicht mag,
letztlich reichte der Content im StringBuilder ohne Prefixe an sich, falls man QueryFactory und QueryExecutionFactory umgeht und direkt mit QueryEngineHTTP hantiert,
welches sowieso als das QueryExecution-Objekt zurückgegeben würde, jedenfalls in diesem Beispiel
public class Test2 {
public static void main(String[] args) throws Exception {
StringBuilder sb = new StringBuilder();
// sb.append("prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#> ");
// sb.append("prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> ");
// sb.append("prefix gn:<http://www.geonames.org/ontology#> ");
// sb.append("prefix v:<http://www.w3.org/2006/vcard/ns#> ");
// sb.append("prefix owl:<http://www.w3.org/2002/07/owl#> ");
// sb.append("prefix rapex: <http://ec.europa.eu/semantic_webgate/dataset/rapex/resource/> ");
sb.append("SELECT ?report WHERE { ");
sb.append("?report a rapex:report . ");
sb.append(" ?report rapex:id ?id FILTER(?id = 'report-2010-022') . }");
String url = "http://ec.europa.eu/semantic_webgate/query/sparql";
QueryEngineHTTP qe = new QueryEngineHTTP(url, sb.toString());
qe.addParam("dataset", "rapex");
qe.addParam("format", "rdf");
qe.addParam("limit", "10");
ResultSet rs = qe.execSelect();
System.out.println(rs.hasNext());
QuerySolution qs = rs.next();
System.out.println(qs.toString());
}
}
ob damit alle möglichen Querys funktionieren lasse ich offen, mich interessierte nur, diese eine zum Laufen zu bringen
zurück zum Fehler ‚Content-Type: text/xml which is not currently supported for SELECT queries‘:
da geht bei mir nur Modifikation des Quellcodes:
Klasse QueryEngineHTTP, Zeile ~384, ein if-Konstrukt auf den ContentType:
if (actualContentType.equals(WebContent.contentTypeXMLAlt) || actualContentType.equals(WebContent.contentTypeResultsXML) || actualContentType.equals(WebContent.contentTypeXML))
return ResultSetFactory.fromXML(in);
if (actualContentType.equals(WebContent.contentTypeResultsJSON) || actualContentType.equals(WebContent.contentTypeJSON))
return ResultSetFactory.fromJSON(in);
if (actualContentType.equals(WebContent.contentTypeTextTSV))
return ResultSetFactory.fromTSV(in);
if (actualContentType.equals(WebContent.contentTypeTextCSV))
return CSVInput.fromCSV(in);
WebContent.contentTypeXMLAlt ist Konstante für „text/xml“, im Standard aber nirgendwo genutzt…, habe ich ergänzt
es gibt noch eine zweite Codestelle mit gleichen if-Konstrukt
um Code zu modifizieren braucht man den Quellcode aus dem Download, jena-arq und jena-core hatte ich als Quellcode reinkopiert (com und org) und dann
auf die beiden Jars als externe Libraries verzichtet,
bisschen mehr ist noch in den Jars, was als Ressourcen wohl auch irgendwann gebraucht wird, nur experimentell bei mir…
edit:
ein Umweg ohne Quellcode-Spielereien wäre (für dieses Beispiel) noch,
XML-Datei vom Server mit HTTPClient oder schlicht URL mit der korrekten Query (qe.toString() ohne GET) zu laden:
InputStream in = urlO .openStream();
ResultSet rs = XMLInput.fromXML(in);
System.out.println(rs.hasNext());
QuerySolution qs = rs.next();
System.out.println(qs.toString());
allgemein muss ec.europa.eu wohl den gleichen ‚Bug‘ wie im Link oben bearbeiten, ContentType umstellen, außerdem vielleicht Prefixe im Query-String akzeptieren,
Jena sollte besser doch auch mit ‚text/xml‘ arbeiten, vielleicht Queries einfach ohne Prefixe, ohne nervige Fehlermeldungen erlauben,
außerdem sollten zusätzliche Parameter in URL besser unterstützt werden
darfst gerne an alle schreiben und nerven