Ontology Driven Knowledge Design and Development for Supply Chain Management

Charu Chandra, Armen Tumanyan University of Michigan Dear!orn "ndustrial and Manufacturing Systems #ngineering Department Dear!orn, Michigan $%&'%, USA A!stract
One of the ways of effective supply chain management is through shared knowledge among its constituents. Knowledge about supply chain can be classified as organizational and problem specific. Organizational knowledge helps to understand the domain requirements for supply chain management. Problem knowledge provides input for problem-solving modules. The concept of ontology is applied to systematically document shared knowledge about issues and problems in the supply chain domain. Ontology development for a supply chain is a collaborative process that crosses individual organizational boundaries of its members and comprises knowledge !a" capture !b" assemble !c" store and !d" dissemination. Keywords( knowledge design ontology supply chain management information system

"ntroduction
One of the key issues in managing a supply chain !#$" is integration among its constituents. To facilitate integration #$ information resources ought to be effectively organized and shared. %nformation integration provides channels that convey information from one #$ constituent to another. One form of this problem involves the integration of e&isting implementations that have been built in heterogeneous infrastructures viz. different hardware platforms operating systems and database management systems. 'y presenting data on which applications perform in a uniform self-consistent way it can be made sure that they share the same view of the #$ where same data stored in more than one of the local systems should have the same meaning if not an identical form in all of them. (nother form of integration is concerned with working on common problems collectively by sharing the understanding of the problem reasoning logic and applying best practices. This provides a common architecture in information sharing for #$ member)s collaborative activities to provide performance improvement to each member and to the entire #$. The process of information integration in a #$ can be decomposed into the following components* !+" standardization of information representation !," shared vocabulary !-" problem-oriented data conceptualization !." transparency of information and !/" standardization of information access and retrieval. Ontology is a promising construct in the pursuit of information integration for the following reasons* !+" ontology is a shared and common understanding of a domain that can be communicated across people and computers 0+ , -1 and help access information they need. 'y providing shared domain theories ontologies can be the key assets for information organization 0.1. !," Ontology is also being utilized for intelligent information integration information retrieval knowledge management web standards online databases and multi-agent systems. The reason for increasing use of ontologies is the lack of standards !shared knowledge" for communication syntactically and semantically both from human and computer perspectives. This problem will deteriorate especially with information levels increasing e&ponentially and impacting the decision modeling process. Ontology as a formal e&plicit specification of a shared conceptualization offers a practical solution grounded in proven theoretical constructs for designing #$ organizational and problem knowledge to facilitate information integration.

Knowledge types( organi)ational and pro!lem domains

Two main forms of knowledge have been identified as potentially sharable and reusable viz. +" problem-solving methods describing steps to be taken in performing a task and ," organizational knowledge describing the structure of an organization in a particular field. The ontology framework proposed in this paper deals with both forms of knowledge representations. %t describes modeling of organizational specific knowledge !organizational ontology"

#ubmitted as $onference Proceedings +-th (nnual %ndustrial 2ngineering 3esearch $onference !%23$ ,44." 5ouston Te&as 6ay +7-+8 ,44..

and problem specific knowledge !problem ontology". The former can be used to understand the domain of study while the latter provides decision-making agents with appropriate knowledge for problem solving tasks. The Ontology modeling framework proposed in this paper offers a mechanism for transforming implicit knowledge which is in e&perts) domains into e&plicit models. 5uman operators as well as computational software applications can use this knowledge. Knowledge modeling ontologies constructed for organizational and problem domains can be used as building blocks of knowledge bases ob9ect schema for ob9ect oriented systems conceptual schema for databases structured glossaries for human collaborations vocabularies for communication between agents and class definitions for conventional software systems.

Ontology !ac*ground( definitions, pro+ects

Ontology refers to an engineering artifact constituted by a specific vocabulary used to describe a certain reality in addition to a set of e&plicit assumptions regarding the intended meaning of words in the vocabulary 0,1. One of the logical ways of representing #$ knowledge is in the form of hierarchy of concepts embedded in its structure. $handra and Tumanyan 0/1 have described system ta&onomy as a method for building this hierarchy. 6odels encapsulate concepts applied to solving real problems. 6odels acquire their realism through assumptions which e&press relationships between concepts. (&ioms describe model assumptions with the rule-based formalism. (&iom development is an important step in designing appropriate knowledge for problem solving. (s described in a later section #$ ontologies are conceptualized based on model assumptions that convey information requirements for a #$ system. 6any research efforts are committed to applying ontological principles for designing organizational and problem knowledge. The most significant pro9ects in this field are briefly described in this section. TO,# !http*::www.eil.utoronto.ca:enterprise-modelling:tove" pro9ect is focused on the enterprise modeling concurrent engineering and integrated supply chain management 071. TO;2 ontology provides reach and precise representation of generic knowledge such as activities processes time and causality and enterpriseoriented knowledge such as cost quality and organization structure. On-To-Knowledge !www.ontoknowledge.org" is focused on content-driven knowledge management through evolving ontologies. The technical backbone of On-To-Knowledge is the use of ontologies for various tasks of information integration tasks and mediation and can help knowledge workers who are not %T specialists to access company-wide information repositories in an efficient natural and intuitive way. Process Handbook Project !http*::ccs.mit.edu:ph:" proposes a novel theoretical and empirical approach to tasks such as business process redesign and knowledge management. The pro9ect involves collecting e&amples of how different organizations perform similar processes and organizing these e&amples in an on-line <Process handbook=. These repositories can be used to share and manage knowledge about e&isting businesses and to generate innovative ideas about new business possibilities. The Enterprise pro9ect !http*::www.aiai.ed.ac.uk:pro9ect:enterprise:enterprise:ontology.html" is a ma9or initiative to promote the use of knowledge-based systems in enterprise modeling aiming to support organizations effectively in the 6anagement of $hange. $omponents of the 2nterprise Toolset developed in the scope of this pro9ect include* a Procedure 'uilder for capturing process models an (gent Toolkit for supporting the development of agents a Task 6anager for integration visualization and support for process enactment and enterprise ontology for communication.

Ontology conceptuali)ation( a framewor*

The proposed framework provides close integration of knowledge components with decision support systems and their consumption by software applications called agents. Knowledge components encompass ontology models and the infrastructure supporting their creation storage and use. 'ased on information integration requirements presented in the %ntroduction #ection and serving the needs of the decision-modeling system following assumptions are made for ontology conceptualization* !+" systematic principles for knowledge conceptualization !," problem specific nature of ontology constructs !-" modularity and ob9ect nature of formed knowledge !." reusability of created knowledge !/" integration of distributed data and !7" machine readable format of delivered knowledge. These assumptions provide the scope of functional requirements for the ontology conceptualization framework depicted in >igure +. %t consists of four layers of information abstraction. The upper layers are meta-models for developing the lower layers. %t starts with the #$ system ta&onomy which is a systematic classification of

#ubmitted as $onference Proceedings +-th (nnual %ndustrial 2ngineering 3esearch $onference !%23$ ,44." 5ouston Te&as 6ay +7-+8 ,44..

organizational and problem domain characteristics and describes concepts and their relationships 0/1. #ystem ta&onomy is developed through e&amination of the #$ domain and its problems. #ystem ta&onomy comprises the entire #$ system and its problem-solving components designed to address specific #$ issues or problems. Pro9ecting the problem specific issues from system ta&onomy generates many #$ problem model ta&onomies for many sub-models. #tudying the problem space with its related characteristics and concepts does this pro9ection. Problem model ta&onomy serves as a meta-model for knowledge model generation and ontology development. 'ased on the concepts and characteristics inherited from Problem 6odel Ta&onomy rules and regulations held on organization or problem domain are formulated utilizing the concepts of ontology development.
S!bject Domain
Classification

System Taxonomy
Projection

Problem Model Taxonomy Problem Domain

Domain Space Identification Axioms Identification Kno ledge generation

Ontology
Instantiation

Commitments

Repository

Object Model

>igure +. The conceptual framework of Ontology development Ontology inherits its structure and vocabulary from problem model ta&onomy thus providing consistency in representing various problems. Ontology development components enrich problem model with constructs thus turning it from abstract problem representation into a knowledge model. These constructs are* !+" a&ioms - defines rules and regulations specific to a problem domain !," algorithms - provides step-by-step procedures for approaching the problem and solving it and !-" commitments - interpret abstract concept characteristics into problem variables and link them to data repositories. The first two components are modeled through thorough analysis of the problem. #ystem analysis and design techniques are applied here such as process modeling and ob9ect-oriented system development. The identification of first two components is the most important part of ontology development. Ontology by itself is a vocabulary with rules and description on how to use them. 3eal world applications require data to operate with. Ontological commitments provide these data. Ob9ect models are tangible software constructs where problem specific data are represented in a common programming language encapsulated in a formal model accompanied by descriptions of what to do with the data and how to do it.

Model
?otations S @ #ystem T @ Thing symbolizing the elements of system R @ 3elationships among things of system defined on T W @ $lass instances of # for #$ domain w @ The instance of class A S w @ #pecific system for #$ domain !an instance of #" Tw @ Things specific to #$ domain !an instance of T" Rw @ #et of relationships held on Tw M @ Bata model for #$ domain I @ Ontological commitments. >unctions interpreting characteristics into variables V @ #et of variables Bw Bc Bh @ Observation channels for defining variables constraints and algorithms respectively J @ #et of %nterpretation functions I M w @ Bata model for #$ problem C @ $onstraints on data O @ Ontology model A @ #et of a&ioms H @ (lgorithm or heuristics G @ #et of equations

The approach for system representation can be formulated as follows* # C !T 3". Betailed description of ta&onomy of system in general can be found in $handra and Tumanyan 0/1. >ormally #$ system can be represented as a collection of all possible instances of generic system applied to #$ with corresponding relationships* S = !T A 3" . >or each possible system instance w W the intended structure of w according to # is the structure* S w = !Tw 3 w " 3 w is the set of e&tensions !relative to w" of elements of T. R = { Rw D w W } . Ae denote with # the set of all the intended system instance structures of system. S = { S w D w W } . S w is a description of a problem !problem model ta&onomy" to be solved. S w contains names of parameters identified in problem description with corresponding

#ubmitted as $onference Proceedings +-th (nnual %ndustrial 2ngineering 3esearch $onference !%23$ ,44." 5ouston Te&as 6ay +7-+8 ,44..

relationships organized in a structured hierarchy. Ontology development starts with this structured vocabulary and ties them to variables. Problem model ta&onomy S w is an abstract representation of an organizational or a problem domain* a meta-model. Ontological commitments are interfaces between abstract problem representation and real world data storage. 3earranging the standard definition a model 6 is defined as a structure !# %" where #C!T 3" is a world structure !standard system definition" and % is an interpretation function which through observation channel ' assigns attributes of T to variables of ;* M = ! S %" I = !V Tw 'w " . Observation channel 'w predicates variables ;. This intentional interpretation can be classified as the first ontological commitment. Observation channels are situations where the system state is captured to observe variables ;. These can be process models where required variables participate. #tudying documented process model may reveal the meaning of variables and where they can be taken from. (nother e&ample of observation channel can be database schema precisely describing how variables can be queried and stored. The model representation can be used for more general cases* M = !T A 3 E" . These are data model for system in general including its all instances and all possible interpretations. 3ather data models presentation for specific system instances can be formulated* M w = !Tw 3 w %" assuming that #w S for each instance w A . M w is an instance of M but it will be referred to as a model not model instance since model M will never be implemented. ( model can describe a situation common to many states. The second ontological commitment is the application of logical a&ioms designed to account for the intended meaning of vocabulary and assigning constraints to system variables. Ontology can be represented as continuation of problem representation by adding new features to it. %t can be defined as an organizational or problem knowledge that contains concepts with relationships a&iomsF and if it is a problem ontology problem reasoning algorithms. This proposition is formally presented O = ! M ( 5" . ( is a set of a&ioms for assigning constraints to variables through 'C observation channel A = !C V 'C " . 5 is a set of algorithms for assigning mechanisms !G" to data model processing through ' H observation channel H = !G M 'H " . Ontology consists of three components* data model !6" a&ioms !(" and algorithms !5". >or building an ontology model these three components should be considered and constructed.

Ontology development components

Ontology development consists of four aspects namely* capture assembly storage and usage. ( demonstration of ontology development process is done based on a case study of a pilot pro9ect to design a knowledge base for a decision support system for steel processing and shipment !#P#" #$. #P# is a multi-stage manufacturing process. The automobile #$ consists of several raw material suppliers and a stamping plant !>igure ," which bus steel from them to produce assembly components. The stamping plant consists of blanking pressing and assembly departments. The blanking department cuts the raw steel into rectangular pieces. The pressing department stamps the blanks into parts. Aelding and other operations are performed on stamped parts at the metal assembly department.
Ra Ra Ra Ra material s!pplier " material s!pplier # material s!pplier $ material s!pplier % &lan'ing " &lan'ing # Stamping Pressing " Pressing # Assembly " Assembly #

>igure , #teel processing and shipment supply chain The Ontology development framework assumes four stages of information modeling* +" ta&onomy ," problem model -" ontology model and ." ob9ect model. Ta.onomy development is discussed in $handra and Tumanyan 0/1. /ro!lem model development starts with studying the problem and its information needs. Thorough analysis of #P# #$ reveals a list of parameters necessary for incorporating into decision modeling systems and finding solutions for optimal problem solving. Parameters studied are translated into terms and definitions identified in system ta&onomy. The process of this transformation is finding classes where above characteristics reside and pro9ecting these into a new hierarchy* problem model ta&onomy. The transformed diagram is depicted in >igure -.

#ubmitted as $onference Proceedings +-th (nnual %ndustrial 2ngineering 3esearch $onference !%23$ ,44." 5ouston Te&as 6ay +7-+8 ,44..

SteelSupplyChain Output Mechanism " Product +Prod!ctType.int +Prod!ctStat!s.int +Prod!ctSi5e.int +Prod!ctID.int +Prod!ct,ame.int +Prod!ct6!antity.int ())* Structure " ())* +In3entory-oldingCost.int +ProcessingCost.int +Prod!ctSet!pCost.int +Prod!ctCost.int +Period.int ProductStructure +6!antity.int +MaterialID.int +Prod!ctID.int

Agent ProductionUnit +Stage.int +P0ID.int +P0,ame.int " ())* ())* " Transportation +TransportationDate.int +TransportationTime.int +TransportationType.int +Destination.int

Resource +,!mberof-o!rs.int +Reso!rce,ame.int +S/ift.int +TotalCapacity.int

"

())* Cost +2ixedCost.int +Ot/erCost.int +TransportationCost.int

ProductProduction +Prod!ctionTime.int +Set!pTime.int +Reso!rce.int +&rea'Do nD!rationP".int +&rea'Do nD!rationP#.int +&rea'Do nD!rationType.int +Deffecti3enessP".int +Deffecti3enessP#.int +Deffecti3enessType.int +&rea'Do n2re4!encyP".int +&rea'Do n2re4!encyP#.int +&rea'Do n2re4!encyType.int

ProductCost

" "))* ResourceAttributes +Capacity.int +Sc/ed!ledRate.int +1ield.int +Prod!ctID.int

Demand +6!antityAcc!m!lati3e.int +Demand,et.int +Costomer.int +Period.int

>igure - $onfiguration : scheduling problem model ta&onomy Ontology model development is concerned with capturing assembling storing and using of ontology constituents which are data model a&ioms and algorithms. Capture0 Bata model is captured by inheriting data structure from problem model ta&onomy and adding ontological commitments discussed earlier for connecting data sources and transforming abstract characteristics into variable with real values. >ormulation of rules is done with formal analysis of problem domains in #P# #$. (&iom representation is based on situation calculus and predicate calculus for representing dynamically changing world. #ituation theory views domain as having a state !or situation". Ahen the state is changed there is necessity for an action. Predicate theory defines conditions on which specific actions can be taken. #P# #$ specific e&ample can be the statement that each product should have demand. This can be formulated as Exist !demand p r oduct " . (nother e&ample of an a&iom can be the inventory constraint* Less ! MaxIn ento!" Cu!!In ento!" " . (n e&ample of an algorithm !5" can be the formula according to which order size is calculated. %f inventory level !%H" is less than the calculated reorder level an order is placed which is equal to the difference of reorder and inventory levels. This a&iom can be formulated as* #oss !do!! L I AVG + $ I ST% " = s " > I& " Ma'eO!de! ! s I& " were s is the reorder level H is lead-time (;G #TB are forecasted demand means and standard deviation z is customer service indicator. Assem!ly0 (ssembly is an e&plicit representation of conceptualization captured in the previous stage in some formal language. This involves* +" committing to the basic terms that will be used to specify the ontology ," choosing a representation language and -" writing the code. ( supp&"(chain(ma!'up(&an)ua)e !#$6H" for presenting knowledge about #$ is being proposed. The specification of #$6H is formulated as a J6H #chema Befinition !J#B" file. %t reflects system representation formalism presented in system ta&onomy viz. at the top level there are seven groupings representing seven components of a #ystem* input output functions environment processes agents and mechanisms. 2ach grouping is a container which consists of subclasses. #cript + depicts two a&ioms formulated with #$6H. These a&ioms are formal representation of situations and conditions that can take place in #$ domain and identified by domain e&perts from industry. The first service level a&iom describes the condition where <#ervice HevelK is +44L only when %nventory level is always higher than demand. Ontological commitments build data model by connecting problem ta&onomy to database systems.
7S!pplyC/ain8 7Axioms8 7R!le ,!mber9:": ,ame9:Ser3ice le3el is "((;:8 7Arg!ment ,ame9:In3: Description9:In3entory:<8 7Arg!ment ,ame9:Dm: Description9:Demand:<8 7&ody8In3=gt>9Dm7<&ody8 7R!le ,!mber9:?: ,ame9:Reso!rce !tili5ation s/o!ld be less t/en its capacity:8 7Arg!ment ,ame9:R@0: Description9:Reso!rce !tili5ation:<8 7Arg!ment ,ame9:R@C: Description9:Reso!rce capacity:<8 7&ody8R@0=gt>9R@C7<&ody8 7<R!le8

3ule Ob9ect with two parameters stating the situation when service level is +44L This rule is a constraint stating utilization cannot be more than the capacity

#ubmitted as $onference Proceedings +-th (nnual %ndustrial 2ngineering 3esearch $onference !%23$ ,44." 5ouston Te&as 6ay +7-+8 ,44..

7<S!pplyC/ain8

#cript +. Ontology (&ioms for #$ scheduling problem Storage0 The purpose of building Ontology #erver is to enable technology that will provide large-scale reuse of ontologies not only inside the enterprise but also for large #$ community through Aeb interfaces. Ontology ob9ects are stored in J6H format interfaced with a web server. J6H formalism allows ontologies to be accessed as web pages and viewed using %nternet browsers constituting a semantic web wherein software programs !agents" can search navigate and browse %nternet resources and e&tract necessary knowledge. Usage0 Ontology consumers are human users or computerized software agents. (gents) application for %# design is rapidly increasing where ontologies carry the knowledge necessary for agents) operations. (gents as carriers of knowledge and distributors play significant role in knowledge management and engineering 0M1. %n this paper #$ is viewed as being managed by a set of intelligent agents each responsible for one or more tasks in #$ and each interacting with other agents in the planning and e&ecution of their responsibilities. 2very agent requires specific knowledge with which to operate. Ontologies provide this knowledge and advise the system user of the vocabulary for representing domain or problem knowledge. Ontologies are also crucial for enabling knowledge level interoperations of agents. (s ontology consumers agents are programmed to find the necessary knowledge in ontology server. O!+ect model is an instance of ontology model. Ahen ontology is downloaded it collects data using ontological commitments which are implemented as B$O6 programs fills J6H data model structure with content and delivers it to system users. %f the same ontology is accessed another time the ob9ect model can be different from the previous access time since #$ members can change real data.

Conclusion
Ontology driven knowledge design for #$ domain is demonstrated in this paper. Ontological principles are utilized for capturing the knowledge about organizational and problem domains. ( case study demonstrates how ontology can be designed and used to integrate activities in supply chain. >or intelligent supply chain management software agents performing functions to coordinate supply chain activities and decisions are utilized. (gents are ontology users that search find and consume knowledge encapsulated in ontologies.

Ac*nowledgement
This research is funded by grants from Nniversity of 6ichigan-Bearborn under the 3esearch 2&cellence and 2conomic Bevelopment >und and >ord 6otor $ompany under the Nniversity 3esearch Program for ,444-4-.

1eferences
+. ,. -. .. /. 7. M. Gruber T.3. +OO-. <( translation approach to portable ontologiesK *now&ed)e(Ac+uisition /!," pp. +OO-,,4. Guarino ?. +OO8. <>ormal Ontology and %nformation systemsK. #!oceedin)s(o,(-OIS./0 (msterdam %O# Press. Nschold 6. GrPninger 6. +OO7. =O?TOHOG%2#* Principles 6ethods and (pplications= *now&ed)e ( En)inee!in)(!e iew(++!," pp. O--+//. Bing Q. ,44+. <( review of ontologies with the #emantic Aeb in viewK Jou!na&(o,(In,o!mation(Science ,44+. ,M!7"* p. -MM--88. $handra $. Tumanyan (. ,44-. a. =#upply $hain #ystem Ta&onomy* development and application= #!oceedin)(o,(IERC12334 Portland Oregon N#( >o& 6. 'arbuceanu 6. Teigen 3. ,444. <(gent-Oriented #upply-$hain 6anagementK The(Inte!nationa&( Jou!na&(o,(-&exi5&e(Manu,actu!in)(S"stems6 +, pp. +7/@+88 Aooldridge 6. Eennings ?. 3. +OO/. =%ntelligent (gents* Theory and Practice.= *now&ed)e (En)inee!in) ( Re iew +4!," pp.++/-+7+.

#ubmitted as $onference Proceedings +-th (nnual %ndustrial 2ngineering 3esearch $onference !%23$ ,44." 5ouston Te&as 6ay +7-+8 ,44..