TopBraid 4.3 introduces a small Event-Condition-Action (ECA) rule engine that can be used to trigger rules whenever a change was performed on an EVN vocabulary or ontology. Example use cases of this feature include anything that needs to happen as a side effect of edit operations: updating an external index (such as Solr), creating automatically generated triples, aligning inverse properties, sending automated notifications to co-workers etc.
Let me introduce this feature with an example rule definition. The rule below inserts an rdfs:comment whenever a new owl:DatatypeProperty has been created by someone.
As shown above, these ECA rules are essentially SWP elements that define their behavior is their ui:prototype. To create your own rule, simply create a globally registered .ui.* file that imports the teamworkrules system ontology, and then create a subclass of teamwork:EditRules. The rule engine of EVN will execute the ui:prototype of any globally registered edit rule after each edit. During the execution of those prototypes, there are two dedicated named graphs with a special meaning: The graph ui:addedGraph will contain the newly added triples, and ui:deletedGraph will contain those triples that have just been deleted. For example, if someone has pressed Save Changes on an EVN form, replacing one skos:altLabel with another, then the ui:addedGraph will contain the new value, and ui:deletedGraph will contain the old value. You can use SPARQL to query those change triples and perform side effects with ui:update or SPARQLMotion modules.
EVN uses this rule engine out of the box to update a Solr index after each edit (if Solr has been activated for the current project). The implementation of this Solr updater rule is shown below.
As this blog may be out of date when you read it, you can find the current implementation of this rule in the file teamworkrules.ui.ttlx. Note that this rule has a guard clause in the first ui:if statement, to make sure that the rule only fires for the master graph, i.e. the tag/working copy must be unbound. If this condition is true, then a helper SPIN template is called that will deliver all subjects that have been mentioned in the current change:
It is possible to distinguish between normal edit operations (teamwork:EditRule) and commit operations, in which a working copy has been merged into the master copy of an EVN project (teamwork:CommitRule).
