Query over multiple named graphs

Support
1

I have a problem when performing a query over multiple named graphs. For instance the following works as all triples are in the HVAC-I graph:

PREFIX seas: <https://w3id.org/seas/>
PREFIX prov: <http://www.w3.org/ns/prov#>
SELECT *
FROM NAMED <https://localhost/seas/HVAC>
FROM NAMED <https://localhost/seas/HVAC-I>
WHERE {
  GRAPH ?g {
    <propURI> seas:evaluation ?eval .
    ?eval seas:evaluatedValue ?latestVal ;
          prov:wasGeneratedAtTime ?latestTime .
    OPTIONAL {
      ?eval prov:wasDerivedFrom ?depEval .
    }
  }
}

But when I extend the OPTIONAL statement with the following, I get no results (as these triples are in the HVAC graph):

OPTIONAL {
  ?eval prov:wasDerivedFrom ?depEval .
  ?depEval ^seas:evaluation ?depProp .
}

Performing the query alone does return a result:

SELECT * 
FROM NAMED <https://localhost/seas/HVAC>
WHERE { 
  GRAPH ?g { 
  	<evalURI> ^seas:evaluation ?prop
  }
}

I might have misunderstood the SPARQL syntax, but I believe what I am trying to achieve is not impossible?

2

Can you provide the version of Stardog and the query plan for the query which does not return results?

Thanks,
Pavel

3

I'm running Stardog 4.2.3, but if this can be the issue I will ugrade to version 5 right away.

The Query Plan:

prefix seas: https://w3id.org/seas/
prefix prov: http://www.w3.org/ns/prov#

From Named https://localhost/seas/HVAC
From Named https://localhost/seas/HVAC-I
Projection(?g, ?eval, ?latestVal, ?latestCalc, ?depEval, ?depProp) [#1]
─ MergeJoinOuter(?eval) [#1] +─ MergeJoin(?eval) [#1] │ +─ Scan[PSOC](?eval, seas:evaluatedValue, ?latestVal){?g} [#3] │ ─ MergeJoin(?eval) [#1]
│ +─ Scan[PSOC](?eval, prov:wasGeneratedAtTime, ?latestCalc){?g} [#3]
│ ─ Scan[SPOC](<https://localhost/seas/Property/e3a93425-aa05-4734-9773-ae6899a7a704>, seas:evaluation, ?eval){?g} [#1] ─ Sort(?eval) [#2]
─ MergeJoin(?depEval) [#2] +─ Scan[POSC](?eval, prov:wasDerivedFrom, ?depEval){?g} [#2] ─ Scan[POSC](?depProp, seas:evaluation, ?depEval){?g} [#3]

5

There was an issue which could, in principle, play a role here. We fixed it in 4.2.4. I’ll appreciate if you try that.

Thanks,
Pavel

6

I just upgraded to version 5, but now I have some problems with performing queries over HTTP. Can you tell me what triggers the “Cannot execute update query on read endpoint”?

7

How exactly are you executing the query?

8

Through an HTTP POST request. I use accept header “text/boolean” and basic auth (which works for GET requests).

9

Sounds like you’re using the wrong endpoint for update queries. You should use /{db}/update for updates and /{db}/query for reads.

10

You are absolutely right. It worked with the old version though.

It inserts the triples as it should, but it returns the following. Is this a problem?

"code": "HPE_UNEXPECTED_CONTENT_LENGTH"

11

It worked in 4.x because the read endpoint was incorrectly accepting update queries.

Can you provide the exact command you’re using to execute the POST request and the stardog.log on the server if there is a related exception?

12

I see.

The log doesn't seem to contain anything. I use request promise with the following options:

{ uri: 'http://localhost:5820/seas/update',
auth: { username: 'admin', password: 'admin' },
json: true,
method: 'POST',
qs: { query: 'INSERT DATA {GRAPH https://localhost/seas/HVAC { https://localhost/seas/HeatingSystem/b7af9a3a-4277-4474-b10d-7c8cda4a7ecd a https://w3id.org/seas/HeatingSystem ; rdfs:label "Heating System 2"^^xsd:string . } }' },
headers: { accept: 'text/boolean' } }

I recieve the error on all update requests.

13

Hi,

What if, in your options, you passed the query in via form instead of by qs? That will send it as x-www-form-urlencoded and should match it with the proper Content-Length

14

Hi Stephen. This doesn't work either. Maybe this can help you? Apparently there is some problem with the content-length header Stardog's API is sending.

15

To follow up on this. I just did a request with postman, and that works fine for me. I receive “true” and a status 200 OK. When I look at the headers, I see that I get a content-length header with the value 24. I would guess that the problem is a mismatch between this and what I actually receive.

16

Hi Pavel

I just did the same query in version 5.0, and unfortunately it still doesn’t work. Maybe I can send you a TRIG-file and the query I am trying to run?

17

Sure, please do (pavel at company’s domain). If the data is too large for email, we can give you access to our dropbox.

Thanks,
Pavel

18

Hi, I tried the request-promise library to send the INSERT query you posted. I noticed that in your qs.query object, you have invalid SPARQL. Your URIs need to have <> surrounding them like so:

{ uri: 'http://localhost:5820/seas/update',
auth: { username: 'admin', password: 'admin' },
json: true,
method: 'POST',
qs: { query: 'INSERT DATA {GRAPH <https://localhost/seas/HVAC> { <https://localhost/seas/HeatingSystem/b7af9a3a-4277-4474-b10d-7c8cda4a7ecd> a <https://w3id.org/seas/HeatingSystem> ; rdfs:label "Heating System 2"^^xsd:string . } }' },
headers: { accept: 'text/boolean' } }

If I do that then Stardog has no issues processing it. I get an error from request-promise, but that could be due to what you posted, in which case we can look into our responses setting Content-Type with chunked. Despite that error, the query itself is processed successfully on Stardog.

19

Hi again,

I just wanted to poke back in here and confirm that the Content-Length/chunked bug you posted does seem to cause problems with request-promise. It will be fixed in the next 5.0 release.

20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.