Results for SPARQLConstraint constraints ignore their defined severity level and result always in violations

[costas80]

Using v1.4.4.

When validating against shapes that include SPARQLConstraint constraints, it seems that their defined severity level is ignored. The corresponding results in the report always have violation severity.

To replicate, consider input.ttl as follows ...

@prefix ns0: <http://www.w3.org/ns/locn#> .
@prefix ns1: <http://itb.ec.europa.eu/sample/po#> .

<http://my.sample.po/po#purchaseOrder>
  a <http://itb.ec.europa.eu/sample/po#PurchaseOrder> ;
  ns1:shipTo <http://my.sample.po/po#home> ;
  ns1:billTo <http://my.sample.po/po#home> ;
  ns1:hasItem <http://my.sample.po/po#item1>;
  ns1:hasItem  <http://my.sample.po/po#item2> .

<http://my.sample.po/po#home>
  a <http://www.w3.org/ns/locn#Address> ;
  ns0:fullAddress "Rue du Test 123, 1000 - Brussels, Belgium" ;
  ns0:thoroughfare "Rue du Test" ;
  ns0:locatorDesignator "123" ;
  ns0:postCode "1000" ;
  ns0:postName "Brussels" ;
  ns0:adminUnitL1 "BE" .

<http://my.sample.po/po#item1>
  a ns1:Item ;
  ns1:productName "Mouse" ;
  ns1:quantity 20 ;
  ns1:priceEUR 15.99 .

<http://my.sample.po/po#item2>
  a ns1:Item ;
  ns1:productName "Keyboard" ;
  ns1:quantity 5 ;
  ns1:priceEUR 25.50 .

... and shapes.ttl defining a SPARQL constraint as follows:

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ns1: <http://itb.ec.europa.eu/sample/po#> .
@prefix ex: <http://example.org/shapes#> .

ex:PurchaseOrderShape
    a sh:NodeShape ;
    sh:targetClass ns1:PurchaseOrder ;
    sh:sparql ex:SameBillingAndShippingWarning .

ex:SameBillingAndShippingWarning
    a sh:SPARQLConstraint ;
    sh:severity sh:Warning ;
    sh:message "PurchaseOrder {$this} has the same billing and shipping address ({?address}). This may be intentional but should be verified."@en ;
    sh:prefixes ex:, ns1: ;
    sh:select """
        PREFIX ns1: <http://itb.ec.europa.eu/sample/po#>
        SELECT $this ?address
        WHERE {
            $this ns1:shipTo ?address .
            $this ns1:billTo ?address .
        }
    """ .

Validating using shaclvalidate.bat -datafile input.ttl -shapesfile shapes.ttl produces the following report:

PREFIX dash:    <http://datashapes.org/dash#>
PREFIX ex:      <http://example.org/shapes#>
PREFIX graphql: <http://datashapes.org/graphql#>
PREFIX ns0:     <http://www.w3.org/ns/locn#>
PREFIX ns1:     <http://itb.ec.europa.eu/sample/po#>
PREFIX owl:     <http://www.w3.org/2002/07/owl#>
PREFIX rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs:    <http://www.w3.org/2000/01/rdf-schema#>
PREFIX sh:      <http://www.w3.org/ns/shacl#>
PREFIX swa:     <http://topbraid.org/swa#>
PREFIX tosh:    <http://topbraid.org/tosh#>
PREFIX xsd:     <http://www.w3.org/2001/XMLSchema#>

[ rdf:type     sh:ValidationReport;
  sh:conforms  false;
  sh:result    [ rdf:type                      sh:ValidationResult;
                 sh:focusNode                  <http://my.sample.po/po#purchaseOrder>;
                 sh:resultMessage              "PurchaseOrder <http://my.sample.po/po#purchaseOrder> has the same billing and shipping address (<http://my.sample.po/po#home>). This may be intentional but should be verified."@en;
                 sh:resultSeverity             sh:Violation;
                 sh:sourceConstraint           ex:SameBillingAndShippingWarning;
                 sh:sourceConstraintComponent  sh:SPARQLConstraintComponent;
                 sh:sourceShape                ex:PurchaseOrderShape;
                 sh:value                      <http://my.sample.po/po#purchaseOrder>
               ]
] .

The reported severity of the result should be sh:Warning as opposed to sh:Violation (and as a result, sh:conforms should be true).

[afs]

Is this issue specific to sh:SPARQLConstraint constraints?

[afs]

(and as a result, sh:conforms should be true).

In SHACL 1.0, this seems to be covered by

The value of sh:conforms is true if and only if the validation did not produce any validation results, and false otherwise.

In SHACL12, there is some control of this: https://www.w3.org/TR/shacl12-core/#conformanceDisallows

[costas80]

Is this issue specific to sh:SPARQLConstraint constraints?

Yes, from what I've seen up to now other constraints' severity is respected when producing the results. The first time this came up was for sh:SPARQLConstraint.

[afs]

jena-shacl does the same (sh:resultSeverity sh:Violation)

It is because sh:severity is on shape. ex:SameBillingAndShippingWarning is not a shape -it's a constraint - so the triple isn't seen.

[costas80]

From what I understand it is not illegal to use sh:severity with constraints (unless I'm missing something).

What I did on my end was to post-process the SHACL validation report and check whether results correspond to sh:SPARQLConstraint constraints. If yes then I fetch their severity (if present) from the shapes graph and apply that in the report.

[afs]

The domain of sh:severity is sh:Shape in SHACL 1.0.

In SHACL 1.2 the section is now "3.1.4 Declaring the Severity of a Shape or Constraint" which allows sh:severity on a constraint.

IIUC, the annotation is on the triple with the property for the constraint: sh:sparql, not in the constraint (object of the triple).

ex:PurchaseOrderShape
    a sh:NodeShape ;
    sh:targetClass ns1:PurchaseOrder ;
    sh:sparql ex:SameBillingAndShippingWarning {| sh:severity sh:Warning |} 
    .