-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Weird query evaluation behaviour #1112
Comments
In order to support various OWL formats and imports, ROBOT loads all input data through OWLAPI, and then sends it to Apache Jena if SPARQL operations are required. My understanding is that your OWL Axiom Annotation implies that there's a triple to annotate, and your example is not well-formed as you presented it. So I guess that OWLAPI is adding the triple when |
Maybe I didn't quite understand. OWL Axiom Annotations require the predicate to be declared as an OWL Annotation Property, which is a common source of confusion that you can see elsewhere on this tracker. |
Yes, I am aware of this - this seems just another example of a mismatch of the RDF-entailment over OWL. The query behaves
|
SPARQL UPDATE is an RDF operation, not an OWL operation. How do you suggest that ROBOT should handle it? |
OWL entailment regime might help (e.g. for handling the reified axioms) as an opt-in switch - https://www.w3.org/TR/sparql11-entailment/#OWLRDFBSEntRegime. |
What tool would we use to implement that? |
At some point I was working on https://github.com/kbss-cvut/owl2query - it is pretty dormant at present, but will try to look around for some other solutions and propose something here if any. |
Given the following input:
the presence of triple
oboInOwl:hasDbXref a owl:AnnotationProperty .
(T1) does affect the result of a simple query:With T1 in, the query
robot query -i input.ttl -u query.rq -o output.ttl
evaluation materializes the reified axiom as :Without T1, the query evaluation removes the related synonym.
I consider this behaviour inconsistent. Would expect the query to behave the same no matter whether hasDbXref is marked explicitely as AnnotationProperty or not.
The text was updated successfully, but these errors were encountered: