SHACL sh:rule with sh:condition in SPARQL in Topbraid Composer

[olidru]

The example ontology has two classes (:MyClass and :Value) and two properties (:MyObjProp and :MyDataProp).

:MyClass

  a owl:Class ;

  a sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;

.

:MyDataProp

  a owl:DatatypeProperty ;

  rdfs:domain :MyClass ;

  rdfs:range xsd:string ;

.

:MyObjProp

  a owl:ObjectProperty ;

  rdfs:domain :MyClass ;

  rdfs:range :Value ;

.

:Value

  a owl:Class ;

  rdfs:subClassOf owl:Thing ; .

Some instances were added.

:MyClass_1

  a :MyClass ;

  :MyDataProp :Value_1 ;

  :MyObjProp :Value_1 ; .

  :MyClass_2 a :MyClass ;

  :MyObjProp :Value_2 ;

.

:Value_1

  a :Value ;

.

:Value_2

  a :Value ;

.

A NodeShape :NodeShapeRule with a sh:rule (:SPARQLRule_1) was created. This rule creates new triples. With the sh:condition the rule should be restricted to a subset of targets.

:NodeShapeRule

  a sh:NodeShape ;

  sh:rule :SPARQLRule_1 ;

  sh:targetClass :MyClass ;

.

:SPARQLRule_1

  a sh:SPARQLRule ;

  sh:condition :NodeShapeConditionSPARQL ;

  sh:construct """

     PREFIX : <http://example.org/ex#>

     CONSTRUCT {

        $this :MyDataProp \"New input\" .

     }

     WHERE {

        $this :MyObjProp ?p .

     }

  """ ;

.

For the restriction two equivalent NodeShapes were defined. The first constraint works with sh:property, the other uses sh:sparql.

:NodeShapeConditionProperty

  a sh:NodeShape ;

  sh:property [

    sh:path :MyObjProp ;

    sh:description "NodeShapeConditionProperty" ;

    sh:hasValue :Value_1 ;

  ] ;

  sh:targetClass :MyClass ;

.

:NodeShapeConditionSPARQL

  a sh:NodeShape ;

  sh:sparql [

    sh:message "NodeShapeConditionSPARQL" ;

    sh:prefixes <http://example.org/ex> ;

    sh:select """

      PREFIX : <http://example.org/ex#>

      SELECT $this

      WHERE {

        $this :MyObjProp ?prop .

      }

    """ ;

  ] ;

  sh:targetClass :MyClass ;

.

While doing inferencing with Topbraid Composer I received different results for both solutions. Only the solution with sh:property provides the expected response. Please, can anyone explain me this behavior?

:MyClass_1 :MyDataProp "New input"

[Holger Knublauch]

Thanks for sending the details in a minimal executable format. Made it much easier to play around.

The issue is that the sh:condition must apply to the focus node(s), which means that before a rule is applied, the focus node must not violate any constraints from the node shape that is the sh:condition. In your example, the sh:sparql constraint will be violated, because

      PREFIX : <http://example.org/ex#>

      SELECT $this

      WHERE {

        $this :MyObjProp ?prop .

      }

in SHACL means that it will produce a constraint violation for each result in the SELECT query. In your example data, it would produce one violation for each value of MyObjProp, of which there are plenty.

Maybe you meant to say WHERE { FILTER NOT EXISTS { $this :MyObjProp ?anyProp } } instead, to check that the focus node has *no* value for that property?

HTH
Holger

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/09c459dd-d5e5-4e58-9a5a-a16b53c24605n%40googlegroups.com.

[olidru]

Thanks for you quick reply. The result of my SPARQL query describes the violation. So, with your proposal the not existing part of the triples is declared as violation.

What makes me wonder is that in opposite the expressions in sh:property doesn’t describe the violation. What’s the reason for this different understanding?

Many thanks for your help!

Oliver

[Holger Knublauch]

On 2021-12-20 10:22 pm, olidru wrote:

Thanks for you quick reply. The result of my SPARQL query describes the violation. So, with your proposal the not existing part of the triples is declared as violation.

What makes me wonder is that in opposite the expressions in sh:property doesn’t describe the violation. What’s the reason for this different understanding?

In all cases, the sh:condition shape describes the constraints that the target nodes must fulfill. In the case of property constraints this is quite intuitive, so if you say sh:hasValue :Value_1 then it will only apply to nodes where that property has the given value. With SHACL-SPARQL constraints, you formulate the constraints in a way that may be confusing at first, because you have to state the patterns that are *not* supposed to exist. So if the SPARQL query returns no result (rows) then all is fine and the rule will fire. The reason for this design is that this enables SPARQL queries to return more information about the violation, e.g. the focus node (?this) and the value node (?value).

Is this clearer now?

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9240a044-bfd4-4459-bc8d-6b3f83172480n%40googlegroups.com.

[olidru]

Thank you very much. Now it's clear to me and I'm one step further.

Oliver