How to Add Concept of Active/Inactive to SPIN Rules?

Question

I'm using TopBraid Composer Free Edition to compose ontologies and SPIN rules. I'm loading my ontologies into Sesame OpenRDF Workbench using an RDF file saved from TopBraid Composer Free Edition.

I have an application for SPIN rules (more precisely, SPIN constructors) which is dynamic in terms of which of hundreds of rules should apply. I would like to find a way to add a concept of "active" or "inactive" to SPIN rules. I'm willing to add a check to each rule in the WHERE clause so that only "active" rules. To illustrate, suppose that I create two sub-properties of SPIN:constructor, call them myPrefix:activeConstructor and myPrefix:inactiveConstuctor.

Now I want to add to the WHERE clause of my constructors a triple of the form:

?thisConstructorURI a myPrefix:activeConstructor .

This approach hinges on defining ?thisConstuctorURI. SPIN sets ?this to the current instance of the class associated with the rule. Is there something similar for the URI of the rule itslef.

I also believe that at present, the rules reside at blank nodes. For example, the constructors for my sxxicc:Pub7Proposal class have the following triples for 13 constructors as viewed in Sesame/OpenRDF Workbench:

SUBJECT              PREDICATE           OBJECT
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox14591
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox14638
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox14710
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox14787
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox14841
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox14927
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox15002
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox15088
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox15114
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox15195
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox15257
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox15336
sxxicc:Pub7Proposal  spin:constructor    _:node1anlqmpiox15377

What I really need (I think) is

1. rules to be able to reference themselves (my ?thisConstructorURI idea)
2. to be able to name rules when I write them (e.g. sxxicci:Pub7ProposalSecurityClassificationConsistencyCheck)

This is all so that I can activate/deactivate the rules one-by-one (or by simple extension in arbitrary named groups). Any ideas on how to do this?

Satisfying 1. above is similar to the spin:violationSource already supported for constraints which can be included in a spin:ConstraintViolation. However, I'm quite deliberately using constructors instead of constraints primarily because I do not want to block instantiation of a class even if it has violations.

I'm afraid the answer is that the current SPIN standard and implementations do not support this and that it would require altering the supporting implementation to extend the standard to do this.

Answer 1

I've confirmed one awkward way to activate/deactivate my constructors. Note that I'm using the following subproperty structure:

spin:constructor
  sxxicc:sxxiPub7ComplianceCheckRule
    sxxicc:activeSxxiPub7ComplianceCheckRule

I create the following conststructor as a sxxicc:sxxiPub7ComplianceCheckRule:

# THE MAJOR FUNCTION IDENTIFIER IS INVALID. (511 02)
CONSTRUCT {
    ?this sxxicc:pub7ProposalHasComplianceMessage "THE MAJOR FUNCTION IDENTIFIER IS INVALID. (511 02)"^^xsd:string .
}
WHERE {
    ?this a sxxicc:Pub7Proposal .
    ?this sxxicc:pub7ProposalHasDataItem ?dataItem511 .
    sxxicc:Pub7Proposal sxxicc:activeSxxiPub7ComplianceCheckRule ?thisRule .
    ?thisRule rdfs:comment "THE MAJOR FUNCTION IDENTIFIER IS INVALID. (511 02)"^^xsd:string .
    ?dataItem511 a sxxicc:Pub7DataItem511 .
    ?dataItem511 sxxicc:pub7DataItemHasStringValue ?majorFunctionID .
    ?this sxxicc:pub7ProposalHasDataItem ?dataItem102 .
    ?dataItem102 a sxxicc:Pub7DataItem102 .
    ?dataItem102 sxxicc:pub7DataItemHasStringValue ?serialNumString .
    BIND (SUBSTR(?serialNumString, 1, 4) AS ?orgString) .
    FILTER (((((?orgString = SUBSTR("AF  X"^^xsd:string, 1, 4)) || (?orgString = SUBSTR("AR  X"^^xsd:string, 1, 4))) || (?orgString = SUBSTR("N   X"^^xsd:string, 1, 4))) || (?orgString = SUBSTR("NS  X"^^xsd:string, 1, 4))) || (?orgString = SUBSTR("MC  X"^^xsd:string, 1, 4))) .
    FILTER (!(((((((((((?majorFunctionID = "AIR OPERATIONS") || (?majorFunctionID = "GROUND OPERATIONS")) || (?majorFunctionID = "SEA OPERATIONS")) || (?majorFunctionID = "SPACE OPERATIONS")) || (?majorFunctionID = "RANGE OPERATIONS")) || (?majorFunctionID = "SURVEILLANCE/RECONNAISSANCE")) || (?majorFunctionID = "SPECIAL OPERATIONS")) || (?majorFunctionID = "C3")) || (?majorFunctionID = "SUSTAINING OPERATIONS")) || (?majorFunctionID = "DOMESTIC SUPPORT OPERATIONS")) || (?majorFunctionID = "OTHER OPERATIONS"))) .
}

The most relevant lines of this query for activation are:

sxxicc:Pub7Proposal sxxicc:activeSxxiPub7ComplianceCheckRule ?thisRule .
?thisRule rdfs:comment "THE MAJOR FUNCTION IDENTIFIER IS INVALID. (511 02)"^^xsd:string .

By default, this rule cannot produce its error message since it has the superproperty but not the active subproperty. I confirmed this by asserting a sxxicc:Pub7Proposal with dataItem511 set to "Sight Seeing" (not a valid major function identifier). This constructor did not produce its error message.

I then ran the following SPARQL Update query from the OpenRDF Workbench "Modify/SPARQL Update" to change this constructor to "active":

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX sxxicc: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheck#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX sp: <http://spinrdf.org/sp#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX smf: <http://topbraid.org/sparqlmotionfunctions#>
PREFIX fn: <http://www.w3.org/2005/xpath-functions#>
PREFIX spl: <http://spinrdf.org/spl#>
PREFIX spin: <http://spinrdf.org/spin#>
PREFIX arg: <http://spinrdf.org/arg#>
PREFIX SXXIComplianceCheckIndividuals: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheckIndividuals#>
PREFIX sxxicci: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheckIndividuals#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX bugs: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/BugReproduction#>
PREFIX BugReproduction: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/BugReproduction#>
PREFIX bugsi: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/BugReproductionInstantiations#>
PREFIX BugReproductionInstantiations: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/BugReproductionInstantiations#>

INSERT {
    sxxicc:Pub7Proposal sxxicc:activeSxxiPub7ComplianceCheckRule ?thisRule .
}
WHERE {
    sxxicc:Pub7Proposal sxxicc:sxxiPub7ComplianceCheckRule ?thisRule .
    ?thisRule rdfs:comment "THE MAJOR FUNCTION IDENTIFIER IS INVALID. (511 02)"^^xsd:string .
}

I asserted another identical sxxicc:Pub7Proposal (different IRI), and this rule did indeed complain that "Sight Seeing" is not a valid major function identifier, as expected.

Note that a query of the same form but with a DELETE clause replacing the above INSERT clause (identical triple) could dynamically inactive the constructor. More precisely, it would prevent the error message from being generated again.

This is an inefficient way to accomplish dynamic activating and deactivating of constructors. I'm doing a lot of work go get around the blank nodes that anchor the constructors. I'm using the rule's comment to assure uniqueness, and I'm using my own subproperty to constrain the scope of a rule's search for itself. I'd love to have a better way to dynamically activate/deactivate constructor rules without loading/unloading them entirely. It would be great if the rule engine itself understood the concept of "active" so that "inactive" rules would not needlessly run only to find that they are inactive.