Ontology Manager is a web service that connects with an Ontology Service to update the domain model based on event notifications.
Ontology Manager provides all of its services through the web service interface outlined in Table 3.2. The service interface enables remote software actors to interact with Ontology Manager. In addition, Ontology Manager includes a graphical user interface (GUI) for direct user interaction. The GUI is particularly useful for creating update rules and is accessible through the Ontology Manager host computer.
To receive event notifications from domain web services, Ontology Manager must subscribe to them. To this end, the Ontology Manager web service interface includes the ScanNetwork operation. Invoking the operation causes Ontology Manager to discover all available web services using the Web Services Dynamic Discovery (WS- Discovery) [68] protocol. After discovering a service, Ontology Manager subscribes to receive all event notifications from it using the Web Services Eventing (WS- Eventing) [119] protocol. The ScanNetwork operation can also be invoked through the GUI menu bar.
Whenever Ontology Manager receives an event notification, it consults a set of update rules to determine the appropriate update request to send to Ontology Ser- vice. An update rule essentially consists of a set of conditions and a set of effects to be applied when the conditions match an incoming event notification. Ontology Manager compares the conditions directly to the received event notification, and if they match, applies the effects by invoking the Ontology Service ExecuteUpdate- WithMapping operation.
3. Methods 50
Figure 3.6: The conditions in Ontology Manager update rules directly refer to notification message contents.
notification operation action URI and the conditions on notification message content. The latter conditions are a list of pairs formed by an XPath [10] expression and a string value. The XPath expression identifies an XML element or element attribute in a notification message, and the string value specifies the required text content of the element or the attribute value.
The update rule effects are a list of SPARQL/Update expression templates. The templates may also contain keywords indicated by enclosing them within ’#$’ and ’$#’. The keywords must be XML element names. Before sending the update ex- pressions to Ontology Service, Ontology Manager will replace each keyword with the text content of the corresponding XML element in the received notification message, so that the templates are expanded into valid SPARQL/Update expressions. In ad- dition, update rules may contain variables. Each variable has the same name as some SPARQL query variable occurring in the update expressions and an XSLT [9] script that extracts the variable value from the received notification message. The variable value mapping will then be included in the request message when Ontology Manager invokes the ExecuteUpdateWithMapping operation. Figure 3.6 illustrates the update rule structure.
The update rule conditions refer directly to the XML structure of the notifica- tion messages. Hence, they require stable service interfaces. In particular, if the XML Schema structure of a notification message is altered, the update rules refer- ring to that notification will most probably cease to function as intended. There- fore, an alternative update rule type called semantic update rules was proposed in [83]. However, such an approach would require difficult rules on applying semantic annotations and compromise the complete independence of the Ontology Manager
3. Methods 51
Figure 3.7: Rule conditions in the abandoned semantic update rule approach referred to OWL models through SPARQL expressions.
approach from the service descriptions. Moreover, the only benefit of the alternative approach, the ability to apply the same update rules regardless of modifications to the service interface, would be merely artificial as it would only shift the effort into the development of the service descriptions. Therefore, the alternative approach has been abandoned in the current version of Ontology Manager, and any XSLT transformation scripts must now be specified in the rules themselves as described above.
Semantic update rules differ from the conventional update rules in that their con- ditions do not refer directly to the notification message XML contents, but to an OWL model generated from the message by applying an XSLT script. The XSLT script must be referenced by the corresponding WSDL message part through an SAWSDL (Semantic Annotations for WSDL and XML Schema) [20] liftingSchemaMap- ping annotation. The condition list of a semantic update rule is a list of SPARQL ASK type queries to be evaluated against the OWL model resulting from the trans- formation. Ontology Manager would evaluate the condition expressions to determine if a rule matches. Figure 3.7 illustrates the structure of semantic update rules.
Whenever Ontology Manager receives an event notification, it compares the no- tification message to each update rule and executes each matching rule by invoking the ExecuteUpdateWithMapping operation with appropriate parameters.
Instead of notification operations, update rules may alternatively refer to request- response type operations. Ontology Manager will then invoke those operations peri- odically to determine when the rules should be applied. This approach is useful when a web service provides no event notifications but includes adequate request-response type operations for accurately determining the service status. The time interval of successive request-response operation invocations can be configured through the Ontology Manager GUI.