META-MODEL ANNOTATION 71 1 GPO (General Process Ontology)

For meta-model annotation, a process ontology is an explicit and formal specification of concepts which are used to model processes in general. It is supposed to provide common and core semantics of process modeling constructs. We have investigated a number of process modeling languages and process ontologies in Chapter 3. Most of them were not initiated for annotation purposes and are not represented in OWL, except OWL-S. OWL-S is designed to describe processes of Web services in OWL.

Although a process model in our approach may be regarded as a service, the difference between a Web service and a process model is that a Web service is executable and uses programming-like control constructs as their basic building blocks which are inadequate for all the modeling issues, especially for the type level of modeling. Therefore, we propose a new ontology for meta-model annotation purpose in our framework.

It is difficult to build an ontology to cover all the semantics of various modeling constructs, which would be very complicated. To facilitate the annotation, represen-tations of the ontology should be easily understandable and able to preserve enough semantics of process knowledge. As Musen stated [109]: "Although no simple predicate tells us unambiguously whether a particular specification is an ontology, we can still agree on certain things. We can agree that ontologies enumerate the salient concepts in an application area." A process ontology therefore consists of core concepts which can present the process perspectives specified in Chapter 3.

We set a design principle of the process ontology as simple but comprehensive for modeling process knowledge. Based on such principle, we create an ontology for process modeling, namely General Process Ontology (GPO).

Main concepts defined in GPO

The main concepts in GPO are Activity, Artifact, Actor-role, Input, Output, Precondition, Postcondition, Exception and WorkflowPattern. GPO consisting of those concepts and their relationships are represented using RML [168] in Figure 4.5.

• Activity is a central concept which composes a process. Activity is a synonym of process. However, we also found Process is seldom a construct or just a package construct in most process modeling languages because it is obvious that a process model describes processes. Event is used to trigger Activities but it is sometimes used like an Activity. It also sometimes mixed with state. In order to avoid any ambiguity of those concepts, event and state are not included in GPO. We still think event and state are crucial for process models at the execution level but less at the conceptual business process level. We therefore use the concept Activity in our general process ontology. An activity may be an atomic activity or a composed activity represented by the aggregation relation between activities, i.e. one activity is a subActivity of another activity.

• Artifact represents something involved in an activity such as product, information, tool and software.

• Input and Output of an Activity specify what are consumed and produced by this activity respectively. The way an Artifact is involved in an activity can be

72 CHAPTER 4. SEMANTIC ANNOTATION FRAMEWORK specified through its relations with inputs or outputs.

• Actor-role is the one who interacts with an activity. Although actor and role are two different concepts, we combine these into one to represent that a role is acted by an actor and an actor is a person, or an organization or a system that operates the activity. The role is not acted by any artifact which is distinguished from the definitions of role in some modeling languages, e.g. ResourceRole in UEML.

• Precondition and Postcondition represent respectively constraints before an ac-tivity starts and after an acac-tivity ends. Pre- or Post- conditions may also directly constrain inputs and outputs of activities.

• Exception provides additional information about failures of a process or any ex-ceptional cases in a process. The exception can be handled by activities.

• WorkflowPatterns represent orderings of different activities. WorkflowPattern can be refined into several specific patterns according to the workflow patterns defined in [191], such as Choice (Exclusive Choice, MultipleChoice, ParallelSpit), Merge (SimpleMerge, MultipleMerge, Synchronization) and Sequence, which are basic control workflow patterns supported by most process modeling languages with logical symbols like AND, OR and XOR. The aim of including workflow patterns in GPO is for the user to navigate preceding, succeeding, synchronizing and exclusive activities, because those workflow patterns denote semantics of process orders.

Figure 4.5: General Process Ontology

Process perspectives in GPO

With regard to the process perspectives from the paradigm of BPM systems (defined in Chapter 3), GPO has following correspondences: GPO uses Activity together with

4.4. META-MODEL ANNOTATION 73 Input and Output to represent the operational/function perspective. Decomposable Activities and their subAcitivities can be applied to specify the structural perspective.

The resource and organizational perspectives can be presented through the specifica-tions of Artifact and Actor-role respectively. The control perspective of a process is represented by Precondition, Postcondition of Activities and a set of WorkflowPatterns and Exception to link Activities. No particular concept is identified to represent the data transaction perspective but the links between Artifact and Input or Output can be used to specify changes of data values associated with a certain Artifact.

4.4.2 Mapping rules in Meta-model annotation

GPO is a mediator for semantic reconciliation of process modeling concepts and it should not be seen as a new process modeling language, but a means to annotate the process modeling constructs. In a meta-model annotation a process modeling language is annotated manually by annotators. The procedure of meta-model annotation is in fact to set mapping rules between the GPO concepts and process modeling language constructs or meta-model elements. The mapping rules consist of both one-to-one and one-to-many correspondences between the GPO concepts and modeling language constructs or meta-model elements. More complicated cases might occur, such as a correspondence between a GPO concept and a combination of several modeling con-structs or meta-model elements. To define mapping rules for different cases, we cat-egorize three types of modeling constructs — AtomicConstruct, EnumeratedConstruct and ComposedConstruct. Each single modeling construct is an AtomicConstruct, an EnumeratedConstuct is a list of several AtomicConstructs, and a ComposedConstruct is composed of several AtomicConstructs.

Mapping Rules:

• One-to-one mapping: a GPO concept is referred by an AtomicConstruct (e.g.

GPO:Activity) is mapped to EEML:Task);

• One-to-many mapping: a GPO concept can be referred by several modeling language constructs respectively which are enumerated in an EnumeratedCon-struct (e.g. GPO:Artifact) can be mapped to EEML:Information Object or EEML:Material Object);

• One-to-combination mapping: a GPO concept is referred by a combination of

those modeling language constructs in a ComposedConstruct (e.g. GPO:WorkflowPattern is mapped to a combination of EEML:Flow and EEML:Decision Point).

Different technologies can be employed to represent the mapping rules, such as XML, RDF/RDFS or OWL. An OWL representation is exemplified below. A names-pace metaAnno is used to encode meta-model annotation in these three mapping cases:

<metaAnno:AtomicConstruct rdf:ID=CONSTRUCT_ID>

<metaAnno:refers_to

rdf:resource=&GPO_ONTOLOGY#MODELING_ONTOLOGY_CONCEPT/>

<metaAnno:modeling_language_construct

rdf:resource=&MODELNG_LANGUAGE#LANGUAGE_CONSTRUCT/>

74 CHAPTER 4. SEMANTIC ANNOTATION FRAMEWORK

Once the mapping rules are defined for a certain process modeling language, process models in that process modeling language can be described by the GPO concepts, i.e.

the GPO concepts are used as metadata to annotate process semantics. We call the process models described by the GPO metadata as GPO-annotated process models.

A GPO-annotated process model will be formalized in a process semantic annotation model (PSAM) in section 4.6.