SPARQL datasource CONSTRUCT wrapped in SELECT for certain SPARQL endpoints

[SvenLieber]

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>

[pheyvaer]

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.