www.elsevier.com/locate/ecra

Electronic Commerce Research and Applications 5 (2006) 2–15

Ontology management for large-scale enterprise systems

Juhnyoung Lee *, Richard Goodwin

IBM T.J. Watson Research Center, Hawthorne, NY 10532, USA

Received 29 November 2004; received in revised form 30 May 2005; accepted 16 August 2005Available online 4 November 2005

Abstract

Semantic markup languages such as RDF (Resource Description Framework) [Resource Description Framework (RDF), http://www.w3.org/RDF/] and OWL (Web Ontology Language) [Web Ontology Language (OWL), http://www.w3.org/2004/OWL/] areincreasingly being used to externalize meta-data or ontologies about data, software and services in a declarative form. Such externalizeddescriptions in ontological format are used for purposes ranging from search and retrieval to information integration and to service com-position [Resource Description Framework (RDF): Projects and Applications, http://w3c.org/RDF/#projects, Web Ontology Language(OWL): Tools, Projects and Applications, http://w3c.org/2004/OWL/#projects]. Ontologies could significantly reduce the costs ofdeploying, integrating and maintaining enterprise systems. The barrier to more wide-spread use of ontologies for such applications isthe lack of support in the currently available middleware stacks used in enterprise computing. This paper presents our work on devel-oping an enterprise-scale ontology management system that will provide APIs and query languages, and scalability and performance thatenterprise applications demand. We describe the design and implementation of the management system that programmatically supportsthe ontology needs of enterprise applications in a similar way a database management system supports the data needs of applications. Inaddition, we present a novel approach to representing ontologies in relational database tables to address the scalability and performanceissues. The state of the art ontology management systems are either memory-based or use ad hoc solutions for persisting data, and soprovide limited scalability.� 2005 Elsevier B.V. All rights reserved.

Keywords: Semantic web; Ontology; Management system; Inference

1. Introduction

In recent years, there has been a surge of interest inusing ontological information for communicating knowl-edge among software systems. Particularly, the effort hasbeen lead by the semantic Web initiative by W3C [33]. Asa result, an increasing range of software systems need toengage in a variety of ontology management tasks, includ-ing the creation, storage, search, query, reuse, mainte-nance, and integration of ontological information.Recently, there have been efforts to externalize such ontol-ogy management burden from individual software systemsand put them together in middleware known as an ontol-

1567-4223/$ - see front matter � 2005 Elsevier B.V. All rights reserved.

doi:10.1016/j.elerap.2005.08.003

* Corresponding author.E-mail addresses: jyl@us.ibm.com (J. Lee), rgoodwin@us.ibm.com

(R. Goodwin).

ogy management system. An ontology management systemprovides a mechanism to deal with ontological informationat an appropriate level of abstraction. By using program-ming interfaces and query languages the ontology manage-ment system provides, application programs canmanipulate and query ontologies without the need to knowtheir details or to re-implement the semantics of standardontology languages. Such a setting is analogous to theway a database management system allows applicationsto deal with data as tables and provides a query engine thatcan understand and optimize SQL queries.

In this paper, we describe the design and implementa-tion of the SnoBase ontology management system [34],which is being developed at IBM T.J. Watson ResearchCenter. While there are a number of projects for buildingontology support tools [4,6,16,18,25,27,29], the SnoBaseproject is different from others in its objective of developing

J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15 3

an industry-strength ontology management system. Thedesign of the SnoBase system focuses on providing reliabil-ity, scalability, and performance for enterprise computing,and also providing functionality robust and sufficient fordifferent levels of practitioners of ontological information.

To make the system fit well into the current softwaredevelopment environment and reduce rather than increasethe burden on software architects, programmers andadministrators, we synthesize concepts familiar to softwaredevelopers with ideas from the semantic Web and ontologycommunities. The SnoBase system programmatically sup-ports the ontology needs of applications in a similar waya database management system supports the data needsof applications. For programmers, SnoBase provides aJava API referred to as Java Ontology Base Connector(JOBC), which is the ontological equivalent of Java DataBase Connector (JDBC) [24]. JOBC provides a simple-to-use but powerful mechanism for application programmersto utilize ontologies without dealing with the details ofontological information. In addition, the SnoBase ontol-ogy management system supports a number of query lan-guages. At present, SnoBase supports a variant of OWLQuery Language (OWL-QL) [7] and RDF Query Language(RDQL) [30] as ontological equivalents of SQL (StructuredQuery Language) of relational database systems.

In addition, to address the scalability and performanceissues of the state of the art ontology management systemsthat are either memory-based or use ad hoc solutions forpersisting data, SnoBase provides a novel approach to rep-resenting ontologies directly in database tables and provid-ing logical reasoning by using plain SQL triggers. Theprovision of inference in an ontology management systemrequires the description and enforcement of semantics ofsemantic markup language constructs as rules. It turnsout that most useful part of the semantics of W3C semanticWeb markup languages (such as RDF and OWL) can beeffectively expressed as plain SQL triggers. The executionof the triggers automatically enforces the semantics of theontology markup language constructs. With this data-base-based reasoning approach, an ontology managementsystem gains the scalability, reliability and query perfor-mance of the mature relational database system withoutextra cost. This paper describes the schematic architectureand design considerations of the ontology managementsystem.

The rest of this paper is structured as follows: In Section2, we describe several enterprise application contexts inwhich an ontology management system can be useful. Sec-tion 3 provides technical background information onontology using an example and discusses technical chal-lenges on its management support. In Section 4, we explainhow we address the challenges and provide a schematicoverview of the SnoBase ontology management system.Additionally, we briefly describe each component of theSnoBase system. Section 5 explains on ontology query lan-guages which the SnoBase system supports. In Section 6,we describe the design of JOBC API with examples. Sec-

tion 7 presents an approach to representing ontologiesdirectly in database tables and providing logical reasoningcapabilities by using plain SQL triggers. Section 8 summa-rizes the previous work on the ontology management prob-lem, and discusses how the presented work is different fromthem. In Section 9, conclusions are drawn and future workis outlined.

2. Use cases in enterprise computing

Ontology is similar to a dictionary, taxonomy or glos-sary, but with structure and formalism that enables com-puters to process its content. It consists of a set ofconcepts, axioms, and relations, and represents an area ofknowledge. Unlike taxonomy or glossary, ontology allowsto model arbitrary relations among concepts, also modellogical properties and semantics of the relations such assymmetricity, transitivity and inverse, and logically reasonabout the relations. Ontology is often specified in a declar-ative form by using semantic markup languages such asRDF and OWL. It provides a number of potential benefitsin processing knowledge, including the separation ofdomain knowledge from operational knowledge, sharingof common understanding of subjects among human andalso among computer programs, and the reuse of domainknowledge.

This section describes several enterprise application con-texts in which an ontology management system can be use-ful. In addition to these examples, ontology managementcan be beneficial to any system dealing with multipledomain concepts that are interrelated and needs to usethe concepts to describe the behavior or capabilities of itsprograms. Some other examples would include informationretrieval and search systems for semantic-based searchcapabilities, video retrieval systems to annotate media withmetadata, and collaboration management systems to pro-vide a common understanding to collaboration contextsand annotate them.

2.1. Business process integration with web services

Web services facilitate the creation of business processsolutions in an efficient, standard way. However, the pro-cess integration with Web services requires the automationof discovery and composition of Web services. Ontologiesare applied to resolve two basic issues with the Web ser-vice-based business process integration: the discovery ofWeb services based on the capabilities and properties ofpublished services, and the composition of business pro-cesses based on the business requirements of submittedrequests. Application providers can annotate their Webservices using semantic markup languages and make theseservices available for business partners via business serviceregistries such as UDDI. Suppose that there is a semanticmatching service available to help match service requestswith services offered by providers. Such a matching servicewould need to refer to ontologies in which domain knowl-

Fig. 1. University ontology.

4 J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15

edge describing the requirements or capabilities of servicesis defined. Then, it would be able to infer degrees of matchbetween the requested and available services. An ontologymanagement system that can manage the underlying ontol-ogy representation models and reasoning will enable thematching service to perform such semantic-based matches[1].

2.2. Collaboration using corporate social networks

In any large organization such as a university, a com-pany and a government, employees have to collaboratewith a wide variety of people in order to perform differentkinds of tasks. They collaborate with people, not only intheir own group or department, but also with people inother departments, particularly, service departments suchas Human Resources, Legal, Finance, IT, Purchasing,Facilities, Public Relations, etc. Large organizations oftenhave specific people assigned for these tasks that anemployee can contact. However, this contact informationis often not available explicitly in the organization data-base. Therefore, it becomes difficult for a person, especiallya new employee, to discover his/her assigned contact foraccomplishing a certain kind of task. A possible approachto alleviating this problem is to use the concept of ‘‘socialnetworks’’ based on the ‘‘friend’’ relation among people[11]. The informal social networks of an organization set-ting can be further extended with richer ontological infor-mation on the types of relations. For example, eachemployee in the corporate social network has links to var-ious kinds of contacts (e.g., HR, Legal, IT, etc.). The sys-tem then explores the corporate social network to findthe right contact for a certain task. It was reported thatone of the most popular applications of RDF is the Friendof a Friend (FOAF) project, which is about creating a Webof machine-readable homepages describing people, linksbetween them and things they create and do [13,32].

2.3. Model-driven business transformation

An approach to business transformation is to employbusiness models such as process-oriented models or busi-ness component models to identify opportunities for savingcosts or improve business processes [20]. The model-drivenapproach requires a model representation of business enti-ties such as business processes, components, competencies,activities, resources, metrics, Key Performance Indicators(KPIs), etc., and their relations. Semantic models usingontology markup languages provide useful representationof business models because they are not limited in repre-senting different types of relations among business entities.Also, the automatic reasoning capability of semantic mod-els provides an effective method for analyzing businessmodels for identifying cost-saving or process improvementopportunities. For example, business performance metricsare naturally fit well with business activities and tradition-ally represented that way. By using this relation between

business activities and metrics, and also the relationbetween business components and business activities repre-sented in a semantic model, a business analyst can inferrelations between business components and metrics. Thisrelation can provides business insights into how the corpo-rate can improve its performance metrics by addressingissues with the business components associated with theselected set of metrics. Then, by identifying, again in thesemantic model, IT systems (a type of resources) associatedwith the business components, the analysts may be able tosuggest recommendations about IT system management toimprove performance metrics.

3. Technical background

Fig. 1 illustrates a simple example of ontology, whichrepresents knowledge of a university domain [11]. Theontology is displayed as a tree, as shown in a popularontology editor, Protege [29]. In this simple example, allthe relations among nodes are subClassOf. Note thatontology, in general, represents a graph, not a tree, becauseit allows arbitrary relations among nodes, and also allows anode to inherit more than one parents. In this example,PhD student is a subclass of two classes, Researcher andGraduate students.

As described earlier, an ontology is often specified in adeclarative form by using semantic markup languages.The Semantic Web initiative of W3C is a vision for thefuture of the Web in which information is given explicitmeaning, making it easier for machines to automaticallyprocess and integrate information available on the Web.The initiative utilizes XML and XML Schema�s ability to

J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15 5

define customized tagging schemes and RDF�s flexibleapproach to representing data. RDF provides a simplesemantics for data, and the data models can be representedin an XML syntax. In addition, the initiative introduces anontology language, OWL (Web Ontology Language),which can formally describe the meaning of terms. OWLis part of the growing stack of W3C recommendationsrelated to the Semantic Web. Fig. 2 displays a portion ofthe OWL representation of the university ontology intro-duced in Fig. 1. It shows a number of classes related to peo-ple in the domain and their subClassOf relations by usingOWL and RDF constructs.

An ontology is expected to allow machines to performuseful reasoning tasks on documents and system it anno-tates with its concepts and relations. An inference engineprovides this reasoning functionality. It extracts all thefacts from the given ontology, and asserts them into itsworking memory. Also, it is equipped with a knowledgebase which stores a set of action rules for interpreting con-structs of RDF and OWL.

Before asserting the facts initially specified in OWL intothe working memory, the inference engine often utilizes anOWL parser and translates them into a language, Notation3 or N3 [28], which is simplified, but basically equivalent toRDF and OWL in computational power. In RDF andOWL, information is simply a collection of statements,each with a subject, verb and object, and nothing else. InN3, facts are written as triples, verb (subject, object).Fig. 3 shows a portion of facts extracted from the univer-sity ontology, translated into N3, and numbered. They willbe asserted into the working memory of inference engine

Fig. 2. University ontology representation in OWL.

for reasoning. Note that this set of facts is basically thesame set shown in Fig. 2, only in a different notation,i.e., N3.

An essential component of ontology management sys-tems is the inference engine, which provides a mechanismfor interpreting the semantics of an ontology language, rep-resented as a set of language specific rules. The rules areused to answer queries, when the requested fact is notimmediately available, but must be inferred from availablefacts. For example, if the application requests the child-renOf an individual, but the working memory only con-tains parentOf relations, the inference engine can use theinverse property statements about childrenOf and parentOfto identify the correct response. For the inference enginecomponent, most ontology management systems dependon pattern matching algorithms such as Rete [8] originatedfrom earlier work on the rule-based systems [2]. These sys-tems comprises a working memory comprised of a set offacts representing the current status of the system, a knowl-edge base which stores a set of condition action rules, and arule interpreter which applies the rules to the workingmemory. The pattern matching algorithms find all rulesthat are eligible to be fired by matching antecedent of rulesto facts in working memory. If rules have variables, match-ing requires unification. The Rete algorithm does it effi-ciently because it avoids searching all rules every cycle bystoring changes.

The inference engines of most ontology managementsystems currently available are based on pattern matchingalgorithms developed for expert systems in the 1970s and1980s. Their model for working memory and knowledgebase is memory-based or uses ad hoc solutions for manag-ing data. While this model is adequate for dealing withclass hierarchies in small to medium scales, it does not scalefor applications that involve large-scale ontologies andlarge amounts of instance data. We will explain how weaddress this scalability problem with the inference enginesof ontology management systems in Section 6. First, wewill describe the architecture and APIs of the SnoBaseontology management system.

4. SnoBase ontology management system

Ontologies are becoming increasingly prevalent andimportant in a wide range of enterprise applications. Theyare used to support parametric searches, enhanced naviga-tion and browsing, to integrate heterogeneous data sourcesand applications, to configure software, products and ser-vices, and to qualitatively analyze business processes andcomponents. In addition, applications such as informationand (Web) service discovery and composition, and autono-mous agents that are built on top of the Semantic Webrequire extensive use of ontologies.

One of challenges in the design of an industry-strengthontology management system is the versatility of Applica-tion Programming Interfaces and query languages for sup-porting such as diverse applications. This objective requires

Fig. 3. Asserted facts of the university ontology in N3 notation (part).

6 J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15

a careful design to simultaneously satisfy seemingly con-flicting objectives such as being simple, easy-to-use forthe users, and easy-to-adopt for the developers. Anotherchallenge in ontology management is to provide ontol-ogy-enhanced industrial applications with a system that isscalable (supporting thousands of simultaneous distributedusers), available (running 365 · 24 · 7), fast, and reliable.These non-functional features are essential not only forthe initial development and maintenance of ontologies,but also during their deployment.

To provide a holistic management support for theentire lifecycle of ontological information, includingontology creation, storage, search, query, reuse, mainte-nance and integration, an ontology management systemneeds to address a wide range of problems; ontologymodels, ontology base design, query languages, program-ming interfaces, query processing and optimization, feder-ation of knowledge sources, caching and indexing,transaction support, distributed system support, and secu-

rity support, to name a few. While some of these areas arenew challenges for ontology management systems, someare familiar and there have been active studies, particu-larly in relation to traditional studies on knowledge repre-sentation, or recent studies on semantic Web standards.Our approach to the ontology management support is apragmatic one, that is, we identify missing pieces in thispicture, and engineer and synthesize them with prior workfor providing a holistic management system for ontologi-cal information.

Fig. 4 shows a schematic overview of the SnoBase ontol-ogy management system. Conceptually, the applicationprograms interact with the JOBC API that provides high-level access to ontology resources and the ontology engine.The application program interacts with the JOBC API thatprovides an access to an implementation of the API via anontology base driver. In this case, our driver is the SnoBasedriver. In this section, we will describe the each componentof the SnoBase ontology management system.

Fig. 4. SnoBase ontology management system architecture.

J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15 7

4.1. JOBC API

The SnoBase system provides a Java API referred to asJava Ontology Base Connector (JOBC), which is the onto-logical equivalent of the Java Data Base Connector(JDBC). The JOBC API follows the design patterns ofJDBC, with several alterations. Just like JDBC, JOBC pro-vides a connection-based interaction between applicationsand ontology sources. Also, JOBC provides JDBC-style,cursor-based result sets for representing query results.The similarity of JOBC to JDBC was a design decision tohelp application developers of SnoBase can quickly learnthe programming style of JOBC from their previous expe-rience of the popular JDBC protocol. One difference

Fig. 5. A JOBC Statement.

Fig. 6. A JOB

between JOBC and JDBC is that JOBC allows connectionsto be made without reference to a particular base ontology.Such connections provide an access to default ontologies ofthe top-level definitions of XML-based ontology languagessuch as OWL, RDF, RDF Schema and XML Schema.These definitions are required in order to process any onto-logical information. An example JOBC statement (seeFig. 5) and an example JOBC query (see Fig. 6).

4.2. SnoBase driver

This component is an IBM driver for the JOBC interfacethat is equivalent to the IBM DB2 driver for JDBC. TheSnoBase driver consists of Java classes that will providean implementation of the JOBC API, and contains of anumber of components: a local ontology directory, aninference engine, a working memory, a query optimizerand a set of connectors, and other infrastructure neededto support ontology management.

4.3. Ontology directory

This component provides the meta-level informationabout ontologies that are available to the SnoBase driver.By default, the ontology directory contains the referencesto the top-level definitions of OWL, RDF, RDF Schema,XML Schema, and similar definitions for the set of

C query.

8 J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15

XML-based ontology languages supported. In addition,the ontology directory provides metadata such as deploy-ment information and additional sources of ontology infor-mation. For each ontology source, the directory will needto store the URI, but may additionally store informationabout the contents of the ontology source to aid in queryoptimization.

4.4. Inference engine

This component provides a mechanism for interpretingthe semantics of an ontology language, represented as aset of language specific rules. The rules are used to answerqueries, when the requested fact is not immediately avail-able, but must be inferred from available facts. For exam-ple, if the application requests the childrenOf an individual,but the working memory only contains parentOf relations,the inference engine can use the inverse property state-ments about childrenOf and parentOf to identify the cor-rect response. The details of this component, differentapproaches to implementing this component and issues ofthe scalability and performance will be discussed in Section6.

4.5. Query optimizer

For applications that connect to large databases and/orontologies, it will not be feasible to load the entire set ofavailable information into working memory. Instead, thedriver will query the ontology source for appropriate infor-mation as it is needed. In addition, the task of the queryoptimizer is to not only optimize the retrieval of informa-tion from ontology sources, but also coordinate queriesthat span multiple sources.

4.6. Ontology source connectors

These connectors provide a mechanism for reading, que-rying, and writing ontology information to persistent stor-age. The simplest connector is the file connector that isused to store information to the local file system. In addi-tion, there will be connectors for storing ontological infor-mation in remote servers. Also, the connectors are used toimplement caching of remote information to cache the def-initions of the top-level ontology definitions OWL, RDF,RDF Schema, and XML Schema to allow the system towork if the W3C Web site were inaccessible.

5. Query languages

Currently, the SnoBase system supports a variant ofOWL Query Language (OWL-QL) as an ontologicalequivalent of Structured Query Language (SQL). OWL-QL is a language and protocol supporting agent-to-agentquery-answering dialogues using knowledge representedin OWL. It precisely specifies the semantic relations amonga query, a query answer, and the ontology base(s) used to

produce the answer. It also supports query-answering dia-logues in which the answering agent may use automatedreasoning methods to derive answers to queries. AnOWL-QL query contains a query pattern that is a collec-tion of OWL sentences in which some literals and/or URIshave been replaced by variables. A query answer providesbindings of terms to some of these variables such that theconjunction of the answer sentences – produced by apply-ing the bindings to the query pattern and considering theremaining variables in the query pattern to be existentiallyquantified – is entailed by a knowledge base (KB) called theanswer KB.

This design provides a simple but expressive querymodel. To make a query, a program simply describes theconcept it is searching for, indicating with variables whichaspects of matching concepts it is interested in receiving aspart of a reply. This query model is similar to the conceptof query-by-example, but with the advantage that theontology language allows a richer method for describingthe examples. Another advantage of the OWL-QL queryapproach is that the mechanism is easily adaptable to avariety of ontology representation languages. In additionto OWL-QL, SnoBase also supports another ontologyquery language, RDQL, whose specification was submittedto W3C for a possible recommendation. RDQL is similarto OWL-QL in its underlying query mechanism.

6. Java ontology base connector

As described earlier, we designed the JOBC API forSnoBase as an ontological equivalent of the Java DataBase Connector (JDBC). The API is implemented usingthe abstract factory pattern [10]. An abstract factory classdefines methods to create an instance of each abstract classthat represents a user interface widget. Concrete factoriesare concrete subclasses of an abstract factory that imple-ments its methods to create instances of concrete widgetclasses for the same platform. The DataManager class pro-vides a method that is used to construct a connection,based on the URI used to initiate the connection. Thereis a mechanism in the DataManager that uses the databasetype specified in the URI to identify and load the correctdriver. This driver is then used to create a connection ofthe appropriate type. The connection then acts as a factoryto produce objects, such as statements. The objects createdimplement interfaces defined in the JDBC package, buthave implementations that are provided by the driver thatis loaded. We follow a similar design pattern in the imple-mentation of JOBC, with several alterations, as describedabove. The following code sample illustrates the use ofJOBC.

In this example, the code first gets a connection. Thisconnection is then used to create resources and a statement(john isA researcher). This statement is then asserted intothe inference engine. The code then creates a simple queryfor the asserted fact and retrieves it from the working mem-ory of the inference engine. More complex queries can be

J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15 9

implemented using variables. For example, the followingquery requests all who are researchers.

The results of such a query are a set of triples thatinclude the binding(s) of the variable(s) in the query. In thiscase, the variable X is bound to john. Using these basicAPIs, SnoBase programmers can build more complicatedqueries. For example, a query may contain multiple vari-ables and multiple (query) statements. Also, note that Sno-Base does not simply retrieve information previously storedfor queries. Instead, by using an inference engine, it infersfor answering facts that are not immediately available.

7. Direct representation of ontologies in a database

State of the art inference engines for ontology manage-ment systems are either memory-based or use ad hoc solu-tions for persisting data (for a survey of ontology storagesystems, see [14]). While this is adequate for dealing withthe class hierarchies in small to medium-size ontologies, itdoes not scale for applications that involve large amountsof instance data. This is due to the emphasis that is placedon the metadata (hierarchy of classes or concepts) as first-class citizen as opposed to the data (in-stances of classes).

However, many new application domains of enterprisecomputing such as e-commerce and social networks, andbioinformatics deal with large amounts of pre-existing datathat needs to be linked to an ontology. Current solutionsrecommend migration of the existing data into the ontol-ogy data structures. However, if other applications stilluse that data, this approach requires constant replicationto keep the two versions in sync. Moreover, typical adhoc storage solutions do not provide the same level of sup-port for data integrity, concurrent access, and recovery as amature database management system. We believe thatapproaches that create custom storage systems may sufferfrom severe limitations in the long run, such as problemsarising from the need to integrate different ontologies, orontologies with existing data in terms of scalability andflexibility.

To overcome these limitations, we propose exploringdatabase-centric architectures for storing and manipulatingontological data. Such solutions will take advantage ofexisting standards for data management and the DBMSfeatures that have been optimized over the years (robust-

Fig. 7. Data schema

ness, concurrency control, recovery, scalability). This is,however, just the first step towards leveraging relationaldatabase systems for large-scale ontology data manage-ment (ODM). Due to the inherent complexity of ontologi-cal queries, a straightforward database implementation ofan ontology system may not perform optimally. The reasonis that database systems are not optimized for this type ofapplication. We identify several promising directions offuture research with the hope of stimulating the interestof the database community in supporting efficient manage-ment of ontological data.

In this section, we introduce a solution to the lack ofscalability and performance problem of the traditionalapproach to reasoning in ontology management systems.This solution improves reasoning for ontologies by directlyrepresenting facts in relational database tables and repre-senting action rules in SQL triggers. This solution providesa single table called Fact Table, which stores facts assertedby ontology. The table is designed to store facts expressedin N3 notation. Also, this solution provides a set of triggerswhich are fired when a statement is inserted, updated, ordeleted from the Fact Table. Facts added by the triggersare called derived facts, as opposed to asserted facts whichare originated from the ontology. The Fact Table storesthese derived facts along with the keys (IDs) of statementsthat caused their existence. Those keys are called justifica-tions. Note that the justification fields of asserted facts arenull. The justification fields are important because they areused to delete derived statements when their justificationstatements are deleted from the Fact Table. The deletionof derived facts is also automatically managed by usingtriggers.

Fig. 7 displays the data schema of the Fact Table, whichshows the fields for three parts of statements, subject, verband object, justification fields, along with the key field.Note that the fields for subject, verb and object are foreignkeys to an ancillary table which stores actual strings. Themodel field represents the scope of the given statement,but it is not directly related to this discussion.

Fig. 8 displays a couple of triggers that enforce thesemantic of subClassOf relations, namely, the subClassOfrelation is transitive. If a statement inserted into the FactTable completes the rule�s antecedent, then the trigger addsa derived fact as a consequent. There can be many rules

for Fact Table.

Fig. 8. Triggers for deriving implied facts from asserted facts (part).

10 J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15

represented in plain SQL triggers in the system to imple-ment the meaning of constructs of RDF and OWL.

Fig. 9 displays a few facts derived by the triggers shownin Fig. 8. In this simple example, it is relatively straightfor-ward to see the justifications of each derived statement, asshown in Fig. 10. Note that firing of a rule sometimes cancause chains of trigger firing. Also, note that a statementcan be derived by multiple combinations of justificationstatements. Therefore, the solution should provide a mech-anism that prevents a statement from being added multipletimes to the Fact Table.

With statements both asserted and derived in relationaldatabase tables, queries to the ontology management sys-tem become SQL queries to the relational database tables.Most ontology management systems available today usescertain query languages which express queries with a col-lection of N3 statements in which some parts are replacedby variables. A query answer provides bindings of terms tosome of these variables. As explained earlier, the query lan-guage of the IBM�s SnoBase system which is loosely basedon OWL-QL follows this query pattern. The solution pre-sented in this section provides a query processor whichtransforms ontology queries into SQL queries against theFact Table.

Provision of an inference mechanism which is purelybased on mature relational database technology and SQLwould resolve the problems with scalability and perfor-mance of the traditional approach based on rule-basedexpert systems. In addition, query optimization techniquesknown to relational databases such as indexing, schemaoptimization, and performance tuning can be applied tothis proposed approach and further improve the perfor-mance of ontology query execution.

8. Model-driven approach to a semantic toolkit

Until now, we have focused on the description of theapplication programming interfaces, query languages, andinference engines of the SnoBase Ontology ManagementSystem. In this section, we will describe its environmentfor application and model development and transforma-tion, which is equally important in the adoption of thesemantic technology in the industry. The work presentedin this section is a result from our collaboration withresearchers at IBM�s China Research Lab.

Participating in a number of real-world applications byusing the SnoBase Ontology Management System, we havelearned that it is critical to provide a comprehensive devel-opment environment including supporting tools for theapplication developers. A pick-and-choose approach tothe best of the breed tools from different environments doesnot always work well for the majority of the developers andoften results in a longer learning curve for the developers.A comprehensive ontology development environment oftenmeans a tight integration of various tools for applicationdevelopment, ontology development, model import andtransformation, among others. Semantic markup lan-guages such as W3C�s RDF and OWL are based on thework in the logic and Artificial Intelligence (AI) communi-ties, such as Description Logic and Knowledge Representa-tion. The syntax of these languages is less intuitive to thosetrained for object-oriented programming and simple XML-based languages. This deficiency makes the job of subjectmatter experts and application developers difficult, andoften affects negatively to the adoption of the semantictechnology in the industry. An effective ontology applica-tion development environment should bridge this gap

Fig. 9. Derived facts of the university ontology (part).

Fig. 10. Justifications of derived facts.

J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15 11

between the semantic markup languages and the object-ori-ented programmers by providing a tight and seamlessintegration.

Another consideration for the industry adoption of thesemantic technology is the interoperability of the semanticmarkup languages with the well-established and widely-accepted industry standard modeling languages such asEntity-Relation (ER) modeling, XML Schema, and Uni-fied Modeling Language (UML). The fact is that enter-prises developed models in these languages for the pastfew decades and invested significantly to build systems

around them. Despite all the advantages the semantic tech-nology brings in, it is highly unlikely that the enterprisesabandon the legacy systems and develop new systemsaround the semantic technology only. Rather, the usersof the semantic technology in the industry would be inter-ested in the interoperability of the modeling languages, andthe reuse of the existing models and data with the semantictechnology.

To address these practical requirements of the industry,we took an approach based on the Model Driven Architec-ture (MDA), which enables developers and users to design,build, integrate and manage applications throughout theirlifecycle, while separating technology and business con-cerns [26]. The Object Management Group�s MDA specifi-cation provides means to organize and manage enterprisearchitectures supported by automated tools and servicesfor both defining the models and facilitating transforma-tions between different model types. It also provides anopen, vendor-neutral approach against the challenge ofinteroperability. It facilitates efficient use of models in thesoftware development process and reuse of best practiceswhen creating families of systems.

12 J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15

For implementation, we utilized the Eclipse ModelingFramework (EMF), which is IBM�s open source MDAinfrastructure for integration of modeling tools [23]. Amodel specification described in various modeling lan-guages including XML Metadata Interchange (XMI) lan-guage, XML Schema, and annotated Java source can beimported into EMF. Then EMF produces a set of Javaclasses for the model, a set of adapter classes that enableviewing and command-based editing of the model, and abasic editor. In its current implementation, EMF doesnot provide formal semantics definitions, inference andthe related model specifications. We are adding this capa-bility to EMF for the comprehensive ontology applicationdevelopment environment and the dynamic applicationintegration.

For adding the semantic model transformation capabil-ity to EMF, we utilized the OMG�s specification of Ontol-ogy Definition Metamodel (ODM) [3], which providesmetamodels of W3C�s RDF and OWL in UML. By usingEMF and ODM, we generated a foundational memorymodel, i.e., Java classes, for the constructs of RDF andOWL. This foundational memory model is referred to asEODM (Eclipse Ontology Definition Metamodel). By add-ing several necessary helper classes and methods toEODM, we can use it to create, edit, and navigate anymodels in RDF and OWL.

We also added an RDF/OWL parser to EODM, whichcan load RDF/OWL files into EODM and generate RDF/OWL files from EODM, i.e., serialize EODM models tostandard XML RDF/OWL files. The parser utilizes anXMI adaptor which enables the transformation betweenthe RDF/OWL models and EMF Core (Ecore) models[23]. The transformation is made possible by defining amapping between RDF/OWL and the Ecore metamodel.The transformation opens a way to interoperabilitybetween RDF/OWL models and other EMF supportedmodels, which currently include ones defined in XMLSchema, UML and annotated Java classes. The supportof other models such as Entity Relationship models inEMF will be provided in the near future. By leveragingthe RDF/OWL parser and the bi-directional transforma-tion between the RDF/OWLmodels and the Ecore models,ontology application developers can develop ontologiesusing their favorite model building tools, import them intoEMF, transform their models into OWL ontologies, enrichthem with semantics, leverage their inference capability,and utilize the comprehensive development facility ofEclipse and EMF.

To be more specific, the EODM Ecore model is the coremodel that represents ontologies in memory. It is theintermediate model for imported and transformed legacymodels, as well as the generated ontology, Java code, Javaeditor and Java edit. The development environment allowsits users to manipulate EODM Ecore models, enrich it withsemantic specification, and generate Java code. A defaultset of mappings between metamodels of legacy modelsand OWL are developed in EMF. Eclipse plug-in

developers can extend the mappings to handle other typesof legacy models, or other elements in legacy modelsspecifying semantics. In the generated Java code, a smallfoot-print inference engine is shipped with the code andcan be invoked by applications. The generated Java editorand Java edit provide ready-to-use visual tools to populateor manipulated instances of OWL models. The visual toolsare actually copies of the standard methods of supportingapplication development in EMF.

9. Related work

One of the notable studies in ontology management isthe Open Knowledge Base Connectivity (OKBC) [4],which shares somewhat similar objectives with JOBC. Itis a protocol for accessing knowledge bases stored inKnowledge Representation (KR) Systems. The API hasbeen developed to address the issue of knowledge basetool reusability and was implemented in various languagesincluding Java. It provides a set of operations with a gen-eric interface to underlying KR systems, so that it pro-vides applications with independence from theidiosyncrasies of specific KR system and enables thedevelopment of generic tools.

Other work on ontology management includes KAON[18], SymOntoX [16], pOWL [27], and Jena [25]. KAONis a tool suite for ontology management, providing an edi-tor, a Web interface, an API and an inference enginebased on a deductive database approach. SymOntoX isa Web-based ontology editing environment which sup-ports collaborative and distributed ontology authoringactivities. Similarly, pOWL also provides a Web-basedontology editing environment. Jena is a collection ofRDF tools written in Java that includes a Java model/graph API, an RDF parser, a query system, support clas-ses for OWL ontologies, and persistent and in-memorystorage. Jena provides statement-centric methods formanipulating an RDF model as a set of RDF triplesand resource-centric methods for manipulating an RDFmodel as a set of resources with properties.

Additionally, there is active work for ontology integra-tion, which enables to detect and resolve ontological differ-ences and mismatches among existing models andontologies. Systems such as PROMPT [17] and Chimera[15] belong to this category. A more comprehensive surveyon ontology tools can be found in [6]. This survey focuseson the ontology editors and reports 94 existing tools. Addi-tionally, the study reports on management functions of theexisting systems such as reasoning and problem solvingfacilities, standard ontology language support, version con-trol, visual navigation support, ontology alignment, natu-ral language support, collaborative development support,etc.

There are many activities going on in the areas of ontol-ogy query. In addition to OWL-QL described in Section 4,there are a few other ontology query languages of interest.RDQL (RDF Query Language) is a typed, declarative

J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15 13

query language for querying RDF description bases. TRI-PLE is an ontology query, inference, and transformationlanguage for the semantic Web [19]. It allows the semanticsof languages on top of RDF to be defined with rules.

The database-centric architecture for storing and man-aging ontological data presented in Section 6 is related todeductive databases [9,21,22]. The concept of the deductivedatabase was implemented in several systems includingSABRE [9], CORAL Deductive Database [21], and Dat-alog [22]. They often provided a logic-based, declarativequery language for the relational model, and imperativeconstructs such as update, insert and delete rules. In addi-tion, CORAL provided C++ API to combine declarativeand imperative programming.

One aspect that separates our approach from thedeductive databases is that it teaches rules are writtenin the standard SQL language as SQL triggers, whilethe prior art (CORAL, SABRE, Datalog) teaches thatrules are written in a logic-based, declarative query lan-guage, which is not standard SQL. In addition, unlikeprior art, this approach takes advantage of the maturestandard SQL technology for managing rules (forupdate, assert and retract) instead some other means,which is not standard SQL.

Another database-centric approach related to ontologysupport was discussed in [5]. This approach expandedSQL by adding new operations for supporting ontology-based semantic matching in SQL queries. It allows usersto write a SQL query by using the new ontology opera-tors that returns not only syntactically matching rows ofdata, but also rows of data semantically related as definedin the ontology also specified in the query. It stores ontol-ogies in system-defined tables instead of user tables, andso, they are invisible to the users. Also, inference for que-ries is hidden in the implementation of the ontology oper-ators. Therefore, it is invisible to the users. The approachadditionally discussed a special indexing scheme forspeeding up the ontology-based semantic matching que-ries. This work focused on extending SQL to supportontology-based semantic matching. They placed theactual implementation of the inference and ontology stor-age mechanisms in a lower level of the system. In con-trast, the database-centric approach presented in thispaper focuses on the implementation of the inferenceand ontology storage mechanisms by using plain SQLconstructs (triggers) and user tables. The user queriesontologies through OWL-QL which SnoBase supportsand the OWL-QL queries are automatically translatedinto SQL queries.

10. Concluding remarks

An increasing range of applications require an ontologymanagement system that helps externalize ontologicalinformation for a variety of purposes in a declarativeway. The primary objective of ontology management sys-tems is to provide holistic control over management activ-

ities for ontological information by externalizing themfrom application programs. Ontology management systemsprovide ontology independence to applications in a similarway that database management systems provide data inde-pendence. One of the pragmatic challenges for ontologymanagement system research is how to create missing com-ponent technology pieces, and to engineer them with exist-ing results from prior research work for providing a holisticmanagement system.

In this paper, we presented a project for developingan industry-strength ontology management system thatwill provide reliability, scalability, and performance forenterprise uses, and also provide functionality robustand sufficient for different levels of practitioners of onto-logical information. We described the design and imple-mentation of the SnoBase ontology managementsystem, which is under development at IBM T.J. WatsonResearch Center. The programming interface of the Sno-Base system provides a Java API, Java Ontology BaseConnector, which is the ontological equivalent of theJava Data Base Connector. Similarly, this system sup-ports a variant of OWL Query Language (OWL-QL)as our ontological equivalent of SQL (Structured QueryLanguage), and will support a few other ontology querylanguages in the future.

As ontologies are becoming central to an increasingnumber of enterprise applications such as business processand information integration, and information search andnavigation which require scalability and performance, effi-cient storage and manipulation of large scale ontologicaldata is going to be essential. In this paper, we introducedan architecture that leverages relational database systemsfor storing ontologies. We described a direct representa-tion of ontologies in a relational database using a verticaltable for storing ontology triples and triggers for auto-matic maintenance of inferred facts. This solution is pri-marily concerned with the storage of classes and theirrelations and less with instance data. In order to accom-modate large volumes of data, we are working on anarchitecture that leaves the data in place, and provides avirtualization layer that effectively links the data triplesto ontology classes. The database-centric approach toontology management support is still in its infancy. Forthis approach to scale, a number of technical challengesneed to be addressed. Some directions for further investi-gation include:

� Improving trigger evaluation by exploiting the fact thatmany inference rule-specific triggers share considerableportions of their conditions.

� Exploring query rewriting possibilities by analyzing thecharacteristics of vertical virtual views used in the data-base-centric inference scheme.

� A specialized metadata, ontology indexes to guaranteeshort response times when supporting an increasingnumber of enterprise applications with large volumesof instance data.

14 J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15

� Extensions to SQL for ontological queries over classes,relations and instances. For example, it might be usefulto allow path patterns over the labeled graph of classesand relations.

� Exploring hybrid approaches to storage ranging fromfully materialized vertical tables to fully virtual viewsover existing tables. Cost measures can take intoaccount query work-load and physical distribution ofdata.

� Reasoning about the cardinalities of the relationsbetween classes and tables. For example, one table cor-responds to one and only class, one table storesinstances of many classes, a single class can span multi-ple tables, and finally many-to-many class-tablerelations.

� Lazy vs. Eager computation of derived facts: some infer-ence rules involve transitive closure and are harder toevaluate at query time; for others, simpler rules (non-recursive) can be added to a user query automaticallyand evaluated at query time.

Finally, we presented an ontology application develop-ment environment which allows model transformation.We took an approach based on the Model Driven Archi-tecture, which supports automated tools and services forboth defining the models and facilitating transformationsbetween different model types. Our implementation utilizedthe Eclipse Modeling Framework (EMF) which is IBM�sopen source MDA infrastructure. By leveraging the bi-directional transformation between the RDF/OWL modelsand the EMF models, our system enables ontology applica-tion developers to develop ontologies using their favoritemodel building tools, import them into EMF, transformtheir models into OWL ontologies, enrich them withsemantics, leverage their inference capability, and utilizethe comprehensive development facility of Eclipse andEMF.

Acknowledgements

The author thanks Guo Tong Xie, Yue Pan, Li Ma,Yang Yang, ZhaoMing Qiu and Rama Akkiraju for theirconstructive discussion and support for this work.

References

[1] R. Akkiraju, K. Verma, R. Goodwin, P. Doshi, J. Lee, ‘‘ExecutingAbstract Web Process Flows,’’ in: The 14th International Conferenceon Automated Planning and Scheduling (ICAPS 2004), Whistler,British Columbia, Canada, June 3–7, 2004.

[2] L. Brownston, R. Farrell, E. Kant, Programming Expert Systems inOPS5: An Introduction to Rule-Based Programming, The Addison-Wesley series in Artificial Intelligence, 1985.

[3] Daniel T. Chang, Elisa Kendall, ‘‘Metamodels for RDF Schemaand OWL,’’ http://www.sandsoft.com/edoc2004/ChangRDFS&OWLMDSW.pdf.

[4] V. Chaudhri, A. Farquhar, R. Fikes, P. Karp, J. Rice, ‘‘OKBC: AProgrammatic Foundation for Knowledge Base Interoperability;’’AAAI-98.

[5] S. Das, E.I. Chong, G. Eadon, J. Srinivasan, Supporting Ontology-based Semantic Matching in RDBMS, in: The 30th InternationalConference on Very Large Data Bases, Toronto, Canada, 29 August– 3 September, 2004.

[6] M. Denny, ‘‘Ontology Tools Survey, Revisited,’’ http://www.xml.com/pub/a/2004/07/14/onto.html, July 14, 2004.

[7] R. Fikes, P. Hayes, I. Horrocks, OWL-QL – A Language forDeductive Query Answering on the Semantic Web, KnowledgeSystems Laboratory, Stanford University, Stanford, CA, 2003.

[8] C. Forgy, Rete: a fast algorithm for the many pattern/many objectpattern match problem, Artificial Intelligence 19 (1982) 17–37.

[9] G. Gardarin, F. Pasquer, Design and Implementation of SABRE : ADeductive and Parallel Database Machine, in: Database Machines,NATO, Pergamon Press, New York, 1985.

[10] M. Grand, Patterns in JavaA Catalog of Reusable Design PatternsIllustrated with UML, vol. 1, Wiley, 1998.

[11] I. Horrocks, University Ontology, http://protege.stanford.edu/plu-gins/owl/owl-library/ka.owl.

[13] J. Lee, R. Goodwin, The Semantic Webscape: a View of the SemanticWeb, in: The International World Wide Web Conference, Chiba,Japan, May 10–14, 2005.

[14] A. Magkanaraki, G. Karvounarakis, T.T. Anh, V. Christophides, D.Plexousakis, Ontology Storage and Querying, ICS-FORTH TechnicalReport, No. 308, April, 2002.

[15] D.L. McGuiness, ‘‘Conceptual Modeling for Distributed OntologyEnvironments,’’ in: Proceedings of the 8th International Confer-ence on Conceptual Structures Logical, Linguistic, and Compu-tational Issues (ICCS 2000), Darmstadt, Germany, August 14–18,2000.

[16] M. Missikoff, F. Taglino, SymOntoX: A Web-Ontology Tool foreBusiness Domains, in: The 4th International Conference on WebInformation Systems Engineering (WISE�03), Rome, Italy, December10–12, 2003.

[17] N.F. Noy, M.A. Musen, PROMPT: Algorithm and Tool forAutomated Ontology Merging and Alignment, in: 17th NationalConference on Artificial Intelligence (AAAI-2000).

[18] D. Oberle, R. Volz, B. Motik, S. Staab, An extensible ontologysoftware environment, in: Steffen Staab, Rudi Studer (Eds.), Hand-book on Ontologies, Springer, Berlin, 2004, pp. 311–333 (ChapterIII).

[19] M. Sintek, S. Decker, TRIPLE – An RDF Query, Inference, andTransformation Language for the Semantic Web, in: InternationalSemantic Web Conference, 2001.

[20] J. Zhu, Z. Tian, T. Li, W. Sun, S. Ye, W. Ding, C.C. Wang, G. Wu, L.Weng, S. Huang, B. Liu, D. Chou, Model-Driven Business ProcessIntegration and Management: a Case Study with the Bank SinoPacRegional Service Platform, http://www.research.ibm.com/journal/rd/485/zhu.html.

[21] Coral Database Project, http://www.cs.wisc.edu/coral/.[22] Deductive Databases – Datalog Approach, http://goanna.cs.rmit.e-

du.au/~zahirt/Teaching/subj-datalog.html.[23] EMF: Eclipse Modeling Franework, http://www.eclipse.org/emf/.[24] J2EE JDBC Technology, http://java.sun.com/products/jdbc/.[25] Jena: A Semantic Web Framework, http://www.hpl.hp.com/semweb/

jena.htm.[26] OMG Model-Driven Architecture, http://www.omg.org/mda/.[27] pOWL: Semantic Web Development Platform, http://powl.source-

forge.net/.[28] Primer: Getting into RDF & Semantic Web using N3, http://

www.w3.org/2000/10/swap/Primer.html.[29] Protege Ontology Editor, http://protege.stanford.edu/.[30] RDF Data Query Language (RDQL), RDQL – A Query Language

for RDF, http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/.

[31] Resource Description Framework (RDF), http://www.w3.org/RDF/.[32] Resource Description Framework (RDF): Projects and Applications,

http://w3c.org/RDF/#projects.[33] Semantic Web, http://www.w3.org/2001/sw/.

J. Lee, R. Goodwin / Electronic Commerce Research and Applications 5 (2006) 2–15 15

[34] SnoBase: IBM Ontology Management System, http://alpha-works.ibm.com/tech/snobase.

[35] Web Ontology Language (OWL), http://www.w3.org/2004/OWL/.[36] Web Ontology Language (OWL): Tools, Projects and Applications,

http://w3c.org/2004/OWL/#projects.

Further reading

[12] V. Krebs, An Introduction to Social Network Analysis, http://www.orgnet.com/sna.html.