21.01.2014 Views

Semantic Annotation for Process Models: - Department of Computer ...

Semantic Annotation for Process Models: - Department of Computer ...

Semantic Annotation for Process Models: - Department of Computer ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

112 CHAPTER 7. EXEMPLAR STUDIES AND APPLICATION SYSTEM<br />

Table 7.1: OWL definition <strong>of</strong> the SCOR ontology<br />

OWL Ontology Class<br />

Subsumption OWL Properties<br />

Property Range<br />

Relation<br />

owl:subClassOf hasInput multiple<br />

SCOR_MGMT_PROCESS<br />

Activity<br />

SCOR_INPUT_OUTPUT<br />

hasOutput multiple<br />

SCOR_INPUT_OUTPUT<br />

precedes multiple<br />

SCOR_MGMT_PROCESS<br />

isPrecededBy multiple<br />

SCOR_MGMT_PROCESS<br />

owl:subClassOf isInputTo multiple<br />

SCOR_INPUT_OUTPUT Artifact<br />

SCOR_MGMT_PROCESS<br />

isOutputOf multiple<br />

SCOR_MGMT_PROCESS<br />

has_state (data property inherited from<br />

Artifact<br />

SCOR_ORGANIZATIONAL owl:subClassOf<br />

Actor-role<br />

has sub-Class has_parts multiple Goal<br />

Hard Goal,<br />

Goal<br />

S<strong>of</strong>t Goal<br />

part_<strong>of</strong><br />

multiple Goal<br />

targetActivity multiple Activity<br />

targetArtifact multiple Artifact<br />

targetRole multiple Actor-role<br />

targetConstraint (data property)<br />

Each SCOR_MGMT_PROCESS has object properties hasInput and hasOutput to<br />

specify inputs and outputs <strong>of</strong> each process element. The object properties precedes<br />

and isPrecededBy indicate logic flows between the process elements. Inversely,<br />

SCOR_INPUT_OUTPUT has the object properties isInputTo and isOutputOf to<br />

relate itself to SCOR_MGMT_PROCESS. A data property has_state is defined as<br />

a property <strong>of</strong> Artifact. This property can be used associated with isInputTo and<br />

isOutputOf properties to indicate that a same artifact with different states represents<br />

different inputs/outputs.<br />

Goal ontology concepts are organized into Hard and S<strong>of</strong>t Goals. S<strong>of</strong>t goals are<br />

further organized into some general s<strong>of</strong>t goal categories. We integrate the domain<br />

ontology and goal ontology into one OWL file, because they are both derived from<br />

SCOR descriptions. According to the semantic representation <strong>of</strong> the goal ontology<br />

in Chapter 5, the values <strong>of</strong> the object properties targetActivity, targetArtifact,<br />

and targetRole are from the domain ontology Activity, Artifact and Actor-role respectively.<br />

TargetConstraint is modeled as a data property since there is no corresponding<br />

ontological definition in the domain ontology. A pair <strong>of</strong> inverse properties has_parts<br />

and part_<strong>of</strong> are defined <strong>for</strong> a goal concept to represent the semantics <strong>of</strong> goal decomposition.<br />

An OWL model <strong>of</strong> the SCOR ontology is presented in Table 7.1.<br />

The identified domain and goal concepts from the SCOR specifications are modeled<br />

as sub-Classes <strong>of</strong> the above categories. Values <strong>of</strong> the properties <strong>for</strong> a SCOR Class are<br />

specified through the OWL restrictions. As examples, Figure 7.11, Figure 7.12, Figure<br />

7.13 and Figure 7.14 illustrate the sub-Classes <strong>of</strong> the SCOR_MGMT_PROCESS,<br />

SCOR_INPUT_OUTPUT, Hard Goal and S<strong>of</strong>t Goal in the Protégé-OWL editor.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!