Available online at www.sciencedirect.

com

Computers and Chemical Engineering 32 (2008) 320–342

An ontology-based approach to knowledge

management in design processes
Sebastian C. Brandt a,∗ , Jan Morbach b , Michalis Miatidis a ,
Manfred Theißen b , Matthias Jarke a,c , Wolfgang Marquardt b
a Informatik 5 (Information Systems), RWTH Aachen University, Ahornstr. 55, 52056 Aachen, Germany
b Process Systems Engineering, RWTH Aachen University, Turmstr. 46, 52056 Aachen, Germany
c Fraunhofer FIT, Schloss Birlinghoven, 53754 St. Augustin, Germany

Received 24 January 2007; received in revised form 5 April 2007; accepted 10 April 2007
Available online 24 April 2007

Abstract
Engineering design processes comprise highly creative and knowledge-intensive tasks that involve extensive information exchange and commu-
nication among distributed teams. In such dynamic settings, traditional information management systems fail to provide adequate support due to
their inflexible data structures and hard-wired usage procedures, as well as their restricted ability to integrate process and product information. In
this paper, we advocate the idea of Process Data Warehousing as a means to provide a knowledge management and integration platform for such
design processes. The key idea behind our approach is a flexible ontology-based schema with formally defined semantics that enables the capture
and reuse of design experience, supported by advanced computer science methods.
© 2007 Elsevier Ltd. All rights reserved.

Keywords: Process Data Warehousing; Engineering design; Ontologies; Information management; Knowledge management; Design repository

1. Introduction that emphasize the collection and organization of knowledge

Knowledge about engineering design processes constitutes
one of the most valuable assets of a modern enterprise. Normally,
this knowledge is only known implicitly to the participating
designers, relying heavily on the personal experience back-
ground of each designer. To fully exploit this intellectual capital,
it must be made explicit and shared among designers and
across the enterprise. Consistent and comprehensive knowledge
management methods need to be applied to capture and inte-
grate the individual knowledge items emerging in the course of
an engineering design project. Knowledge management (KM)
is a scientific discipline that stems from management theory
and concentrates on the systematic creation, leverage, shar-
ing and reuse of knowledge resources in a company (Awad &
Ghaziri, 2003). Knowledge management approaches are gener-
ally divided into personalization approaches that focus on human
resources and communication, and codification approaches
∗ Corresponding author. Tel.: +49 241 80 21514.
E-mail address: sbrandt@cs.rwth-aachen.de (S.C. Brandt).
(McMahon, Lowe, & Culley, 2004). We only consider the latter
approach, stressing the automated recording of the application
of implicit design knowledge. Thus, experience knowledge is
captured that can be shared and reused later on. This poses the
challenges on knowledge management systems (KMS) that are
described below.
Typically, a vast amount of design knowledge is manipulated
by legacy tools and stored in highly heterogeneous sources, such
as electronic documents and databases. Thus, a KMS should
(a) provide a comprehensive representation of the contents of
these sources, thereby correlating the scattered knowledge items
and providing a single point of access to design knowledge.
As such a comprehensive representation cannot be complete
(for reasons of scaling, maintainability, practicability, etc.), a
KMS should (b) employ mechanisms to easily locate the orig-
inal knowledge sources, where more detailed information can
be retrieved. To this aim, (meta) information about the sources
(e.g., type, structure, version history, storage location) should be
combined with information about their contents, and the KMS
should be integrated with existing tools and data stores to pro-
mote easy access to the original sources. In addition, the KMS

0098-1354/$ – see front matter © 2007 Elsevier Ltd. All rights reserved.
doi:10.1016/j.compchemeng.2007.04.013
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
should (c) enable the capture and archival of work processes in
order to provide information about the circumstances in which
the individual knowledge items have been created. In particular,
recording of the decision-making procedures allows to recall
the design rationale applied at that time. This allows to sys-
tematically retrieve experience knowledge that is suitable for a
particular situation, and evaluate its applicability to the current
working context. Moreover, best practices abstracted from the
recorded work processes can be exploited for direct process sup-
port (i.e., the partially automated enactment of routine tasks in
design tools).
This paper presents a novel approach for supporting creative,
non-deterministic1 design processes that addresses the above
demands: based on the concepts introduced by Jarke, List, and
Köller (2000), our Process Data Warehouse (PDW) allows the
capture and reuse of design knowledge – product data, doc-
uments, work processes, and decision-making procedures, as
well as their interdependencies – through ontologies. In this con-
text, the term “ontology” denotes a conceptual data schema that
represents the relevant domain entities and their relationships
by means of classes and relations. Ontologies are flexible data
structures that can be changed and adapted at run time; more-
over, they allow representing the semantics of design knowledge
in a formal way the computer can interpret. These characteristics
enable the provisioning of advanced computer science methods
for managing, enriching, and searching the knowledge within
the PDW.
The paper is organized as follows: the next section investi-
gates the possibilities of supporting technical design processes
by experience management. In Section 3, we introduce our
approach of the Process Data Warehouse for knowledge cap-
ture and experience reuse. Section 4 illustrates how the PDW
is applied in process engineering design. Methods and tools for
knowledge capture are described in Section 5. In Section 6, we
discuss how our work correlates with the research activities of
other groups. Finally, conclusions are drawn, including further
on-going and future research.
2. Supporting creative design processes
Experience that can be gathered and recorded using knowl-
edge management methods, is intended to be used for supporting
designers when executing creative design processes (Jarke
& Marquardt, 1996). Those conceptual design processes, as
found in chemical engineering, are highly dynamic and non-
deterministic, and therefore hardly predictable (Marquardt &
Nagl, 2004; Westerberg, Subrahmanian, Reich, Konda, & the
n-dim group, 1997). Any software solution has to cope with
the continually changing requirements and the many degrees
of freedom within these processes. Appropriate process support
for the chemical engineering domain is even harder to achieve
than for domains like automotive engineering where stan-
dardized, well-understood products are developed: the design
1 That is, work processes that cannot be completely planned and/or scheduled
in advance due to initially incomplete knowledge, and uncertainties.
321
processes in these domains are relatively well-documented,
strict, and deterministic, allowing a prescriptive definition of
the activities to be executed. In contrast, chemical engineering
is concerned with the development of individual and highly cus-
tomizable products (i.e., chemical plants); therefore, the design
processes are more dynamic and do not allow for deterministic
approaches.
In this context, two different types of information resources
need to be distinguished. On the one hand, the products created
as part of the design processes (e.g., process flow diagrams, sim-
ulation models, design calculations, cost estimates, etc.) should
be considered. These may be organized into documents, which
act as logical units to enable work distribution or version con-
trol. On the other hand, there are the work processes or activities
themselves, in which the products are created, used or manip-
ulated. Any kind of integrated support needs to take both the
product and the process aspect into account. In the following,
we discuss to which degree the different types of software solu-
tions available today support the management of product and
process knowledge.
Document Management Systems such as Windream
(Windream GmbH, 2006) or Documentum (EMC2 , 2006) are
widely used in industrial practice for the storage, maintenance,
and distribution of documents. Their process support is restricted
to micro-level processes like versioning and to the execution of
simple workflow definitions, offering a subset of the function-
ality of standard workflow management systems. Some of these
systems provide collaborative extensions, such as the Documen-
tum eRoom. These offer additional functionalities for intra- and
inter-enterprise collaboration, and for the flexible definition and
execution of cooperative and coordinative workflows.
A step further, Product Data Management (PDM) systems
provide extended facilities for the handling of detailed product
information, ranging from design to production stage. Nowa-
days, such systems are routinely applied for the manufacturing
of mechanical and electronic devices. They are being succeeded
by Product Lifecycle Management (PLM) systems, such as
Windchill (PTC, 2006a), TeamCenter (UGS, 2006) or CATIA
(Dassault Systemes, 2006). The aim of these systems is to inte-
grate information on the manufacturing processes (usually CAM
systems) with design data (CAD systems) on the one hand,
and information about Enterprise Resource Planning (ERP) pro-
cesses on the other hand.
The PDM/PLM systems available today adequately support
information exchange between developers, especially in the later
phases of the engineering lifecycle which are characterized by
more deterministic and well-known processes. Nowadays, they
also provide improved possibilities to integrate a company’s
legacy systems, provided that the company is willing to tackle
the required integration effort (Mesihovic, Malmqvist, & Pikosz,
2004). However, they lack essential capabilities for the manage-
ment and reuse of design knowledge (Bilgic & Rock, 1997;
Gao, Aziz, Maropoulos, & Cheung, 2003; Maropoulos, 2003)
and are less suited for the conceptual design stage (Gao et al.,
2003; Mesihovic et al., 2004).
A significant shortcoming of existing PDM and PLM systems
criticized by many authors, is their lack of adequate informa-
322 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
tion models for product representation (e.g., Szykman, Sriram,
& Regli, 2001). These models would be needed to effectively
capture, exchange, retrieve, and reuse design knowledge. In
particular, formal and well-structured information models for
the conceptual design stage are missing that reflect different
perspectives such as function, behavior, and structure (e.g.,
Bilgic & Rock, 1997; Mesihovic et al., 2004; Szykman et al.,
2001).
Regarding process support, current PDM systems have
largely focused on the support of micro-level processes on the
administrative level, such as versioning or engineering change
management (Mesihovic et al., 2004). Some attention is paid
to project management, however without reaching the capa-
bilities of full-fledged project management systems (Bilgic &
Rock, 1997; Mesihovic et al., 2004). They lack the functional-
ity to capture complex work processes and decisions, as well as
capabilities for direct process support.
While PLM systems are widely used in the manufacturing
industries, they are less common in the chemical engineer-
ing domain. Instead, specialized Computer Aided Engineering
(CAE) systems are used, which resemble classical PDM solu-
tions but are specifically adapted to the needs of the chemical
process industries. Examples are Aspen Zyqad (AspenTech,
2006), Comos PT (Innotec, 2006), SmartPlant P&ID
(Intergraph, 2006a), and VANTAGE (AVEVA, 2006a). Like
PDM systems, these CAE systems focus on geometrical data and
flowsheets; other plant-related information are also considered
but to a much lesser degree. Information models of CAE systems
suffer the same deficiencies as PDM systems, that is the lack of
well-structured product representation, especially for the early
design phases (e.g., Bayer, 2003; Bayer & Marquardt, 2003).
Like PDM systems, CAE systems offer process support on
the micro-level but fail to support more complex development
activities. They lack capabilities for the capture of work pro-
cesses and decisions, nor do they offer direct process support.
Project management is supported to some degree.
The CAE systems available today do not cover the entire
lifecycle of a chemical plant (Schneider & Marquardt, 2002).
Therefore, vendors offer information integration environments
such as Optegra (PTC, 2006b) to integrate and consolidate
information from heterogeneous sources. Some solutions have
been developed specifically for the domain of chemical engi-
neering, such as the Process Engineering Data Warehouse
(PEDW, Bayer Technology Services, 2006), SmartPlant Foun-
dation (Intergraph, 2006b), and VNET (AVEVA, 2006b). These
solutions aim to correlate design data and technical specifica-
tions obtained from multiple sources (CAE systems, process
simulators, and other engineering tools) with other informa-
tion, such as process studies, material balances, property data,
and project-related data. Data import is mainly realized through
XML and is often restricted to the proprietary formats of the
vendors and their cooperation partners. The tools offer services
such as version management, change management, notification
(if some changes have been committed), and simple navigation
and retrieval functionality.
In summary, none of the commercial solutions currently
available is able to provide knowledge management support as
it has been envisioned in the previous section. Since each of
these tools is based on its own proprietary information model
and contains only some generic import and/or export functions,
only part of the product knowledge created during the design
process can be captured for reuse. Reuse of product knowledge
is further hindered by the lack of adequate information models
and the tools’ insufficient retrieval capabilities. As for the pro-
cess aspect, none of the tools offers process support beyond
prescriptive workflow management and micro-level services.
As mentioned before, these deterministic approaches are not
adequate for conceptual design processes which are not suffi-
ciently well understood and involve activities of multi-objective
decision-making based on incomplete information.
Thus, to move beyond the approaches described so far, there
is a need for integrated technical support in the early phases of
conceptual design. Therefore, the authors’ work groups have
examined the possibilities offered by recording and reusing
product and process knowledge. To stress the integration and
interleaving of product and process data, the underlying concept
has been named the Process Data Warehouse.
3. The Process Data Warehouse
In this section, the concept of the Process Data Warehouse as a
traces-based knowledge management system will be described.
It records the traces of design processes in its experience repos-
itory and thus allows them to be reused for supporting creative
design processes. Section 3.1 introduces the so-called Core
Ontology, and Section 3.2 describes some ontological exten-
sion modules. Section 3.3 shows how the ontological model is
used for the implementation of the PDW.
3.1. A Core Ontology for engineering knowledge
management
The concept of the Process Data Warehouse has been
derived from the concept of Data Warehousing (Jarke, Lenzerini,
Vassiliou, & Vassiliadis, 2003) where large amounts of fixedly
structured data (e.g., from sales or accounting) are stored, aggre-
gated, and then presented. For those conventional tools and
warehouses, fixed schemas are used for data storage. Yet to
support design and other creative work processes, dynamic
extension of the existing data structures and integration of addi-
tional, suitable domain models2 must be supported (Jarke et al.,
2000).
The PDW uses ontologies to represent the domain models.
In computer science, an ontology is usually understood as a
“formal, explicit specification of a shared conceptualization”
(Studer, Benjamins, & Fensel, 1998); that means, an ontology is
formal model which explicitly represents the consensual knowl-
edge of a domain. The domain entities are modeled through
classes and relations. By instantiating these ontological con-
cepts, concrete facts and information items can be stored in the
ontology.
2 A domain model is an information model for a particular application domain.
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Fig. 1. Simplified view of the Core Ontology and some peripheral ontology modules.
Ontologies have two major advantages over conventional
data schemas: firstly, they are highly flexible, enabling mod-
ifications and extensions of the data structures even during
project execution. Secondly, they are represented in a machine-
readable, logic-based language, which allows to formally define
the semantics of the ontological concepts. This enables the com-
puter to interpret and reason with the information stored in the
ontology. In consequence, advanced support for information
management and retrieval can be provided: for example, it is pos-
sible to perform a semantic search on the ontology. In contrast to
other, simpler forms of search (e.g., keyword based), a semantic
search allows for a more systematic retrieval of information.
The PDW has been constructed on top of loosely connected
ontology modules which are held together by a central Core
Ontology (Brandt, Morbach, et al., 2006; Brandt, Schlüter, &
Jarke, 2006a). The Core Ontology introduces top-level concepts
that describe products and processes, as well as their interre-
lations and dependencies, independently from any particular
domain or application. These fundamental concepts are then
refined and concretized within peripheral ontology modules.
Different ontology modules can be added to the Core Ontol-
ogy to flexibly adapt the PDW to the requirements of a specific
application domain; some exemplary extensions are presented in
Section 3.2. Fig. 1 displays a simplified view of the Core Ontol-
ogy. Four prominent areas of conceptualization are arranged
around the Object as the central concept.
• Product Area. The Product Area (top) contains concepts for
the description of the type and version history of electronic
documents and other information resources, as well as their
323
mutual dependencies and their structural decomposition. The
Product class denotes all kinds of information elements, such
as data items or decision representation objects, which are
created or modified during a work process. Products can be
aggregated into DocumentVersions. The different versions of
a Product can be bundled by a VersionSet. A specialization of
VersionSet is the (logical) Document, which bundles different
DocumentVersions.
• Storage Area. The Storage Area (right) describes at which
location (StoragePlace) inside a Store a particular Version-
Set is stored. Examples of stores are databases, Document
Management Systems, and external tools. Instances of the
Transformation class control the integration of external data,
e.g., by defining XML document transformation based on
XSLT (W3C, 1999).
• Descriptive Area. The Descriptive Area (left) contains
basic concepts for describing the content or the role of
ProductObjects on a high semantic level. This includes Con-
tentDescriptions and Categorizations, which are grouped into
CategorizationSchemes. Unlike Categorizations which sim-
ply classify ProductObjects according to certain categories,
a ContentDescription is a placeholder for a term (or even a
composite expression) from a controlled vocabulary that char-
acterizes the contents of the associated ProductObject. Thus,
the descriptive area provides content-specific meta informa-
tion for the annotation of documents and data stores.
• Process Area. The Process Area (bottom) contains the con-
cepts needed to represent the ProcessObjects that manipulate
(i.e., create, use, or modify) ProductObjects. Process-
Elements comprise general process definitions (Activities)
324 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
such as coarse-grained guidelines for designers or fine-
grained process steps for direct process support. They also
comprise ProcessTraces that describe the concrete actions
performed in a project by Users or (software) Tools. If
ProcessTraces have been executed according to a process
definition given by an Activity, they are related by charac-
terizedBy.
Knowledge is not only contained in information, but also
in the relationships among information items (Rus & Lindvall,
2002). Thus, many relationships have been explicitly modeled
that associate classes inside one area, or between several of the
conceptualization areas. The following may serve as examples:
• describedBy connects the ProductObjects with descriptive
elements that describe their content or category;
• storedAt represents the storage of products and documents in
physical locations such as file systems or repositories;
• manipulatedBy describes how the ProductObjects are created,
used, and modified by the users during process activities;
• a generic dependsOn relation allows to introduce and derive
specialized relations between Objects of any type.
Some of the concepts described here, especially those in
the Product and Process Areas, have been derived from the
traceability reference model introduced by Ramesh and Jarke
(2001). Abstracted from a large number of industrial case stud-
ies, the model describes the conceptual relations of product- and
process-related traces in more detail.
For reasons of interoperability, the Web Ontology Language
OWL (Bechhofer et al., 2004), a W3C standard for the Seman-
tic Web (Berners-Lee, Hendler, & Lassila, 2001), would be the
first choice for the representation of ontologies. However, since
current OWL-based ontology repositories do not offer an effi-
ciently searchable storage in relational databases, the KAON
system (Oberle, Volz, Motik, & Staab, 2004) is used instead.
KAON is based on the same set of base standards (RDF, RDFS,
see Manola & Miller, 2004) as OWL. KAON enables efficient
search and retrieval mechanism directly on the database back-
end, at the cost of loosing some of the expressiveness of OWL
(cf. discussion in Section 7).
3.2. Selected extension modules
The Core Ontology only contains high-level concepts
required to establish, organize, and integrate the four fundamen-
tal Areas. In addition, each Area offers some extension points
where ontology modules for specific application domains or
other specializations can be added. These modules refine the
domain-independent concepts introduced in the Core Ontology
(refinement is indicated by dashed arrows in Fig. 1). Exemplar-
ily, some extensions are presented in the following.
3.2.1. OntoCAPE
The most elaborate of these extensions is OntoCAPE
(Morbach, Yang, & Marquardt, 2007; Yang & Marquardt, 2004),
a large-scale ontology for the domain of computer-aided pro-
cess engineering. OntoCAPE was originally developed in the
COGents project (Braunschweig et al., 2004) and has been
refined in the context of this work. It consists of a set of intercon-
nected partial models which are hierarchically organized across
several levels of abstraction. Important areas covered by Onto-
CAPE are substances and their thermophysical properties, unit
operations and plant equipment, as well as mathematical mod-
eling. The design of OntoCAPE emphasizes extensibility and
ease of customization. Accordingly, only the higher level domain
entities are specified in the ontology at deployment time. The
users can then easily refine and extend the ontology according
to the needs of their respective organizations. The customization
process is guided by several mechanisms, such as the specifica-
tion of a default structure for the partial models, the provision of
design patterns to suggest best-practice solutions for common
design problems, and the definition of a meta model that repre-
sents the underlying design principles of the ontology and is thus
able to enforce design consistency when changing or extending
the ontology.
In the PDW, OntoCAPE extends the Descriptive Area by
refining the ContentDescription class, thus providing a domain-
specific vocabulary for the description of ProductObjects and
ProcessObjects.
3.2.2. Chemical engineering documents
The ontology module Chemical Engineering Documents
refines the generic Document class in the Product Area of the
Core Ontology. It provides a taxonomy of the document types
that are typically used in chemical process design, such as Pro-
cess & Instrumentation Diagrams, equipment lists, or model
files. A detailed description of this ontology module can be found
in Morbach, Hai, Bayer, and Marquardt (2007, chap. 2.3). In an
analogous manner, alternative taxonomies can be developed by
the users of the PDW to represent the document types that exist
in the users’ organization.
3.2.3. Document Management
The Storage Area offers the basic models for file storage
inside a Document Management System (DMS), correlating file-
based documents with their conceptual representation inside the
PDW. This allows to locate the documents in their physical
storage places. Thus, the original documents can be accessed.
Additionally, change notifications from such DMS can be cap-
tured.
The Document Management extension module contains the
Store refinements for various kinds of DMS, including Docu-
mentum (EMC2 , 2006), Jakarta Slide (Slide, 2006), and simpler
systems that do not support version control, such as network
file systems. For each Store, specialized classes of StoragePlace
exist that define the physical location of a document inside the
Store, e.g., by giving a path and file name.
Other kinds of repositories – relational databases, interfaces
to external tools, etc. – also refine the Store class, and use refine-
ments of StoragePlace to define uniquely identifying attributes
(e.g., primary keys or id tags) to represent the physical storage
elements.
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
To achieve an integration of the external systems, it is of
course necessary to develop specific program code for each
external system, and to connect this program code with the onto-
logical class that represents the Store refinement (cf. Section
5.2).
3.2.4. Work Process & Project Management
The Work Process & Project Management module covers pro-
cess models which prescribe (part of) the work processes to be
performed by a designer or a design team confronted with a cer-
tain task. Typically, these process models contain patterns, such
as sequences of Activities or alternative sub-processes. Coarse-
grained process models are represented using a process ontology
based on the C3 modeling language (Eggersmann et al., 2007,
chap. 2.4), a modified version of UML activity diagrams (OMG,
2004) which provides the required expressivity for the weakly
structured design processes in chemical engineering.
At a more fine-grained level, the designer performs his/her
assigned tasks following various methodologies while using
interactive software tools. Because of design creativity, only few
of the methodologies followed are well understood and can be
adequately described using a fine-grained process model. We
refer to such well-understood methodologies as method frag-
ments. In our case, we have extended the Process Area of the
Core Ontology with concepts for formalizing method fragments
using the NATURE process meta model (Rolland, Souveyet, &
Moreno, 1995). Briefly, the NATURE meta model promotes the
contextualization of process knowledge and represents method
fragments as tuples of arbitrary contexts. A context relates the
current process situation to the goal of the designer. Thus, a con-
text might either represent a specific method fragment that has to
be followed, or the need for a choice among several alternative
contexts, or even a simple step operationalized by a tool action.
3.2.5. Design traces
Whereas prescriptive process models capture an ideal
abstraction of the reality, design traces give a faithful descrip-
tion of the real process that provides evidence how the process
evolves over time (Ramesh & Jarke, 2001). This information
can be used, for example, to backtrace poor design decisions,
or to crystallize knowledge out of successful ones. The Design
Traces module, based on the ProcessTrace class, comprises con-
cepts for structuring traces recorded during process execution.
More specifically, concepts are provided for the description of
the sequence of performed process steps, the states of the prod-
uct being worked upon by the process steps, as well as the
relationships between process and product traces.
3.2.6. Decision documentation
The decision documentation module, based on the Deci-
sion Representation Language (DRL) by Lee and Lai (1996),
provides concepts for representing the rationale on which a
design decision is based during a particular project (Theißen &
Marquardt, 2007, chap. 2.5). For example, a Goal can represent
a constraint to be met for a particular DecisionProblem, while
an Alternative denotes a design which is to be evaluated based
on Goals. The decision documentation module is a refinement
325
of the Product class of the Core Ontology. Instances of classes
of this module can be further specified using the concepts of the
descriptive area. For instance, the goal of designing a chemi-
cal reactor with a product stream of 40,000 t/year can easily be
modeled by connecting (i.e., refining) an instance of Goal with
concepts from OntoCAPE.
3.2.7. Application tools
The extension application tools contains a representation of
the software tools that can support a designer when executing a
work process. Activities can be associated with the Tools that are
needed to enact them. Thus, tool environments may be prepared,
preconditions like tool usability may be checked, and users may
be guided in using the appropriate tool. ProcessTraces can be
related to the Tool the changes have been executed in.
Additionally, most software tools only work with certain
document types (or other resource types). By relating this
information to a Tool instance itself, the information resources
resulting from tool use or needed for using the tool can be
identified.
3.3. Architecture of the PDW
In the preceding sections, the general problems of supporting
creative processes have been described, and the Core Ontology
has been introduced. In this section, the architectural structure
of the PDW experience repository as a trace recording and reuse
framework is shown. Furthermore, it is described how the PDW
interacts with the software environment it is realized in. Follow-
ing the authors’ concept of a posteriori integration, the existing
software tools are augmented by integrating them with the PDW
framework. While the engineers can go on working with the
tools they are accustomed to, additional support functionality is
offered by the integrated environment.
Fig. 2 shows how the experience repository of the PDW is
embedded into its usage environment. The PDW server itself
can be seen on the right of the figure. The KAON ontology
framework (Oberle et al., 2004) is responsible for managing the
ontology classes of the PDW and the corresponding instances.
All this data is stored in an SQL2-compatible relational database
(PostgreSQL, 2006), mapping the flexible ontology structure
onto a fixed relational schema. Additionally, KAON offers a
query mechanism that is able to transform requests in a high-
level semantic query language into SQL queries which can be
performed directly on the relational storage back-end. Thus, only
those instances that either result from the query or are navigated
to need to be loaded from storage.
Around this ontology framework, the PDW-Model forms
an implementation wrapper that represents the Core Ontol-
ogy and offers other specialized functionality. It gives access
to the ontological concepts both in a generic way (as classes,
instances, association types, and relations) and by specialized
interfaces.
The realization of the server as described here is placed in an
application server based on the J2EE programming language and
platform (Sun, 2006). This enables the PDW to offer services
326 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Fig. 2. Overview of the PDW architecture.
based on various standardized communication protocols:
• Web services are nowadays often used for service-based
integration of enterprise applications, thus offering company-
spanning workflows that can be dynamically composed.
Especially in a cooperative setting, this allows to extend the
PDW with well-defined and standards-based service inter-
faces.
• Access for thin clients (i.e., web browsers) is provided by
web applications that are using the technologies of Servlets
and Java Server Pages (Sun, 2006).
• Access to the server from rich clients (i.e., stand-alone client
applications) is realized via Enterprise Java Beans, EJB (Sun,
2006).
In the center of Fig. 2, such a rich client application can be
seen. This application, the PDW front-end, forms the primary
means of accessing the PDW experience server and repository.
The front-end contains a client-side representation of a part of the
PDW’s classes and instances, thus reflecting the current state of
information inside the server. Changes to the client-side data are
transferred to the server and persisted in a database transaction.
All those changes are then communicated to the running clients,
allowing the clients to synchronize with the current state of
information, and, possibly, display the newly created or changed
information.
Three different kinds of graphical user interfaces are offered
by the PDW front-end. The generic display is based on UML
notation (OMG, 2004) of the classes and instances of the onto-
logical models. It displays classes and instances as blocks of
different colors with their attribute types and values, and rela-
tions as links between them. This view is mainly aimed at the
ontology engineer responsible for modeling and integrating a
particular domain into the system, and for rapid prototyping of
possible use cases. Specific user interfaces need to be created
for the various application cases, so that the domain users can
work with customized interfaces that offer appropriate solutions
for their problems. Semi-specific interfaces can be used to uni-
formly visualize different concepts of the ontology that have
similar characteristics. This allows to define general rules for
presentation as model annotations, e.g., to display composition
hierarchies or networks of blocks and streams of various kinds,
using the same user interface.
The PDW system is in several ways integrated with its
external environment. As already mentioned, this external envi-
ronment is mainly kept unchanged, it is only extended. A
Document Management System, such as Documentum (EMC2 ,
2006) or Jakarta Slide (Slide, 2006), is responsible for support-
ing document-based storages, offering version management and
change notification support. When an expert checks in a new
version of a document into the DMS, the PDW front-end run-
ning on his or her workplace is notified. The ontology instances
corresponding to the document, its new version, and its storage
place are created or updated and shown to the expert. The doc-
ument instance can then be enriched semi-automatically with
the current organizational context. Possibly, the content of the
document can be transformed from the external tool’s format
into a representation inside the PDW’s repository, provided
that the format can be automatically interpreted (cf. Section
5.2).
Other external tools, mainly those that use repositories or
databases for storage purposes instead of simple files or docu-
ments, can be integrated as external data sources as well. This
often applies to ERP or CAE systems. Their data can usually be
accessed by the programming interfaces offered by these tools,
read and converted into PDW storage, enriched with semantic
information, and transferred to and from other tools for subse-
quent design steps. A generic mechanism for integrating external
data sources has been implemented using XML (W3C, 2006)
as an exchange format, and XSLT (W3C, 1999) to transform
the intermediate files into a form that matches the conceptual
representation of the PDW (for details, see Section 5.2).
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Fig. 3. Query for polyamide-6 reactor equipment.
4. Using the PDW
In Section 4.1, we describe an exemplary session with the
PDW to illustrate its usage in an engineering design project;
usage is demonstrated by means of an application scenario from
the area of conceptual process design. As a single scenario can-
not cover all the application possibilities of the PDW, we will
discuss other use cases in Section 4.2 in a systematic manner.
4.1. A scenario in process design
As application scenario, we consider the conceptual design
of a chemical reactor for polyamide-6, to be performed by
a single engineer who is part of an interdisciplinary design
team. The chosen scenario is part of a large case study on the
design of a polyamide-6 production facility. This case study has
been elaborated in the Collaborative Research Center (CRC)
IMPROVE (Marquardt & Nagl, 2004) in cooperation with indus-
trial partners (e.g., Bayer AG). A detailed description of the
entire case study can be found elsewhere (Bayer, Eggersmann,
Gani, & Schneider, 2002; Eggersmann, Hackenberg, Marquardt,
& Cameron, 2002; Nagl, Westfechtel, & Schneider, 2003).
At the outset of the application scenario, the engineer is
assigned the task of developing a conceptual design for this
polyamide-6 reactor. The only specifications given at this point
are the feedstock – polyamide-6 is to be produced from water and
caprolactam – and the desired amount and material properties
of the polyamide-6 product. To come up with a suitable pro-
cess design, the engineer can draw on the experience knowledge
stored in the PDW.
Typically, a sample session with the PDW consists of three
intertwined steps, each reflecting a different mode of operation:
1. Retrieval of experience knowledge: The user searches the
PDW for experience knowledge matching his/her current
task. To this aim, the PDW supports two modes of operation:
a. The user may either actively search the PDW by compos-
ing queries manually, or
b. he may rely on the PDW’s ability to automatically derive
queries from the current work context of the application
tools (context-sensitive knowledge retrieval).
327
2. Review and reuse of retrieved experience knowledge: The
retrieved information needs to be reviewed by the user, who
can then decide on reusing some or all of the experience
knowledge in the tools that form the current work context.
3. Knowledge capture: The design knowledge created by the
user when processing the current task is recorded and stored
in the PDW in order to increase the knowledge base.
In the following, we discuss how the three steps are carried
out in this particular application scenario.
4.1.1. Step 1a: Manual search for experience knowledge
To gain a first insight into the new task, the engineer wants
to search the PDW for experience knowledge created by former
design projects. In particular, he is interested in the reactor equip-
ment that is typically used for the production of polyamide-6. To
this end, he formulates a query to the PDW by selecting appro-
priate concepts from the PDW ontologies. A graphical query
editor supports the composition of such queries in a “query-by-
example”-based fashion. Ontological classes can be employed as
query variables; that way, all knowledge items that are (seman-
tic) instances of the respective class will be retrieved. The query
variables can be further specified by using relations and already
known instances from the ontology.
As it is shown in Fig. 3, the class ChemicalReactor is chosen
as a first query variable.3 However, since the semantics of this
class is fairly general – it is defined as “any apparatus within
which a chemical reaction takes place” – the query would pro-
duce a large number of unwanted results. Thus, the query needs
to be refined—for instance, by constraining the type of chemical
reaction that takes place in the reactor. This is done by means
of a second query variable, namely ChemicalReaction, which is
linked to ChemicalReactor via the ontological relation takesPla-
ceIn (cf. Fig. 3); takesPlaceIn defines the semantic relationship
between the two query variables. Finally, the ChemicalReaction
is specified by indicating the desired reactants (water and capro-
lactam) as well as the product (polyamide-6) of the reaction; the
3 ChemicalReactor is a class defined in the OntoCAPE ontology (cf. Section
3.2); the prefixed question mark indicates that the class is used as a query variable.
328 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Fig. 4. Query for P&IDs containing information about reactor equipment for polyamide-6 production.
chemical substances are made available by the PDW in form of
instances, their roles in this context (i.e., as reactants or product)
are defined via ontological relations.
The query now reads: “Find all chemical reactors within
which a reaction takes place that has caprolactam and water
as reactants and polyamide-6 as reaction product”. It should be
noted that, since the semantics of all query terms are formally
defined within the PDW ontologies, the computer can inter-
pret the meaning of the query and is therefore able to retrieve
the appropriate knowledge items, even if they are represented
through different (but semantically equivalent) ontological con-
cepts within the PDW. This retrieval mechanism, which is called
“semantic searching”, will be further explained in Section 4.2.
The query is passed to the PDW to search for matching experi-
ence knowledge. Several knowledge items (ontology instances)
are found that match the query; all of them can be recognized
as instances of a particular class, VK Tube, a specialization of
ChemicalReactor representing a special type of column reactor
for polyamide-6 production (e.g., Agrawal, Devika, & Manabe,
2001). The engineer concludes from these facts that a VK tube
reactor is an appropriate choice for this chemical process.
To find out more about the construction of a VK tube, the
engineer decides to search for associated documents. For that
purpose, the above query is extended by concepts from the Core
Ontology’s Product Area. First, ChemicalReactor is linked with
the query variable DocumentVersion via a describedBy relation,
as shown in Fig. 4. Next, the query is further refined by speci-
fying the desired document type: to this end, DocumentVersion
is linked with the class P&ID, a subclass of Document which
is introduced in the ontology extension Chemical Engineering
Documents (cf. Section 3.2) to represent Process & Instrumen-
tation Diagrams. By choosing the relation currentVersion for the
linkage of DocumentVersion and P&ID, only the latest version
of the P&ID document will be retrieved.
Now the query reads: “Find the latest version of any Pro-
cess & Instrumentation Diagram that describes a reactor for
polyamide-6 production from caprolactam and water”. After
processing the query, several P&ID documents are retrieved.
From these, the engineer learns about the specific details of
VK tube design. He now possesses enough information to start
working on his design task.
4.1.2. Step 1b: Context-sensitive retrieval of experience
knowledge
The manual construction of queries is highly flexible, but
as it is a rather complex task it might discourage non-expert
users. Therefore, a more convenient way of knowledge retrieval
is offered by the PDW: Queries are derived from the current work
context of the application tools, thus providing reusable product
or process knowledge that matches the current situation. To this
end, the PDW needs to be integrated with the (legacy) applica-
tion tools used by designers. To demonstrate the feasibility of
this approach, a prototypical experience reuse framework has
been realized, consisting of the Process Data Warehouse, the
process-integrated development environment PRIME (Pohl et
al., 1999) and a proprietary Flowsheet Editor (Bayer, Marquardt,
Weidenhaupt, & Jarke, 2001), which is an advanced prototypical
design environment for process flowsheets.
Assume that the engineer needs to perform simulation exper-
iments to determine certain design parameters of the VK tube
reactor. To this aim, he wants to query the PDW for mathemat-
ical models that can be reused to simulate the physicochemical
behavior of the VK tube. Instead of composing such a query
manually, as it was done in Step 1a, the query can be derived
from the work context of the Flowsheet Editor: An initial Pro-
cess Flow Diagram has been created in the Flowsheet Editor,
reflecting the main process steps and interconnecting material
streams of the polyamide-6 process (Fig. 5, item 1). The search
for an appropriate mathematical model is triggered by clicking
on a menu item “find simulation model” and selecting the sec-
tion of the flow diagram that is to be simulated (Fig. 5, item 2).
Again, the query is composed of concepts from several areas of
the Core Ontology:
• The product part of the query defines the type of document
(i.e., a model file) to be retrieved as well as optional further
constraints such as the desired format (e.g., an Aspen Plus
file).
• The descriptive part of the query specifies the content of the
model by using concepts from OntoCAPE. In this particular
case, the specification comprises the type of model (steady-
state, rigorous), the type of the modeled reactor (VK tube),
and the material streams flowing into and out of the reactor.
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Fig. 5. The application scenario of chemical plant design with PDW support.
• The most important process element is the user’s intention
in this situation, i.e., “find simulation model”, given by the
menu item. This also determines the desired document type,
a model file (see above).
This situation definition can then be passed on to the Process
Data Warehouse to search for matching experience information
(Fig. 5, item 3).
4.1.3. Step 2: Review and reuse of retrieved experience
knowledge
In the example scenario, several different mathematical mod-
els for the simulation of a polyamide-6 reactor are found and
returned. The models are combinations of different standard
model blocks, such as flash units, Plug Flow Reactors (PFR), or
Continuous Stirred Tank Reactors (CSTR), which are intercon-
nected via process streams. This information is then presented to
the user via the front-end of the PDW (Fig. 5, item 4). Two dif-
ferent visualizations, as described in Section 3.3, can be applied
here: The generic representation shows the class instances, their
attributes and relations in UML instance notation, while the spe-
cific representation in this case shows a graphical snapshot of
the reactor models (see Fig. 6).
Now the expert needs to decide which of the simulation
models to reuse. The PDW supports this decision-making
by providing additional information about the models in the
Description Area, such as the reaction kinetics and material
properties data used in the model. Moreover, by browsing
associated concepts from the Process Area (refinements of Pro-
cessTrace) and related decision documentation, the user may
find out more about the former usage of the models. For exam-
ple, he may learn that a particular model was developed for
an initial feasibility study (and is therefore likely to be rather
simple and inaccurate), while another model was employed for
329
detailed design calculations and was therefore validated against
experimental data. Thus, in accordance with the present task,
the engineer decides to reuse the latter model.
The model is then retrieved from the PDW and adapted
according to the specifications of the given design task. Sim-
ulation experiments are performed, from which the engineer
derives design parameters such as temperature, flow rates, or
dimensions. Based on these parameters, the reactor equipment
(apparatus, heat transfer equipment, etc.) is specified. Option-
ally, the rationale underlying this specification process can be
documented using the concepts of the decision documentation
module. For instance, assume that the engineer is notified about
a still functional VK tube available from a decommissioned
plant. The capacity of this tube is not sufficient for the new
plant, but it can be used to realize an alternative plant design
comprising two VK tubes in parallel. In contrast to the orig-
inal design, the alternative would require the acquisition of
a considerably smaller and cheaper VK tube, which finally
makes the engineer opt for the alternative design. This deci-
sion is likely to become inscrutable when the knowledge about
the already existing VK tube becomes lost. Thus, the engi-
neer explicitly documents the underlying constraints to make
sure that his decision in this particular case will not affect
other design projects when knowledge from this project may be
reused.
4.1.4. Step 3: Knowledge capture
Up to now, the scenario process comprises specifying a reac-
tor design, simulating its behavior, analyzing the results, and
finally the decision for a specific design. This process is traced,
and some design knowledge is extracted, recorded, and stored in
the PDW in order to augment the knowledge base. Apart from
the product information (the adapted simulation model as well as
the design specification in the Flowsheet Editor), the task-related
330 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Fig. 6. The generic (left) and the specific (right) visualizations of the search results.
working steps and situations are traced (semi-)automatically.
The technical realization of this knowledge capture is discussed
in Section 5.
Fig. 7 illustrates how (part of) the application scenario is
captured within the PDW. Grey boxes represent instances of
classes, which are defined in the peripheral ontology mod-
ules. For the sake of illustration, the representation has been
simplified.
The Product Area represents the ProductObjects that are
created in the scenario. ReactorBlock is an instance of Prod-
uct representing the VK reactor within the Flowsheet Editor;
it is contained in the ProcessFlowDiagram v0.7, which is
an instance of the DocumentVersion class. ModelFile v1.0 is
another instance of DocumentVersion representing the math-
ematical model used in the final calculations for the original
design featuring a single tube. ModelFile v1.0 and Process-
FlowDiagram v0.7 are the current versions of ModelFile and
ProcessFlowDiagram, respectively, which are instances of the
Document class. The upper part of the Product Area shows
instances of the decision documentation module representing
the rationale to use a design with two VK tubes. For the
NumberOfVK TubesProblem, which is an instance of the class
DecisionProblem, two instances of the class Alternative have
been evaluated with respect to the sub-goal EconomyGoal (only
the Evaluation of the TwoTubesAlternative is shown in the fig-
ure), taking into account the existence of an old VK tube.
Based on these Evaluations, the final Decision is in favor of
the TwoTubesAlternative.
In the Descriptive Area, the ProductObjects are described by
domain-specific concepts: ModelFile v1.0 is characterized as a
MathematicalModel that models the behaviour of a VK Tube;
VK Tube, in turn, describes both the ReactorBlock and the
SingleTubeAlternative. MathematicalModel and VK Tube are
further specified by the indication of the ChemicalReaction,
which has Caprolactam and Water as reactants and Polyamide-6
as reaction product.
In the Storage Area, all file versions of the Aspen Mod-
elFile are storedAt the location “<project>/AspenFile#1” (a
StoragePlace) inside the DocumentManagementSystem “Doc-
umentum”. The Flowsheet Editor uses a database storage of
its own that can be accessed via certain programming inter-
faces. Therefore, this store has been integrated via this interface
(ToolInterface), using parameterized StorageQueries to get cur-
rent and historical flowsheet data.
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342 331

Fig. 7. Representation of the application scenario within the PDW.

The Process Area describes the usage and/or manipulation of
the Products. The tasks that the engineer performs in the scenario
are represented by instances of ProcessTrace (e.g., Modeling to
denote the creation of the reactor model, and Deciding for the
final decision to use the two-tube design). Appropriate instances
of the classes User and Tool describe the human and computer
agents involved in the work process. The ProductObjects pro-
duced during the engineering activities are associated with the
ProcessTraces via the relation createdBy, a specialization of the
manipulatedBy relation introduced in Fig. 1.
4.2. Additional use cases
This section summarizes the different usage possibilities of
the PDW, some of which have already been mentioned in the
section above. In Section 4.2.1, the reuse of product knowl-
edge (i.e., documents and data) is discussed, while Section 4.2.2
addresses the reuse of process knowledge, including decisions.
The support of intra-organizational and cross-organizational
cooperation is addressed in Sections 4.2.3 and 4.2.4, respec-
tively.
4.2.1. Reuse of product knowledge
Retrieval of product knowledge (as well as process knowl-
edge) is supported by three major retrieval mechanisms: (1)
semantic search, (2) browsing ontological categories, and (3)
navigating through a semantic network of interconnected, the-
matically related resources. All these retrieval mechanisms rely
on the description of the resources through meta information. As
explained before, this meta information is represented by instan-
tiating the classes and relations specified in the Core Ontology
and their various extensions. The PDW does not only support
332 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
conventional, but also content-specific meta information to char-
acterize the contents of the different documents and data stores.
The terminology for the content descriptions is provided by the
ontology modules that extend the Descriptive Area of the Core
Ontology, particularly by the domain ontology OntoCAPE.
In the following, the usage of the different retrieval mecha-
nisms offered by the PDW will be discussed in detail.
4.2.1.1. Semantic search. As explained before, semantic search
retrieves information based on the types of the information
items and the relations between them, instead of using sim-
ple string comparisons. Queries to the PDW can be composed
from arbitrary concepts (classes, instances, relations, attributes)
of the PDW ontologies. A major advantage over conventional
keyword search is the possibility to connect query terms via
ontological relations instead of using Boolean operators. In
conventional information retrieval, Boolean operators produce
ambiguous queries. Consider, for example, a query for a reac-
tor that produces Caprolactam. If the logical operator AND
was used to combine the query terms “Reactor” and “Capro-
lactam”, the query could refer to a reactor for the production
of Caprolactam as well as to a reactor that takes Caprolac-
tam as a feed. The ambiguity can be resolved by replacing the
generic AND by the more specific relation “hasOutput” (which
produces the composite query “Reactor hasOutput Caprolac-
tam”). That way, the intended meaning of the query is clearly
defined.
The queries are processed by the PDW’s built-in semantic
search engine which tries to match the query expression against
the meta information describing the various knowledge items.
Since the semantics of the ontological concepts are formally
defined, the search engine can interpret the meaning of both
query and meta information in order to find a semantic match.
This approach has the following advantages:
• The search engine has the ability to skip homonyms4 during a
search in order to avoid some of the unwanted results produced
by conventional search engines. For instance, consider search-
ing for information about the reaction of a certain substance.
A conventional search using the keyword “reaction” would
yield not only the desired information but also information
about allergic reactions to this substance. The semantic search
engine, on the other hand, can distinguish between a chemical
reaction and an allergic reaction since their respective mean-
ings are formally defined in the PDW ontologies. Thus, as
only information with the desired meaning is retrieved, the
precision5 of the search is largely improved.
• Based on the inference functionality offered by the ontology
language, the semantic search engine takes the specialization
relations between ontological classes into account. This helps
to resolve the following dilemma of knowledge retrieval:
domain experts prefer to use domain terminology as meta
4 Homonyms are terms with the same spelling but different meaning.
5 Precision is defined as the proportion of relevant information out of all the
retrieved information.
information since this enables the precise description of
knowledge items and therefore increases the probability of
relevant retrieval. However, such a specialized vocabulary
restricts the access to the knowledge for a novice (Hinds,
1999) as well as for a specialist from another area (Dougherty,
1992). The PDW supports users of both groups: while domain
experts will prefer a specialized terminology to annotate and
query the repository, non-specialists may use more generic
terms for information retrieval. The special terms are derived
from the more general ones, and these specialization rela-
tions are automatically inferred. Therefore, the knowledge
resources will be found either way. For example, if an expert
chooses the term “Reactor” to annotate a resource, it can actu-
ally be retrieved by the generic query term “Vessel” since
Reactor is defined as a subclass of Vessel in the ontology.
4.2.1.2. Browsing by categories. A second way to retrieve
product knowledge from the PDW can be achieved by brows-
ing the available meta information. To this aim, the ontology
modules that extend the Descriptive Area of the Core Ontology
provide categories to structure the meta information.
• Some Products are explicitly categorized by means of the Cat-
egory concept. A well-known example for this type of retrieval
mechanism is the Yahoo! Directory, http://dir.yahoo.com/.
Classification under more than one category is of course pos-
sible.
• The ContentDescriptions of Products can be searched in a
similar way. As explained, ContentDescriptions are given by
the OntoCAPE ontology. OntoCAPE has a concise structure
which can be browsed easily: the ontology is thematically par-
titioned into sub-ontologies (called “partial models”) which
already constitute a coarse categorization of the domain. The
partial models are consistently structured: on the entrance
level, the top-level classes are organized according to the
principles of general systems theory (e.g., van Gigch, 1991);
the classes are then refined on the lower levels, thus creating
taxonomies of specialized subcategories. To find informa-
tion about a specific topic, one firstly selects the appropriate
partial model and then browses its class hierarchy for meta
information that describe the respective Products.
4.2.1.3. Navigating through a semantic network. Another pos-
sibility to explore the PDW is given by the ontological relations
that interlink the individual ContentDescriptions. They form a
directed graph, consisting of nodes which represent instances of
ContentDescription and arcs which represent semantic relations
between these ContentDescriptions. Such a semantic network
(e.g., Sowa, 1991) of related meta information can be navigated
by means of custom tools like the PDW front-end.
Semantic relations cannot only be used to connect Content-
Descriptions describing similar contents but also to interrelate
ContentDescriptions with complementary contents, thus point-
ing to additional product knowledge that would otherwise
remain undetected. For instance, the documents ModelFile
and ProcessFlowDiagram created in the application scenario
(cf. Figs. 5 and 7), provide complementary information about
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
the chemical reactor. Therefore, their ContentDescriptions are
linked via the modelsBehaviorOf relation. A user may navigate
from the simulation model of the reactor to the flowsheet object
describing its realization, and vice versa. Such navigation is use-
ful in daily work when questions arise like: “Where can I find
the simulation model that was used to design this apparatus!”.
Furthermore, ontological relations may be used to link Pro-
ductObjects to concepts from the other areas of the Core
Ontology in order to provide some additional information about
the respective products:
• Via relations, it is possible to point from a document to its
author or other potential knowledge holders that might be
relevant in this context.
• By connecting ProductObjects to ProcessObjects, it becomes
possible to provide information about the organizational con-
text (i.e., the work processes and decision-making procedures)
in which a product was created, used, or modified. This allows
to answer questions such as “What has this model file been uti-
lized for?” or “Which decisions have been taken on the basis
of this data?”. That is, by analyzing the organizational context
associated with some design knowledge, one can evaluate the
applicability of the retrieved knowledge to the current work
situation. As pointed out by Carlile and Rebentisch (2003),
the circumstances in which the knowledge has been produced
are highly relevant for its successful reuse: if the context of
the information item changes between storing and reusing
this knowledge, new requirements or novel conditions arise.
In this case, the stored knowledge is no longer relevant and
can even become harmful when it is retrieved for reuse and
applied under wrong conditions.
Concluding the discussion about the reuse of product knowl-
edge, we would like to emphasize the PDW’s ability to centralize
access to product information. Such a central point of access
greatly facilitates the retrieval of product knowledge. The PDW
allows to simultaneously search the contents of all kinds of doc-
uments and data stores, regardless of their respective formats or
storage locations, which reduces the search effort significantly.
Ease of use is further improved by the fact that the individual
sources can be explored via a single, familiar user interface.
Also, the PDW contains relationships between elements of dif-
ferent sources, which allows to find information based on these
relations that are not contained in any of the data sources them-
selves. Moreover, the PDW allows to search information sources
that could not be accessed otherwise, as the user might not
have the required software or access rights to open the origi-
nal sources. And lastly, the search considers even sources of the
existence of which the designer was not even aware. Thus, the
scope of knowledge retrieval is widened while the search effort
is reduced.
4.2.2. Reuse of process knowledge
The PDW contains coarse-grained and fine-grained process
traces and decision-making procedures. The rationale leading to
a decision commonly spans multiple working steps, each with
different products being manipulated. Hence, the full scope of
333
the rationale is only recognizable when looking at the process
history. Together with other aspects of the Process Area, they
document the organizational context in which a certain project
has been or is being conducted.
Beyond this documentation of organizational context, poten-
tial applications for reusing this process knowledge are (1)
process advice, and (2) the automatic execution of processes.
(1) One can systematically search for a work context similar
to the current situation to find some procedural advice that
is applicable. Moreover, by analyzing the ProcessTraces of
already accomplished projects, the user can find out who
already solved a certain type of problem, and he can con-
tact this expert directly to draw on the person’s implicit
knowledge.
(2) This also offers the possibility of analyzing the data to
detect recurring fragments. Fine-grained process support
can then be offered to the user by guiding him or her through
these fragments, or even enacting those traces in the process
engine of the process integrated environment (see PRIME
in Section 5.5).
4.2.3. Support of intra-organizational cooperation
The members of design teams need to communicate effi-
ciently to achieve the common goal of completing a project.
Typically, the team members are distributed across disparate
locations and use different software tools to create and manip-
ulate product information. The PDW guides and drives the
transfer of development product information between team
members and across software systems. The participating experts
directly access the repository of the PDW, which contains the
product and process traces of the project, thus reflecting its
current status. Access can be achieved by extending the com-
mon design tools of the domain with additional, integrated
functionality that accesses the PDW’s repository. The PDW par-
ticularly improves the communication in interdisciplinary teams
where the team members have heterogeneous professional back-
grounds, as the ontologies provide access at different levels of
expert knowledge (cf. discussion in Section 4.2.1).
In later stages of the plant lifecycle, the PDW can be used as
an information base to support tasks like change management,
plant expansion, or claims management.
4.2.4. Support of cross-organizational cooperation
Information often needs to be passed on to a coopera-
tion partner, based on strict rules of intellectual property and
need-to-know. Besides the problems of business agreements,
communications, and the technologies used for information
transfer, it must be ensured that only specific information may
be passed across organizational boundaries. Consequently, the
cooperation partner may only be allowed to have access to a
restricted and well-controlled view of the repository.
To define such a view on the side of the contractee (i.e.,
the delegating company), cooperative discussions among the
contractee’s experts are necessary. They need to agree which
information items (ontology instances), relations between these
items (ontology relationships), and which of their attributes may
334 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
be transferred to the external contractor (“released”). The dis-
cussion results are recorded in the PDW, including the decisions
taken with their arguments, and the data to be transferred. This
enables the reuse of these traces in later cooperations. In the
front-end of the PDW (see Section 3.3), the instances that corre-
spond to the released information can be marked. Furthermore,
view definitions may be abstracted from a concrete view to define
which information items are to be usually released jointly.
The marked information can then be exported into an ontolog-
ical format (e.g., OWL, Bechhofer et al., 2004) and transferred
to the contractor. This ontological information is defined by
a precise semantic structure; thus, the contractor can draw on
computer support (e.g., transformations or matching rules) to
integrate the information into his own information systems.
While the task is being solved at the contractor’s site, infor-
mation may be recognized to be missing. In this case, it has to be
inquired from the contractee. The PDW allows finding this data
and, possibly, additionally retrieving the decision that led to its
exclusion. This decision may now either be revised (allowing
the data to be released) or confirmed.
As a last part of the cooperation process, the information
returned from the contractor needs to be reviewed, discussed,
and then integrated into the project flow through the PDW’s
repository. Similarly, the PDW can support the contractor,
instead of the contractee as described above. More information
about the cross-organizational support functionality of the PDW
can be found in Brandt, Fritzen, Jarke, and List (2007, chap. 4.1)
and Brandt, Schlüter, and Jarke (2006b).
5. Knowledge acquisition
This section describes how information, and thus knowledge,
from existing sources can be acquired by the PDW. Section 5.1
discusses the problems of knowledge acquisition in general.
Section 5.2 gives an overview on how the PDW handles the
integration of external data sources. The subsequent sections
provide examples of these integrations.
5.1. General problems of knowledge acquisition
Knowledge acquisition – that is, the process of capturing
and storing knowledge in an appropriate format in a knowledge
base – is recognized as a major bottleneck when it comes to the
deployment of a knowledge management system in an organi-
zation (e.g., Abecker, Bernardi, Hinkelmann, Kiihn, & Sintek,
1998; Carlile & Rebentisch, 2003; Thomson, Adams, Cowley,
& Walker, 2003; Zeng, Pan, Zheng, & Peng, 2006). In indus-
trial practice, documentation and archival of design knowledge
is often neglected or not performed at all. The reasons for this
are two-fold.
Employees are reluctant to invest much time in sharing their
knowledge since this requires extra effort on top of their daily
workload, from which they do not profit personally. Even worse,
by making their knowledge explicit, employees could weaken
their position as indispensable knowledge holders in the orga-
nization, and thus facilitate their replacement. Likewise, project
leaders have little interest in enforcing a thorough documenta-
tion of processes and key decisions, as these do not count among
the core activities of a project and are therefore not considered
in the project budget and schedule.
While this lack of motivation can be counteracted by appro-
priate reward systems (e.g., Rus & Lindvall, 2002), a second
problem is that knowledge capture is both haphazard and error-
prone: empirical studies (e.g., Furner, Ellis, & Willett, 1999;
Furnas, Landauer, Gomez, & Dumais, 1987; Leonard, 1977)
have shown that little agreement exists among different per-
sons on the sets of annotation terms to be assigned to individual
resources. Thus, meta information about products is chosen
inconsistently and, similarly, work processes and decision-
making procedures are captured by different users in different
ways (e.g., using dissimilar structuring mechanisms on different
levels of detail). Consequently, knowledge retrieval is severely
limited, as only part of the available knowledge items would be
properly integrated into the ontology structure of the PDW and
thus could be found by some query.
A solution to these problems is to automate knowledge acqui-
sition as much as possible. Depending on the nature of the
knowledge, different techniques can be applied, some of which
will be described in the following sections.
5.2. Connecting external data sources
The recording of product information is normally realized
inside the different software tools of a development environment.
Thus, an important task of the PDW is to transfer information
from the external data sources into its repository. This concerns
document-based tools, application tools that use a database store
themselves (such as CAE systems), external databases (such as
material databases), and complete software systems that provide
certain data or programming interfaces (such as ERP systems).
The architectural concepts of integrating these data sources have
already been introduced in Section 3.3. Here, the underlying
mechanisms for connecting external data sources and converting
their contents to and from the information storage of the PDW
will be described in more detail.
For this goal, a flexible and extensible mechanism had to
be developed for integrating all these different kinds of data
sources. External stores and their elements can be represented
through ontological concepts from the Storage Area, particularly
Store and StoragePlace. For accessing the external stores and
converting their data into the PDW format, “connectors” and
“transformers” have been designed which will be described in
the following. The two cases of file-based storage and external
tool interfaces will be distinguished.
5.2.1. Importing documents
When working with documents or files, those are usually
stored inside a Document Management System, which auto-
matically offers cooperative features like shared folders, file
locking, access control, and workflow management. The Doc-
umentum (EMC2 , 2006) system and the Jakarta Slide system
(Slide, 2006), which is based on the WebDAV standard (Web
Distributed Authoring and Versioning, RFC, 1999), have been
integrated with the PDW for this purpose.
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
When a new version of such a document is checked into the
DMS, the PDW is notified of this change and can then locate the
corresponding ontology instances for the Store, the place where
the document is stored (StoragePlace), and the logical document
concept (the Document) with its various versions (DocumentVer-
sion). A connector which needs to be specifically developed for
each kind of source document, is then responsible for reading the
information from the external file into an intermediate, XML-
based format. This format is usually specific for each application
the document stems from. Sometimes, the information from sev-
eral tools may be treated the same way, or needs to be integrated
to construct a comprehensive intermediate document (see Sec-
tion 5.3 for an example). In most cases, only part of the external
file needs to be read, as some specific details or fine-grained
aspects are often not necessary for the “overview” aspect of the
PDW.
This intermediate XML is then transformed into an input
format that directly represents instances of the PDW’s con-
cepts. The appropriate Transformation instance is looked up in
the PDW, and the corresponding transformer is activated. RDF
Schema (W3C, 2004) is used here as output format from the
transformers and thus, as input format to the PDW. This has
the advantage that, on the one hand, the KAON system which
forms the base of the PDW, can directly work with it; on the other
hand, many cases allow to use powerful XML Schema Transfor-
mations (XSLT; W3C, 1999) to convert the intermediate XML
into the XML-based RDF Schema representation. The Product
instances corresponding to the entities defined in the input files,
and their related descriptive meta information, can be created
from this data; furthermore, relations to or from existing identi-
fiable instances can be created or modified. It is also possible to
find the differences between the existing and the new version of
the document, thus importing only the changes into the PDW.
Sometimes, such a transformation is not possible, as the
document is too weakly structured or the necessary imple-
mentation has not yet been realized. In such a case, it is also
possible to annotate and/or enrich the Document and Docu-
mentVersion instances of the PDW manually, for example, by
classifying them into categories or by providing other kinds of
content description. Several tools are available for this purpose:
existing markup tools like the OntoMat-Annotizer (Annotation
Portal, 2006) or SemanticWord (Teknowledge, 2006) support
the annotation of informal text documents with ontological con-
cepts via simple drag and drop operations. The tool TRAMP
(Jarke, Miatidis, Schlüter, & Brandt, 2006) has been especially
developed for structuring and annotating multimedia contents
resulting from three-dimensional simulations in plastics engi-
neering. Also, the organizational aspect (especially the current
user and workflow activities) can be recorded in relation to the
imported information: traces of coarse-grained work processes
can be captured by the Workflow Modeling System WOMS (cf.
Section 5.4). For supplementary information like decisions taken
and their arguments, specialized tools (e.g., a decision editor) are
being developed.
Additionally, environments for fine-grained process support
at the engineering workplaces can store traced experiences in the
PDW and reuse them when demanded, by providing experience-
335
based methodical guidance for developers. To this end, the
PRIME process-integrated modeling environment closely inter-
weaves with the PDW (cf. Section 5.5).
This kind of external source integration described so far is
usually change- or source-driven: that is, when a user changes
a document with the corresponding tool, the new information is
stored in the PDW. This stands in contrast to the query-driven
integration as described in the following.
5.2.2. Integrating databases and tools
Often, information needed for the PDW is stored by an
external application in some repository or database format that
cannot be accessed directly, but only through the programming
interfaces offered by the external tool. Sometimes, information
from such a tool is required in the PDW, e.g., when browsing
through the experience base and navigating from an instance
that is related to an external storage representation. In this case,
a connector as described above, is responsible for retrieving
the required data and writing it into the intermediate XML
format. Again, this XML data is transformed by the appropri-
ate transformer and then imported into the PDW as instances,
attributes and relationships. Similar queries can be executed on
database back-ends, often by using SQL. The execution of these
queries can also be triggered by external events (source-driven,
as above), or done regularly.
As an example, the ERP system SAP R/3 (SAP, 2006) has
been integrated into certain PDW-based workflows. This allows
to retrieve the transport history of certain goods by calling the
appropriate SAP interface method, and use this information
for information visualization and semantic queries in the PDW
(Kopecky, 2006). Usually, the relatively unstructured design pro-
cesses are not supported by deterministic systems like ERP. The
PDW, in contrast, allows to relate these creative design processes
on the one hand, with the administrative or business perspective
on the other hand. This can be achieved by integrating the pro-
cess traces of the PDW with the project management sub-system
of the ERP system.
5.3. Conversion of simulation models
Conversion of document formats with well-defined syntax
and semantics (databases, XML files, model files, etc.) can
automatically be performed by connectors that extract meta
information from the documents and transformers that map
it onto the ontologies of the PDW. For demonstration pur-
poses, a prototypical converter has been developed, which
can automatically create content-specific meta information for
model files of the process simulator Aspen Plus (AspenTech,
2006).
The converter follows a step-wise approach: in the first step
of this conversion process, a mathematical model represented in
the Aspen Plus input format (.inp), is converted to a so-called
raw XML file, which gives a more structured representation of
(selected portions of) the Aspen Plus model. In the next step,
the raw XML is transformed into CapeML, an XML-based
model exchange language specifically developed for the CAPE
domain (von Wedel, 2002). This second conversion step com-
336 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Fig. 8. Step-wise conversion of Aspen Plus files into an OWL file.
prises a further structural as well as a semantic enrichment
of the raw XML data. Additionally, material property infor-
mation derived from an Aspen Plus report file (.rep) may be
included in the CapeML file. In the final step, the CapeML
file is converted to an OWL file; this transformation comprises
both a format conversion and a further semantic enrichment.
The resulting file can then be imported by the PDW (simi-
lar to the import based on RDF Schema described in Section
5.2).
A graphical illustration of the conversion chain is shown
in Fig. 8: the Aspen2CapeML Converter integrates the first
two conversion steps, which are indicated by the blocks Aspen
Inp(ut) Handler and Report File Handler. The final conversion
is performed by the XML2OWL Converter (Amin & Morbach,
2007).
The converters implementing the different steps of the con-
version chain may also be used independently. In particular, the
XML2OWL converter is not limited to handling CapeML files;
rather, it is capable of mapping arbitrary XML data onto any
existing OWL ontology. The conversion from XML to OWL is
controlled by so-called mapping rules specified in an external
rules definition file. These rules can be formulated easily and
without deep knowledge of the converter’s program logic. Thus,
the converter can be easily configured to a number of differ-
ent mapping problems, such as the WOMS to OWL conversion
described in the next section.
5.4. Process and decision documentation
The Workflow Modeling System WOMS was created for
modeling design processes on a coarse-grained level (cf. Hai,
Theißen, Schneider, Morbach, & Marquardt, 2007, chap. 5.1).
The tool, based on Microsoft Visio, supports a variant of the
C3 modeling language. Its graphical user interface (see Fig. 9)
provides the C3 modeling elements which can easily be dragged
into the drawing area. Several macros support the easy and intu-
itive creation of work process models. WOMS is suitable for
both prescriptive models (e.g., guidelines or best practices for
designers) and descriptive models of executed design processes
(i.e., design traces). As the tool provides an export functionality
to XML, the further conversion into OWL is realized by using
the XML2OWL converter described in Section 5.3; the OWL
representation can then be imported by the PDW. Depending on
the type of the work process model (prescriptive or descriptive),
the OWL representation is based either on concepts defined in
the extension module Work Process & Project Management or
on concepts defined in Design Traces (cf. Section 3).
The difficulties in knowledge acquisition described in the
beginning of Section 5 are in particular significant for capturing
and documenting the rationale of design decisions. Document-
ing design rationale is often seen as an unacceptable overhead
by designers (e.g., Lee, 1997), while the beneficiaries of the doc-
umentation are typically to be found later in the design process
or even later in the life cycle of the artifact (Grudin, 1996), for
example, on the occasion of a retrofit of an existing plant. A fur-
ther obstacle is the reluctance to explicitly document discarded
alternatives as they might be conceived as an indication of not
working in an optimal way. In order to support designers as
far as possible during the creation of decision documentation,
an extended version of WOMS is under development, which
will support the integrated documentation of work processes
and decisions.
5.5. Process-integrated tracing and guidance
The considerable heterogeneity of the software tools
supporting various design tasks greatly complicates their inter-
operability as well as the exchange of data (cf. Section 2). As
a remedy to this problem, integrated tool environments consti-
tute an ambitious endeavor for integrating individual tools into
a coherent whole, whose interplay is much easier to coordinate.
Typically, such environments employ application and process
integration techniques in order to orchestrate the services pro-
vided by disparate legacy systems using some sort of middleware
and agreed-upon protocol.
In the context of the IMPROVE project, we aimed at devel-
oping such an approach in order to integrate the heterogeneous
tools employed during the reference polyamide-6 design pro-
cess, and provide method guidance to the designer based on
previously traced experiences. To this end, we adapted the
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342 337

