Federated Endpoint Query fails for rdfs:label property

Support
1

I am trying to access U.S National Library of Medicine (MeSH) Sparql endpoint and facing a weird issue.
I am able to query the data if I don't use the rdf or rdfs predicate for example. Below query works fine and I get the output.

SELECT *
WHERE{
    SERVICE <http://id.nlm.nih.gov/mesh/sparql> { 
  <http://id.nlm.nih.gov/mesh/Q000302> ?p ?o .  
    } 
}

But when I try to find to access the query with "rdfs:label" it doesn't work

prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT *
WHERE{
    SERVICE <http://id.nlm.nih.gov/mesh/sparql> { 
  <http://id.nlm.nih.gov/mesh/Q000302> rdfs:label ?o .
  
    } 
}

I get below error

"[2020-07-15 11:36:03.421] [error] Failed to run query: Something went wrong and we're not sure what it is. Contact your system admin to review server logs for more details if the issue persists."
The diagnoistic reports state the below error "com.complexible.stardog.plan.eval.operator.OperatorException: SERVICE evaluation returned HTTP response code 500"

I am not sure what I am doing wrong, but it appears the federated endpoint query fails if I try to use the rdf and rdfs property.

Can you please help me with this. Thanks!!

2

please find entire stacktrace below

Slice(offset=0, limit=1000) [#1,0K]
─ Projection(?o) [#10K] ─ Service http://id.nlm.nih.gov/mesh/sparql {
`─ http://id.nlm.nih.gov/mesh/Q000302 rdfs:label ?o .
}

against database thesis
com.complexible.stardog.plan.eval.operator.OperatorException: SERVICE evaluation returned HTTP response code 500
at com.complexible.stardog.plan.eval.service.SPARQLService$SparqlServiceQuery.evaluateBatch(SPARQLService.java:196) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.service.BatchingJoinArgServiceQuery.evaluate(BatchingJoinArgServiceQuery.java:74) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.impl.ServiceOperatorImpl.computeNext(ServiceOperatorImpl.java:93) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.impl.ServiceOperatorImpl.computeNext(ServiceOperatorImpl.java:29) ~[stardog-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:147) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:134) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:87) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:29) ~[stardog-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:147) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:134) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.impl.SliceOp._hasNext(SliceOp.java:92) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.impl.SliceOp.computeNext(SliceOp.java:100) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.impl.SliceOp.computeNext(SliceOp.java:26) ~[stardog-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:147) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:134) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:154) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:28) ~[stardog-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:147) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:134) ~[stardog-utils-common-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:119) ~[stardog-7.3.2.jar:?]
at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:40) ~[stardog-7.3.2.jar:?]
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141) ~[guava-27.0-jre.jar:?]
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136) ~[guava-27.0-jre.jar:?]
at com.complexible.common.base.CloseableIterator$2.computeNext(CloseableIterator.java:84) ~[stardog-utils-common-7.3.2.jar:?]
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141) ~[guava-27.0-jre.jar:?]
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136) ~[guava-27.0-jre.jar:?]
at com.complexible.common.rdf.query.IteratorAsTupleQueryResult.computeNext(IteratorAsTupleQueryResult.java:81) ~[stardog-utils-rdf-7.3.2.jar:?]
at com.complexible.common.rdf.query.IteratorAsTupleQueryResult.computeNext(IteratorAsTupleQueryResult.java:23) ~[stardog-utils-rdf-7.3.2.jar:?]
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141) ~[guava-27.0-jre.jar:?]
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136) ~[guava-27.0-jre.jar:?]
at com.stardog.stark.query.ClosingSpliterator.forEachRemaining(ClosingSpliterator.java:37) ~[stardog-stark-query-api-7.3.2.jar:?]
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) ~[?:?]
at com.stardog.stark.query.io.QueryResultWriters.write(QueryResultWriters.java:142) ~[stardog-stark-query-io-7.3.2.jar:?]
at com.stardog.stark.query.io.QueryResultWriters.write(QueryResultWriters.java:127) ~[stardog-stark-query-io-7.3.2.jar:?]
at com.complexible.stardog.protocols.http.server.ProtocolUtils.writeTupleResponse(ProtocolUtils.java:697) ~[stardog-protocols-http-server-7.3.2.jar:?]
at com.complexible.stardog.protocols.http.server.ProtocolUtils.executeReadQuery(ProtocolUtils.java:589) ~[stardog-protocols-http-server-7.3.2.jar:?]
at com.complexible.stardog.protocols.http.server.ProtocolUtils.executeReadQuery(ProtocolUtils.java:561) ~[stardog-protocols-http-server-7.3.2.jar:?]
at com.complexible.stardog.protocols.http.server.ProtocolUtils.executeReadQuery(ProtocolUtils.java:522) ~[stardog-protocols-http-server-7.3.2.jar:?]
at com.complexible.stardog.protocols.http.server.SPARQLProtocol.executeQuery(SPARQLProtocol.java:146) ~[stardog-protocols-http-server-7.3.2.jar:?]
at com.complexible.stardog.protocols.http.server.SPARQLProtocol.post(SPARQLProtocol.java:106) ~[stardog-protocols-http-server-7.3.2.jar:?]
at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5(ExtractRoutes.java:192) ~[stardog-protocols-http-server-7.3.2.jar:?]
at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120) [shiro-core-1.3.0.jar:1.3.0]
at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108) [shiro-core-1.3.0.jar:1.3.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:830) [?:?]
Caused by: com.complexible.stardog.plan.eval.operator.OperatorException: SERVICE evaluation returned HTTP response code 500
at com.complexible.stardog.plan.eval.service.SPARQLService$SparqlServiceQuery.evaluateBatch(SPARQLService.java:190) ~[stardog-7.3.2.jar:?]
... 45 more

3

It's not the prefix. If you remove the prefix and use the full IRI you get the same problem

prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT *
WHERE{
    SERVICE <http://id.nlm.nih.gov/mesh/sparql> { 
  <http://id.nlm.nih.gov/mesh/Q000302> <http://www.w3.org/2000/01/rdf-schema#label> ?o .
  
    } 
}

It looks like the sparql endpoint it redirecting to https but that's not the problem either.

Running the query directly against the endpoint returns successfully.

MeSH SPARQL Explorer

Looking at that url gives me an idea. Maybe they're not allowing unlimited query results so it doesn't overwhelm the server? I'm also not sure what that year parameter is all about.

4

Nope, getting rid of all the extra parameters still works fine

curl -X GET "https://id.nlm.nih.gov/mesh/sparql?query=prefix%20rdfs%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%20SELECT%20*%20WHERE%7B%20%20%20%3Chttp%3A%2F%2Fid.nlm.nih.gov%2Fmesh%2FQ000302%3E%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23label%3E%20%3Fo%20.%20%20%20%20%20%20%20%20%7D%20" -H "accept: application/sparql-results+xml"

5

hi @zachary.whitley thanks a lot for your prompt response.
Actually my goal is to extract the information for the Medical Concepts and display their names i.e. Labels.
When we try to query just single concept and check the results it gives out 16 values. And out of them if I try to extract the rdf:label as mentioned earlier it fails. So I am not sure what the "unlimited query results" mean here

example - the below query gives out 16 values and our goal is to get the label

prefix rdfs: http://www.w3.org/2000/01/rdf-schema#
SELECT *
WHERE{
SERVICE http://id.nlm.nih.gov/mesh/sparql {
http://id.nlm.nih.gov/mesh/Q000302 ?p ?o .
}
}

6

It wouldn't be unlimited but without a LIMIT clause it could potentially return a large number of results. It's returning a 500 so there's something wrong on their side but I'm trying to figure out what exactly it doesn't like about the query so maybe you can get a workaround or at least figure out what's going on.

1 Like
7

@zachary.whitley - also surprisingly when I run the same query via any other sparql editor (Advanced SPARQL Query Editor - Publications Office of the EU)
It does run fine to extract the Label name via rdfs:label but somehow in the stardog studio it fails to produce the output and gives error

8

yes that would be great, Thanks!! I'm also figuring out of ways for a workaround. This for a research project for my master thesis and I have the entire Stardog Studio DB setup. The final ask is to fetch related medical concepts for my local DB URIs via the U.S National Library of Medicine (MeSH) Service Endpoint for which I would need the Labels etc :confused:
In their documentation I do see the "years" etc parameters given. but like you mentioned even without those optional parameters it should work (SPARQL and URI Requests)

thanks for all the help so far

9

I think I know what might be happening but I'm still looking into it but it looks like Stardog isn't passing along the rdfs prefix and that's causing a problem even when you use the full IRI and don't use a prefix because Stardog is rewriting the full IRI back to rdfs:label and doesn't include the prefix.

10

ohh that's interesting and peculiar. but good to hear atleast you have a hunch of what might be going wrong. Thanks for the update, will await to hear from you. thanks

11

hi @zachary.whitley - were able to get some more insights on this issue?

13

I think I've got a good idea of what the problem is. Stardog doesn't pass along prefixes because it expects to rewrite the service query with full IRI's and shouldn't require a prefix but is prefixing the built in prefixes, rdf, rdfs, owl, xsd, etc. Removing the predefined prefixes does not fix the problem and you'll have to wait for Stardog to release a fix. The good news is I have found a work around that may work in the interim so you can continue with your work.

Rewrite the following query

prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT *
WHERE{
    SERVICE <http://id.nlm.nih.gov/mesh/sparql> { 
  <http://id.nlm.nih.gov/mesh/Q000302> rdfs:label ?o .
  
    } 
}

to this one

prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT *
WHERE{
    SERVICE <http://id.nlm.nih.gov/mesh/sparql> { 
        <http://id.nlm.nih.gov/mesh/Q000302> ?p ?o .
        FILTER(STR(?p) = "http://www.w3.org/2000/01/rdf-schema#")
  
    } 
}

Since the url is now in a literal it's protected from being rewritten with the prefix. The performance would depend on the optimizer on the remote endpoint but it could be rewritten to the equivalent of the first query and be fine. I gave it a try and that seems to be he case.

This trick also works with BIND and the IRI function. I haven't tested it yet but VALUES would probably work as well.

SELECT *
WHERE{
    SERVICE <http://id.nlm.nih.gov/mesh/sparql> { 
        BIND(IRI"http://www.w3.org/2000/01/rdf-schema#") AS ?p)
        <http://id.nlm.nih.gov/mesh/Q000302> ?p ?o .

  
    } 
}
1 Like
14

Thanks a lot @zachary.whitley for your response. Yes now I can see that when I protect the rdfs:label as a literal in the Filter. I do get the output. I think this should suffice for now and I can continue with my Thesis development work with the same. This indeed was a brain scratcher but I appreciate all your help and time you invested to debug this and provide me with a workaround.

image
image944×434 13.9 KB

Have a happy weekend,
Kanwal

15

My pleasure @kanwalmeet. If you don't mind, please share your thesis when you're done so we can congratulate you and see what you've done with Stardog.

1 Like
16

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