walder
walder copied to clipboard
SPARQL datasource CONSTRUCT wrapped in SELECT for certain SPARQL endpoints
Hi,
when configuring a SPARQL datasource, the sent CONSTRUCT query is wrapped inside a SELECT which causes an error (the provided example/config-sparql.yaml
works though). This is probably the following comunica issue: https://github.com/comunica/comunica/issues/1251
According to that issue, a missing rdfs prefix mapping causes this behavior. But I am not sure how to properly configure the prefix mapping in the required JSON-LD frame of the walder config (used config and view and the end of the issue).
Done GET /persons text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 500 31.291 ms - 0
/home/slieber/.nvm/versions/node/v17.1.0/lib/node_modules/walder/node_modules/fetch-sparql-endpoint/lib/SparqlEndpointFetcher.js:209
throw new Error(`Invalid SPARQL endpoint response from ${simpleUrl} (HTTP status ${httpResponse.status}):\n${bodyString}`);
^
Error: Invalid SPARQL endpoint response from http://localhost:3001/sparql (HTTP status 400):
Parse error on line 1:
...?p ?label WHERE { CONSTRUCT { ?p <
----------------------^
Expecting 'IRIREF', 'PNAME_NS', '{', '}', 'SELECT', '(', 'INTEGER', 'VALUES', 'VAR', 'NIL', 'GRAPH', 'OPTIONAL', 'MINUS', 'SERVICE', 'FILTER', 'BIND', '[', 'DECIMAL', 'DOUBLE', 'BOOLEAN', 'INTEGER_POSITIVE', 'DECIMAL_POSITIVE', 'DOUBLE_POSITIVE', 'INTEGER_NEGATIVE', 'DECIMAL_NEGATIVE', 'DOUBLE_NEGATIVE', 'STRING_LITERAL1', 'STRING_LITERAL2', 'STRING_LITERAL_LONG1', 'STRING_LITERAL_LONG2', 'PNAME_LN', 'BLANK_NODE_LABEL', 'ANON', '<<', got 'CONSTRUCT'
at SparqlEndpointFetcher.handleFetchCall (/home/slieber/.nvm/versions/node/v17.1.0/lib/node_modules/walder/node_modules/fetch-sparql-endpoint/lib/SparqlEndpointFetcher.js:209:19)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async SparqlEndpointFetcher.fetchBindings (/home/slieber/.nvm/versions/node/v17.1.0/lib/node_modules/walder/node_modules/fetch-sparql-endpoint/lib/SparqlEndpointFetcher.js:88:47)
I have to say that the config example/config-sparql.yaml
on top of the DBPedia endpoint works for me.
The error occurs
- when querying an internal Blazegraph triple store (with
http://username:password@..
prefix for http auth) - when querying a local Comunica SPARQL endpoint on top of that internal Blazegraph (that setup anyway doesn't work, because even when configuring comunica on top of a username:password prefixed URL, queries against the comunica endpoint get a 401 unauthenticated error)
But in the latter case I can see that the comunica server receives a wrong query from walder (enclosing SELECT):
Worker 17343 got assigned a new query (0).
[400] Bad request
Worker 17343 timed out for query 0.
Shutting down worker 17343 with 0 open connections.
Worker 17343 died with 15. Starting new worker.
Server worker (17439) running on http://localhost:3001/sparql
[200] POST to /sparql
Requested media type: application/sparql-results+json
Received query query: SELECT ?p ?label WHERE {
CONSTRUCT {
?p <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person>.
?p <http://www.w3.org/2000/01/rdf-schema#label> ?label.
}
WHERE {
GRAPH <http://beltrans-contributors> {
?p <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person>.
?p <http://www.w3.org/2000/01/rdf-schema#label> ?label.
}
}
}
I installed walder (4.1.3) using npm install -g walder
inside an nvm (version 0.35.3) and node version 17.1.0.
This is my walder config (partially based on the walder tutorial and the provided config-sparql.yaml):
openapi: 3.0.2
info:
title: 'BELTRANS corpus'
version: 1.0.0
x-walder-datasources:
- http://localhost:3001/sparql
paths:
/persons:
get:
summary: Returns a list of all person contributors
responses:
200:
description: List of all person contributors
x-walder-input-text/html: persons.handlebars
x-walder-query:
sparql-query: >
CONSTRUCT {
?p a schema:Person ;
rdfs:label ?label .
}
WHERE {
graph <http://beltrans-contributors> { ?p a schema:Person ;
rdfs:label ?label .
}
}
json-ld-frame: >
{
"@context": {"@vocab": "http://www.w3.org/2000/01/rdf-schema#"},
"@type": "http://schema.org/Person"
}
and this the testing view:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
</head>
<body>
<h1>Persons</h1>
<div>
<ul>
{{#each data}}
<li>{{this.p}}: {{this.label}} </li>
{{/each}}
</ul>
</div>
</body>
</html>
Hi @SvenLieber, the prefixes in the JSON-LD frame have not influence on the Comunica. The output of Comunica is framed using that frame, but it has not influence on the querying itself. So I think it will be fixed in Walder if the corresponding issue in Comunica is fixed.