search

ad-freiburg / qlever

Very fast SPARQL Engine, which can handle very large knowledge graphs like the complete Wikidata, offers context-sensitive autocompletion for SPARQL queries, and allows combination with text search. It's faster than engines like Blazegraph or Virtuoso, especially for queries involving large result sets.
Apache License 2.0
376 stars 45 forks source link

Accept header with multiple options does not return the supported format #1372

Open white-gecko opened 3 months ago

white-gecko commented 3 months ago

Apparently for request with multiple formats in the Accept header, qlever does not look for the first actually supported field, but returns an exception if a known but unsupported format is listed:

$ curl 'https://qlever.cs.uni-freiburg.de/api/dnb' -X POST -H "Accept: application/sparql-results+json, text/turtle, application/trix, application/n-quads, application/sparql-results+json, application/n-triples, application/rdf+xml, application/ld+json, text/n3" -H "Content-type: application/sparql-query" --data "construct { ?s ?p ?o } where { ?s ?p ?o } limit 10"
{
    "exception": "SPARQL-compliant JSON format is only supported for SELECT queries. In file \"/local/data/qlever/qlever-code/src/engine/ExportQueryExecutionTrees.cpp \" at line 726",
    "query": "construct { ?s ?p ?o } where { ?s ?p ?o } limit 10",
    "resultsize": 0,
    "runtimeInformation": {
        "cache_status": "computed",
        "children": [],
        "column_names": [],
        "description": "",
        "details": null,
        "estimated_column_multiplicities": [],
        "estimated_operation_cost": 0,
        "estimated_size": 0,
        "estimated_total_cost": 0,
        "operation_time": 0,
        "original_operation_time": 0,
        "original_total_time": 0,
        "result_cols": 0,
        "result_rows": 0,
        "status": "not started",
        "total_time": 0
    },
    "status": "ERROR",
    "time": {
        "computeResult": 0,
        "total": 0
    }
}

while

$ curl 'https://qlever.cs.uni-freiburg.de/api/dnb' -X POST -H "Accept: text/turtle, application/trix, application/n-quads, application/sparql-results+json, application/n-triples, application/rdf+xml, application/ld+json, text/n3" -H "Content-type: application/sparql-query" --data "construct { ?s ?p ?o } where { ?s ?p ?o } limit 10" 
_:bn39602389 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602390 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602391 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602392 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602394 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602395 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602396 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn39602397 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn40067157 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .
_:bn40067158 <https://d-nb.info/standards/elementset/agrelon#metadataConfidence> 0 .

works.

joka921 commented 3 months ago

Thanks for pointing this out. Our parsing of the GET and POS requests is still rather rudimentary (the bug you discovered is not the only one, and not even the only one we know of). Thanks for reporting this, it is on our list, do you have a way of working around this issue in your application for now?