SPIN constraint using CONSTRUCT: where do the CONSTRUCT's triples go?

Question

I'm using TopBraid Composer Free Edition (5.1.3) to create ontologies including SPIN constraints. I then load the resulting RDF files into RDF4J (2.0.1) and use RDF4J Workbench for testing.

I'm working on SPIN constraints. Here's an example to check for non-negative signal rates that I've added to the CRO2:SignalRate class:

CONSTRUCT {
  ?this soo:hasConstraintViolation _:b0 .
  _:b0 a spin:ConstraintViolation .
  _:b0 rdfs:label "Non-Positive SignalRate" .
  _:b0 spin:violationRoot ?this .
  _:b0 spin:violationPath Nuvio:hasDataValue .
  _:b0 spin:violationLevel spin:Warning .
}
WHERE {
    ?this Nuvio:hasDataValue ?signalRate .
    FILTER (?signalRate <= 0.0) .
}

So, I'm testing this constraint in RDF4J workbench using the following SPARQL update query:

PREFIX inst: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Sharing/Instantiations#>
PREFIX Nuvio: <http://cogradio.org/ont/Nuvio.owl#>
PREFIX CRO2: <http://cogradio.org/ont/CRO2.owl#>

INSERT DATA {
  inst:aSignalRate_test a CRO2:SignalRate ;
    Nuvio:hasDataValue "-10"^^xsd:long .
}

This test instant violates the constraint shown above. If I omit the spin:violationLevel triple and allow this to default to a spin:Error, then I get an error message from the query and the test instance is not asserted, as expected. When executed as shown, the constraint violation is a spin:Warning, so the inst:aSignalRate_test individual is created with data value -10.0. My question is, where do the assertions in the constraint's CONSTRUCT clause go? I believe they're being asserted since the change in the spin:violationLevel impacts behavior. Note that I've tried to tie into the blank node with my own soo:hasConstraintViolation property, but this doesn't work. Are the CONSTRUCT triples asserted in some other context/graph? I'm just using the default/graph for everything.

I'm looking for the expected triples both using RDF4J Workbench's Explore and using SPARQL queries. For example, the following query returns nothing after I assert my errant CRO2:SignalRate:

PREFIX spin: <http://spinrdf.org/spin#>

SELECT DISTINCT *
WHERE {
    ?s spin:violationRoot ?o .
}

This behavior is consistent between asserting in TopBraid Composer FE and RDF4J Workbench.

My goal is to find and use the diagnostic messages asserted in case of SPIN constraint violations, preferably by using SPARQL queries to find such diagnostics. Seems reasonable. I'm missing something.

Thanks.

Answer 1

The short answer: you can't.

SPIN constraints are intended to detect violations and report them. In RDF4J, that reporting mechanism is the log.

The relevant part of the SPIN spec (http://spinrdf.org/spin.html#spin-constraints) :

[...] if an ASK constraint evaluates to true for one instance, then the instance violates the condition. Optionally, CONSTRUCT queries can create instances of a spin:ConstraintViolation class that provide details on a specific violation.

Note that there is no requirement on the reasoner to do anything with the data that a CONSTRUCT-based constraint produces - it's merely for optional "additional information".

It's perhaps worth seeing if we could add an enhancement to the reasoner to report such triples back in one form or another, but in the current system, only SPIN rules (using DELETE/INSERT etc) modify the database.

Answer 2

So, following @JeenBroekstra comments and my response comment above, I've switched to using constuctors so that the error information remains as visible artifacts. I've created several of my own subproperties of the spin:constructor in order to keep things ordered. I've also specified the execution order of these constructors so that these checks run ahead of other rules that might be tripped up (e.g. by a negative signal rate).

Advantages of this approach:

• The error detail artifacts (e.g. spin:violationRoot) remain visible in the triple store. This is very important in my application which involves machine-to-machine.
• All the compliance checks are done, so an individual with multiple problems lists all problems as separate hasConstraintViolation properties, not just the first violation to block instantiation.

Disadvantages of this approach:

• The errant individual is still instantiated.
• This is not standard behavior, so tools geared to look for constraint artifacts in the logs probably won't find them.

Here's a screen shot of an example rule implemented as a subproperty of spin:constructor: