T h e

S e m a n t i c

W e b

DAML+OIL: An Ontology Language for the Semantic Web

Deborah L. McGuinness and Richard Fikes, Stanford University James Hendler, University of Maryland Lynn Andrea Stein, Franklin W. Olin College of Engineering

B
DAML+OILs goal is to support the transformation of the Web from being a forum for information presentation to a resource for interoperability, understanding, and reasoning.

y all measures, the Web is enormous and growing at a staggering rate, which has made it increasingly difficultand importantfor both people and programs to

have quick and accurate access to Web information and services. The Semantic Web offers a solution, capturing and exploiting the meaning of terms to transform the Web from
a platform that focuses on presenting information, to a platform that focuses on understanding and reasoning with information. To support Semantic Web development, the US Defense Advanced Research Projects Agency launched the DARPA Agent Markup Language (DAML) initiative to fund research in languages, tools, infrastructure, and applications that make Web content more accessible and understandable. Although the US government funds DAML, several organizationsincluding US and European businesses and universities, and international consortia such as the World Wide Web Consortiumhave contributed to work on issues related to DAMLs development and deployment. Our focus in this article is on DAMLs current markup language, DAML+OIL, which is a proposed starting point for the W3Cs Semantic Web Activitys Ontology Web Language (OWL). Here, we introduce DAML+OILs syntax and usage through a set of examples, drawn from a wine knowledge base used to teach novices how to build ontologies.1 DAML and revise DAML-ONT in response to community comments. Generally, compared with DAML-ONT, DAML+ OIL places much more emphasis on clear semantics, using both our updated first-order logic (FOL) semantics and a model-theoretic semantics (see www.daml.org/2000/12/axiomatic-semantics.html and www.daml.org/2000/12/model-theoretic-semantics.html, respectively). DAML+OIL also introduced several language constructors that increased the expressive power of DAML. The first version of DAML+OIL was released in December 2000. Because a timely release was crucial, the first version did not address data type integration. Among the new features the first release introduced were Improved handling for some concepts, including the top concept Local cardinality restrictions Cleaner, modified restriction semantics Integration of necessary and sufficient conditions That version also included name changes for a few constructors and eliminated a few language features that had unclear semantics or redundant usage. (A complete discussion of the differences between DAMLONT and DAML+OILs first release appears elsewhere.5) The current version of DAML+OIL (www.daml.org/2001/03) was released in March 2001;
IEEE INTELLIGENT SYSTEMS

DAML+OIL: Early releases

As the sidebar DAML Evolution explains, DAML+OIL evolved from a merger of DAMLONT,2 an earlier DAML ontology language, and the Ontology Inference Layer (OIL), a description logic.3 The goal of this merger was to integrate the formal foundations found in description logics4 into
72
1094-7167/02/$17.00 2002 IEEE

it extends DAML+OIL with arbitrary datatypes from the XML Schema type system.

</daml:Class> Next, to describe a wine type, such as red or white wine, we write <daml:Class rdf:ID=RedWine> <rdfs:subClassOf rdf:resource=#Wine/> </daml:Class> The subClassOf element asserts that its subjectRedWineis a subclass of its object, which is the resource identified by #Wine. Similarly, we describe WhiteWine: <daml:Class rdf:ID=WhiteWine> <rdfs:subClassOf rdf:resource=#Wine/> </daml:Class> To state that no wine can be simultaneously a RedWine and a WhiteWine, we combine the about tag and disjointWith tag: <daml:Class rdf:about=#WhiteWine> <rdfs:comment>no wine is both a red and a white wine</rdfs:comment> <daml:disjointWith rdf:resource= #RedWine/> </daml:Class> Describing individuals To introduce individuals, we use the same syntax. For example, imagine that we want to say that our favorite drink is a red wine, or that a particular wine, Marietta Zinfandel, is red. To do this, we must provide the syntax for describing the individuals, MyFavoriteDrink and MariettaZinfandel. We begin this DAML statement with the type of thing were describing, in this case RedWine: <RedWine rdf:ID=MyFavoriteDrink> <rdfs:label>MyFavoriteDrink</rdfs:label> <rdfs:comment>MyFavoriteDrink is a RedWine.</rdfs:comment> </RedWine> <RedWine rdf:ID=MariettaZinfandel> <rdfs:label>MariettaZinfandel </rdfs:label> <rdfs:comment>MariettaZinfandel is a RedWine.</rdfs:comment> </RedWine> Although we attach the label and comment attributes to the individuals, MyFavoriteDrink and MariettaZinfandel, neither carries semantics for the computer or an automatic reasoner. However, they do use inference. Because we
computer.org/intelligent

An introduction through examples

To capture terms and their meaning, a language must describe object classes and relations between objects, and ground objects in the domain of discourse. To introduce basic DAML+OIL language notions, well use an extended example in the style of the Annotated DAML+OIL Markup.6 Here, our domain is wine and we use examples from the Classic tutorial.7 The examples use the Resource Description Framework serialized into XML (RDF/XML). The full DAML+OIL ontology language is available at www.daml. org, which includes several more-sophisticated features that are beyond this articles scope. In addition, the sidebar DAML Resources offers pointers to further information sources. Describing classes An ontology consists of object descriptions. To help us describe objects, we first describe object types. If were interested in wines and foods, for example, we describe general classes, such as the wine class: <daml:Class rdf:ID=Wine> This states that there is a Class known as Wine; it says nothing more about wine, nor does it imply that its the sole source of information about wine. However, stating that the RDF ID is Wine lets us later add sentences that refer to this basic wine description (using the URI of the containing page, followed by #Wine). The RDF Namespaces sidebar on page 77 offers details on the RDF namespace scheme. Next, we annotate terms with labels and comments: <rdfs:label>Wine</rdfs:label> <rdfs:comment> Wine is a class. It will be used for pedagogical purposes. </rdfs:comment> This wine class illustrates two key ontological idioms: label and comment. A label is a brief identifier of the enclosing element, suitable for graphical representations of RDF and so on. A comment is a natural language description of the element it is included within. Neither labels nor comments contribute to the DAMLs logical interpretation. To close the description, we use
SEPTEMBER/OCTOBER 2002

know that MyFavoriteDrink is a RedWine and also that MariettaZinfandel is a RedWine, and we know that red wines are wines, we thus know that MyFavoriteDrink and MariettaZinfandel are instances of the class RedWine. Describing properties We use properties to relate individuals to each other. So far, we have a simple class, Wine, and two subclasses (RedWine and WhiteWine) distinguished by color. Properties let us introduce associated object properties, such as a wines body and its sugar level. To introduce the color property, we use <daml:ObjectProperty rdf:ID=hasWineColor> The property description begins much like that of the class, basically stating that there is a property called hasWineColor. Although some of the wine knowledge base encodings use a simple property-naming convention, such as color, we use the convention with a leading prefix, has, for claritys sake, to distinguish properties that we could use with other classes, and to state the domain restriction in the name. To limit the kinds of individuals that can fill the hasWineColor property, we must state the propertys range. To do this, we describe a class that represents valid wine colors and use that as the property range: <rdfs:range rdf:resource=#WineColor/> That said, using a term such as WineColor before it is described is perfectly valid. Next, to state that the property applies to things that are wine, we state the propertys domain: <rdfs:domain rdf:resource=#WINE/> To close the hasWineColor property, we use </daml:ObjectProperty> Because domains and ranges offer global information about properties, using overly restrictive domain or range restrictions can create problems, such as limited reuse. In this case, using a restrictive name for our property was appropriate, clearly associating it only with the wine domain. We also created a similarly restrictive class for the range restriction. However, as we now describe, it is possible to restrict the propertys restriction, rather than use global domain and range restrictions.
73

T h e

S e m a n t i c

W e b

DAMLs Evolution
The DAML Web ontology language has evolved over several years. Here we offer a historical and motivational perspective on its growth. recent examples include Fact14 and the Ontology Inference Layer (OIL).15 Description logics emphasize clear, unambiguous languages supported by complete denotational semantics and tractable reasoning algorithms. Researchers have heavily analyzed description logics to understand how constructors interact and combine to impact tractable reasoning (see, for example, work by Donini and colleagues16,17). Other work has studied reasoning algorithms to further their efficiency, including, for example, work by Horrocks and colleagues.1820 Although our work on DAML-ONT drew generally on description logics research, we took particular inspiration from OIL, the latest description logic. Researchers designed OIL to be an expressive description logic integrated with modern Web technology. Finally, the ontology language drew inspiration from the Knowledge Interchange Format, which is an FOL-based proposed ANSI standard for knowledge interchange.

Research influences
Work on the DAML ontology languages was inspired by three basic building blocks: Web integration, frame-based systems, and description logics. Web integration Our most critical requirement for DARPA Agent Markup Languages initial ontology language, DAML-ONT, was easy Web integration with RDF1,2 (with embedded XML) and RDF Schema.3 This gives the language crucial backward compatibility with existing Web standards, permitting interoperability with the growing base of content and language tools, and also works for users who are comfortable with existing languages. DAML-ONT provided expressive power that went beyond RDF and RDF Schema by capturing semantic relations in machine-readable form using more expressive term descriptions and more precise semantics. This is important for many reasons; arguably the most salient is to facilitate agent intercommunication. Frame-based systems DAML-ONT was also influenced by systems that emphasized paradigms supporting conceptual modeling. Many developers perceived frame systems as acceptable and easy to use and have embraced them relatively widely.46 Thus, we were also influenced by systems with a frame-based look and feel or application programming interfaces such as Ontolingua,7 Open Knowledge Base Connectivity (OKBC),6 the Extensible Ontology Languages (XOL and iXOL),8 and General Frame Protocol (GFP). A particularly notable influence on our work was Simple HTML Ontology Extensions,9,10 which was the first frame-based knowledge-representation language specifically designed for Web use. SHOE extended HTML (and later XML) to permit the description of classes and their properties, as well as Hornclause-like inference rules. We based many key Web-enablement constructors in both DAML-ONT and DAML+OIL on SHOE mechanisms. Given our goal to make the DAML ontology language accessible to the masses, choosing paradigms that were easy to explain and use was important. Description logics Our work on DAML-ONT was partially motivated by work in description logics (www.dl.kr.org), which offers a formal foundation for frame-based systems. Some early description-logic based systems include KL-One,11 Classic,12 and Loom;13 more

Early DAML language releases

DAML-ONT was initially released in October 2000.21 The language was subsequently taken over by a DAML language committee, which, in turn, expanded to become the Joint US/EU ad hoc Agent Markup Language Committee. This committee has been responsible for all other DAML ontology language releases to date. The initial release DAML-ONTs initial release was basically an extension of RDF Schema vocabulary, with input from frame-based systems and description logics. We chose initial constructors from use-case analysis experience with RDF and XML (and a few other languages) and from SHOE use cases.22 At that time, one of our primary goals was to produce a language quickly so that experimentation could inform further development. The DAML program rapidly formed an ontology library for the larger community to submit, store, and reuse the DAML ontologies. Along with timeliness, Web language compatibility was the primary concern. Usability issues (related to frame languages) and clean formal foundations (related to description logics) were secondary. Approaching DAML+OIL Following the initial release, Richard Fikes and Deborah McGuinness produced a FOL semantics for DAML-ONT,23 which gave the language a more precise foundation for semantic analysis. Simultaneously, the joint committee began evolving the language in accordance with needs expressed by reviewers and the potential user community. Among those needs were for a more formal specification of the languages meaning. People in the description logic communitywhich typically offers formal

Property restrictions So far, weve introduced the wine class, but have not placed any restrictions on its properties. We now add restrictions, which gives the class internal structure: <daml:Class rdf:about=#Wine> <rdfs:comment> Wines must have a wine color, and the filler for this property must be of the type WineColor. (However, not everything with
74

a color of type WineColor is a wine). </rdfs:comment> <rdfs:subClassOf> <daml:Restriction daml:minCardinality=1> <daml:onProperty rdf:resrouce= #hasWineColor/> </daml:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <daml:Restriction>
computer.org/intelligent

