OntoCAPE—A large-scale ontology for chemical process engineering

ARTICLE IN PRESS

Engineering Applications of Artificial Intelligence 20 (2007) 147–161 www.elsevier.com/locate/engappai

OntoCAPE—A large-scale ontology for chemical process engineering Jan Morbach, Aidong Yang1, Wolfgang Marquardt Lehrstuhl fu¨r Prozesstechnik, RWTH Aachen University, Turmstr. 46, 52064 Aachen, Germany Received 30 September 2005; received in revised form 2 June 2006; accepted 28 June 2006 Available online 7 September 2006

Abstract An overview on OntoCAPE, a large-scale ontology for chemical process engineering, is given, and the development and some applications of OntoCAPE are reported. The methodology adopted for developing OntoCAPE is described to show how the ontology has evolved from its skeletal, informal specification to a complete, formal specification. Furthermore, the organization of the ontology is addressed through presenting its modular, layered structure. It is shown that this design enables a proper balance between usability and reusability of this ontology and that it provides a principled guidance for a better understanding and an easier further development. Some exemplary applications of OntoCAPE in the area of computer-aided process engineering are sketched to demonstrate the ontology’s range of use. It is shown which advantageous features of OntoCAPE facilitate the handling of the changes of such a complex engineering ontology over a long period of evolution. A comprehensive environment providing adequate computer support for the evolution of complex ontologies is envisioned. r 2006 Elsevier Ltd. All rights reserved. Keywords: Ontology; Methodology; Structural design; Ontology evolution; Chemical engineering; Semantic annotation; Mathematical modeling; Computer-aided process engineering

1. Introduction An ontology is an ‘‘explicit specification of a conceptualization’’ (Gruber, 1993). Ontologies aim to capture consensual knowledge in a generic way; they may be reused and shared across software applications and by groups of people (Go´mez-Pe´rez et al., 2004). They can be represented in various kinds of languages and with different degrees of formality (Uschold and Gru¨ninger, 1996). They can also differ with respect to the richness of their internal structure (Lassila and McGuiness, 2001), ranging from lightweight ontologies, which are simple taxonomies or controlled vocabularies, to heavyweight ontologies, which specify relations and logical constraints between the ontological terms using expressive ontology languages (Go´mez-Pe´rez et al., 2004). According to their ‘‘subject of conceptualization’’ (van Heijst et al., 1997), ontologies can be classified into Corresponding author. Tel.:+49 241 8094668; fax:+49 241 8092326.

E-mail address: [email protected] (W. Marquardt). Current address: School of Chemical Engineering and Advanced Materials, University of Newcastle, Newcastle upon Tyne NE3 3RT, UK. 1

0952-1976/$ - see front matter r 2006 Elsevier Ltd. All rights reserved. doi:10.1016/j.engappai.2006.06.010

representation ontologies, generic (or common) ontologies, top-level (or upper-level) ontologies, domain ontologies, task ontologies, method ontologies, and application ontologies (Go´mez-Pe´rez et al, 2004). Among them, domain ontologies express conceptualizations that are specific for certain domains. In particular, there have been a number of ontologies developed for the engineering domains, such as PhysSys for modeling generic physical systems (Borst, 1997), EngMath which formulates fundamental mathematical concepts for engineering modeling (Gruber and Olsen, 1994), and YMIR for representing engineering design knowledge (Alberts, 1994). Batres et al. (2005) are developing an upper-level ontology for the chemical engineering domain based on the ISO 15296 standard (ISO, 2003), which can be used to represent knowledge about hazards and operability studies of chemical plants. In this contribution, we report on the development and application of OntoCAPE, a formal, heavyweight ontology for the domain of (chemical) process engineering. In this domain, the design, construction, and operations of chemical plants are considered as the major engineering activities. In the past decades, various computing technologies

ARTICLE IN PRESS 148

J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

have been widely applied to support the above activities. The research field for promoting these applications is known as Computer-Aided Process Engineering (CAPE). OntoCAPE, named after the idea of developing an ontology for CAPE, has initially been developed in the COGents project (Braunschweig et al., 2004), which explores an agent-based architecture for numerical simulation of chemical processes. Its development has been continued in the IMPROVE project (Marquardt and Nagl, 2004), which focuses on new concepts and software engineering solutions to support collaborative engineering design processes. In this paper, we describe the development of OntoCAPE as well as some of its applications in process modeling and design. The methodology adopted in developing OntoCAPE, the structural design of OntoCAPE, and an overview of the informal and formal specifications of OntoCAPE are presented in Sections 2, 3, and 4, respectively. In Section 5, various applications of OntoCAPE are described. Since OntoCAPE is in fact the result of a long-term ontological development effort, we discuss issues with respect to supporting the evolution of large-scale, complex ontologies in Section 6. 2. Methodology for developing OntoCAPE A methodology for developing ontologies determines the major development stages and proposes guidelines for each stage. A handful of methodologies have been proposed since the mid 1990s; a comparative review on some methodologies has been presented recently by Go´mezPe´rez et al. (2004). Not surprisingly, several development stages are common to all of those methodologies, obviously influenced by the lifecycle concept from software engineering. Typical stages, often considered iteratively instead of purely sequentially, include requirements analysis, conceptualization, formalization, and maintenance. In addition to those stages, some of the methodologies (e.g., METHONTOLOGY, Ferna´ndez-Lopez et al., 1997), suggest to routinely perform certain activities at each stage, such as documentation and evaluation. The methodology adopted for developing OntoCAPE consists of stages including requirements analysis, collection of reusable resources, skeletal and full informal specification, formal specification, and maintenance (cf. Fig. 1). Iterations

between different stages should be performed as necessary; they are not shown in Fig. 1, but elaborated later in this section. At each stage, documentation and evaluation are required in addition to the development work. In the following, the tasks performed and the guidelines adopted in each stage are explained in more detail. Requirements analysis: In this stage, the major requirements to OntoCAPE are specified in terms of purpose, scope, use cases to be supported, and formalisms. Uschold and Gru¨ninger (1996) suggested the use of motivating scenarios and (informal) competency questions for identifying requirements. For the requirements analysis of OntoCAPE, detailed case studies have been developed by domain experts. These case studies cover topics ranging from process modeling, simulation to design. Each case study articulates one or a few use cases, each of which in turn describes the goal to be achieved, the sequence of issues to be addressed, and possible methods/techniques to be employed. To a large extent, the descriptions of the major use cases have rendered a nice coverage of the important competency questions one can ask, the decomposition of those questions, as well as the answers to them. Therefore, the case studies have been used as an important input for developing OntoCAPE. OntoCAPE should eventually provide concepts (aka classes) and properties (aka relations and/or attributes), which are sufficient to represent all information on the case studies. Of course, this requirement only addresses the sole needs of the case studies explicitly considered, which is not sufficient considering OntoCAPE’s broader goal of being a largely general domain ontology for CAPE. However, since a complete domain theory is lacking in almost any complex (engineering) domain, such an inductive approach seems to be the only viable strategy. In order to be successfully in an evolutionary development process, the ontology has to be extensible. We will come back to this issue later in Section 6. Collection of reusable resources: In this stage, existing ontologies and conceptual data models relevant to the scope of OntoCAPE have been reviewed to identify reusable parts of relevance. Design features adopted by some of these ontologies or data models, in aspects such as inclusion of multiple layers and modularization, have been reviewed, as well. Special attention has been paid to

Maintenance

Formal specification Requirements analysis

Resource collection

Skeletal informal specification

Full informal specification

Time Fig. 1. Stages in the OntoCAPE development process.

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

ontologies concerning physical systems modeling such as PhysSys (Borst, 1997), mathematical modeling such as EngMath (Gruber and Olsen, 1994) and CapeML (von Wedel, 2002), and particularly process plant information modeling such as VeDa (Bogusch et al., 1998) and CLiP (Bayer and Marquardt, 2004). Skeletal and full informal specification: In this stage, an informal representation of OntoCAPE has been produced for the purposes of (1) communicating the conceptualization to project team members and other interested people using graphics and natural language, and (2) providing a basis for developing the formal specification. Concretely, those concepts and their relations, which are indispensable for reflecting the case studies, have been identified and defined. Because OntoCAPE must well support several case studies with widely differing scopes specified by different project partners, it is important to get timely feedback on the decisions taken during the ontology development process. For this purpose, two steps have been taken to accomplish the informal specification. In the first step, a ‘‘skeleton’’ of OntoCAPE is proposed. The so-called skeletal informal specification is a document presenting a designed structure of the ontology (cf. Section 3), that is, it describes the major partial models and modules within the ontology and determines their relations on a coarse level. Further, it specifies a number of key concepts required by the case studies, such as chemical process system or software system. After the skeletal informal specification has been reviewed by the project team members, it is further elaborated into a detailed specification in a second step. The so-called full informal specification of OntoCAPE (as of version 1.0) has been documented in about 200 pages, which makes a thorough review very time consuming and essentially impractical given the time constraints imposed on any project team. In fact, the comments from team members were focused only on specific parts of the lengthy document that were of their special interests. Consequently, no critical review could be achieved on the entire ontology. Fortunately, the skeletal informal specification, the length of which is just about one fifth of that of the full ontology, has been carefully reviewed by the team members. Since the skeletal informal specification comprises all the major decisions about the design of OntoCAPE, the review on it had essentially provided an opportunity for the whole project team to genuinely reach an agreement on the high-level contents of the entire ontology. Hence, such a two-step procedure is strongly recommended in any realistic development process. Formal specification: In this stage, the informal specification of OntoCAPE is formalized by means of an ontology modeling language to generate a formal specification. Such a formal representation allows the ontology to be used and interpreted by an information system. Further, certain verifications of the ontology, including consistency checking and classification, can be performed automatically by means of ontology reasoning tools.

149

Maintenance: The informal and the formal specifications of OntoCAPE are updated when changes are suggested during the evaluation, or when new requirements are introduced while the ontology is applied in software development. It is important to keep the informal and formal specifications consistently updated. Each update has to be approved by affected team members who have proposed and/or implemented relevant case studies. The maintenance history has to be documented. We have mentioned earlier the necessity of performing iterations between different stages. Concretely speaking, it is not uncommon to go back and forth between the formal and informal specifications as progress on the former may uncover problems on the latter. Besides, work on the full specifications may reveal, though not frequently, high-level deficiencies which make it necessary to revise the skeletal specification. Similarly, requirements analysis may have to be revisited, for example to enhance clarity to facilitate development in the following stages. In the next two sections, we will present in detail the results of the two major stages where the specifications of OntoCAPE are produced. Firstly, we will discuss the structural design of OntoCAPE in Section 3, which is the most important activity in constructing the skeleton of the ontology. Following that, the informal and formal specifications of OntoCAPE are described in Section 4. 3. Structural design As for any complex system, a sound structure is critical for a large-scale ontology to (1) facilitate its efficient construction and maintenance in a long run and (2) allow an easy adaptation to different areas of application. In the following, we discuss how this concern has been addressed in developing OntoCAPE. 3.1. Types of structural elements Fig. 2 shows the structure of OntoCAPE. It can be observed that the ontology is organized by means of three types of structural elements: layers, modules, and partial models. Layers subdivide the ontology into five levels of abstraction, thus separating general knowledge from knowledge about particular domains and applications. The design of each layer follows the principle of ‘‘minimal ontological commitment’’ (Gruber, 1995), meaning that a layer holds only those terms that are essential for its function. Concepts and refinements not directly related to the layer’s purpose are sourced out to lower layers. The topmost meta layer is the most abstract one: It introduces fundamental root terms and design patterns that are to be used on the lower layers. The upper layer describes the overall design paradigm according to which the domain ontology is organized: OntoCAPE is based on general systems theory (e.g., Bunge, 1979; van Gigch, 1991), which is a common organizing principle for ontologies in

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

150

notation meta model

core ontology

module

core_ontology (application-dependent)

meta_motel

Layer

inlcudes

Meta Layer module Onto CAPE upper level

partial model tensor_quantity

coordinate_system

Layer

system system

partial model

Upper Layer chemical process system

supporting concepts

physical dimension

mathematical relation

SI_unit

space and_time

chemical_process_system processing sub system plant

Conceptual Layer

chemical process material

cost_model

phase_system

processing subsystem

cost operating subsystem

software system

software system model mathematical model

substance process model substance

behavior

process

model

operating subsystem

process geometry

material

process_model

process units TGL_25000 classification scheme_A TGL_25000 classification scheme_B

atomic species

process_ units

mixing unit

molecular species

splitting unit

property models laws

process modeling software

polymers

flash_unit

chemical_reactor

process_ unit_model

simulation

modeling_task specification

numerical solution strategy

heat_transfer_unit

distillation_system Applicationoriented Layer applications annotation_of Aspen_Plus_model_files Applicationspecific Layer

Fig. 2. Structure of OntoCAPE.

engineering (Alberts, 1994; Borst, 1997; Bayer and Marquardt, 2004). On the conceptual layer, a conceptual model of the CAPE domain is established. The subsequent layers elaborate the conceptual model by adding concepts of practical relevance for certain tasks and applications; thereby, the application-oriented layer describes the diverse application areas in general, whereas the applicationspecific layer aims at concrete tasks and applications. Modules assemble a number of classes that cover a common topic as well as the relations describing the interactions between the classes and the constraints defined on them. A module can be designed, adapted, and reused to some extent independently from other parts of an ontology (Stuckenschmidt and Klein, 2003). That way, the

ontology is decomposed into an ‘‘inclusion lattice’’ (Gruber and Olsen, 1994) of individual subontologies. Inclusion means that if module A includes module B, the ontological assertions provided by B are included in A. Inclusion is transitive, that is, if module B includes another module C, the ontological assertions specified in C will also be valid in A. Modules that address closely related topics are grouped into partial models. The partial models constitute a coarse categorization of the domain. Unlike modules, partial models may stretch across several layers. While the boundaries of the modules are chosen for practical considerations (such that the interactions between modules are minimized to facilitate their handling), the boundaries

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

of the partial models reflect the ‘‘natural’’ thematic boundaries of the domain and are therefore less likely to change in the course of ontology evolution. As there is no unique way of modeling an area of interest, different variants of an ontology module may evolve. These variants represent alternative conceptualizations of the subject covered by the module. For example, variants may arise whenever the ontology is adapted to a new area of application, since a new task may imply a different view on the domain and consequently a different conceptualization (Noy and Klein, 2004). Examples to back up this general statement will be presented in Sections 3.2 and 6. While the partial model structure is chosen according to general organizing principles (to be briefly explained in Section 3.2), their subdivision into modules and variants follows practical reasons, aiming at an easy management of classes and relations with respect to the application at hand. In the course of ontology evolution (cf. Section 6), the partial module structure is therefore supposed to remain relatively stable, whereas the number of modules as well as their content and interrelations are likely to change over time in order to comply with new applications. 3.2. Semantic content The meta-layer on top of OntoCAPE holds two partial models: the meta model and the core ontology. The meta model introduces meta root terms, generic concepts, and design patterns.







A root term is a term without ancestors. Meta-root terms denote fundamental classes and relations in the metamodel, such as object or n-ary relation, from which all root terms introduced on the lower layers should be derived. Their function is to promote a shared understanding of the root terms introduced on the lower layers and of the role that they play within the ontology. Generic concepts are domain-independent classes or relations that are used throughout the entire ontology. Typical examples are mereological and topological relations (i.e., aggregation, composition, connectivity). Design patterns describe best-practice solutions to common design problems. That way, they promote a consistent, uniform design of the different ontology modules. A typical example is the modeling of an array whose elements are accessed by an index—a pattern that appears repeatedly within the ontology to define concepts like vector or coordinate set. As there are various possibilities to represent this notion in an ontology language, a design pattern has been established to specify which approach is to be employed in OntoCAPE.

The core ontology integrates the different types of ontologies that are required for a certain application. Consider for example the ontology-based process data

151

warehouse described in Section 5.3: It relies on a core ontology that links OntoCAPE with ontologies for the description of documents, work processes, and storage systems (cf. Fig. 7). Different applications require different core ontologies. The function of these core ontologies is (1) to retrieve those concepts that are relevant for the particular application from the utilized (domain) ontologies, (2) to define how these concepts are used (i.e., interpreted) by the application, and (3) to introduce additional top-level concepts required by the application that cannot be retrieved from the available ontologies. The upper layer contains three modules. The module system introduces important systems-theoretical and physicochemical primitives such as system, system property, quantity, physical dimension, unit, etc., and specifies their mutual relations: A system is characterized by its system properties, each of which can take numerous values. To distinguish the different values of a single system property, the concept of backdrop (Klir, 1985) is introduced. Adapting Klir’s definition to the terminology of OntoCAPE, a backdrop is some sort of background against which the different values of a system property can be observed. In OntoCAPE, the values of any system property can act as a backdrop to distinguish the different values of other system properties. Time and space are typical choices of such distinguishing system properties. An example is shown in Fig. 3, where, the values of the system property ‘‘time’’ are used to distinguish the different values of the system property ‘‘temperature’’ that arise in the course of an observation. Furthermore, a system can be decomposed into subsystems, some of which reflect certain aspects of the system, for instance its function, constitution, behavior, or performance (Patzak, 1982; Bayer, 2003). That way, a systemstheoretical view of the world is established as the organizing principle of the ontology, which is propagated to the lower layers. Note that the idea to use systems theory as design principle has also been used for other engineering ontologies, such as PhysSys (Borst, 1997) and YMIR (Alberts, 1994); compared to those, OntoCAPE has taken a more systematic and explicit manner through introducing the concept aspect in the module system. System is complemented by the modules tensor quantity and coordinate system. Tensor quantity extends the systems concept to multidimensional values by providing a method to define vectors and tensors, whereas coordinate system clarifies the definition and usage of the backdrop. On the conceptual layer, the CAPE domain is represented by four partial models: The most important one is the chemical process system, which can be subdivided into the processing subsystem concerned with the physicochemical processing of materials and the operating subsystem referring to the operation support systems of the processing plant.2 The partial model material provides an abstract description of materials involved in a chemical 2 Since the operating subsystem is not yet fully elaborated, only the processing subsystem is shown in Fig. 2 in detail.

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

152

is observed against backdrop has value System Property

Value

273 K Temperature

has value

notation

is observed against backdrop

285 K is observed

Class

property

Individual

instantiation

against backdrop 1h Time

has value 3h

Fig. 3. Value representation in OntoCAPE (simplified).

process, whereas model introduces notions required for a description of models and model building. Software system describes concepts like software applications, operating systems, middleware platforms, and software interfaces. Finally, the partial model supporting concepts supplies fundamental notions such as space, time, physical quantities, SI-units, mathematical relations etc., which do not directly belong to the CAPE domain but are required for defining and completing domain concepts.3 The organizing principle of general systems theory, which has been introduced on the upper layer, is taken up on the conceptual layer: With the exception of supporting concepts, each of the aforementioned partial models holds a key module that describes the main system (e.g., processing subsystem) as well as supplemental modules that describe the system and its properties under certain aspects (e.g., process describes the functional aspect of the processing subsystem). A detailed description of these issues is given elsewhere (Bayer, 2003; Yang et al., 2003; Bayer and Marquardt, 2004). The application-oriented layer extends the conceptual domain model by adding concepts needed for its practical usage. Some exemplary modules are shown in Fig. 2: Substance, which describes the intrinsic characteristics of materials, is supplemented by chemical species data for atoms, molecules, and polymers. Process, representing the functional aspect of a processing subsystem, is extended by a classification hierarchy of unit operations based on the national standard TGL 25000 (1974). Two alternative classification schemata are provided as variants of the module TGL 25000: Classification schema A uses the physical state of the processed materials as the organizing 3

The partial model supporting concepts is only rudimentarily developed, as it is not the objective of OntoCAPE to conceptualize areas that are beyond the scope of the CAPE domain.

principle, whereas classification schema B organizes the process units according to theoretical considerations (Bayer and Marquardt, 2005). The partial model process units contains descriptions of typical process units,4 that is, specialized processing subsystems, each of which is considered under the aspects of function, realization, and behavior; exemplarily shown are the modules mixing unit, splitting unit, distillation system, flash unit, chemical reactor, and shell and tube heat exchanger. Process model is extended by the modules laws, which describes typical physico-chemical phenomena of chemical process systems, and property models providing common models of physicochemical properties. Moreover, the module process unit model conceptualizes prevalent mathematical models for process units, such as models of ideal reactors (PFR, CSTR) or a distillation column model based on the MESH equations (e.g., Biegler et al., 1997). The application-specific layer holds concepts that are required for particular tasks or applications. Fig. 2 shows exemplarily a module, which has been devised for the annotation of model files in Aspen Plus format (cf. Section 5.3). 4. Informal and formal specifications According to the structural design displayed in Fig. 2, informal and formal specifications of OntoCAPE have been constructed: The term ‘‘formal specification’’ refers to the representation of the ontology in a formal language, such as DAML+OIL (Connolly et al., 2001) or OWL (Bechhofer et al., 2004). As these languages are difficult to read for humans, even with the help of graphical ontology 4

Process units are often called ‘‘unit operations’’; here we adopt the term ‘‘process units’’ instead of ‘‘unit operations’’, since the latter is intended to refer to the functional aspect of a processing subsystem.

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

editors or similar devices, a supplementary informal specification has been provided, which presents the ontology in a human-readable form.



4.1. Informal specification



The main purpose of the informal specification is to reach a shared understanding of the domain represented by OntoCAPE. To be more precise, it should provide the development team and the users of the ontology with a ‘‘shared memory’’ about the domain (according to Konda et al., 1992, ‘‘shared memory’’ is defined as ‘‘materialized, persistent shared meaning’’). To serve this purpose, all ontology modules are depicted through graphical representations. Concretely, UML-like class diagrams are used to provide a graphical view of the main interrelations between classes, individuals (instances of classes), and properties (relations between or attributes of classes), including the hierarchical organization of classes and properties. These graphical representations evolve quite naturally in the course of ontology development, as designers often like to model the area of interest graphically before specifying the ontology in a formal language. Lately, tools like DUET (CODIP (Components for Ontology Driven Information Push), 2004) and ezOWL (ETRI (Electronics and Telecommunications Research Institute), 2004) have become available, which support this modeling strategy by automatic generation of a formal representation from these diagrams. In addition to graphical illustrations, the informal specification comprises natural language descriptions of classes, properties, and individuals. Classes are characterized by the following categories in natural language:





Description: A lexical description of the class, for example ‘‘A chemical reactor is an apparatus for holding substances that are undergoing a chemical reaction.’’ (WordNet 2.1, 2005). Definition: A definition determines the semantics of a class by correlating it with other, previously established classes; classes can be correlated through specialization, through properties and property restrictions, and through class constructors, such as set expressions (intersection, union, or complement of some classes). Consider for example the definition: ‘‘A chemical reactor is a special type of apparatus that has at least one physico-chemical phenomenon, namely a chemical reaction’’. Here, the class chemical reactor is defined through the previously defined classes apparatus and chemical reaction; to the former, it is related through specialization, to the latter, it is related via the property has physico-chemical phenomenon, on which the restriction ‘‘at least one’’ is imposed. Unlike a description, a definition can be transcribed into a formal ontology language, where it establishes the set of necessary and sufficient conditions by which the membership of an ontological concept to the present class is determined.





153

Classes for which such a definition cannot be provided are called primitive classes. Super classes: A list of parent classes from which the current class is derived via specialization. Disjointness. A list of classes that are disjoint with the present class. Disjointness between classes means that an instance of the first class cannot simultaneously be an instance of the second class. Property restrictions: A property of a class can be a relation between this class and another, or an attribute of this class. Property restrictions specify the occurrence of a property as well as its cardinality and value range with respect to the current class. Property restrictions represent necessary conditions, which must be fulfilled by any member of the class. Usage: Here, the intended usage of the class is described; some illustrative examples may be provided. Properties are characterized by the following terms:

    

Description: Similar to that of classes as mentioned above. Super properties: A list of super properties from which the present property is derived via specialization. Global property restrictions: Value restrictions of the property’s range and domain. Characteristics: Indicates whether the property is transitive, symmetric, or functional. If the property has an inverse, it is specified here, as well. Usage: As above.

While OntoCAPE is mostly concerned with classes and properties, it also contains some individuals, which are described by the following aspects within the informal specification:

 



Description: As above. Properties: Some individuals are characterized by attributes or relations to other individuals. For instance, the individual denoting the SI-unit Newton is related to the individuals kilogram, meter, and second. Differentiation: A list of those individuals that are explicitly declared to be distinct from the present one. For example, the individuals solid, liquid, and gaseous, which are instances of the class aggregate state, are defined to be mutually different in order to exclude that an aggregate state can be solid and liquid at the same time.

4.2. Formal specification The informal specification of OntoCAPE was ‘‘translated’’ into DAML+OIL (Connolly et al., 2001), which was the state-of-the-art ontology modeling language at the time we started to produce the formal specification. The formal specification was created using the ontology editor

ARTICLE IN PRESS 154

J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

OilEd (Bechhofer et al., 2001) and verified by the reasoner FaCT (Horrocks, 1998). Later, the formal specification was converted into the Ontology Web Language OWL (OWL DL in particular) (Bechhofer et al., 2004), which has replaced DAML+OIL as a standard ontology modeling language. This laborious task of conversion — as of version 1.0, the ontology contains about 600 concepts and 450 relations represented by 20,000 lines of code—was supported by a converter (Amin and Morbach, 2005), which handled most of the translation. However, as OWL does not offer equivalents for all language elements of DAML+OIL, some parts of the ontology had to be remodeled manually. It should be noted, in particular, that concepts of the lower layers in the multi-layer structure of OntoCAPE should be derived from meta-layer concepts by instantiation. However, OWL DL does not support this kind of meta-modeling. Therefore, concepts of the lower layers are currently linked to the meta-layer by specialization (subclassing). For the verification of the OWL version of the ontology, the reasoner RACER (Haarslev and Mo¨ller, 2001) in combination with the ontology editor Prote´ge´ (Stanford Medical Informatics, 2006) was used. In the formal specification, ontology modules are manifested through namespaces, each of which is stored in a single OWL file. Inclusion is realized by using the appropriate import mechanisms provided by OWL. The partial models correspond to homonymous directories in the formal specification; that way they establish a directory structure for managing the OWL files. Variants of a module are represented as separate OWL files, which are stored in the same directory and have the first part of their two-part file name in common. 5. Applications of OntoCAPE So far, OntoCAPE has been used in a number of process modeling and design applications. All these applications have in common that existing software tools developed by the ontological engineering community, such as Jena (HP Labs, 2006) and RACER (Haarslev and Mo¨ller, 2001), have been applied for loading, processing, and reasoning about the formal specification of OntoCAPE. Some of these applications are described below. 5.1. Automatic selection of software components for process modeling In the COGents project, OntoCAPE has been used for selecting suitable process modeling components (PMCs) from some libraries for a given process modeling task (Braunschweig et al., 2004). A typical scenario, carried out by a number of interacting software agents is illustrated in Fig. 4. The scenario starts with a Personal Assistant Agent, which composes a modeling task specification (MTS), an instance of a class defined in the modeling task specification

Personal Assistant Agent

PMC Library A

Modeling Task Manager

Library Wrapper Agent A Match-Making Agent

PMC Library B

Library Wrapper Agent B

Fig. 4. A simplified COGents architecture.

human modeler

conceptual model

consistency checking tool

graphical user interface

ontology querying tool

file exchange

OntoCAPE

interaction between tools and/or user

Fig. 5. Structure of a conceptual modeling tool using OntoCAPE.

ontology module (located in the partial model model on the application-oriented layer, cf. Fig. 2). The MTS describes the properties of a desirable PMC in terms of the object to be modeled (which is either a chemical process system or a chemical process material), software features of the PMC that allow it to be embedded in the software environment of the user for doing process modeling and/or design, etc. This MTS is then verified by the Modeling Task Manager to assure its consistency with respect to OntoCAPE. Thereafter, it is sent to the Match-Making Agent, which is responsible for retrieving information about existing PMCs. The information, expressed using OntoCAPE, can be acquired by communicating with the Library Wrapper Agents, which represent the libraries accessible by the COGents system. Matching is then performed by the Match-Making Agent in order to find one or more PMCs that satisfy the requirements stated in the MTS. 5.2. Ontology-based process modeling OntoCAPE has been used in computer-aided modeling of chemical processes following an ontology-based approach (Yang and Marquardt, 2004; Yang et al., 2004). This approach suggests that a mathematical model is constructed in two successive steps, namely conceptual modeling and model generation. Illustrated by Fig. 5, the first step is aimed at composing a conceptual model, that is, a physical (not mathematical) characterization of a chemical process to be modeled. In this step, OntoCAPE provides chemical engineering concepts needed for describing structural and phenomenological details of the chemical process. An ontology-querying tool is used to retrieve, from the large number of concepts in OntoCAPE, those relevant to the current modeling context. These

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

155

concepts are then presented to the human modeler through the graphical user interface (GUI). Working with the GUI, the human modeler composes the conceptual model by selecting, instantiating, and connecting relevant concepts. At the request of the human modeler, intermediate results can be validated against OntoCAPE by the consistency checking tool in order to detect elements in the conceptual model that violate the constraints predefined in the ontology. Through this validation, some modeling errors can be detected and thus avoided already at the physical level, before the mathematical models are generated. In the second step of modeling (not covered in Fig. 5), a model generation engine takes the conceptual model generated in the first step, processes it according to the formal definitions of concepts and relations in OntoCAPE, and finally retrieves elementary model pieces from a model building block library and customizes them. Eventually, a mathematical model is generated that corresponds well to the conceptual model. More details regarding how the model generation engine works and its merits can be found elsewhere (Yang et al., 2004).

reactor; the model incorporates a chemical reaction with the chemical components A and B as reactants and component C as reaction product. The PFD specifies that the reaction is realized in a pressure vessel, which is equipped with a propeller agitator and a cooling jacket. Prototypical converters, which automatically derive content annotations from documents and data stores, have been developed for the data formats of several software applications, amongst others the process simulator Aspen Plus (AspenTech 2006) and the CAE system Comos PT (Innotec 2006). That way, only minimal user interaction is required to annotate the resources: In the above example (Fig. 6), only the connection between the annotation of the CSTR model and that of the pressure vessel has to be specified manually. Content annotations can be utilized by computer systems that provide access to distributed and disparate information sources, like search engines, enterprise web portals, document management systems, and data warehouses. These systems can employ OntoCAPE annotations to support the following tasks:

5.3. Semantic annotation of the contents of information sources



OntoCAPE can be used to annotate the content of electronic documents and data stores belonging to the domain of process engineering, such as model files, process flowsheets, or material properties databases. As an example, Fig. 6 shows a model file generated by a process simulator and a process flow diagram (PFD) stored in a computer-aided engineering (CAE) system that are both annotated through OntoCAPE concepts: The model file specifies a CSTR model (a standard type of mathematical model in process engineering) that models a chemical





Documentation: The annotations provide a consistent and centrally accessible description of the content of the individual resources, regardless of the proprietary format in which the information is stored. Navigation: Links between the information sources are established, which can be employed for navigation between resources: Consider for instance the situation in Fig. 6, where a user may navigate from the simulation model of a reactor to the flowsheet object describing its realization, and vice versa. Retrieval: As the annotations are represented in a formal machine-interpretable ontology language, they can be exploited by appropriate browsing and querying tools.

Process Flow Diagram

Model file BLOCK CSTR RCSTR PARAM VOL=2. TEMP=450. & PRES=20. NPHASE=1 PHASE=L REACTIONS RXN-IDS=REAC-1 REACTIONS REAC-1 POWERLAW REAC-DATA 1 RATE-CON1 PRE-EXP=.5ACT-ENERGY=50. & T-REF=150. STOIC1 MIXED A-1. / B -1. / C 1.

modeled by CSTR Model incorporates phenomena A reactants

Chemical Reaction

B

Chemical Reactor

realized by equipment

Pressure Vessel

has agitator

has fixture

Connection established manually

product C

Propeller

Cooling Jacket

Equipment description derived from CAE system

Model description derived from model file

Fig. 6. Semantic annotation of a model file and a process flow diagram.

ARTICLE IN PRESS 156

J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

core ontology

core_ ontology is annotated by Document is stored in Content Description is used by

Object

Store

User

Meta Layer OntoCAPE

PDW ontologies

system system

user user register register

stores stores

documents

Fig. 7. Core ontology of the PDW. Dashed lines indicate that concepts are refined in lower modules.

Brandt et al. (2005, 2006) describe a process data warehouse (PDW) that uses OntoCAPE for the annotation of electronic documents. In this application, OntoCAPE is combined with other ontologies that describe the type and format of the documents, their storage, and the usage of the documents in work processes by human users and software tools. The individual ontologies are integrated via a core ontology (cf. Section 3.2). The core ontology introduces top-level classes and their relations, which are further refined within the peripheral ontology modules. Fig. 7 displays a simplified view of the core ontology: A document is annotated by a content description, which might be a system (or any other concept) defined within OntoCAPE. Moreover, a document is used by a user and stored in a store; these concepts are further elaborated in the modules documents, user register, and stores, respectively. 6. Discussion on ontology extension, evolution, and reuse We discuss in this section some issues pertaining to the handling of ontology extension, evolution, and reuse. Here, extension means that new ontological terms for special uses can be defined based on the existing vocabulary, in a way that does not require a revision of the existing definitions (Gruber, 1995). Evolution means that parts of the ontology are changed with respect to their level of detail or granularity, scope, or conceptualization, while the ontology as such remains intact. Reuse means that some parts are extracted from the ontology and used as building blocks to construct a new ontology. In relation to the development of OntoCAPE, we have faced a history of evolution and reuse of a number of complex ontologies for chemical process engineering in the past decade. The data model VeDa (Bogusch et al., 1998), developed since the early 1990s and represented in VDDL (Baumeister, 1998), was partially reused in CLiP (Bayer, 2003; Bayer and Marquardt, 2004), which was first encoded in the O-Telos language (Jeusfeld et al., 1998)

and later in UML (Fowler, 1997). In the current work, both of them have been taken as the basis for developing OntoCAPE v1.0, the first version of OntoCAPE devised for the COGents project. OntoCAPE was also influenced by the work on the ModKit knowledge base (Molitor, 2000; Bogusch, 2001), which addresses the representation and storage of mathematical models. After the release of OWL, version 1.1 was created by translating OntoCAPE from DAML+OIL into OWL. Subsequent to translation, the ontology was revised: Class definitions were enhanced, redundant concepts deleted, new properties and constraints added, etc. Moreover, the objectives targeted by the IMPROVE project (cf. Section 5.3) required an extension of the ontology, which gave rise to the creation of OntoCAPE v2.0. The history of OntoCAPE shows exemplarily that ontologies are dynamic systems, which evolve and change according to prevailing conditions and requirements. Three causes of ontology change can be distinguished:







New representation languages can induce developers to represent the ontology in a different form, either to benefit from advanced language features (expressiveness, usability, etc.), which was our motivation for developing the DAML+OIL version of OntoCAPE in addition to its UML representation, or to adapt to a new standard, as it was the case when migrating OntoCAPE from DAML+OIL to OWL. New insights may change the way how some part of a domain is understood in comparison to how it was modeled previously. This frequently happens as a result of re-evaluating different alternatives for modeling the same real world object, resulting in an improved conceptualization of the object in question. New tasks and/or application areas may necessitate extending and adapting the ontology with respect to scope, level of detail or granularity, and representation. In particular, this can be due to the interaction problem (Bylander and Chandrasekaran, 1988), which states that

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

representing knowledge for the purpose of solving some problem is strongly affected by the nature of the problem and the inference strategy to be applied to the problem. Thus, when developing a large-scale ontology, the possibility of later changes should already be considered and consequently be reflected by its design and structure. In the following, we discuss how changes are supported by design features of OntoCAPE. The first feature to mention is the layered structure of OntoCAPE. As suggested by several authors (e.g., Russ et al., 1999), OntoCAPE is subdivided into layers to separate application-specific knowledge from more general domain knowledge. The layered design takes the so-called reusability–usability trade-off problem (Klinker et al., 1991) into account, which states that the more reusable a part of an ontology is, the less usable it becomes (and vice versa). This means, the general knowledge, which is represented in the upper layers of OntoCAPE, can be applied to various application areas, yet it is not immediately applicable since the upper layers hold only generic ontological concepts that must be refined before being useful for an application. On the other hand, the lower layers contain knowledge that is ready for use, yet problem-specific and therefore not transferable to other applications. OntoCAPE’s layered structure allows a user to freely select the degree of usability. That is, due to the gradual increase of application-specific content, knowledge can be retrieved at exactly the required level of generality: Consider for example the different software applications described in Section 5. As they perform different tasks, they require different modules on the application-specific layer. However, as these tasks fall into a common application area (i.e., process modeling and simulation), the software systems can share ontological concepts from the application-oriented layer and the layers above. Similarly, a software system that operates on an application area hitherto not supported by OntoCAPE but still falling into the process-engineering domain (say an ecommerce system for equipment purchasing) could still reuse the ontology down to and including the conceptual layer. A software application belonging to a domain different from process engineering may reuse at least the upper layer and the meta-layer. Another benefit of the layered structure is that the metalayer and the upper layer explicitly represent the modeling style and the organizing principles of the ontology. The indication of these underlying design principles ensures consistency during ontology evolution and reduces the likelihood of making ad-hoc extensions (Aitken, 1998), which is especially important when changes are carried out by diverse developers at different times. It also enhances the reusability of the ontology (Borst, 1997). In particular, it helps to evaluate whether the part to be reused is compatible with the new ontology, since differences in modeling styles and underlying principles can cause problems in merging (Russ et al., 1999).

157

The second feature of OntoCAPE that supports ontological changes is modularization, that is, the subdivision of the ontology into modules, which has been recommended by many authors (e.g., Visser and Cui, 1998; Pinto et al., 1999; Heflin and Hendler, 2000; Rector, 2003; Stuckenschmidt and Klein, 2003) as a means to promote both evolution and reuse of ontologies. Modules are concise and therefore easier to deal with than a complete ontology, hence bringing advantages in maintenance and comprehensibility. As pointed out by Gruber and Olsen (1994), modularization also enhances the extendibility of the ontology, as newly defined terms do not have to be compatible with the entire ontology but only with a subset, thus reducing the likelihood of inconsistencies between new and existing ontological definitions. Moreover, modules can be modified or reused to some extent independently, as they have by definition only few interrelations with the other parts of the ontology. For easy handling of the remaining interrelations, the header of each OWL file representing a module in OntoCAPE lists all those classes, properties, and individuals from other modules, which are referenced or used by the current module. If the module is modified during ontology evolution, it must be inspected whether and how these concepts are affected by the change. If the module is reused in a different ontology, these concepts must be incorporated in the ontology, as well. Note that currently these tasks have to be handled manually for the most part; better tool support is therefore highly expected. In OntoCAPE, modularization is arranged in such a way that different variants may exist for a particular ontology module. Consequently, if a new application requires a representation of knowledge that is different from the one specified in the ontology, it might not be necessary to release an entirely new version. Rather new variants of the affected ontology modules can be developed and integrated into the present ontology. The introduction of variants is an option whenever different applications need the same scope of knowledge yet represented in a different way, that is, at a different level of detail or granularity, or reflecting a different usage perspective. Consider for example the conceptualization of plant equipments and their connections: Document annotation, as described in Section 5.3, calls for a simple, coarse-grained description of the connection of plant equipments (i.e., the mere indication that, in a particular flowsheet, equipment A is attached to equipment B is sufficient for this application). On the other hand, an ontology-based system for equipment purchasing would require a more precise description; connectivity must be addressed by indicating the number and position of flanges, specification of their type and diameter, etc. These details are rather irrelevant for document annotation. As a solution, two variants of the module plant can be developed, providing different conceptualizations of connectivity specifically tailored to the information demands of the respective application. Note that the communication between these software applications could easily be

ARTICLE IN PRESS 158

J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

superordinate module

superordinate module

module base module module variant A

module variant B

dependent module variant A

dependent module variant B

Straight-forward extension by duplicating the entire module; dependent modules must be duplicated as well.

module extension variant A

module extension variant B

dependent module Partial reconciliation by partitioning the module into module base and module extensions; that way, duplication of dependent modules may be avoided.

Fig. 8. Introduction and subsequent reconciliation of variants.

realized, even though the variants are not immediately compatible. Yet, as both variants have the same position within the partial model structure and are consequently based on the same ontological definitions inherited from superordinate modules, their integration is facilitated compared to that of entirely separated ontologies (Bayer et al., 2000) and can even be partially automated (Visser and Cui, 1998). Variants have the advantage that the ontology can quickly be adapted to new tasks, regardless of the impact of changes on existing applications. The obvious drawback of this approach is that, with an increasing number of supported applications, the number of variants gets unmanageably large, in particular because the dependent modules (those that are positioned below the variants in the inclusion lattice, cf. left side of Fig. 8) must be split into variants, as well, since they are derived from different conceptualizations. That way, different configurations of the ontology evolve. Configuration management systems such as CVS (GNU, 2005) or Subversion (Collins-Sussman et al., 2006) can support the handling of the growing number of variants and their mutual dependencies. At the same time, a reconciliation of the variants should be considered. A simple merging of the variants would contradict the idea of customized conceptualizations for particular applications. As a compromise, a new module base can be introduced, which contains the ontological definitions shared by all variants (cf. right side of Fig. 8); simultaneously, the variants are reduced to mere extensions of the base module. Module extensions hold only those ontological definitions that distinguish the variants from one another. Subordinate modules—if not explicitly dependent on concepts defined in the extensions—can refer to the base module only, thus avoiding unnecessary duplication. Reasoners that offer non-standard inferences—for example determination of the least common subsumer of related concepts (Cohen et al., 1992)—can support the reconciliation process (Molitor, 2000).

Finally, a less visible but still quite important feature of OntoCAPE is the description of intended usages of individual concepts, which are available both in the informal specification and as comments in the OWL files (cf. Section 4). Such descriptions reflect, at least to some extent, the rationale of the developer of existing pieces of an ontology. Therefore, this feature allows the insights of modeling to be explicitly recorded during the evolution of the ontology, thus making the changes on conceptualization more traceable. Having presented features of OntoCAPE in the consideration of ontology evolution and reuse, we have to point out that development and maintenance of OntoCAPE has been supported by very fragmented tools. Towards an improvement, we envision a comprehensive environment that can support the evolution of complex ontologies. Recently, some researchers have paid attention to ontology evolution (e.g., Klein and Noy, 2003; Noy and Klein, 2004). However, existing efforts have been mainly aiming at translation, merging, versioning, and alignment of ontologies expressed in formal languages (e.g., Farquhar, et al, 1997; Noy and Musen, 1999; Stuckenschmidt and Klein, 2003). Thus, there is still a gap between these technologies and the type of comprehensive environment we feel to be necessary for developing and managing complex ontologies. Bayer and Marquardt (2004) discuss the tool support needed for developing, using, and exporting information models (or ontologies) for engineering applications. Focusing on the perspective of long-term development of complex ontologies in general, our experience shows that a desirable environment should comprise and integrate tools that (a) guide the extension of the ontology based on an explicitly represented design framework; that (b) systematically document modeling decisions; that (c) support the documentation and maintenance of inter-module relations; and that (d) support the transformation and maintenance of different ontology representations, especially when informal languages and heterogeneous modeling tools are involved.

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

7. Summary OntoCAPE, a large-scale ontology for chemical process engineering, has been presented in this paper. The development of OntoCAPE has followed a state-of-theart methodology advised by the ontological engineering community, with an addition of adopting a skeletal ontology as an intermediate step to improve the efficiency of development. Regarding structural design, the contents of the ontology have been allocated to five layers with decreasing degree of abstraction, namely the meta-layer, the upper layer, the conceptual layer, the application-oriented layer, and finally the application-specific layer. Such a multi-layer structure allows for the contents of the ontology to be selectively reused at the proper level of abstraction. The upper layer is based on systems theory, which provides a principled guidance to its users and future developers of the conceptual and other more concrete layers. Each layer in OntoCAPE is composed of a number of ontology modules, which can be taken as convenient basic units for using and maintaining the ontology. Variants allow the coexistence of alternative knowledge representations within a coherent ontology structure, thus supporting applications with conflicting ontological demands. Further, the adoption of partial models brings additional organizing means that enables the grouping of modules across different layers as needed. OntoCAPE has been represented with both an informal and a formal specification. The informal specification provides a graphical representation of the ontology as well as description, definition, and illustration of individual concepts using structured natural language. As a translation of the information specification, the formal specification is represented in a formal ontology representation language, for the purposes of rendering a rigorous semantics of the ontology and making the ontology processable by software tools. Reflecting the evolution of ontology language standards, a DAML+OIL version and an OWL version of the formal specification have been subsequently produced for OntoCAPE. Exemplarily, three applications of OntoCAPE in CAPE have been sketched, namely automatic selection of software components, computer-aided construction of mathematical models, and semantic annotation of documents. These applications have demonstrated the potentials of using OntoCAPE (its formal specification in particular) for authoring, searching, and reasoning about information and knowledge of chemical process engineering. OntoCAPE has been developed as part of a continuous information modeling effort. In this effort, we have witnessed the necessity of making various changes to existing data models or ontologies, as the consequence of adopting new representation languages or new modeling insights, or encountering new applications. The design features of OntoCAPE, such as the layered structure and the modularization, have to some extent supported the

159

evolution of this large-scale ontology in a long run. Nevertheless, a comprehensive software environment is still expected for more efficiently managing the changes of complex ontologies. We believe that the ontology modeling process we described, although summarizing experience gained in an academic institute, may be equally applied in an industrial setting, since the problems to be addressed are basically the same. To validate this assumption, we are currently using OntoCAPE in a large-scale industrial project dealing with the integration and management of technical data throughout the lifecycle of a chemical plant. That way, we are able to test our approach in industrial practice and, if necessary, adapt it to real-world requirements and needs. Acknowledgments This work has been supported by the DFG in the Collaborative Research Center IMPROVE (SFB 476) and by the EC in the COGents Project (IST-2001-34431). References Aitken, S., 1998. Extending the HPKB-upper-level ontology: experiences and observations. In: Proceedings of the Workshop on Applications of Ontologies and Problem Solving Methods (ECAI’98), Brighton, England, August 1998. Alberts, L.K., 1994. YMIR: a sharable ontology for the formal representation of engineering design knowledge. In: Gero, J.S., Tyugu, E. (Eds.), Proceedings of the IFIP TC5/WG5.2 Workshop on Formal Design Methods for CAD. Elsevier, New York, pp. 3–32. Amin, M.A., Morbach, J., 2005. DAML+OIL to OWL converter. Available at /http://www.lpt.rwth-aachen.de/Research/OntoCAPE/ daml2owl.phpS, 18 March 2005. Accessed 24 May 2006. AspenTech, 2006. AspenTech homepage. Available at /http://www. aspentech.comS, 2006. Accessed 24 May 2006. Batres, R., West, M., Leal, D., Price, D., Naka, Y., 2005. An upper ontology based on ISO 15926. In: Puigjaner, L., Espuna, A. (Eds.), Proceedings of European Symposium on Computer-Aided Process Engineering, vol. 15. Elsevier, Amsterdam, pp. 1543–1548. Baumeister, M., 1998. The chemical engineering data model VeDa. Part 1: the language definition. Technical report, Lehrstuhl fuer Prozesstechnik, RWTH Aachen. Available at /http://www.lpt.rwth-aachen.de/ Research/Completed/veda.phpS, 18 March 2005. Accessed 24 May 2006. Bayer, B., Schneider, R., Marquardt, W., 2000. Integration of data models for process design — first steps and experiences. Computer and Chemical Engineering 24, 599–605. Bayer, B., 2003. Conceptual information modeling for computer aided support of chemical process design. Ph.D. Thesis, Lehrstuhl fuer Prozesstechnik, RWTH Aachen University. Published in: FortschrittBerichte VDI: Reihe 3, No. 787. VDI-Verlag, Du¨sseldorf. Bayer, B., Marquardt, W., 2004. Towards integrated information models for data and documents. Computers and Chemical Engineering 28, 1249–1266. Bayer, B., Marquardt, W., 2005. A conceptual information model for the chemical process design lifecycle. In: Jeusfeld, M.A., Jarke, M., Mylopoulos, J. (Eds.), Metamodeling for Method Engineering. MIT Press, Cambridge, MA. Bechhofer, S., Horrocks, I., Goble, C., Stevens, R., 2001. OilEd: a reasonable ontology editor for the semantic web. In: Baader, F., Brewka, G., Eiter, T. (Eds.), Proceedings of KI2001, Joint German/Austrian conference on Artificial Intelligence, September 19–21, Vienna. Lecture

ARTICLE IN PRESS 160

J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161

Notes in Artificial Intelligence, vol. 2174. Springer, Berlin, pp. 396–408. Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D.L., Patel-Schneider, P.F., Stein, L.A., 2004. OWL web ontology language reference. Available at /http://www.w3.org/TR/owl-ref/S, 10 February 2004. Accessed 24 May 2006. Biegler, L.T., Grossmann, I.E., Westerberg, A.W., 1997. Systematic Methods of Chemical Process Design. Prentice-Hall PTR, New York. Bogusch, 2001. A Software Environment for Computer-aided Modeling of Chemical Processes. Ph.D. thesis, Lehrstuhl fuer Prozesstechnik, RWTH Aachen University. Published in: Fortschritt-Berichte VDI: Reihe 3, No. 705, VDI-Verlag, Du¨sseldorf. Bogusch, R., Krobb, C., Lohmann, B., Souza, D., von Wedel, L., Marquardt, W., 1998. The chemical engineering data model VeDa. Parts 2-6. Technical reports, Lehrstuhl fuer Prozesstechnik, RWTH Aachen University. Available at /http://www.lpt.rwth-aachen.de/ Research/Completed/veda.phpS, 18 March 2005. Accessed 24 May 2006. Borst, W. N., 1997. Construction of engineering ontologies for knowledge sharing and reuse. CTIT Ph.D. Thesis Series No. 97-14, Universiteit Twente. Brandt, S.C., Schlu¨ter, M., Jarke, M., 2005. A process data warehouse for tracing and reuse of engineering design processes. In: Proceedings of the Second International Conference on Innovations in Information Technology (IIT’05), Dubai, United Arab Emirates, September 2005. Brandt, S.C., Morbach, J., Miatidis, M., TheiXen, M., Jarke, M., Marquardt, W., 2006. Ontology-based information management in design processes. In: Marquardt, W., Pantelides, C. (Eds.), Sixteenth European Symposium on Computer Aided Process Engineering and Ninth International Symposium on Process Systems Engineering. Elsevier, Amsterdam, pp. 2021–2026. Braunschweig, B., Fraga, E., Guessoum, Z., Marquardt, W., Nadjemi, O., Paen, D., Pinol, D., Roux, P., Sama, S., Serra, M., Stalker, I., Yang, A., 2004. CAPE web services: the COGents way. In: Barbarosa-Po´voa, A., Matos, H. (Eds.), European Symposium on Computer Aided Process Engineering, vol. 14. Elsevier, Amsterdam, pp. 1021–1026. Bunge, M., 1979. Treatise on Basic Philosophy, vol. 4: Ontology II: A World of Systems. D. Riedel, Dordrecht. Bylander, T., Chandrasekaran, B., 1988. Generic tasks for knowledgebased reasoning: the ‘‘right’’ level of abstraction for knowledge acquisition. In: Gaines, B.R., Boose, J.H. (Eds.), Knowledge Acquisition for Knowledge-Based Systems. Academic Press, London, pp. 65–77. CODIP (Components for Ontology Driven Information Push), 2004. Tools, components, and services. Available at /http://codip.grci.com/S. Accessed 24 May 2006. Cohen, W.W., Borgida, A., Hirsh, H., 1992. Computing least common subsumers in description logics, in Swartout, W. (Ed.), Proceedings of the 10th National Conference on Artificial Intelligence. MIT Press, pp. 754–760. Collins-Sussman, B, Fitzpatrick, B.W., Pilato, C.M., 2006. Version control with subversion. Available at /http://svnbook.red-bean.com/S. Accessed 24 May 2006. Connolly, D., van Harmelen, F., Horrocks, I., McGuinness, D.L., PatelSchneider, P.F., Stein, L.A., 2001. DAML+OIL reference description. Available at /http://www.w3.org/TR/daml+oil-referenceS, 18 December 2001. Accessed 24 May 2006. ETRI (Electronics and Telecommunications Research Institute), 2004. Welcome to ezOWL. Available at /http://iweb.etri.re.kr/ezowl/S, 12 April 2004. Accessed 19 August 2005. Farquhar, A., Fikes, R., Rice, J., 1997. The Ontolingua Server: a tool for collaborative ontology construction. International Journal on Human–Computer Studies 46, 707–727. Ferna´ndez-Lopez, M., Go´mez-Pe´rez, A., Juristo, N., 1997. METHONTOLOGY: From ontological art towards ontological engineering. In: Working Notes of the AAAI Spring Symposium on Ontological Engineering, Stanford, CA, March 1997, AAAI Press, Stanford University.

Fowler, M., 1997. UML Distilled — Applying the Standard Object Modeling Language. Addison-Wesley, Longman, Inc., New York. GNU, 2005. CVS — Open Source Version Control. Available at /http:// www.nongnu.org/cvs/S, 23 February 2006. Accessed 24 May 2006. Go´mez-Pe´rez, A., Ferna´ndez-Lopez, M., Corcho, O., 2004. Ontological Engineering. Springer, London. Gruber, T.R., 1993. A translation approach to portable ontology specifications. Knowledge Acquisitions 5 (3), 199–220. Gruber, T.R., 1995. Toward principles for the design of ontologies used for knowledge sharing. International Journal of Human–Computer Studies 43, 907–928. Gruber, T.R., Olsen, G.R., 1994. An ontology for engineering mathematics. In: Doyle, J., Torasso, P., Sandewall, E. (Eds.), Fourth International Conference on Principles of Knowledge Representation and Reasoning, Bonn, Germany. Morgan Kaufmann, San Francisco, CA, pp. 258–269. Haarslev, V., Mo¨ller, R., 2001. Description of the RACER system and its applications. In: Proceedings of International Workshop on Description Logics (DL-2001), Stanford, USA, 1–3 August 2001. Heflin, J., Hendler, J., 2000. Dynamic ontologies on the web. In: Proceedings of the Seventeenth National Conference on Artificial Intelligence (AAAI-2000), AAAI/MIT Press, Menlo Park, CA, pp. 443–449. Horrocks, I., 1998. Using an expressive description logic: FaCT or fiction? In: Cohn, A.G., Schubert, L., Shapiro, S.C. (Eds.), Principles of Knowledge Representation and Reasoning: Proceedings of the Sixth International Conference (KR’98). Morgan Kaufmann, San Francisco, CA, pp. 636–647. HP Labs, 2006. HP Labs semantic web research. Available at /http:// www.hpl.hp.com/semweb/S, 2006. Accessed 24 May 2006. Innotec, 2006. Innotec homepage. Available at /http://www.innotec.deS, 2006. Accessed 24 May 2006. ISO, 2003. Integration of lifecycle data for process plant including oil and gas production facilities: Part 2—data model. International Standard. ISO 15926-2: 2003, ISO, Geneva. Jeusfeld, M.A., Jarke, M., Nissen, H.W., Staudt, M., 1998. ConceptBase — managing conceptual models about information systems. In: Bernus, P., Mertins, K., Schmidt, G. (Eds.), Handbook on Architectures of Information Systems. Springer, Berlin, pp. 265–285. Klein, M., Noy, N.F., 2003. A component-based framework for ontology evolution. In: Proceedings of the Workshop on Ontologies and Distributed Systems (IJCAI’03), Acapulco, Mexico, 2003. Klinker, G., Bhola, C., Dallemagne, G., Marques, D., McDermott, J., 1991. Usable and reusable programming constructs. Knowledge Acquisition 3 (2), 117–135. Klir, G.J., 1985. Architecture of Systems Problem Solving. Plenum Press, New York. Konda, S., Monarch, I., Sargent, P., Subrahmanian, E., 1992. Shared memory in design: a unifying theme for research and practice. Research in Engineering Design 4 (1), 23–42. Lassila, O., McGuiness, D., 2001. The role of frame-based representation on the semantic web. Technical Report KSL-01-02, Knowledge Systems Laboratory, Stanford University. Marquardt, W., Nagl, M., 2004. Workflow and information centered support of design processes — the IMPROVE perspective. Computers and Chemical Engineering 29, 65–82. Molitor, R., 2000. Unterstu¨tzung der Modellierung verfahrenstechnischer Prozesse durch Nicht-Standardinferenzen in Beschreibungslogiken. Ph.D. Thesis, Department of Computer Science, RWTH Aachen University, Aachen, Germany. Noy, N.F., Klein, M., 2004. Ontology evolution: not the same as schema evolution. Knowledge and Information Systems 6, 428–440. Noy, N. F., Musen, M.A., 1999. SMART: Automated support for ontology merging and alignment. In: 12th Workshop on Knowledge Acquisition, Modeling, and Management, Banff, Alberta, Canada, 16–21 October 1999. Patzak, G., 1982. Systemtechnik — Planung Komplexer Innovativer Systeme. Springer, Berlin.

ARTICLE IN PRESS J. Morbach et al. / Engineering Applications of Artificial Intelligence 20 (2007) 147–161 Pinto, H.S., Gomez-Perez, A., Martins, J. P., 1999. Some issues on ontology integration. In: Proceedings of IJCAI99’s Workshop on Ontologies and Problem Solving Methods: Lessons Learned and Future Trends, Stockholm, Sweden, July 31–August 6, 1999. Rector, A., 2003. Modularisation of domain ontologies implemented in description logics and related formalisms including OWL. In: Haller, S., Russell, I. (Eds.), Proceedings of the 16th International FLAIRS Conference, AAAI Press, FL. Russ, T., Valente, A., MacGregor, R., Swartout, W., 1999. Practical experiences in trading off ontology usability and reusability. In: Proceedings of the Knowledge Acquisition Workshop (KAW99), Banff, Alberta. Stanford Medical Informatics, 2006. The Prote´ge´ ontology editor and knowledge acquisition system. Available at /http://protege.stanford. edu/S, 2006. Accessed 24 May 2006. Stuckenschmidt, H., Klein, M., 2003. Integrity and change in modular ontologies. In: Proceedings of the International Joint Conference on Artificial Intelligence—IJCAI ‘03, Acapulco, Mexico, 2003. Morgan Kaufmann, San Francisco, CA, pp. 900–905. TGL 25000, 1974. Chemical engineering unit operations — classification. Departmental Standard of the German Democratic Republic. Uschold, M., Gru¨ninger, M., 1996. Ontologies: principles, methods and applications. Knowledge Engineering Review 11 (2), 93–155. van Gigch, J.P., 1991. System Design Modeling and Metamodeling. Springer, New York.

161

van Heijst, G., Shreiber, A., Wielinga, B.J., 1997. Using explicit ontologies in KBS development. International Journal of Human–Computer Studies 45, 183–292. Visser, P.R.S., Cui, Z., 1998. Heterogeneous ontology structures for distributed architectures. In: ECAI-98 Workshop on Applications of Ontologies and Problem-solving Methods, pp. 112–119. von Wedel, L., 2002. CapeML — A model exchange language for chemical process modeling. Technical report (LPT-2002-16), Lehrstuhl fuer Prozesstechnik, RWTH Aachen University. Available at /http://www.lpt.rwth-aachen.de/Publication/abstract.php?Nummer= LPT-2002-16S, 8 June 2005. Accessed 24 May 2006. Yang, A., Marquardt, W., 2004. An ontology-based approach to conceptual process modeling. In: Barbarosa-Po´voa, A., Matos, H. (Eds.), European Symposium on Computer Aided Process Engineering, vol. 14. Elsevier, Amsterdam, pp. 1159–1164. Yang, A., Morbach, J., Marquardt, W., 2004. From conceptualization to model generation: the roles of ontologies in process modeling. In: Floudas, C. A., Agrarwal, R. (Eds.), Proceedings of FOCAPD 2004, pp. 591–594. Yang, A., Schlu¨ter, M., Bayer, B., Kru¨ger, J., Haberstroh, E., Marquardt, W., 2003. A concise conceptual model for material data and its applications in process engineering. Computers and Chemical Engineering 27, 595–609. WordNet 2.1, 2005. Cognitive Science Laboratory, Princeton University. Available at /http://wordnet.princeton.edu/S, 2005. Accessed 1 June 2006.