Figure 1: Processes Composed of Sub-Processes and Events
Copyright General Electric Company 2005, 2006
The AcuityController, using constructs in the APVF ontology (http://research.ge.com/Acuity/apvf.owl), implements a simple user-interface workflow. This facilitates the construction of simple wizards, for example, by implementing the concept of a process with sequential steps and with the display content varying from step to step. This document describes the constructs and usage of simple workflow in an ACUITy application.
Borrowing from the upper-level ontology of Sowa (2000), we view a Process as a time-variant (occurrent), independent, physical thing. The workflow processes of interest to us here are Discrete Processes--processes in which changes take place in discrete steps called Events interleaved with periods without change called States.
Every Discrete Process is composed of Events, and every Event can, if desired, be examined on a finer-grained time scale and thereby viewed as a Process. When decomposing Events, we will once again restrict ourselves to Discrete Processes as far as ACUITy workflow is concerned. Whether an Event should be decomposed in the model will depend upon the objective of the modeler.
The ACUITy Upper-Level Ontology (AULO), which is imported by the APVF ontology, contains the concept aulo:DiscreteProcess, required to have at least one property of type aulo:hasFirstStep. The range of aulo:hasFirstStep is the union of aulo:DiscreteProcess and aulo:Event. Both aulo:DiscreteProcess and aulo:Event may have the property aulo:hasNextStep, with the same range (union of DiscreteProcess and Event). From these building blocks, one may create simple workflow constructs such as the one show in Figure 1 below.
Figure 1: Processes Composed of Sub-Processes and Events
In Figure 1, Process P1 is composed of Process P1.2, Process P1.3, and Event E1.4. Process P1.2 is composed of Events E1.2.1 and E1.2.2, and so forth. If all the Events in Process P1 were to proceed in the order implied, the sequence would be {E1.2.1, E1.2.2, E1.3.1, E1.3.2, E1.4}.
Although not illustrated in Figure 1, both aulo:hasFirstStep and aulo:hasNextStep can be multi-valued. Multiple links from an Event or Process to subsequent Events or Processes represent parallel workflow paths within the containing Process. The AcuityController does not provide complete support for parallel workflow at this time. Also not currently modeled in ACUITy is conditional branching to sub-Processes or Events.
The APVF ontology defines apvf:AcuityInteractionEvent as a subclass of aulo:Event. This class is meant to capture, through its subclasses and/or Individuals, occurrences within the ACUITy application's user-interface which affect the PresentationObjects that are contained in a particular Vantage. To this end, apvf:AcuityInteractionEvent is the domain of two properties:
In the interest of simplicity of representation, there is a little twist to this design. The apvf:AcuityInteractionEvent is anticipitory--it is the Event which is about to or may happen next. The "change" represented by the Event is effected by the apvf:ServerSideScript or rdf:List of Scripts identified by the apvf:hasEffect property or properties. In preparation for this Event, those PresentationObjects which are associated with the Event by the apvf:usesPresentationObject property are added to the Vantage for the duration of the implicit State existing before the subject Event.
More precisely, a Vantage may have the property apvf:hasActiveProcess with range the union of aulo:DiscreteProcess and aulo:Event. When a Vantage has such a property and the object is an instance of aulo:DiscreteProcess, that instance of DiscreteProcess may have the property apvf:hasActiveStep, with range aulo:Event. Thus a Vantage may have an "active" Event, either directly (apvf:hasActiveProcess with object an instance of Event) or indirectly (the "active" Process has an active Event). When a Vantage has an "active" Event, those PresentationObjects identified with the event by apvf:usesPresentationObject are added to the content of the Vantage. When the Event is no longer "active" these POs will no longer appear in the Vantage.
In terms of the Processes and Events of Figure 1, a Vantage might have an apvf:hasActiveProcess property with value P1. Process P1 might have apvf:hasActiveStep Event E1.2.2, in which case the next event would be E1.3.1. The AcuityController checks, when a Vantage has the focus, to see if it has any value for or restriction on apvf:hasActiveProcess. If so, that Process is checked to see if it has an active step. If not, the first step is automatically made the active step. (In the Process in Figure 1, this would be Event E1.2.1.) This has the effect that if a Process is completed and the Vantage still has the focus and an active Process, and the Process's active step is cleared (the Process no longer has an apvf:hasActiveStep property), the Process will automatically start over. If this is not desired a terminal Event that remains the active step but has no POs, effects, or means of transitioning to another step can be used as the active step. The APVF ontology provides such an Event, the Individual apvf:NoOpTerminalEvent.
For convenience, the ontology http://reasearch.ge.com/Acuity/acuityplus.owl defines three Individuals of type apvf:OnDemandAction and which correspond to methods on the Java class com.ge.grc.acuity.apvfplus.actions.DiscreteProcessActions.
For convenience, this Java class also provides a method for generating the appropriate subset of these three on-demand actions as possible answers, i.e., 1 and 3 for the first step, 1 and 2 for the last step, and all three for intermediate steps. The APVF OnDemandAction instance for generating these possible answers is named DiscreteProcessActionsAnswersGenerator. If the Event identified as the active step has a label, this label is provided as the label of the "This Step" action. That failing, if the step has an effect with a label, that label will be used. Using these labels making it easier to make the menu option more specific and meaningful for the user while still using the ThisStep as the OnDemandAction on the menu.