the semantic web: a brain for humankind - mit media labthe semantic web: a brain for humankind...

24 1094-7167/01/$10.00 © 2001 IEEE IEEE INTELLIGENT SYSTEMS

G u e s t E d i t o r s ’ I n t r o d u c t i o n

The Semantic Web: A Brain for HumankindDieter Fensel, Vrije Universiteit AmsterdamMark A. Musen, Stanford University

O riginally, the computer was intended as a device for computation. Then, in the 1980s,

the PC developed into a system for games, text processing, and PowerPoint pre-

sentations. Eventually, the computer became a portal to cyberspace—an entry point to a

worldwide network of information exchange and business transactions. Consequently,

technology that supports access to unstructured, het-erogeneous, and distributed information and knowl-edge sources is about to become as essential as pro-gramming languages were in the 60s and 70s.

The Internet—especially World Wide Web tech-nology—was what introduced this change. The Web isan impressive success story, in terms of both its avail-able information and the growth rate of human users.It now penetrates most areas of our lives, and its suc-cess is based on its simplicity. The restrictiveness ofHTTP and (early) HTML gave software developers,information providers, and users easy access to newmedia, helping this media reach a critical mass.

Unfortunately, this simplicity could hamper fur-ther Web development. What we’re seeing is just thefirst version of the Web. The next version will be evenbigger and more powerful—but we’re still figuringout how to obtain this upgrade.

Growing complexityFigure 1 illustrates the growth rate of current Web

technology. It started as an in-house solution for asmall group of users. Soon, it established itself as aworldwide communication medium for more than

10 million people. In a few years, it will interweaveone billion people and penetrate not just computersbut also other devices, including cars, refrigerators,coffee machines, and even clothes.

However, the current state of Web technology gen-erates serious obstacles to its further growth. Thetechnology’s simplicity has already caused bottle-necks that hinder searching, extracting, maintaining,and generating information. Computers are only usedas devices that post and render information—theydon’t have access to the actual content. Thus, theycan only offer limited support in accessing and pro-cessing this information. So, the main burden not onlyof accessing and processing information but also ofextracting and interpreting it is on the human user.

The Semantic WebTim Berners-Lee first envisioned a Semantic Web

that provides automated information access based onmachine-processable semantics of data and heuristicsthat use these metadata. The explicit representation ofthe semantics of data, accompanied with domain the-ories (that is, ontologies), will enable a Web that pro-vides a qualitatively new level of service. It will weave

together an incredibly large network of humanknowledge and will complement it withmachine processability. Various automated ser-vices will help the user to achieve goals byaccessing and providing information in amachine-understandable form. This processmight ultimately create an extremely knowl-edgeable system with various specialized rea-soning services—systems that can support us innearly all aspects of our life and that will becomeas necessary to us as access to electric power.

This gives us a completely new perspectiveof the knowledge acquisition and engineeringand the knowledge representation communi-ties. Some 20 years ago,AI researchers coinedthe slogan “knowledge is power.” Quickly,two communities arose:

• knowledge acquisition and engineering,which deals with the bottleneck of acquir-ing and modeling knowledge (the human-oriented problem), and

• knowledge representation, which dealswith the bottleneck of representing knowl-edge and reasoning about it (the computer-oriented problem).

However, the results of both communitiesnever really hit the nail on the head. Knowl-edge acquisition is too costly, and the knowl-edge representation systems that were cre-ated were mainly isolated, brittle, and smallsolutions for minor problems.

With the Web and the Semantic Web, thissituation has changed drastically. We havemillions of knowledge “acquisitioners” work-ing nearly for free, providing up to a billionWeb pages of information and knowledge.Transforming the Web into a “knowledgeWeb” suddenly put knowledge acquisitionand knowledge representation at the center ofan extremely interesting and powerful topic:Given the amount of available online infor-

mation we already have achieved, this Knowl-edge (or Semantic) Web will be extremelyuseful and powerful. Imagine a Web that con-tains large bodies of the overall human knowl-edge and trillions of specialized reasoningservices using these bodies of knowledge.Compared to the potential of the SemanticWeb, the original AI vision seems small andold-fashioned, like an idea of the 19th cen-tury. Instead of trying to rebuild some aspectsof a human brain, we are going to build abrain of and for humankind.

In this issueThe work and projects described in this

special issue provide initial steps into such adirection. We start with Michel Klein’s tuto-rial, which introduces the current languagestandards of the Semantic Web: XML,XMLS, RDF, and RDFS.

James Hendler—who has already helpedus all by successfully initiating and runninga large DARPA-funded initiative on theSemantic Web—reveals his vision of theSemantic Web. On the basis of a standardontology language, he sees software agentspopulating the Semantic Web, providingintelligent services to their human users. In“OIL: An Ontology Infrastructure for theSemantic Web,” Dieter Fensel, Ian Horrocks,Frank van Harmelen, Deborah L. McGuin-ness, and Peter F. Patel-Schneider proposesuch an ontology standard language. OIL andDAML+OIL are the basis of a semanticworking group of the W3C that should soondevelop a standardization approach. SheilaA. McIlraith, Tran Cao Son, and HongleiZeng, in “Semantic Web Services,” and JeffHeflin and James Hendler, in “A Portrait ofthe Semantic Web in Action,” describe intel-ligent services on top of such services, basedon query and reasoning support for theSemantic Web.

A key technology for the Semantic Web isontologies. In “Creating Semantic Web Con-tents with Protégé-2000,” Natalya F. Noy,Michael Sintek, Stefan Decker, MonicaCrubézy, Ray W. Fergerson, and Mark A.Musen provide excellent tool support formanually building ontologies based on Pro-tégé-2000. However, even with an excellenttool environment, manually building ontolo-gies is labor intensive and costly. AlexanderMaedche and Steffen Staab, in “OntologyLearning for the Semantic Web,” try tomechanize The ontology building processwith machine learning techniques.

MARCH/APRIL 2001 computer.org/intelligent 25

T h e A u t h o r sDieter Fensel is anassociate professor atthe Division of Math-ematics and ComputerScience, Vrije Univer-siteit, Amsterdam, anda new department edi-tor for Trends & Con-troversies. After study-

ing mathematics, sociology, and computerscience in Berlin, he joined the Institute AIFBat the University of Karlsruhe. His major subjectwas knowledge engineering, and his PhD thesiswas on formal specification language for knowl-edge-based systems. Currently, his focus is onusing ontologies to mediate access to heteroge-neous knowledge sources and to apply them inknowledge management and e-commerce. Con-tact him at the Division of Mathematics andComputer Science, Vrije Universiteit Amster-dam, De Boelelaan 1081a, 1081 HV Amster-dam, Netherlands; [email protected]; www.cs.vu.nl/~dieter.

Mark A. Musen is anassociate professor ofmedicine (medical in-formatics) and com-puter science at Stan-ford University and ishead of the StanfordMedical Informaticslaboratory. He con-

ducts research related to knowledge acquisitionfor intelligent systems, knowledge-system archi-tecture, and medical-decision support. He hasdirected the Protégé project since its inception in1986, emphasizing the use of explicit ontologiesand reusable problem-solving methods to buildrobust knowledge-based systems. He has an MDfrom Brown University and a PhD from Stan-ford. Contact him at Stanford Medical Informat-ics, 251 Campus Dr., Stanford Univ., Stanford,CA 94305; [email protected]; www.smi.stanford.edu/people/musen.

1990 1997

10 million usersworldwide

1 billion usersdevicewide

2003

1,000 usersin-house solution

Figure 1. The growth rate of current Web technology.

By Michel KleinVrije Universiteit

T u t o r i a l : T h e S e m a n t i c W e b


Let’s start with XMLXML (eXtensible Markup Language) is a specification

for computer-readable documents. Markup means thatcertain sequences of characters in the document containinformation indicating the role of the document’s content.The markup describes the document’s data layout and logi-cal structure and makes the information self-describing, ina sense. It takes the form of words between pointy brack-ets, called tags—for example, <name> or <h1>. In thisaspect, XML looks very much like the well-known lan-guage HTML.

However, extensible indicates an important differenceand a main characteristic of XML. XML is actually ametalanguage: a mechanism for representing other lan-guages in a standardized way. In other words, XML onlyprovides a data format for structured documents, withoutspecifying an actual vocabulary. This makes XML univer-sally applicable: you can define customized markup lan-guages for unlimited types of documents. This has alreadyoccurred on a massive scale. Besides many proprietarylanguages—ranging from electronic order forms to appli-cation file formats—a number of standard languages aredefined in XML (called XML applications). For example,XHTML is a redefinition of HTML 4.0 in XML.

Let’s take a more detailed look at XML. The mainmarkup entities in XML are elements. They consist nor-mally of an opening tag and a closing tag—for example,<person> and </person>. Elements might contain other ele-ments or text. If an element has no content, it can beabbreviated as <person/>. Elements should be properlynested: a child element’s opening and closing tags must bewithin its parent’s opening and closing tags. Every XML

document must have exactly one root element. Elementscan carry attributes with values, encoded as additional“word = value” pairs inside an element tag—for example,<person name=“John”>. Here is a piece of XML:

<?xml version=“1.0”?><employees>

List of persons in company:<person name=“John”>

<phone>47782</phone>On leave for 2001.

</person></employees>

XML does not imply a specific interpretation of thedata. Of course, on account of the tag’s names, the mean-ing of the previous piece of XML seems obvious tohuman users, but it is not formally specified! The onlylegitimate interpretation is that XML code contains namedentities with subentities and values; that is, every XMLdocument forms an ordered, labeled tree. This generalityis both XML’s strength and its weakness. You can encodeall kinds of data structures in an unambiguous syntax, butXML does not specify the data’s use and semantics. Theparties that use XML for their data exchange must agreebeforehand on the vocabulary, its use, and its meaning.

Enter DTDs and XML SchemasSuch an agreement can be partly specified by Docu-

ment Type Definitions and XML Schemas. AlthoughDTDs and XML Schemas do not specify the data’s mean-ing, they do specify the names of elements and attributes(the vocabulary) and their use in documents. Both aremechanisms with which you can specify the structure ofXML documents. You can then validate specific docu-ments against the structure prescription specified by aDTD or an XML Schema.

DTDs provide only a simple structure prescription: theyspecify the allowed nesting of elements, the elements’possible attributes, and the locations where normal text isallowed. For example, a DTD might prescribe that every

Languages for representing data and knowledge are an

important aspect of the Semantic Web. And there are

a lot of languages around! Most languages are based on

XML or use XML as syntax; some have connections to

RDF or RDF Schemas. This tutorial will briefly introduce

XML, XML Schemas, RDF, and RDF Schemas.

XML, RDF, and Relatives

person element must have a name attributeand may have a child element called phonewhose content must be text. A DTD’s syn-tax looks a bit awkward, but it is actuallyquite simple.

XML Schemas are a proposed successorto DTDs. The XML Schema definition isstill a candidate recommendation from theW3C (World Wide Web Consortium), whichmeans that, although it is considered stable,it might still undergo small revisions. XMLSchemas have several advantages overDTDs. First, the XML Schema mechanismprovides a richer grammar for prescribingthe structure of elements. For example, youcan specify the exact number of allowedoccurrences of child elements, you canspecify default values, and you can putelements in a choice group, which meansthat exactly one of the elements in thatgroup is allowed at a specific location. Sec-ond, it provides data typing. In the examplein the previous paragraph, you could pre-scribe the phone element’s content as fivedigits, possibly preceded by another fivedigits between brackets. A third advantageis that the XML Schema definition pro-vides inclusion and derivation mechanisms.This lets you reuse common element defin-itions and adapt existing definitions to newpractices.

A final difference from DTDs is thatXML Schema prescriptions use XML astheir encoding syntax. (XML is a metalan-guage, remember?) This simplifies tooldevelopment, because both the structureprescription and the prescribed documentsuse the same syntax. The XML Schemaspecification’s developers exploited thisfeature by using an XML Schema docu-ment to define the class of XML Schemadocuments. After all, because an XMLSchema prescription is an XML applica-tion, it must obey rules for its structure,which can be defined by another XMLSchema prescription. However, this recur-sive definition can be a bit confusing.

RDF represents data about dataXML provides a syntax to encode data;

the resource description framework is amechanism to tell something about data. Asits name indicates, it is not a language but amodel for representing data about “thingson the Web.” This type of data about data iscalled metadata. The “things” are resourcesin RDF vocabulary.

RDF’s basic data model is simple:

besides resources, it contains propertiesand statements. A property is a specificaspect, characteristic, attribute, or relationthat describes a resource. A statement con-sists of a specific resource with a namedproperty plus that property’s value for thatresource. This value can be another re-source or a literal value: free text, basi-cally. Altogether, an RDF description is alist of triples: an object (a resource), anattribute (a property), and a value (a re-source or free text). For example, Table 1shows the three triples necessary to statethat a specific Web page was created bysomething with a name “John” and a phonenumber “47782.”

You can easily depict an RDF model as adirected labeled graph. To do this, you drawan oval for every resource and an arrow forevery property, and you represent literalvalues as boxes with values. Figure 1 showssuch a graph for the triples in Table 1.

These example notations reveal thatRDF is ignorant about syntax; it only pro-vides a model for representing metadata.The triple list is one possible representa-tion, as is the labeled graph, and other syn-tactic representations are possible. Ofcourse, XML would be an obvious candi-date for an alternative representation. Thespecification of the data model includessuch an XML-based encoding for RDF.

As with XML, an RDF model does notdefine (a priori) the semantics of any appli-cation domain or make assumptions abouta particular application domain. It just pro-vides a domain-neutral mechanism to de-scribe metadata. Defining domain-specificproperties and their semantics requiresadditional facilities.

Defining an RDF vocabulary:RDF Schema

Basically, RDF Schema is a simple typesystem for RDF. It provides a mechanismto define domain-specific properties andclasses of resources to which you can applythose properties.

The basic modeling primitives in RDFSchema are class definitions and subclass-of statements (which together allow thedefinition of class hierarchies), propertydefinitions and subproperty-of statements(to build property hierarchies), domain andrange statements (to restrict the possiblecombinations of properties and classes),and type statements (to declare a resourceas an instance of a specific class). Withthese primitives you can build a schema fora specific domain. In the example I’ve beenusing throughout this tutorial, you coulddefine a schema that declares two classesof resources, Person and WebPage, and twoproperties, name and phone, both with thedomain Person and range Literal. You coulduse this schema to define the resourcehttp://www.w3.org/ as an instance of WebPageand the anonymous resource as an instanceof Person. Together, this would give someinterpretation and validation possibilities tothe RDF data.

RDF Schema is quite simple compared tofull-fledged knowledge representation lan-guages. Also, it still does not provide exactsemantics. However, this omission is partlyintentional; the W3C foresees and advo-cates further extensions to RDF Schema.

Because the RDF Schema specificationis also a kind of metadata, you can useRDF to encode it. This is exactly whatoccurs in the RDF Schema specification


http://www.w3.org/name

phone

John

47782

created by

Figure 1. A directed labeled graph for the triples in Table 1.

Table 1. An RDF description consisting of three triples indicating that a specific Web page was created by somethingwith a name John and a phone number “47782.”

OBJECT ATTRIBUTE VALUE

http://www.w3.org/ created_by #anonymous_resource1#anonymous_resource1 name “John”#anonymous_resource1 phone “47782”

document. Moreover, the specification pro-vides an RDF Schema document that de-fines the properties and classes that theRDF Schema specification introduced. Aswith the XML Schema specification, sucha recursive definition of RDF Schemalooks somewhat confusing.

XML and RDF are different formalismswith their own purposes, and their roles inthe realization of the Semantic Web visionwill be different. XML aims to provide aneasy-to-use syntax for Web data. With it,you can encode all kinds of data that isexchanged between computers, using XMLSchemas to prescribe the data structure.This makes XML a fundamental languagefor the Semantic Web, in the sense thatmany techniques will probably use XML astheir underlying syntax.

XML does not provide any interpretationof the data beforehand, so it does not con-tribute much to the “semantic” aspect ofthe Semantic Web. RDF provides a stan-dard model to describe facts about Webresources, which gives some interpretationto the data. RDF Schema extends thoseinterpretation possibilities somewhat more.However, to realize the Semantic Web

vision, it will be necessary to express evenmore semantics of data, so further exten-sions are needed. There are already someinitial steps in this direction—for example,the DAML+OIL (DARPA Agent MarkupLanguage + Ontology Inference Layer)language, which adds new modeling primitives and formal semantics to RDF Schema.

The “Further Reading” sidebar containspointers to more detailed explanations ofXML and RDF and lists the URLs of theofficial homepages of XML, RDF, and theSemantic Web Activity at the W3C. Throughthose pages, you can find many projects andapplications related to these topics.

28 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

• The pages at www.w3.org/XML andwww.w3.org/RDF contain pointersto the official definitions of thelanguages that I covered in thisminitutorial.

• XML.com (www.xml.com) containstechnical introductions to both XMLand XML Schemas.

• Pierre-Antoine Champin providescomprehensive tutorial on RDF and RDF Schema at www710.

univ-lyon1.fr/~champin/rdf-tutorial.• Robin Cover maintains a compre-

hensive online reference for XMLand related techniques atwww.oasis-open.org/cover.

• The vision of the Semantic Web issketched at www.w3.org/2001/sw/Activity.

• The DAML+OIL extension to RDFSchema lives at www.daml.org/2001/03/daml+oil-index.

Further Reading

C o m i n g N e x t I s s u e

Wearable AIWearable artificial intelligence allows the use of AI in situations where computing previously was severely limited,even from palm computers. Wearable AI also promises to provide nonintrusive access to intelligent systems. This issue will spotlight leading research in this cutting-edge field.

Michel Klein is a PhD student at the Infor-mation Management Group of the Vrije Uni-versiteit in Amsterdam. His research interestsinclude ontology modeling, maintenance, andintegration, and representation and interoper-ability issues of semistructured data. Contacthim at the Faculty of Sciences, Division ofMathematics and Computer Science, VrijeUniversiteit, De Boelelaan 1081a, 1081 HVAmsterdam, Netherlands; [email protected]; www.cs.vu.nl/~mcaklein.

22-MAR-2001

E X E C U T I V E C O M M I T T E E

PURPOSE The IEEE Computer Society isthe world’s largest association of comput-ing professionals, and is the leadingprovider of technical information in thefield.

C O M P U T E RS O C I E T Y W E B S I T EThe IEEE Computer Society’s Web site, athttp://computer.org, offers informationand samples from the society’s publica-tions and conferences, as well as a broadrange of information about technicalcommittees, standards, student activities,and more.

C H A P T E R S Regular and studentchapters worldwide provide the oppor-tunity to interact with colleagues, heartechnical experts, and serve the localprofessional community.

O MBUDSMAN Members experiencingproblems—magazine delivery, member-ship status, or unresolved complaints—may write to the ombudsman at thePublications Office or send an e-mail [email protected].

AVAILABLE INFORMATIONTo obtain more information on anyof the following, contact the Publi-cations Office:

• Membership applications

• Publications catalog

• Draft standards and order forms

• Technical committee list

• Technical committee application

• Chapter start-up procedures

• Student scholarship information

• Volunteer leaders/staff directory

• IEEE senior member grade applica-tion (requires 10 years practice and significant performance in five of those 10)

To check membership status or reporta change of address, call the IEEE toll-free number, +1 800 678 4333. Directall other Computer Society-relatedquestions to the Publications Office.

P U B L I C A T I O N S A N DA C T I V I T I E SComputer. An authoritative, easy-to-read magazine containing tutorial and in-depth articles on topics across the com-puter field, plus news, conferences, cal-endar, industry trends, and productreviews.

Periodicals. The society publishes 11magazines and nine research transac-tions. Refer to membership applicationor request information as noted at left.

Conference Proceedings, Tutorial Texts, Standards Documents.The Computer Society Press publishesmore than 150 titles every year.

Standards Working Groups. Morethan 200 of these groups produce IEEEstandards used throughout the industrialworld.

Technical Committees. Thirty TCspublish newsletters, provide interactionwith peers in specialty areas, and direct-ly influence standards, conferences, andeducation.

Conferences/Education. The soci-ety holds about 100 conferences each year and sponsors many educational activities, including computing scienceaccreditation.

ME M B E R S HI P Members receive themonthly magazine COMPUTER, discounts,and opportunities to serve (all activitiesare led by volunteer members). Mem-bership is open to all IEEE members,affiliate society members, and othersinterested in the computer field.

B O A R D O F G O V E R N O R STerm Expiring 2001: Kenneth R. Anderson,Wolfgang K. Giloi, Haruhisa Ichikawa, Lowell G.Johnson, Ming T. Liu, David G. McKendry, AnnelieseAmschler Andrews

Term Expiring 2002: Mark Grant, James D. Isaak, Gene F. Hoffnagle, Karl Reed, Kathleen M. Swigger,Ronald Waxman, Akihiko Yamada

Term Expiring 2003: Fiorenza C. Albert-Howard, Manfred Broy, Alan Clements, Richard A.Kemmerer, Susan A. Mengel, James W. Moore,Christina M. Schober

Next Board Meeting: 25 May 2001, Seattle,Washington

E X E C U T I V E S T A F FActing Executive Director : ANNE MARIE KELLYPublisher: ANGELA BURGESSActing Director, Volunteer Services:MARY-KATE RADAChief Financial Officer: VIOLET S. DOANDirector, Information Technology & Services: ROBERT CAREManager, Research & Planning: JOHN C. KEATON

C O M P U T E R S O C I E T Y O F F I C E S

Headquarters Office1730 Massachusetts Ave. NW Washington, DC 20036-1992Phone: +1 202 371 0101 • Fax: +1 202 728 9614E-mail: [email protected]

Publications Office10662 Los Vaqueros Cir., PO Box 3014Los Alamitos, CA 90720-1314General Information: Phone:+1 714 8218380E-mail: [email protected] and Publication Orders:Phone: +1 800 272 6657 Fax: +1 714 821 4641E-mail: [email protected]

European Office13, Ave. de L’AquilonB-1200 Brussels, BelgiumPhone: +32 2 770 21 98 • Fax: +32 2 770 85 05E-mail: [email protected]

Asia/Pacific OfficeWatanabe Building1-4-2 Minami-Aoyama,Minato-ku,Tokyo107-0062, JapanPhone: +81 3 3408 3118 • Fax: +81 3 3408 3553E-mail: [email protected]

I E E E O F F I C E R SPresident:JOEL B. SNYDER

President-Elect:RAYMOND D. FINDLAY

Executive Director:DANIEL J. SENESE

Secretary:DAVID J. KEMP

Treasurer:DAVID A. CONNOR

VP, Educational Activities:LYLE D. FEISEL

VP, Publications Activities: MICHAEL S. ADLER

VP, Regional Activities: ANTONIO BASTOS

VP, Standards Association: DONALD C. LOUGHRY

VP, Technical Activities: ROBERT A. DENT

President, IEEE-USA: NED R. SAUTHOFF

President:BENJAMIN W. WAH *

University of IllinoisCoordinated Sci Lab1308 W Main StUrbana, IL 61801-2307Phone: +1 217 333 3516Fax: +1 217 244 [email protected]

President-Elect: WILLIS K. KING *

Past President: GUYLAINE M. POLLOCK*

VP, Educational Activities: CARL K. CHANG (1ST VP)*

VP, Conferences and Tutorials: GERALD L. ENGEL*

VP, Chapters Activities: JAMES H. CROSS †

VP, Publications: RANGACHAR KASTURI †

VP, Standards Activities: LOWELL G. JOHNSON*

VP, Technical Activities: DEBORAH K. SCHERRER (2ND VP)*

Secretary: WOLFGANG K. GILOI*

Treasurer: STEPHEN L. DIAMOND*

2000–2001 IEEE Division VDirector: DORIS L. CARVER †

2001–2002 IEEE Division VIIIDirector: THOMAS W. WILLIAMS †

Acting Executive Director: ANNE MARIE KELLY†

* voting member of the Board of Governors† nonvoting member of the Board of Governors


T h e S e m a n t i c W e b

Agents and theSemantic WebJames Hendler, University of Maryland

A t a colloquium I attended recently, a speaker described a “science fiction” vision

comprising agents running around the Web performing complex actions for

their users. The speaker argued that we are far from the day this vision would become

a reality because we don’t have the infrastructure to make it happen.

Although I agree with his assessment about infra-structure, his claim that we are “far from the day”is too pessimistic. A crucial component of this infra-structure, a standardized Web ontology language,is emerging. This article offers a few pointers to thisemerging area and shows how the ontology languages of the Semantic Web can lead directly to more powerful agent-based approaches—that is, to the realization of my colleague’s “science fic-tion” vision.

What is an ontology, really?There are a number of terms we sometimes abuse

in the AI community. These terms become evenmore confusing when we interact with other com-munities, such as Web toolkit developers, who alsoabuse them. One such term is ontology, which theOxford English Dictionary defines as “the scienceor study of being.” In AI, we usually attribute thenotion of ontology to, essentially, the specificationof a conceptualization—that is, defined terms andrelationships between them, usually in some formaland preferably machine-readable manner.1 Evenmore complicated is the relationship betweenontologies and logics. Some people treat ontologyas a subset of logic, some treat logic as a subset ofontological reasoning, and others consider the termsdisjoint.

In this article, I employ the term as it is currentlybeing used in Semantic Web circles. I define ontol-ogy as a set of knowledge terms, including thevocabulary, the semantic interconnections, and somesimple rules of inference and logic for some partic-

ular topic. For example, the ontology of cooking andcookbooks includes ingredients, how to stir andcombine the ingredients, the difference betweensimmering and deep-frying, the expectation that theproducts will be eaten or drunk, that oil is for cook-ing or consuming and not for lubrication, and soforth.

In practice, it is useful to consider more complexlogics and inference systems to be separate from an

Many challenges of

bringing communicating

multiagent systems to the

Web require ontologies.

The integration of

agent technology and

ontologies could

significantly affect the

use of Web services and

the ability to extend

programs to perform

tasks for users more

efficiently and with less

human intervention.

Trust

Proof

Logic

Ontology vocabuary

Rules

Data

Data

Self-describingdocument

XML + Name space + XML Schema

Unicode Universal resourceindicator

Digi

tal s

igna

ture

Resource DescriptionFramework + RDF Schema

Figure 1. The Semantic Web “layer cake”presented by Tim Berners-Lee at the XML 2000conference.

ontology. Figure 1, derived from a talk givenby Tim Berners-Lee at the recent XML 2000conference, shows the proposed layers of theSemantic Web with higher-level languagesusing the syntax and semantics of lower lev-els. This article focuses primarily on theontology language level and the sort of agent-based computing that ontology languagesenable. Higher levels (with complex logicsand the exchange of proofs to establish trustrelationships) will enable even more inter-esting functionality, but I’ve left those to bediscussed in other articles.

Semantic Web ontologiesThe Semantic Web, as I envision it evolv-

ing, will not primarily consist of neat ontolo-gies that expert AI researchers have carefullyconstructed. I envision a complex Web ofsemantics ruled by the same sort of anarchythat rules the rest of the Web. Instead of afew large, complex, consistent ontologiesthat great numbers of users share, I see agreat number of small ontological compo-nents consisting largely of pointers to eachother. Web users will develop these compo-nents in much the same way that Web con-tent is created.

In the next few years, almost every com-pany, university, government agency, or adhoc interest group will want their Webresources linked to ontological contentbecause of the many powerful tools that willbe available for using that content. Informa-tion will be exchanged between applications,letting programs collect and process Webcontent and exchange information freely. Ontop of this infrastructure, agent-based com-puting will become much more practical.Distributed computer programs interactingwith nonlocal Web-based resources mighteventually become the dominant way inwhich computers interact with humans andeach other. Such interaction will also be a pri-mary means of computation in the not-so-distant future.

However, for this vision to become a real-ity, a phenomenon similar to the Web’s earlydays must occur. Web users will not mark uptheir Web pages unless they perceive value indoing so, and tools to demonstrate this valuewill not be developed unless Web resourcesare marked up. To help solve this chicken-and-egg problem, DARPA is funding a set ofresearchers to both develop freely availabletools and provide significant content for thesetools to manipulate. This should demonstrateto the government and other parts of society

that the Semantic Web can be a reality.But without some killer apps showing the

great power of Web semantics, it will still bea long row to hoe. Although I don’t claim tohave all the answers, perhaps some ideas inthe remainder of this article will inspire thecreation of exciting Web-agent applications.I will develop this vision one step at a time bydescribing the creation of pages with onto-logical information, the definition of servicesin a machine-readable form, and the use oflogics and agents that provide important newcapabilities.

Markup for freeA crucial aspect of creating the Semantic

Web is to enable users who are not logic

experts to create machine-readable Web con-tent. Ideally, most users shouldn’t even needto know that Web semantics exist. Loweringmarkup’s cost isn’t enough; for many users itmust be free. Semantic markup should be aby-product of normal computer use. Muchlike current Web content, a small number oftool creators and Web ontology designerswill need to know the details, but most userswill not even know ontologies exist.

Consider any of the well-known productsfor creating online slide shows. Several ofthese products contain libraries of clippingsthat you can insert into a presentation. Soft-ware developers could mark these clippingswith pointers to ontologies. The save-as-HTML feature could include linking theseproducts to their respective ontologies. So, apresentation that had pictures of, for exam-ple, a cow and a donkey would be linked tobarnyard animals, mammals, animals, and soforth. While doing so would not guaranteeappropriate semantics—the cow might be themascot of some school or the donkey the icon

of some political party—retrieval enginescould use the markups as clues to what thepresentations contain and how they can belinked to other ones. The user simply createsa slide show, but the search tools do a betterjob of finding results.

An alternative example is a markup tooldriven by one or more ontologies. Considera page-creation tool that represents hierar-chical class relations as menus. Properties ofthe classes could be tied to various types offorms, and these made available through sim-ple Web forms. A user could thus choose froma menu to add information about a person,and then choose a relative (as opposed to afriend, professional acquaintance, and soforth) and then a daughter. The system woulduse the semantics to retrieve the properties ofdaughters specified in the ontologies and todisplay them to the user as a form to be filledout with strings (such as name) or numbers(age)—or to browse for related links (home-page), online images (photo-of), and so forth.The system would then lay these out usingappropriate Web page design tools whilerecording the relevant instance information.

Because the tool could be driven by anyontology, libraries of terms could be created(and mixed) in many different ways. Thus, asingle easy-to-use tool would allow the cre-ation of homepages (using ontologies onpeople, hobbies, and so forth), professionalpages (using ontologies relating to specificoccupations or industries), or agency-specificpages (using ontologies relating to specificfunctions). In an easy, interactive way thetool would help a user create a page andwould provide free markup. Also, mixturesof the various ontologies and forms could beeasily created, thus helping to create theSemantic Web of pages linking to many dif-ferent ontologies, as I mentioned earlier.

Incremental ontology creationNot only can pages be created with links to

numerous ontologies, but the ontologies canalso include links between them to reuse orchange terms. The notion of creating largeontologies by combining components is notunique to the Semantic Web vision.2 How-ever, the ability to link and browse ontolog-ical relations enabled by the Web’s use ofsemantics will be a powerful tool for userswho do know what ontologies are and whythey should be used.

How will it all work? Consider Mary, theWebmaster for a new business-to-consumerWeb site for an online pet shop. Browsing


The ability to link and browse

ontological relations enabled by

the Web’s use of semantics will be

a powerful tool for users who do

know what ontologies are and why

they should be used.

through a Web ontology repository (such asthe one at www.daml.org/ontologies/), shefinds that many interesting ontologies areavailable. Selecting a product ontology,Mary uses a browser to choose the variousclasses and relations that she wants toinclude in her ontology. Several of thesemight need to be further constrained depend-ing on the properties of her particular busi-ness. For example, Mary must define someof these properties for the various animalsshe will sell.

Searching further in the repository, Maryfinds a biological taxonomy that containsmany classes, such as feline, canine, mammal, andanimal. She finds that these ontologies containseveral properties relevant to her business, soshe provides links to them. She adds a newdescriptor field to animal called product shippingtype and sets it to default to the value alive (nota standard property or default in the productontology she chose to extend).

Finally, she notices that although the biological ontology contains several kinds of felines, it didn’t use the categories shewanted (popular pets, exotic pets, and soforth), so she adds these classes as subclassesof the ones in the parent ontology and definestheir properties. Saving this ontology on herWeb site, she can now use other ontology-based tools to organize and manage her Website. Mary is motivated to add the semanticsto her site by both these tools and the otherpowerful browsing and search tools that thesemantics enable.

The many ontology-based search andbrowsing tools on the Web, when pointed ather pages, can use this information to distin-guish her site from the non-ontology-basedsites that her competitors run. This makes it

easy for her to extend her site to use variousbusiness-to-business e-commerce tools thatcan exploit Web ontologies for automatedbusiness uses. In addition, she might submither ontology back into one of the reposito-ries so that others in her profession can findit and use it for their own sites. After all, thepower of the ontologies is in the sharing; themore people using common terms with her,the better.

Ontologies and servicesWeb services might be one of the most

powerful uses of Web ontologies and will bea key enabler for Web agents. Recently,numerous small businesses, particularlythose in supply chain management for busi-ness-to-business e-commerce, have been dis-cussing the role of ontologies in managingmachine-to-machine interactions. In mostcases, however, these approaches assume thatcomputer program constructors primarily useontologies to ensure that everyone agrees onterms, types, constraints, and so forth. So, theagreement is recorded primarily offline andused in Web management applications. Onthe Semantic Web, we will go much furtherthan this, creating machine-readable ontolo-gies used by “capable” agents to find theseWeb services and automate their use.

A well-known problem with the Web isthat finding the many available Web servicesis difficult. For example, when I first startedwriting this article, I wanted to send a Webgreeting card but didn’t know the name ofany companies offering such a service. Usingstandard keyword-based searches did nothelp much. The query “web greeting card”turned up many links to sites displayinggreeting cards or using the terms on their

pages. In fact, for these three keywords, sev-eral of the most common search engines didnot turn up the most popular Web greetingcard service provider in their top 20 sugges-tions. A search on “eCards” would havefound the most popular site, but I didn’t hap-pen to know this particular neologism.

As I’m finalizing this article, the searchengines are now actually finding the mostpopular site with the “web greeting card” key-words. However, if I want something morecomplex—for example, an anniversary cardfor my mother-in-law that plays “Hava Nag-ila”—I’m still pretty much out of luck. As thenumber of services grows and the specificityof our needs increases, the ability of currentsearch engines to find the most appropriateservices is strained to the limit.

Several efforts are underway to improvethis situation. Some examples are the Uni-versal Description, Discovery, and Integra-tion specification (www.uddi.org); ebXML(www.ebXML.org); and eSpeak (www.e-speak.hp.com). These efforts focus onservice advertisements. By creating a con-trolled vocabulary for service advertise-ments, search engines could find these Webservices. So, Mary’s pet site (discussedabove) might have an annotation that it pro-vides a “sell” service of object “pet,” whichwould let pet buyers find it more easily. Sim-ilarly, a Web greeting card site could regis-ter as something such as “personal service,e-mail, communications,” and a user couldmore easily get to it without knowing theterm “eCard.”

Semantic Web techniques can—and must—go much further. The first use of ontologieson the Web for this purpose is straightfor-ward. By creating the service advertisementsin an ontological language, you would beable to use the hierarchy (and propertyrestrictions) to find matches through classand subclass properties or other semanticlinks. For example, someone looking to buyroses might find florists (who sell flowers)even if no exact match served the purpose.Using description logic (or other inferentialmeans), the user could even find categoriza-tions that weren’t explicit. So, for example,specifying a search for animals that were of“size = small” and “type = friendly,” the usercould end up finding the pet shop Mary isworking for, which happens to be overflow-ing in hamsters and gerbils.

However, by using a combination of Webpointers, Web markup, and ontology lan-guages, we can do even better than just



Query Processed:• A satellite image taken yesterday at 10 AM is available on the Web at http://.…• A new satellite image, to be taken today at 10 AM, will be available for $100—click here to

authorize transfer of funds and obtain image. (You will need a valid credit card number fromone of the following providers.…)

• In an emergency situation, a Coast Guard observer plane can be sent to any location within thearea you indicate. Service Note: You will be responsible for cost of flight if the situation doesnot result in an emergency pickup. Click here for more information.

• A high-altitude observer can be sent to your location in 13 hours. Click here to initiate proce-dure. (You will need to provide US military authorization, a valid military unit code, and thename of the commanding officer. Abuse of this procedure can result in fine or imprisonment.)

• A service entitled commercial service for providing satellite images is advertised as becomingavailable in 2004. See http://… for more information.

Figure 2. The results of processing a fictitious agent-based query from a fishing vesselthat finds itself in a difficult weather situation.

putting service advertisements into ontolo-gies. By using these techniques we can alsoinclude a machine-readable description ofa service (as to how it runs) and someexplicit logic describing the consequencesof using the service. Such service descrip-tions and service logic will lead us to theintegration of agents and ontologies in someexciting ways.

Agents and servicesIn an earlier article, I described a vision of

intelligent Web agents using the analogy oftravel agents.3 Rather than doing everythingfor a user, the agents would find possibleways to meet user needs and offer the userchoices for their achievement. Much as atravel agent might give you a list of severalflights to take, or a choice of flying asopposed to taking a train, a Web agent couldoffer several possible ways to get you whatyou need on the Web.

Consider a Web-enabled method for sav-ing the doomed crew of The Perfect Storm.4

In this story, now a major motion picture, acrew of fishermen is out at sea when weatherconditions conspire to create a storm of epicproportions. For various reasons, the crew isunable to get a detailed weather map, so theymiss that the storm is developing right in theirway. Instead of avoiding it, they end up at itscenter, with tragic results.

How could Web agents have helped? As

the ship’s captain goes to call land, a wavehits and his cell phone is swept overboard.Luckily, he is a savvy Web user and hasbrought his wireless Web device with him.Checking the weather forecast from a stan-dard weather site, he determines that a stormis coming, but he does not find enough detailfor his needs. He goes to an agent-enabledgeographical server site and invokes thequery “Get me a satellite photo of this regionof the Atlantic,” and he draws a box on anappropriate map.

The system comes back a little later withthe message shown in Figure 2. Optionsrange from a picture available on the Web(possibly out of date) to other services (thatmight need special resources) and evenfuture options being announced. The captainnow chooses an option on the basis of whatavailable resources he has and what criterionhe is willing to accept. Recognizing the grav-ity of his situation, he invokes the CoastGuard option, which creates a scheduledoverflight for his GPS location. Seeing theemerging weather, the Coast Guard arrangesan emergency pickup at sea, and the sailorscan go on to fish again some other day.

Using the tools of the Semantic Web, wecan make this sort of thing routine and avail-able to anyone who needs to use a Web ser-vice for any purpose. We simply need tomake expressive service capability adver-tisements available to, and usable by, Web

agents. Figure 3 depicts a complete instanceof a potential service class. Each serviceclass has three properties: a pointer to the ser-vice advertisement as discussed above, apointer to a service description, and a declar-ative service logic. I will discuss the servicelogic later; I first want to concentrate on ser-vice descriptions.

Consider visiting a current business-to-consumer Web site, such as a book vendor.When you are ready to order, you usuallyhave to fill out a form. When you click on theSubmit button, you’re taken to another formor returned to the same form to provide miss-ing information or to fix an error. When youpass through the first form, you get directedto a new form where the same might happen,until eventually you provide the informationnecessary to complete the order. Most otherWeb services require similar interactions,whether to buy an item, get directions to alocation, or find a particular image.

The most common way to develop thesesystems is with the Common Gateway Inter-face (CGI), in which procedural code is writ-ten to invoke various functions of the Webprotocols. This code links the set of Webpages to an external resource, which meansthat the invocation procedure is representedprocedurally on the Web. Thus, an agent vis-iting the page cannot easily determine the setof information that must be provided or ana-lyze other features of the code.


Proceduralcode

Universal resource indicator

External resource



Subclass

Display-ServiceType: GeographicFormat: PhotoReturn: DisplayValue: Weather

Service-Logic TransferOccurs(#cost,Service) := Reached(ServState11),ServiceCost(#cost)

Class: WeatherService Property: Advertisement Value: Property: Description Value: Property: Logic Value:

Class:Service

Invocation-Description

Figure 3. A potential service class and its properties on the Semantic Web.

On the Semantic Web, solving this prob-lem will be easy by using a declarativeframework. Eventually you might wish touse some sort of Web-enabled logic lan-guage, but there is a much simpler way to getstarted. Figure 3 shows the invocation of theprocedural code through a simple finite-stateautomaton. An ontology language such asDAML+OIL (see the sidebar “DAML andOther Languages”) could be easily used todefine an ontology—not of services but ofthe terms needed to describe the invocationof services.

Using the example of a finite-state machine(FSM), we can see what this ontology wouldcontain. It would start with classes such asState and Link and have special subclasses suchas StartState and EndState. Constraints and prop-erties would be described to give links a headand tail, to give states a list of the links thatlead out from them, and to give states a name,URI (universal resource identifier), or otheridentifying property. This would provide abase ontology that specific types of serviceproviders could extend (much as Maryextended a biological ontology in the earlierexample), and in which specialized ontolo-gies could easily describe sets of terms forgeneral use.

For example, a “standard Web sale” couldbe defined in some service ontology com-prising a particular set of states and links. A

service provider could then simply say that aparticular part of a transaction was a standardWeb sale, which would then find the neces-sary set of links and nodes through a pointeron the Web.

Exciting capabilities arise through creat-ing such ontologies. Because these ontolo-gies are Web-enabled and declarative, agentscoming to a page containing a servicedescription could analyze the FSM foundthere and would be able to determine the par-ticular information needs for invoking theservice (and reaching an EndState). An agentthat had access to a set of information abouta user could analyze the FSM and determineif that information would be sufficient forusing this service. If not, the agent couldinform the user as to what additional infor-mation would be required or other actiontaken.

While I’ve described primarily an FSMapproach, there is no reason this couldn’t bedone using any other declarative framework.More expressive logic languages or otherdeclarative frameworks would extend thecapabilities of agents to analyze the informa-tion needs, resource requirements, and pro-cessing burden of the services so described.As these languages are linked to CGI scriptsor other procedural techniques, the agentscould perform the procedural invocation.This would let them actually run the services

(without user intervention), thus allowing avery general form of agent interaction withoff-Web resources.

Service logicsBy defining languages that let users define

structural ontologies, current projects (includ-ing the DARPA DAML initiative) are explor-ing the extension of Web ontologies to allowrules to be expressed within the languagesthemselves. These efforts vary in the com-plexity of the rules allowed, and range fromdescription logics (as in the DAML+OIL language mentioned earlier), to SHOE’s useof Horn-clause-like rules,5 and even to first-and higher-order logics in several exploratoryefforts.6–9

Whatever types of rules you use, they canbe particularly effective in connection withthe service classes, as Figure 3 shows. Theservice class contains (in addition to the ser-vice advertisement and service description)a pointer to a URI containing associated ser-vice logic. This logic can be used to expressinformation that goes beyond the informa-tion contained in the service description.

For example, returning to the agent repliesin Figure 2, consider a case in which the ser-vice offers an up-to-date picture (to be takentomorrow) at some particular cost. A rulesuch as

TransferOccurs(#cost,Service) := Reached(ServState11), ServiceCost(#cost)

might represent the information that theactual transfer of funds will occur uponreaching a particular point in the serviceinvocation (ServState11 in this case). This infor-mation would not be obvious from the statemachine itself but could be useful in severalkinds of e-commerce transactions. For exam-ple, users often leave a site without com-pleting a particular CGI script, and they can-not always know whether they’ve actuallycompleted a transaction and incurred a creditcard charge. Using service logics, such thingscould be made explicit.

More interesting transactional logicsmight also be used. Figure 4 shows a poten-tial interaction between two Web agents thatcan use proof checking to confirm transac-tions. An agent sends an annotated proof toanother agent. The annotations can be point-ers to a particular fact on the Web or to anontology where a particular rule resides. Theagent receiving this proof can analyze it,check the pointers (or decide they are trusted



You owe me $30.

Oh yeah? Prove it.

{Purchased(user1.book1.AOL);www.confirm.com#t1221122}{Priceof (book1, $30);AOL-historyDB#t29293910}{Purchase(a,b,c) & Priceof(b,d)->Owes(a,c,d);www.ont.com/prodont} The check is

in the email!

Figure 4. Agents exchanging simple proofs.

by some previous agreements), and checkthat the ontology is one it can read and agreewith. This lets the agent recognize that a validtransaction has occurred and allow the fundsto be transferred.

Such service logics could serve manyother purposes as well. For example, Het-erogeneous Agent Systems10 discusses theuse of deontic logics and agent programs formultiagent systems. These logics, tied to theappropriate service descriptions, can repre-sent what an agent can do and when it canor cannot do so. Logical descriptions of ser-vices could also be used for automatedmatchmaking and brokering, for planning aset of services that together achieve a user’sgoal, and for other capabilities currently dis-cussed (but not yet implemented) for multi-agent systems.

Agent-to-agent communicationOf course, having pages, service descrip-

tions, and agent programs that are linked tomany ontologies, which might themselvesinclude links to still other ontologies and soon, introduces some compelling issues. Fig-ure 5 shows a representation of a small pieceof this ontological Web. The small boxes rep-resent agents or other Web resources that usethe terms in Web ontologies represented bythe larger boxes. The arrows represent anymechanism that provides a mapping (full orpartial) from one ontology to another. Thismapping can be as simple as inclusion ofterms or as complex as some sort of ad hocmapping program that simply reads in termsfrom one and spits out terms of another. Thefigure shows one DAG (directed acyclicgraph) that could be taken from the muchlarger Web of ontologies.

Assuming agents are communicating witheach other using the terms in these ontolo-gies for the content terms, it is relativelystraightforward for them to communicate. By

linking to these ontologies, the agents com-mit to using the terms consistently with theusage mandated in that ontology. If the ontol-ogy specifies that a particular class has a par-ticular property and that the property hassome restriction, then each agent can assumethat the other has legal values for that prop-erty maintaining that restriction.

What is more interesting, agents that arenot using the same ontologies might still beable to communicate. If all mappings wereperfect, then obviously any agent could com-municate with any other by finding a com-mon ontology they could both map into.More likely, however, is that the ontologiesare only partially or imperfectly mapped.This would happen, for example, withMary’s pet shop site. When Mary defined hersite’s ontology as linking back to the zoo’sanimal ontology, she changed some defini-tions but left others untouched. Those termsthat were not modified, or were modified in


The modern IT world is a dynamically changing environmentwith an exponentially increasing ability to create and publishdata that rapidly swamps human abilities to process that datainto information. Agent-based computing can potentially helpus recognize complex patterns in this widely distributed, hetero-geneous, uncertain information environment. Unfortunately,this potential is hampered by the difficulty agents face in under-standing and interacting with data that is either unprocessed orin natural languages. The inability of agents to understand theconceptual aspects of a Web page, their difficulty in handlingthe semantics inherent in program output, and the complexityof fusing sensor output information—to name but a few prob-lems—truly keep the agent revolution from happening.

One potential solution is for humans to meet the com-puter halfway. By using tools to provide markup annotationsattached to data sources, we can make information availableto agents in new and exciting ways. The goal of the DARPAAgent Markup Language (DAML) program is to develop a lan-guage aimed at representing semantic relations in machine-readable ways that will be compatible with current and futureInternet technologies. The program is currently developingprototype tools to show the potential of such markups to pro-vide revolutionary capabilities that will change the way humansinteract with information.

To realize these goals, Internet markup languages must movebeyond the implicit semantic agreements inherent in XML andcommunity-specific controlled languages. DARPA is leading theway with DAML, which will be a semantic language that tiesthe information on a page to machine-readable semantics. Thelanguage must allow for communities to extend simple ontolo-gies for their own use, allowing the bottom-up design of mean-ing while allowing sharing of higher-level concepts. In addition,the language will provide mechanisms for the explicit represen-

tation of services, processes, and business models so as to allownonexplicit information (such as that encapsulated in programsor sensors) to be recognized.

DAML will provide a number of advantages over currentmarkup approaches. It will allow semantic interoperability atthe level we currently have syntactic interoperability in XML.Objects in the Web can be marked (manually or automatically)to include descriptions of information they encode, descrip-tions of functions they provide, and descriptions of data theycan produce. Doing so will allow Web pages, databases, pro-grams, models, and sensors all to be linked together by agentsthat use DAML to recognize the concepts they are looking for.If successful, information fusion from diverse sources willbecome a reality.

DARPA funds work in the development of DAML to help the US military in areas of command and control and for use in military intelligence. For example, one use of DAML is toimprove the organization and retrieval of large military infor-mation stores such as those at the US Center for Army LessonsLearned. With respect to intelligence, DAML is aimed at improv-ing the integration of information from many sources to pro-vide specific indications and warnings aimed at preventing ter-rorist attacks on military targets such as last year's attack on theUSS Cole in Yemen.

Recently, an ad hoc group of researchers formed the JointUS–EU committee on Agent Markup Languages and released anew version of DAML called DAML+OIL. This language is basedon the Resource Description Framework (www.w3.org/rdf);you can find discussion of RDF’s features on an open mailinglist archived at http://lists.w3.org/Archives/Public/www-rdf-logic. For details of the language, a repository of numerousontologies and annotated Web pages, and a full description ofDAML and related projects see www.daml.org.

DAML and Other Languages

certain restricted ways, could be mappedeven if others couldn’t. So, those ontologiesmade by combination and extension of oth-ers could, in principle, be partially mappedwithout too much trouble.

With this in mind, let’s reconsider the DAGin Figure 5. Clearly, many of these agentscould be able to find at least some terms thatthey could share with others. For agents suchas those pointing at ontologies C and E, theterms they share might be some sort of sub-set. In this case the agent at E might be ableto use only some of the terms in C (those thatwere not significantly changed when E wasdefined). Other agents, such as the ones point-ing at F and G, might share partial terms fromanother ontology that they both changed (D inthis case). In fact, all of the agents might sharesome terms with all the others, although thismight take several mappings (and thus theremight be very few common terms, if any, insome cases).

The previous discussion is purposelyvague regarding what these mappings are andhow they work. For certain kinds of restrictedmappings, we might be able to obtain someinteresting formal results. For example, if allmappings are inclusion links—that is, thelower ontology includes all the terms fromthe upper one in Figure 5—and we can finda rooted DAG among a set of agents, then wecould guarantee that all those agents willshare some terms with all others (although, inthe worst case, some might only share theterms from the uppermost ontology). If themappings are more ad hoc—they might, forexample, be some sort of procedural mapsdefined by hand—we might lose provableproperties but gain power or efficiency.

The research issues inherent in such ontol-ogy mappings are quite interesting and chal-lenging. Two agents that communicate oftenmight want to have maximal mappings oreven a merged ontology. Two agents that aresimply sending a single message (such as theinvocation of an online service) might wantsome sort of quick on-the-fly translation lim-ited to the terms in a particular message.Another approach might be to use very largeontologies, such as CYC,11 to infer mappingterms between agents in other ontologies.The possibilities are endless and are anotherexciting challenge for researchers interestedin bringing agents to the Semantic Web.

Idid not intend this article to be a compre-hensive technical tome. Rather, I hope that

I have convinced you that several strands ofresearch in AI, Web languages, and multi-agent systems can be brought together inexciting and interesting ways.

Many of the challenges inherent in bring-ing communicating multiagent systems to theWeb require ontologies of the type beingdeveloped in DARPA’s DAML program andelsewhere. What is more important, the inte-gration of agent technology and ontologiesmight significantly affect the use of Web ser-vices and the ability to extend programs toperform tasks for users more efficiently andwith less human intervention.

Unifying these research areas and bring-ing to fruition a Web teeming with complex,intelligent agents is both possible and prac-tical, although a number of research chal-lenges still remain. The pieces are comingtogether, and thus the Semantic Web ofagents is no longer a science fiction future.It is a practical application on which to focuscurrent efforts.

AcknowledgmentsThis paper benefited from reviews by a wide

number of early readers. I especially thank OliverSelfridge, who offered a comprehensive review,including the addition of several paragraphs. I alsothank David Ackley, Tim Berners-Lee, Dan Brick-ley, Dan Connolly, Jeff Heflin, George Cybenko,Ora Lassila, Deborah McGuinness, Sheila Mc-Ilraith, Frank van Harmelen, Dieter Fensel, and



Web sitesW3C Semantic Web Activity: www.w3.org/2001/swThe DAML project: www.daml.orgThe SHOE project: www.cs.umd.edu/projects/plus/SHOEThe Semantic Web Community Portal: www.semanticweb.org

ArticlesJ. Heflin, J. Hendler, and S. Luke, “Reading between the Lines: Using SHOE to

Discover Implicit Knowledge from the Web,” Proc. AAAI-98 Workshop AI andInformation Integration, AAAI Press, Menlo Park, Calif., 1998, www.cs.umd.edu/projects/plus/SHOE/pubs/shoe-aaai98.ps.

S. McIlraith, “Modeling and Programming Devices and Web Agents,” to be pub-lished in Proc. NASA Goddard Workshop Formal Approaches to Agent-Based Sys-tems, Springer-Verlag, New York.

F. Zini and L. Sterling, “Designing Ontologies for Agents,” Proc. Appia-Gulp-Prode 99: Joint Conf. Declarative Programming, 1999, pp. 29–42.

For Further Reading

Uses

A

Uses

Uses

Uses

UsesUses

Uses

E

Uses

B

F

D

C

G

Figure 5. Mappings between agents and the ontologies they use.

many participants in the CoABS, DAML, andTASK DARPA initiatives who offered commentson earlier drafts. Finally, I am indebted to ananonymous reviewer who, shall we say, wasn’timpressed by an earlier version of this article anddemanded copious changes. I made many of thesechanges, which improved the article greatly.

References1. T.R. Gruber, “A Translation Approach to

Portable Ontologies,” Knowledge Acquisition,vol. 5, no. 2, 1993, pp. 199–220.

2. P. Clark and B. Porter, “Building ConceptRepresentations from Reusable Compo-nents,” Proc. 14th Nat’l Conf. Artificial Intel-ligence (AAAI-97), MIT Press, Cambridge,Mass., 1997, pp. 369–376.

3. J. Hendler, “Is There an Intelligent Agent inYour Future?” Nature, 11 Mar. 1999, www.nature.com/nature/webmatters/agents/agents.html (current 19 Mar. 2001).

4. S. Junger, The Perfect Storm: A True Story ofMen against the Sea, W.W. Norton and Co.,London, 1997.

5. J. Heflin and J. Hendler, “Dynamic Ontolo-gies on the Web,” Proc. 17th Nat’l Conf. Arti-ficial Intelligence (AAAI 2000), MIT Press,

Cambridge, Mass., 2000, pp. 443–449.

6. A.W. Appel and E.W. Felten, “Proof-Carrying Authentication,” Proc. 6th ACM Conf.Computer and Communications Security,ACMPress, New York, 1999; www.cs.princeton.edu/~appel/papers/fpcc.pdf.

7. D. Fensel et al., “The Component Model ofUPML in a Nutshell,” Proc. 1st Working IFIPConf. Software Architecture (WICSA 1),Kluwer Academic Publishers, 1999, ftp.aifb.uni-karlsruhe.de/pub/mike/dfe/paper/upml.ifip.pdf.

8. D. Fensel et al., “OIL in a Nutshell,” Proc.12th European Workshop Knowledge Acqui-sition, Modeling, and Management (EKAW-00), Springer-Verlag, New York, 2000; www.few.vu.nl/~frankh/postscript/EKAW00.pdf.

9. M. Genesereth et al., Knowledge InterchangeFormat Version 3.0 Reference Manual, http://logic.stanford.edu/kif/Hypertext/kif-manual.html.

10. V.S. Subrahmanian et al., Heterogeneous AgentSystems, MIT Press, Cambridge, Mass., 2000.

11. D. Lenat and R. Guha, Building Large Knowl-edge-Based Systems: Representation and Infer-ence in the CYC Project, Addison-Wesley,Reading, Mass., 1990.


T h e A u t h o rJames Hendler is theChief Scientist ofDARPA’s InformationSystems Office andthe program managerresponsible for agent-based computing. Heis on leave from theUniversity of Mary-

land where he is a professor and head of boththe Autonomous Mobile Robots Laboratory andthe Advanced Information Technology Labora-tory. He has joint appointments in the Depart-ment of Computer Science, the Institute forAdvanced Computer Studies, the Institute forSystems Research, and is also an affiliate of theElectrical Engineering Department. He receiveda PhD in artificial intelligence from Brown Uni-versity. Hendler received a 1995 Fulbright Foun-dation Fellowship, is a Fellow of the AmericanAssociation for Artificial Intelligence, and is amember of the US Air Force Science AdvisoryBoard. Contact him at [email protected];www.cs.umd.edu/~hendler.

IEEE Intelligent Systems seeks papers on allaspects of artificial intelligence, focusing on the

development of the latest research into practical,fielded applications. Papers should range from3,000 to 7,500 words, including figures, which

each count as 250 words.

Submit one double-spaced copy and a cover letter or e-mail to

Magazine AssistantIEEE Intelligent Systems

10662 Los Vaqueros CirclePO Box 3014

Los Alamitos, CA 90720-1314phone +1 714 821 8380; fax +1 714 821 4010

[email protected].

For author guidelines, seehttp://computer.org/intelligent/author.htm

2001

Call for PapersCall for Papers



OIL: An OntologyInfrastructure for the Semantic WebDieter Fensel and Frank van Harmelen, Vrije Universiteit, AmsterdamIan Horrocks, University of Manchester, UKDeborah L. McGuinness, Stanford UniversityPeter F. Patel-Schneider, Bell Laboratories

R esearchers in artificial intelligence first developed ontologies to facilitate knowl-

edge sharing and reuse. Since the beginning of the 1990s, ontologies have

become a popular research topic, and several AI research communities—including

knowledge engineering, natural language processing, and knowledge representation—

have investigated them. More recently, the notion ofan ontology is becoming widespread in fields suchas intelligent information integration, cooperativeinformation systems, information retrieval, elec-tronic commerce, and knowledge management.Ontologies are becoming popular largely because ofwhat they promise: a shared and common under-standing that reaches across people and applicationsystems.

Currently, ontologies applied to the World WideWeb are creating the Semantic Web.1 Originally, theWeb grew mainly around HTML, which provides astandard for structuring documents that browsers cantranslate in a canonical way to render those docu-ments. On the one hand, HTML’s simplicity helpedspur the Web’s fast growth; on the other, its simplic-ity seriously hampered more advanced Web appli-cations in many domains and for many tasks. Thisled to XML (see Figure 1), which lets developersdefine arbitrary domain- and task-specific extensions(even HTML appears as an XML application—XHTML).

XML is basically a defined way to provide a seri-alized syntax for tree structures—it is an importantfirst step toward building a Semantic Web, where

application programs have direct access to datasemantics. The resource description framework2

has taken an important additional step by defininga syntactical convention and a simple data modelfor representing machine-processable data seman-tics. RDF is a standard for the Web metadata theWorld Wide Web Consortium (www.w3c.org/rdf)develops, and it defines a data model based ontriples: object, property, and value. The RDFSchema3 takes a step further into a richer represen-tation formalism and introduces basic ontologicalmodeling primitives into the Web. With RDFS, wecan talk about classes, subclasses, subproperties,domain and range restrictions of properties, and soforth in a Web-based context. We took RDFS as astarting point and enriched it into a full-fledgedWeb-based ontology language called OIL.4 Weincluded these aspects:

• A more intuitive choice of some of the modelingprimitives and richer ways to define concepts andattributes.

• The definition of a formal semantics for OIL.• The development of customized editors and infer-

ence engines to work with OIL.

Ontologies play a

major role in

supporting information

exchange across

various networks. A

prerequisite for such a

role is the development

of a joint standard for

specifying and

exchanging ontologies.

The authors present

OIL, a proposal for

such a standard.

Ontologies: A revolution for information access andintegration

Many definitions of ontologies have sur-faced in the last decade, but the one that inour opinion best characterizes an ontology’sessence is this: “An ontology is a formal,explicit specification of a shared conceptual-ization.”5 In this context, conceptualizationrefers to an abstract model of some phenom-enon in the world that identifies that phe-nomenon’s relevant concepts. Explicit meansthat the type of concepts used and the con-straints on their use are explicitly defined, andformal means that the ontology should bemachine understandable. Different degreesof formality are possible. Large ontologiessuch as WordNet (www.cogsci.princeton.edu/~wn) provide a thesaurus for over100,000 terms explained in natural language.On the other end of the spectrum is CYC(www.cyc.com), which provides formalaxiomating theories for many aspects of com-monsense knowledge. Shared reflects thenotion that an ontology captures consensualknowledge—that is, it is not restricted tosome individual but is accepted by a group.

The three main application areas of ontol-ogy technology are knowledge management,Web commerce, and electronic business.

Knowledge managementKM is concerned with acquiring, maintain-

ing, and accessing an organization’s knowl-edge. Its purpose is to exploit an organization’sintellectual assets for greater productivity, newvalue, and increased competitiveness. Owingto globalization and the Internet’s impact,many organizations are increasingly geo-graphically dispersed and organized aroundvirtual teams. With the large number of onlinedocuments, several document managementsystems have entered the market. However,these systems have weaknesses:

• Searching information: Existing keyword-based searches retrieve irrelevant informa-tion that uses a certain word in a differentcontext; they might miss information whendifferent words about the desired contentare used.

• Extracting information: Current humanbrowsing and reading requires extractingrelevant information from informationsources. Automatic agents lack the com-monsense knowledge required to extractsuch information from textual representa-tions, and they fail to integrate informa-

tion spread over different sources.• Maintaining: Sustaining weakly struc-

tured text sources is difficult and time-consuming when such sources becomelarge. Keeping such collections consis-tent, correct, and up to date requires amechanized representation of semanticsand constraints that can help detectanomalies.

• Automatic document generation: AdaptiveWeb sites that enable dynamic reconfigu-ration according to user profiles or otherrelevant aspects could prove very useful.The generation of semistructured infor-mation presentations from semistructureddata requires a machine-accessible repre-sentation of the semantics of these infor-mation sources.

Using ontologies, semantic annotationswill allow structural and semantic definitionsof documents. These annotations could pro-vide completely new possibilities: intelligentsearch instead of keyword matching, queryanswering instead of information retrieval,document exchange between departmentsthrough ontology mappings, and definitionsof views on documents.

Web commerceE-commerce is an important and growing

business area for two reasons. First, e-com-merce extends existing business models—itreduces costs, extends existing distributionchannels, and might even introduce new dis-tribution possibilities. Second, it enables com-pletely new business models and gives thema much greater importance than they hadbefore. What has up to now been a peripheralaspect of a business field can suddenly receiveits own important revenue flow.

Examples of business field extensions areonline stores; examples of new businessfields are shopping agents and online mar-ketplaces and auction houses that turn com-parison shopping into a business with itsown significant revenue flow. The advan-tages of online stores and their success sto-ries have led to a large number of shoppingpages. The new task for customers is to finda shop that sells the product they’re seek-ing, getting it in the desired quality, quan-tity, and time, and paying as little as possi-ble for it. Achieving these goals throughbrowsing requires significant time and onlycovers a small share of the actual offers.Shopbots visit several stores, extract prod-uct information, and present it to the cus-

tomer as an instant market overview. Theirfunctionality is provided through wrappers,which use keyword search to find productinformation together with assumptions onregularities in presentation format and textextraction heuristics. This technology hastwo severe limitations:

• Effort: Writing a wrapper for each onlinestore is time-consuming, and changes instore presentation or organization increasemaintenance.

• Quality: The extracted product informa-tion is limited (it contains mostly priceinformation), error-prone, and incomplete.For example, a wrapper might extract theproduct price, but it usually misses indi-rect costs such as shipping.

Most product information is provided innatural language; automatic text recognitionis still a research area with significantunsolved problems. However, the situationwill drastically change in the near futurewhen standard representation formalisms fordata structure and semantics are available.Software agents will then understand prod-uct information. Meta online stores will growwith little effort, which will enable completemarket transparency in the various dimen-sions of the diverse product properties.Ontology mappings, which translate differentproduct descriptions, will replace the low-level programming of wrappers, which isbased on text extraction and format heuris-tics. An ontology will describe the variousproducts and help navigate and search auto-matically for the required information.

Electronic business E-commerce in the business-to-business

field (B2B) is not new—initiatives to sup-port it in business processes between dif-ferent companies existed in the 1960s. Toexchange business transactions electroni-cally, sender and receiver must agree on a


DAML-O OIL

RDFS

RDF

XMLHTML

XHTML

Figure 1. The layer language model forthe Web.

standard (a protocol for transmitting con-tent and a language for describing content).A number of standards arose for this pur-pose—one of them is the UN initiative,Electronic Data Interchange for Adminis-tration, Commerce, and Transport (Edifact).In general, the automation of business trans-actions has not lived up to the propagan-dists’ expectations, partly because of theserious shortcomings of approaches such asEdifact: It is a procedural and cumbersomestandard, making the programming of busi-ness transactions expensive and error-prone,and it results in large maintenance efforts.Moreover, the exchange of business dataover extranets is not integrated with otherdocument exchange processes—Edifact isan isolated standard.

Using the Internet’s infrastructure forbusiness exchange will significantly im-prove this situation. Standard browsers canrender business transactions and transpar-ently integrate them into other documentexchange processes in intranet and Internetenvironments. However, the fact that HTMLdoes not provide a means for presenting richsyntax and data semantics hampers this.XML, which is designed to close this gapin current Internet technology, drasticallychanges the situation. We can model B2Bcommunication and data exchange with thesame means available for other dataexchange processes, we can render transac-tion specifications on standard browsers,and maintenance is cheap. However,although XML provides a standard serial-ized syntax for defining data structure andsemantics, it does not provide standard datastructures and terminologies to describebusiness processes and exchanged products.Therefore, XML-based e-commerce will

need ontologies in two important ways:

• Standard ontologies must cover the vari-ous business areas. In addition to officialstandards, vertical marketplaces (Internetportals) could generate de facto stan-dards—if they can attract significantshares of a business field’s online trans-actions. Examples include Dublin Core,Common Business Library (CBL), Com-merce XML (cXML), ecl@ss, OpenApplications Group Integration Specifi-cation (OAGIS), Open Catalog Format(OCF), Open Financial Exchange (OFX),Real Estate Transaction Markup Lan-guage (RETML), RosettaNet, UN/SPSC(see www.diffuse.org), and UCEC.

• Ontology-based translation services mustlink different data structures in areaswhere standard ontologies do not exist orwhere a particular client needs a transla-tion from his or her terminology into thestandard. This translation service mustcover structural and semantic as well aslanguage differences (see Figure 2).

Ontology-based trading will significantlyextend the degree to which data exchange isautomated and will create completely new busi-ness models in participating market segments.

Why OIL?Effective, efficient work with ontologies

requires support from advanced tools. Weneed an advanced ontology language toexpress and represent ontologies. This lan-guage must meet three requirements:

• It must be highly intuitive to the humanuser. Given the success of the frame-basedand object-oriented modeling paradigm,

an ontology should have a frame-like lookand feel.

• It must have a well-defined formal seman-tics with established reasoning propertiesto ensure completeness, correctness, andefficiency.

• It must have a proper link with existingWeb languages such as XML and RDF toensure interoperability.

Many of the existing languages such asCycL,6 KIF,7 and Ontolingua8 fail. However,OIL9 matches these criteria and unifies thethree important aspects that different com-munities provide: epistemologically richmodeling primitives as provided by the framecommunity, formal semantics and efficientreasoning support as provided by descriptionlogics, and a standard proposal for syntacti-cal exchange notations as provided by theWeb community.

Frame-based systemsThe central modeling primitives of pred-

icate logic are predicates. Frame-based andobject-oriented approaches take a differentviewpoint. Their central modeling primi-tives are classes (or frames) with certainproperties called attributes. These attributesdo not have a global scope but apply onlyto the classes for which they are defined—we can associate the “same” attribute (thesame attribute name) with different rangeand value restrictions when defined for dif-ferent classes. A frame provides a contextfor modeling one aspect of a domain.Researchers have developed many otheradditional refinements of these modelingconstructs, which have led to this modelingparadigm’s incredible success.

Many frame-based systems and lan-guages have emerged, and, renamed asobject orientation, they have conquered thesoftware engineering community. OILincorporates the essential modeling primi-tives of frame-based systems—it is basedon the notion of a concept and the defini-tion of its superclasses and attributes. Rela-tions can also be defined not as an attributeof a class but as an independent entity hav-ing a certain domain and range. Likeclasses, relations can fall into a hierarchy.

Description logics DL describes knowledge in terms of con-

cepts and role restrictions that can auto-matically derive classification taxonomies.Knowledge representation research’s main



Productcatalogue

Productcatalogue

Business Business

Translationserver

Orderinformation

Bestell-information

<Auto> <Name>Daimler 230 SE</Name> <Preis>40.000 DM</Preis></Auto>

<product> <type>Car</type> <name>Daimler 230 SE </name> <price> 23,000 $</price></product>

Figure 2. The translation of structure, semantics, and language.

thrust is to provide theories and systems forexpressing structured knowledge and foraccessing and reasoning with it in a princi-pled way. In spite of the discouraging theo-retical complexity of the results, there arenow efficient implementations for DL lan-guages, which we explain later. OIL inher-its from DL its formal semantics and theefficient reasoning support.

Web standards: XML and RDF Modeling primitives and their semantics

are one aspect of an ontology language, butwe still have to decide about its syntax.Given the Web’s current dominance andimportance, we must formulate a syntax ofan ontology exchange language with exist-ing Web standards for information repre-sentation. First, OIL has a well-defined syn-tax in XML based on a document typedefinition and an XML Schema definition.Second, OIL is an extension of RDF andRDFS. With regard to ontologies, RDFSprovides two important contributions: a stan-dardized syntax for writing ontologies anda standard set of modeling primitives suchas instance-of and subclass-of relationships.

OIL’s layered architectureA single ontology language is unlikely to

fulfill all the needs of the Semantic Web’slarge range of users and applications. Wetherefore organized OIL as a series of ever-increasing layers of sublanguages. Eachadditional layer adds functionality and com-plexity to the previous one. Agents (humansor machines) that can only process a lowerlayer can still partially understand ontolo-gies expressed in any of the higher layers. Afirst and very important application of thisprinciple is the relation between OIL andRDFS. As Figure 3 shows, core OIL coin-cides largely with RDFS (with the excep-tion of RDFS’s reification features). Thismeans that even simple RDFS agents canprocess OIL ontologies and pick up as muchof their meaning as possible with their lim-ited capabilities.

Standard OIL aims to capture the neces-sary mainstream modeling primitives thatprovide adequate expressive power and arewell understood, thus precisely specifyingthe semantics and making complete infer-ence viable.

Instance OIL includes a thorough individ-ual integration. Although the previouslayer—Standard OIL—includes modelingconstructs that specify individual fillers in

term definitions, Instance OIL includes afull-fledged database capability.

Heavy OIL will include additional repre-sentational (and reasoning) capabilities. Amore expressive rule language and metaclassfacilities seem highly desirable. We willdefine these extensions of OIL in coopera-tion with the DAML (DARPA Agent MarkupLanguage; www.daml.org) initiative for arule language for the Web.

OIL’s layered architecture has threeadvantages:

• An application is not forced to work witha language that offers significantly moreexpressiveness and complexity than isneeded.

• Applications that can only process a lowerlevel of complexity can still catch some ofan ontology’s aspects.

• An application that is aware of a higherlevel of complexity can still understandontologies expressed in a simpler ontol-ogy language.

Defining an ontology language as anextension of RDFS means that every RDFSontology is a valid ontology in the new lan-guage (an OIL processor will also understandRDFS). However, the other direction is alsopossible: Defining an OIL extension asclosely as possible to RDFS allows maximalreuse of existing RDFS-based applicationsand tools. However, because the ontologylanguage usually contains new aspects (andtherefore a new vocabulary, which an RDFSprocessor does not know), 100 percent com-patibility is impossible. Let’s look at anexample. The following OIL expressiondefines herbivore as a class, which is a sub-class of animal and disjunct to all carnivores:

<rdfs:Class rdf:ID=”herbivore”><rdf:type

rdf:resource=”http://www.ontoknowledge.org/oil/RDFS-

schema/#DefinedClass”/><rdfs:subClassOf rdf:resource=”#animal”/><rdfs:subClassOf>

<oil:NOT><oil:hasOperand rdf:resource=”

#carnivore”/></oil:NOT>

</rdfs:subClassOf></rdfs:Class>

An application limited to pure RDFS canstill capture some aspects of this definition:

<rdfs:Class rdf:ID=”herbivore”><rdfs:subClassOf rdf:resource=”#animal”/><rdfs:subClassOf>

…</rdfs:subClassOf>

</rdfs:Class>

It encounters that herbivore is a subclass ofanimal and a subclass of a second class, whichit cannot understand properly. This seems topreserve complicated semantics for simplerapplications.

An illustration of the OILmodeling primitive

An OIL ontology is itself annotated withmetadata, starting with such things as title,creator, creation date, and so on. OIL followsthe W3C Dublin Core Standard on biblio-graphical meta date for this purpose.

Any ontology language’s core is its hier-archy of class declarations, stating, for exam-ple, that DeskJet printers are a subclass ofprinters. We can declare classes as defined,which indicates that the stated properties arenot only necessary but also sufficient condi-tions for class membership. Instead of usingsingle types in expressions, we can combineclasses in logical expressions indicatingintersection, union, and complement ofclasses.

We can declare slots (relations betweenclasses) together with logical axioms, statingwhether they are functional (having at mostone value), transitive, or symmetric, and stat-ing which (if any) slots are inverse. We canstate range restrictions as part of a slot decla-ration as well as the number of distinct valuesthat a slot may have. We can further restrictslots by value-type or has-value restrictions. Avalue-type restriction demands that everyvalue of the property must be of the stated


Heavy OIL(possible future extensions)

Standard OIL

Core OIL(Standard OIL ^ RDFS)

Instance OIL(Standard OIL + RDFS) RDFS

Reification

Figure 3. OIL’s layered language model.



type; has-value restrictions require the slot tohave at least values from the stated type.

A crucial aspect of OIL is its formalsemantics.10 An OIL ontology is given a for-mal semantics by mapping each class into aset of objects and each slot into a set of pairsof objects. This mapping must obey the con-straints specified by the definitions of theclasses and slots. We omit the details of this

formal semantics, but it must exist and beconsulted whenever necessary to resolve dis-putes about the meaning of language con-structions. It is an ultimate reference pointfor OIL applications.

Figure 4 shows a very simple example ofan OIL ontology provided by SemanticEdge(www.interprice.com). It illustrates OIL’smost basic constructs.

This defines a number of classes andorganizes them in a class hierarchy (forexample, HPProduct is a subclass of Product).Various properties (or slots) are defined,together with the classes to which theyapply (such as a Price is a property of anyProduct, but a PrintingResolution can only bestated for a Printer, an indirect subclass ofProduct). For certain classes, these proper-ties have restricted values (for example, theprice of any HPLaserJet1100se is restrictedto $479). In OIL, we can also combineclasses by using logical expressions—forexample, an HPPrinter is both an HPProductand a Printer (and consequently inherits theproperties from both classes).

OIL toolsOIL has strong tool support in three areas:

• ontology editors, to build new ontologies;• ontology-based annotation tools, to link

unstructured and semistructured informa-tion sources with ontologies; and

• reasoning with ontologies, which enablesadvanced query-answering services, sup-ports ontology creation, and helps mapbetween different ontologies.

Ontology editorsOntology editors help human knowledge

engineers build ontologies—they support thedefinition of concept hierarchies, the defini-tion attributes for concepts, and the defini-tion of axioms and constraints. They mustprovide graphical interfaces and conform toexisting standards in Web-based softwaredevelopment. They enable the inspecting,browsing, codifying, and modifying ofontologies, and they support ontology devel-opment and maintenance tasks. Currently,two editors for OIL are available, and a thirdis under development:

• OntoEdit (see Figure 5) is an ontology-engineering environment developed at theKnowledge Management Group of theUniversity of Karlsruhe, Institute AIFB(http://ontoserver.aifb.uni-karlsruhe.de/

ontoedit). Currently, OntoEdit supportsFrame-Logic, OIL, RDFS, and XML. It iscommercialized from Ontoprise (www.ontoprise.de).

• OILed is a freely available and customizededitor for OIL implemented by the Uni-versity of Manchester and sponsored bythe Vrije Universiteit, Amsterdam, andSemanticEdge (see http://img.cs.man.ac.uk/oil). OILed aims to provide a simplefreeware editor that demonstrates—andstimulates interest in—OIL. OILed is notintended to be a full ontology developmentenvironment—it will not actively supportthe development of large-scale ontologies,the migration and integration of ontolo-gies, versioning, argumentation, and manyother activities that are involved in ontol-ogy construction. Rather, it is a NotePadfor ontology editors that offers just enoughfunctionality to let users build ontologiesand demonstrate how to check them forconsistency.

• Protégé11 lets domain experts build knowl-edge-based systems by creating and mod-ifying reusable ontologies and problem-solving methods (see www.smi.stanford.edu/projects/protege). Protégé generatesdomain-specific knowledge acquisitiontools and applications from ontologies.More than 30 countries have used it. It isan ontology editor that can define classesand class hierarchy, slots and slot-valuerestrictions, and relationships betweenclasses and properties of these relation-ships. The instances tab is a knowledgeacquisition tool that can acquire instancesof the classes defined in the ontology. Pro-tégé, built at Stanford University, currentlysupports RDF—work on extending it toOIL is starting.

Ontology-based annotation tools Ontologies can describe large instance

populations. In OIL’s case, two tools cur-rently aid such a process. First, we can derivean XML DTD and an XML Schema defini-tion from an ontology in OIL. Second, wecan derive an RDF and RDFS definition forinstances from OIL. Both provide means toexpress large volumes of semistructuredinformation as instance information in OIL.More details appear elsewhere.4,12,13

Reasoning with ontologies: Instanceand schema inferences

Inference engines for ontologies can rea-son about an ontology’s instances and

class-def Productslot-def Price

domain Productslot-def ManufacturedBy

domain Productclass-def PrintingAndDigitalImagingProduct

subclass-of Productclass-def HPProduct

subclass-of Productslot-constraint ManufacturedBy

has-value “Hewlett Packard”class-def Printer

subclass-of PrintingAndDigitalImagingProductslot-def PrinterTechnology

domain Printerslot-def Printing Speed

domain Printerslot-def PrintingResolution

domain Printerclass-def PrinterForPersonalUse

subclass-of Printerclass-def HPPrinter

subclass-of HPProduct and Printerclass-def LaserJetPrinter

subclass-of Printerslot-constraint PrintingTechnology

has-value “Laser Jet”class-def HPLaserJetPrinter

subclass-of LaserJetPrinter and HPProductclass-def HPLaserJet1100Series

subclass-of HPLaserJetPrinter and PrinterForPersonalUse

slot-constraint PrintingSpeedhas-value “8 ppm”

slot-constraint PrintingResolutionhas-value “600 dpi”

class-def HPLaserJet1100sesubclass-of HPLaserJet1100Seriesslot-constraint Price

has-value “$479”class-def HPLaserJet1100xi

subclass-of HPLaserJet1100Seriesslot-constraint Price

has-value “$399”

Figure 4. A small printer ontology in OIL.

schema definition. For example, they canautomatically derive the right position of anew concept in a given concept hierarchy.Such reasoners help build ontologies anduse them for advanced information accessand navigation. OIL uses the FaCT (FastClassification of Terminologies, www.cs.man.ac.uk/~horrocks/FaCT) system to pro-vide reasoning support for ontology design,integration, and verification. FaCT is a DLclassifier that can provide consistencychecking in modal and other similar logics.FaCT’s most interesting features are itsexpressive logic, its optimized tableauximplementation (which has now become thestandard for DL systems), and its Corba-based client–server architecture. FaCT’soptimizations specifically aim to improvethe system’s performance when classifyingrealistic ontologies. This results in perfor-mance improvements of several orders ofmagnitude compared with older DL sys-tems. This performance improvement isoften so great that it is impossible to mea-sure precisely because nonoptimized sys-tems are virtually nonterminating withontologies that FaCT can easily deal with.14

For example, for a large medical terminol-ogy ontology developed in the GALEN pro-ject,15 FaCT can check the consistency ofall 2,740 classes and determine the com-plete class hierarchy in approximately 60seconds of CPU (450-MHz Pentium III)time. FaCT can be accessed through a Corbainterface.

Applications of OILEarlier, we sketched three application

areas for ontologies: knowledge manage-ment, Web commerce, and e-business. Notsurprisingly, we find applications of OIL inall three areas. On-To-Knowledge (www.ontoknowledge.org)16 extends OIL to a full-fledged environment for knowledge man-agement in large intranets and Web sites.Unstructured and semistructured data is auto-matically annotated, and agent-based userinterface techniques and visualization toolshelp users navigate and query the informa-tion space. Here, On-To-Knowledge contin-ues a line of research that began withSHOE17 and Ontobroker:18 using ontologiesto model and annotate the semantics of infor-mation resources in a machine-processablemanner. On-To-Knowledge is carrying outthree industrial case studies to evaluate thetool environment for ontology-based knowl-edge management.

Swiss Life: Organizational memory Swiss Life19 (www.swisslife.ch) imple-

ments an intranet-based front end to anorganizational memory with OIL. The start-ing point is the existing intranet informa-tion system, called ZIS, which has consid-erable drawbacks. Its great flexibilityallows for its evolution with actual needs,but this also makes finding certain infor-mation difficult. Search engines help onlymarginally. Clearly, formalized knowledgeis connected with weakly structured back-ground knowledge here—experience showsthat this is extremely bothersome and error-prone to maintain. The only way out is toapply content-based information access sothat we no longer have a mere collection ofWeb pages but a full-fledged informationsystem that we can rightly call an organi-zational memory.

British Telecom: Call centersCall centers are an increasingly impor-

tant mechanism for customer contact inmany industries. What will be required inthe future is a new philosophy in customerinteraction design. Every transaction shouldemphasize the uniqueness of both the cus-tomer and the customer service person—this requires effective knowledge manage-ment (see www.bt.com/innovations), in-cluding knowledge about the customer andabout the customer service person, so thatcustomers are directed to the correct personin a meaningful and timely way. Some ofBT’s call centers are targeted to identifyopportunities for effective knowledge man-agement. More specifically, call centeragents tend to use a variety of electronicsources for information when interactingwith customers, including their own spe-cialized systems, customer databases, theorganization’s intranet, and, perhaps mostimportant, case bases of best practices. OILprovides an intuitive front-end tool to these

heterogeneous information sources to en-sure smooth transfer to others.

EnerSearch: Virtual enterpriseEnerSearch is a virtual organization

researching new IT-based business strate-gies and customer services in deregulatedenergy markets (www.enersearch.se).20

EnerSearch is a knowledge creation com-pany—knowledge that must transfer to itsshareholders and other interested parties.Its Web site is one of the mechanisms forthis, but finding information on certain top-ics is difficult—the current search enginesupports free-text search rather than con-tent-based search. So, EnerSearch appliesthe OIL toolkit to enhance knowledgetransfer to researchers in the virtual orga-nization in different disciplines and coun-tries and specialists from shareholdingcompanies interested in getting up-to-dateR&D information.

O IL has several advantages: it is prop-erly grounded in Web languages such

as XML Schemas and RDFS, and it offersdifferent levels of complexity. Its inner lay-ers enable efficient reasoning support basedon FaCT, and it has a well-defined formalsemantics that is a baseline requirement forthe Semantic Web’s languages. Regarding itsmodeling primitives, OIL is not just anothernew language but reflects certain consensusin areas such as DL and frame-based sys-tems. We could only achieve this by includ-ing a large group of scientists in OIL’s devel-opment. OIL is also a significant source ofinspiration for the ontology language


Figure 5. A screen shot of OntoEdit.

DAML+OIL (www.cs.man.ac.uk/~horrocks/DAML-OIL), developed through the DAMLinitiative. The next step is to start on a W3Cworking group on the Semantic Web, takingDAML+OIL as a starting point.

Defining a proper language is an impor-tant step to expanding the Semantic Web.Developing new tools, architectures, andapplications is the real challenge that willfollow.

AcknowledgmentsWe thank Hans Akkermans, Sean Bechhofer,

Jeen Broekstra, Stefan Decker,Ying Ding, MichaelErdmann, Carole Goble, Michel Klein, AlexanderMädche, Enrico Motta, Borys Omelayenko, Stef-fen Staab, Guus Schreiber, Lynn Stein, HeinerStuckenschmidt, and Rudi Studer, all of whomwere involved in OIL’s development.

References

1. T. Berners-Lee, Weaving the Web, Orion Busi-ness Books, London, 1999.

2. O. Lassila and R. Swick, Resource Descrip-tion Framework (RDF) Model and SyntaxSpecification, W3C Recommendation, WorldWide Web Consortium, Boston, 1999, www.w3.org/TR/REC-rdf-syntax (current 6 Dec.2000).

3. D. Brickley and R.V. Guha, ResourceDescription Framework (RDF) SchemaSpecification 1.0, W3C Candidate Recom-mendation, World Wide Web Consortium,Boston, 2000, www.w3.org/TR/rdf-schema(current 6 Dec. 2000).

4. J. Broekstra et al., “Enabling Knowledge Rep-resentation on the Web by Extending RDFSchema,” Proc. 10th Int’l World Wide WebConf., Hong Kong, 2001.

5. T.R. Gruber, “A Translation Approach toPortable Ontology Specifications,” Knowl-edge Acquisition, vol. 5, 1993, pp. 199–220.

6. D.B. Lenat and R.V. Guha, Building LargeKnowledge-Based Systems: Representationand Inference in the Cyc Project, Addison-Wesley, Reading, Mass., 1990.

7. M.R. Genesereth, “Knowledge InterchangeFormat,” Proc. Second Int’l Conf. Principlesof Knowledge Representation and Reasoning(KR 91), J. Allenet et al., eds., Morgan Kauf-

mann, San Francisco, 1991, pp. 238–249;http://logic.stanford.edu/kif/kif.html (current9 Mar. 2001).

8. A. Farquhar, R. Fikes, and J. Rice, “TheOntolingua Server: A Tool for CollaborativeOntology Construction,” Int’l. J. Human–Computer Studies, vol. 46, 1997, pp. 707–728.



Dieter Fensel’s biography appears in the Guest Editors’ Introduction on page 25.

Ian Horrocks is a lecturer in computer science with the Information Man-agement Group at the University of Manchester, UK. His research interestsinclude knowledge representation, automated reasoning, optimizing rea-soning systems, and ontological engineering, with particular emphasis onthe application of these techniques to the World Wide Web. He received aPhD in computer science from the University of Manchester. He is a mem-ber of the OIL language steering committee and the Joint EU/US Commit-tee on Agent Markup Languages, and is coeditor of the DAML+OIL lan-guage specification. Contact him at the Dept. of Computer Science, Univ. ofManchester, Oxford Rd., Manchester, M13 9PL, UK; [email protected];www.cs.man.ac.uk/~horrocks.

Frank van Harmelen is a senior lecturer in the AI Department at Vrije Uni-versiteit in Amsterdam. His research interests include specification languagesfor knowledge-based systems, using languages for validation and verificationof KBS, developing gradual notions of correctness for KBS, and verifyingweakly structured data. He received a PhD in artificial intelligence from theUniversity of Edinburgh. Contact him at Dept. of AI, Faculty of Sciences,Vrije Universiteit Amsterdam de Boelelaan 1081a, 1081HV Amsterdam,Netherlands; [email protected]; www.cs.vu.nl/~frankh.

Deborah L. McGuinness is the associate director and senior research sci-entist for the Knowledge Systems Laboratory at Stanford University. Hermain research areas include ontologies, description logics, reasoning sys-tems, environments for building and maintaining information, knowledge-enhanced search, configuration, and intelligent commerce applications. Shealso runs a consulting business dealing with ontologies and artificial intelli-gence for business applications and serves on several technology advisoryboards and academic advisory boards. She received a PhD from Rutgers Uni-versity in reasoning systems. Contact her at the Knowledge Systems Labo-ratory, Stanford Univ., Stanford, CA 94305; [email protected];www.ksl.stanford.edu/people/dm.

Peter F. Patel-Schneider is a member of the technical staff at Bell LabsResearch. His research interests center on the properties and use of descrip-tion logics. He is also interested in rule-based systems, including standard sys-tems derived from OPS as well as newer formalisms such as R++. He receivedhis PhD from the University of Toronto. Contact him at Bell Labs Research,600 Mountain Ave., Murray Hill, NJ 07974; [email protected];www.bell-labs.com/user/pfps.

T h e A u t h o r s

9. D. Fensel et al., “OIL in a Nutshell,” Proc.European Knowledge Acquisition Confer-ence (EKAW 2000), R. Dieng et al., eds.,Lecture Notes in Artificial Intelligence, no.1937, Springer-Verlag, Berlin, 2000, pp.1–16.

10. I. Horrocks et al., The Ontology InferenceLayer OIL, tech. report, Vrije UniversiteitAmsterdam; www.ontoknowledge.org/oil/TR/oil.long.html (current 9 Mar. 2001).

11. W.E. Grosso et al., “Knowledge Modeling atthe Millennium (The Design and Evolutionof Protege-2000),” Proc. 12th WorkshopKnowledge Acquisition, Modeling, and Man-agement, 1999.

12. M. Klein et al., “The Relation betweenOntologies and Schema-Languages: Trans-lating OIL Specifications to XML Schema,”Proc. Workshop on Applications of Ontolo-gies and Problem-Solving Methods, 14thEuropean Conf. on Artificial Intelligence,Berlin, 2000.

13. M. Erdmann and R. Studer, “How to Struc-ture and Access XML Documents withOntologies,” Data and Knowledge Eng., vol.36, no. 3, 2001.

14. I. Horrocks and P.F. Patel-Schneider, “Opti-mizing Description Logic Subsumption,” J.Logic and Computation, vol. 9, no. 3, June1999, pp. 267–293.

15. A.L. Rector, W.A. Nowlan, and A. Glowin-ski, “Goals for Concept Representation in theGALEN Project,” Proc. 17th Ann. Symp.Computer Applications in Medical Care(SCAMC 93), McGraw-Hill, New York,1993, pp. 414–418.

16. D. Fensel et al., “On-To-Knowledge: Ontol-ogy-based Tools for Knowledge Manage-ment,” Proc. eBusiness and eWork 2000Conf. (EMMSEC 2000), 2000.

17. S. Luke, L. Spector, and D. Rager, “Ontol-ogy-Based Knowledge Discovery on theWorld Wide Web,” Proc. 13th Nat’l Conf.Artificial Intelligence (AAAI 96), Ameri-can Association for Artificial Intelligence,Menlo Park, Calif., 1996.

18. D. Fensel et al., “Lessons Learned fromApplying AI to the Web,” J. CooperativeInformation Systems, vol. 9, no. 4, Dec. 2000,pp. 361–382.

19. U. Reimer et al., eds., Proc. Second Int’l Conf.Practical Aspects of Knowledge Management(PAKM 98), 1998.

20. F. Ygge and J.M. Akkermans, “DecentralizedMarkets versus Central Control: A Compara-tive Study,” J. Artificial Intelligence Research,vol. 11, July–Dec. 1999, pp. 301–333.


IN BIOLOGYMOTIVATION

Biology is rapidly becoming a data-rich science owing to recentmassive data generation technologies, while our biological colleaguesare designing cleverer and more informative experiments owing torecent advances in molecular science. These data and these experi-ments hold the keys to the deepest secrets of biology and medicine,but cannot be analyzed fully by humans because of the wealth andcomplexity of the information available. The result is a great need forintelligent systems in biology.

Intelligent systems probably helped design the last drug your doc-tor prescribed, and intelligent computational analysis of the humangenome will drive medicine for at least the next half-century. Even asyou read these words, intelligent systems are working on gene expres-sion data to help understand genetic regulation, and thus ultimatelythe regulated control of all life processes including cancer, regenera-tion, and aging. Modern intelligent analysis of biological sequencesresults today in the most accurate picture of evolution ever achieved.Knowledge bases of metabolic pathways and other biological net-works presently make inferences in systems biology that, for example,let a pharmaceutical program target a pathogen pathway that doesnot exist in humans, resulting in fewer side effects to patients. Intelli-gent literature-access systems exploit a knowledge flow exceedinghalf a million biomedical articles per year, while machine-learning sys-tems exploit heterogeneous online databases whose exponentialgrowth mimics Moore’s law. Knowledge-based empirical approachesare the most successful method known for general protein structureprediction, a problem that has been called the “Holy Grail of molecu-lar biology” and “solving the second half of the genetic code.”

This announcement seeks papers and referees for a special issueon Intelligent Systems in Biology. Preferred papers will describe animplemented intelligent system that produces results of significance inbiology or medicine. Systems thatextend or enhance the intelligence ofhuman biologists are especially wel-come. Referees are solicited fromexperts in the field who do not intendto submit a paper.

Special Issue, IEEE Intelligent Systems, Sept./Oct. 2001

GUEST EDITORRichard H. LathropDept. of Information and Computer ScienceUniv. of California, IrvineIrvine, CA 92697-3425Phone: +1 949 824 4021Fax: +1 949 824 [email protected]/~ricklSUBMISSION

GUIDELINESIEEE Intelligent Systems is a scholarlypeer-reviewed publication intended for a broadresearch and user community. An informal, direct, andlively writing style should be adopted. The issue will con-tain a tutorial and an overview of the field, but explicitly biolog-ical terms or concepts should be explained concisely. Manuscripts shouldbe original and should have between 6 and 10 magazine pages (not morethan 7,500 words) with up to 10 references. Send manuscripts in PDF format [email protected] by 25 May, 2001. Potential referees and general inquiries should con-tact [email protected] directly.



Semantic Web Services

Sheila A. McIlraith, Tran Cao Son, and Honglei Zeng, Stanford University

The Web, once solely a repository for text and images, is evolving into a provider

of services—information-providing services, such as flight information providers,

temperature sensors, and cameras, and world-altering services, such as flight-booking

programs, sensor controllers, and a variety of e-commerce and business-to-business

applications. Web-accessible programs, databases,sensors, and a variety of other physical devices real-ize these services. In the next decade, computers willmost likely be ubiquitous, and most devices will havesome sort of computer inside them. Vint Cerf, oneof the fathers of the Internet, views the populationof the Internet by smart devices as the harbinger ofa new revolution in Internet technology.

Today’s Web was designed primarily for humaninterpretation and use. Nevertheless, we are seeingincreased automation of Web service interoperation,primarily in B2B and e-commerce applications. Gen-erally, such interoperation is realized through APIs thatincorporate hand-coded information-extraction code tolocate and extract content from the HTML syntax of aWeb page presentation layout. Unfortunately, when aWeb page changes its presentation layout, the API mustbe modified to prevent failure. Fundamental to havingcomputer programs or agents1 implement reliable,large-scale interoperation of Web services is the need tomake such services computer interpretable—to createa Semantic Web2 of services whose properties, capa-bilities, interfaces, and effects are encoded in an unam-biguous, machine-understandable form.

The realization of the Semantic Web is underwaywith the development of new AI-inspired contentmarkup languages, such as OIL,3 DAML+OIL(www.daml.org/2000/10/daml-oil), and DAML-L (thelast two are members of the DARPA Agent MarkupLanguage (DAML) family of languages).4 These lan-guages have a well-defined semantics and enable themarkup and manipulation of complex taxonomic andlogical relations between entities on the Web. A fun-

damental component of the Semantic Web will be themarkup of Web services to make them computer-inter-pretable, use-apparent, and agent-ready. This articleaddresses precisely this component.

We present an approach to Web service markup thatprovides an agent-independent declarative API cap-turing the data and metadata associated with a servicetogether with specifications of its properties and capa-bilities, the interface for its execution, and the prereq-uisites and consequences of its use. Markup exploitsontologies to facilitate sharing, reuse, composition,mapping, and succinct local Web service markup. Ourvision is partially realized by Web service markup in adialect of the newly proposed DAML family of Seman-tic Web markup languages.4 Such so-called semanticmarkup of Web services creates a distributed knowl-edge base. This provides a means for agents to populatetheir local KBs so that they can reason about Web ser-vices to perform automatic Web service discovery, exe-cution, and composition and interoperation.

To illustrate this claim, we present an agent tech-nology based on reusable generic procedures andcustomizing user constraints that exploits and show-cases our Web service markup. This agent technol-ogy is realized using the first-order language of thesituation calculus and an extended version of theagent programming language ConGolog,5 togetherwith deductive machinery.

Figure 1 illustrates the basic components of ourSemantic Web services framework. It is composed ofsemantic markup of Web services, user constraints, andWeb agent generic procedures. In addition to themarkup, our framework includes a variety of agent tech-

The authors propose the

markup of Web services

in the DAML family of

Semantic Web markup

languages. This markup

enables a wide variety of

agent technologies for

automated Web service

discovery, execution,

composition, and

interoperation. The

authors present one

such technology for

automated Web service

composition.

nologies—specialized services that use anagent broker to send requests for service toappropriate Web services and to dispatch ser-vice responses back to the agent.

Automating Web servicesTo realize our vision of Semantic Web ser-

vices, we are creating semantic markup ofWeb services that makes them machineunderstandable and use-apparent. We are alsodeveloping agent technology that exploits thissemantic markup to support automated Webservice composition and interoperability. Dri-ving the development of our markup andagent technology are the automation tasks thatsemantic markup of Web services will enable—in particular, service discovery, execution,and composition and interoperation.

Automatic Web service discovery involvesautomatically locating Web services that pro-vide a particular service and that adhere torequested properties. A user might say, forexample, “Find a service that sells airline tick-ets between San Francisco and Toronto andthat accepts payment by Diner’s Club creditcard.” Currently, a human must perform thistask, first using a search engine to find a serviceand then either reading the Web page associ-ated with that service or executing the serviceto see whether it adheres to the requested prop-erties. With semantic markup of services, wecan specify the information necessary for Webservice discovery as computer-interpretablesemantic markup at the service Web sites, anda service registry or (ontology-enhanced)search engine can automatically locate appro-priate services.

Automatic Web service execution involvesa computer program or agent automaticallyexecuting an identified Web service. A usercould request, “Buy me an airline ticket fromwww.acmetravel.com on UAL Flight 1234from San Francisco to Toronto on 3 March.”To execute a particular service on today’sWeb, such as buying an airline ticket, a usergenerally must go to the Web site offering thatservice, fill out a form, and click a button toexecute the service. Alternately, the user mightsend an http request directly to the serviceURL with the appropriate parameters en-coded. Either case requires a human to under-stand what information is required to executethe service and to interpret the information theservice returns. Semantic markup of Web ser-vices provides a declarative, computer-inter-pretable API for executing services. Themarkup tells the agent what input is necessary,what information will be returned, and how to

execute—and potentially interact with—theservice automatically.

Automatic Web service composition andinteroperation involves the automatic selec-tion, composition, and interoperation ofappropriate Web services to perform sometask, given a high-level description of thetask’s objective. A user might say, “Make thetravel arrangements for my IJCAI 2001 con-ference trip.” Currently, if some task requiresa composition of Web services that must inter-operate, then the user must select the Web ser-vices, manually specify the composition, en-sure that any software for interoperation iscustom-created, and provide the input atchoice points (for example, selecting a flightfrom among several options). With semanticmarkup of Web services, the information nec-essary to select, compose, and respond to ser-vices is encoded at the service Web sites. Wecan write software to manipulate this markup,together with a specification of the task’sobjectives, to achieve the task automatically.Service composition and interoperation lever-age automatic discovery and execution.

Of these three tasks, none is entirely real-izable with today’s Web, primarily because ofa lack of content markup and a suitablemarkup language. Academic research on Webservice discovery is growing out of agentmatchmaking research such as the Lark sys-tem,6 which proposes a representation forannotating agent capabilities so that they canbe located and brokered. Recent industrial

efforts have focused primarily on improvingWeb service discovery and aspects of serviceexecution through initiatives such as the Uni-versal Description, Discovery, and Integration(UDDI) standard service registry; the XML-based Web Service Description Language(WSDL), released in September 2000 as aframework-independent Web service descrip-tion language; and ebXML, an initiative of theUnited Nations and OASIS (Organization forthe Advancement of Structured InformationStandards) to standardize a framework fortrading partner interchange.

E-business infrastructure companies arebeginning to announce platforms to supportsome level of Web-service automation. Exam-ples of such products include Hewlett-Packard’se-speak, a description, registration, and dynamicdiscovery platform for e-services; Microsoft’s.NET and BizTalk tools; Oracle’s Dynamic Ser-vices Framework; IBM’s Application Frame-work for E-Business; and Sun’s Open NetworkEnvironment. VerticalNet Solutions, anticipat-ing and wishing to accelerate the markup of services for discovery, is building ontologiesand tools to organize and customize Web ser-vice discovery and—with its OSM Platform—is delivering an infrastructure that coordinatesWeb services for public and private tradingexchanges.

What distinguishes our work in this arenais our semantic markup of Web services in anexpressive semantic Web markup languagewith a well-defined semantics. Our semantic


Web proceduresontologies

Semantic markup ofpersonal or company

constraints and preferences

Semantic-markup-enabledagent technology

Web serviceontologies

Semantic markup ofWeb service sites

Agent broker

Email ...

Knowledgebase

Figure 1. A framework for Semantic Web services.

markup provides a semantic layer that shouldcomfortably sit on top of efforts such asWSDL, enabling a richer level of descriptionand hence more sophisticated interactions andreasoning at the agent or application level. Todemonstrate this claim, we present agenttechnology that performs automatic Web ser-vice composition, an area that industry is notyet tackling in any great measure.

Semantic Web service markupThe three automation tasks we’ve described

are driving the development of our semanticWeb services markup in the DAML family ofmarkup languages. We are marking up

• Web services, such as Yahoo’s drivingdirection information service or UnitedAirlines’ flight booking service;

• user and group constraints and preferences,such as a user’s—let’s say Bob’s—sched-ule, that he prefers driving over flying if thedriving time to his destination is less thanthree hours, his use of stock quotes exclu-sively from the E*Trade Web service, andso forth; and

• agent procedures, which are (partial) com-positions of existing Web services, designedto perform a particular task and marked upfor sharing and reuse by groups of otherusers. Examples include Bob’s businesstravel booking procedure or his friend’sstock assessment procedure.

Our DAML markup provides a declarativerepresentation of Web service and user con-straint knowledge. (See the “The Case forDAML” sidebar to learn why we chose theDAML family of markup languages.) A keyfeature of our markup is the exploitation ofontologies, which DAML+OIL’s roots indescription logics and frame systems support.

We use ontologies to encode the classesand subclasses of concepts and relations per-taining to services and user constraints. (Forexample, the service BuyUALTicket and Buy-LufthansaTicket are subclasses of the serviceBuyAirlineTicket, inheriting the parameters cus-tomer, origin, destination, and so forth). Domain-independent Web service ontologies are aug-mented by domain-specific ontologies thatinherit concepts from the domain-indepen-dent ontologies and that additionally encodeconcepts that are specific to the individualWeb service or user. Using ontologiesenables the sharing of common concepts, thespecialization of these concepts and vocab-ulary for reuse across multiple applications,

the mapping of concepts between differentontologies, and the composition of new con-cepts from multiple ontologies. Ontologiessupport the development of succinct service-or user-specific markup by enabling an indi-vidual service or user to inherit much of itssemantic markup from ontologies, thusrequiring only minimal markup at the Website. Most importantly, ontologies can givesemantics to markup by constraining orgrounding its interpretation. Web servicesand users need not exploit Web serviceontologies, but we foresee many domainswhere communities will want to agree on astandard definition of terminology andencode it in an ontology.

DAML markup of Web servicesCollectively, our markup of Web services

provides

• declarative advertisements of serviceproperties and capabilities, which can beused for automatic service discovery;

• declarative APIs for individual servicesthat are necessary for automatic serviceexecution; and

• declarative specifications of the prerequi-sites and consequences of individual ser-vice use that are necessary for automaticservice composition and interoperation.

The semantic markup of multiple Web ser-vices collectively forms a distributed KB ofWeb services. Semantic markup can populatedetailed registries of the properties and capa-bilities of Web services for knowledge-basedindexing and retrieval of Web services byagent brokers and humans alike. Semanticmarkup can also populate individual agentKBs, to enable automated reasoning aboutWeb services.

Our Web service markup comprises a num-ber of different ontologies that provide thebackbone for our Web service descriptions. Wedefine the domain-independent class of ser-vices, Service, and divide it into two subclasses,PrimitiveService and ComplexService. In the contextof the Web, a primitive service is an individ-ual Web-executable computer program, sen-sor, or device that does not call another Webservice. There is no ongoing interactionbetween the user and a primitive service. Theuser or agent calls the service, and the servicereturns a response. An example of a primitiveservice is a Web-accessible program thatreturns a postal code, given a valid address. Incontrast, a complex service is composed of

multiple primitive services, often requiring aninteraction or conversation between the userand services, so that the user can make deci-sions. An example might be interacting withwww.amazon.com to buy a book.

Domain-specific Web service ontologiesare subclasses of these general classes. Theyenable an individual service to inheritshared concepts, and vocabulary in a partic-ular domain. The ontology being used is spec-ified in the Web site markup and then simplyrefined and augmented to provide service-specific markup. For example, we mightdefine an ontology containing the class Buy,with subclass BuyTicket, which has subclassesBuyMovieTicket, BuyAirlineTicket, and so forth. Buy-AirlineTicket has subclasses BuyUALTicket, Buy-LufthansaTicket, and so on. Each service is eithera PrimitiveService or a ComplexService. Associatedwith each service is a set of Parameters. Forexample, the class Buy will have the parame-ter Customer. BuyAirlineTicket will inherit the Cus-tomer parameter and will also have the para-meters Origin, Destination, DepartureDate, and so on.We constructed domain-specific ontologiesto describe parameter values. For example,we restricted the values of Origin and Destinationto instances of the class Airport. BuyUALTicketinherits these parameters, further restrictingthem to Aiports whose property Airlines includesUAL. These value restrictions provide animportant way of describing Web serviceproperties, which supports better brokeringof services and simple type checking for ourdeclarative APIs. In addition, we have usedthese restrictions in our agent technology tocreate customized user interfaces.

Markup for Web service discovery. To auto-mate Web service discovery, we associateproperties with services that are relevant toautomated service classification and selec-tion. In the case of BuyUALTicket, these wouldinclude service-independent property typessuch as the company name, the service URL,a unique service identifier, the intended use,and so forth. They would also include service-specific property types such as valid methodsof payment, travel bonus plans accepted, andso forth. This markup, together with certain ofthe properties specified later, collectively pro-vides a declarative advertisement of serviceproperties and capabilities, which is computerinterpretable and can be used for automaticservice discovery.

Markup for Web service execution. To auto-mate Web service execution, markup must



enable a computer agent to automaticallyconstruct and execute a Web service requestand interpret and potentially respond to theservice’s response. Markup for executionrequires a dataflow model, and we use botha function metaphor and a process or con-versation model to realize our markup. Eachprimitive service is conceived as a functionwith Input values and potentially multiplealternative Output values. For example, if theuser orders a book, the response will differdepending on whether the book is in stock,out of stock, or out of print.

Complex services are conceived as a com-position of functions (services) whose output

might require an exchange of informationbetween the agent and an individual service.For example, a complex service that books aflight for a user might involve first findingflights that meet the user’s request, then sus-pending until the user selects one flight. Com-plex services are composed of primitive orcomplex services using typical programminglanguages and business-process modelinglanguage constructs such as Sequence, Iteration,If-then-Else, and so forth. This markup providesdeclarative APIs for individual Web servicesthat are necessary for automatic Web serviceexecution. It additionally provides a processdataflow model for complex services. For an

agent to respond automatically to a complexservice execution—that is, to automaticallyinteroperate with that service—it will requiresome of the information encoded for auto-matic composition and interoperation.

Markup for Web service composition. Thefunction metaphor used for automatic Web ser-vice execution provides information about dataflow, but it does not provide information aboutwhat the Web service actually does. To auto-mate service composition, and for services andagents to interoperate, we must also encodehow the service affects the world. For exam-ple, when a user visits www.amazon.com and


In recent years, several markup languages have been devel-oped with a view to creating languages that are adequate forrealizing the Semantic Web. The construction of these lang-uages is evolving according to a layered approach to languagedevelopment.1

XML was the first language to separate the markup of Webcontent from Web presentation, facilitating the representa-tion of task- and domain-specific data on the Web. Unfortu-nately, XML lacks semantics. As such, computer programs can-not be guaranteed to determine the intended interpretationof XML tags. For example, a computer program would not beable to identify that <SALARY> data refers to the same informa-tion as <WAGE> data, or that the <DUE-DATE> specified at a Webservice vendor’s site might be different from the <DUE-DATE> atthe purchaser’s site.

The World Wide Web Consortium developed the resourcedescription framework (RDF)2 as a standard for metadata. The goal was to add a formal semantics to the Web, defined on top of XML, to provide a data model and syntax conventionfor representing the semantics of data in a standardized inter-operable manner. It provides a means of describing the relation-ships among resources (basically anything nameable by a URI) in terms of named properties and values. The RDF workinggroup also developed RDF Schema, an object-oriented type sys-tem that can be effectively thought of as a minimal ontology-modeling language. Although RDF and RDFS provide goodbuilding blocks for defining a Semantic Web markup language,they lack expressive power. For example, you can’t define prop-erties of properties, necessary and sufficient conditions for classmembership, or equivalence and disjointness of classes. Further-more, the only constraints expressible are domain and rangeconstraints on properties. Finally, and perhaps most importantly,the semantics remains underspecified.

Recently, there have been several efforts to build on RDF and RDFS with more AI-inspired knowledge representation languages such as SHOE,3 DAML-ONT,4 OIL,5 and most recentlyDAML+OIL. DAML+OIL is the second in the DAML family ofmarkup languages, replacing DAML-ONT as an expressive ontol-ogy description language for markup. Building on top of RDFand RDFS, and with its roots in AI description logics, DAML+OILovercomes many of the expressiveness inadequacies plaguingRDFS and most important, has a well-defined model-theoreticsemantics as well as an axiomatic specification that determinesthe language’s intended interpretations. DAML+OIL is unam-biguously computer-interpretable, thus making it amenable to

agent interoperability and automated-reasoning techniques,such as those we exploit in our agent technology.

In the next six months, DAML will be extended with the addi-tion of DAML-L, a logical language with a well-defined seman-tics and the ability to express at least propositional Horn clauses.Horn clauses enable compact representation of constraints andrules for reasoning. Consider a flight information service thatencodes whether a flight shows a movie. One way to do this isto create a markup for each flight indicating whether or not itdoes. A more compact representation is to write the constraintflight-over-3-hours → movie and to use deductive reasoning to infer if aflight will show a movie. This representation is more compact,more informative, and easier to modify than an explicit enumer-ation of individual flights and movies. Similarly, such clauses canrepresent markup constraints, business rules, and user prefer-ences in a compact form.

DAML+OIL and DAML-L together will provide a markup lan-guage for the Semantic Web with reasonable expressive powerand a well-defined semantics. Should further expressive powerbe necessary, the layered approach to language developmentlets a more expressive logical language extend DAML-L or actas an alternate extension to DAML+OIL. Because DAML-L hasnot yet been developed, our current Web service markup is in acombination of DAML+OIL and a subset of first-order logic. Ourmarkup will evolve as the DAML family of languages evolves.

References

1. D. Fensel, “The Semantic Web and Its Languages,” IEEE IntelligentSystems, vol. 15, no. 6, Nov./Dec. 2000, p. 67–73.

2. O. Lassila and R. Swick, Resource Description Framework (RDF)Model and Syntax Specification, W3C Recommendation, WorldWide Web Consortium, Feb. 1999; www.w3.org/TR/REC-rdf-syntax(current 11 Apr. 2001).

3. S. Luke and J. Heflin, SHOE 1.01. Proposed Specification,www.cs.umd.edu/projects/plus/SHOE/spec1.01.html, 2000 (current20 Mar. 2001).

4. J. Hendler and D. McGuinness, “The DARPA Agent MarkupLanguage,” IEEE Intelligent Systems, vol. 15, no. 6, Nov./Dec. 2000,pp. 72–73.

5. F. van Harmelen and I. Horrocks, “FAQs on OIL: The Ontology Infer-ence Layer,” IEEE Intelligent Systems, vol. 15, no. 6, Nov./Dec. 2000,pp. 69–72.

The Case for DAML

successfully executes the BuyBook service, sheknows she has purchased a book, that her creditcard will be debited, and that she will receivea book at the address she provided. Such con-sequences of Web service execution are notpart of the markup nor part of the function-based specification provided for automaticexecution. To automate Web service composi-tion and interoperation, or even to select anindividual service to meet some objective, wemust encode prerequisites and consequencesof Web service execution for computer use.

Our DAML markup of Web services forautomatic composition and interoperability isbuilt on an AI-based action metaphor. We con-ceive each Web service as an action—either aPrimitiveAction or a ComplexAction. Primitive actionsare in turn conceived as world-altering actionsthat change the state of the world, such as deb-iting the user’s credit card, booking the user aticket, and so forth; as information-gatheringactions that change the agent’s state of knowl-edge, so that after executing the action, theagent knows a piece of information; or assome combination of the two.

An advantage of exploiting an actionmetaphor to describe Web services is that it letsus bring to bear the vast AI research on rea-soning about action, to support automated rea-soning tasks such as Web service composition.In developing our markup, we choose to remainagnostic with respect to an action representa-tion formalism. In the AI community, there iswidespread disagreement over the best actionrepresentation formalism. As a consequence,different agents use very different internal rep-resentations for reasoning about and planningsequences of actions. The planning communityhas addressed this lack of consensus by devel-oping a specification language for describingplanning domains—Plan Domain DescriptionLanguage (PDDL).7 We adopt this languagehere, specifying each of our Web services interms of PDDL-inspired Parameters, Preconditions,and Effects. The Input and Output necessary forautomatic Web service execution also play therole of KnowledgePreconditions and KnowledgeEffects forthe purposes of Web service composition andinteroperation. We assume, as in the planningcommunity, that users will compile this gen-eral representation into an action formalism thatbest suits their reasoning needs. Translatorsalready exist from PDDL to a variety of differ-ent AI action formalisms.

Complex actions, like complex services, arecompositions of individual services; however,dependencies between these compositions arepredicated on state rather than on data, as is

the case with the execution-motivated markup.Complex actions are composed of primitiveactions or other complex actions using typi-cal programming languages and business-process modeling-language constructs suchas Sequence, Parallel, If-then-Else, While, and so forth.

DAML markup of user constraintsand preferences

Our vision is that agents will exploit users’constraints and preferences to help customizeusers’requests for automatic Web service dis-covery, execution, or composition and inter-operation. Examples of user constraints andpreferences include user Bob’s schedule, histravel bonus point plans, that he prefers to driveif the driving time to his destination is less than

three hours, that he likes to get stock quotesfrom the E*Trade Web service, that his com-pany requires all domestic business travel tobe with a particular set of carriers, and so forth.The actual markup of user constraints is rela-tively straightforward, given DAML-L. We canexpress most constraints as these Horn clauses(see the sidebar), and ontologies let users clas-sify, inherit, and share constraints. Inheritingterminology from Web service ontologiesensures, for example, that Bob’s constraintabout DrivingTime is enforced by determining thevalue of DrivingTime from a service that uses thesame notion of DrivingTime. More challengingthan the markup itself is the agent technologythat will appropriately exploit it.

DAML-enabled agent technologyOur semantic markup of Web services

enables a wide variety of agent technologies.Here, we present an agent technology we aredeveloping that exploits DAML markup ofWeb services to perform automated Web ser-vice composition.

Consider the example task given earlier:“Make the travel arrangements for my IJCAI2001 conference trip.” If you were to performthis task using services available on the Web,you might first find the IJCAI 2001 confer-ence Web page and determine the confer-ence’s location and dates. Based on the loca-tion, you would choose the most appropriatemode of transportation. If traveling by air, youmight then check flight schedules with one ormore Web services, book flights, and so on.

Although the entire procedure is lengthyand somewhat tedious to perform, the aver-age person could easily describe how to makeyour travel arrangements. Nevertheless, it’snot easy to get someone else to make thearrangements for you. What makes this taskdifficult is not the basic steps but the need tomake decisions to customize the generic pro-cedure to enforce the traveler’s constraints.Constraints can be numerous and conse-quently difficult for another person to keep inmind and satisfy. Fortunately, enforcing com-plex constraints is something a computer doeswell.

Our objective is to develop agent technol-ogy that will perform these types of tasks auto-matically by exploiting DAML markup ofWeb services and of user constraints and pref-erences. We argue that many of the activitiesusers might wish to perform on the SemanticWeb, within the context of their workplace orhome, can be viewed as customizations ofreusable, high-level generic procedures. Ourvision is to construct such reusable, high-levelgeneric procedures and to represent them asdistinguished services in DAML using a sub-set of the markup designed for complex ser-vices. We also hope to archive them insharable generic procedures ontologies so thatmultiple users can access them. Generic pro-cedures are customized with respect to users’constraints, using deductive machinery.

Generic procedures and customiz-ing user constraints

We built our research on model-based pro-gramming8 and on research into the agentprogramming language Golog and its vari-ants, such as ConGolog.5 Our goal was toprovide a DAML-enabled agent program-ming capability that supports writing genericprocedures for Web service-based tasks.

Model-based programs comprise a model—in this case, the agent’s KB—and a program—the generic procedure we wish to execute. Weargue that the situation calculus (a logical lan-guage for reasoning about action and change)



Our vision is that agents will exploit

users’ constraints and preferences

to help customize users’ requests

for automatic Web service

discovery, execution, or

composition and interoperation.

and ConGolog5 provide a compelling languagefor realizing our agent technology. When a userrequests a generic procedure, such as a generictravel arrangements procedure, the agent pop-ulates its local KB with the subset of the PDDL-inspired DAML Web service markup that is rel-evant to the procedure. It also adds the user’sconstraints to its KB. Exploiting our actionmetaphor for Web services, the agent KB pro-vides a logical encoding of the preconditionsand effects of the Web service actions in thelanguage of the situation calculus.

Model-based programs, such as our genericprocedures, are written in ConGolog withoutprior knowledge of what specific services theagent will use or of how exactly to use the avail-able services. As such, they capture what toachieve but not exactly how to do it. They useprocedural programming language constructs(if-then-else, while, and so forth) composed withconcepts defined in our DAML service andconstraints ontologies to describe the proce-dure. The agent’s model-based program is notexecutable as is. We must deductively instanti-ate it in the context of the agent’s KB, whichincludes properties of the agent and its user,properties of the specific services we are using,and the state of the world. We perform theinstantiation by using deductive machinery. Aninstantiated program is simply a sequence ofprimitive actions (individual Web services),which ConGolog interprets and sends to theagent broker as a request for service. The greatadvantage of these generic procedures is thatthe same generic procedure, called with differ-ent parameters and user constraints, can gen-erate very different sequences of actions.

ConGolog ConGolog is a high-level logic programming

language developed at the University ofToronto. Its primary use is for robot program-

ming and to support high-level robot taskplanning. ConGolog is built on top of situ-ation calculus. In situation calculus, theworld is conceived as a tree of situations,starting at an initial situation, S0, and evolv-ing to a new situation through the perfor-mance of an action a (for example, Webservices such as BuyUALTicket(origin,dest, date)).Thus, a situation s is a history of the actionsperformed from S0. The state of the worldis expressed in terms of relations and func-tions (so-called fluents) that are true or falseor have a particular value in a situation, s(for example, flightAvailable(origin,dest, date,s)).

Figure 2 illustrates the tree of situationsinduced by a situation calculus theory withactions a1, …,an (ignore the ×’s for the timebeing). The tree is not actually computed, butit reflects the search space the situation cal-culus KB induces. We could have performeddeductive plan synthesis to plan sequencesof Web service actions over this search space,but instead, we developed generic proceduresin ConGolog.

ConGolog provides a set of extralogicalprocedural programming constructs forassembling primitive and complex situationcalculus actions into other complex actions.5

Let δ1 and δ2 be complex actions, and let ϕand a be so-called pseudo fluents and pseudoactions, respectively—that is, a fluent oraction in the language of situation calculuswith all its situation arguments suppressed.Figure 3a shows a subset of the constructs inthe ConGolog language.

A user can employ these constructs towrite generic procedures, which are complexactions in ConGolog. The instruction set forthese complex actions is simply the generalWeb services (for example, BookAirlineTicket) orother complex actions. Figure 3b gives exam-ples of ConGolog statements.

To instantiate a ConGolog program in the

context of a KB, the abbreviation Do(δ,s,s′) isdefined. It says that Do(δ,s,s′) holds when-ever s′ is a terminating situation following the execution of complex action δ, starting insituation s. Given the agent KB and a genericprocedure δ, we can instantiate δwith respectto the KB and the current situation S0 byentailing a binding for the situation variables. Because situations are simply the historyof actions from S0, the binding for s defines asequence of actions that leads to successfultermination of the generic procedure δ:

KB ❘= (∃ s).Do(δ, S0, s)

It is important to observe that ConGolog pro-grams—and hence our generic procedures—are not programs in the conventional sense.Although they have the complex structure ofprograms—including loops, if-then-else state-ments, and so forth—they differ in that they arenot necessarily deterministic. Rather than nec-essarily dictating a unique sequence of actions,ConGolog programs serve to add temporal con-straints to the situation tree of a KB, as Figure2 depicts. As such, they eliminate certainbranches of the situation tree (designated by the×’s), reducing the size of the search space ofsituations that instantiate the generic procedure.


aj

. . .

a1 an

S0

. . . . . .. . .aja1 an aja1 an

. . .aja1 an

. . .. . .. . .. . .aja1 an

Figure 2. The tree of situations.

Figure 3. (a) A subset of the constructs in theConGolog language. (b) Examples ofConGolog statements.

Primitive action: a Test of truth: ϕ?Sequence: (δ1; δ2)Nondeterministic choice between actions: (δ1 | δ2) Nondeterministic choice of arguments: πx.δNondeterministic iteration: δ *Conditiona: if ϕ then δ1 else δ2 endIfLoop: while ϕ do δ endWhileProcedure: proc P(v) δ endProc

(a)

while ∃ x.(hotel(x)∧ goodLoc(x,dest)) docheckAvailability(x,dDate,rDate)

endWhile

if ¬ hotelAvailable(dest,dDate,rDate) thenBookB&B(cust,dest,dDate,rDate)

endIf

proc Travel(cust,origin,dest,dDate,rDate,purpose);If registrationRequired then Register endlf;BookTranspo(cust,origin,dest,dDate,rDate);BookAccommodations(cust,dest,dDate,rDate);UpdateExpenseClaim(cust);Inform(cust)

endProc

(b)

The Desirable predicate, Desirable(a,s),which we introduced into ConGolog to incor-porate user constraints, also further reduces thetree to those situations that are desirable to theuser. Because generic procedures and cus-tomizing user constraints simply serve to con-strain the possible evolution of actions, depend-ing on how they are specified, they can playdifferent roles. At one extreme, the generic pro-cedure simply constrains the search spacerequired in planning. At the other extreme,a generic procedure can dictate a uniquesequence of actions, much in the way a tradi-tional program might. We leverage this nonde-terminism to describe generic procedures thathave the leeway to be relevant to a broad rangeof users, while at the same time being cus-tomizable to reflect the desires of individualusers.We contrast this to a traditional proceduralprogram that would have to be explicitly mod-ified to incorporate unanticipated constraints.

ImplementationTo implement our agent technology, we

started with an implementation of an onlineConGolog interpreter in Quintus Prolog 3.2.5

We augmented and extended this interpreterin a variety of ways (discussed further else-where9). Some of the issues we dealt with werebalancing the offline search for an instantia-tion of a generic procedure with online execu-tion of information-gathering Web services,because they help to further constrain thesearch space of possible solutions. We addednew constructs to the ConGolog language toenable more flexible encoding of generic pro-cedures, and we incorporated users’ cus-tomizing constraints into ConGolog by addingthe Desirable predicate mentioned earlier.

We also modified the interpreter to com-municate with the Open Agent Architectureagent brokering system.10 OAA sends requeststo appropriate Web services and dispatchesresponses to the agents. When the SemanticWeb is a reality, Web services will communi-cate through DAML. Currently, we musttranslate our markup (DAML+OIL and a sub-set of first-order logic) back and forth toHTML through a set of Java programs. Weuse an information extraction program, WorldWide Web Wrapper Factory (http://db.cis.upenn.edu/W4F), to extract the informationWeb services currently produce in HTML. Allinformation-gathering services are performedthis way. For obvious practical and financialreasons, world-altering aspects of services arenot actually executed.

ExampleHere, we illustrate the execution of our

agent technology with a generic procedurefor making travel arrangements. Let’s sayBob wants to travel from San Francisco toMonterey on Knowledge Systems Lab busi-ness with the DARPA-funded DAML re-search project. He has two constraints—onepersonal and one inherited from the KSL, towhich he belongs. He wishes to drive ratherthan fly, if the driving time is less than threehours, and as a member of the KSL, he hasinherited the constraint that he must use anAmerican carrier for business travel.

In reality, our demo doesn’t provide muchto see. The user makes a request to the agentthrough a user interface that is automaticallycreated from our DAML+OIL agent proce-dures ontology, and the agent emails the userthe travel itinerary when it is done. For the pur-

poses of illustration, Figure 4 provides a win-dow into what is happening behind the scenes.It is a trace from the run of our augmented andextended ConGolog interpreter, operating inQuintus Prolog. The agent KB is representedin a Prolog encoding of the situation calculus,a translation of the Semantic Web servicemarkup relevant to the generic travel procedurebeing called, together with Bob’s user con-straint markup. We have defined a generic pro-cedure for travel not unlike the one illustratedin Figure 3b.

Arrow 1 points to the call to the ConGologprocedure travel(user,origin,dest,dDate,rDate,purpose),with the parameters instantiated as noted.Arrow 2 shows the interpreter contacting OAA,which sends a request to Yahoo Maps to exe-cute the getDrivingTime(San Franciso,Monterey) serviceYahoo Maps provides. Yahoo Maps indicatesthat the driving time between San Franciscoand Monterey is two hours. Because Bob has aconstraint that he wishes to drive if the drivingdistance is less than three hours, booking aflight is not desirable. Consequently, as de-picted at Arrow 3, the agent elects to search foran available car rental at the point of origin, SanFrancisco. A number of available cars are re-turned, and because Bob has no constraints thataffect car selection, the first car is selected atArrow 4. Arrow 5 depicts the call to OAA fora hotel at the destination point, and so on. Ouragent technology goes on to complete Bob’stravel arrangements, creating an expense claimform for Bob and filling in as much informa-tion as was available from the Web services.The expense claim illustrates the agent’s abil-ity to both read and write Semantic Webmarkup. Finally, the agent sends an email mes-sage to Bob, notifying him of his agenda.

To demonstrate the merits of our approach,we often contrast such an execution of thegeneric travel procedure with one a differentuser called, with different user constraints.The different user and constraints produce adifferent search space, thus yielding a dif-ferent sequence of Web services.

Related workOur agent technology broadly relates to the

plethora of work on agent-based systems.Three agent technologies that deserve men-tion are the Golog family of agent technolo-gies referenced earlier, the work of researchersat SRI on Web agent technology,11 and thesoftbot work developed at the University ofWashington.12 The last also used a notion ofaction schemas to describe actions on theInternet that an agent could use to achieve a


| ?– travel (‘Bob Chen‘, ‘09/02/00‘, ‘San Francisco‘, ‘Monterey‘, ‘DAML‘).Contacting Web Service Broker: Request Driving Time [San Francisco] – [Monterey]Result 2

Contacting Web Service Broker: Request Car Info in [San Francisco]Result HERTZShuttle to Car CounterEconomy Car Automati… ACEOff Airport, Shuttle ProvidedEconomy Car Aut… NATIONALShuttle to Car CounterEconomy Car Auto… FOXOff Airport, Shuttle ProvidedMini Car Automa… PAYLESSOff Airport, Shuttle ProvidedMini Car Au… ALL INTLOff Airport, Shuttle ProvidedEconomy Ca… HOLIDAYOff Airport, Shuttle ProvidedEconomy Car… ABLE RENTOff Airport, Shuttle ProvidedCompact C… Select HERTZ (San Francisco Airport), Location: Shuttle to Car Counter, Economy Car Automatic with Air Conditioning, Unlimited Mileage

Contact Web Service Broker: Request Hotel Info in [Monterey]Result TravelodgeMonterey, CA55 Rooms / 2 FloorsNo… EconolodgesMonterey, CA47 Rooms / 2 Floors 1… Lexington SerciesMonterey, CA52 RoomsNot A… Ramada InnsMonterey, CA47 RoomsNot Availabl… Best Western IntlMonterey, CA43 Rooms / 3 Floo… Motel 6Monterey, CA52 Rooms / 2 FloorsNot A… Villager LodgeMonterey, CA55 Rooms / 2 Floors<… Best Western IntlMonterey, CA34 Rooms / 2 Flo…

1xterm

2

3

4

5

Figure 4. Agent interacting with Web services through OAA.

goal. Also of note is the Ibrow system, an intel-ligent brokering service for knowledge-com-ponent reuse on the Web.13 Our work is simi-lar to Ibrow in the use of an agent brokeringsystem and ontologies to support interactionwith the Web. Nevertheless, we are focusingon developing and exploiting Semantic Webmarkup, which will provide us with the KBfor our agents. Our agent technology performsautomated service composition based on thismarkup. This is a problem the Ibrow commu-nity has yet to address.

The DAML family of semantic Webmarkup languages will enable Web

service providers to develop semanticallygrounded, rich representations of Web servicesthat a variety of different agent architecturesand technologies can exploit to a variety of dif-ferent ends. The markup and agent technologypresented in this article is but one of many pos-sible realizations. We are building on the mark-up presented here to provide a core set of Web service markup language constructs in alanguage we’re calling DAML-S. We’re work-ing in collaboration with SRI, Carnegie Mel-lon University, Bolt Baranek and Newman,and Nokia, and we’ll eventually publish thelanguage at www.daml.org. Our agent tech-nology for automating Web service composi-tion and interoperation is also fast evolving.We’ll publicize updates at www.ksl.stanford.edu/projects/DAML/webservices.

AcknowledgmentsWe thank Richard Fikes and Deborah McGuin-

ness for useful discussions related to this work; RonFadel and Jessica Jenkins for their help with ser-vice ontology construction; and the reviewers,Adam Cheyer and Karl Pfleger for helpful com-ments on a draft of this article. We also thank theCognitive Robotics Group at the University ofToronto for providing an initial ConGolog inter-preter that we have extended and augmented, andSRI for the use of the Open Agent Architecture soft-ware. Finally, we gratefully acknowledge the finan-cial support of the US Defense Advanced ResearchProjects Agency DAML Program #F30602-00-2-0579-P00001.

References

1. J. Hendler, “Agents and the Semantic Web,”IEEE Intelligent Systems, vol. 16, no. 2,Mar./Apr. 2001, pp. 30–37.

2. T. Berners-Lee, M. Fischetti, and T. M. Der-touzos, Weaving the Web: The OriginalDesign and Ultimate Destiny of the WorldWide Web by its Inventor, Harper, San Fran-cisco, 1999.

3. F. van Harmelen and I. Horrocks, “FAQs onOIL: The Ontology Inference Layer,” IEEEIntelligent Systems, vol. 15, no. 6, Nov./Dec.2000, pp. 69–72.

4. J. Hendler and D. McGuinness, “The DARPAAgent Markup Language,” IEEE Intelligent Sys-tems, vol. 15, no. 6, Nov./Dec. 2000, pp. 72–73.

5. G. De Giacomo, Y. Lesperance, and H.Levesque, “ConGolog, a Concurrent Pro-gramming Language Based on the SituationCalculus,” Artificial Intelligence, vols. 1–2,no. 121, Aug. 2000, pp. 109–169.

6. K. Sycara et al., “Dynamic Service Match-making among Agents in Open InformationEnvironments,” J. ACM SIGMOD Record,vol. 28, no. 1, Mar. 1999, pp. 47–53.

7. M. Ghallab et al., PDDL: The PlanningDomain Definition Language, Version 1.2,tech. report CVC TR–98–003/DCS TR–1165,Yale Center for Computational Vision andControl,Yale Univ., New Haven, Conn., 1998.

8. S. McIlraith, “Modeling and ProgrammingDevices and Web Agents,” to be published inProc. NASA Goddard Workshop Formal

Approaches to Agent-Based Systems, LectureNotes in Computer Science, Springer-Verlag,New York, 2001.

9. S. McIlraith and T.C. Son, “Adapting Gologfor Programming the Semantic Web,” to bepublished in Proc. 5th Symp. on Logical For-malizations of Commonsense Reasoning(Common Sense 2001), 2001.

10. D.L. Martin, A.J. Cheyer, and D.B. Moran,“The Open Agent Architecture:A Frameworkfor Building Distributed Software Systems,”Applied Artificial Intelligence, vol. 13, nos.1–2, Jan.–Mar. 1999, pp. 91–128.

11. R. Waldinger, “Deductive Composition ofWeb Software Agents,” to be published inProc. NASA Goddard Workshop FormalApproaches to Agent-Based Systems, LectureNotes in Computer Science, Springer-Verlag,New York, 2001.

12. O. Etzioni and D. Weld, “A Softbot-BasedInterface to the Internet,” Comm. ACM, July1994, Vol. 37, no. 7, pp. 72–76.

13. V. R. Benjamins et al., “IBROW3: An Intel-ligent Brokering Service for Knowledge-Component Reuse on the World Wide Web,”Proc. 11th Banff Knowledge Acquisition forKnowledge-Based System Workshop (KAW’98), Banff, Canada, 1998; http://spuds.cpsc.ucalgary.ca/KAW/KAW98/KAW98Proc.html (current 20 Mar. 2001).


Sheila A. McIlraith is a research scientist in Stanford University’s Knowl-edge Systems Laboratory and the project lead on the KSL’s DAML Web Ser-vices project. Her research interests include knowledge representation andreasoning techniques for the Web, for modeling, diagnosing, and controllingstatic and dynamical systems, and for model-based programming of devicesand agents. She received her PhD in computer science from the Universityof Toronto. Contact her at [email protected].

Tran Cao Son is an assistant professor in the Department of Computer Sci-ence at New Mexico State University. His research interests include knowl-edge representation, autonomous agents, reasoning about actions and changes,answer set programming and its applications in planning and diagnosis, modelbased reasoning, and logic programming. Contact him at [email protected].

Honglei Zeng is a graduate student in the Department of Computer Scienceat Stanford University. He is also a research assistant in the Knowledge Sys-tems Laboratory. His research interests include the Semantic Web, knowl-edge representation, commonsense reasoning, and multiple agents systems.Contact him at [email protected].

T h e A u t h o r s



A Portrait of theSemantic Web inActionJeff Heflin and James Hendler, University of Maryland

The Web’s phenomenal growth rate makes it increasingly difficult to locate, orga-

nize, and integrate the available information. To cope with the enormous quan-

tity of data, we need to hand off portions of these tasks to machines. However, because

natural-language processing is still an unsolved problem, machines cannot understand

the Web pages to the extent required to perform thedesired tasks.

An alternative is to change the Web to make itmore understandable by machines, thereby creatinga Semantic Web. Many researchers believe the key tobuilding this new Web lies in the development ofsemantically enriched languages. Early languages,such as the resource description framework,1 Sim-ple HTML Ontology Extensions (SHOE),2 andOntobroker,3 have led to more recent efforts, such asthe Defense Advanced Research Projects Agency’sAgent Markup Language (DAML). Some say thatlanguages such as these will revolutionize the Web.If so, how will the new Web work?

In this article, we put a Semantic Web languagethrough its paces and try to answer questions abouthow people can use it, such as:

• How do authors generate semantic descriptions?• How do agents discover these descriptions?• How can agents integrate information from dif-

ferent sites?• How can users query the Semantic Web?

We present a system that addresses these ques-tions and describe tools that help users interact withthe Semantic Web. We motivate the design of oursystem with a specific application: semantic markupin the computer science domain.

Producing semantic markupDescribing a set of Web pages using a Semantic

Web language can be challenging. (For an overviewof Semantic Web languages, see the related sidebar.)The first step is to consider the pages’ domain andchoose an appropriate ontology. As Semantic Weblanguages evolve, knowledge engineers will likelyprovide huge ontology libraries, as well as numeroussearch mechanisms to help users find relevant ontolo-gies. Meanwhile, some of the common languagesprovide starter ontology libraries. (Knowledge engi-neering, which covers the difficult process of design-ing ontologies, is outside this article’s scope.)

Our running example uses the SHOE language,which has served as a testbed for Semantic Web ideasover the past five years, although technically the dis-cussion could apply to any Semantic Web language.SHOE has a computer science department ontologythat includes classes such as Student, Faculty, Course,Department, Publication, and Research, and relations suchas publicationAuthor, member, emailAddress, and advisor. Thisontology’s scope makes it relevant to faculty and stu-dent homepages, department Web pages, researchproject Web pages, and publication indices. Authorscan use a number of methods to produce SHOEmarkup for these pages.

Authoring toolsAs with HTML, authors can use a text editor to

Without semantically

enriched content, the

Web cannot reach its

full potential. The

authors discuss tools

and techniques for

generating and

processing such

content, thus setting a

foundation upon

which to build the

Semantic Web.

add semantic markup to a page. However,unlike HTML processors, Semantic Webprocessors are not very forgiving, and errorscan result in the processors ignoring largeportions of the annotations. One solution is toprovide authoring tools that let authors cre-ate markup by making selections and fillingin forms. For the SHOE project, we devel-oped the Knowledge Annotator (see Figure1) to perform this function.

In SHOE, a document references a set ofontologies that provide the vocabulary usedto describe entities (called instances). Eachassertion about an instance is called a claim,to denote that it may not necessarily be true.

The Knowledge Annotator has an interfacethat displays instances, ontologies, and claims,and a user can add, edit, or remove any ofthese objects. When creating a new object, theKnowledge Annotator prompts the user forthe necessary information. In the case ofclaims, the user can choose the source ontol-ogy from a list and then choose categories orrelations defined in that ontology from anotherlist. The available relations are automaticallyfiltered based on whether the instances enteredcan fill the argument positions.

Users have access to various methods forviewing the knowledge in the document.These include a view of the source HTML, a

logical notation view, and a view that orga-nizes claims by subject and describes themusing simple English. In addition to prompt-ing the user for inputs, the tool performs errorchecking to ensure correctness and convertsthe inputs into legal SHOE syntax. For thesereasons, only a rudimentary understandingof SHOE is necessary to mark up Web pages.If developers enhance contemporary Webauthoring tools with semantic markupauthoring capabilities, adding semanticmarkup could become a regular activity inthe Web-page design process.

Members of our research group providedmarkup for their homepages and those of the


Unlike Extensible Markup Language (XML), which uses aname or prose description to imply meaning in documents, aSemantic Web language must describe meaning in a machine-readable way. Therefore, the language needs not only theability to specify a vocabulary, but also to formally define thevocabulary so that it will work in automated reasoning. Assuch, the subfield of AI known as knowledge representationgreatly influences Semantic Web languages.

However, to meet the needs of the Web, Semantic Web lan-guages must also differ from traditional KR languages. Themost obvious difference is syntactical: Language designersbase Semantic Web syntaxes on existing standards such asHypertext Markup Language (HTML) or XML so that integra-tion with other Web technologies is possible. Other differencesdepend on the nature of the Web.

Because the Web is decentralized, the language must allowfor the definition of diverse—and potentially conflicting—vocabularies. To handle the Web’s rapid evolution, the lan-guage must let the vocabularies evolve as human understand-ing of their use improves. Finally, the Web’s size requires thatscalability play a role in any solution.

An author can formally specify a Semantic Web vocabularyusing an ontology or a schema. Such ontologies and schemasare also typically sharable (so users can agree to use the samedefinitions) and extensible (so users can agree on some commonset of definitions but add terms and definitions as necessary).Researchers expect that ontology hierarchies will develop, withtop-level abstract ontologies at the root and domain-specificontologies at the leaves. Thus, automatic interoperabilitybetween a pair of ontologies exists to the degree that theyshare a common ancestor. The language’s expressivity deter-mines the potential richness of an ontology’s definitions. Mostlanguages let ontologies define class taxonomies so that it ispossible to say, for example, a car is a type of vehicle. They alsoallow for the definition of properties for each class and relation-ships between multiple classes. Some languages might alsoallow the formation of more complex definitions, using axiomsfrom some form of logic.

Major differences exist between the leading Semantic Weblanguages. The resource description framework (RDF) Schema1

is the least expressive. It is based on a semantic network

model, with special links for defining category and propertytaxonomies and links for applying domain and rangeconstraints to properties. Simple HTML Ontology Extensions(SHOE)2 is based on a frame system but also allows Horn clauseaxioms (essentially, simple if–then rules), which authors can useto define things not possible in RDF. More so than its peers,SHOE focuses on dealing with the problems of a dynamic, dis-tributed environment.3 The Ontology Inference Layer (OIL),based on a frame system augmented with description logic,lets authors express different kinds of definitions.4 TheDefense Advanced Research Projects Agency Agent MarkupLanguage (DAML) is a language under development with theintent to combine the best features of RDF, SHOE, and OIL.

Although ontologies are crucial to making a Semantic Weblanguage work, they merely serve to standardize and provideinterpretations for Web content. To make this content machineunderstandable, the Web pages must contain semanticmarkup—that is, descriptions which use the terminology thatone or more ontologies define. The semantic markup mightstate that a particular entity is a member of a class, an entity hasa particular property, or two entities have some relationshipbetween them. By committing to an ontology, the semanticmarkup sanctions inferences based on the ontology definitionsand lets agents conclude things that the markup implies.

References

1. O. Lassila, “Web Metadata: A Matter of Semantics,” IEEE InternetComputing, vol. 2, no. 4, July 1998, pp. 30–37.

2. S. Luke et al., “Ontology-Based Web Agents,” Proc. First Int’l Conf.Autonomous Agents, ACM Press, New York, 1997.

3. J. Heflin and J. Hendler, “Dynamic Ontologies on the Web,” Proc.17th Nat’l Conf. AI (AAAI-2000), MIT–AAAI Press, Menlo Park,Calif., 2000, pp. 443–449.

4. S. Decker et al., “Knowledge Representation on the Web,” Proc.2000 Int’l Workshop on Description Logics (DL2000), Sun SITECentral Europe (CEUR), Aachen, Germany, 2000, http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-33/.

Overview of Semantic Web languages

group’s Web site. Most used the KnowledgeAnnotator, but some preferred a text editor.Although we produced detailed markup fora set of pages, the set is too small to be of usefor anything but controlled demos.

Generating markup on a largescale

For semantic markup to be really useful,it needs to be ubiquitous, but using an author-ing tool to generate a lot of markup is tedious.Detractors of the Semantic Web languageapproach often cite the difficulty of produc-ing markup as the main reason it won’t work.Fortunately, there are automatic and semi-automatic approaches for generating seman-tic markup.

Running SHOE. Some Web pages have reg-ular structure, with labeled fields, lists, andtables. Often, an analyst can map these struc-tures to an ontology and write a program totranslate portions of the Web page into thesemantic markup language. We developedRunning SHOE (see Figure 2), a tool thathelps users specify how to extract SHOEmarkup from these kinds of Web pages. Theuser selects a page to markup and creates awrapper for it by specifying a series of delim-iters that describe how to extract interestinginformation. These delimiters indicate thestart of a list (so that the program can skipheader information) and end of a list (so thatit can ignore trailing information); the startand end of a record; and for each field of

interest, a pair of start and end delimiters.A fundamental problem in distributed sys-

tems is knowing when markup from differentpeople describes the same entity. If we are tointegrate descriptions about such an entity,we must use a common identifier (or key)when referring to it. A URL can often serveas this key because it identifies exactly oneWeb page, which a single person or organi-zation owns. The regular pages that work bestwith Running SHOE tend to have lists ofthings, and each item in each list typicallycontains a hyperlink to a thing’s homepage.However, these hyperlinks often use relativeURLs, which are not unique. To handle thisproblem, the user can specify that a particu-lar field is a URL, so that when the programextracts the data, it expands all relative URLsusing the page’s URL as a base.

After the user has specified the delimiters,the tool can display a table with a row foreach record and a column for each field.Irregularities in a page’s HTML code canoften cause the program to extract fields orrecords improperly; this table lets the userverify the results before proceeding. The nextstep is to convert the table into SHOEmarkup. In the top-right panel, the user canspecify ontology information and a series oftemplates for SHOE classification and rela-tion declarations.

For each classification or relation argu-ment, the user can specify a literal value orreference a field. At the user’s command, thetool can then iterate through these templates

and the table of records to create a series ofSHOE statements. Using this tool, a traineduser can extract substantial markup from aWeb page in minutes. Furthermore, becauseRunning SHOE lets users save and retrievetemplates, it is easy to regenerate new SHOEmarkup if the page’s content changes.

Computer science department Web sitesoften have faculty, project, course, and userlists that have ideal formats for RunningSHOE. Each item in each list contains an <A>tag that provides the URL of the item’s home-page, and this element’s content is often thename of the entity being linked to, providingus with a value for the “name” relation. Otherproperties of the instance often follow and aredelimited by punctuation, emphasis, or spe-cial spacing. With this tool, a single user cancreate SHOE markup about the faculty,courses, and projects of 15 major computerscience departments in a day.

Although there are many pages for whichRunning SHOE is useful, there are otherimportant resources from which it cannotextract information. An example of such a siteis CiteSeer (http://citeseer.nj.nec.com/cs), anindex of online computer science publicationsthat we wanted to integrate with our depart-ment Web pages. Interaction with CiteSeerinvolves issuing a query to one page, view-ing a results page, and then selecting a resultto get a page about a particular publication.This multistep process prevents RunningSHOE from extracting markup from the Cite-Seer site.

Publication SHOE Maker. To extract SHOEfrom CiteSeer, we built a tool called Publi-cation SHOE Maker. PSM issues a query toget publications likely to be from a particu-lar institution and retrieves a fixed numberof publication pages from the results. Thepublication pages contain the publication’stitle, authors, year, links to online copies, andoccasionally additional BibTex information.Each publication page’s layout is very simi-lar, so PSM can extract the values of thedesired fields easily.

An important issue is how to link theauthor information with the faculty instancesextracted from the department Web pages.Fortunately, CiteSeer includes homepageinformation, which HomePageSearch (http://hpsearch.uni-trier.de) generates for eachauthor. By using these URLs (as opposed tothe authors’names), PSM can establish linksto the appropriate instances.

Running SHOE and PSM are only two



Figure 1. The Knowledge Annotator. Here, the interface is being used to view semanticmarkup about a Simple HTML Ontology Extensions (SHOE) publication.

examples of tools with which authors cangenerate markup. Other extraction toolsmight include machine-learning4,5 or natural-language-processing techniques. As Exten-sible Markup Language becomes ubiquitouson the Web, generating wrappers willbecome easier, and authors will be able touse style sheets to transform a simple XMLvocabulary into a semantically enriched one.

If a Web page’s provider is willing toinclude semantic markup, the process can beeven easier. For example, databases holdmuch of the Web’s data, and scripts produceWeb pages from that data. Because databasesare structured resources, an analyst can deter-mine the semantics of a database schema,map the schema to an ontology, and modifythe scripts that produce the Web pages toinclude the appropriate semantic markup.

Integrating resourcesAfter authors have described a number of

diverse Web sites with semantic markup, thenext problem is determining how to integratethe information. Information integration sys-tems, such as Ariadne,6 can be useful whendeveloping an application that combines datafrom a finite number of predeterminedsources, but are less helpful when integrat-ing information “on the fly” is necessary.One solution mirrors the operation of con-temporary search engines by crawling theWeb and storing the information in a centralrepository.

ExposéExposé is a Web crawler that searches for

Web pages with SHOE markup and internsthe knowledge. A Web crawler essentiallyperforms a graph traversal where the nodesare Web pages and the arcs are the hypertextlinks between them. When Exposé discoversa new URL, it assigns the page a cost anduses this cost to schedule when it will loadthat page. Thus, the cost function determinesa traversal order. We assume SHOE pageswill tend to be localized and interconnected.Therefore, we use a cost function thatincreases with distance from the start node,where paths through nonSHOE pages aremore expensive than those through SHOEpages, and paths that stay within the samedirectory on the same server are cheaper thanthose that do not.

Exposé parses each Web page, and if apage references an ontology that Exposé isunfamiliar with, it loads the ontology also.To update its list of pages to visit, Exposé

identifies all of the hypertext links, categoryinstances, and relation arguments within thepage and evaluates each new URL as we dis-cussed. Finally, the agent stores SHOE cat-egory and relation statements and any newontology information in a knowledge base.

This KB will determine the system’s querycapabilities, and thus we must choose anappropriate knowledge representation sys-tem. Our SHOE tools all use a generic appli-cation programming interface for interactionwith the KB, letting us easily use differentbackends. We have implemented versions ofthis API for Parka, a high-performance framesystem;7 XSB, a deductive database;8 andOpen Knowledge Base Connectivity-com-pliant KBs.9

By changing the back-end knowledge rep-resentation system, we get varying trade-offsbetween query response time and the degreeto which the system uses inference to com-pute answers. For example, Parka answersrecognition queries on large KBs (contain-ing millions of assertions) in seconds, andwhen used on parallel machines, it provideseven better performance. However, Parka’sonly inferential capabilities are class mem-bership and inheritance, so it cannot use theextra Horn clause rules that SHOE allows.However, XSB can reason with these rules

but is not as efficient as Parka. Alternately,the KB could be a relational or object data-base, providing the greatest scalability andbest query response times but sacrificing theability to infer additional answers. Clearly,the choice of the back-end system dependson the application’s expected query needs.

We let Exposé crawl the various computerscience Web pages described earlier, and itwas able to gather approximately 40,000assertions. The crawler stored these asser-tions in both Parka and XSB KBs. Techni-cally we did not need a Web crawler for ourexample, because we knew the locations ofall the relevant pages a priori. However, inan ideal Semantic Web situation, the markupis the product of many individuals workingindependently, and users could not easilylocate it without a crawler.

Querying the Semantic WebBoth general-purpose and domain-specific

query tools can access the SHOE knowledgeafter it has been loaded into the KB. TheSHOE Search tool (see Figure 3) is a gen-eral-purpose tool that gives users a new wayto browse the Web by letting them submitstructured queries and open documents byclicking on the URLs in the results. The userfirst chooses an ontology against which to


Figure 2. Running SHOE. A user can specify delimiters for recognizing fields andrecords, verify that they are extracted correctly, then create templates that translatethe data into SHOE format.

issue the query (which essentially establishesa context for the query).

The user then chooses the desired object’sclass from a hierarchical list and is presentedwith a list of all properties that could apply tothat object. After entering desired values forone or more of these properties, the userissues a query and receives a set of results ina table. If the user double-clicks on a bind-ing that is a URL, the corresponding Webpage will open in a new browser window.Thus, the user can browse the Semantic Web.

If SHOE markup does not describe all ofthe relevant Web pages, SHOE Search’s stan-dard query method will not be able to return ananswer or might only return partial answers.Therefore, we also have a Web Search featurethat translates the user’s query into a similarsearch engine query and submits it to any of anumber of popular search engines. UsingSHOE Search in this way has two advantagesover using the search engines directly:

• By prompting the user for values of prop-erties, it increases the chance that the userwill provide distinguishing information forthe desired results.

• By automatically creating the query, it canexploit helpful features that users oftenoverlook, such as quoting phrases or usingthe plus sign to indicate a mandatory term.

We build a query string that comprises aquoted short name for the selected category

and, for each property value that the userspecifies, a short phrase describing the prop-erty. The user’s value, which we quote andprecede with a plus sign to indicate that it isa mandatory phrase, follows the phrasedescribing the property.

With SHOE Search, a user can submitmany queries pertinent to our computer sci-ence domain. Figure 3 shows a sample queryto locate University of Washington facultymembers and their publications. The com-puter science ontology serves as a unifyingframework for integrating information fromthe university’s faculty page with publicationinformation from CiteSeer. Furthermore, theontology lets the query system recognize thatanyone declared a Professor is also Faculty.

Sample queries to the KB exposed oneproblem with the system: Sometimes it didn’tintegrate information from a department Webpage and CiteSeer as expected. These sitesoccasionally use different URLs to refer tothe same person. This is a fundamental prob-lem with using URLs as keys in a SemanticWeb system: Multiple URLs can refer to thesame Web page because of multiple hostnames for a given IP address, default pagesfor a directory URL, host-dependent short-cuts such as a tilde for the users directory,symbolic links within the host, and so on.Additionally, some individuals might havemultiple URLs that make equally valid keysfor them, such as the URLs of both profes-sional and personal homepages. These prob-

lems would be partially alleviated if the lan-guage included the ability to specify identifierequivalence—a feature absent from SHOEbut present in DAML.

We created a search engine called Se-mantic Search that is based on the tech-nologies we describe. Semantic Searchuses the SHOE Search tool as a query inter-face and provides utilities for authors,including links to an ontology library, theKnowledge Annotator, an online SHOEvalidation form, and a form for submittingnew pages to the repository. We encouragereaders to add markup to their own Webpages and submit them. Semantic Searchis available at http://www.cs.umd.edu/projects/plus/SHOE/search/.

We have described a simple archi-tecture for a Semantic Web system

that parallels the way contemporary Webtools and search engines work. As Figure 4shows, authors use various tools to addmarkup to Web pages, and a Web crawler dis-covers the information and stores it in arepository, which other tools can then query.Generally, authors need not produce allmarkup by hand; in many cases, simpleextraction tools can generate accurate mark-up with minimal human effort. Although thetools that comprise this architecture aredesigned for use with the SHOE language,developers can create similar tools for otherSemantic Web languages. Because any num-ber of tools can produce and process thesemantic markup on a Web page, other archi-tectures are also possible. For example,developers could create an agent that queriespages directly as opposed to issuing queriesto a Web-crawler-constructed repository.

If we achieve the Semantic Web vision,locating useful information on the Internetwill be easier, and integrating diverseresources will be simpler. The first step is todesign languages that we can use to expressexplicit semantics. The next step is toimprove the systems and tools we describe,so users can naturally provide and receiveinformation on the Semantic Web. Obvi-ously, we must still overcome some obsta-cles: We need better schemes for ensuringinteroperability between independentlydeveloped ontologies and approaches fordetermining who and what to trust. However,



Figure 3. SHOE Search. With this tool, a user issues a query by choosing an ontology,choosing a category from that ontology, and then filling in desired values for proper-ties that instances of that category might have.

these challenges do not appear to be insur-mountable, and the Semantic Web could bejust around the corner.

AcknowledgmentsThe US Air Force Research Laboratory sup-

ported this work under grant F306029910013.

References

1. O. Lassila, “Web Metadata: A Matter ofSemantics,” IEEE Internet Computing, vol.2, no. 4, July 1998, pp. 30–37.

2. S. Luke et al., “Ontology-Based WebAgents,” Proc. First Int’l Conf. AutonomousAgents, ACM Press, New York, 1997, pp.59–66.

3. D. Fensel et al., “Ontobroker: How toEnable Intelligent Access to the WWW,”AAAI-98 Workshop on AI and InformationIntegration, AAAI Press, Menlo Park,Calif., 1998, pp. 36–42.

4. D. Freitag, “Information Extraction fromHTML: Application of a General MachineLearning Approach,” Proc. 15th Nat’l Conf.AI (AAAI-98), MIT–AAAI Press, MenloPark, Calif., 1998, pp. 517–523.

5. N. Kushmerick, D. Weld, and R.Doorenbos, “Wrapper Induction forInformation Extraction,” Proc. 15th Int’lJoint Conf. AI, Morgan Kaufmann, SanFrancisco, 1997, pp. 729–735.

6. C. Knoblock et al., “Modeling Web Sourcesfor Information Integration,” Proc. 15thNat’l Conf. AI (AAAI-98), MIT–AAAIPress, Menlo Park, Calif., 1998, pp.211–218.

7. K. Stoffel, M. Taylor, and J. Hendler,“Efficient Management of Very LargeOntologies,” Proc. 14th Nat’l Conf. AI(AAAI-97), MIT–AAAI Press, Menlo Park,Calif., 1997.

8. K. Sagonas, T. Swift, and D. Warren, “XSBas an Efficient Deductive DatabaseEngine,” Proc. 1994 ACM SIGMOD Int’lConf. Management of Data (SIGMOD’94),ACM Press, New York, 1994, pp. 442–453.

9. V. Chaudhri et al., “OKBC: A ProgrammaticFoundation for Knowledge Base Inter-operability,” Proc. 15th Nat’l Conf. AI(AAAI-98), MIT–AAAI Press, Menlo Park,Calif., 1998, pp. 600–607.

MARCH/APRIL 2001 computer.org/intelligent

Knowledgebase

Domaininterfaces

SHOEsearch

ExposéWeb

pages

User interfaces

Texteditor

Knowledgeannotator

Annotation

Figure 4. A simple Semantic Web system based on the tools we describe.

T h e A u t h o r sJeff Heflin is a PhDcandidate in the Com-puter Science Depart-ment at the Universityof Maryland. His re-search interests in-clude Semantic Weblanguages, ontologies,Internet agents, and

knowledge representation. He has worked inthe computer consulting industry for four yearsas a data modeler, database designer, and data-base administrator. He received a BS in com-puter science from the College of William andMary and an MS in computer science from theUniversity of Maryland. He is currently a mem-ber of the Joint US–EU Ad hoc Agent MarkupLanguage Committee. Contact him at the Uni-versity of Maryland, Dept. of Computer Sci-ence, College Park, MD 20742; [email protected].

James Hendler’s biography appears on p. 37.

computer.org/internet/

IEEE Internet Computingreports emerging tools,technologies, andapplications implementedthrough the Internet tosupport a worldwidecomputing environment.

In 2001, we’ll look at• Embedded systems• Virtual markets• Internet engineering for

medical applications• Distributed data storage• Web server scaling• Personalization

... and more!



Creating Semantic Web Contents with Protégé-2000Natalya F. Noy, Michael Sintek, Stefan Decker, Monica Crubézy, Ray W. Fergerson, andMark A. Musen, Stanford University

B ecause we can process only a tiny fraction of information available on the Web,

we must turn to machines for help in processing and analyzing its contents. With

current technology, machines cannot understand and interpret the meaning of the infor-

mation in natural-language form, which is how most Web information is represented

today. We need a Semantic Web to express informa-tion in a precise, machine-interpretable form, so soft-ware agents processing the same set of data share anunderstanding of what the terms describing the datamean.1

Consequently, we’ve recently seen an explosionin the number of Semantic Web languages devel-oped. Because researchers and developers haven’tyet reached a consensus on which language is themost suitable, which features each language musthave, or which syntax is the most appropriate, we arelikely to see even more languages emerge. We needto develop tools that will let us experiment with thesenew languages so we can compare their expressive-ness and features, change language specifications,and select a suitable language for a specific task.

In this article, we describe Protégé-2000, a graph-ical tool for ontology editing and knowledge acqui-sition that we can adapt to enable conceptual model-ing with new and evolving Semantic Web languages.Protégé-2000 lets us think about domain models at aconceptual level without having to know the syntaxof the language ultimately used on the Web. We canconcentrate on the concepts and relationships in thedomain and the facts about them that we need toexpress. For example, if we are developing an ontol-ogy of wines, food, and appropriate wine–food com-binations, we can focus on Bordeaux and lambinstead of markup tags and correct syntax.

Naturally, designing a new tool specifically for anew language could be better than adapting an exist-ing tool. We can offer several reasons, however, for

adapting an existing tool at the stage where no sin-gle language has emerged as the winner. First, wecan experiment with emerging languages withoutcommitting enormous amounts of resources to cre-ating tools that are custom-tailored for these lan-guages—only to decide later that the languages arenot suitable. Second, Protégé-2000 already providesconsiderable functionality that a new tool will needto replicate, both at the modeling and user-interfacelevels. Third, using different customizations of thesame tool to edit ontologies in different languagesgives us most of the translation among the modelsin the languages “for free.” Translating a model fromone language to another becomes as easy as select-ing a “save as…” item from a menu.

Semantic Web languagesAI researchers have used ontologies for a long

time to express formally a shared understanding ofinformation. An ontology is an explicit specificationof the concepts in a domain and the relations amongthem, which provides a formal vocabulary for infor-mation exchange. Specific instances of the conceptsdefined in the ontologies—instance data—pairedwith ontologies constitute the basis of the SemanticWeb. In recent experiments to prototype the Seman-tic Web, members of different communities with dif-ferent backgrounds and goals in mind have createda multitude of languages for representing ontologiesand instance data on the Web (see Table1). Typically,a Semantic Web language for describing ontologiesand instance data contains a hierarchical description

As researchers continue

to create new languages

in the hope of developing

a Semantic Web, they still

lack consensus on a

standard. The authors

describe how Protégé-

2000—a tool for

ontology development

and knowledge

acquisition—can be

adapted for editing

models in different

Semantic Web

languages.

of important concepts in a domain (classes).Individuals in the domain are instances ofthese classes, and properties (slots) of eachclass describe various features and attributesof the concept. Logical statements describerelations among concepts. For example, con-sider an ontology describing wines, food, andappropriate wine–food combinations. Someof the classes describing this domain are Wine,Wineries, and different types of Food. Someproperties of the Wine class include the wine’sflavor, body, sugar level, and the winery that pro-duced it.

These notions are present in many Seman-tic Web languages existing today includingSHOE, Topic Maps, XOL, RDF and RDFS,and DAML+OIL.

The SHOE (Simple HTML OntologyExtensions) language, developed at the Uni-versity of Maryland, introduces primitives todefine ontology and instance data on Webpages. Classes are called categories in SHOE.Categories constitute a simple is-a hierarchy,and slots are binary relations. SHOE alsoallows relations among instances or instancesand data to have any number of arguments(not just binary relations). Horn clausesexpress intensional definitions in SHOE.

The Hytime community developed TopicMaps, a recent ISO standard (ISO/IEC13250). Topic Maps aim to annotate docu-ments with conceptual information. Topicscorrespond to classes in other ontology lan-guages and can be linked to documents. Top-ics are instances of Topic Types (other topics),which can be related to one another with Asso-ciations. Associations correspond closely toslots in other ontology languages. Associa-tions belong to Association Types, which areagain Topics. Topic Maps do not have a spe-cialized primitive for representing instances.Any instance of a topic type can act as a topictype itself.

The bioinformatics community designedXOL for the exchange of ontologies in thefield of bioinformatics. It evolved to becomea general language for interchange of ontol-ogy and instance data. Being an interchangelanguage, XOL includes primitives found inmany knowledge-representation systems,object databases, and relational databases. Itprovides means to define classes, a class hier-archy, slots, facets, and instances.

RDF (resource description framework)provides a graph-based data model, consist-ing of nodes and edges. Nodes correspond to

objects or resources and the edges to prop-erties of these objects. The labels on thenodes and edges are Uniform Resource Iden-tifiers (URIs). However, RDF itself does notdefine any primitives for creating ontologies.It is the basis for several other ontology-def-inition languages such as RDFS andDAML+OIL.

RDF Schema2 defines the primitives forcreating ontologies. Figure 1 shows an exam-ple of a graph representing our ontology ofwines as an RDFS. In RDFS, there areclasses of concepts, which constitute a hier-archy with multiple inheritance. For exam-ple, the class Wine is a subclass of the classDrink. Classes typically have instances (forexample, a specific red wine is an instanceof the Red Wine class) and a resource can be aninstance of more than one class (for exam-ple, Romariz Port is an instance of both the RedWine and the Dessert Wine classes). Resourceshave properties associated with them (forexample, Wine has flavor). Properties describeattributes of a resource or a relation of aresource to another resource. RDFS definesa property’s domain—resources that can besubjects of the property—and a property’srange—resources that can be objects of the


Table 1. A selection of Semantic Web languages.

Language Description URL

XOL XML-based ontology-exchange language www.ai.sri.com/~pkarp/xol

Topic Maps ISO standard for describing knowledge structures www.topicmaps.org

SHOE Simple HTML Ontology Extensions www.cs.umd.edu/projects/plus/SHOE

RDF and Resource description framework and www.w3.org/RDFRDFS RDF Schema

DAML+OIL DARPA Agent Markup Language + www.daml.orgOntology Inference Layer

rdf:type

rdfs:subClassOf

rdfs:subClassOf

rdf:type

rdf:typerdf:type rdf:type rdf:type

rdf:type

rdf:type

rdf:type

rdf:type

rdfs:rangerdfs:range

rdfs:subClassOf

rdfs:subClassOf rdfs:subClassOf

rdfs:domain

rdfs:domain

rdf:Property

d:White_wine d:Dessert_wine

d:Drink d:maker

d:grape

rdfs:Class

d:Wine

d:Winery

d:Red_wine d:Rose_wine

d:Wine_grape

Figure 1. An RDF Schema graph representing the Wine ontology.

property. For example, the property makermay have a class Wine as its domain and aclass Winery as its range.

DAML+OIL (DARPA Agent Markup lan-guage + Ontology Inference Layer)3 takes adifferent approach to defining classes andinstances. In addition to defining classes andinstances declaratively, DAML+OIL andother description-logics languages let us cre-ate intensional class definitions using Booleanexpressions and specify necessary, or neces-sary and sufficient, conditions for class mem-bership. These languages rely on inferenceengines (classifiers) to compute a class hier-archy and to determine class membership ofinstances based on the properties of classesand instances. For example, we can define aclass of Bordeaux wines as “a class of winesproduced by a winery in the Bordeaux region.”In DAML+OIL, we can also specify globalproperties of classes and slots. For example,we can say that the location slot is transitive: ifa winery is located in the Bordeaux region andthe Bordeaux region is located in France, thenthe winery is in France. We will describeDAML+OIL in more detail later.

We can see from this discussion thatSemantic Web languages for representingontologies and instance data have many fea-tures in common. At the same time, there aresignificant differences stemming from dif-ferent design goals for the languages. Inadapting Protégé-2000 as an editor for theselanguages, we build on the similaritiesamong them and custom-tailor the tool toaccount for the individual differences.

Protégé-2000For many years now, experts in domains

such as medicine and manufacturing haveused Protégé-2000 for domain modeling. Weshow not only how we adapt Protégé-2000to the new world of the Semantic Web—reusing its user interface, internal represen-tation, and framework—but also how ourchanges enable conceptual modeling with thenew Semantic Web languages.

Protégé-2000 is highly customizable,which makes its adaptation as an editor for anew language faster than creating a new edi-tor from scratch. The following featuresmake this customization possible:

• An extensible knowledge model. We canredefine declaratively the representationalprimitives the system uses.

• A customizable output file format. We canimplement Protégé-2000 components thattranslate from the Protégé-2000 internalrepresentation to a text representation inany formal language.

• A customizable user interface. We canreplace Protégé-2000 user-interface com-ponents for displaying and acquiring datawith new components that fit the new lan-guage better.

• An extensible architecture that enablesintegration with other applications. Wecan connect Protégé-2000 directly toexternal semantic modules, such as spe-cific reasoning engines operating on themodels in the new language.

Protégé-2000 knowledge model Protégé-2000’s representational primi-

tives—the elements of its knowledgemodel4—are very similar to those of theSemantic Web languages that we describedearlier. Protégé-2000 has classes, instances



The tabs representing differentviews of a knowledge base and the

configuration information

The class hiearchy The slot definition

The facets

Figure 2. A snapshot of the ontology representing wines. The tree on the left represents a class hierarchy. The form on the rightshows the definition of the Wine class.

of these classes, slots representing attributesof classes and instances, and facets express-ing additional information about slots.

Figure 2 shows an example definition of aclass, which is part of an ontology describingwines, food, and desirable wine–food com-binations. In the figure, the tree on the leftrepresents a class hierarchy. The class of Pauil-lac wines, for instance, is a subclass of theclass of Médoc wines. In other words, eachPauillac wine is a Médoc wine. The class of Médocwines is, in turn, a subclass of Red Bordeauxwines and so on. The form on the right in Fig-ure 2 represents the definition of the selectedclass (Wine). There is the name of the class,its documentation, a list of possible con-straints, and definitions of slots that theinstances of this class will have. Instances ofthe class Wine will have slots describing theirflavor, body, sugar level, the winery that producedthe wine, and so on.

The form in Figure 3 displays an instanceof the class Pauillac representing Château LafiteRothschild Pauillac, and the fields display the slotvalues for that instance. Therefore, we knowthat Château Lafite Rothschild Pauillac has afull body and strong flavor among otherproperties. Both the class-definition forms(the right-hand side in Figure 2) and theinstance-definition forms (Figure 3) areknowledge-acquisition forms in Protégé-2000. The fields on the knowledge-acquisi-tion forms correspond to slot values, and wedefine classes and instances by filling in slotvalues in these fields. Protégé-2000 gener-ates knowledge-acquisition forms automati-cally based on the types of the slots andrestrictions on their values.

The Protégé-2000 user interface (Figure2) consists of several tabs for editing differ-ent elements of a knowledge base and cus-tom tailoring the layout of the knowledge-acquisition forms, such as the forms inFigures 2 and 3. The Classes tab definesclasses and slots, and the Instances tabacquires specific instances. The Forms taballows us to change the layout and the con-tents of the knowledge-acquisition forms.

We can customize almost all of the Pro-tégé-2000 features we have described to fita specific domain or task by

• changing declaratively the standard classand slot definitions;

• changing the content and the layout of theknowledge-acquisition forms; and

• developing plug-ins using the Protégé-2000 application-programming interface.5

Let’s look at how we can customize Pro-tégé-2000 and then see how we can use thisflexibility to create Protégé-based editors fornew Semantic Web languages.

Changing the notion of classesand slots

The definition of the Wine class in Figure 2is a standard class definition in Protégé-2000,with a class name, documentation, list ofslots, and so on. What if we need to add moreattributes to a class definition, or change howa class looks, or change the default definitionof a class in the system? For instance, wemight want to add a list of a few best winer-ies for each type of wine in the hierarchy.Such a list is a property of a class (such asPauillac wines) rather than a property of spe-cific instances of the class (such as ChâteauLafite Rothschild Pauillac). The list of the bestwineries for a class is not inherited by its sub-classes: The best wineries producing red Bor-deaux are not necessarily the same as the bestMédoc or Pauillac wineries (although, theymay overlap). Therefore, this list mustbecome a part of a class definition the sameway as documentation is a part of a class def-inition. The Protégé-2000 metaclass archi-tecture lets us do just that.4,5

Metaclasses are templates for classes inthe same way that classes are templates forinstances. We can define our own meta-classes and effectively change a definition ofwhat a class is, in the same way we woulddefine a new class. The default Protégé-2000template (the standard metaclass) defines thefields that we see in Figure 2. We can extenddeclaratively this standard definition of what

a class is with new fields of any type bydefining a new metaclass, which simplybecomes a part of the knowledge base. Fig-ure 4 shows a definition of the Red Bordeauxclass that includes the additional field with alist of the best Bordeaux wineries.

Similarly, we can define new metaslots asuser-defined templates for new slots. If slotdefinitions in our system must have fields inaddition to the ones that Protégé-2000 has,we simply define new templates where wedescribe these new fields.

Custom-tailoring slot widgets forvalue acquisition

The look and behavior of the fields on theknowledge-acquisition forms in Figures 2and 3 depend on the types of the values thatthe fields can take. A field for a string value,such as a class name, has a simple text win-dow. A field that contains a list of complexvalues is a list box with buttons to add andremove values and to create new values.These fields are called slot widgets. They notonly display the values appropriately, but alsohelp to ensure that the values are correctbased on the slot definitions in the ontology.For example, the maker of a wine must be awinery—an instance of the Winery class. Theslot widget for the maker slot in Figure 3 letsus set the value only to a Winery instance.

Developers can extend Protégé-2000 byimplementing their own slot widgets that aretailored to acquire and verify particular kindsof values. Suppose we wanted to be moreprecise about the sugar level in wine and tomark it on a scale rather than simply choos-ing among three values—dry, sweet, or off-dry.


Figure 3. An instance of the class Pauillac representing the Château Lafite Rothschild Pauillac. Thiswine has a full body, a strong flavor, and a moderate tannin level, among other properties.

We could store the value as a number in thesugar slot. We could use a slot widget thatwould let us select the value on a slider ratherthan enter a number (see Figure 5). When wecustomize knowledge-acquisition forms, wechoose not only the layout of the fields onthe form, but also the slot widgets that mustbe used for different fields. The slot widgetswe choose do not usually affect the contentsof the knowledge base itself, but their use canmake the look and feel of the tool much moresuitable for a particular domain or language.Slot widgets also can help ensure the internalconsistency of a knowledge base by check-ing, for example, that an integer value thatwe enter is between the allowed maximumand minimum for that slot.

Using a back-end plug-in to generate the right output

When we develop a domain model in Pro-tégé-2000, we do not need to think about thespecific file format that Protégé-2000 will use

to save our work. We think about our domainat the conceptual level and create classes, slots,facets, and instances using the graphical userinterface. Protégé-2000 then saves the result-ing domain models in its own file format.Developers can change this file format in thesame way they plug in slot widgets. Back-endplug-ins let developers substitute the Protégé-2000 text file format with any other file for-mat. For example, suppose we wanted to useXML to publish the wine ontology and otherdomain models we create using Protégé-2000.We would then need to create an XML backend that substitutes files in the Protégé-2000format with the files in XML. A back end cre-ates a mapping between the in-memory rep-resentation of a Protégé-2000 knowledge baseand the file output in the required format. Theback end also enables us to import the files inthat format into Protégé-2000. The new fileformat has the same status as the Protégé-2000native file format, and the users can chooseeither format for their files.

Editing Semantic Web languageswith Protégé-2000

Armed with the arsenal of tools to custom-tailor Protégé-2000 quickly and easily, let’slook at what is involved in creating a Protégé-2000 editor for a new Semantic Web language.We will use the Protégé-RDFS editor devel-oped in our laboratory as an example, but theideas are the same for any new language.

We start creating a Protégé-2000 editor forour new language by determining the differ-ences between the knowledge models of thetwo languages: the knowledge model of Pro-tégé-2000 and the knowledge model under-lying our language of choice. We then decidewhich of the available tools—metaclasses,custom user-interface components, or a cus-tom back end—we will use to reconcile thedifferences or to hide them from the user.

In practice, the overlap between the knowl-edge models underlying the Semantic Weblanguages available today is very large. Themodels might use different terminology for



The field in the new template

Figure 4. A class definition that uses a nonstandard template. We added the best wineries slot to the standard class-definition template.

the same notion (for example, slots in Pro-tégé-2000 and properties in RDFS). How-ever, the structure of the concepts, the under-lying semantics, and the restrictions are oftensimilar.

When we compare the two knowledgemodels, we identify four categories of con-cepts (see Figure 6):

1. Concepts that are exactly the same in thetwo languages (possibly with differentnames). Usually, classes, inheritance,instances, slots as properties of classes andinstances, and many of the slot restrictionsfall into this category.

2. Concepts that are the same but expresseddifferently in the two languages. Forexample, Protégé-2000 associates slotswith classes by attaching a slot to a class.RDFS defines essentially the same rela-tionship by defining a domain of a property.

3. Concepts in our language of choice thatdo not have an equivalent in Protégé-2000.For example, RDFS allows an instance tohave more than one type, whereas in Pro-tégé-2000 each instance has a unique directtype.

4. Concepts that Protégé-2000 supports andour language of choice does not. For exam-ple, Protégé-2000 allows a slot to have

more than one allowed class for its values,whereas the range of a property in RDFSis limited to a single class.

Naturally, we can express all the featuresof our language that fall into the first categorydirectly in Protégé-2000. We deal with the dif-ferences in the other three categories by defin-ing appropriate metaclasses and metaslots andby resolving the remaining changes in theback end. We hide the differences from theuser behind custom-tailored slot widgets.

The second item on the list, the conceptsthat do not have a direct equivalent in Protégé-2000 but that can be mapped to native Pro-tégé-2000 concepts, deserves a special dis-cussion. Consider domains of properties inRDFS (rdfs:domain). A domain specifies a classon which a property might be used. For exam-ple, the domain of the flavor property is the Wineclass. Protégé-2000 slots are similar to prop-erties in RDFS. Attaching a slot to a class inProtégé-2000 also specifies that a slot can beused with that class. For example, the flavor slot


A slider widget fornumeric values

Figure 5. Changing a slot widget. We use a slider instead of a simple field to acquirenumeric values for the sugar level.

(2) Concepts that can beencoded as native Protégé

concepts

(1) Conceptsthat are identical

semantically

(3) Concepts that do nothave an equivalentin native Protégé

(4) Concepts in Protégé thatdo not have an equivalent

in the language

Use nativeProtégé concepts

Use Protégéconcepts directly

Use metaclasses andmetaslots to encode

the information

Use custom labels andslot widgets to hide

the differences

Back end

Use custom slot widgetsto facilitate

knowledge entry

Use knowledge-acquisitionforms to disable

the features

Map between the model inProtégé and the model

required by the language

Map directly intothe model required

by the language

Modeling

User interface

Map between the model inProtégé and the model

required by the language

Define the means of storingthe information in the

language format

The new language3

1

2

4 Protégé-2000

Figure 6. Comparing the knowledge models of Protégé-2000 and a new Semantic Web language.

is attached to the Wine class. We have two waysto encode the RDFS domain information in aProtégé-RDFS editor. First, we can add adomain slot to a template (metaslot) that we willuse for all our slots. Then, a field for domainwill appear on each form for a slot, and wewill fill it in there. Second, we can simply usethe native Protégé-2000 notion of slot attach-ment and translate the attachments of slots toclasses into domains of properties in the backend. The second solution lets us use the Pro-tégé-2000 user interface directly and hides thefeatures of a specific language used to storethe information.

We find it extremely beneficial to adopt theparadigm of using the native Protégé-2000 fea-tures wherever possible and of resorting toadditional definitions, such as metaclasses andmetaslots, only when absolutely necessary.This approach maximally facilitates theexchange of domain models among differentlanguages, which we edit (or will edit) withProtégé-2000. As new languages emerge andwe experiment with them, the knowledge mod-els underlying these languages will undoubt-edly overlap. By encoding as much as possiblein the native Protégé-2000 structures and leav-ing part of the translation between the Protégé-2000 model and the language to the back end,we maximize the amount of information thatwe will preserve by simply loading a knowl-edge base in one language supported by Pro-tégé-2000 and saving it to another language.Even though there would often be some parts

of these models that will not be part of thisoverlap, we are maximizing the amount ofinformation that gets ported among models indifferent languages for free.

Having generated the four groups of con-cepts after comparing the two knowledgemodels (see Figure 6), we can reconcile thedifferences using

1. modeling—by changing default defini-tions of classes and slots at the modelinglevel;

2. the user interface—by developing spe-cialized user-interface components; and

3. the back end—by implementing the newback end that will translate between thedomain model in Protégé-2000 and thedomain model in our language of choice.

Let’s look at how each of these three lev-els works using the development of a Pro-tégé-based RDFS editor as an example (seeTable 2 for a summary of the entire process).

The modeling levelWe start by determining which concepts in

our language of choice are identical to Protégé-2000 concepts or that can be represented usingthe native Protégé-2000 concepts. We use thenative Protégé-2000 as a means to model thisgroup of concepts, even if it is not how theseelements are directly expressed in our lan-guage. We then define the new templates forclass and slot definitions if necessary.

Consider, for example, the two attrib-utes—rdfs:seeAlso and rdfs:isDefinedBy—that areassociated with each class and each propertyin RDFS. The rdfs:seeAlso property specifiesanother resource containing informationabout the subject resource, and the rdfs:isDe-finedBy property indicates the resource defin-ing the subject resource. The values of theseproperties are other resources or URIs point-ing to other resources. We must add these twofields that the Protégé-2000 itself does nothave to each class and slot form in our knowl-edge base. To add these fields, we define anew metaclass that will serve as a templatefor RDFS classes. This metaclass is, in fact,equivalent to the RDFS class rdfs:Class. Figure7 shows the definition of rdfs:Class with the newtemplate slots that will appear on each classform that uses this template.

The user-interface levelWhen creating a Protégé-based editor for a

new language, we can change both the behav-ior and the look and feel of the knowledge-acquisition forms to reflect the terminologyand the features of the language. First, we canchange the labels on the forms—the simplesttype of customization. For example, we caneasily replace Protégé’s “Template slots”label in a class definition with the RDFS“Properties” label to give the form an RDFSlook. Other elements that we can easily con-figure by manipulating the forms includewhether or not a field should be visible to the



Table 2. Creating the Protégé-based RDFS editor.

Category (1) Concepts in RDFS (2) Concepts in RDFS (3) Concepts in RDFS (4) Concepts in Protégéthat are (nearly) identical that can be encoded that do not have an that do not haveto Protégé concepts as native Protégé concepts equivalent in native Protégé an equivalent in RDFS

Modeling rdfs:Class = :STANDARD-CLASS Do not use explicit rdfs:domain and rdfs:Class is a default for Cardinality, inverse slot, rdfs:subClassOf = rdfs:range for properties; rdfs: metaclass, and rdf:Property is a and default value facets;

subclass of domain encoded as slot attachment; default metaslot; add properties multiple allowed classesrdf:type = instance of rdfs:range encoded as allowed class rdfs:isDefinedBy, rdfs:seeAlso for a slotrdf:Property = Instance-typed slots as core slots; add

:STANDARD-SLOT rdfs:ConstraintProperty and rdfs:subPropertyOf = rdfs:ConstraintResource as

subslot of core classes; multiple types of rdfs:Resource = :THING an instancerdf:comment =

:DOCUMENTATION

User Custom labels on class Plug-in URI slot widget for Disable default-value andinterface and slots forms (for validating URI-type slots. inverse-slot widgets on

example, “Properties” slot forms.and “Comment”)

Back end Map Protégé concepts Translate slot attachments On import, create new class Write out extra facet informationdirectly to RDFS concepts as rdfs:domain for as a subclass of the multiple as Protégé-specific properties

properties and allowed types. on properties. If a slot has classes as rdfs:range multiple allowed classes, create

a new class for rdfs:range value. On import, do the reverse.

user, the buttons on the fields, the position andsize of the fields, and the slot widgets to beused for each field. We perform this configu-ration entirely in the Protégé-2000 Forms taband not in the programming code.

We could also develop our own slot-wid-get plug-ins to allow editing and verificationof elements that are unique to our language.For example, a URI widget in the Protégé-RDF editor can validate that the user hasentered a correct URI or even take the userto the corresponding Web page.

Disabling fields for some slots on the formprevents the user from exercising Protégé-2000 features that the particular Semantic Weblanguage does not support. For example, wecan disable the field for entering default slotvalues in the Protégé-RDFS editor, becauseRDFS does not support default values.

The back-end levelWhatever the differences between Protégé-

2000 and our language that we could notresolve at the modeling and user-interface lev-els, we will need to reconcile in the modulethat saves the internal Protégé-2000 repre-

sentation in the required output file format—the back-end plug-in. The back-end plug-in

1. saves a Protégé-2000 knowledge base ina file format that conforms to the syntaxof our language of choice;

2. maps the elements of the Protégé-2000knowledge base that do not have a directequivalent in our language to the appro-priate set of elements in this language; and

3. imports domain models in this languagethat were developed elsewhere for edit-ing in Protégé-2000.

Usually, when developers define a lan-guage with a new syntax, they quickly imple-ment a parser that allows developers to readand write files in that language’s syntax.Many of the new languages are extensions ofXML or RDF, and thus we can often use theexisting XML and RDF parsers to take careof the syntactic part of adapting to the newlanguage.

In RDFS, the back end must deal with anumber of issues that we did not resolve atthe modeling level or in the user interface. We

might have resolved some of these issuesthere, but it would have unnecessarily com-plicated the editor for the user. For example,instances in Protégé-2000 are of a singleclass, whereas in RDFS they can be directinstances of several classes (for example, theyhave several direct types). Because the RDFSmodel is more general, we have no problemin saving a Protégé-2000 knowledge base inRDFS. However, when we import RDFSinstance data into Protégé-2000, we must dealwith instances that have several direct types.Suppose we have a class for red wines and aclass for dessert wines. We have Romariz Port asan instance of both classes in RDFS. Whenwe import this RDFS instance data into Pro-tégé-2000, the back end can create a new classthat is a subclass of both classes (for exam-ple, denoting a concept of dessert red wines)and make the Romariz Port instance an instanceof this new class. We can record the two orig-inal classes of Romariz Port as additional slotson the newly created class (as shown in Fig-ure 4). When saving back to RDFS, the backend can extract the information from this slot,thus preserving the original model.


The additional slotsdefining RFDS-specific

properties

Figure 7. A template definition for classes in RDFS. The class rdfs:Class inherits most of the slots from the standard class template, butthe two slots at the top of the list of properties are the ones that we defined for RDFS.

Any user-defined back end has the samestatus as all the other back ends, includingthe ones that are part of the core Protégé-2000 system: it can be used as a storage for-mat for Protégé-2000 knowledge bases.Therefore, there is another, no less impor-tant, goal of a back-end plug-in: to ensurethat when we create a knowledge base in Pro-tégé-2000, save it using the back-end plug-in,and load it again, we have preserved all theinformation. Hence, we must find a way tostore the elements that Protégé-2000 sup-ports, but that our language of choice doesnot. Most Semantic Web languages are flex-ible enough to easily store this information.For example, in RDFS, we simply add newProtégé-specific properties to slots to recorddefault values, which RDFS does not have.These properties have no meaning to anotherRDFS agent, but if we read the knowledge

base back in Protégé-2000, we will have thedefault values preserved.

Creating new tabs to includeother semantic modules

In addition to creating a Protégé-basededitor for a new Semantic Web language,developers can plug in other applications inthe knowledge-base–editing environment. Inaddition to the standard tabs that constitutethe Protégé-2000 user interface (Figures 2and 4), developers can create tab plug-ins inthe same way they can plug in new slot wid-gets. These tabs can include arbitrary appli-cations that benefit from the live connectionto the knowledge base. These applicationsthen become an integral part of the knowl-edge-base–editing environment.

Consider our wine example again. Havingcreated a knowledge base of wines and food

and the appropriate combinations, we mightwant to build an application that produceswine suggestions for a meal course in a restau-rant. Such an application would actively usethe data in the knowledge base but it wouldalso implement its own reasoning mechanismto analyze suggestions. We can implement thiswine-selection application as a tab plug-in.

In practical terms, a tab plug-in is a sepa-rate application, a developer’s own user-interface space from which the developer canconnect to, query, and update the current Pro-tégé-2000 knowledge base.

In the realm of the Semantic Web, a tabcan include any applications that would helpus acquire or annotate the knowledge base.Such applications can

• enable direct annotation of HTML pageswith semantic elements;



Auxilliary coreclasses

Figure 8. The definition for the spicy-red-meat-course class in the Protégé-OIL editor. In addition to the standard fields, such as thoseshown in Figure 2 ), we have OIL-specific fields such as hasPropertyRestriction and subClassOf for specifying complex class expressions.These slots use the OIL-specific slot widget to display expressions. The tree on the left contains the auxiliary core classes wedefined for OIL.

• provide connection to external reasoningand inference resources;

• acquire the semantic data automaticallyfrom text; and

• present a graphical view of a set of inter-related resources.

Using Protégé to edit DAML+OILDAML+OIL, the Semantic Web language

that was heavily inspired by research indescription logics (DL), allows more typesof concept definitions in ontologies than Pro-tégé-2000 and RDFS do. The DL-inspiredlanguages usually include the following fea-tures in addition to the ones found in the tra-ditional frame-based languages:

• We can specify not only necessary but alsosufficient conditions for class membership.For example, if a wine is produced by awinery from the Bordeaux region, it is aBordeaux wine.

• We can use arbitrary Boolean expressionsin class and slot definitions to specifysuperclasses of a class, domain and rangeof a slot, and so on. For example, a spicyred-meat course must contain red meat andmust contain food that is itself spicy orfood containing something that is spicy.

• We can specify global slot properties. Forexample, location is a transitive property: ifthe Château Lafite Rothschild winery is in the Bor-deaux region and the Bordeaux region is inFrance, then the Château Lafite Rothschild wineryis in France.

• We can define global axioms that expressadditional properties of classes. For exam-ple, we can say that the classification ofthe class of all wines into the subclassesfor red, white, and rosé wines is disjoint:Each instance of the Wine class belongsonly to one of these subclasses.

We have adapted Protégé-2000 to work asan OIL editor. (The OIL language is a pre-cursor for DAML+OIL.) In doing so, we fol-lowed the same steps we described in creat-ing the Protégé-based RDFS editor. Inaddition, we have integrated external servicesfor OIL ontologies into Protégé-2000. Inte-grating DAML+OIL would require nearlyidentical steps.

The modeling levelWe introduce the new class and slot tem-

plates, OilClass and OilProperty, to specify com-plex class and slot definitions. As a result, a

class template, for example, acquires thesethree new fields (see Figure 8):

1. type—to specify whether the class defin-ition contains only necessary or bothnecessary and sufficient conditions forclass membership;

2. hasPropertyRestriction—to specify complexexpressions for slot restrictions; and

3. subclassOf—to specify complex expres-sions describing the position of the classin the class hierarchy.

To integrate OIL into Protégé-2000, we usedthe names from the RDFS serialization syntaxof (Standard-)OIL and not the plain ASCII ver-sion. See www.ontoknowledge.org/oil/ for thevarious syntaxes and versions.

Just as for RDFS, we use as many nativeProtégé-2000 mechanisms for modeling OILontologies as possible. If a new class is sim-ply a subclass of several existing classes inthe hierarchy, we use Protégé’s own notion ofsubclasses by placing the new class where itbelongs in the hierarchy. However, if a super-class definition requires boolean expres-sions—something Protégé-2000 does notallow—we use the subClassOf field that we seeon the template. Even though Protégé-2000does not understand the semantics of thisfield, we can represent this additional super-class information declaratively, and then passit to a classifier or simply save in OIL.

We use the hasPropertyRestriction field when weneed complex expressions or when we needto specify existential slot constraints: Protégé-2000 allows definition of value-type con-straints on slots (“All values of this slot mustbe instances of this class”). OIL allows exis-tential slot constraints in addition to the value-type constraints (“One value of this slot mustcome from this class and one value mustcome from that class”). We build the complexexpressions declaratively by creatinginstances of core auxiliary classes. We cansee some of these core classes in the tree inFigure 8. In the example, we specify a sub-class of a meal-course, spicy-red-meat-course, whichwe define as “a course that must contain redmeat and must contain food that is itself spicyor food containing something that is spicy.”

Even though Protégé-2000 does not sup-port some of the semantics that OIL has, wecan still encode the additional informationdeclaratively. Protégé-2000 will “ignore” theinformation, but it will be able to pass it onto a classifier or to encode it in OIL so that anOIL agent can understand it.

The user-interface levelApart from changing labels and rearrang-

ing fields on the forms for the OilClass and Oil-Property templates, we created a new slot widgetto allow easier editing of nested expressionssuch as the ones representing “food that isitself spicy or food containing something thatis spicy” in Figure 8. This widget augmentsthe standard Protégé-2000 widget for select-ing and creating values for instance-valuedslots with a display of the nested expressionsin a more practical form. A further extensionof this simple but effective slot widget caninclude a full context-sensitive, validatingexpression editor.

The back-end levelWe describe here an OIL back end that pro-

duces the RDFS output for OIL. Therefore,we can build largely on the existing RDFSback end. In defining the class and slot namesand the structure of the auxiliary core classesin the OIL editor, we have mainly adhered tothe RDFS specification of OIL. As a result,just using the RDFS back end, described ear-lier, gives us an output that is very close butnot identical to the RDFS OIL output that weneed. Thus, to create the OIL back end, westarted with the existing RDFS back end. Weadapted it to add the parts of definitions spec-ified by the native Protégé-2000 means to thecomplex class expressions.

The OIL back end encodes the conceptsthat Protégé-2000 has and OIL does not(global cardinality restrictions on slots, forexample) by defining additional statementsin a Protégé namespace. An OIL agent willnot understand these statements and willignore them, but Protégé-2000 will be able toextract the necessary information from them.

Because many Semantic Web languagesare in their infancy and already come in manydifferent versions, there is an alternativeapproach to developing specific back endsfor each of these versions. We can create ageneral RDF back end for Protégé-2000 andthen use a declarative and easily adaptableRDF transformation language for generatingthe desired outputs. Some research groupsare currently investigating such a back endand the corresponding RDF transformation(and query) language.

Accessing external services througha tab plug-in

The DL languages, such as OIL andDAML+OIL, traditionally rely on an infer-ence component—a classifier—to find the


right position of a class in the class hierar-chy and to determine which class definitionsare unsatisfiable (cannot have any instances).Therefore, it is crucial to have a connectionto a DL classifier as part of the environmentfor editing OIL and DAML+OIL ontologies.Having created a set of definitions, we caninvoke the classifier to determine how theevolving class hierarchy looks. We can seethe effects that changes in class definitionswill have on the evolving hierarchy. We canimmediately check if logical expressionsdefining a class contradict one another mak-ing the class unsatisfiable.

Therefore, in order to create a full-fledgedProtégé-based OIL editor, we need to con-nect Protégé-2000 to such an inference com-ponent and present the results to the user. Weimplemented this connection as a Protégé-2000 tab plug-in.

Figure 9 shows the OIL tab in action. Ini-tially, the class hierarchy has the various meal-course subclasses as siblings. In addition, wespecify that an oyster-shellfish-course is a meal-course that has OYSTERS as the value for its FOOD slot;

a shellfish-course is a meal-course that has shellfishas its food, and so on. We then use the OIL tabto connect to a DL classifier, FaCT,6 and tohave it rearrange the class hierarchy accord-ing to the class definitions. In the resultinghierarchy, the oyster-shellfish-course class, forexample, is correctly classified as being asubclass of the shellfish-course class.

W ith the advent of the Semantic Web,the current network of online

resources is expanding from a set of staticdocuments designed mainly for human con-sumption to a new Web of dynamic docu-ments, services, and devices, which softwareagents will be able to understand. Develop-ers will likely create many different repre-sentation languages to embrace the hetero-geneous nature of these resources. Somelanguages will be used to describe specificdomains of knowledge; others will modelcapabilities of services and devices. These

languages will have different emphasis,scope, and expressive power.

Protégé-2000 provides full-fledged sup-port for knowledge modeling and acquisi-tion. Developers also can custom-tailor Pro-tégé-2000 quickly and easily to be an editorfor a new Semantic Web language. A Pro-tégé-based editor enables modeling at a con-ceptual level that allows developers to thinkin terms of concepts and relations in thedomain that they are modeling and not interms of the syntax of the final output.

By adapting Protégé-2000 to edit a newSemantic Web language rather than creatinga new editor from scratch or using a text edi-tor to create ontologies in the new language,we obtain a graphical, conceptual-levelontology editor and knowledge-acquisitiontool. We get a new editor to experiment withthe new language without investing manyresources into it. And we can use Protégé-2000 as an interchange module to translatemost of the models in other Semantic-Weblanguages into our new language and viceversa. In our experience, it takes a few days



OIL tab plugin

Figure 9. Tab plug-in for classification of OIL ontologies. On the right, we see a hierarchy of meal courses before classification. Themiddle pane shows interactions with the FaCT classifier. The hierarchy on the right is the one that the classifier computed.

to adapt Protégé-2000 to a new Semantic-Web language—a lot less time than isrequired to create any sophisticated softwarefrom scratch. We were able to create theseeditors even for a language like OIL, whichtakes a knowledge-modeling approach thatis different from the frame-based approachfor which Protégé originally was designed.The extensible and flexible knowledge modeland the open plug-in architecture of Protégé-2000 constitute the basis for developing asuite of conceptual-level editors for Seman-tic Web languages.

AcknowledgmentsFor more information about the Protégé project,

please visit http://protege.stanford.edu. A grantfrom Spawar, a grant from FastTrack Systems, andthe DARPA DAML program supported this work.

References

1. T. Berners-Lee, M. Fischetti, and M. Der-touzos, Weaving the Web: The OriginalDesign and Ultimate Destiny of the WorldWide Web by its Inventor, Harper, San Fran-cisco, 1999.

2. D. Brickley and R.V. Guha, “ResourceDescription Framework (RDF) Schema Spec-ification,” World Wide Web Consortium, Pro-posed Recommendation 1999, www.w3.org/TR/2000/CR-rdf-schema-20000327 (cur-rent 28 Mar. 2001).

3. J. Hendler and D.L. McGuinness, “TheDARPA Agent Markup Language, ” IEEEIntelligent Systems, vol. 16, no. 6, Jan./Feb.,2000, pp. 67–73.

4. N.F. Noy, R.W. Fergerson, and M.A. Musen,“The Knowledge Model of Protégé-2000:Combining Interoperability and Flexibility,”Proc. Knowledge Engineering and Knowl-edge Management: 12th Int’l Conf. (EKAW-2000), Lecture Notes in Artificial Intelligence,no. 1937, Springer-Verlag, Berlin, 2000,pp.17–32.

5. M.A. Musen et al., “Component-Based Sup-port for Building Knowledge-AcquisitionSystems, ” Proc. Conf. Intelligent Informa-tion Processing (IIP 2000) Int’l Federationfor Information Processing World ComputerCongress (WCC 2000), Beijing, China, 2000,http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-2000-0838.html (current 28Mar. 2001).

6. I. Horrocks, “The FaCT system,” Proc. Auto-mated Reasoning with Analytic Tableaux andRelated Methods: Int’l Conf. Tableaux 98, Lec-ture Notes in Artificial Intelligence, no. 1397,Springer-Verlag, Berlin, 1998, pp. 307–312.


Natalya F. Noy is a research scientist in the Stanford Medical Informaticslaboratory at Stanford University. Her interests include ontology developmentand evaluation, semantic integration of ontologies, and making ontology-development accessible to experts in noncomputer-science domains. She hasa BS in applied mathematics from Moscow State University, Russia, an MAin computer science from Boston University, and a PhD in computer sciencefrom Northeastern University in Boston. Contact her at Stanford MedicalInformatics, 251 Campus Dr., Stanford Univ., Stanford, CA 94305;[email protected].

Michael Sintek is a research scientist at the German Research Center forArtificial Intelligence. Currently, he is project leader of the FRODO projectwhere an RDF-based framework for building distributed organizational mem-ories is developed. He has a Diplom in computer science and economics fromthe University of Kaiserslautern. Contact him at the German Research Cen-ter for Artificial Intelligence (DFKI) GmbH, Knowledge Management Group,Postfach 2080, D-67608 Kaiserslautern, Germany; [email protected].

Stefan Decker is a postdoctoral fellow at the Department of Computer Sci-ence at Stanford University, where he works on Semantic Web Infrastruc-ture in the DARPA DAML program. His research interests include knowledgerepresentation and database systems for the Web, information integration,and ontology articulation and merging. He has a PhD in computer sciencefrom the University of Karlsruhe, Germany, where he worked on ontology-based access to information. Contact him at Stanford University, Gates Hall4A, Room 425, Stanford, CA 94305; [email protected].

Monica Crubézy is a postdoctoral researcher in the Stanford Medical Infor-matics laboratory at Stanford University. Her research focuses on the mod-eling and integration of libraries of problem-solving methods in the Protégéknowledge-based-system development framework. She graduated from theÉcole Polytechnique Féminine, France, in general engineering and computerscience. She has a PhD in computer science from the Institut National deRecherche en Informatique et Automatique in Sophia Antipolis, France. Con-tact her at Stanford Medical Informatics, 251 Campus Drive,Stanford Uni-versity, Stanford, CA 94305; [email protected].

Ray Fergerson is a programmer in the Stanford Medical Informatics labo-ratory at Stanford University. He has a BS in physics from the ColoradoSchool of Mines and a PhD in experimental nuclear physics from the Uni-versity of Texas in Austin. Contact him at Stanford Medical Informatics, 251Campus Drive, Stanford University, Stanford, CA 94305; [email protected].

Mark A. Musen’s biography appears in the Guest Editors’ Introduction on page 25.

T h e A u t h o r s



Ontology Learning forthe Semantic WebAlexander Maedche and Steffen Staab, University of Karlsruhe

The Semantic Web relies heavily on formal ontologies to structure data for com-

prehensive and transportable machine understanding. Thus, the proliferation of

ontologies factors largely in the Semantic Web’s success. Ontology learning greatly helps

ontology engineers construct ontologies. The vision of ontology learning that we propose

includes a number of complementary disciplines thatfeed on different types of unstructured, semistruc-tured, and fully structured data to support semiauto-matic, cooperative ontology engineering. Our ontol-ogy-learning framework proceeds through ontologyimport, extraction, pruning, refinement, and evalua-tion, giving the ontology engineer coordinated toolsfor ontology modeling. Besides the general frame-work and architecture, this article discusses tech-niques in the ontology-learning cycle that we imple-mented in our ontology-learning environment, suchas ontology learning from free text, dictionaries, andlegacy ontologies. We also refer to other techniquesfor future implementation, such as reverse engi-neering of ontologies from database schemata orlearning from XML documents.

Ontologies for the Semantic WebThe conceptual structures that define an underlying

ontology provide the key to machine-processable dataon the Semantic Web. Ontologies serve as metadataschemas, providing a controlled vocabulary of concepts,each with explicitly defined and machine-processablesemantics. By defining shared and common domain the-ories, ontologies help people and machines to commu-nicate concisely—supporting semantics exchange, notjust syntax. Hence, the Semantic Web’s success and pro-liferation depends on quickly and cheaply constructingdomain-specific ontologies.

Although ontology-engineering tools have maturedover the last decade,1 manual ontology acquisitionremains a tedious, cumbersome task that can easilyresult in a knowledge acquisition bottleneck. When

developing our ontology-engineering workbench,OntoEdit, we particularly faced this question as wewere asked questions that dealt with time (“Can youdevelop an ontology quickly?”), difficulty, (“Is it dif-ficult to build an ontology?”), and confidence (“Howdo you know that you’ve got the ontology right?”).

These problems resemble those that knowledgeengineers have dealt with over the last two decadesas they worked on knowledge acquisition method-ologies or workbenches for defining knowledgebases. The integration of knowledge acquisition withmachine-learning techniques proved extremely ben-eficial for knowledge acquisition.2 The drawback tosuch approaches,3 however, was their rather strongfocus on structured knowledge or databases, fromwhich they induced their rules.

Conversely, in the Web environment we encounterwhen building Web ontologies, structured knowl-edge bases or databases are the exception rather thanthe norm. Hence, intelligent support tools for anontology engineer take on a different meaning thanthe integration architectures for more conventionalknowledge acquisition.4

In ontology learning, we aim to integrate numerousdisciplines to facilitate ontology construction, partic-ularly machine learning. Because fully automaticmachine knowledge acquisition remains in the distantfuture, we consider ontology learning as semiauto-matic with human intervention, adopting the paradigmof balanced cooperative modeling for constructingontologies for the Semantic Web.5 With this objectivein mind, we built an architecture that combines knowl-edge acquisition with machine learning, drawing on

The authors present

an ontology-learning

framework that

extends typical

ontology engineering

environments by using

semiautomatic

ontology-construction

tools. The framework

encompasses ontology

import, extraction,

pruning, refinement,

and evaluation.

resources that we find on the syntactic Web—free text, semistructured text, schema defini-tions (such as document type definitions[DTDs]), and so on. Thereby, our framework’smodules serve different steps in the engineer-ing cycle (see Figure 1):

• Merging existing structures or definingmapping rules between these structuresallows importing and reusing existingontologies. (For instance, Cyc’s ontolog-ical structures have been used to constructa domain-specific ontology.6)

• Ontology extraction models major partsof the target ontology, with learning sup-port fed from Web documents.

• The target ontology’s rough outline, whichresults from import, reuse, and extraction,is pruned to better fit the ontology to itsprimary purpose.

• Ontology refinement profits from the prunedontology but completes the ontology at afine granularity (in contrast to extraction).

• The target application serves as a measurefor validating the resulting ontology.7

Finally, the ontology engineer can begin thiscycle again—for example, to include newdomains in the constructed ontology or tomaintain and update its scope.

ArchitectureGiven the task of constructing and main-

taining an ontology for a Semantic Webapplication such as an ontology-basedknowledge portal,8 we produced support forthe ontology engineer embedded in a com-prehensive architecture (see Figure 2). Theontology engineer only interacts via thegraphical interfaces, which comprise two ofthe four components: the OntoEdit Ontol-ogy Engineering Workbench and the Man-agement Component. Resource Processingand the Algorithm Library are the architec-ture’s remaining components.

The OntoEdit Ontology EngineeringWorkbench offers sophisticated graphicalmeans for manual modeling and refining of thefinal ontology. The interface gives the user dif-ferent views, targeting the epistemologicallevel rather than a particular representation lan-guage. However, the user can export the onto-logical structures to standard Semantic Webrepresentation languages such as OIL (ontol-ogy interchange language) and DAML-ONT(DAML ontology language), as well as our ownF-Logic-based extensions of RDF(S)—we useRDF(S) to refer to the combined technologies


Web documents

Crawlcorpus

Domain ontology

Wordnet

O1

Resultset

ResourceProcessing

Center

Natural-language-processingsystem

OntologyOntologyengineer

Processed data

O2

HTMLHTML

DTD

Legacy databases

Importschema Import

existing ontologies

XML schema

OntoEdit OntologyEngineering Workbench

AlgorithmLibrary

Resultset

Lexicon

Management Component

XML Import semistructured schema

Figure 2. Ontology-learning architecture for the Semantic Web.

Apply

Extract

Refine

Prune

Import and reuse Ontologylearning

Ontologylearning

Legacy and application data

Legacy and application data

Domain ontology

Figure 1. The ontology-learning process.

of the resource description framework andRDF Schema. Additionally, users can gener-ate and access executable representations forconstraint checking and application debuggingthrough SilRi (simple logic-based RDF inter-preter, www.ontoprise.de), our F-Logic infer-ence engine, which connects directly toOntoEdit.

We knew that sophisticated ontology-engi-neering tools—for example, the Protégé mod-eling environment for knowledge-based sys-tems1—would offer capabilities roughlycomparable to OntoEdit. However, in tryingto construct a knowledge portal, we foundthat a large conceptual gap existed betweenthe ontology-engineering tool and the input(often legacy data), such as Web documents,Web document schemata, databases on theWeb, and Web ontologies, which ultimatelydetermine the target ontology. Into this voidwe have positioned new components of ourontology-learning architecture (see Figure 2).The new components support the ontologyengineer in importing existing ontology prim-itives, extracting new ones, pruning givenones, or refining with additional ontologyprimitives. In our case, the ontology primi-tives comprise

• a set of strings that describe lexical entriesL for concepts and relations;

• a set of concepts C (roughly akin tosynsets in WordNet9);

• a taxonomy of concepts with multipleinheritance (heterarchy) HC;

• a set of nontaxonomic relations Rdescribed by their domain and rangerestrictions;

• a heterarchy of relations—HR;• relations F and G that relate concepts and

relations with their lexical entries; and• a set of axioms A that describe additional

constraints on the ontology and makeimplicit facts explicit.8

This structure corresponds closely toRDF(S), except for the explicit considerationof lexical entries. Separating concept refer-ence from concept denotation permits verydomain-specific ontologies without incur-ring an instantaneous conflict when merg-ing ontologies—a standard Semantic Webrequest. For instance, the lexical entry schoolin one ontology might refer to a building inontology A, an organization in ontology B,or both in ontology C. Also, in ontology A,we can refer to the concept referred to inEnglish by school and school building by the

German Schule and Schulgebäude.Ontology learning relies on an ontology

structured along these lines and on input dataas described earlier to propose new knowledgeabout reasonably interesting concepts, rela-tions, and lexical entries or about links betweenthese entities—proposing some for addition,deletion, or merging. The graphical result setpresents the ontology-learning process’sresults to the ontology engineer (we’ll discussthis further in the “Association rules” section).The ontology engineer can then browse theresults and decide to follow, delete, or modifythe proposals, as the task requires.

ComponentsBy integrating the previously discussed con-

siderations into a coherent generic architecturefor extracting and maintaining ontologies fromWeb data, we have identified several core com-ponents (including the graphical user interfacediscussed earlier).

Management component graphical user interface

The ontology engineer uses the manage-ment component to select input data—that is,relevant resources such as HTML and XMLdocuments, DTDs, databases, or existingontologies that the discovery process can fur-ther exploit. Then, using the managementcomponent, the engineer chooses from a setof resource-processing methods available inthe resource-processing component and froma set of algorithms available in the algorithmlibrary.

The management component also supportsthe engineer in discovering task-relevantlegacy data—for example, an ontology-basedcrawler gathers HTML documents that are rel-evant to a given core ontology.

Resource processingDepending on the available input data, the

engineer can choose various strategies forresource processing:

• Index and reduce HTML documents tofree text.

• Transform semistructured documents,such as dictionaries, into a predefined rela-tional structure.

• Handle semistructured and structuredschema data (such as DTDs, structureddatabase schemata, and existing ontolo-gies) by following different strategies forimport, as described later in this article.

• Process free natural text. Our systemaccesses the natural-language-processingsystem Saarbrücken Message ExtractionSystem, a shallow-text processor for Ger-man.10 SMES comprises a tokenizerbased on regular expressions, a lexicalanalysis component including variousword lexicons, an amorphological analy-sis module, a named-entity recognizer,a part-of-speech tagger, and a chunkparser.

After first preprocessing data according to oneof these or similar strategies, the resource-pro-cessing module transforms the data into analgorithm-specific relational representation.

Algorithm libraryWe can describe an ontology by a number

of sets of concepts, relations, lexical entries,and links between these entities. We canacquire an existing ontology definition(including L, C, HC, R, HR, A, F, and G),using various algorithms that work on thisdefinition and the preprocessed input data.Although specific algorithms can varygreatly from one type of input to the next, aconsiderable overlap exists for underlyinglearning approaches such as associationrules, formal concept analysis, or clustering.Hence, we can reuse algorithms from thelibrary for acquiring different parts of theontology definition.

In our implementation, we generally usea multistrategy learning and result combina-tion approach. Thus, each algorithm pluggedinto the library generates normalized resultsthat adhere to the ontology structures we’vediscussed and that we can apply toward acoherent ontology definition.

Import and reuseGiven our experiences in medicine,



In trying to construct a

knowledge portal, we found that a

large conceptual gap existed

between the ontology-

engineering tool and the input

(often legacy data).

telecommunications, tourism, and insurance,we expect that domain conceptualizations areavailable for almost any commercially signif-icant domain. Thus, we need mechanisms andstrategies to import and reuse domain con-ceptualizations from existing (schema) struc-tures. We can recover the conceptualizations,for example, from legacy database schemata,DTDs, or from existing ontologies that con-ceptualize some relevant part of the targetontology.

In the first part of import and reuse, weidentify the schema structures and discusstheir general content with domain experts.We must import each of these knowledgesources separately. We can also import man-ually—which can include a manual defini-tion of transformation rules. Alternatively,reverse-engineering tools—such as thosethat exist for recovering extended entity-relationship diagrams from a given data-base’s SQL description (see the sidebar)—might facilitate the recovery of conceptualstructures.

In the second part of the import and reusestep, we must merge or align imported con-

ceptual structures to form a single commonground from which to springboard into thesubsequent ontology-learning phases ofextracting, pruning, and refining. Althoughthe general research issue of merging andaligning is still an open problem, recent pro-posals have shown how to improve the man-ual merging and aligning process. Existingmethods mostly rely on matching heuristicsfor proposing the merger of concepts and sim-ilar knowledge base operations. Our researchalso integrates mechanisms that use an appli-cation-data–oriented, bottom-up approach.11

For instance, formal concept analysis lets usdiscover patterns between application dataand the use of concepts, on one hand, andtheir heterarchies’relations and semantics, onthe other, in a formally concise way (see B.Ganter and R. Wille’s work on formal con-cept analysis in the sidebar).

Overall, the ontology-learning import andreuse step seems to be the hardest to general-ize. The task vaguely resembles the generalproblems encountered in data-warehousing—adding, however, challenging problems of its own.

ExtractionOntology-extraction models major

parts—the complete ontology or largechunks representing a new ontology sub-domain—with learning support exploitingvarious types of Web sources. Ontology-learning techniques partially rely on givenontology parts. Thus, we here encounter aniterative model where previous revisionsthrough the ontology-learning cycle canpropel subsequent ones, and more sophis-ticated algorithms can work on structuresthat previous, more straightforward algo-rithms have proposed.

To describe this phase, let’s look at someof the techniques and algorithms that weembedded in our framework and imple-mented in our ontology-learning environ-ment Text-To-Onto (see Figure 3). Wecover a substantial part of the overall ontol-ogy-learning task in the extraction phase.Text-To-Onto proposes many differentontology learning algorithms for primi-tives, which we described previously (thatis, L, C, R, and so on), to the ontology engi-neer building on several types of input.


Figure 3. Screenshot of our ontology-learning workbench, Text-To-Onto.


Until recently, ontology learning—for comprehensive ontol-ogy construction—did not exist. However, much work in numer-ous disciplines—computational linguistics, information retrieval,machine learning, databases, and software engineering—hasresearched and practiced techniques that we can use in ontol-ogy learning. Hence, we can find techniques and methods rel-evant for ontology learning referred to as

• “acquisition of selectional restrictions,”1,2

• “word sense disambiguation and learning of word senses,”3

• “computation of concept lattices from formal contexts,”4 and• “reverse engineering in software engineering.”5

Ontology learning puts many research activities—which focuson different input types but share a common domain conceptu-alization—into one perspective. The activities in Table A span avariety of communities, with references from 20 completely dif-ferent events and journals.

References1. P. Resnik, Selection and Information: A Class-Based Approach to

Lexical Relationships, PhD thesis, Dept. of Computer Science, Univ.of Pennsylvania, Philadelphia, 1993.

2. R. Basili, M.T. Pazienza, and P. Velardi, “Acquisition of SelectionalPatterns in a Sublanguage,” Machine Translation, vol. 8, no. 1, 1993,pp. 175–201.

3. P. Wiemer-Hastings,A. Graesser, and K. Wiemer-Hastings, “Inferringthe Meaning of Verbs from Context,” Proc. 20th Ann. Conf. CognitiveScience Society (CogSci-98), Lawrence Erlbaum, New York, 1998.

4. B. Ganter and R. Wille, Formal Concept Analysis: MathematicalFoundations, Springer-Verlag, Berlin, 1999.

5. H.A. Mueller et al., “Reverse Engineering: A Roadmap,” Proc. Int’lConf. Software Eng. (ICSE-00),ACM Press, New York, 2000, pp. 47–60.

6. P. Buitelaar,CORELEX Systematic Polysemy and Underspecification,PhDthesis,Dept. of Computer Science,Brandeis Univ.,Waltham,Mass., 1998.

7. H. Assadi, “Construction of a Regional Ontology from Text and ItsUse within a Documentary System,” Proc. Int’l Conf. Formal Ontol-ogy and Information Systems (FOIS-98), IOS Press, Amsterdam.

8. D. Faure and C. Nedellec, “A Corpus-Based Conceptual ClusteringMethod for Verb Frames and Ontology Acquisition,” Proc. LREC-98Workshop on Adapting Lexical and Corpus Resources to Sublan-guages and Applications, European Language Resources—Distrib-ution Agency, Paris, 1998.

9. F. Esposito et al., “Learning from Parsed Sentences with INTHELEX,”Proc. Learning Language in Logic Workshop (LLL-2000) and Learn-ing Language in Logic Workshop (LLL-2000), Assoc. for Computa-tional Linguistics, New Brunswick, N.J., 2000, pp. 194-198.

10. A. Maedche and S. Staab, “Discovering Conceptual Relations fromText,” Proc. European Conf. Artificial Intelligence (ECAI-00), IOSPress, Amsterdam, 2000, pp. 321–325.

11. J.-U. Kietz,A. Maedche, and R. Volz, “Semi-Automatic Ontology Acqui-sition from a Corporate Intranet.” Proc. Learning Language in LogicWorkshop (LLL-2000), ACL, New Brunswick, N.J., 2000, pp. 31–43.

12. E. Morin, “Automatic Acquisition of Semantic Relations betweenTerms from Technical Corpora,” Proc. of the Fifth Int’l Congress onTerminology and Knowledge Engineering (TKE-99), TermNet-Ver-lag, Vienna, 1999.

13. U. Hahn and K. Schnattinger, “Towards Text Knowledge Engineer-ing,” Proc. Am. Assoc. for Artificial Intelligence (AAAI-98),AAAI/MIT Press, Menlo Park, Calif., 1998.

14. M.A. Hearst, “Automatic Acquisition of Hyponyms from Large TextCorpora,” Proc. Conf. Computational Linguistics (COLING-92), 1992.

15. Y. Wilks, B. Slator, and L. Guthrie, Electric Words: Dictionaries,Computers, and Meanings, MIT Press, Cambridge, Mass., 1996.

16. J. Jannink and G. Wiederhold, “Thesaurus Entry Extraction from anOn-Line Dictionary,” Proc. Second Int’l Conf. Information Fusion(Fusion-99), Omnipress, Wisconsin, 1999.

17. J.-U. Kietz and K. Morik, “A Polynomial Approach to the Con-structive Induction of Structural Knowledge,” Machine Learning,vol. 14, no. 2, 1994, pp. 193–211.

18. S. Schlobach, “Assertional Mining in Description Logics,” Proc. 2000Int’l Workshop on Description Logics (DL-2000), 2000; http://Sun-SITE.Informatik.RWTH-Aachen.DE/Publications/CEUR-WS/Vol-33.

19. A. Doan, P. Domingos, and A. Levy, “Learning Source Descriptionsfor Data Integration,” Proc. Int’l Workshop on The Web and Data-bases (WebDB-2000), Springer-Verlag, Berlin, 2000, pp. 60–71.

20. P. Johannesson, “A Method for Transforming Relational Schemasinto Conceptual Schemas,” Proc. Int’l Conf. Data Engineering(IDCE-94), IEEE Press, Piscataway, N.J., 1994, pp. 190–201.

21. Z. Tari et al., “The Reengineering of Relational Databases Based onKey and Data Correlations,” Proc. Seventh Conf. Database Seman-tics (DS-7), Chapman & Hall, 1998, pp. 40–52.

A Common Perspective

Table A. A survey of ontology-learning approaches.

Domain Methods Features used Prime purpose Papers

Free Text Clustering Syntax Extract Paul Buitelaar,6 H. Assadi,7 and David Faure and Claure Nedellec8

Inductive logic Syntax, logic Extract Frederique Esposito et al.9programming representation

Association rules Syntax, Tokens Extract Alexander Maedche and Steffen Staab10

Frequency-based Syntax Prune Joerg-Uwe Kietz et al.11

Pattern matching — Extract Emanuelle Morin12

Classification Syntax, semantics Refine Udo Hahn and Klemens Schnattinger13

Dictionary Information extraction Syntax Extract Marti Hearst,14 Yorik Wilks,15 and Joerg-Uwe Kietz et al.11

Page rank Tokens — Jan Jannink and Gio Wiederhold16

Knowledge base Concept induction, Relations Extract Joerg-Uwe Kietz and Katharina Morik17 and S. Schlobach18

A-Box mining

Semistructured Naive Bayes Relations Reverse engineering Anahai Doan et al.19

schemata

Relational Data correlation Relations Reverse engineering Paul Johannesson20 and Zahir Tari et al.21

schemata

Lexical entry and concept extractionOne of the baseline methods applied in our

framework for acquiring lexical entries withcorresponding concepts is lexical entry andconcept extraction. Text-To-Onto processesWeb documents on the morphological level,including multiword terms such as “databasereverse engineering” by n-grams, a simple sta-tistics-based technique. Based on this text pre-processing, we apply term-extraction tech-niques, which are based on (weighted)statistical frequencies, to propose new lexicalentries for L.

Often, the ontology engineer follows theproposal by the lexical entry and concept-extraction mechanism and includes a new lex-ical entry in the ontology. Because the newlexical entry comes without an associated con-cept, the ontology engineer must then decide(possibly with help from further processing)whether to introduce a new concept or link thenew lexical entry to an existing concept.

Hierarchical concept clusteringGiven a lexicon and a set of concepts, one

major next step is taxonomic concept classifi-cation. One generally applicable method withregard to this is hierarchical clustering, whichexploits items’ similarities to propose a hier-archy of item categories. We compute the sim-ilarity measure on the properties of items.

When extracting a hierarchy from natural-language text, term adjacency or syntacticalrelationships between terms yield consider-able descriptive power to induce the semantichierarchy of concepts related to these terms.

David Faure and Claure Nedellec give asophisticated example for hierarchical clus-tering (see the sidebar). They present a coop-erative machine-learning system, Asium(acquisition of semantic knowledge usingmachine-learning method), which acquirestaxonomic relations and subcategorizationframes of verbs based on syntactic input. TheAsium system hierarchically clusters nounsbased on the verbs to which they are syntac-tically related and vice versa. Thus, theycooperatively extend the lexicon, the conceptset, and the concept heterarchy (L, C, HC).

Dictionary parsingMachine-readable dictionaries are fre-

quently available for many domains. Althoughtheir internal structure is mostly free text, com-paratively few patterns are used to give textdefinitions. Hence, MRDs exhibit a largedegree of regularity that can be exploited toextract a domain conceptualization.

We have used Text-To-Onto to generate aconcept taxonomy from an insurance com-pany’s MRD (see the sidebar). Likewise,we’ve applied morphological processing toterm extraction from free text—this time,however, complementing several pattern-matching heuristics. Take, for example, thefollowing dictionary entry:

Automatic Debit Transfer: Electronic servicearising from a debit authorization of the YellowAccount holder for a recipient to debit bills thatfall due direct from the account….

We applied several heuristics to the mor-phologically analyzed definitions. Forinstance, one simple heuristic relates the defi-nition term, here automatic debit transfer, with

the first noun phrase in the definition, here elec-tronic service. The heterarchy HC : HC (auto-matic debit transfer, electronic service) linkstheir corresponding concepts. Applying thisheuristic iteratively, we can propose large partsof the target ontology—more precisely, L, C,and HC to the ontology engineer. In fact,because verbs tend to be modeled as relations,we can also use this method to extend R (andthe linkage between R and L).

Association rulesOne typically uses association-rule-learn-

ing algorithms for prototypical applications ofdata mining—for example, finding associa-tions that occur between items such as super-market products in a set of transactions forexample customers’ purchases. The general-ized association-rule-learning algorithm ex-tends its baseline by aiming at descriptions atthe appropriate taxonomy level—for example,“snacks are purchased together with drinks,”rather than “chips are purchased with beer,”and “peanuts are purchased with soda.”

In Text-To-Onto (see the sidebar), we usea modified generalized association-rule-learning algorithm to discover relationsbetween concepts. A given class hierarchyHC serves as background knowledge. Pairsof syntactically related concepts—for exam-ple, pair (festival,island) describing thehead–modifier relationship contained in thesentence “The festival on Usedom attractstourists from all over the world.”—are givenas input to the algorithm. The algorithm gen-erates association rules that compare the rel-evance of different rules while climbing up ordown the taxonomy. The algorithm proposeswhat appears to be the most relevant binaryrules to the ontology engineer for modelingrelations into the ontology, thus extending R.

As the algorithm tends to generate a highnumber of rules, we offer various interactionmodes. For example, the ontology engineercan restrict the number of suggested relationsby defining so-called restriction concepts thatmust participate in the extracted relations.The flexible enabling and disabling of taxo-nomic knowledge for extracting relations isanother way of focusing.

Figure 4 shows various views of theresults. We can induce a generalized relationfrom the example data given earlier—relationrel(event,area), which the ontology engineercould name locatedin, namely, events located inan area (which extends L and G). The user canadd extracted relations to the ontology bydragging and dropping them. To explore anddetermine the right aggregation level ofadding a relation to the ontology, the user canbrowse the relation views for extracted prop-erties (see the left side of Figure 4).

PruningA common theme of modeling in various

disciplines is the balance between com-pleteness and domain-model scarcity. Tar-geting completeness for the domain modelappears to be practically unmanageable andcomputationally intractable, but targeting thescarcest model overly limits expressiveness.Hence, we aim for a balance between the twothat works. Our model should capture a richtarget-domain conceptualization but excludethe parts out of its focus. Ontology importand reuse as well as ontology extraction putthe scale considerably out of balance whereout-of-focus concepts reign. Therefore, weappropriately diminish the ontology in thepruning phase.

We can view the problem of pruning in atleast two ways. First, we need to clarify how


Targeting completeness for the

domain model appears to be

practically unmanageable and

computationally intractable, but

targeting the scarcest model

overly limits expressiveness.

pruning particular parts of the ontology (forexample, removing a concept or relation)affects the rest. For instance, Brian Petersonand his colleagues have described strategiesthat leave the user with a coherent ontology(that is, no dangling or broken links).6 Second,we can consider strategies for proposing ontol-ogy items that we should either keep or prune.Given a set of application-specific documents,several strategies exist for pruning the ontol-ogy that are based on absolute or relativecounts of term frequency combined with theontology’s background knowledge (see thesidebar).

RefinementRefining plays a similar role to extract-

ing—the difference is on a sliding scalerather than a clear-cut distinction. Although

extracting serves mainly for cooperativemodeling of the overall ontology (or at leastof very significant chunks of it), the refine-ment phase is about fine-tuning the targetontology and the support of its evolvingnature. The refinement phase can use datathat comes from a concrete Semantic Webapplication—for example, log files of userqueries or generic user data. Adapting andrefining the ontology with respect to userrequirements plays a major role in theapplication’s acceptance and its furtherdevelopment.

In principle, we can use the same algo-rithms for extraction and refinement. How-ever, during refinement, we must considerin detail the existing ontology and its exist-ing connections, while extraction worksmore often than not practically from scratch.

Udo Hahn and Klemens Schnattingerpresented a prototypical approach for re-finement (see the sidebar)—although notfor extraction! They introduced a method-ology for automating the maintenance ofdomain-specific taxonomies. This incre-mentally updates an ontology as it acquiresnew concepts from text. The acquisitionprocess is centered on the linguistic andconceptual “quality” of various forms ofevidence underlying concept-hypothesisgeneration and refinement. Particularly, todetermine a particular proposal’s quality,Hahn and Schnattinger consider semanticconflicts and analogous semantic structuresfrom the knowledge base for the ontology,thus extending an existing ontology withnew lexical entries for L, new concepts forC, and new relations for HC.



Figure 4. Result presentation in Text-To-Onto.


Ontology learning could add significantleverage to the Semantic Web because

it propels the construction of domain ontolo-gies, which the Semantic Web needs to suc-ceed. We have presented a comprehensiveframework for ontology learning that crossesthe boundaries of single disciplines, touch-ing on a number of challenges. The goodnews is, however, that you don’t need perfector optimal support for cooperative ontologymodeling. At least according to our experi-ence, cheap methods in an integrated envi-ronment can tremendously help the ontologyengineer.

While a number of problems remainwithin individual disciplines, additional chal-lenges arise that specifically pertain to apply-ing ontology learning to the Semantic Web.With the use of XML-based namespacemechanisms, the notion of an ontology withwell-defined boundaries—for example, onlydefinitions that are in one file—will disap-pear. Rather, the Semantic Web might yieldan amoeba-like structure regarding ontologyboundaries because ontologies refer to andimport each other (for example, the DAML-ONT primitive import). However, we do notyet know what the semantics of these struc-tures will look like. In light of these facts, theimportance of methods such as ontologypruning and crawling will drasticallyincrease. Moreover, we have so far restrictedour attention in ontology learning to the con-ceptual structures that are almost containedin RDF(S). Additional semantic layers on topof RDF (for example, future OIL or DAML-ONT with axioms, A) will require newmeans for improved ontology engineeringwith axioms, too!

AcknowledgmentsWe thank our students, Dirk Wenke, and

Raphael Volz for work on OntoEdit and Text-To-Onto. Swiss Life/Rentenanstalt (Zurich,Switzerland), Ontoprise GmbH (Karlsruhe,Germany), the US Air Force DARPA DAML(“OntoAgents” project), the European Union(IST-1999-10132 “On-To-Knowledge” project),and the German BMBF (01IN901C0 “GETESS”project) partly financed research for this article.

References

1. E. Grosso et al., “Knowledge Modeling at theMillennium—the Design and Evolution ofProtégé-2000,” Proc. 12th Int’l WorkshopKnowledge Acquisition, Modeling and Man-agement (KAW-99), 1999.

2. G. Webb, J. Wells, and Z. Zheng, “An Exper-imental Evaluation of Integrating MachineLearning with Knowledge Acquisition,”Machine Learning, vol. 35, no. 1, 1999, pp.5–23.

3. K. Morik et al., Knowledge Acquisition andMachine Learning: Theory, Methods, andApplications, Academic Press, London,1993.

4. B. Gaines and M. Shaw, “Integrated Knowl-edge Acquisition Architectures,” J. IntelligentInformation Systems, vol. 1, no. 1, 1992, pp.9–34.

5. K. Morik, “Balanced Cooperative Modeling,”Machine Learning, vol. 11, no. 1, 1993, pp.217–235.

6. B. Peterson, W. Andersen, and J. Engel,“Knowledge Bus: Generating Application-

Focused Databases from Large Ontologies,”Proc. Fifth Workshop Knowledge Represen-tation Meets Databases (KRDB-98), 1998,http://sunsite.informatik.rwth-aachen.de/Pub-lications/CEUR-WS/Vol-10 (current 19 Mar.2001).

7. S. Staab et al., “Knowledge Processes andOntologies,” IEEE Intelligent Systems, vol.16, no. 1, Jan./Feb. 2001, pp. 26–34.

8. S. Staab and A. Maedche, “Knowledge Por-tals—Ontologies at Work,” to be published inAI Magazine, vol. 21, no. 2, Summer 2001.

9. G. Miller, “WordNet: A Lexical Database forEnglish,” Comm. ACM, vol. 38, no. 11, Nov.1995, pp. 39–41.

10. G. Neumann et al., “An Information Extrac-tion Core System for Real World German TextProcessing,” Proc. Fifth Conf. Applied Nat-ural Language Processing (ANLP-97), 1997,pp. 208–215.

11. G. Stumme and A. Maedche, “FCA-Merge:A Bottom-Up Approach for Merging Ontolo-gies,” to be published in Proc. 17th Int’l JointConf. Artificial Intelligence (IJCAI ’01),Morgan Kaufmann, San Francisco, 2001.

Alexander Maedche is a PhD student at the Institute of Applied Informat-ics and Formal Description Methods at the University of Karlsruhe. Hisresearch interests include knowledge discovery in data and text, ontologyengineering, learning and application of ontologies, and the Semantic Web.He recently founded together with Rudi Studer a research group at the FZIResearch Center for Information Technologies at the University of Karlsruhethat researches Semantic Web technologies and applies them to knowledgemanagement applications in practice. He received a diploma in industrialengineering, majoring in computer science and operations research, from the

University of Karlsruhe. Contact him at the Institute AIFB, Univ. of Karlsruhe, 76128 Karlsruhe,Germany; [email protected].

Steffen Staab is an assistant professor at the University of Karlsruhe andcofounder of Ontoprise GmbH. His research interests include computationallinguistics, text mining, knowledge management, ontologies, and the Seman-tic Web. He received an MSE from the University of Pennsylvania and a Dr.rer. nat. from the University of Freiburg, both in informatics. He organizedseveral national and international conferences and workshops, and is nowchairing the Semantic Web Workshop in Hongkong at WWW10. Contacthim at the Institute AIFB, Univ. of Karlsruhe, 76128 Karlsruhe, Germany;[email protected].

T h e A u t h o r s