Inconsistent behaviour with OWL reasoning

[pchampin]

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

2. Enable OWL RL reasoning.

3. Run the following query:
```sparql
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]

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]

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, [ https://github.com/Wimmics/corese/issues/178#issuecomment-2011900652 | 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: @.***>

[pchampin]

A solution that I can see (I leave it to you to decide whether it is elegant or not :wink:), 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]

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

[ocorby]

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: @.***>

[pchampin]

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]

Elegant but not sustainable :-)

I agree, unfortunately :sweat_smile: . I'll close this issue then.