Open hannahbast opened 2 years ago
Please advise if the following SPARQL expression is on the development roadmap?
... WHERE BIND (EXISTS {SELECT ...
If it is not, I would be grateful if you could support it. Having this expression in SPARQL query raises the following error: Invalid SPARQL query: Built-in function "exists { select where{ http://test.domain/device.owl#interface/address ?p ?o.} limit1 }" not yet implemented; if you need it, just add it to SparqlQleverVisitor.cpp::visitTypesafe(Parser::BuiltInCallContext following the already implemented functions there
Could you post the full query @tokarenko?
<http://test.domain/device.owl#interface/address>
.in the error message it looks like the subquery has no projection, is this correct? Please show the whole query.
Other than that, I think (not) exists
function is simply not implemented yet. It won't work even with a a correct subquery.
I am trying to use qLever with my custom ontology behind a SPARQL federation engine.
I am trying to get "1.1.1.1" from the following triple:
<http://test.domain/device.owl#core1_Gi0/1_ipv4_address> <http://test.domain/device.owl#IP> "1.1.1.1"^^<http://www.w3.org/2001/XMLSchema#string> .
The query is as follows:
prefix onto: <http://test.domain/device.owl#>
SELECT ?ip WHERE {
<http://test.domain/device.owl#core1_Gi0/1_ipv4_address> onto:IP ?ip
}
Federation engine queries qLever as follows:
prefix onto: <http://test.domain/device.owl#>
select *
where {
bind (exists {select *
where {
?s onto:IP ?o .
}
limit 1 } as ?b0)
bind (exists {select *
where {
<http://test.domain/device.owl#core1_Gi0/1_ipv4_address> onto:IP ?ip .
}
limit 1 } as ?b1)
}
limit 1000
I tried Ontotext GraphDB with the same ontology. It works as expected. So, I assume the query is fine.
I had a look into the code. exists
and not exists
are not implemented. The error message is wrong. It should of course mark that EXISTS
is not implemented instead of marking the whole sub pattern.
While the simple s-p-o query works, restricting it to ?s a ?o fails: https://qlever.cs.uni-freiburg.de/wikidata/TqjfBa
Also, while the wiki claims that IN and NOT IN are supported, the relevant PR https://github.com/ad-freiburg/qlever/pull/1344 is not yet merged. The linked example query demonstrates a workaround (using VALUES), but not IN/NOT IN
Hi, Yes, #1344 is almost finished, and will implement IN/NOT IN Also #1374 Will fix your other issue (LIMITS on single triples). The more general feature (limiting arbitrary results that run out of memory when run unlimited) is a work in process, but will probably still take some time..
Please note that the https://github.com/WolfgangFahl/snapquery can now happily host the test queries as named parameterized queries. I intend to e.g. give all queries of this tickets names as i already did successfully for the tickets from the wikidata query service short names queries with the help of an LLM to guess the names, description and the like. @joka921 - i also sent you and e-mail recently - it might have ended up in your SPAM filter so it would be great if you get actively in touch. Do you have an official suite of test queries by now or shall we offer one as part of the snapquery project?
The DESCRIBE keyword is not supported. I have not seen it mentioned anywhere in the issues or in the wiki.
@agustaf9 Thanks for pointing that out, I have added DESCRIBE
and ASK
to the list on https://github.com/ad-freiburg/qlever/wiki/Current-deviations-from-the-SPARQL-1.1-standard, together with simple workarounds.
@WolfgangFahl I missed your last request and reading it now, I am not sure I understand it. Could you provide a bit more context?
Just a detail: If I understand correctly NOW()
has been implemented by #1377
SELECT (NOW() AS ?now) WHERE {}
Whenever you encounter a query that you think should work (according to the SPARQL 1.1 standard) but throws an error message or gives an unexpected result, please post it here. Please check whether a similar query has already been posted before.
I will now move various queries from other issues here, so that we don't have one issue per query (which doesn't really help).