Fig. 9. Workflow Modeling System WOMS.

Process-Integrated Modeling Environment (PRIME) approach can potentially exploit the following four extension modules of
to build an integrated design support environment for chemi- the Core Ontology:
cal engineering (Jarke, List, & Weidenhaupt, 1999; Pohl et al.,
1999; Weidenhaupt, 2001). PRIME is especially well suited for
• process models which are described by using fine-grained
the realization of tool environments for creative processes, like
concepts of the Work Process & Project Management module,
engineering design processes. It builds on the key idea of a pos-
can be enacted by process-integrated tools in order to provide
teriori process integration that offers the potential to flexibly
method guidance to the designer;
couple different tools. At the same time, it provides flexible,
• the Design Traces module can be used to build a concrete
situated method guidance to the designer directly from inside
traceability structure, according to which the design history
his tools. More specifically, PRIME is able to record all the
inside process-integrated tools is recorded;
actions executed inside a process-integrated tool, as well as the
• inside PRIME, process-integrated tools are modeled with
products worked upon by these actions. The recorded infor-
respect to their services and user interface capabilities. Thus,
mation is structured according to a concrete traceability meta
the application tools module can be employed for their
model abstracted from a number of case studies (Ramesh &
description;
Jarke, 2001). On the other hand, recorded process or product
• lastly, descriptions of the products manipulated by process-
experiences from the past can be reused, on request, inside
integrated tools, can be represented using elements from the
process-integrated tools. Then, the tool is able to automatically
Chemical Engineering Documents module.
execute the steps comprising a requested method fragment, or
directly load products for reuse support, corresponding to the
current design situation (Miatidis, Jarke, & Weidenhaupt, 2007, 6. Related work
chap. 3.1).
The overall PRIME-IMPROVE environment has been imple- As already discussed in Section 2, most of the existing PDM
mented as a flowsheet-centered architecture that operationally and PLM systems still lack essential aspects needed for sup-
couples the fully process-integrated Flowsheet Editor (cf. Sec- porting phases of conceptual design, such as capabilities for
tion 4.1) with other domains-specific simulation tools (Bayer et knowledge management (Gao et al., 2003), or flexible data struc-
al., 2001). It has a flexible repository layer that can be fairly tures that allow runtime extensions and adaptations (Marquardt
easily adapted in order to exploit the PDW infrastructure for the & Nagl, 2004). Some recent research projects try to extend
persistent storage of information manipulated or generated by the capabilities of PDM/PLM systems. Two examples from the
process-integrated tools. More specifically, the PRIME approach domain of automotive engineering are given in the following.
338 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Kim, Kang, Lee, and Yoo (2001) have integrated concepts
of artificial intelligence into commercial PDM systems. The
software is based on a dynamic and flexible workflow model,
as opposed to the deterministic workflows seen in most com-
mercial PDM applications. A built-in workflow management
system enables the integrated management of task processes
and information flows. The system can be searched by means
of a semantic query and manipulation language. However, the
system relies on prescriptive process definitions which require
relatively well-understood and well-documented processes. As
this does not apply to conceptual process engineering, this
approach cannot be used here.
Gao et al. (2003) describe an integration of a PDM system
with ontological methods and tools. The Protégé ontology edi-
tor (Stanford Medical Informatics, 2006) is combined with a
commercial PDM system to provide knowledge management
capabilities for the conceptual design stage. In an associated
research project, a graphical interfaces for user-friendly knowl-
edge acquisition has been developed. In contrast to the PDW
described here, knowledge needs to be entered manually and
explicitly, based on ontology instances and static rules; expe-
rience knowledge is not recorded. Again, this approach relies
on a domain where the processes are better understood than in
process engineering.
Some research teams are currently developing design repos-
itories based on semantic technologies. Two representative
examples from the domain of electromechanical engineering
are described below.
Kopena and Regli (2003) designed an ontology for the rep-
resentation of product knowledge. A Core Ontology defines
the basic structure to describe products from a functional view.
Vocabulary extensions describe the domain of electromechani-
cal devices. The model representation is based on a Description
Logic (DL) system with low expressivity to achieve good com-
putability and scalability (cf. discussion in Section 7).
Szykman, Sriram, Bochenek, Racz, and Senfaute (2000)
describe a design repository to enable storage and retrieval of
design artifact knowledge. It is based on a proprietary knowledge
base implementation that can be accessed via a web interface.
All queries need to be developed manually and coded as spe-
cific algorithms. The system uses technologies that predate the
Semantic Web approach. Consequently, it tries to mimic the
functionality of ontological models and semantic technologies
without reaching their potential.
Both described design repositories are limited to the storage
of product data and documents. They do not offer support for
the recording and management of the associated work processes
and decision-making procedures. A review of other recent devel-
opments in the area of representation, capture and retrieval of
design knowledge is given also by Szykman et al. (2001).
An ontological architecture for knowledge management that
resembles the Core Ontology described here has been pro-
posed by Abecker et al. (1998). Similar to our approach, the
proposed ontology-based system it is intended to enable both
content-specific and task-specific retrieval of resources. The
authors distinguish three types of interconnected ontologies:
Information Ontologies that model the different kinds of infor-
mation sources, their structure, access permissions, and format
properties; Domain Ontologies that describe the content of the
information sources; and Enterprise Ontologies that model the
organizational context, such as the work processes or the struc-
ture of an enterprise. Thus, the Information Ontologies cover
the scope of both the Product Area and Storage Area of the
Core Ontology, the scope of the Domain Ontologies correspond
to that of the Descriptive Area, and the Enterprise Ontologies
resemble the Process Area. The paper gives a good overview on
the process of knowledge management itself and the concepts
of ontological support, from the perspective of computer and
information science. The application of these concepts to engi-
neering domains does not fall into the scope of this particular
research group.
In the area of chemical engineering, several prototypical
design environments have been developed based on ontological
models and tools. Unlike the PDW, these environments focus
on other aspects than knowledge management and experience
reuse. Some recent examples are given here.
Bañares-Alcántara and Lababidi (1995) have developed
KBDS, a prototypical design support system for process
engineering. The implementation is based on CLOS, an object-
oriented extension of Common Lisp, and additionally makes
use of an assumption-based truth maintenance system (ATMS).
KDBS is not a full-fledged KM system, but incorporates some of
its features: it supports (1) the representation and management
of different design alternatives (i.e., alternative flowsheets) and
their relations to mathematical models, (2) the documentation
of the design objectives, (3) the evaluation of a design alter-
native against a previously stated set of design objectives, and
(4) the evolution of these aspects during a design project. The
representation of design rationale in KBDS (Bañares-Alcántara
& King, 1996) is based on IBIS (Issue-Based Information Sys-
tems, Kunz & Rittel, 1970), a graphical notation similar to DRL,
but less expressive. KBDS supports decision-making in the con-
ceptual design stage and facilitates the cooperation between the
members of a project team. Compared to the PDW, KBDS has
a narrower focus in so far as it covers only information about
flowsheet alternatives and design objectives.
Batres and Naka (2000) and Batres, Naka, and Lu (1999)
have developed the prototypical design environment P-DOSS.
The major objective of the P-DOSS system is to enhance inter-
operability between different application tools. Within P-DOSS,
information are described through the ontology MDF (Batres,
Aoyama, & Naka, 2001; Batres & Naka, 2000), which is repre-
sented in the Knowledge Interchange Format, KIF (KSL, 2006).
Comparable to OntoCAPE (cf. Section 3.2), the MDF ontology
describes products and processes in the chemical engineering
domain, however with the focus on the later design stages (pri-
marily detail engineering and operations planning).
Kitamura and Mizoguchi (2003) describe a design envi-
ronment called Functional Way Server which is based on the
prototypical ontology editor Hozo (Kozaki, Kitamura, Ikeda,
& Mizoguchi, 2000). In the conceptual design stage, the user
needs to specify the desired function of the engineering artifact
to be designed; the system then suggests alternative “functional
ways” (e.g., different physical principles) how to achieve the
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
artifact’s desired function. It also determines the manufacturing
steps that are necessary for the realization of each functional way.
The Functional Way Server relies on a knowledge base consist-
ing of two major ontologies: the Functional Ontology, which
provides a comprehensive representation of generic design
knowledge, forms the core of the knowledge base. For the sup-
port of conceptual process engineering, the Functional Ontology
is extended by a domain-specific Plant Ontology (Mizoguchi,
2001; Mizoguchi, Kozaki, Sano, & Kitamura, 2000). The knowl-
edge base of the Functional Way Server must be developed a
priori; unlike the PDW, there are no mechanisms to record and
incorporate experience knowledge during project execution.
The Process Information Repository developed by Zhao,
Hailemariam, et al. (2006), Zhao, Jain, et al. (2006), Zhao,
Joglekar, Jain, Venkatasubramanian, and Reklaitis (2005), and
Venkatasubramanian et al. (2006) aims at the systematic reuse
of knowledge in the pharmaceutical industries. Like the PDW,
the repository stores product knowledge (meta information
describing the contents of documents and databases) as well as
process knowledge (deterministic guidelines) in form of ontolo-
gies. However, the scope of representable (and thus retrievable)
knowledge is limited, as the ontologies of the repository are
specialized on describing particular aspects of pharmaceutical
products and processes, and are consequently not as generic and
broadly applicable as those of the PDW.
Moreover, the system does allow to perform inference and
search operations directly on the repository, but requires load-
ing all data into memory first. This is not a practicable option
due to scalability and performance problems (cf. discussion in
Section 7). A further shortcoming is that the crucial point of
automated knowledge capture (cf. discussion in Section 5) is not
addressed.
7. Discussion and outlook
The Process Data Warehouse has been developed as an
ontology-based repository for the support of design processes.
Its key features are: (1) flexible data structures and work process
models for the support of creative and dynamic work processes,
(2) improved navigation and retrieval mechanisms based on
the use of Semantic Web technologies (e.g., semantic search),
(3) integrated representation of resources, content descriptions,
and organizational context to enable experience reuse, and (4)
functionality for (semi-)automatic capture of experience knowl-
edge during the execution of design projects. These features
are achieved by means of a specific architecture: a central
Core Ontology which is flexibly refined by extension ontol-
ogy modules. The application of the PDW has been illustrated
by several use cases, including a major application scenario
about the conceptual design of a polyamide-6 production facil-
ity. In the following, some of the shortfalls of our approach are
described, together with possible counter-measures and some
planned extensions.
A major problem of current ontology-based frameworks is
the trade-off between implementation efficiency and descriptive
logical power. Most existing ontology frameworks need to load
the entire information into memory to work with it. As a result,
339
these frameworks can handle only a relatively small amount of
instance data. Thus, to develop a system usable for real-world
application, it is necessary to use a back-end for database storage
that is directly able to interpret at least some inference rules and
semantic queries. The KAON system which the PDW uses has
been realized this way.
On the other hand, the full expressive power of ontology
and description-logic (DL) based languages (Baader, Horrocks,
& Sattler, 2004, chap. 1) would offer capabilities not avail-
able in the current PDW. While the PDW is only able to infer
supertype and subtype relations, a full-fledged description logic
system would be able to infer certain characteristics of classes
and instances, based on semantic constraints and rules. This
goes beyond the capabilities of semantic search currently imple-
mented in the PDW, as can be seen from the following example
which extends the use case described in Section 4.2.1: if an inex-
perienced user enters information about a reactor, annotating it
as an instance of the generic class Vessel only, the current PDW
will not return this instance when queried for a Reactor. In con-
trast to that, a DL system might contain an inference rule “A
Reactor is a Vessel in which a ChemicalReaction takes place”.
The system could then conclude that the above Vessel is in fact a
Reactor, and return it when queried for such. Thus, the recall of
the search (i.e., the proportion of relevant information retrieved
out of all the relevant information in the collection) may be
significantly enhanced.
As we did not find a way to combine scalability and full
logic expressiveness, we decided to focus on the former for the
development of the PDW. This decision will have to be reviewed
once efficient and scalable DL systems have become available.
In addition to this technical aspect, we are planning to extend
the models and application cases of the PDW. Experience knowl-
edge from the full plant life cycle is going to be examined, from
the design phase through plant operation (production), modifi-
cations and redesign or reengineering. As a first step, we have
considered to extend the knowledge acquisition to the produc-
tion stage. One potential benefit of this could be to incorporate
selected data from production processes into the PDW and relat-
ing it to the simulation models used to design the respective
production facility. This allows to compare the simulation mod-
els with the actual plant performance; thus, when reusing the
models, the model quality can be easily determined. Expe-
riences in this direction have been gained by recording and
supporting rubber extrusion processes (Raddatz, Schlüter, &
Brandt, 2006), and by feeding these traces back into process
design.
To remedy the difficulties in documenting design and deci-
sion rationale mentioned in Section 5.4, an extended version of
WOMS is under development, which supports the integrated
documentation of work processes and decisions. In particu-
lar, the tool will enable the reuse of fragments of generalized
decision models (decision templates) as part of the decision
documentation in concrete projects. This approach will not only
reduce the effort to create decision documentation but also help
the designer to consider the relevant aspects in a particular case,
such as potential alternatives and their pros and cons under
certain constraints.
340 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Acknowledgements
Most of the research described in this article has been per-
formed in the context of the Collaborative Research Center on
Cooperative Computer-Aided Process Engineering (CRC/SFB
476 IMPROVE, Marquardt & Nagl, 2004), funded by the
German Research Foundation (DFG). The authors would like
to thank their student workers, especially M.A. Amin, M.
Comanns, M.T. Ikram, J. Kopecky, A. Passen, and J. Renner,
who implemented major parts of the software systems described.
References
Abecker, A., Bernardi, A., Hinkelmann, K., Kühn, O., & Sintek, M. (1998).
Toward a technology for organizational memories. IEEE Intelligent Systems,
13(3), 40–48.
Agrawal, A. K., Devika, K., & Manabe, T. (2001). Simulation of hydrolytic
polymerization of nylon-6 in industrial reactors: Part I Mono-acid-stabilized
systems in VK tube reactors. Industrial & Engineering Chemistry Research,
40(12), 2563–2572.
Amin, M. A., & Morbach, J. (2007). XML to OWL converter. Technical report
(LPT-2007-02), Lehrstuhl für Prozesstechnik. RWTH Aachen University.
Annotation Portal. (2006). OntoMat Homepage. Available at http://annotation.
semanticweb.org/ontomat/index.html. Accessed October 2006.
AspenTech. (2006). Homepage. Available at http://www.aspentech.com/.
Accessed October 2006.
AVEVA. (2006a). VANTAGE Plant Engineering. Available at http://www.aveva.
com/products/plant/vpe.html. Accessed October 2006.
AVEVA. (2006b). VANTAGE Enterprise Net. Available at http://www.
aveva.com/products/plant/vnet.html. Accessed October 2006.
Awad, E. M., & Ghaziri, H. M. (2003). Knowledge management. Prentice Hall.
Baader, F., Horrocks, I., & Sattler, U. (2004). Description logics. In S. Staab & R.
Studer (Eds.), Handbook on ontologies. Berlin, Heidelberg: Springer-Verlag.
Banares-Alcantara, R., & King, J. M. P. (1996). Design support systems for
process engineering—III. Design rationale as a requirement for effective
support. Computers and Chemical Engineering, 21, 263–276.
Banares-Alcantara, R., & Lababidi, H. M. S. (1995). Design support systems
for process engineering—II. KBDS: An experimental prototype. Computers
and Chemical Engineering, 19, 279–301.
Batres, R., Aoyama, A., & Naka, Y. (2001). A life-cycle approach for model reuse
and exchange. In R. Gani & S. B. Jørgensen (Eds.), European symposium
on computer aided process engineering, Vol. 11 (pp. 87–92). Elsevier.
Batres, R., & Naka, Y. (2000). Process plant ontologies based on a multi-
dimensional framework. In M. F. Malone, J. A. Trainham, & B. Carnahan
(Eds.), Proceedings of the fifth international conference on foundations of
computer-aided process design, AIChE symposium series no. 323, Vol. 96
(pp. 433–437).
Batres, R., Naka, Y., & Lu, M. L. (1999). A multidimensional design framework
and its implementation in an engineering design environment. Concurrent
Engineering: Research and Applications, 7(1), 43–54.
Bayer, B. (2003). Conceptual information modeling for computer aided sup-
port of chemical process design. Ph.D. thesis. Lehrstuhl fur Prozesstechnik,
RWTH Aachen University. Published in: Fortschritt-Berichte VDI: Reihe 3,
No. 787. Düsseldorf: VDI-Verlag.
Bayer, B., Eggersmann, M., Gani, R., & Schneider, R. (2002). Case studies in
design and analysis. In B. Braunschweig & R. Gani (Eds.), Software archi-
tectures and tools for computer aided process engineering (pp. 591–634).
Elsevier Science.
Bayer, B., & Marquardt, W. (2003). A comparison of data models in chemi-
cal engineering. Concurrent Engineering Research and Applications, 11(2),
129–138.
Bayer, B., Marquardt, W., Weidenhaupt, K., & Jarke, M. (2001). A flowsheet
centered architecture for conceptual design. In R. Gani & S. B. Jørgensen
(Eds.), European symposium on computer aided process engineering, Vol.
11 (pp. 345–350). Elsevier.
Bayer Technology Services. (2006). Engineering software—PEDW. Available
at http://www.bayertechnology.com/eng/products/43 1488.php. Accessed
October 2006.
Bechhofer, S., Harmelen, F., van Hendler, J., Horrocks, I., McGuiness, D.,
Patel-Schneider, P., et al. (2004). OWL Web Ontology Language Reference.
Available at http://www.w3.org/TR/owl-ref/. Accessed September 2006.
Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The Semantic Web—A new
form of Web content that is meaningful to computers will unleash a revolution
of new possibilities. Scientific American, 17.
Bilgic, T., & Rock, D. (1997, September). Product data management systems:
State-of-the-art and the future. In Proceedings of the 1997 ASME design
engineering technical conferences
Brandt, S. C., Fritzen, O., Jarke, M., & List, T. (2007). Goal-oriented information
flow management in design processes. In M. Nagl & W. Marquardt (Eds.),
Collaborative and distributed chemical engineering design processes: From
understanding to substantial support. Berlin, Heidelberg: Springer-Verlag.
Brandt, S. C., Morbach, J., Miatidis, M., Theißen, M., Jarke, M., & Marquardt,
W. (2006). Ontology-based information management in design processes.
In W. Marquardt & C. Pantelides (Eds.), 16th European symposium on com-
puter aided process engineering and 9th international symposium on process
systems engineering (pp. 2021–2026). Elsevier.
Brandt, S. C., Schlüter, M., & Jarke, M. (2006b). A process data warehouse for
tracing and reuse of engineering design processes. International Journal of
Intelligent Information Technologies, 2(4), 18–26.
Brandt, S. C., Schlüter, M., & Jarke, M. (2006c). Process data warehouse models
for cooperative engineering processes. In Proceedings 9th IFAC symposium
on automated systems based on human skill and knowledge.
Braunschweig, B., Fraga, E., Guessoum, Z., Marquardt, W., Nadjemi, O., Paen,
D., et al. (2004). CAPE web services: The COGents way. In A. Barbrosa-
Povoa & H. Matos (Eds.), European symposium on computer aided process
engineering, Vol. 14 (pp. 1021–1026). Elsevier.
Carlile, P. R., & Rebentisch, E. S. (2003). Into the black box: The knowledge
transformation cycle. Management Science, 49(9), 1180–1195.
Dassault Systemes. (2006). PLM Solutions. Available at http://www.3ds.com/
products-solutions/plm-solutions/. Accessed October 2006.
Dougherty, D. (1992). Interpretive barriers to successful product innovation in
large firms. Organization Science, 3, 179–202.
Eggersmann, M., Hackenberg, J., Marquardt, W., & Cameron, I. (2002). Applica-
tions of modelling: A case study from process design. In B. Braunschweig &
R. Gani (Eds.), Software architectures and tools for computer aided process
engineering (pp. 335–372). Elsevier Science.
Eggersmann, M., Hai, R., Kausch, B., Luczak, H., Marquardt, W., Schlick, C.,
et al. (2007). Work process models. In M. Nagl & W. Marquardt (Eds.),
Collaborative and distributed chemical engineering design processes: From
understanding to substantial support. Berlin, Heidelberg: Springer-Verlag.
EMC2 . (2006). Documentum. Available at http://software.emc.com/products/
product family/documentum family.htm. Accessed September 2006.
Furnas, G. W., Landauer, T. K., Gomez, L. M., & Dumais, S. T. (1987). The
vocabulary problem in human-system communication. Communications of
the ACM (CACM), 30, 964–971.
Furner, J., Ellis, D., & Willett, P. (1999). Inter-linker consistency in the man-
ual construction of hypertext documents. ACM Computing Survey (CSUR),
31(4). Article No. 18
Gao, J. X., Aziz, F. L., Maropoulos, P. G., & Cheung, W. M. (2003). Appli-
cation of product data management technologies for enterprise integration.
International Journal of Computer Integrated Manufacturing, 16(7–8), 491–
500.
Grudin, J. (1996). Evaluating opportunities for design capture. In T. P. Moran &
J. M. Carroll (Eds.), Design rationale: Concepts, techniques, and use (pp.
453–470). Mehwah, New Jersey: Lawrence Erlbaum Associates, Inc.
Hai, R., Theißen, M., Schneider, R., Morbach, W., & Marquardt, W. (2007).
Scenario-based analysis of industrial work processes. In M. Nagl & W. Mar-
quardt (Eds.), Collaborative and distributed chemical engineering design
processes: From understanding to substantial support. Berlin, Heidelberg:
Springer-Verlag.
Hinds, P. J. (1999). The curse of expertise: The effects of expertise and debias-
ing methods on prediction of novice performance. Journal of Experimental
Psychology: Applied, 5, 205–221.
 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Innotec. (2006). Homepage. Available at http://www.innotec.de/index.php?id=
14&L=l. Accessed September 2006.
Intergraph. (2006a). SmartPlant P&ID. Available at http://www.
intergraph.com/smartplant/pid/. Accessed October 2006.
Intergraph. (2006b). SmartPlant Foundation. Available at http://www.
intergraph.com/smartplant/foundation/. Accessed October 2006.
Jarke, M., Lenzerini, M., Vassiliou, Y., & Vassiliadis, P. (2003). Fundamentals
of data warehouses (2nd ed.). Springer-Verlag.
Jarke, M., List, T., & Köller, J. (2000). The challenge of process data ware-
housing. In Proceedings of the 26th international conference on very large
databases—VLDB
Jarke, M., List, T., & Weidenhaupt, K. (1999). A process-integrated conceptual
environment for chemical engineering. In Proceedings of the 18th interna-
tional conference on conceptual modeling—ER.
Jarke, M., & Marquardt, W. (1996). Design and evaluation of computer-aided
process modeling tools. In J. F. Davis, G. Stephanopoulos, & V. Venkata-
subramanian (Eds.), Intelligent systems in process engineering, AIChE
symposium series no. 312, Vol. 92 (pp. 97–109).
Jarke, M., Miatidis, M., Schlüter, M., & Brandt, S. C. (2006). Process inte-
gration and media-assisted traceability in cross-organisational engineering.
International Journal of Business Process Integration and Management,
1(2), 65–75.
Kim, Y., Kang, S., Lee, S., & Yoo, S. (2001). A distributed, open, intelligent prod-
uct data management system. International Journal of Computer Integrated
Manufacturing, 14, 224–235.
Kitamura, Y., & Mizoguchi, R. (2003). Ontology-based description of functional
design knowledge and its use in a functional way server. Expert Systems with
Applications, 24(2), 153–166.
Kopecky, J. (2006). Model-based integration of operating and ERP systems data.
Master’s thesis. RWTH Aachen University.
Kopena, J., & Regli, W. C. (2003). Functional modeling of engineering designs
for the semantic web. IEEE Data Engineering Bulletin, 26(4), 55–61.
Kozaki, K., Kitamura, Y., Ikeda, M., & Mizoguchi, R. (2000). Development
of an environment for building ontologies which is based on a fun-
damental consideration of “relationship” and “role”. In Proceedings of
the sixth pacific knowledge acquisition workshop (PKAW2000) (pp. 205–
221).
KSL, Stanford University. (2006). Knowledge Interchange Format (KIF).
http://www.ksl.stanford.edu/knowledge-sharing/kif/.
Kunz, W., & Rittel, H. W. J. (1970). Issues as elements of information sys-
tems. Working paper no. 131. Institute of Urban and Regional Development,
Berkeley. Available at http://www-iurd.ced.berkeley.edu/pub/WP-131.pdf.
Accessed October 2006.
Lee, J. (1997). Design rationale systems: Understanding the issues. IEEE Expert,
12(3), 78–85.
Lee, J., & Lai, K.-Y. (1996). What’s in design rationale? In T. P. Moran & J. M.
Carroll (Eds.), Design rationale: Concepts, techniques, and use (pp. 21–51).
Mehwah, New Jersey: Lawrence Erlbaum Associates, Inc.
Leonard, L. E. (1977). Inter-indexer consistency studies, 1954–1975: A review
of the literature and summary of study results. Occasional papers series,
no. 131. University of Illinois Graduate School of Library Science, Urbana-
Champaign, IL.
Manola, F., & Miller, E. (Eds.) (2004). RDF Primer. Online available at
http://www.w3.org/TR/rdf-syntax-grammar/. Accessed January 2007.
Maropoulos, P. G. (2003). Digital enterprise technology—Defining perspec-
tives and research priorities. International Journal of Computer Integrated
Manufacturing, 16(7/8), 467–478.
Marquardt, W., & Nagl, M. (2004). Workflow and information centered support
of design processes—The IMPROVE perspective. Computers and Chemical
Engineering, 29, 65–82.
McMahon, C., Lowe, A., & Culley, S. J. (2004). Knowledge management in
engineering design, personalisation and codification. Journal of Engineering
Design, 15(4), 307–325.
Mesihovic, S., Malmqvist, J., & Pikosz, P. (2004). Product data management
system-based support for engineering project management. Journal of Engi-
neering Design, 15(4), 389–403.
Miatidis, M., Jarke, M., & Weidenhaupt, K. (2007). Using developers’ experi-
ence in cooperative design processes. In M. Nagl & W. Marquardt (Eds.),
341
Collaborative and distributed chemical engineering design processes: From
understanding to substantial support. Berlin, Heidelberg: Springer-Verlag.
Mizoguchi, R. (2001). Ontological engineering: Foundation of the next gener-
ation knowledge processing. In Proceedings of web intelligence: Research
and development, Lecture notes in computer science, Vol. 2198 (pp. 44–57).
Springer.
Mizoguchi, R., Kozaki, K., Sano, T., & Kitamura, Y. (2000). Construction and
deployment of a plant ontology. In R. Dieng & O. Corby (Eds.), Proceedings
of the 12th European workshop on knowledge acquisition, modeling and
management, Lecture notes in computer science, Vol. 1937 (pp. 113–128).
Springer.
Morbach, J., Hai, R., Bayer, B., & Marquardt, M. (2007). Document models.
In M. Nagl & W. Marquardt (Eds.), Collaborative and distributed chemical
engineering design processes: From understanding to substantial support.
Berlin, Heidelberg: Springer-Verlag.
Morbach, J., Yang, A., & Marquardt, W. (2007). OntoCAPE—A large-scale
ontology for chemical process engineering. Engineering Applications of
Artificial Intelligence, 20(2), 147–161.
Nagl, M., Westfechtel, B., & Schneider, R. (2003). Tool support for the manage-
ment of design processes in chemical engineering. Computers and Chemical
Engineering, 27(2), 175–197.
Oberle, D., Volz, R., Motik, B., & Staab, S. (2004). An extensible ontology soft-
ware environment. In S. Staab & R. Studer (Eds.), Handbook on ontologies
(pp. 311–333). Springer.
OMG. (2004). Unified Modeling Language (UML), version 2.0. Available at
http://www.uml.org/. Accessed October 2006.
Pohl, K., Weidenhaupt, K., Dömges, R., Haumer, P., Jarke, M., & Klamma, R.
(1999). PRIME: Towards process-integrated environments. ACM Transac-
tions on Software Engineering and Methodology, 8(4), 343–410.
PostgreSQL. (2006). Homepage. Available at http://www.postgresql.org/.
Accessed October 2006.
PTC. (2006a). Windchill. Available at http://www.ptc.com/appserver/
mkt/products/home.jsp?k=37. Accessed October 2006.
PTC. (2006b). CADDS 5i Optegra. Available at http://www.ptc.com/products/
cadds/optegra.htm. Accessed October 2006.
Raddatz, M., Schlüter, M., & Brandt, S. C. (2006). Identification and reuse
of experience knowledge in continuous production processes. In 9th IFAC
symposium on automated systems based on human skill and knowledge
Ramesh, B., & Jarke, M. (2001). Toward reference models for requirements
traceability. IEEE Transactions on Software Engineering, 27(1), 58–93.
RFC—Request for Comment. (1999). HTTP Extensions for Dis-
tributed Authoring—WEBDAV. IETF RFC 2518. Available at
http://www.ietf.org/rfc/rfc2518.txt. Accessed October 2006.
Rolland, C., Souveyet, C., & Moreno, M. (1995). An approach for defining
ways-of-working. Information Systems, 20(4), 337–359.
Rus, I., & Lindvall, M. (2002). Knowledge management in software engineering.
IEEE Software, 19(3), 26–38.
SAP. (2006). SAP—Business software applications and services (homepage).
Available at http://www.sap.com/. Accessed October 2006.
Schneider, R., & Marquardt, W. (2002). Information technology support in the
chemical process design life cycle. Chemical Engineering Science, 57(10),
1763–1792.
Slide. (2006). The Jakarta Slide project. Available at http://jakarta.
apache.org/slide/. Accessed October 2006.
Sowa, J. (Ed.). (1991). Principles of semantic networks: Explorations in
the representation of knowledge. San Mateo, CA: Morgan Kaufmann
Publishers.
Stanford Medical Informatics. (2006). The Protégé ontology editor and knowl-
edge acquisition system. Available at http://protege.stanford.edu/. Accessed
October 2006.
Studer, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineering:
Principles and methods. IEEE Transactions on Data and Knowledge Engi-
neering, 25(1–2), 161–197.
Sun. (2006). Java 2 Enterprise Edition Homepage. Available at
http://java.sun.com/javaee/. Accessed October 2006.
Szykman, S., Sriram, R. D., Bochenek, C., Racz, J. W., & Senfaute, J. (2000).
Design repositories: Engineering design’s new knowledge base. IEEE Intel-
ligent Systems, 15(3), 48–55.
342 S.C. Brandt et al. / Computers and Chemical Engineering 32 (2008) 320–342
Szykman, S., Sriram, R. D., & Regli, W. C. (2001). The role of knowledge in next-
generation product development systems. ASME Journal of Computation
and Information Science in Engineering, 1(1), 3–11.
Teknowledge. (2006). Semantic word. Available at http://mr.teknowledge.
com/daml/SemanticWord/SemanticWord.htm. Accessed October
2006.
Theißen, M., & Marquardt, W. (2007). Decision models. In M. Nagl & W. Mar-
quardt (Eds.), Collaborative and distributed chemical engineering design
processes: From understanding to substantial support. Berlin, Heidelberg:
Springer-Verlag.
Thomson, J., Adams, D., Cowley, P. J., & Walker, K. (2003). Metadata’s
role in a scientific archive. IEEE Computer Magazine, 36(12), 27–
34.
UGS. (2006). Teamcenter 2005. Available at http://www.ugs.com/products/
teamcenter/. Accessed October 2006.
van Gigch, J. P. (1991). System design modeling and metamodeling. New York:
Springer.
Venkatasubramanian, V., Zhao, C., Joglekar, G., Jain, A., Hailemariam, L.,
Suresh, P., et al. (2006). Ontological informatics infrastructure for pharma-
ceutical product development and manufacturing. Computers & Chemical
Engineering, 30, 1482–1496.
von Wedel, L. (2002). CapeML—A model exchange language for chem-
ical process modeling. Technical report (LPT-2002-16), Lehrstuhl für
Prozesstechnik. RWTH Aachen University.
Weidenhaupt, K. (2001). Anpassbarkeit von Software-Werkzeugen in prozess-
integrierten Entwicklungsumgebungen. Ph.D. thesis. Informatik V, RWTH
Aachen University.
Westerberg, A. W., Subrahmanian, E., Reich, Y., Konda, S., & the n-dim group.
(1997). Designing the process design process. Computers & Chemical Engi-
neering, 21(S), S1–S9.
Windream GmbH. (2006). Managing documents by Windream. Available at
http://www.windream.com/. Accessed October 2006.
W3C-World Wide Web Consortium. (1999). XSL Transformations (XSLT), ver-
sion 1.0, W3C Recommendation. Available at http://www.w3.org/TR/xslt.
Accessed September 2006.
W3C-World Wide Web Consortium. (2004). RDF Vocabulary Descrip-
tion Language 1.0: RDF Schema. W3C Recommendation. Available at
http://www.w3.org/TR/rdf-schema/. Accessed October 2006.
W3C-World Wide Web Consortium. (2006). Extensible Markup Lan-
guage (XML) 1.0 (Forth Edition), W3C Recommendation. Available at
http://www.w3.org/TR/xml/. Accessed October 2006.
Yang, A., & Marquardt, W. (2004). An ontology-based approach to conceptual
process modelling. In A. Barbarosa-Póvoa & H. Matos (Eds.), European
symposium on computer aided process engineering, Vol. 14 (pp. 1159–1164).
Elsevier.
Zeng, A., Pan, D., Zheng, Q. L., & Peng, H. (2006). Knowledge acquisition
based on rough set theory and principal component analysis. IEEE Intelligent
Systems, 21(2), 78–84.
Zhao, C., Hailemariam, L., Jain, A., Joglekar, G., Venkatasubramanian, V.,
Morris, K., et al. (2006). Information modeling for pharmaceutical prod-
uct development. In W. Marquardt & C. Pantelides (Eds.), 16th European
symposium on computer aided process engineering and 9th international
symposium on process systems engineering (pp. 2147–2152). Elsevier.
Zhao, C., Jain, A., Hailemariam, L., Joglekar, G., Venkatasubramanian, V.,
Morris, K., et al. (2006). A unified approach for knowledge modeling in phar-
maceutical product development. In W. Marquardt & C. Pantelides (Eds.),
16th European symposium on computer aided process engineering and 9th
international symposium on process systems engineering (pp. 1929–1935).
Elsevier.
Zhao, C., Joglekar, G., Jain, A., Venkatasubramanian, V., & Reklaitis, G. V.
(2005). Pharmaceutical informatics: A novel paradigm for pharmaceutical
product development and manufacture. In L. Puigjaner & A. Espuña (Eds.),
European symposium on computer aided process engineering, Vol. 15 (pp.
1561–1566). Elsevier.