<daml:onProperty rdf:resource= #hasWineColor/> <daml:toClass rdf:resource= #WineColor/> </daml:Restriction> </rdfs:subClassOf> </daml:Class> Wine is now a subclass of two restrictions: one that restricts the minimum
IEEE INTELLIGENT SYSTEMS

semantic specifications with language descriptionsidentified sources of ambiguity. Users also identified where language designers had differing interpretations of meanings. This motivated both the FOL semantics effort to offer a clear specification of meaning, while simultaneously motivating a true integration of description logic principles into the DAML ontology language. Because DAML-ONTs goals were now very similar to those of OIL, we naturally considered merging the best features of both languages. OIL had several attractive qualities. First, one of its goals was to be a Web ontology language with a firm formal foundation, and the language was already designed and documented. OIL developers had also carefully evaluated its constructor choices so as to maintain tractability. Finally, OIL, and later DAML+OIL, used SHIQa well-studied and fairly expressive description logic with good formal propertiesas an underlying formal description logic (for more on SHIQ, including the various properties represented by the acronym and variant description logics, see the Description Logic Handbook appendix at http://titles.cambridge.org/catalogue.asp?isbn. 0521781760).

10. J. Heflin, Towards the Semantic Web: Knowledge Representation in a Dynamic Distributed Environment, doctoral dissertation, Computer Science Dept., Univ. of Maryland, College Park, Md., 2001. 11. R. Brachman and J. Schmolze, An Overview of the KL-ONE Knowledge Representation System, Cognitive Science, vol. 9, no. 2, 1985, pp. 171216. 12. A. Borgida et al., Classic: A Structural Data Model for Objects, Proc. 1989 ACM SIGMOD Intl Conf. Management of Data, ACM Press, New York, 1989, pp. 5967. 13. R.M. MacGregor, Inside the LOOM Description Classifier, Sigart Bulletin, vol. 2, no. 3, June 1991, pp. 8892; http://dblp.uni-trier.de/ db/journals/sigart/sigart2.html. 14. I. Horrocks, FaCT and iFaCT, Proc. Intl Workshop on Description Logics (DL 99), Technical Univ. of Aachen, Germany, 1999, pp. 133 135. 15. D. Fensel et al., OIL: An Ontology Infrastructure for the Semantic Web, IEEE Intelligent Systems, vol. 16, no. 2, Mar./Apr. 2001, pp. 3845. 16. F. Donini et al., The Complexity of Concept Languages, Proc. 2nd Intl Conf. on Principles of Knowledge Representation and Reasoning, Morgan Kaufmann, San Francisco, 1991, pp. 151162. 17. F. Donini et al., Tractable Concept Languages, Intl Joint Conf. Artificial Intelligence (IJCAI 91), Morgan Kaufmann, San Francisco, 1991, pp. 458465. 18. I. Horrocks and P. Patel-Schneider, Optimizing Description Logic Subsumption, J. Logic and Computation, vol. 9, no. 3, 1999, pp. 267293. 19. I. Horrocks and U. Sattler, A Description Logic with Transitive and Inverse Roles and Role Hierarchies, J. Logic and Computation, vol. 9, no. 3, June 1999, pp. 385410; www3.oup.co.uk/logcom/hdb/ Volume_09/Issue_03. 20. I. Horrocks, U. Sattler, and S. Tobies, Practical Reasoning for Very Expressive Description Logics, Logic J. IGPL, vol. 8, no. 3, May 2000, pp. 239263; www3.oup.co.uk/igpl/Volume_08/Issue_03. 21. D. Connolly, L. Stein, and D. McGuinness, eds., DAML-ONT Initial Release, Oct. 2000; www.daml.org/2000/10/daml-ont.html. 22. J. Heflin, J. Hendler, and S. Luke, Applying Ontology to the Web: A Case Study, Intl Work-Conf. Artificial and Natural Neural Networks (IWANN 99), Springer Verlag, Berlin, 1999, pp. 715724. 23. R. Fikes and D.L. McGuinness, An Axiomatic Semantics for RDF, RDF-Schema, and DAML-ONT, tech. report, Knowledge Systems Laboratory, Stanford Univ., Stanford, Calif., Dec. 2000; www.ksl. stanford.edu/people/dlm/daml-semantics/abstract-axiiomaticsemantics.html.

References
1. O. Lassila, Web Metadata: A Matter of Semantics, IEEE Internet Computing, vol. 2, no. 4, July/Aug. 1998, pp. 3037. O. Lassila and R. Swick, Resource Description Framework (RDF) Model and Syntax Specification, W3C Recommendation, World Wide Web Consortium, 1999; www.w3.org/TR/REC-rdf-syntax. D. Brickley and R.V. Guha, Resource Description Framework (RDF) Schema Specification 1.0, W3C Candidate Recommendation, World Wide Web Consortium, 2000; www.w3.org/TR/rdf-schema. R. Fikes and T. Kehler, The Role of Frame-Based Representation in Reasoning, Comm. ACM, vol. 28, no. 9, Sept. 1985, pp. 904920. P. D. Karp, The Design Space of Frame Knowledge Representation Systems, tech. report 520, AI Center, SRI Intl, Menlo Park, Calif.; ftp://www.ai.sri.com/pub/papers/karp-freview.ps.Z. V. Chaudhri et al., OKBC: A Programmatic Foundation for Knowledge Base Interoperability, AAAI Press, Menlo Park, Calif., 1998. A. Farquhar, R. Fikes, and J. Rice, The Ontolingua Server: A Tool for Collaborative Ontology Construction, Intl. J. HumanComputer Studies, vol. 46, no. 6, 1 June 1997, pp. 707727. P. D. Karp, V.K. Chaudhri, and J. F. Thomere, XOL: An XML-Based Ontology Exchange Language, tech. note 559, AI Center, SRI Intl, Menlo Park, Calif., 1999. S. Luke et al., Ontology-Based Web Agents, Proc. 1st Intl Conf. Autonomous Agents, ACM Press, New York, 1997, pp. 5968.

2.

3.

4.

5.

6.

7.

8.

9.

number of fillers for the hasWineColor property and another that restricts the propertys filler type. Each restriction actually describes an anonymous classthe class of all things that satisfy the restriction. In the first case, it is the class of all things that have at least one filler for the property hasWineColor . The syntax here is a clich; that is, it is always used as shown, except for
SEPTEMBER/OCTOBER 2002

The resource name in the OnProperty element, which is the name of the restricted property The resource associated with the toClass element, which gives the name of the class to which the property is restricted In the earlier section, Properties, we showed how to restrict the range of all uses of the hasWineColor property. In the statement
computer.org/intelligent

above, however, we restrict the range of hasWineColor only when it is used on the Wine class. In general, stating toClass restrictions locally to provide range restrictions results in more extendableand therefore more reusableontologies. In the first wine knowledge bases, for example, we had one color property and restricted its range using a toClass restriction on the Wine class, thereby limiting its use on wines to the range of wine75

T h e

S e m a n t i c

W e b

DAML Resources
For more information on DAML, see the following resources. The DAML Web site, www.daml.org, has the ontology languages full specification, an example file, and annotated walkthroughs for both DAML-ONT and DAML+OIL. The site also contains a DAML ontology library, numerous links to related work, and DAML-related announcements. The World Wide Web Ontology working group site, www.w3.org/2001/sw/ WebOnt/, contains the initial language submission and updated W3C notes on requirements, use cases, and recent OWL language details and documents. The OIL site, www.ontoknowledge.org/oil, has information on the OIL specification, documentation, and semantics, and provides use cases. It also has a white paper with a good introduction to OIL and its denotational semantics specification (which was the starting point for the denotational semantics for DAML+OIL; the latter is available at www.daml.org/2001/03/model-theoretic-semantics.html).

as well. Also, weve included a new property in the CotturriZinfandel description named hasMaker. Although it might be good practice in conceptual modeling to introduce properties before they are used, it is not a requirement of DAML+OIL.

A FOL semantics for DAML+OIL

To fully specify a knowledge representation language, both the syntax and the semantics of the language must be described. The syntax description specifies which strings of characters are legal statements in the language, and the semantic description specifies each legal statements intended meaning. The semantics of a representation language can be formally specified in multiple ways. We have chosen here to specify an equivalence-preserving translation from DAML+OIL into FOL. The translation consists of a mapping of DAML+OIL statements into sentences in FOL accompanied by a set of FOL axioms that constrain the possible interpretations of the nonlogical symbols (that is, the relation symbols, function symbols, and constants) in the FOL sentences the mapping produced. The translation into FOL provides a semantics for DAML+OIL in that any given axiomatization of a logical theory represented in DAML+OIL is defined to be logically equivalent to an axiomatization of a theory represented in FOL, for which a declarative semantics is known. Why FOL? The DAML+OIL specification submitted to W3C includes both this FOL semantics and a model-theoretic semantics.8 The model-theoretic semantics is in the traditional form, in which an interpretation function is named for each nonlogical symbol in the language, and constraints are stated that must hold for those interpretation functions. This work complements the model-theoretic semantics and makes the following additional contributions. Our translation into FOL enables the use of traditional FOL automatic theorem provers and problem solvers to answer queries and search for logical inconsistencies in theories represented in DAML+OIL. Unlike standard descriptions of modeltheoretic semantics, the constraints on the mappings are represented as axioms in a language for which automatic reasoning tools exist. These tools can thus be used to critique the constraints for inconsistencies
IEEE INTELLIGENT SYSTEMS

Colors, but letting us use the property color on other classes as well. Also, in the example above, we specified a minimum cardinality on the hasWineColor property, but not a maximum. If we had not specified anything, a minimum cardinality of 0 would be assumed. We can add a specific maximum cardinality, or, if we know the exact number of fillers for a property, we can use the cardinality property (instead of making two statements, one with minCardinality and one with maxCardinality). In this case, we could have stated <daml:Class rdf:about=#WINE> <rdfs:comment>Wines must have exactly one wine color. </rdfs:comment> <rdfs:subClassOf> <daml:Restriction daml:cardinality=1> <daml:onProperty rdf:resource= #hasWineColor/> </daml:Restriction> </rdfs:subClassOf> </daml:Class> We can set cardinality to any integer. In special cases (as above) where the cardinality is one, we call it a UniqueProperty. As these examples show, DAML offers multiple ways of encoding meaning. Class notations To construct a class description that lets a human or computer determine if something is an instance of a class, we provide <daml:Class rdf:about=#RedWine> <daml:intersectionOf> <daml:List> <daml:item> <rdfs:Class rdf:about=#WINE/>
76

</daml:item> <daml:item> <daml:Restriction> <daml:onProperty rdf:resource= #hasWineColor/> <daml:hasValue rdf:resource=#RED/> </daml:Restriction> </daml:item> </daml:List> </daml:intersectionOf> </daml:Class> This creates a class exactly equivalent to those things that are both wines and that have red as the filler of the hasWineColor property. We can deduce that anything with these two features is an instance of the class RedWine. Similarly, anything stated as an instance (or subclass) of the class RedWine will have these two properties. Thus, in our example above using the individuals MyFavoriteDrink and MariettaZinfandel, the system could conclude that they are both instances of Wine and instances of the class with a Red filler for its hasWineColor property. To create another individual wine, we can assert <Wine rdf:ID=CotturiZinfandel> <rdfs:label>CotturiZinfandel</rdfs:label> <rdfs:comment>CotturiZinfandel is a Wine whose color is red and whose maker is Cotturi. </rdfs:comment> <hasMaker rdf:resource=#COTTURI/> <hasWineColor rdf:resource=#Red/> </Wine> This individual is automatically recognized as an instance of the class RedWine, because we know it is a Wine whose color is Red. Similarly, if we had described a class of things that have at least one color, we could recognize CotturiZinfandel as an instance of that class
computer.org/intelligent

RDF Namespaces
and redundancies, and determine whether they entail (only) intended consequences. Tools to support such critiques are particularly important for the semantic specifications of developing languages (such as DAML+OIL), because they can help developers debug and understand the consequences of proposed language changes. Although it is possible to translate the current version of DAML+OIL into a FOL subset (into a description logic, for example), DAML+OILs development plan is to significantly expand its expressive power to more fully support the expected representational demands of Semantic Web ontologies. Using FOL translations and reasoning methods should both accommodate and support this plan, and will become increasingly necessary as the languages expressive power expands.
Because DAML+OIL is consistent with the RDF namespace scheme, we refer to RDF namespaces and create a base namespace for work. All ontologies begin with an RDF start tag and include an appropriate namespace specification. A typical example of our namespace declaration is the one at the beginning of our wines ontology:

<rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns# xmlns:xsd=http://www.w3.org/2000/10/XMLSchema# xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema# xmlns:daml=http://www.daml.org/2001/03/daml+oil#> xmlns=http://ontolingua.stanford.edu/doc/chimaera/ontologies/wines.daml# >

The rdf: prefix refers to the official W3C RDF namespace. This is a conventional RDF declaration and appears verbatim at the beginning of almost every RDF document. The two declarations following it refer to the XML Schema and RDF Schema data type namespaces. The fourth declaration refers to namespace terms from www. daml.org/2001/03/daml+oil#. This is a conventional DAML+OIL declaration and should appear verbatim at the beginning of all current-generation DAML+OIL documents. The final declaration states that unprefixed elements refer to terms in the ontology itself (in this case, the wine example) and provides the ontology files location.

Mapping DAML+OIL to FOL We map DAML+OIL to FOL using a simple rule for translating an RDF statement into a first-order relational sentence. Because DAML+OIL is simply a vocabulary of properties, classes, and constants added to RDF and RDF Schema, and RDF Schema is simply a vocabulary of properties and classes added to RDF, all statements in DAML+OIL are RDF statements. A rule for mapping RDF statements to FOL is thus sufficient for mapping DAML+OIL statements as well. We produce a logical theory that is logically equivalent to a DAML+OIL knowledge as follows: Translate the DAML+OIL knowledge base from its concrete syntax into a collection of RDF statements. Translate each RDF statement with property P, subject S, and object O into a FOL sentence of the form (PropertyValue P S O), where PropertyValue denotes a ternary relation that relates a property and an entity (a subject) to a value (an object) that the property has for that entity. Add the axioms that constrain the allowable interpretations of the properties, classes, and constants included in RDF, RDF Schema, and DAML+OIL. DAML+OILs concrete syntax is typically something other than <property, subject, object> triples. (The RDF specification,9 for example, describes an Extensible Markup Language encoding as the concrete syntax for
SEPTEMBER/OCTOBER 2002

RDF.) Thus, the first step of the translation into FOL is a translation from a concrete syntax into RDF statements. The only requirements we impose on that translation step is that each element in the RDF statements it produces be labeled with either A URI or a literal as given in the concrete syntax, or A Skolem constant generated by the translator for an unlabeled element in the concrete syntax (each label generated for unlabeled statement elements must be distinct) This translation is designed to place minimal constraints on the interpretation of the nonlogical symbols in the translated logical theory and to enable the required axioms to be expressible in FOL. In particular, it does not require that we translate properties into binary relations or that we translate classes into unary relations. The translation therefore lets us state axioms that apply to all properties and all classes (that is, that use a universally quantified variable for the property or class) without quantifying over the relation in a relational sentence. Such axioms are thus expressible in FOL. The axiom language DAML+OIL axioms are written in ANSI Knowledge Interchange Format (KIF) using standard FOL constructs and KIF-specific relations and functions for integers, which axiomatize the DAML+OIL properties dealcomputer.org/intelligent

ing with cardinality. As we stated earlier, we translate the RDF statement Property P of resource R has value V into the KIF sentence (PropertyValue P R V). Because the type property is central in RDF, we define an additional binary relation called Type to provide a more succinct translation of RDF statements of the form Property type of resource R has value V. The meaning of the Type relation is specified by the following axiom: (<=> (Type ?r ?v) (PropertyValue type ?r ?v)) In KIF, <=> means if and only if, relational sentences have the form (<relation name> <argument>*), and names with the first character ? are variables. Also, if no explicit quantifier is specified, variables are assumed to be universally quantified. So, the axiom above says that for all objects R and V, relation Type holds for R and V if and only if relation PropertyValue holds for object type, R, and V. RDF axioms Because DAML+OIL is specified as an extension to the RDF and RDF Schema vocabulary, our axiomatization includes axioms describing the properties and classes in both RDF and RDF Schema, as well as those in DAML+OIL itself. RDF language is a language for Declaring named resources to have type Property or Class Declaring resources to have a given class as
77

T h e

S e m a n t i c

W e b

a type (Clyde is type Elephant, for example) Stating that a given property of a given resource has a given value (property Color of Clyde has value Gray, for example) In RDF, the type property declares that the type of a resource R is T; such a declaration is actually a statement that property type of resource R has value T. Thus, an RDF knowledge base consists entirely of statements of the form, Property P of resource R has value V. The axiomatization provides axioms restricting the interpretation of the RDF classes and properties. The axioms include constraints, such as that the first argument of relation PropertyValue must be a property; that an entity cannot have both Property and Class as types (that is, they are disjoint classes); and that an RDF statement has exactly one property, one object, and one subject. RDF Schema axioms RDF Schema is simply a vocabulary of properties and classes added to RDF, and the axiomatization restricts the possible interpretations of those classes and properties. The added vocabulary includes standard properties such as subClassOf, subPropertyOf, range, and domain. The axioms include constraints such as these: a superclass of an object type is also a type of that object; if an entity is a value of another propertys subproperty, then the entity is also a value of the other property; a property value must have the range of that property as a type; and an object that has a value for a property must have that propertys domain as a type. DAML+OIL axioms DAML+OIL is simply a vocabulary of properties and classes added to RDF and RDF Schema. The DAML+OIL axioms are significantly more extensive than the axioms for either RDF or RDF Schema. They include constraints that Add 12 classes to the subclass taxonomy and 26 properties to the subproperty taxonomy Specify domain and range constraints for each of the new classes and properties Define the class of all objects (Thing), the empty class (Nothing), the class of properties that are transitive, the class of properties that can have at most one value for a given object (UniqueProperty), the class of properties that can have a given value for at most one object (UnambiguousProperty), the property for stating that classes are disjoint (dis78

jointWith), the property for stating that properties are inverses of each other (inverseOf), and the property for stating that classes are complements of each other (complementOf) Define properties for stating the equivalence of objects, classes, or properties Define properties for stating that a class is a union, intersection, or disjoint intersection of a list of classes Define the various kinds of cardinality and value restrictions Define lists and their properties

axioms for each of the cardinality restrictions. As an example, we offer one for cardinality that expresses a constraint on the NoRepeatsTuple length and contains all of a given propertys values at any one object: (=> (and (PropertyValue onProperty ?r ?p) (PropertyValue cardinality ?r ?n)) (forall (?i) (<=> (Type ?i ?r) (exists (?vl) (and (NoRepeatsTuple ?vl) (forall (?v) (<=> (Item ?vl ?v) (PropertyValue ?p ?i ?v))) (= (Length ?v1) ?n))))) Example translation and inference Consider the following DAML+OIL descriptions of class Wine and of wine MyFavoriteDrink: <daml:Class rdf:ID = Wine> <rdfs:subClassOf rdf:resource = Drink/> <rdfs:subClassOf> <daml:Restriction> <daml:onProperty rdf:resource = hasWineColor/> <daml:toClass rdf:resource = WineColor/> </daml:Restriction> </rdfs:subClassOf> </daml:Class> <Wine rdf:ID = MyFavoriteDrink> <has WineColor rdf:resource = Red/> </Wine> Those descriptions are equivalent to the following RDF statements: (rdf:type Wine daml:Class) (rdfs:subClassOf Wine Drink) (rdfs:subClassOf Wine GnR) [GnR is the generated label for the unlabeled restriction.] (rdf:type GnR daml:Restriction) (daml:onProperty GnR has WineColor) (daml:toClass GnR WineColor) (rdf:type MyFavoriteDrink Wine) (hasWineColor MyFavoriteDrink Red) Our FOL semantics translate those RDF statement semantics into the following FOL sentences: (Type Wine daml:Class) (PropertyValue rdfs:subClassOf Wine Drink)
IEEE INTELLIGENT SYSTEMS

One of the challenges in writing the DAML+OIL axioms was axiomatizing the various cardinality restrictions that are expressible in the language (minCardinality, maxCardinalityQ, and so on) without adding a set theory to FOL. We dealt with this issue by

DAML+OIL is simply a vocabulary of properties and classes added to RDF and RDF Schema.
writing a simple axiomatization of tuples and their length, and then defined a type of tuple that has no repeating elements. In those axioms, we define the empty tuple, EmptyTuple; the binary relation, Item, which relates a tuple to each of its elements; the unary function, First, which maps a nonempty tuple to its first element; the unary function, Rest, which maps a nonempty tuple to the tuple consisting of its second through last elements; the unary function, Length, which maps a tuple to the number of elements it has; and the unary relation, NoRepeatsTuple, which is true of tuples that have no repeating elements. The axiom that defines the NoRepeatsTuple relation is (<=> (NoRepeatsTuple ?t) (and (Type ?t Tuple) (or (= ?t EmptyTuple) (= (Rest ?t) EmptyTuple) (and (not (Item (Rest ?t) (First ?t))) (NoRepeatsTuple (Rest ?t)))))) Given this axiomatization, we wrote
computer.org/intelligent

Glossary
(Type GnR daml:Restriction) (PropertyValue rdfs:subClassOf Wine GnR) (PropertyValue daml:onProperty GnR hasWineColor) (PropertyValue daml:toClass GnR WineColor) (Type MyFavoriateDrink Wine) (PropertyValue has WineColor MyFavoriteDrink Red) A FOL reasoner can infer from these sentences and the DAML+OIL axioms that Red is type WineColor. It makes that inference by first inferring that Red is type GnR, using the following subClassOf axiom: (<=> (PropertyValue subClassOf ?csub ?csuper) (and (Type ?csub rdfs:Class) (Type ?csuper rdfs:Class) (forall (?x) (=> (Type ?x ?csub) (Type ?x ?csuper))))) If the reasoner substitutes Wine for ?csub and GnR for ?csuper, the axiom can be used to infer the following: (=> (PropertyValue subClassOf Wine GnR) (=> (Type MyFavoriteDrink Wine) (Type My FavoriteDrink GnR))) Because (PropertyValue subClassOf Wine GnR) and (Type MyFavoriteDrink Wine) are given, the reasoner can infer (Type MyFavoriteDrink GnR). It can then infer that Red is type WineColor using the axiom: (=> (and (PropertyValue onProperty ?r ?p) (PropertyValue toClass ?r ?c)) (forall (?i) (<=> (Type ?i ?r) (forall (?j) (=> (PropertyValue ?p ?i ?j) (Type ?j ?c)))))) The axiom says that if R is a toClass restriction on class C for property P, then for all I, I is type R if and only if all values J of P are type C. If the reasoner substitutes GnR for ?r, hasWineColor for ?p, WineColor for ?c, and MyFavoriteDrink for ?i, the axiom can be used to infer this: (=> (PropertyValue hasWineColor MyFavoriteDrink ?j) (Type ?j WineColor)) If the reasoner substitutes Red for ?j in that intermediate result, it can infer (Type Red WineColor), which is what we set out to prove. Theorems for automatic reasoning A primary motivation for developing a
SEPTEMBER/OCTOBER 2002

DAML: DARPA Agent Markup Language DAML-Logic: Forthcoming catch-all DAML languages that will address rules and proofs DAML+OIL: The DAML programs current ontology language, which merges DAML-ONT and the Ontology Inference Layer (OIL). DAML-ONT: The DAML programs initial ontology language DAML-S: DAMLs Web services ontology FOL: First-order logic KIF: Knowledge Interchange Format, a FOL-based language for knowledge interchange. OIL: Ontology Inference Layer, a description logic OWL: W3Cs Semantic Web Activity Ontology Web Language RDF: Resource Description Framework RDF Schema: A vocabulary of properties and classes added to RDF

translation of DAML+OIL into FOL was to facilitate automatic query-answeringthat is, a deductive retrieval of objects that match a given set of constraintsfrom a DAML+OIL knowledge base. It would be difficult for a reasoner to use many of the axioms as written. We therefore produced a set of theorems that are inferable from the axioms for RDF, RDF Schema, and DAML+OIL, and that are in the Horn Clause form that is conducive to effective FOL theorem prover use. (A Horn Clause is an implication of the form (=> (and a1 an) c), where each of a1, , an, and c are atomic sentences. In this case, an atomic sentence is either an RDF statement or false.) The theorems (which we list elsewhere10) should state all of the RDF statements that can be inferred about the knowledge bases vocabularythat is, about constants that are either explicitly mentioned in the knowledge base or defined in the knowledge base language (RDF, RDF Schema, or DAML+ OIL). So, for example, the theorems express a consequence that an object is not an instance of a class only if the complement of the class is already a named class in the knowledge base. The theorems can be considered as the axioms intended consequences expressed in forms that traditional FOL reasoners can directly use. Any consequence that a FOL reasoner is having difficulty making can be expressed as a Horn clause, which a theorem prover can attempt to prove from the axioms. If the proof succeeds, then the Horn clause is a theorem that a FOL reasoner can use directly in future reasoning to infer the intended consequence. The most important theorems in terms of facilitating reasoning are those involving the various cardinality restrictions. The axioms that define the semantics of cardinality restrictions using a NoRepeatsTuple are difficult
computer.org/intelligent

for FOL reasoners to use effectively. For example, such reasoners would have difficulty using them to make standard inferences about inconsistent cardinality restrictions (such as when a maxCardinality restriction is less than a corresponding minCardinality restriction) and equality of property values (such as when there are two values of a property for an object that has a maxCardinality restriction of 1). The theorems support each of those standard inferences by providing a Horn clause that a reasoner can use to directly make the desired conclusion.

ere developing DAML+OIL in stages. Our initial aim was to capture term descriptions, as weve described here. The DAML program is now working on a query language and the integration of a rule-encoding option. The next major language enhancement, DAML-Logic (DAMLL) will address encoding inference and general implications. The DAML Services group also built a Web service ontology, DAML-S, which uses DAML+OIL to provide a foundation for Web agents. DAML+OIL was submitted11 as the starting point for the W3C Semantic Web Activitys OWL. The W3Cs Web Ontology Working Group has produced a set of requirements for OWL, as motivated by a collection of use cases. DAML+OIL meets the current requirements draft reasonably well, and the initial OWL language description is quite similar to DAML+OIL. We believe that DAML+OIL is a useful starting point for describing Web content, building on decades of research in framebased systems, description logics, and Web languages. Given this foundation, and the research benefits into languages, complexity, and usability it provides, DAML+OIL
79

T h e

S e m a n t i c

W e b

T h e

A u t h o r s
Deborah L. McGuinness is associate director and a senior research scien-

tist at the Knowledge Systems Laboratory of Stanford University. Her main research areas include ontologies, description logics, reasoning systems, environments for building and maintaining information, knowledge-enhanced search, configuration, and intelligent commerce applications. She also runs a consulting business dealing with ontologies and artificial intelligence for business applications and serves on advisory boards for the American Association of Artificial Intelligence, the Semantic Web Science Foundation, Knowledge Representation and Reasoning Inc., Network Inference, Applied Semantics, and Sandpiper Software. She received a PhD from Rutgers University in reasoning systems. Contact her at the Knowledge Systems Laboratory, Stanford Univ., Stanford, CA 94305; dlm@ksl.stanford.edu; www.ksl.stanford.edu/people/dlm.
Richard Fikes is a professor of computer science at Stanford University and the director of Stanfords Knowledge Systems Laboratory, where he leads projects focused on developing large-scale distributed repositories of computer-interpretable knowledge, collaborative development of multiuse ontologies, enabling technology for the Semantic Web, and reasoning methods applicable to large-scale knowledge bases. He is co-developer of the STRIPS automatic planning system, the Knowledge Interchange Format, the Ontolingua language and development environment, the Open Knowledge Base Connectivity API for knowledge servers, and IntelliCorps KEE system. Contact him at the Computer Science Dept., Gates Bldg. 2A, Rm. 246, Stanford Univ., Stanford, CA 94305; fikes@ksl.stanford.edu. James Hendler is a professor of computer science at the University of Mary-

Ontology Language for the Semantic Web, The Semantic Web, D. Fensel, J. et al., eds., to be published by MIT Press, Cambridge, Mass., 2002; www.daml.org/2000/10/damlont. html. 3. S. Bechhofer et al., An Informal Description of OIL-Core and Standard OIL: A Layered Proposal for DAML-O, Nov. 2002, www. ontoknowledge.org/oil/downl/dialects.pdf. 4 F. Baader et al., eds., The Description Logic Handbook: Theory, Implementation and Applications, Cambridge Univ. Press, Cambridge, UK, 2002. 5. I. Horrocks et al., Some Notes on the Differences between DAML+OIL and DAML+ ONT, Dec. 2000, www.daml.org/2000/12/ differences-daml.html. 6. D. Connolly et al., eds, Annotated DAML Ontology Markup, World Wide Web Consortium, Note 18, Dec. 2001, www.w3.org/TR/ daml+oil-walkthru. 7. D. McGuinness et al., Classic Knowledge Representation System Tutorial, Artificial Intelligence Principles Research Dept., AT&T Labs Research, 1994; www.bell-labs.com/ project/classic/papers/ClassTut/ClassTut. html. 8. F. van Harmelen et al., A Model-Theoretic Semantics for DAML+OIL (March 2001), W3C Note 18, World Wide Web Consortium, Dec. 2001; www.w3.org/TR/2001/NOTEdaml+oil-model-20011218. 9. O. Lassila and R. Swick, Resource Description Framework (RDF) Model and Syntax Specification, W3C Recommendation, World Wide Web Consortium, 1999; www.w3.org/ TR/REC-rdf-syntax. 10. R. Fikes and D.L. McGuinness, An Axiomatic Semantics for RDF, RDF-Schema, and DAMLONT, tech. report, Knowledge Systems Laboratory, Stanford Univ., Stanford, Calif., Dec. 2000; www.ksl.stanford.edu/people/dlm/ daml-semantics/abstract-axiomatic-semantics. html. 11. D. Connolly et al., eds., DAML+OIL (March 2001) Reference Description, W3C Note 18, World Wide Web Consortium, Dec. 2001; www.w3.org/TR/daml+oil-reference.

land and the Director of Semantic Web and Agent Technologies at the Maryland Information and Network Dynamics Laboratory. He received his PhD in artificial intelligence from Brown University. He is a fellow of the American Association for Artificial Intelligence, a member of the US Air Force Science Advisory Board, and the former Chief Scientist for Information Systems at DARPA. Contact him at the Dept. of Computer Science, Univ. of Maryland, College Park, MD 20742; hendler@cs.umd.edu; www.cs.umd. edu/~hendler.
Lynn Andrea Stein is a professor of computer science and engineering and

a founding faculty member of the Franklin W. Olin College of Engineering. Her research interests include a broad subset of artificial intelligence and computer science, including logic, software agents, cognitive robotics, objectoriented programming, and computer science education. She received a PhD from Brown University and an AB from Harvard and Radcliffe Colleges. She is fellow of the KISS Institute for Practical Robotics. Contact her at the Franklin W. Olin College of Eng., 1735 Great Plain Ave., Needham, MA 02492; las@olin.edu.

could serve as a sound foundation for the next evolution of Web access. Researchers have already accepted DAML+OIL as a starting point for Web semantics representation and used it for applications ranging from military intelligence to medical and genetic database integration. Among the current development efforts are those focusing on using DAML+OIL for managing large Web sites and document and image collections, integrating disparate databases, and providing Web services interoperability (for more details, see the DAML Web page).

DAML program director. All four authors are members of the joint committee in charge of developing of the language. Dan Connolly, one of the original DAML-ONT coeditors, had a significant impact on the initial language release. We also acknowledge the efforts of the entire DAML Joint Committee, in particular the editors of DAML+OILs current release: Frank van Harmelen, Ian Horrocks, and Peter PatelSchneider, who, among other things, updated the original DAML-ONT documents to reflect DAML+OIL.

References
1. R.J. Brachman et al., Living with Classic: When and How to Use a KL-ONE-like Language, Principles of Semantic Networks: Explorations in the Representation of Knowledge, John Sowa, ed., Morgan Kaufmann, San Francisco, 1991, pp. 401456. 2. D.L. McGuinness et al., DAML-ONT: An
computer.org/intelligent

Acknowledgments
DAML+OIL is the result of the DAML program and the DAML Joint Committee. This article was written by two of the three original editors of the initial DAML language release, the two authors of the FOL axioms, and the initial 80

For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.

IEEE INTELLIGENT SYSTEMS