-
Notifications
You must be signed in to change notification settings - Fork 29
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
Inconsistent behaviour with OWL reasoning #178
Comments
FWIW, GraphDB 10.0.2 does exactly the same. Digging into this, I realize that the |
Yes that's the point.
In addition literals have no property and hence no rdf:type property.
So we would have to hack the sparql interpreter for the case ?literal rdf:type owl:Thing
I do not see an elegant solution for this issue.
… De: "Pierre-Antoine Champin" ***@***.***>
À: "Wimmics" ***@***.***>
Cc: "Subscribed" ***@***.***>
Envoyé: Jeudi 21 Mars 2024 11:43:08
Objet: Re: [Wimmics/corese] Inconsistent behaviour with OWL reasoning (Issue
#178)
FWIW, GraphDB 10.0.2 does exactly the same.
Digging into this, I realize that the "type" results are probably inferred via
rule [ https://www.w3.org/TR/owl2-profiles/#cls-svf2 | cls-svf2 ] , while there
is no rule to infer the "path" result for :i2 .
Note that the rules provided in [
https://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules
| OWL 2 Profiles §4.3 ] are explicitly a partial axiomatization, so it is not
entirely surprising that those rules do not produce complete results.
—
Reply to this email directly, [
#178 (comment) | view it
on GitHub ] , or [
https://github.com/notifications/unsubscribe-auth/ABKXNJGIUXONXNV2X32OAHDYZK2TZAVCNFSM6AAAAABFAGQKZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJRHEYDANRVGI
| unsubscribe ] .
You are receiving this because you are subscribed to this thread. Message ID:
***@***.***>
|
A solution that I can see (I leave it to you to decide whether it is elegant or not 😉), would be to implement the rdfD1 rule suggested in RDF seamntics. In SPARQL CONSTRUCT, it would look like that: CONSTRUCT { ?s ?p [ a ?d ] }
WHERE {
?s ?p ?o.
BIND (datatype(?o) as ?d)
FILTER (?d in (
# here, a list of supported datatypes
))
} but granted, it creates a proliferation of blank nodes... |
interesting suggestion indeed to use the semantics of blank nodes as in "there is a node but I can't identify it" |
Elegant but not sustainable :-)
-------- Message d'origine --------De : Pierre-Antoine Champin ***@***.***> Date : 27/03/2024 09:10 (GMT+01:00) À : Wimmics/corese ***@***.***> Cc : ocorby ***@***.***>, Comment ***@***.***> Objet : Re: [Wimmics/corese] Inconsistent behaviour with OWL reasoning (Issue #178)
A solution that I can see (I leave it to you to decide whether it is elegant or not 😉), would be to implement the rdfD1 rule suggested in RDF seamntics. In SPARQL CONSTRUCT, it would look like that:
CONSTRUCT { ?s ?p [ a ?d ] }
WHERE {
?s ?p ?o.
BIND (datatype(?o) as ?d)
FILTER (?d in (
# here, a list of supported datatypes
))
}
but granted, it creates a proliferation of blank nodes...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
@FabienGandon about that, you might be interested in a recent finding by the RDF-star WG: an inference rule was missing from the RDFS rules to make them complete, involving the use of blank node for denoting literals: w3c/rdf-semantics#45 |
I agree, unfortunately 😅 . I'll close this issue then. |
Issue Description:
Two different ways to ask the same question in SPARQL give different results.
Steps to Reproduce:
Enable OWL RL reasoning.
Run the following query:
Expected Behavior:
You would expect that the two parts of the union give exactly the same results under OWL entailment,
since the second part (
"path"
part) corresponds to the definition of the class in the first part ("type"
part).Actual Behavior:
Corese 4.5.0 gives the following results:
:i2
is recognized as an instance ofHasPThing
, even though it is not recognized to have a value for:p
of typeowl:Thing
in the 2nd part of the query.The text was updated successfully, but these errors were encountered: