Ontology Driven Knowledge Design and Development for Supply Chain Management Charu Chandra, Armen Tumanyan University of Michigan – Dearborn Industrial and Manufacturing Systems Engineering Department Dearborn, Michigan 48128, USA Abstract 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 Introduction One of the key issues in managing a supply chain (SC) is integration among its constituents. To facilitate integration, SC information resources ought to be effectively organized and shared. Information integration provides channels that convey information from one SC constituent to another. One form of this problem involves the integration of existing implementations that have been built in heterogeneous infrastructures, viz., different hardware platforms, operating systems, and database management systems. By 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 SC, 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. Another 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 SC member’s collaborative activities to provide performance improvement to each member and to the entire SC. The process of information integration in a SC can be decomposed into the following components: (1) standardization of information representation, (2) shared vocabulary, (3) problem-oriented data conceptualization, (4) transparency of information, and (5) standardization of information access and retrieval. Ontology is a promising construct in the pursuit of information integration for the following reasons: (1) ontology is a shared and common understanding of a domain that can be communicated across people and computers [1, 2, 3] and help access information they need. By providing shared domain theories, ontologies can be the key assets for information organization . (2) 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 exponentially and impacting the decision modeling process. Ontology, as a formal explicit specification of a shared conceptualization offers a practical solution grounded in proven theoretical constructs, for designing SC organizational and problem knowledge to facilitate information integration. Knowledge types: organizational and problem domains Two main forms of knowledge have been identified as potentially sharable and reusable, viz., 1) problem-solving methods, describing steps to be taken in performing a task, and 2) 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. It describes modeling of organizational specific knowledge (organizational ontology) Submitted as Conference Proceedings, 13th Annual Industrial Engineering Research Conference (IERC 2004), Houston, Texas, May 16-18, 2004. 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 experts’ domains, into explicit models. Human 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, object schema for object oriented systems, conceptual schema for databases, structured glossaries for human collaborations, vocabularies for communication between agents, and class definitions for conventional software systems. Ontology background: definitions, projects Ontology refers to an engineering artifact, constituted by a specific vocabulary, used to describe a certain reality, in addition to a set of explicit assumptions regarding the intended meaning of words in the vocabulary . One of the logical ways of representing SC knowledge is in the form of hierarchy of concepts embedded in its structure. Chandra and Tumanyan  have described system taxonomy as a method for building this hierarchy. Models encapsulate concepts applied to solving real problems. Models acquire their realism through assumptions, which express relationships between concepts. Axioms describe model assumptions with the rule-based formalism. Axiom development is an important step in designing appropriate knowledge for problem solving. As described in a later section, SC ontologies are conceptualized based on model assumptions that convey information requirements for a SC system. Many research efforts are committed to applying ontological principles for designing organizational and problem knowledge. The most significant projects in this field are briefly described in this section. TOVE (http://www.eil.utoronto.ca/enterprise-modelling/tove) project is focused on the enterprise modeling, concurrent engineering and integrated supply chain management . TOVE ontology provides reach and precise representation of generic knowledge, such as activities, processes, time and causality, and enterprise- oriented 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 IT 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 project involves collecting examples of how different organizations perform similar processes, and organizing these examples in an on-line “Process handbook". These repositories can be used to share and manage knowledge about existing businesses and to generate innovative ideas about new business possibilities. The Enterprise project (http://www.aiai.ed.ac.uk/project/enterprise/enterprise/ontology.html) is a major initiative to promote the use of knowledge-based systems in enterprise modeling, aiming to support organizations effectively in the Management of Change. Components of the Enterprise Toolset, developed in the scope of this project include: a Procedure Builder for capturing process models, an Agent Toolkit for supporting the development of agents, a Task Manager for integration, visualization, and support for process enactment, and enterprise ontology for communication. Ontology conceptualization: a framework 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. Based on information integration requirements presented in the Introduction Section and serving the needs of the decision-modeling system, following assumptions are made for ontology conceptualization: (1) systematic principles for knowledge conceptualization, (2) problem specific nature of ontology constructs, (3) modularity and object nature of formed knowledge, (4) reusability of created knowledge, (5) integration of distributed data, and (6) machine readable format of delivered knowledge. These assumptions provide the scope of functional requirements for the ontology conceptualization framework depicted in Figure 1. It consists of four layers of information abstraction. The upper layers are meta-models for developing the lower layers. It starts with the SC system taxonomy, which is a systematic classification of Submitted as Conference Proceedings, 13th Annual Industrial Engineering Research Conference (IERC 2004), Houston, Texas, May 16-18, 2004. organizational and problem domain characteristics and describes concepts and their relationships . System taxonomy is developed through examination of the SC domain and its problems. System taxonomy comprises the entire SC system and its problem-solving components, designed to address specific SC issues or problems. Projecting the problem specific issues from system taxonomy generates many SC problem model taxonomies for many sub-models. Studying the problem space with its related characteristics and concepts does this projection. Problem model taxonomy serves as a meta-model for knowledge model generation and ontology development. Based on the concepts and characteristics inherited from Problem Model Taxonomy, rules and regulations held on organization or problem domain are formulated utilizing the concepts of ontology development. Subject Classification Domain System Taxonomy Projection Problem Model Taxonomy Domain Space Knowledge generation Identification Problem Axioms Domain Identification Ontology Commitments Repository Instantiation Object Model Figure 1. The conceptual framework of Ontology development Ontology inherits its structure and vocabulary from problem model taxonomy, 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: (1) axioms - defines rules and regulations specific to a problem domain, (2) algorithms - provides step-by-step procedures for approaching the problem and solving it, and (3) 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. System analysis and design techniques are applied here, such as process modeling and object-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. Real world applications require data to operate with. Ontological commitments provide these data. Object 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 Notations S – System Bw , Bc , Bh – Observation channels for defining T – Thing symbolizing the elements of system variables, constraints, and algorithms respectively R – Relationships among things of system defined on T J – Set of Interpretation functions I W – Class instances of S for SC domain M w – Data model for SC problem w – The instance of class W C – Constraints on data Sw – Specific system for SC domain (an instance of S) O – Ontology model Tw – Things specific to SC domain (an instance of T) A – Set of axioms Rw – Set of relationships held on Tw H – Algorithm or heuristics M – Data model for SC domain G – Set of equations I – Ontological commitments. Functions interpreting characteristics into variables V – Set of variables The approach for system representation can be formulated as follows: S = (T, R). Detailed description of taxonomy of system in general can be found in Chandra and Tumanyan . Formally SC system can be represented as a collection of all possible instances of generic system applied to SC, with corresponding relationships: S (T , W, R) . For each possible system instance w W , the intended structure of w according to S is the structure: Sw (Tw , R w ) , R w is the set of extensions (relative to w) of elements of T. R Rw | w W . We denote with S, the set of all the intended system instance structures of system. S Sw | w W . Sw is a description of a Submitted as Conference Proceedings, 13th Annual Industrial Engineering Research Conference (IERC 2004), Houston, Texas, May 16-18, 2004. problem (problem model taxonomy) to be solved. Sw contains names of parameters identified in problem description with corresponding relationships organized in a structured hierarchy. Ontology development starts with this structured vocabulary and ties them to variables. Problem model taxonomy Sw 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. Rearranging the standard definition, a model M is defined as a structure (S, I), where S=(T, R) is a world structure (standard system definition) and I is an interpretation function, which through observation channel B assigns attributes of T to variables of V: M (S , I) , I (V Tw Bw ) . Observation channel, Bw predicates variables V. This intentional interpretation can be classified as the first ontological commitment. Observation channels are situations, where the system state is captured to observe variables V. These can be process models where required variables participate. Studying documented process model may reveal the meaning of variables and where they can be taken from. Another example 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 , W, R, J) . These are data model for system in general, including its all instances, and all possible interpretations. Rather, data models presentation for specific system instances can be formulated: M w (Tw , R w , I) assuming that Sw S , for each instance w W . 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. A model can describe a situation common to many states. The second ontological commitment is the application of logical axioms 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. It can be defined as an organizational or problem knowledge that contains concepts with relationships, axioms; and if it is a problem ontology, problem reasoning algorithms. This proposition is formally presented O (M , A, H) . A is a set of axioms for assigning constraints to variables through BC observation channel, A (C V BC ) . H is a set of algorithms for assigning mechanisms (G) to data model processing, through BH observation channel, H (G M BH ) . Ontology consists of three components: data model (M), axioms (A), and algorithms (H). For 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. A demonstration of ontology development process is done based on a case study of a pilot project to design a knowledge base for a decision support system for steel processing and shipment (SPS) SC. SPS is a multi-stage manufacturing process. The automobile SC consists of several raw material suppliers and a stamping plant (Figure 2), 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. Welding and other operations are performed on stamped parts at the metal assembly department. Raw material supplier 1 Stamping Raw material supplier 2 Blanking 1 Pressing 1 Assembly 1 Raw material supplier 3 Blanking 2 Pressing 2 Assembly 2 Raw material supplier 4 Figure 2 Steel processing and shipment supply chain The Ontology development framework assumes four stages of information modeling: 1) taxonomy, 2) problem model, 3) ontology model, and 4) object model. Taxonomy development is discussed in Chandra and Tumanyan . Problem model development starts with studying the problem and its information needs. Thorough analysis of SPS SC 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 taxonomy. The process of this transformation is finding classes, where above characteristics reside and projecting these into a new hierarchy: problem model taxonomy. The transformed diagram is depicted in Figure 3. Submitted as Conference Proceedings, 13th Annual Industrial Engineering Research Conference (IERC 2004), Houston, Texas, May 16-18, 2004. SteelSupplyChain Output Mechanism Agent 1 ProductionUnit -S tag e:in t Product 0 ..* -PU ID:int Structure Resource -PU Name :in t -Pro d u c tT yp e:in t 0 1 ..* -Pro d u c tS tatu s:in t -Nu mb er o fHo u rs :in t 1 1 -Pro d u c tS ize:in t 0 ..* ProductProduction ProductCost -R eso u r ceName:int -Pro d u c tID:int -S h ift:in t 0 ..* 0 ..* Cost -Pro d u c tName :in t 1 -Pro d u c tio n Tim e:in t -In ven to r yHo ld in g Co s t:in t -T o ta lC ap acity:in t Transportation -Pro d u c tQ u an tity:in t ProductStructure -S etu p T im e:in t -Pro c essin g Co s t:in t -F ix ed C o st:in t -R eso u r ce:in t -Pro d u c tS etu p Co s t:in t -T ran s p o rtatio n Date:in t -Q u an tity:in t -O th er Co s t:in t -Bre akDo wn Du ra tio n P 1:in t -Pro d u c tC o st:in t -T ran s p o rtatio n T ime:int -M ater ialID:in t -T ran s p o rtatio n C o st:in t -Bre akDo wn Du ra tio n P 2:in t -Per io d :in t -T ran s p o rtatio n T yp e :in t -Pro d u c tID:int 1 -Bre akDo wn Du ra tio n T y p e:in t -Destin atio n :in t Demand 1 ..* -Deffectiven es sP1 :in t -Deffectiven es sP2 :in t ResourceAttributes -Q u an tityA c cu mu lative:in t -Deffectiven es sT yp e:in t -Dem an d Ne t:in t -Bre akDo wn F r eq u en cyP1 :in t -C ap acity:in t -C o sto mer:int -Bre akDo wn F r eq u en cyP2 :in t -S ch ed u led R ate :in t -Per io d :in t -Bre akDo wn F r eq u en cyT yp e:int -Y ield :in t -Pro d u c tID:int Figure 3 Configuration / scheduling problem model taxonomy Ontology model development is concerned with capturing, assembling, storing, and using of ontology constituents, which are data model, axioms, and algorithms. Capture. Data model is captured by inheriting data structure from problem model taxonomy and adding ontological commitments discussed earlier for connecting data sources and transforming abstract characteristics into variable with real values. Formulation of rules is done with formal analysis of problem domains in SPS SC. Axiom representation is based on situation calculus and predicate calculus for representing dynamically changing world. Situation theory views domain as having a state (or situation). When the state is changed, there is necessity for an action. Predicate theory defines conditions on which specific actions can be taken. SPS SC specific example can be the statement that each product should have demand. This can be formulated as Exist (demand , p r oduct ) . Another example of an axiom can be the inventory constraint: Less(MaxInventory, CurrInventory) . An example of an algorithm (H) can be the formula according to which order size is calculated. If inventory level (IL) is less than the calculated reorder level, an order is placed, which is equal to the difference of reorder and inventory levels. This axiom can be formulated as: Poss(do(( L * AVG z * STD) s) Il ) MakeOrder(s Il ) , were s is the reorder level, L is lead-time, AVG, STD are forecasted demand means and standard deviation, z is customer service indicator. Assembly. Assembly is an explicit representation of conceptualization captured in the previous stage in some formal language. This involves: 1) committing to the basic terms that will be used to specify the ontology, 2) choosing a representation language, and 3) writing the code. A supply chain markup language (SCML) for presenting knowledge about SC is being proposed. The specification of SCML is formulated as a XML Schema Definition (XSD) file. It reflects system representation formalism presented in system taxonomy, viz. at the top level there are seven groupings representing seven components of a System: input, output, functions, environment, processes, agents, and mechanisms. Each grouping is a container, which consists of subclasses. Script 1 depicts two axioms formulated with SCML. These axioms are formal representation of situations and conditions that can take place in SC domain and identified by domain experts from industry. The first, service level axiom describes the condition, where “Service Level” is 100%, only when Inventory level is always higher than demand. Ontological commitments build data model by connecting problem taxonomy to database systems. <SupplyChain> <Axioms> <Rule Number="1" Name="Service level is 100%"> Rule Object with two parameters stating the situation <Argument Name="Inv" Description="Inventory"/> when service level is 100% <Argument Name="Dm" Description="Demand"/> <Body>Inv>=Dm</Body> <Rule Number="5" Name="Resource utilization should be less then its capacity"> <Argument Name="R_U" Description="Resource utilization"/> This rule is a constraint stating utilization <Argument Name="R_C" Description="Resource capacity"/> cannot be more than the capacity <Body>R_U>=R_C</Body> </Rule> </SupplyChain> Script 1. Ontology Axioms for SC scheduling problem Submitted as Conference Proceedings, 13th Annual Industrial Engineering Research Conference (IERC 2004), Houston, Texas, May 16-18, 2004. Storage. The purpose of building Ontology Server is to enable technology that will provide large-scale reuse of ontologies, not only inside the enterprise, but also for large SC community through Web interfaces. Ontology objects are stored in XML format interfaced with a web server. XML formalism allows ontologies to be accessed as web pages and viewed using Internet browsers, constituting a semantic web, wherein software programs (agents) can search, navigate and browse Internet resources and extract necessary knowledge. Usage. Ontology consumers are human users or computerized software agents. Agents’ application for IS design is rapidly increasing, where ontologies carry the knowledge necessary for agents’ operations. Agents as carriers of knowledge and distributors play significant role in knowledge management and engineering . In this paper, SC is viewed as being managed by a set of intelligent agents, each responsible for one or more tasks in SC, and each interacting with other agents in the planning and execution of their responsibilities. Every 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. As ontology consumers, agents are programmed to find the necessary knowledge in ontology server. Object model is an instance of ontology model. When ontology is downloaded, it collects data using ontological commitments, which are implemented as DCOM programs, fills XML data model structure with content and delivers it to system users. If the same ontology is accessed another time, the object model can be different from the previous access time, since SC members can change real data. Conclusion Ontology driven knowledge design for SC domain is demonstrated in this paper. Ontological principles are utilized for capturing the knowledge about organizational and problem domains. A case study demonstrates how ontology can be designed and used to integrate activities in supply chain. For intelligent supply chain management, software agents performing functions to coordinate supply chain activities and decisions are utilized. Agents are ontology users that search, find, and consume knowledge encapsulated in ontologies. Acknowledgement This research is funded by grants from University of Michigan-Dearborn under the Research Excellence and Economic Development Fund, and Ford Motor Company under the University Research Program for 2000-03. References 1. Gruber, T.R. 1993. “A translation approach to portable ontologies”, Knowledge Acquisition, 5(2), pp. 199-220. 2. Guarino, N. 1998. “Formal Ontology and Information systems”. Proceedings of FOIS'98, Amsterdam, IOS Press. 3. Uschold, M., Grüninger M., 1996. "ONTOLOGIES: Principles, Methods and Applications" Knowledge Engineering review 11(2), pp. 93-155. 4. Ding, Y. 2001. “A review of ontologies with the Semantic Web in view”, Journal of Information Science, 2001. 27(6): p. 377-388. 5. Chandra, C., Tumanyan, A., 2003. a. "Supply Chain System Taxonomy: development and application" Proceeding of IERC’2003, Portland, Oregon, USA 6. Fox, M., Barbuceanu, M., Teigen, R. 2000. “Agent-Oriented Supply-Chain Management”, The International Journal of Flexible Manufacturing Systems, 12, pp. 165–188 7. Wooldridge, M., Jennings, N. R. 1995. "Intelligent Agents: Theory and Practice." Knowledge Engineering Review 10(2) pp.115-161. Submitted as Conference Proceedings, 13th Annual Industrial Engineering Research Conference (IERC 2004), Houston, Texas, May 16-18, 2004.