Table 9.1: SWRL queries and rules for RE1
RE1 Rule Name SWRL formulation
RE1.1 QRule-Activity- subActivity
Activity(?x) ∧has_subActivity(?x, ?y) →query : select(?x, ?y) ∧query : orderBy(?x)
RE1.2 QRule-Activity-hasPrecedingActivities Activity(?x) ∧has_ precedingActivities(?x, ?y) →query : select(?x, ?y) ∧ query : orderBy(?x)
QRule-Activity-
hasSucceedingActivities
Activity(?x) ∧has_succeedingActivities(?x, ?y) →qurey : select(?x, ?y) ∧
query : orderBy(?x)
RE1.3 QRule-Activity- hasArtifact
Activity(?x) ∧has_ Arti f act(?x, ?y) → query : select(?x, ?y) ∧query : orderBy(?x)
RE1.4 QRule-Activity-hasActor Activity(?x) ∧has_ Actor−role(?x, ?y) →query : select(?x, ?y) ∧query : orderBy(?x)
RE1.5 QRule-Activity-hasPrecondition Activity(?x) ∧has_ Precondition(?x, ?y) →query : select(?x, ?y) ∧query : orderBy(?y)
QRule-Activity- hasPostcondition
Activity(?x) ∧has_ Postcondition(?x, ?y) → query : select(?x, ?y) ∧
query : orderBy(?y)
to understand the semantically-reconciled process knowledge from different organiza- tions. In the PSAM models, an ontology is referenced by models through annotation relationships which are represented using OWL properties such as same_as, kind_of, part_of, mapped_to, achieves, positively_satisfies and negatively_satisfies. Therefore, those properties should be specified in the SWRL queries or rules (see Table 9.2).
9.2.3 Formalize RE3 - Semantic check requirements
RE3 is related to G3 (The annotation should help to analyze and validate the existing process models). It is used to infer the underlying process knowledge according to the annotation and to check the semantic completeness and semantic validity of annota- tion models. The SWRL formulations of RE3 are listed in Table 9.3. The queries for inferences are usually built through correlations to OWL properties. For example, be- sides the Object Property has_Artifact of Activity, the relationship between Activity and Artifact can also be inferred through connecting relations among Activity, Input, Output, and Artifact. RE3.1 (Check the Artifacts related to the Input/Output of Activi- ties) is therefore formalized as IRule-Activity-Input-hasArtifact, IRule-Activity- Output-hasArtifact and QRule-Activity-hasArtifact. They can be used to infer the fact that if an Artifact is related to the Input or Output of an Activity, the Activity might have such an Artifact. Such inference tasks can be used to find possible missing annotations of has_Artifact.
RE3.2 (Check the Activity sequences) needs to figure out the ordinary se- quence of activities, sequence of decomposable activities, iterative and in- verse sequence. Sequences of decomposable activities sometimes are not easy to navigate directly from the model specifications. Therefore, QRule- Activity-hasPrecedingActivities-hasSubActivity and QRule-Activity- hasSucceedingActivities-hasSubActivity are formalized to infer such implicit semantics.
The properties of sub-Activities could be passed to their super-Activities, which are validated in RE3.3 (Check the Artifacts in sub-Activities), RE3.4 (Check the Actor-roles in sub-Activities) and RE3.5 (Check the goal annotations in sub-Activities). IRule-
148 CHAPTER 9. VALIDATION OF APPLICABILITY
Table 9.2: SWRL queries and rules for RE2
RE2 Rule Name SWRL formulation
RE2.1
QRule-Activity-sameas Activity(?x) ∧same_ as(?x, ?y) → query : select?x, ?y ∧query : orderBy(?y)
QRule-Activity-kindof Activity(?x) ∧kind_o f(?x, ?y) → query : select(?x, ?y) ∧query : orderBy(?x)
QRule-Activity-phaseof Activity(?x) ∧phase_ o f(?x, ?y) → qurey : select(?x, ?y) ∧query : orderBy(?x)
RE2.2
QRule-Activity-Input- mappedto
Activity(?x) ∧has_ Input(?x, ?y) ∧mapped_to(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity-Output- mappedto
Activity(?x) ∧has_Output(?x, ?y) ∧mapped_to(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity- hasArtifact-sameas
Activity(?x) ∧has_ Arti f act(?x, ?y) ∧same_ as(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity- hasArtifact-kindof
Activity(?x) ∧ has_ Arti f act(?x, ?y) ∧kind_ o f(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity- hasArtifact-partof
Activity(?x) ∧ has_ Arti f act(?x, ?y) ∧part_o f(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
RE2.3
QRule-Activity- hasActor-sameas
Activity(?x) ∧has_ Actor−role(?x, ?y) ∧same_ as(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity- hasActor-kindof
Activity(?x) ∧has_ Actor−role(?x, ?y) ∧kind_ o f(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity- hasActor-memberof
Activity(?x) ∧has_ Actor−role(?x, ?y) ∧member_o f(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
RE2.4 QRule-Activity-achievesHardGoal Activity(?x) ∧achieves(?x, ?y) → query : select(?x, ?y) ∧query : orderBy(?y)
QRule-Activity-
positivelysatisfiesSoftGoal
Activity(?x) ∧positivel y_satis f ies(?x, ?y) → query : select(?x, ?y) ∧
query : orderBy(?y)
QRule-Activity-
negativelysatisfiesSoftGoal
Activity(?x) ∧negativel y_satis f ies(?x, ?y) → query : select(?x, ?y) ∧
query : orderBy(?y)
Activity-subActivity-hasArtifact and IRule-Activity-subActivity-hasActor are used to introduce the implicit annotation of has_Artifact and has_hasActor-role for the super-Activity. The effects of goals from the sub-Activities could be transferred to the super-Activities but it is not necessary for all cases. RE3.5 is therefore formal- ized as SWRL queries not inference rules by only listing the possible goal annotations transferred from the sub-Activities.
RE3.6 (Check the Precondition/Postcondition of Activities) is formal- ized into QRule-Activity-hassamePrecondition and QRule-Activity- hassamePostcondition. It attempts to find out the redundant Activities with the same conditions or the workflow patterns with the branches divided from the conditions. Besides, for RE3.7 (Check the information flow from the Output to the Input) the information flow (/output-input flow) can be identified through comparing the annotated Input and Output in QRule-Activity-hasOuput-mappedto- sameonto-Activity-hasInput. If an output has an ontology reference which is also referenced by an input, there might be an information flow between the output and the input.
9.2.4 Formalize RE4 - Knowledge discovery requirements
RE4 is related to G4 (The annotation should be helpful in the semantic reconciliation of models to facilitate reuse and integration of models.). This requirement is for analyzing the potential semantic relations between different models. However, SWRL rules can only be applied in one ontology file, such as the SWRL formulations of RE1, RE2 and
9.2. SWRL FORMULATION 149
Table 9.3: SWRL queries and rules for RE3
RE3 Rule Name SWRL formulation
RE3.1
QRule-Activity-
hasInput-relatedArtifact
Activity(?x) ∧has_ Input(?x, ?y) ∧related_ Arti f act(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?x)
QRule-Activity- hasOutput- relatedArtifact
Activity(?x) ∧has_Output(?x, ?y) ∧related_ Arti f act(?y, ?z) →query : select(?x, ?y, ?z) ∧query : orderBy(?x)
IRule-Activity-Input- hasArtifact
Activity(?x) ∧ has_ Input(?x, ?y) ∧ related_ Arti f act(?y, ?z) →
Activity(?x) ∧has_ Arti f act(?x, ?z)
IRule-Activity-Output- hasArtifact
Activity(?x) ∧ has_Output(?x, ?y) ∧ related_ Arti f act(?y, ?z) →
Activity(?x) ∧has_ Arti f act(?x, ?z)
RE3.2
QRule-Activity- hasPrecedingActivities- hasSubActivity
Activity(?x) ∧ has_ precedingActivities(?x, ?y) ∧
has_subActivity(?x, ?z) →query : select?y, ?z∧query : orderBy(?y)
QRule-Activity-
hasSucceedingActivities- hasSubActivity
Activity(?x) ∧ has_succeedingActivities(?x, ?y) ∧
has_subActivity(?x, ?z) →query : select?z, ?y∧query : orderBy(?y)
QRule-Activity-iterative- preceding
Activity(?x) ∧has_ preceding Activities(?x, ?x) →qurey : select(?x)
QRule-Activity-iterative- succeeding
Activity(?x) ∧has_succeedingActivities(?x, ?x) →qurey : select(?x)
IRule-Activity- preceding-inverse- succeeding
Activity(?x) ∧ has_ preceding Activities(?x, ?y) → Activity(?y) ∧
has_succeedingActivities(?y, ?x)
IRule-Activity- succeeding-inverse- preceding
Activity(?x) ∧ has_succeeding Activities(?x, ?y) → Activity(?y) ∧
has_ precedingActivities(?y, ?x)
RE3.3 IRule-Activity-
subActivity-hasArtifact
Activity(?x) ∧ has_subActivity(?x, ?y) ∧ has_ Arti f act(?y, ?z) →
Activity(?x) ∧has_ Arti f act(?x, ?z)
RE3.4 IRule-Activity- subActivity-hasActor
Activity(?x) ∧has_subActivity(?x, ?y) ∧has_ Actor −role(?y, ?z) →
Activity(?x) ∧has_ Actor−role(?x, ?z)
RE3.5
QRule-Activity- subActivity-transitive- achievesHG
Activity(?x) ∧has_subActivity(?x, ?y) ∧achieves(?y, ?z) → query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity- subActivity-transitive- positivelysatisfiesSG
Activity(?x) ∧has_subActivity(?x, ?y) ∧positivel y_satis f ies(?y, ?z) →
query : select(?x, ?y, ?z) ∧query : orderBy(?z)
QRule-Activity- subActivity-transitive- negativelysatisfiesSG
Activity(?x) ∧has_subActivity(?x, ?y) ∧negatively_satis f ies(?y, ?z) →
query : select(?x, ?y, ?z) ∧query : orderBy(?z)
RE3.6 QRule-Activity-hassamePrecondition Activity(?x) ∧ Activity(?y) ∧ name(?x, ?n) ∧ name(?y, ?m) ∧ swrlb : notEqual(?n, ?m) ∧ has_ Precondition(?x, ?z) ∧
has_ Precondition(?y, ?z) →query : select(?x, ?y, ?z)
QRule-Activity- hassamePostcondition
Activity(?x) ∧ Activity(?y) ∧ name(?x, ?n) ∧ name(?y, ?m) ∧
swrlb : notEqual(?n, ?m) ∧ has_Postcondition(?x, ?z) ∧
has_ Postcondition(?y, ?z) →query : select(?x, ?y, ?z)
RE3.7 QRule-Activity- hasOutput-mappedto- sameonto-Activity- hasInput
Activity(?x) ∧has_Output(?x?p) ∧mapped_to(?p, ?o) ∧Activity(?y) ∧
has_ Input(?y, ?q) ∧mapped_to(?q, ?n) ∧swrlb : equal(?o, ?n) →query : select(?x, ?y, ?o)
150 CHAPTER 9. VALIDATION OF APPLICABILITY RE3. For RE4, we have to run the SWRL rules of RE1, RE2 and RE3 on different models respectively and analyze all query results manually. For example, implementing RE4.1 (Find out semantic relationships between the Activities of different process mod- els) needs the SWRL rules QRule-Activity-sameas, QRule-Activity-kindof and QRule-Activity-phaseof for RE2.1 (Find the model fragments of process models that reference to SCOR Management Process). In this application, those rules are run on all the three models, and SCOR Management Processes in the domain ontology are used as the common references (which are specified in the variables in the SWRL rule for- mulations) to analyze the relationships between the query results of three models. The relationships usually applied in the analysis are ontological relations such as OWL Class subsumption, OWL Class equivalent, ObjectProperty part-whole relationship and etc. To implement RE4.5 (Find out possible integration points among different process models), we consider the following integration cases by running related SWRL queries and rules for the above requirements.
• Case 1. Output and input. If the outputs in one model can be mapped to the inputs in another model, then it is possible to integrate the two models through the outputs and the inputs. QRule-Activity-Output-mappedto and QRule- Activity-Input-mappedto are run on three models respectively. The variable of ontology concept ?z can be replaced by a specific domain concept.
• Case 2. Sequence of activities. If the Activities from the three annotation models that have references of the SCOR process elements, then a possible integration of those Activities from different models can be checked according to the sequence definition in SCOR ontology. SWRL queries for RE2.1 (Find the model fragments of process models that reference to SCOR Management Process) can be run in this case, and the variable ?y is specified with a SCOR process element in each query. • Case 3. Semantic relationship of activities. If two Activities from different mod- els have certain semantic relationships with each other according to the domain annotation, then there is a possibility for two Activities to be integrated through the relationships. The SWRL queries for RE2.1 (Find the model fragments of process models that reference to SCOR Management Process) can also be used in this case, and the annotation relationships such as same_as, kind_of and phase_of should be concerned in the integration analysis.
• Case 4. Ontological relationship of goals. If two Activities from dif- ferent models are annotated with the goals and the goals are same or have certain ontological relationships, the possible integration of two mod- els can be analyzed based on the goal annotation. Goal concept is spec- ified to replace the ontology concept variable ?y in the queries QRule- Activity-achievesHardGoal, QRule-Activity-positivelysatisfiesSoftGoal and QRule-Activity-negativelysatisfiesSoftGoal. Through the ontological relationship has_parts or rdfs:subClassOf, the parts or the sub-class of this goal are also specified to replace ?y respectively in the queries.
The SWRL queries and rules above are edited in Protégé-OWL SWRLTab (see Figure 9.1). They are attached to all the OWL files of the annotation models and will
9.3. APPLICABILITY VALIDATION IN AN INTEGRATION APPLICATION 151