Skip to content
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

Closed
pchampin opened this issue Mar 20, 2024 · 7 comments
Closed

Inconsistent behaviour with OWL reasoning #178

pchampin opened this issue Mar 20, 2024 · 7 comments

Comments

@pchampin
Copy link
Contributor

Issue Description:

Two different ways to ask the same question in SPARQL give different results.

Steps to Reproduce:

  1. Load the following data:
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <https://example.org/> .

:HasPThing a owl:Restriction ;
  owl:onProperty :p ;
  owl:someValuesFrom owl:Thing ;
.

:i1 :p :i1.
:i2 :p "foo".
  1. Enable OWL RL reasoning.

  2. Run the following query:

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX : <https://example.org/>

SELECT * {
  { ?i a :HasPThing.        BIND("type" as ?d) }
  UNION
  {  ?i :p [ a owl:Thing ]. BIND("path" as ?d) }
}

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:

<https://example.org/i1>	type
<https://example.org/i2>	type
<https://example.org/i1>	path

:i2 is recognized as an instance of HasPThing, even though it is not recognized to have a value for :p of type owl:Thing in the 2nd part of the query.

@pchampin
Copy link
Contributor Author

FWIW, GraphDB 10.0.2 does exactly the same.

Digging into this, I realize that the "type" results are probably inferred via rule cls-svf2, while there is no rule to infer the "path" result for :i2.
Note that the rules provided in OWL 2 Profiles §4.3 are explicitly a partial axiomatization, so it is not entirely surprising that those rules do not produce complete results.

@ocorby
Copy link
Contributor

ocorby commented Mar 21, 2024 via email

@pchampin
Copy link
Contributor Author

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...

@FabienGandon
Copy link
Collaborator

interesting suggestion indeed to use the semantics of blank nodes as in "there is a node but I can't identify it"

@ocorby
Copy link
Contributor

ocorby commented Mar 27, 2024 via email

@pchampin
Copy link
Contributor Author

interesting suggestion indeed to use the semantics of blank nodes as in "there is a node but I can't identify it"

@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

@pchampin
Copy link
Contributor Author

Elegant but not sustainable :-)

I agree, unfortunately 😅 . I'll close this issue then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants