Wie Konzept der aktiven/inaktiv zu SPIN-Regeln hinzufügen?

Question

Ich verwende TopBraid Composer Free Edition, um Ontologien und SPIN-Regeln zu erstellen. Ich lade meine Ontologien in Sesame OpenRDF Workbench mit einer RDF-Datei, die von TopBraid Composer Free Edition gespeichert wurde.

Ich habe eine Anwendung für SPIN-Regeln (genauer gesagt, SPIN-Konstruktoren), die in Bezug auf welche von Hunderten von Regeln dynamisch ist. Ich würde gerne einen Weg finden, SPIN-Regeln ein Konzept von "aktiv" oder "inaktiv" hinzuzufügen. Ich bin bereit, eine Regel zu jeder Regel in der WHERE Klausel hinzuzufügen, so dass nur "aktive" Regeln. Um zu veranschaulichen, nehme ich an, dass ich zwei Untereigenschaften von SPIN erstelle: Konstruktor, rufe sie myPrefix:activeConstructor und myPrefix:inactiveConstuctor.

Jetzt möchte ich eine dreifache des Formulars auf der WHERE-Klausel meiner Konstrukteure hinzuzufügen:

?thisConstructorURI a myPrefix:activeConstructor . 

Dieser Ansatz hängt ?thisConstuctorURI auf definieren. SPIN setzt ?this auf die aktuelle Instanz der Klasse, die der Regel zugeordnet ist. Gibt es etwas ähnliches für die URI der Regel itslef.

Ich glaube auch, dass derzeit die Regeln auf leere Knoten liegen. Zum Beispiel können die Konstrukteure für meine sxxicc: Pub7Proposal Klasse haben folgende Tripel für 13 Konstrukteuren wie in Sesame/OpenRDF Workbench angesehen:

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 

Was wirklich brauche ich (glaube ich) ist

1. Regeln der Lage sein, sich (meine ?thisConstructorURI Idee) zu verweisen
2. der Lage sein, Regeln zu nennen, wenn ich sie schreiben (zB sxxicci:Pub7ProposalSecurityClassificationConsistencyCheck)

Das ist alles, damit ich die Regeln einzeln (oder durch einfache Erweiterung in beliebigen benannten Gruppen) aktivieren/deaktivieren kann. Irgendwelche Ideen, wie man das macht?

Erfüllen 1. oben ist ähnlich dem spin:violationSource bereits für Einschränkungen unterstützt, die in einem spin:ConstraintViolation enthalten sein können. Allerdings verwende ich ganz bewusst Konstruktoren anstelle von Constraints, hauptsächlich weil ich die Instantiierung einer Klasse nicht blockieren möchte, selbst wenn sie Verletzungen aufweist.

Ich fürchte, die Antwort ist, dass der aktuelle SPIN-Standard und Implementierungen dies nicht unterstützen und dass es erforderlich wäre, die unterstützende Implementierung zu ändern, um den Standard dafür zu erweitern.

Answer 1

Ich habe eine unangenehme Möglichkeit bestätigt, meine Konstruktoren zu aktivieren/deaktivieren. Beachten Sie, dass ich mit dem folgenden subproperty Struktur:

spin:constructor 
    sxxicc:sxxiPub7ComplianceCheckRule 
    sxxicc:activeSxxiPub7ComplianceCheckRule 

ich erstellen Sie die folgende conststructor als 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"))) . 
} 

Die wichtigsten Linien dieser Abfrage für die Aktivierung sind:

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

Diese Regel kann standardmäßig keine Fehlermeldung ausgeben, da sie die Supereigenschaft, aber nicht die aktive Untereigenschaft besitzt.Ich bestätigte dies, indem ich eine sxxicc:Pub7Proposal mit dataItem511 auf "Sight Seeing" (keine gültige Hauptfunktionskennung) gesetzt. Dieser Konstruktor hat seine Fehlermeldung nicht erzeugt.

Ich lief dann die folgende SPARQL Aktualisierungsabfrage aus dem OpenRDF Workbench „Ändern/SPARQL Update“ diesen Konstruktor zu ändern „aktiv“:

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

behauptete ich eine andere identisch sxxicc:Pub7Proposal (verschiedene IRI), und dies Regel beklagte sich tatsächlich, dass "Sight Seeing" wie erwartet keine gültige Hauptfunktionskennung ist.

Beachten Sie, dass eine Abfrage der gleichen Form, aber mit einer DELETE Klausel ersetzen die obige INSERT Klausel (identische dreifache) konnte den Konstruktor inaktivieren. Genauer gesagt würde es verhindern, dass die Fehlermeldung erneut erzeugt wird.

Dies ist eine ineffiziente Methode zum dynamischen Aktivieren und Deaktivieren von Konstruktoren. Ich mache eine Menge Arbeit, um die leeren Knoten zu umgehen, die die Konstruktoren verankern. Ich verwende den Kommentar der Regel, um die Eindeutigkeit sicherzustellen, und ich benutze meine eigene Untereigenschaft, um den Geltungsbereich der Suche einer Regel auf sich selbst einzuschränken. Ich hätte gerne eine bessere Möglichkeit, Konstruktorregeln dynamisch zu aktivieren/deaktivieren, ohne sie vollständig zu laden/zu entladen. Es wäre großartig, wenn die Regel-Engine selbst das Konzept von "aktiv" verstehen würde, so dass "inaktive" Regeln nicht unnötig laufen würden, nur um festzustellen, dass sie inaktiv sind.