Computers and Chemical Engineering xxx (2006) xxx–xxx

Ontological informatics infrastructure for pharmaceutical productdevelopment and manufacturing

Venkat Venkatasubramanian ∗, Chunhua Zhao 1, Girish Joglekar, Ankur Jain, Leaelaf Hailemariam,Pradeep Suresh, Pavankumar Akkisetty, Ken Morris, G.V. Reklaitis

Laboratory for Intelligent Process Systems, School of Chemical Engineering, Purdue University, West Lafayette, IN 47907, USA

Received 7 March 2006; received in revised form 23 May 2006; accepted 24 May 2006

Abstract

Informatics infrastructure plays a crucial role in supporting different decision making activities related to pharmaceutical product development,pilot plant and commercial scale manufacturing by streamlining information gathering, data integration, model development and managing allthese for easy and timely access and reuse. The foundation of such an infrastructure is the explicitly and formally modeled information. Thisflspp©

K

1

ovtLtssipdcra

S

0d

oundation enables knowledge in different forms, and best manufacturing practices, to be modeled and captured into tools to support the productifecycle management. This paper discusses the development of ontologies, Semantic Web infrastructure and Web related technologies that makeuch an infrastructure development possible. While many of the issues addressed in this paper are applicable to a wide spectrum of molecular-basedroducts, we focus our work on the development of pharmaceutical informatics to support Active Pharmaceutical Ingredient (API) as well as drugroduct development as case studies to illustrate the various aspects of this infrastructure.

2006 Elsevier Ltd. All rights reserved.

eywords: Pharmaceutical informatics; Product design; Process development; Ontology; Semantic Web

. Introduction

The evolution of commercial scale product and process devel-pment typically goes through the following stages after theiability of a newly discovered molecule is established: labora-ory scale, pilot plant scale and commercial scale manufacturing.aboratory scale experiments are used to determine various syn-

hesis routes and characterize key steps in each route. Pilot planttudies provide detailed understanding of processing steps of theelected route and provide data needed for scale-up, culminat-ng in a commercial scale process. A commercial scale processrovides valuable manufacturing related information useful forebottlenecking and productivity improvement. These three pro-essing stages, and the major tasks contained therein, are closelyelated to each other through various information feedback loopss shown in Fig. 1.

∗ Corresponding author. Tel.: +1 765 494 0734; fax: +1 765 494 0805.E-mail address: venkat@ecn.purdue.edu (V. Venkatasubramanian).

1 Present address: Bayer Technology and Engineering (Shanghai) Co. Ltd.,hanghai 201507, China.

As Fig. 1 suggests, development of a process for an activepharmaceutical ingredient (API) and its dosage form(s) evolvesin stages, requiring participation from several groups and usesa wide range of application tools. Recent progress in the useof new process analytical technologies (PAT) (FDA, 2005) hasled to a better monitoring and gathering of data of the physicaland chemical phenomena. Techniques such as mass spectrome-try for gathering reaction kinetics data, Lasentec Focused BeamReflectance Measurement (FBRM) instrument (Sistare, Berry,& Mojica, 2005) for crystal growth, and so on have made thispossible. For laboratory information integration, solutions likeLIMS (Paszko & Pugsley, 2000) and e-Lab Notebook (Zall,2001) have been developed. However, a systematic way to con-vert this raw data gathered from PAT to information and firstprinciples knowledge that can be used for real-time decisionmaking is lacking.

During process development, a staggering amount of infor-mation of different types, ranging from raw data to lab reportsto sophisticated math models, is shared and revised by com-putational tools in each stage. Subsequent to process devel-opment, technical specifications and reports must be devel-

098-1354/$ – see front matter © 2006 Elsevier Ltd. All rights reserved.oi:10.1016/j.compchemeng.2006.05.036

CACE-3283; No. of Pages 15

2 V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx

Fig. 1. Information flows in pharmaceutical product and process development.

oped to satisfy regulatory requirements. However, due to theincompatibility among such diverse types of data, informationand knowledge, islands of automation exist, but a comprehen-sive, integrated decision support environment does not exist.With the onset of information and knowledge explosion, itis clear that we need intelligent software systems to effec-tively manage and access information for efficient decisionmaking.

In the chemical process development domain, severalattempts have been made towards process information inte-gration, such as KBDS (Banares-Alcantara & Lababidi, 1995),MDOOM (Burkett & Yang, 1995; McGreavy, Wang, Lu, &Naka, 1995) and PROART/CE (Jarke & Marquardt, 1996).Schneider and Marquardt (2002) presented a conceptual life-cycle integration model based on the mapping of workflowmodels into information models describing chemical processesand entities. These are important first attempts recognizing theneed for an informatics framework in modeling complex oper-ations. However, these solutions are limited in their descrip-tion of the relations between the different information enti-ties and in their application to the pharmaceutical domain.Additional limitations include lack of formalization for knowl-edge modeling and the relation to data. While the generalconcepts of information modeling are common across theseprior attempts and ours, the challenges are in the detailsposed by the particular application domain. From that per-siptdptipd

rptocfUtaBkc

2. Information modeling

Over the past 20 years, several tools have been developed tosupport chemical product/process development and manufactur-ing. As an example, we examine three tools which are used inpilot plant operation: BatchPlus (AspenTech, 2005) for recipedevelopment and mass/energy balance calculations, Batches(Batch Process Technologies, 2005) for dynamic simulation ofbatch processes, and PHASuite (Zhao, 2002) for process safetyanalysis. The information required for these three tools is verysimilar, namely information on materials, equipment and recipe.Furthermore, exchange of information between these tools iscrucial. The mass and energy balance information generated bysimulation packages is required for safety analysis packages.Each tool, however, has its own syntax (format of the informa-tion) and semantics (meaning of the information) to describe it,thus making it hard to communicate with each another. Hence,the form in which the information is required and created bythese tools is application centric. To store information BatchPlususes a relational database, PHASuite uses a database and objectbinary serialization, while Batches uses plain text files. Not onlydo these tools use similar information, they also generate similarinformation, for example, the mass and energy balances, cycletime statistics and so on.

In the application-centric view, the scope and representationof a process are influenced by the tool being used. As a result,cerptt(

r

1

2

3

rvsvtifitti

c

pective, this is the first comprehensive informatics frameworkn the pharmaceutical product development domain. In thisaper, we present an overview of our approach to addresshese challenges. In our work, we start from modeling theata/information/knowledge as well as their flows in the entirerocess development. An informatics infrastructure is developedo support decision making spanning the entire process, includ-ng drug product formulation design, process simulation androcess safety analysis for API process as well as drug productevelopment.

The rest of this paper is organized as follows: a brief review ofelated work in information modeling is presented and the pro-osed approach is discussed. The foundation of this approach ishe formal modeling of the domain information. The concept ofntology is introduced; issues of ontological language are dis-ussed. Ontology development is then discussed using ontologyor recipe information and material properties as case studies.ses of the ontology for information management and informa-

ion sharing are discussed. The implication of service-orientedpplication and its impact on tools development is discussed.ased on the formal modeling of information, various forms ofnowledge, such as guidelines and mathematical equations, areaptured and modeled to support the decision making.

omplete representation of a process is often not available. Forxample, a simulation tool does not need to have material safetyelated data for its execution, but this information is crucial torocess safety analysis. The biggest challenge is to overcomehe syntactic and semantic differences of information so thathe information can be shared and reused among different toolsTopQuadrant, 2003).

To share information between tools, a three-step process isequired (Zhao, Bhushan, & Venkatasubramanian, 2003):

. Access and extract information, based on the understandingof syntax and semantics of the information source.

. Translate the acquired information into semantics understoodby the information destination.

. Store the information based on the syntax defined in the des-tination.

Clearly, this scheme to share information is error prone,equires expertise in the source and destination tools, and isery time consuming. Also, with the different versions of theame information, managing changes to information becomesery challenging. In this environment, developing new applica-ions also becomes difficult since a new syntax for the processnformation must be created. The lack of a coherent and uni-ed process view results in islands of information. This limits

he information sharing as well as function sharing among tools,hus limiting the use of these tools in decision support and learn-ng.

The key to resolving this problem is to identify the variousategories of information used for defining a process and used

V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx 3

Fig. 2. Similarities of overall structure and functional components in different tools.

in decision support. Subsequently, suitable mechanisms must bedeveloped for managing the information and delivering the rightinformation for the intended use.

As illustrated in Fig. 2, various categories of tools have sim-ilar overall structure and functional components. On top of theinformation layer is typically the knowledge layer, which con-sists of quantitative models for unit operations in simulationpackages, or qualitative cause–effect models in safety analysispackages. The engine layer contains the solver in simulationpackages, or reasoning engine for safety analysis package. Thepresentation layer provides an interface to access and provideinformation. Failure to recognize the structural similarities hasprecluded the development of an infrastructure for informationsharing, and has resulted in software designs where the knowl-edge is ‘trapped’ in each tool, making it very difficult to create,customize, share and manage the knowledge. To address thesechallenges, an information-centric approach has been proposedfor process development. In this new paradigm, the underlyinginformation is modeled explicitly, independent of tools that usethe information. Instead of encoding information in objects in aparticular programming language or tool specific constructs, theinformation is explicitly described. Knowledge is also explicitlymodeled.

2.1. Review of related work

aBtdMootctMgdelti

C3 formalism (Killich et al., 1999), whose major elements areroles, activities, control flow, input and output info, tools andsynchronous communication. The product (data) model usedthe Conceptual Lifecycle Process Model (CLiP) (Schneiderand Marquardt, 2002). Activities were organized by role andtemporal order in C3 and mapped to CLiP, which has beendeveloped to serve as ontology for chemical processes and theassociated design processes and characterizes input and out-put information more precisely. Integration of product data wasimplemented through Description Logics, which capture theentity-relationships as well as object-oriented data models. Forintegration of tools, the authors suggested either product datacentered integration (where various tools are interfaced withconverters using a global schema) or control centered integra-tion (data exchange through standard formats).

As mentioned above, some of the generic informatics con-cepts we use have been used by these earlier works, but these sys-tems are not directly applicable to the pharmaceutical domain.For instance, the range of material properties required in phar-maceutical domain is much wider, such as solid flow proper-ties, mechanical properties of powders, crystalline properties ofsolids and so on. Additionally, the need to include access toexperimental information is crucial in this domain. Since mostof the processing is done in batch mode and according to spe-cific recipes, the recipe information modeling is also a necessarycomponent of the overall infrastructure.

2

adcnbeatnctreb

Perhaps the first attempt in chemical engineering towardsformal informatics framework for process design was by

anares-Alcantara and Lababidi (1995) who proposed KBDSo integrate the process design space with an object-orientedescription of processing units and a design history archive.cGreavy et al. (1995) developed a multi-dimensional object-

riented conceptual model (MDOOM) for software tool devel-pment consisting of models of physical descriptors like plantopology and process descriptors like pressure drop communi-ating through a common information exchange standard calledhe STandard for Exchange of Product model (STEP). Jarke and

arquardt (1996) presented PROART/CE, which is a tool inte-ration environment based on a definition of representation ofata and specification of the physical structure of the units mod-led. Schneider and Marquardt (2002) presented a conceptualifecycle model that covers the workflow with its activities andheir order in a (work) process model and the results producedn a product (data) model. The (work) process model used the

.2. Ontology for information modeling

To describe the information explicitly, the syntax as wells semantics for the information must be defined. The explicitescription of domain concepts and relationships between theseoncepts is known as ontology (Gruber, 1993). A detailed defi-ition given by Studer, Benjamins, and Fensel (1998) which isased on Gruber’s (1993) definition is “An ontology is a formal,xplicit specification of a shared conceptualization. Conceptu-lization refers to an abstract model of some phenomenon inhe world by having identified the relevant concepts of that phe-omenon. Explicit means that the type of concepts used, and theonstraints on their use are explicitly defined. Formal refers tohe fact that the ontology should be machine-readable. Sharedeflects the notion that an ontology captures consensual knowl-dge, that is, it is not private of some individual, but acceptedy a group.”

4 V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx

Ontology has some similarities and at the same time, manydifferences compared to other information modeling method-ologies. Compared to databases, both of them are used byapplications at run-time for queries and reasoning, however, rela-tionships are defined as first-class constructs only in ontologies.Similar to object models in object-oriented programming lan-guages (such as C++, C# or Java), ontologies describe classesand attributes, on the other hand, ontologies are set-based anddynamic. Various methodologies have been proposed to modelontologies, including frames and first order logic (Gruber, 1993)and Description Logic (DL) (Branchman & Schmolze, 1985).Many different languages have been developed to encode theontologies, including Ontoligua (Farquhar, Fikes, & Rice, 1997),LOOM (MacGregor, 1991), CycL (Lenat & Guha, 1990) andOKBC (Chaudhri, Farquhar, Fikes, Karp, & Rice, 1998).

Recent developments in the field of ontology have creatednew software capabilities that facilitate the implementation ofthe proposed informatics infrastructure. The shared understand-ing is the basis for a formal encoding of the important entities,attributes, processes and their inter-relationships in the domainof interest. Ontologies can be used to describe the semantics ofthe information sources and make the contents explicit, therebyenabling integration of existing information repositories, eitherby standardizing terminology among the different users of therepositories, or by providing the semantic foundations for trans-lators. Compared to a database schema which targets physicaldustcd

2

matWbass

fustsvSBop(i

Fig. 3. Stack of Semantic Web Markup Languages.

(AnIML, see http://animl.sourceforge.net/) for analyticalinformation and Chemical Markup Language (CML, seehttp://www.xml-cml.org/) for molecule information.

Even though XML has become a uniform data exchange for-mat between applications, it does not provide any means ofdefining the semantics (meaning) of the information. Further-more, XML is sufficient to describe a tree structure, but not forgeneral information relations which requires a graph structure.We will use a simple example from API recipe to discuss thecapabilities of the three languages. In this example, we definethe concepts of UnitProcedure and Operation and the relationsthat UnitProcedure contains Operations. We also need to definethe Charge as a subclass of Operation. The graph representationof these concepts is illustrated in Fig. 4.

Fig. 5 shows the tree representation of this information model.The relation is indeed defined within the UnitProcedureTypeas UnitOperation contains Operations. Charge is defined as anextension of Operation.

Resource Description Framework (RDF) has been devel-oped based on XML syntax to define the graph structureof the information. The fundamental concepts of RDF areresources, properties and statements. In RDF, every Webresource (can be thought as an object) has a UniversalResource Identifier (URI). Properties are a special kind ofresources to describe relations between resources. Proper-ties are also defined by URIs. Statements assert the prop-etuRchh

ata independence, and an XML Schema which targets doc-ment structure, an ontology targets agreed upon and explicitemantics of information. As a result, while the functionali-ies of this infrastructure can be implemented in a traditionallient–server framework, the main benefits of this ontology-riven architecture are its openness and semantic richness.

.3. Ontological languages: XML, RDF and OWL

In order to model the information explicitly and formally, weust first decide the modeling language to use. As discussed

bove, several ontological languages have been developed inhe Artificial Intelligence (AI) community. The World Wide

eb Consortium (W3C) has proposed several markup languagesased in these languages for Web environment. Three languagesre briefly discussed here: XML, RDF and OWL (see URL). Ashown in Fig. 3, these languages have different levels of semanticupport and expressive powers.

Extensible Markup Language (XML) is a meta-languageor markup, which does not have a fixed set of tags but allowssers to define tags of their own. It defines the commonyntax for various languages. XML is originally designedo describe a document. As an XML Schema defines thetructure of XML documents, an XML document can bealidated according to the corresponding XML Schema. XMLchemas have been developed for several domains, such asatch Markup Language (BatchML, see? http://www.wbf.rg/displaycommon.cfm?an=1&subarticlenbr=43) for batchrocess information, Mathematical Markup LanguageMathML, see http://www.w3.org/Math/) for mathemat-cs information, Analytical Information Markup Language

rties of resources. A statement is an object–attribute–valueriplet, consisting of a resource, a property and a value. Val-es can either be resources or literals. Similar to XML Schema,DF Schema (RDFS) defines the structure of RDF. Con-epts like UnitProcedure and Operation are defined by URI ofttp://www.purdue.edu/pharmainfo/recipe#UnitProcedure andttp://www.purdue.edu/pharmainfo/recipe#Operation.

Fig. 4. Concept graph of an example.

V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx 5

Fig. 5. Define relation of UnitProcedure and Operation in XML.

The relation is defined as property which has also a URIlinking the concepts of UnitProcedure and Operation as shownin Fig. 6.

The expressivity of RDF and RDFS is limited by design.RDF/RDFS allows the representation of some ontologicalknowledge. The main modeling primitives of RDF/RDFS con-cern the organization of vocabularies in typed hierarchies: sub-class and subproperty relationships, domain and range restric-tions, and instances of classes (Antoniou & Harmelen, 2004).

An ontology language should allow users to write explicit,formal conceptualizations of domain information. Besides awell-defined syntax, a formal semantics, efficient reasoning sup-port, sufficient expressive power are also required. We used WebOntology Language (OWL) for information modeling. OWL isbased on the description logic theory, and is a vocabulary exten-sion of RDF. OWL formalizes a domain by defining classes,properties of these classes and relations between them. OWLcan also define individuals and assert properties about them,and furthermore reason about these classes and individuals tothe degree permitted by the formal semantics of the OWL lan-guage. As shown in Fig. 7, similar to RDFS, the hasOperationis defined as a property, and more than that, it is further definedas ObjectProperty which links two concepts. It also defines theInverse Functional relations with another property: if hasOper-ation describes UnitProcedure1 (an instance of UnitProcedure)contains Operation1 (an instance of Operation), the hasUnitPro-cc

and Operation is defined as subClassOf. The graph structuregenerated from the information modeling is also presented inFig. 7.

2.4. Ontology building

In this section, the workflow, fundamental rules and best prac-tices that we have found useful when developing ontologiesare discussed using the general recipe ontology as an exam-ple. As discussed earlier, ontology models a particular domainusing the constructs provided by a suitable ontology languagesuch as OWL. Ontology building is an evolutionary design pro-cess consisting of proposing, implementing and refining classesand properties that comprise an ontology (Noy & McGuinness,2001). In a sense, there is no one “correct” way of developingan ontology. Some of the typical steps are given below.

2.4.1. Step 1: determine the domain and scope of theontology

The domain of ontology encompasses the information andrelations that will be modeled using that ontology. The gen-eral recipe ontology described here was developed so that thestructure of all information and relationships associated withthe recipe specification of a pharmaceutical product could beformally represented. The classes in the recipe ontology wereioi

2

ddF

edure property of Operation1 uniquely links back to UnitPro-edure1, as illustrated in Fig. 7. The relations between Charge

Fig. 6. Define relation of UnitProcedure and Operation in RDFS.

dentified through discussions with domain experts, knowledgef their intended use and review of the literature on related top-cs.

.4.2. Step 2: enumerate important terms in the ontologyAside from identifying the various classes that must be

efined, another important decision in designing ontologies iseciding which specific classes constitute a particular ontology.or example, on one extreme you could define all classes in one

Fig. 7. Define relation of UnitProcedure and Operation in OWL.

6 V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx

ontology, whereas on the other extreme you could have a sepa-rate ontology for each class. Having all classes in one ontology isadvantageous because it allows you define relationships betweenproperties of various concepts. However, it is against the gen-eral principle of a modular framework. Since a given conceptcan be used for very diverse set of applications, it is desirable toorganize the ontologies such that each ontology consists of asfew classes as possible, and then to use them hierarchically.

At the lowest level, each ontology can be treated as a build-ing block. An ontology at the next level can be constructedby selecting the desired ontologies. For example, an ontologynamed Material contains a class named Material for definingproperties of all pure chemical compounds. This class has oneattribute for each physical property associated with a material.Some of the material attributes are name, chemical formula,molecular weight, state at standard temperature and pressure,density of standard state. The Material ontology can be used asa building block for other ontologies. For example, an ontologythat defines material composition, named MaterialCompostion,contains three attributes named speciesName, compositionValueand measuringUnit. It imports the Material ontology. Similarly,the Stream ontology imports the MaterialComposition ontology.

We used Protege (Version 3.1) (see http://protege.stanford.edu/), an ontology and knowledge-base editor, for cre-ating ontologies. The key higher level concepts in the pro-cess ontology include Parameter, Material, Equipment, Reac-tPF

hiastpphTfvsrP

2

cTgiseapaa

The other way to accomplish this would be to define a classnamed Parameter which has subclasses for each value type suchas temperature, press, mass and so on. A particular temperaturewould be an instance of the Temperature subclass, the Meltingpoint would be specified as a suitable object of the Tempera-ture subclass. Of course, the value of the melting point and thedesired measuring unit are part of the instance of the object ofTemperature subclass.

The latter way of defining a class and attributes has sub-stantial impact in terms of semantics and data organization. Forexample, when all attributes of melting point are defined withthe Material class the information is embedded in a Materialclass object. Therefore, the ability to interpret and process thatinformation must be included in the implementation of the Mate-rial class. On the other hand, if melting point is defined as aninstance of Temperature class, the entire object can be passed tothe implementation of the Temperature class. More importantly,the implementation of the Temperature class can be universallyaccessed and kept up to date. If the attributes are defined everytime they are used, then overheads of implementing and main-taining each occurrence increase significantly.

2.4.4. Step 4: create instancesThe actual data associated with a class is generated through

instances or objects of that class. For example, a specific chem-ical is an instance of the Material class. Since the Material classdvcca

2

ttaplta

potm(eOJthiflO

ion, RecipeElement under which Operation, UnitProcedure androcedure are defined. Other important concepts include Port,lowLink, Stream and FlowNetwork.

The Operation class has several subclasses. Each subclassas attributes or constraints to characterize the underlying phys-cal/chemical change. For example, the Filter subclass has anttribute to let you specify the split fractions for each incomingpecie. OWL provides the capability to describe complex rela-ions between the concepts in the process information. For exam-le, hasUnitProcedure property of Operation and hasOperationsroperty of UnitProcedure are inverse functional relations. TheasOperation property of Port has cardinality restriction of 1.he inference engine can clarify the hierarchy of classes, and

urthermore, check consistency to ensure the completeness andalidity of the process information based on predefined con-istency rules. As an example, a consistency rule is used toequire that the values of hasUpstreamPort and hasDownstream-ort properties of a Stream be different.

.4.3. Step 3: define the classes and class hierarchyClass attributes define the properties of the objects in that

lass. The properties are of two types: object type and data type.he data type attribute values are of primitive types such as inte-er, float, string and so on. The object type attribute values arenstance(s) of some other class(es). As a general principle, theemantic content of information increases when information isncapsulated in classes because explicit meaning can be associ-ted with classes. For example, to completely define the meltingoint of a material you need three attributes, value type, valuend measuring unit. In this case, value type would be temper-ture, and could be specified as a string or a unique identifier.

efines all physical and chemical properties of a material, thealues of properties specific to that material are entered whilereating its instance. The class definitions along with instancesonstitute the information repository. A unique URL is associ-ted with instance(s).

.5. Ontology and tools

In this project, the information is encoded using OWL. Forools to use this information, there are two main options. Forools that will be developed in the future, ontology can be useds a native repository to store declarative knowledge and therocedural knowledge can be encoded using the programminganguage in tools. For legacy tools with its own syntax or seman-ics to the information, the ontology can be used for importingnd exporting information.

Several application programming interfaces are available forarsing, representation, database persistence and querying thentology. These interfaces provide a unified approach for toolso access information repository (Knublauch, 2004). One of the

ost widely used libraries is Jena Semantic Web Frameworksee http://jena.sourceforge.net/), in which OWL classes, prop-rties and individuals are represented as generic Java classes likentClass and Individual. However, there are some limitations in

ena. One of the most important is that there is no direct methodo access all the properties of a given class, when the propertyas more than one domain. The Protege-OWL programmingnterface Version 2.0, an extension of Jena, was used. This inter-ace overcomes some of the limitations in Jena, provides higherevel functionalities and makes it easier to access information inWL.

V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx 7

Fig. 8. Different formats of information in chemical product development.

2.6. Applications of the ontology

As a formal model of domain information, ontology is thefoundation for various applications. In this work, we havedemonstrated the use of ontology for information managementand sharing, and discussed the benefits of ontology-driven soft-ware development.

2.6.1. Ontology-based experiment information managementVoluminous information is generated during product/process

development, such as raw data generated from analytical instru-ments, pictures from SEM instrument, pictures for experimentalsettings, experimental notes and reports, mass and energy bal-ance results from simulation tools, etc. The information couldalso be in different formats, including plain text files, WORDdocument, Excel worksheets, JPEG files, MPEG movies, PDFs,etc. (Fig. 8). How to effectively gather information from differ-ent resources, systematically manage the information, providehelp in decision making become key tasks of information man-agement.

Content management systems were explored to provide thebackbone for the management of experimental data. The contentmanagement systems provide several data management func-tionalities that can be directly used in experimental informationmanagement, for example, user management, data upload, docu-mmItosaodhk

mm

• Meaning of the information not directly accessible. For exam-ple, the content of SEM pictures cannot be described only byfile name.

• Lack of systematic way to represent and explore informa-tion relations. For example, relations between HPLC datadistributed in various locations cannot be described.

• Domain specific information not easily supported. For exam-ple, quality assurance requires a standard for performing andreporting experiments; and interface for data entry needs tobe created manually.

• The information in these systems cannot be easily shared withother software tools.

The file structure is usually created in an ad hoc way. Forexample, in the central storage for all experiment data, the folderstructure is created based on person, time and purpose of a setof files it contains. The typical tree-like folder hierarchy can-not effectively represent the information relations which haveindeed a graph structure.

The root cause of these problems is the lack of semanticsof the information. A more flexible infrastructure which han-dles the semantics of the information in a systematic manneris required for information management. Given the seman-tic nature, ontology and Semantic Web related technologieswould be the foundations for the new infrastructure. Meta-datactdth

sotitpss

ent management, etc. Most of the existing content or documentanagement systems including e-LabNotebooks, Laboratory

nformation Management Systems or Content Management Sys-ems, follow the file/folder structures similar to that in anyperating system, in which folder hierarchies are created totore files. For each file, general and restricted sets of meta-datare usually applied, including the date when the file is createdr modified, the person who created or modified the file, andescription of the file. In order to find information, user mayave to either manually go through the folder structure, or do aeyword-based search.

From our experience of implementing content/documentanagement systems in our project, we found the followingajor limitations with the current structures:

an be defined and managed as ontology, and folder struc-ure can be replaced with the ontology hierarchy. Research oneveloping Semantic Web Portal has demonstrated the poten-ial of these techniques with very interesting prototypes (seettp://www.ontoweb.org/).

In managing the information gathered from pre-formulationtages for pharmaceutical product formulation, we first createdntologies for material properties and experiments. The rela-ions between Material, Experiment and Properties are definedn the ontology and represented graphically in Fig. 9. The cen-ral concept in this abstraction is the material, which representsure substances and mixtures (which are characterized by pureubstances and their compositions in all phases). A material haseveral properties (e.g. specific heat capacity), and can have sev-

8 V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx

Fig. 9. Graph representation of relations.

eral experiments performed on it (e.g. compression tests) whichdetermine the values of respective properties.

When formulation scientists perform an experiment and sub-mit information to the central repository, an instance of corre-sponding ontology is created. Once the information model iscreated automatically from these instances, semantic search canbe carried out. For example, consider the following search:

“Find all the experiments that have been done on themicromeritics of Material A which are potentially affectedby the relative humidity.”

To carry out this search accurately, the following semanticsare required: (1) the subclass relations in micrometritics; (2) therelations between experiment and material; and (3) the relationsbetween context and experiment. Without the semantics, usinga keyword-based search, many irrelevant documents would bereturned.

We are further developing more natural ways to help sci-entists in creating the ontology instances and also investi-gating integration with common content management systemlike Opencms (see http://www.opencms.org/) and Mambo (seehttp://www.mamboserver.com/) to provide functionalities likeuser management, security and so on.

2.7. Ontology-based information sharing

tmi

cafmmiastttal

Fig. 10. Ontology-driven information management and sharing.

We proposed the ontology-driven information sharing inZhao, Bhushan, & Venkatasubramanian (2003), and fur-ther demonstrated the methodology in Zhao, Joglekar, Jain,Venkatasubramanian, and Reklaitis (2005). In this demonstra-tion, the material holdup and stream information calculated byBatches are stored in the information repository and can bedirectly used by PHASuite in conducting safety analysis.

Fig. 10 shows the proposed overall architecture of the APIprocess information sharing and management. The implemen-tation of this infrastructure can be divided into three maintasks. Process ontologies are first created as well as thelogic embedded in the rules to ensure the completeness andvalidity of the process information. Based on the ontologies,instances of the concepts and relations are created for a par-ticular process using the Web-based information managementfacility.

The second task is to create an interface to the repository sousers can access, view and modify the information. A Web-basedinterface for information management was developed becausethe Web is the natural environment for the use of the infras-tructure with such a wide scope. Additionally, development ofthin-client applications in Web environment has become feasibledue to the recent advances in Web technologies.

The third task is to provide application programming inter-face for various tools to access the information repository. Theprocess information repository is in OWL format or relateddpaipwestt

2o

m

As we demonstrate in this project, given its formal and seman-ic richness, ontology would completely define the related infor-

ation and thus can be used to define a common vocabulary fornformation shared by the related tools.

Consider the following scenario: during safety analysis, theomposition, temperature and pressure of material in equipmentnd streams are crucial. This information could be generatedrom simulation tools like Batches, which uses mathematicalodels for unit operations with material properties, or fromanufacturing information systems for real process data if reval-

dation analysis is conducted. For a tool like PHASuite whichssists the experts in safety analysis, without integration withimulation tools or manufacturing information systems, it haso develop its own simplified mass and energy balance calcula-ions. The calculation might not be as accurate as provided byhe simulation packages which deploy sophisticated unit oper-tion models and physical properties calculations. This couldimit the quality of the analysis.

atabases. Given the diversity of the tools that will access therocess information, a middle layer consisting of controller,daptor or translator is created for the tools as well as the Webnterface to access the repository. From what we have shown, therocess information can be sufficiently described using OWL,hich can act as a process information repository. The open and

xplicit description of the information provides a foundation forharing and integrating process information. Fig. 11 illustrateshe process repository, and the interactions between the reposi-ory and tools, using a pharmaceutical API process as case study.

.7.1. Methodologies for software development:ntology-driven and service oriented

This Semantic Web infrastructure is based on formal domainodels in forms of ontologies that are linked to each other on

V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx 9

Fig. 11. Interactions between the process repository and application tools.

the Web. These linked ontologies provide the applications withshared terminologies and understanding. Based on these ontolo-gies, an open infrastructure could be provided for intelligentagents and Web services.

The ontologies not only define the input/output data struc-ture for software applications, they can also be used to rep-resent the knowledge that the applications use to performtheir tasks. The recent movement of Model-Driven Archi-tecture (MDA) proposed by the OMG (Booch et al., 2004)explores ways to better integrate high-level domain models inUnified Modeling Language (UML) with software develop-ment. Ontology-driven approach is very similar to the MDAapproach but in a much more extreme way (Knublauch, 2004):domain models are not only used for code generation, but theyare used as executable artifacts at run-time. We are currentlyexploring these technologies to create a batch simulation plat-form for both quantitative and qualitative simulations and tobetter support the product/process development and lifecyclemanagement.

Service-Oriented Architecture (SOA) promotes loose cou-pling between interacting software agents. Instead of a mono-lithic application package which tries to tightly control allheterogeneous parts, the modules which are loosely separa-ble, should be constructed as services. SOA requires a smallset of simple interfaces to all participating software agents,e.g. the Web Service Description Language 1.1 (WSDL spec-isegaaios2

3. Knowledge modeling and management for decisionmaking

We consider knowledge as organized or contextualized infor-mation which can be used to produce new inferences andgenerate new information. All decisions in chemical prod-uct/process development are based on inferential knowledge,for example, solvent selection based on separation efficiencyand safety/health/environmental concerns, equipment selectionbased on size requirements and material of construction, batchprocess schedules based on optimizing equipment utilization,etc. Among the various forms of knowledge, mathematicalknowledge is the most concise, precise and abstract. Other formsof knowledge include heuristic knowledge which can be pre-sented in forms of rules, and knowledge with the aim of guidingdecisions which can be modeled as guidelines.

In this work, approaches for modeling the knowledge inthe forms of guideline and mathematical knowledge have beenproposed. These knowledge modeling efforts are based on theinformation modeling using ontology. These approaches are dis-cussed using pharmaceutical product/process development ascase study.

3.1. Modeling of guidelines

The process of pharmaceutical product development is a com-peMbpmsdss

fication, see http://www.w3.org/TR/wsdl). Descriptive mes-ages express application-specific semantics, which is currentlyncoded in XML in most cases. OWL Web Ontology Lan-uage for Services (OWL-S) has been submitted to W3C asmarkup language based on OWL for describing the propertiesnd capabilities of Web services in an unambiguous, computer-nterpretable form. OWL-S will facilitate better automationf tasks including Web service discovery, execution, compo-ition and inter-operation (see http://www.w3.org/Submission/004/07/).

lex, iterative process consisting of selection of dosage form,xcipients, processing routes, operating equipments and so on.ost of the decision making is carried out by domain experts

ased on the knowledge they possess. As the pharmaceuticalroduct development is evolving from an art form to one that isore science and engineering based, there is increasing empha-

is on explicit representation of the knowledge which goes intoecision making. Knowledge Modeling helps in better under-tanding of the decision making process by making it moreystematic.

10 V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx

Knowledge which goes into decision making in phar-maceutical product development can be classified into twocategories—implicit and explicit knowledge. An example ofimplicit knowledge would be the knowledge which lies in themind of an experienced domain expert. Explicit knowledgeincludes the formal decision trees and procedures a companymay have or the guidelines from Food and Drug Adminis-tration (FDA) and International Conference on Harmonisation(ICH). However, as the amount of knowledge and informa-tion increase, it becomes very difficult for domain experts touse this knowledge. For effective use, this knowledge must beavailable in explicit form which can be directly understood bycomputers.

Traditional ways to model knowledge in computer inter-pretable format are either programming based or rule based.In the programming-based approach, all the logic is encoded ina computer program and therefore is not transparent. A user can-not change the logic without accessing the source code, whichsometime may not be open or the user may not have the under-standing of particular programming language. Most of the expertsystems use the rule-based approach. Rules are effective in cap-turing the knowledge but are not flexible. Most of the times, rulesare not structured properly, not scalable and difficult to main-tain. Also, it is difficult to predict how different rules interactwith each other.

3

GmdlfrHsrwf

itTotlcssstcrmtA(

3.1.2. Guideline developmentIn this work, various guidelines were developed for the

pharmaceutical product development based on the knowledgecollected from detailed discussions with the academic collab-orators at Department of Industrial and Physical Pharmacy,Purdue University. As a case study, guidelines were used forthe development of a drug product with Cycloserine as the API,to treat the Multidrug-Resistant Tuberculosis (MDRTB). Somedetails of how different guidelines are modeled and used arediscussed here.

Every guideline has a specific purpose and the details of aguideline are specified in algorithm as shown in Fig. 12. Algo-rithm consists of the instances of five types of steps linkedtogether to form a flowchart. Fig. 12 shows the guideline for“Drug Product Development” with the purpose “Given the APIand dose, drug product development (selection of dosage form,processing route and excipients).”

State steps define the starting and end points of a guideline.State step points to the development state instance which con-tains the information of existing state of pharmaceutical productdevelopment. To start using the guideline, first an instance ofdevelopment state is created. To populate the development stateinstance, the API for which the pharmaceutical product devel-opment is desired is selected from the list of materials frommaterial ontology. Other details which are known at this stageare also added, for example, dose.

Fiph(sSArtro

dF“uet

3

(isGdct

.1.1. Structure of guidelineWe use ontology-based approach to model a guideline.

uidelines are created based on the GuideLine Interchange For-at (GLIF) (Peleg et al., 2004) Ontology, which is a specification

eveloped mainly for structured representation of clinical guide-ines. GLIF was developed by the InterMed Collaboratory toacilitate sharing of clinical guidelines. The InterMed collabo-atory is a joint project of medical informatics laboratories atarvard, Stanford, Columbia and McGill Universities. GLIF

upports computer-based guideline execution. It provides a rep-esentation for guidelines which is computer interpretable asell as human readable. It is independent of computing plat-

orms which enables sharing of guidelines.In the GLIF specification, a guideline is represented as an

nstance of the guideline class. Each guideline has the inten-ion attribute which defines the purpose of guideline as text.he process of decision making is encoded as the algorithmf a guideline. Within an algorithm, instances of five types ofasks, which are called guideline steps, can be encoded andinked together in a flowchart to specify their scheduling andoordination during guideline application. Specifically, actionteps are used to record clinical or computational actions; deci-ion steps are used to represent decision points; patient stateteps are used to specify a patient’s states in the specific con-exts of a guideline’s application; and branch steps and syn-hronization steps are used to schedule and coordinate concur-ent tasks. The clinical care process represented in the GLIFodel can be nested using subguidelines, thus multiple views

o the care process with different granularities can be defined.detailed summary of GLIF can be found in Peleg et al.

2004).

The action step Development for IR Solid Oral Dosageorm in the Drug Product Development guideline (Fig. 12)nvokes the subguideline, shown in Fig. 13, which selectsrocessing routes and excipients. Guideline in Fig. 13as examples of various guideline steps. Branch stepStart Excipient Selection for Various Selected Routes) andynchronization step (End Excipient Selection for Variouselected Routes) are used for simultaneous execution of steps.ction step is used for doing computations, giving specific

ecommendations, and starting a subguideline. For example,here are subguidelines for the initial selection of processingoutes based on physical, chemical and mechanical propertiesf the API.

Every decision criterion is specified using decision step. Theecision criterion can be changed based on the requirements.or example, the criterion ‘Is Dose Low’ can be relaxed fromdose < 100 mg” to “dose < 200 mg.” The value of the propertysed in a decision criterion is directly linked to the list of prop-rties. Decision step also specifies the option to select based onhe outcome of a decision.

.1.3. Execution of guidelineFor clinical guidelines, a Guideline Execution Engine

GLEE) has been developed to interpret guidelines encodedn the GLIF format and to integrate with clinical informationystems for guideline implementation. A detailed summary ofLEE can be found at Wang et al. (2004). In order to provide theecision support for drug product development a Java based exe-ution engine was developed to execute guidelines. It is linkedo guideline and other ontologies.

V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx 11

Fig. 12. Basic steps in a guideline algorithm.

As compared to human experts, knowledge in the form ofguidelines is permanent and transferable. In a large search space,decision making is faster and more consistent. GLIF enablesthe modeling and representation of guidelines in a structuredmanner. Guidelines effectively capture the knowledge and canbe used for modeling the knowledge in different domains inchemical and pharmaceutical engineering and in development ofdecision support systems. Apart from helping domain experts indecision making, guidelines can also help them in better under-standing of development process as well as in training.

3.2. Managing mathematical knowledge

Large amount of knowledge used in chemical product andprocess development is in the form of mathematical equations,which is referred to as mathematical knowledge. Compared toother forms of knowledge, like rules, guidelines, etc., mathemat-ical knowledge is more abstract and highly structured (Farmer,2004).

As an example, the equations and variables for fluid-bed dry-ing model (Kunii and Levenspiel, 1969) are shown in Fig. 14.In this model, the drying process is divided into two stages; thefirst stage, modeled by the first two equations, is the vaporiza-tion of moisture on the surface, while the second stage, modeledby the third equation, is the diffusion of water out of the parti-cles. These equations depend on material properties, equipmentp

In pharmaceutical process development, most of the mathe-matical knowledge is either embedded in specific software toolssuch as unit operation models in a simulation software, or hasto be entered into a more general mathematical tool follow-ing a specific syntax, such as Matlab or Mathematica. Much ofthis knowledge, however, concerns specific applications and isexpressed procedurally rather than declaratively. For example, inthe application domain of chemical process development, AspenCustom Modeler (AspenTech, 2005) provides a modeling lan-guage for creating new models which can be used with otherAspen products. Typically, writing and editing of programminglanguage-based models is difficult because it requires familiar-ity with the syntax of the particular solver used (e.g. Matlab,Mathematica or DASSL).

The information technologies are transforming how mathe-matical knowledge is represented, communicated and applied.Mathematical Knowledge Management, a new interdisciplinaryfield of research, has attracted researchers from mathemat-ics, computer science, library science and scientific publishing.Marchiori (2003) provides a general account of technologies likeXML, RDF and OWL to foster the integration of Mathemati-cal representation and Semantic Web. By doing so, it becomespossible to integrate various mathematical sources, to searchglobally, to associate with meta-data as context, and to integratewith other forms of knowledge. Caprotti, Dewar, and Turi (2004)discussed a mechanism for encoding information on mathemat-i

arameters and operating conditions. cal Web services to identify automatically the requirements for

12 V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx

Fig. 13. A guideline showing the details of various steps.

performing a particular task. This mechanism utilizes OWL andDescription Logic reasoning capability.

Bogusch and Marquardt, 1997 refer to an ontology-basedapproach for managing process model equations that defines thesemantics between the equation and the associated variables.Such an object-oriented approach for modeling mathematicalknowledge based on behavioral decomposition is very funda-

mental and therefore reusable. Although many research groupshave tried to use such an ontology based framework for manag-ing process models, for example, ModKit (Bogusch et al., 2001),ProMot (Mangold et al., 2005), etc. Most of them rely upon thesimulation environment/engine to analyze and solve the sys-tems of equations instead of using powerful dedicated solverswhich are available. Also, they use symbolic representation for

Fig. 14. Model for fluid-bed drying.

V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx 13

Fig. 15. The proposed approach for modeling mathematical knowledge.

equations and variables which then is parsed into a format thatthe simulation engine can understand (Mangold et al., 2005).The expensive license fee for most of these model developmentsoftwares is also a point of concern. The components of thesimulation environments discussed above are specialized anddifficult to adapt to other applications.

In the proposed approach, the declarative and procedural partsof the mathematical knowledge have been separated. The declar-ative part consists of the information required by the model torun, the information generated from the model, and the modelequations.

The declarative part consists of the ModelDefenition ontol-ogy and an information repository, also an ontology. Themodel ontology consists of three classes named DependentVari-ables, IndependentVariables and ModelParameters that are usedto define the dependent variables, independent variables, andmodel parameters, respectively. Another class, named ModelE-quations, is used to define all model equations. Each equationis stored as Content MathML, a W3C recommended standardbased on XML.

The model ontology is written in OWL using Protege.Several Web-based graphical editors , such as WebEq (seehttp://www.dessci.com/en/products/webeq/), are available tocreate mathematical equations and store them in ContentMathML. Thus, the process of creating a mathematical modelbecomes very intuitive and user friendly compared to the exist-iotttf

allows representing mathematical equations naturally in a formthat is independent of the solver. The solution of the modelequation is governed by the context in which that model isused. For example, the drying model can be used in a standalone mode to predict the moisture profile in a specific dryerunder given conditions which are retrieved from the informationrepository.

In this work, models consisting of algebraic and first orderexplicit differential equations describing simple unit operationswere created and Mathematica was used as the solver. Mathe-matica has several useful features, including: (1) the symbolicprocessing capability which handles equations in MathML for-mats directly, without having to translate into procedures as inother general mathematic packages; (2) the extensibility withprogramming languages like Java, which makes it possible tocommunicate between the Mathematica kernel and the engine;(3) the Web capability which allows the use of Web environmentto access mathematica installed on remote machines.

The procedural part of this approach is implemented using aJava-based engine. It constructs Mathematica commands basedon equations in MathML. It also creates statements to initializethe model parameters with values provided in the instance ofthe model class chosen, and invokes the Mathematica kernel tosolve the set of equations. A graphical user interface (GUI) isused to display results from the solver (plots or expressions) andis used to select the instance of the model to be solved.

ascha

ng approaches. Each model is an instance of the Model classf the ontology. For example, the fluid-bed drying model inhe ontology calculates the moisture content in the output ofhe dryer as a function of time. The two equations, one forhe heat transfer controlled regime and one for mass trans-er controlled regime are shown in Fig. 15. A model ontology

Due to its modularity, the proposed information centricpproach allows clear separation between model creation andolution. This approach provides a systematic way for modelreators to describe the models in terms of equations with theelp of the intuitive and visual equation editor, and the vari-bles which are described using the ontology and linked to the

14 V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx

Fig. 16. The ontology-driven informatics infrastructure.

information resources. The MathML description of the equa-tions and the ontologies provide an open and solid foundationfor the engine to understand the equations and variables, alongwith the links to access the values of the variables during exe-cution of the model. The equation solving itself is performedby Mathematica. User friendly, Web-based or thick-client inter-faces can be easily created for the use of existing models. Bycreating solver specific engines, a range of solvers can be madeavailable to the users.

The overall structure of the proposed ontology-driven infor-matics infrastructure is shown in Fig. 16. The proposed approachclearly delineates information, knowledge, software tools andpresentation blocks used in pharmaceutical product devel-opment. The Presentation layer encompasses all interactionsbetween the end user and the functional components of theinfrastructure, for example, browsing or uploading informationin the repository, invoking analysis tools, guideline executionand so on. The bidirectional arrows indicate two-way exchangeof information between the connecting blocks.

4. Conclusions

In this paper, we propose an ontological information-centricinfrastructure to support product and process development in thepharmaceutical manufacturing domain. An ontology is used tomfodadmdi

uadiompt

rewards will completely transform how we do product develop-ment and manufacturing in the future.

Acknowledgments

The authors gratefully acknowledge the support from TheIndiana 21st Century Research and Technology Fund. Thanksalso go to our other collaborators at Department of Industrialand Physical Pharmacy at Purdue University, Information Tech-nology at Purdue (ITaP) and Eli Lilly and Company.

References

Aspen Tech (2005). Aspen Custom Modeler. http://www.aspentech.com/product.cfm?ProductID=54.

Antoniou, G., & Harmelen, F. V. (2004). A Semantic Web primer. Cambridge,MA: The MIT Press.

Banares-Alcantara, R., & Lababidi, H. M. S. (1995). Design support systemsfor process engineering—II: KBDS: An experimental prototype. Comput-ers and Chemical Engineering, 19(3), 279–301.

Batch Process Technologies Inc. (2005). Batches reference manual. W.Lafayette, IN.

Booch, G., Brown, A., Iyengar, S., Rumbaugh, J., & Selic, B. (2004). AnMDA manifesto. MDA Journal, 5, 2–9.

Branchman, R. J., & Schmolze, J. G. (1985). An overview of the KL-ONEknowledge representation system. Cognitive Science, 9(2), 171–216.

B

B

B

C

C

F

F

F

G

J

K

K

K

L

M

odel the information, while Semantic Web provides a generalramework for implementing the infrastructure. Various ontol-gy languages and prior attempts in other chemical engineeringomains have been reviewed. Process recipe information is useds an example to demonstrate the major steps in developing aomain specific ontology. Ontology-based information manage-ent and information sharing are discussed. Modeling of two

ifferent forms of knowledge, namely, guideline and mathemat-cal knowledge was discussed.

An ontological framework can better support chemical prod-ct and process development and also open new opportunities forpplications including product/process lifecycle management,evelopment history management and so on. The ontologicalnformatics infrastructure proposed in this paper is at the dawnf a new paradigm for representing, analyzing, interpreting andanaging large amounts of complex and varied information for

roduct development and manufacturing. Considerable intellec-ual and implementation challenges lay ahead but the potential

ogusch, R., & Marquardt, W. (1997). A formal representation of pro-cess model equations. Computers & Chemical Engineering, 21(10),1105–1115.

ogusch, R., Lohmann, B., & Marquardt, W. (2001). Computer-aided processmodeling with ModKit. Computers & Chemical Engineering, 25(7–8),963–995.

urkett, W. C., & Yang, Y. (1995). The STEP integration information archi-tecture. Engineering with Computers, 11, 136–144.

aprotti, O., Dewar, M., & Turi, D. (2004). Mathematical service matchingusing description logic and OWL. In Proceedings of MKM 2004.

haudhri, V. K., Farquhar, A., Fikes, R., Karp, P. D., & Rice J. P. (1998).Open knowledge base connectivity 2.0.3. Technical report.

armer, W. M. (2004). MKM: A new interdisciplinary field of research. ACMSIGSAM Bulletin, 38(2).

arquhar, A., Fikes, R., & Rice, J. (1997). The ontolingua server: A toolfor collaborative ontology construction. International Journal of HumanComputer Studies, 46(6), 707–727.

DA (2005). Process analytical technology initiative. http://www.fda.gov/cder/OPS/PAT.htm.

ruber, T. R. (1993). A translation approach to portable ontology specifica-tion. Knowledge Acquisition, 5(2), 199–220.

arke, M., & Marquardt, W. (1996). Design and evaluation of computer-aided process modeling tools. In J. F. Davis, G. Stephanopoulos, & V.Venkatasubramanian (Eds.), Intelligent systems in process engineering,AIChE symposium series no. 312, 92s, 97–109.

illich, S., Luczak, H., Schlick, C., Weissenbach, M., Wiedenmaier, S., &Ziegler, J. (1999). Task modeling for cooperative work. Behavior andInformation Technology, 18, 325–338.

nublauch, H. (2004). Ontology-driven software development in the con-text of the Semantic Web: An example scenario with Protege/OWL. InInternational workshop on the model-driven Semantic Web.

unii, D., & Levenspiel, O. (1969). Fluidization Engineering. New York:John Wiley & Sons.

enat, D. B., & Guha, R. V. (1990). Building large knowledge-based systems:Representation and interface in the Cyc project. Boston, MA: Addison-Wesley.

acGregor, R. (1991). Inside the LOOM classifier. SIGART Bulletin, 2(3),70–76.

V. Venkatasubramanian et al. / Computers and Chemical Engineering xxx (2006) xxx–xxx 15

Mangold, M., Angeles-Palacios, O., Ginkel, M., Kremling, A., Waschler, R.,Kienle, A., & Gilles, E. D. (2005). Computer-aided modeling of chemicaland biological systems: Methods, tools, and applications. Industrial &Engineering Chemistry Research, 44(8), 2579–2591.

Marchiori, M. (2003). The mathematical Semantic Web. In Proceedings ofthe international conference on mathematical knowledge management.

McGreavy, C., Wang, X. Z., Lu, M. L., & Naka, Y. (1995). A concurrentengineering environment for chemical engineering. Concurrent Engineer-ing: Research and Applications, 3(4), 281–292.

Noy, N. F., & McGuinness, D. L. (2001). Ontology development 101: A guideto creating your first ontology. Stanford Knowledge Systems LaboratoryTechnical Report KSL-01-05.

OWL (2004). Web ontology language overview. W3C Recommendation.http://www.w3.org/TR/owl-features/.

Paszko, C., & Pugsley, C. (2000). Considerations in selecting a Labora-tory Information Management System (LIMS). American Laboratory, 9,38–42.

Peleg, M., Boxwala, A., Tu, S., Wang, D., Ogunyemi, O., & Zeng, Q. (2004).Guideline Interchange Format 3.5 Technical Specification. http://smi-web.stanford.edu/projects/intermed-web/guidelines/.

Schneider, R., & Marquardt, W. (2002). Information technology supportin the chemical process life cycle. Chemical Engineering Science, 57,1763–1792.

Sistare, F., Berry, L. P., & Mojica, C. A. (2005). Process analytical tech-nology: An investment in process knowledge. Organic Process Researchand Development, 9(3), 332–336.

Studer, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineer-ing: Principles and methods. IEEE Transactions on Data and KnowledgeEngineering, 25(1–2), 161–197.

TopQuadrant (2003). Semantic integration: Strategies and tools. TopQuadranttechnology briefing.

Wang, D., Peleg, M., Tu, S. W., Boxwala, A. A., Ogunyemi, O., Zeng, Q., etal. (2004). Design and implementation of the GLIF3 guideline executionengine. Journal of Biomedical Information, 37(5), 305.

Zall, M. (2001). The Nascent Paperless Laboratory. Chemical Innovation, 31,2–9.

Zhao, C. (2002). Knowledge engineering framework for automated HAZOPanalysis. Ph.D. Thesis. Purdue University.

Zhao, C., Bhushan, M., & Venkatasubramanian, V. (2003). Roles of ontol-ogy in automated process safety analysis. In Proceedings of ESCAPE13.

Zhao, C., Joglekar, G., Jain, A., Venkatasubramanian, V., & Reklaitis,G. V. (2005). Pharmaceutical informatics: A novel paradigm for phar-maceutical product development and manufacture. In Proceedings ofESCAPE15.