SCOR is a process reference model that has been developed and endorsed by the Supply- Chain Council as the cross-industry standard diagnostic tool for supply-chain manage- ment. A SCOR reference model has been developed to describe the standard business activities associated with all phases of satisfying a customer’s demand. As standards, the model can be formalized as a reference ontology for supply-chain management do- main.
There are three level process details in the reference model. The top level defines the scope and content of SCOR. Five process types — Plan, Source, Make, Deliver and Return are defined at this level. The second level is the configuration level defining the core "process categories". The third level is the process element level, decomposing the process categories into the process elements. The process element level consists of process element definitions, process element information inputs, and outputs, pro- cess performance metrics, best practices, system capabilities required to support best practices, and systems/tools. As an example, a logic flow of the SCOR level 3 process elements is depicted in Figure 7.10.
The level 3 process elements provide enough details of references for domain activ- ities. In this work, we model domain ontology concepts based on the SCOR process elements at level 3 for model annotation purpose. The SCOR ontology from the IN- TEROP project [62] is extended. The extended ontologies include SCOR_INPUT_OUTPUT, SCOR_MGM_PROCESS and SCOR_ORGANISATION. SCOR_INPUT_OUTPUT are objects which are needed or produced by SCOR process elements. SCOR_MGM_PROCESS are the SCOR process elements at level 3 which are organized in a hierarchy following the SCOR
7.3. SCOR REFERENCE ONTOLOGY 111
Figure 7.10: SCOR S1 process of sourcing stocked product [164]
levels (from level 1 to level 3). SCOR_ORGANISATION are organizations/persons who are involved in the process elements. The goal ontology in this domain is also from SCOR. Usually the hard goals are derived from process elements and also from their inputs and outputs. Performance attributes defined in SCOR can be modeled as a set of Gen- eral Soft Goal Category such as Reliability, Responsiveness, Flexibility, Cost, and Assets. Domain specific soft goals are derived from the metrics of performance attributes [167].
The SCOR ontology is formalized in OWL. To organize those concepts, we catego- rize domain concepts with the 3A concepts (Activity, Artifact, Actor-role) defined in GPO. The purpose of the categories is to establish the mapping relationship be- tween a PSAM model and the reference ontology when annotation. The categories and concepts are modelled as OWL Classes, and they are organized by a subsumption hierarchy.
The ontology concepts which are organized in "SCOR_MGMT_PROCESS" are sub-classes of Activity, the input/output ontology concepts ("SCOR_INPUT_OUTPUT") are sub-classes of Artifact and the organizational ontology concepts ("SCOR_ORGANIZATIONAL") are sub-classes of Actor-role.
112 CHAPTER 7. EXEMPLAR STUDIES AND APPLICATION SYSTEM
Table 7.1: OWL definition of the SCOR ontology
OWL Ontology Class Subsumption
Relation OWL Proper- ties Property Range SCOR_MGMT_PROCESS owl:subClassOf Activity hasInput multiple SCOR_INPUT_OUTPUT hasOutput multiple SCOR_INPUT_OUTPUT precedes multiple SCOR_MGMT_PROCESS isPrecededBy multiple SCOR_MGMT_PROCESS SCOR_INPUT_OUTPUT owl:subClassOf Artifact isInputTo multiple SCOR_MGMT_PROCESS isOutputOf multiple SCOR_MGMT_PROCESS has_state (data property inherited from
Artifact SCOR_ORGANIZATIONAL owl:subClassOf Actor-role Goal has sub-Class Hard Goal, Soft Goal
has_parts multiple Goal
part_of multiple Goal targetActivity multiple Activity targetArtifact multiple Artifact targetRole multiple Actor-role targetConstraint (data property)
Each SCOR_MGMT_PROCESS has object properties hasInput and hasOutput to specify inputs and outputs of each process element. The object properties precedes and isPrecededBy indicate logic flows between the process elements. Inversely, SCOR_INPUT_OUTPUT has the object properties isInputTo and isOutputOf to relate itself to SCOR_MGMT_PROCESS. A data property has_state is defined as a property of Artifact. This property can be used associated with isInputTo and isOutputOfproperties to indicate that a same artifact with different states represents different inputs/outputs.
Goal ontology concepts are organized into Hard and Soft Goals. Soft goals are further organized into some general soft goal categories. We integrate the domain ontology and goal ontology into one OWL file, because they are both derived from SCOR descriptions. According to the semantic representation of the goal ontology in Chapter 5, the values of the object properties targetActivity, targetArtifact, and targetRole are from the domain ontology Activity, Artifact and Actor-role respec- tively. TargetConstraint is modeled as a data property since there is no corresponding ontological definition in the domain ontology. A pair of inverse properties has_parts and part_of are defined for a goal concept to represent the semantics of goal decom- position. An OWL model of the SCOR ontology is presented in Table 7.1.
The identified domain and goal concepts from the SCOR specifications are modeled as sub-Classes of the above categories. Values of the properties for a SCOR Class are specified through the OWL restrictions. As examples, Figure 7.11, Figure 7.12, Fig- ure 7.13 and Figure 7.14 illustrate the sub-Classes of the SCOR_MGMT_PROCESS, SCOR_INPUT_OUTPUT, Hard Goal and Soft Goal in the Protégé-OWL editor.