Deborah L. McGuinness, Richard Fikes, DAML-ONT: An Ontology Language for the Semantic Web Deborah McGuinness Gates Building 2A Stanford University Stanford, CA 94305 USA 650-723-9770 dlm@ksl.stanford.edu Richard Fikes Gates Building 2A Stanford University Stanford, CA 94305 USA 650-723-9770 fikes@ksl.stanford.edu Lynn Andrea Stein Franklin W. Olin College of Engineering 1735 Great Plain Avenue Needham, MA 02495 USA 781-292-2525 las@olin.edu James Hendler DARPA/ISO 3701 N. Fairfax Dr. Arlington, VA 22203 703-696-2238 jhendler@darpa.mil Abstract By all measures, the web is enormous and growing at a staggering rate. This growth has made it simultaneously increasingly difficult and important for humans and programs to be able to quickly and accurately access information and services available on the web. A semantic web—a web where the meanings of terms are captured and exploited—can provide the foundation for convenient access to web content. The DARPA Agent Markup Language (DAML) program is aimed at providing a language and toolset enabling the transformation of the web from a platform that focuses on presenting information to a platform that focuses on understanding and reasoning with information. In this paper, we describe the initial DAML language aimed at capturing the meaning of terms, thereby providing an ontology language for the web. We introduce DAML-ONT by way of examples and include an axiomatization of the language. Keywords: Ontology Language, Markup Language, Semantic Web, DAML, DARPA Introduction The DARPA Agent Markup Language (DAML) initiative is aimed at supporting the development of the semantic web. The program funds research in languages, tools, infrastructure, and applications for making web content more accessible and understandable. It is US Government-funded yet represents collaborations between the Department of Defense, US and European academia and business, and international consortia such as the W3C. While the program covers the breadth of issues related to markup language development, deployment, and evolution, this paper focuses only on the markup language itself. This language is being developed in two pieces. The first portion—covered in this paper—is the ontology language, aimed at capturing definitions of terms—classes, subclasses, their properties, their restrictions, and individual object descriptions. The second portion of the language (called DAML-LOGIC) will address the issue of encoding inference and general logical implications. In this paper, we review the history and motivations for the development of the initial DAML ontology language, DAML-ONT. In the following section, we introduce the DAML-ONT language syntax and usage through a pedagogically ordered set of examples derived from the initial DAML walkthrough document [Stein and Connolly, 2000]. In order to fully specify a knowledge representation language, one needs to describe both the syntax and the semantics of the language. The syntax description specifies what strings of characters are legal statements in the language. The semantic description specifies the intended meaning of each legal statement in the language. In the final section of this paper, we explore an axiomatic semantics for DAML-ONT. The DAML ontology language takes its motivation from many places, most notably the evolving web languages—in particular RDF [Lassila:98, Lassila-Swick:99] (with the embedded XML) and RDFS [Brickley-Guha:00], jointly referred to in this paper as RDF/S. It is important to be backwards compatible with existing web standard for interoperability with the growing user base of content, tools for these languages, and users who are comfortable with the languages. All of our examples below thus have the format of XML-based RDF. DAML-ONT extends RDF/S by capturing semantic relations in machine-readable form through more expressive term descriptions along with precise semantics. This is important for many reasons; arguably the most salient is to facilitate intercommunication between agents. While compatibility with web languages was paramount, we also recognized that markup representational needs went beyond what was conveniently expressible in RDF/S. Thus, an extended language was considered. The language is also influenced by frame-based systems, including knowledge representation languages such as Ontolingua [Farquhar et. al, 1997] or KEE. Frame systems have enjoyed acceptance and perceived ease of use by broad populations and have been embraced relatively widespread use [Fikes & Kehler 1985, Karp 1992, Chaudhri et. al. 1998]. The goal of our language is to be accessible to the masses and thus it was important to use paradigms that are easy to explain and use. Finally, DAML-ONT takes motivation from the field of description logics (www.dl.kr.org), which provide a formal foundation for frame-based systems. Some early description-logic based systems include KL-ONE[Brachman-Schmolze, 1985], CLASSIC [Borgida et. al, 1989], and LOOM[MacGregor, 1991], and a more recent example of a description logic-based system is OIL[Fensel-et-al, 2000, Bechhofer-et-al, 2000]. Description logics emphasize clear, unambiguous languages supported by complete denotational semantics and tractable reasoning algorithms. Description logics have been heavily analyzed in order to understand how constructors interact and combine to impact tractable reasoning. See for example, [Donini-et-al, 1991A and 1991B] for early evaluations. Also, reasoning algorithms have been studied producing knowledge about efficient reasoning algorithms (See [Horrocks and Patel-Schneider, 1999] and [Horrocks—et-al, 2000] for example). DAML-ONT draws on the general field of research in description logics and, in particular, on the latest description logic: OIL. OIL was designed to be an expressive description logic that is integrated with modern web technology. The resulting DAML ontology language is a combination of these three building blocks along with influence from KIF—the Knowledge Interchange Format—a first order logic-based proposed ANSI standard, SHOE—Simple HTML Ontology Language, and OKBC—Open Knowledge Base Connectivity—a standard applications programming interface for knowledge systems. The initial proposal for the language was written by MIT and W3C DAML contractors [Berners-Lee et al., 2000]. It 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. The joint committee has had responsibility for all DAML ontology language releases to date. It is also anticipated that there will be a W3C ontology committee (under the Semantic Web Activity ((http://www.w3.org/2001/sw/)) that will have responsibility for future semantic web language releases. It is worth noting that after DAML-ONT was released, the joint committee undertook a major effort to evolve the language. The initial language was heavily influenced by the web languages. A primary initial goal of DAML-ONT was to provide a web-compatible language expressive enough to handle markup requirements. Constructors were chosen initially from use-case analysis from experience with the current web markup languages—mostly RDF and XML. A second primary goal was to produce a language quickly so that experimentation could inform further development. An ontology library was also formed rapidly so that DAML ontologies could be submitted, stored, and reused by a larger community. Of these competing influences, web language compatibility and timeliness were the first concerns. Usability issues, as informed by frame languages, were a secondary concern, and formal foundations—as found in description logics—came later. In a subsequent effort, Fikes and McGuinness produced an axiomatic semantics for DAML-ONT [Fikes-McGuinness, 2000], providing a more precise foundation for semantic analysis of the language. Simultaneously, the joint committee undertook a concerted effort to improve compatibility of DAML-ONT with more formal foundations. The resulting language, which was essentially a merging of DAML-ONT and OIL, is called DAML+OIL. It places much more emphasis on clear semantics for the language (provided both by our updated axiomatic semantics (http://www.daml.org/2001/03/axiomatic-semantics.html) along with a model-theoretic semantics (http://www.daml.org/2001/03/model-theoretic-semantics.html)). DAML+OIL also filters language constructors according to understanding of the impact that they have on reasoning algorithms. The resulting language, DAML+OIL, chooses its constructors carefully following the analysis done on the underlying formal description logic, typically referred to as SHIQ. SHIQ includes ALC plus transitive roles, inverse roles, and qualified number restrictions. For more on the theoretical analysis and reasoning issues see [Horrocks and Sattler, 1999] and [Horrocks et. al, 1999]. An update to this paper that begins with DAML+OIL is in preparation and will be available from www.ksl.stanford.edu/people/dlm/ . An Introduction Through Examples A language meant to capture terms and their meanings will need to be able to describe classes of objects, relations between objects, and ground objects in the domain of discourse. We will introduce the basic notions of the DAML ontology language through example. Readers interested in more information can also consider the following: The DAML web site (www.daml.org) contains the full specification of the language along with an example file and an annotated walk through. There is also a DAML ontology library along with numerous links to related work. Also, the OIL documentation is useful in particular for the language specification, documentation, semantics, and for use cases. The white paper[Bechhofer et al:2000], available on the OIL site provides a nice introduction to OIL and is available from http://www.ontoknowledge.org/oil/. Also, available from the OIL site is the denotational semantics specification for OIL which was the starting point for the denotational semantics for DAML+OIL. Later in this paper, we provide our axiomatic semantics for DAML-ONT (which is of course the starting place for the axiomatic semantics for DAML+OIL. The following introduction through extended example is motivated by the walkthrough available from the daml home page. Defining Classes and Properties In order to describe objects, it is useful to define types for the objects. For example, we may be interested in describing people and animals. First, some general classes should be defined. The first class defined is named animal <Class ID="Animal"> The Class tag is used to state that there is a class known as Animal. It does not say anything else about what an animal is other than specifying that ID. It is also not (necessarily) the sole source of information about Animals. By saying that the ID is Animal, it becomes possible for future sentences to refer to the definition of Animal given here. (This is done using the URI of the containing page followed by #Animal.) Thus, it is possible to add information to the definition of Animal at a later point. Next, it may be desirable to annotate terms with labels and comments. <label>Animal</label> <comment>This class of animals is illustrative of a number of ontological idioms.</comment> These two lines introduce a label -- a brief identifier of the enclosing element, suitable for graphical representations of RDF, etc. -- and a comment -- a natural language (English, in this case) description of the element within which it is included. Neither a label nor a comment contributes to the logical interpretation of the DAML. </Class> This closes the current definition of the Class Animal. It may be desirable to define types of animals, named Male and Female. <Class ID="Male"> <subClassOf resource="#Animal"/> </Class> The subClassOf element asserts that its subject -- Male -- is a subclass of its object -- the resource identified by #Animal. When we define Female, we may want to state that no one can be simultaneously a Male and a Female. This is done using the disjointFrom tag in combination with the subClassOf tag below. <Class ID="Female"> <subClassOf resource="#Animal"/> <disjointFrom resource="#Male"/> </Class> Defining Individuals The syntax that we’ve used to define classes can also be used to define individuals. For example, imagine that we want to say that Fred is a Male. Here we provide the syntax for defining the individual Fred. This piece of DAML begins with the type of the thing we’re describing, in this case Male: <Male ID="Fred"> <label>Fred</label> <comment>Fred is a Male.</comment> </Male> The label and comment attributes are attached to this individual, Fred, but neither carries any semantics for the computer. At this point, we can see the first benefit to be had from inference. Because we know that Fred is Male and because we are aware of the subclass relationship between Male and Animal, we know that Fred is also of type Animal. Relating Individuals through Properties Properties are used to relate items to each other. In this case we will be interested in connecting two animals via the parent property. <Property ID="parent"> The property definition begins similarly to the Class: There is a property called parent. Note, however, that this is not a closing tag; there's more to this definition. (There is a matching </Property> tag below.) We may want to say how many parents an animal can have. In this case we will state that things that have parents have exactly two parents. <cardinality>2</cardinality> Embedded elements, such as this one, are understood to describe their enclosing elements. So, this cardinality element describes the Property whose ID is parent. We may want to state that parent is a property that applies only to things that are animals. <domain resource="#Animal"/> This element also describes the Property whose ID is parent. It says that the domain of the parent relation is Animal. This is done by asserting that the domain (of the property with ID parent) is the resource known as #Animal. All properties may have domains and ranges specified. The resource attribute is used to refer to a “reference-able” item created with the ID tag. Each of the names defined so far—Animal, Person, Male, and Female -- refers to a name in this (i.e., the containing) document, since each reference begins with a #. </Property> This closes the property whose ID is parent. Describing Attributes of Classes Now we will define a Class with an attribute. <Class ID="Person"> <subClassOf resource="#Animal"/> A Person is a kind of Animal. (See the definition of Animal, above.) The next few lines describe a domain-specific range restriction. The parent of a Person is also a Person. <restrictedBy> <Restriction> <onProperty resource="#parent"/> <toClass resource="#Person"/> </Restriction> </restrictedBy> The syntax used here is a cliché, i.e., it is almost always used as shown, except for the name of the resource in the OnProperty element, which will give the name of the Property to be restricted, and the resource associated with the toClass element, which will give the name of the Class to which the Property is restricted. This is also sometimes referred to as a value restriction since the type of the parent value is being restricted. </Class> That is the end of the Person class definition at this point. Suppose that we have a Person, Joe. <Person ID="Joe"> <label>Joe</label> <comment>Joe is a person.</comment> </Person> As we know, since Joe is stated to be of type Person, he will also be of type Animal (because of the subClassOf relationship). He will also have exactly two parents because of the cardinality statement. Those objects that fill his parent property also are of type person (thus, they also are of type animal and also have exactly two parents who are of type Person). We might also want to define Man as a kind of Male Person and Female as a kind of Female Person. This can be done as follows: <Class ID="Man"> <subClassOf resource="#Person"/> <subClassOf resource="#Male"/> </Class> <Class ID="Woman"> <subClassOf resource="#Person"/> <subClassOf resource="#Female"/> </Class> The upcoming release will allow the exact definition of Man as exactly those things that are both person and male. Thus if something is known to be an instance of a male and a person, then it would be inferred to be of type Man. The definition above only uses the subClassOf relation which states that a Man is simultaneously a subclass of Person and Male but it does not state that everything that is simultaneously a Person and a Male is a Man. Using Properties The next several annotations illustrate features of properties: Father is a property that is a kind of parent property, i.e., x's father is also x's parent. In addition, range is used to ensure that x's father must be Male, and that x has only one father. <Property ID="father"> <subProperty resource="#parent"/> <range resource="#Man"/> <cardinality>1</cardinality> </Property> At this point if Joe is stated to be John’s father, then we can determine that Joe is of type Male because of the range restriction. Because Male is of type animal, Joe is also of type animal. Also, parents have a domain of person, thus John is of type person. He has exactly one father, now known to be Joe. Joe must further be of type Person, since Person has a domain specific range restriction. Mother is defined similarly to father but using a variant notation. A UniqueProperty is one with cardinality 1, so we can omit that sub-element from Mother's definition. <UniqueProperty ID="mother"> <subProperty resource="#parent"/> <range resource="#Woman"/> </UniqueProperty> Sometimes, synonyms are useful. For example, some applications may want to use the term “mom” rather than “mother”. The tag equivalentTo allows us to establish this synonymy: <Property ID="mom"> <equivalentTo resource="#mother"/> </Property> Inverse relationships are supported as well using the inverseOf tag. If x's parent is y, then y is x's child. <Property ID="child"> <inverseOf resource="#parent"/> </Property> Transitive relationships are supported using the TransitiveProperty tag. The ancestor and descendent properties are transitive versions of the parent and child properties. We would need to introduce additional elements to enforce these connections. <TransitiveProperty ID="ancestor"> </TransitiveProperty> <TransitiveProperty ID="descendant"/> The cardinality property is exact. But sometimes we want to bound cardinality without precisely specifying it. A person may have zero or one job, no more: <Property ID="occupation"> <maxCardinality>1</maxCardinality> </Property> In the upcoming version of DAML+OIL, cardinality may be stated in a class-dependent manner instead of requiring the cardinality statement to be universally applied to the property. Classes, too, can be annotated in various ways: <Class ID="Car"> <comment>no car is a person</comment> <subClassOf> The thing that Car is a subClassOf could in principle be specified using a resource= attribute. In this case, however, there is no preexisting succinct name for the thing we want. A car is a kind of non-person. We build this by introducing a new -- anonymous -- Class definition described using the complementOf tag: <Class> <complementOf resource="#Person"/> From the inside out: There's a thing that's the complement of Person, i.e., all non-Persons. </Class> That thing is a Class. </subClassOf> That thing -- the Class of all non-Persons -- has a subClass. </Class> The Class with ID Car is the thing that is a subClass of the Class of all non-Persons. (There's a similar construction from the outside in: Car is a Class that is a specialization of another Class, the Class that is left when you consider everything except Persons). The next example shows an instance of further specifying a previously defined element by using the about attribute. These new assertions about the thing described above with ID Person have no more and no less authority than the assertions made within the <Class ID="Person"> element. (Of course, if the two assertions were in different documents, had different authors, etc., we might want to accord them different authority, but this would be as a result of information about those assertions rather than inherently from the assertions themselves.) In this case, we identify the Class Person with the disjoint union of the Classes Man and Woman. Note that the disjointUnionOf element contains two subelements, the Class Man and the Class Woman. The parseType= "daml:collection" indicates that these subelements are to be treated as a unit, i.e., that they have special RDF-extending meaning within the disjointUnionOf. <Class about="#Person"> <comment>every person is a man or a woman</comment> <disjointUnionOf parseType="daml:collection"> <Class about="#Man"/> <Class about="#Woman"/> </disjointUnionOf> </Class> A Person has a height, which is a Height. (hasHeight is a Property, or relation; Height is a Class, or kind of thing.) <Property ID="hasHeight"> <domain resource="#Person"/> <range resource="#Height"/> </Property> Height is Class described by an explicitly enumerated set. We can describe this set using the oneOf element. Like disjointUnionOf, oneOf uses the RDF-extending parsetype="daml:collection". <Class ID="Height"> <oneOf parseType="daml:collection"> <Height ID="short"/> <Height ID="medium"/> <Height ID="tall"/> </oneOf> </Class> Notes Of course by giving an introduction by example, we have not covered all portions of the language. Brief mention is made here to some other topics. See www.daml.org for more complete information. DAML-ONT is consistent with the RDF namespace scheme, thus one can refer to RDF namespaces and create a base namespace for work. Ontologies will begin with an RDF start tag and then include a specification of appropriate namespaces. The following is typical of a namespace declaration: <rdf:RDF xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns ="http://www.daml.org/2000/10/daml-ont#" xmlns:daml="http://www.daml.org/2000/10/daml-ont#" > In this document, the rdf: prefix should be understood as referring to things drawn from the namespace called http://www.w3.org/1999/02/22-rdf-syntax-ns#. This is a conventional RDF declaration appearing verbatim at the beginning of almost every rdf document The namespace prefix rdf is arbitrary. The name in this document would be the conventional choice. . The second declaration says that unprefixed element names in this document refer to terms in the namespace called http://www.daml.org/2000/10/daml-ont#. This is a conventional DAML-ONT declaration that should appear verbatim at the beginning of the current generation of DAML-ONT documents. The third declaration binds the daml: prefix to the same namespace name. So, for example, <Thing/> and <daml:Thing/> refer to the same thing in this document Unprefixed attribute names are not associated with the default namespace name the way unprefixed element names are. This is expanded upon in myth 4 available in “Namespace Myths exploded” at: http://www.xml.com/pub/a/2000/03/08/namespaces/index.html?page=2 .. This set of three namespaces would come at the beginning of the file and then there would be a trailing closing tag at the end of the file: </rdf:RDF>. One can also state information about version info, import from other resources, etc. for example: <versionInfo>$Id: daml-ex.daml,v 1.2 2000/10/07 03:21:17 connolly Exp $</versionInfo> <comment>An example ontology</comment> <imports resource="http://www.daml.org/2000/10/daml-ont"/> Language Extensions When DAML-ONT was released, its authors were conscious that some expressive extensions would be made. Integrating a description logic-like methodology into DAML-ONT provided it with a more formal foundation. Subsequently, two major features were added through expressive extensions. First, term definitions were introduced, allowing the definition of a term exactly equivalent to a combination of other terms. For example, one could define a term MAN as exactly equivalent to the conjunction of a PERSON who was also a MALE. Thus, if John were later stated to be a PERSON and a MALE, a system could deduce that JOHN was a MAN instead of waiting to be told that JOHN were a MAN. A second later addition was the introduction of concrete domains. It is important in any web language to be able to make reference to ground objects such as the XML type system in order to appropriately encode things such as numbers and strings. The DAML+OIL extension adds XML types to the language. An Axiomatic Semantics of DAML-ONT Overview In order to fully specify a knowledge representation language, one needs to describe both the syntax and the semantics of the language. The syntax description specifies what strings of characters are legal statements in the language, and the semantic description specifies the intended meaning of each legal statement in the language. The semantics of a representation language can be formally specified in multiple ways. We have chosen here to use the method of specifying a translation of the DAML-ONT language into another representation language that has a formally specified semantics. In particular, we have specified a translation of DAML-ONT into first-order predicate calculus, which has a well-accepted model theoretic semantics. We specify how to translate a DAML-ONT ontology into a logical theory expressed in first-order predicate calculus that is claimed to be logically equivalent to the intended meaning of that DAML-ONT ontology. There is an additional benefit to this approach. By translating a DAML-ONT ontology into a logically equivalent first-order predicate calculus theory, we produce a representation of the ontology from which inferences can automatically be made using traditional automatic theorem provers and problem solvers. For example, the DAML-ONT axioms enable a reasoner to infer from the two statements “Class Male and class Female are disjoint” and “John is type Male” that the statement “John is type Female” is false. The translation of DAML-ONT to first-order predicate calculus is done by a simple rule for translating an RDF statement into a first-order relational sentence, and by including in the translation a prespecified set of first-order predicate calculus axioms that restrict the allowable interpretations of the properties and classes that are included in DAML-ONT. This creates a set of first-order sentences that include the specific terms in the ontology along with the pre-specified set of axioms restricting the interpretations. The pre-specified set of axioms and the rules for generating the translation of RDF statements into first order sentences are the focus of this presentation since this is the portion that is leveragable across all DAML-ONT (and RDF/S) ontologies. Since DAML-ONT is simply a vocabulary of properties and classes added to RDF and RDF Schema, and RDF Schema is simply a vocabulary of properties and classes added to RDF, all statements in DAML-ONT are RDF statements and a rule for translating RDF statements is sufficient for translating DAML-ONT statements as well. We now describe the mapping of DAML-ONT into first-order predicate calculus. A logical theory that is logically equivalent to a set of DAML-ONT descriptions is produced as follows: Translate each RDF statement with property P, subject S, and object O into a first-order predicate calculus sentence of the form “(PropertyValue P S O)”. Add to this translation the axioms that constrain the allowable interpretations of the properties and classes that are included in RDF, RDF Schema, and DAML-ONT. Note that it is not necessary to specify a translation for every construct in RDF since any set of RDF descriptions can be translated into an equivalent set of RDF statements (as described in the RDF and RDF Schema specification documents). Thus, the one translation rule above suffices to translate all of RDF and therefore all of DAML-ONT as well. A notable characteristic of this axiomatization is that it is designed to minimize the constraints on the legal interpretations of the DAML-ONT properties and classes in the resulting logical theory. In particular, the axioms do not require classes to be sets or unary relations, nor do they require properties to be sets or binary relations. Such constraints could be added to the resulting logical theory if desired, but they are not needed to express the intended meaning of the DAML-ONT descriptions being translated. We now present an informal description of the axioms that are added to the translation of each DAML-ONT ontology. Since DAML-ONT is specified as an extension to RDF and RDF Schema, the axiomatization includes axioms describing the properties and classes in both RDF and RDF Schema, as well as those in DAML-ONT itself. The Axiom Language The axioms are written in ANSI Knowledge Interchange Format (KIF) (http://logic.stanford.edu/kif/kif.html), which is a proposed ANSI standard. The axioms use standard first-order logic constructs plus KIF-specific relations and functions dealing with lists and integers. Lists and integers as objects in the domain of discourse are needed in order to axiomatize RDF containers and the DAML-ONT properties dealing with cardinality. As stated above, each RDF statement “Property P of resource R has value V” is translated into the KIF sentence “(PropertyValue P R V)”. Because of the centrality of the “type” property in RDF, we define for convenience an additional binary relation call “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 relation “Type” is specified by the following axiom: (<=> KIF note: “<=>” means “if and only if”. Relational sentences in KIF have the form “ (<relation name> <argument>*)”. Names whose first character is ``?'' are variables. If no explicit quantifier is specified, variables are assumed to be universally quantified. (Type ?r ?v) (PropertyValue type ?r ?v )) That is, saying that relation “Type” holds for objects R and V is logically equivalent to saying that relation “PropertyValue” holds for objects “type”, R, and V. The axiomatization also restricts the first argument of relation “Type” to be a resource and the second argument to be a class as follows: (=> KIF note: “=>” means “implies”. (Type ?r ?c) (and (Type ?r Resource) (Type ?c Class))) RDF considers “Resource” to be a class and “Class” itself to be a class. The axiomatization specifies that semantics by including the axioms “(Type Resource Class)” and “(Type Class Class)”. Axioms for RDF RDF is a language for; declaring named resources to have type “Property” or “Class”, declaring resources to have a given class as a type (e.g., “Clyde” is type “Elephant”), and stating that a given property of a given resource has a given value (e.g., that property “Color” of “Clyde” has value “Gray”). A property named “type” is used for declaring that the type of a resource R is T so that such a declaration is actually a statement that a given property of a given resource has a given value, specifically that property “type” of resource R has value T. Thus, an RDF file can be considered to consist entirely of statements of the form “Property P of resource R has value V”. Our axiomatization provides axioms restricting the interpretation of the classes and properties that are included in RDF. Those classes are “Resource”, “Property”, “Class”, “Literal”, “Statement”, “Container”, “Bag”, “Seq”, “Alt”, and “ContainerMembershipProperty”. Those properties are “type”, “subject”, “predicate”, “object”, “value”, “_1”, “_2”, “_3”, … . Axioms for RDF Schema RDF Schema is simply a vocabulary of properties and classes added to RDF. Our axiomatization provides axioms restricting the interpretation of those classes and properties. The classes are “ConstraintResource” and ConstraintProperty”. The properties are “subClassOf”, “subPropertyOf”, “seeAlso”, “isDefinedBy”, “comment”, “label”, “range”, and “domain”. Axioms for DAML-ONT DAML-ONT is simply a vocabulary of properties and classes added to RDF and RDF Schema. We present in the appendix natural language transcriptions of the axioms that restrict the interpretation of those classes and properties. Example Translation and Inference Consider the following DAML-ONT descriptions of class “Person” and of person “Joe”: <Class ID = "Person"> <subClassOf resource = "#Animal” /> <restrictedBy> <Restriction> <onProperty resource = "#parent” /> <toClass resource = "#Person” /> </Restriction> </restrictedBy> </Class> <Person ID = "Joe"> <parent resource = "#John” /> </Person> Those descriptions are equivalent to the following set of RDF statements: (type Person Class) (subClassOf Person Animal) (type Restriction R) The restriction is unnamed in the RDF markup. We use the arbitrary name “R” here to denote the restriction. (restrictedBy Person R) (onProperty R parent) (toClass R Person) (type Joe Person) (parent Joe John) Those RDF statements are translated by our axiomatic semantics into the following KIF sentences: (Type Person Class) (PropertyValue subClassOf Person Animal) (Type R Restriction) (PropertyValue restrictedBy Person R) (PropertyValue onProperty R parent) (PropertyValue toClass R Person) (Type Joe Person) (PropertyValue Parent Joe John) Informally, the “toClass” restriction stated in these sentences is that parents of persons are also persons. Therefore, we should be able to infer from these sentences and the DAML-ONT axioms that “John” is type “Person”. That inference can be made using the primary axiom (i.e., Ax30) associated with property “toClass”. Axiom Ax30 is as follows: (=> (and (PropertyValue restrictedBy ?c1 ?r) (PropertyValue onProperty ?r ?p) (PropertyValue toClass ?r ?c2)) (forall (?i ?v) (=> (and (Type ?i ?c1) (PropertyValue ?p ?i ?v)) (Type ?v ?c2)))) The axiom says that if object R is a value of “restrictedBy” for object C1, object P is a value of “onProperty” for R, and object C2 is a value of “toClass” for R, then for all objects I and V, if I is of type C1 and V is a value of P for I, then V is type C2. In this axiom, if variable ?c1 is bound to “Person”, variable ?r is bound to “R”, variable ?p is bound to “parent”, and variable ?c2 is bound to “Person”, then the sentences describing the “toClass” restriction on the parents of persons satisfy the conjunction that is the antecedent of the implication that is Ax30. One can therefore infer the following corresponding instance of the consequence of that implication: (forall (?i ?v) (=> (and (Type ?i Person) (PropertyValue parent ?i ?v)) (Type ?v Person))) If variable ?i is bound to “Joe” and variable ?v is bound to “John”, then the sentences describing “Joe” satisfy the conjunction that is the antecedent of the above inferred implication. One can therefore infer the following corresponding instance of the consequence of that implication: (Type John Person) That completes a proof that “John” is type “Person”. DAML-ONT Classes This section describes the axioms for the classes that are included in DAML-ONT. For each of these classes C, there is an axiom stating that C is type “Class”. The full logical specification of the axioms is available in [Fikes-McGuinness:2000]. Thing Every object is type Thing. Nothing Every object is not type “Nothing”. List An object of type “List” is also of type “Sequence”. Disjoint Saying that an object is type “Disjoint” is equivalent to saying that the object is type “List”, that every item in the list is type “Class”, and that the classes in the list are pairwise disjoint. The DAML-ONT property “disjointWith” is used to express pairwise disjointness. Empty “Empty” and “Nothing” are the same class. The DAML-ONT property “asClass” is used to express equivalence of classes. TransitiveProperty Saying that an object P is type “TransitiveProperty” is equivalent to saying that P is type “Property”, and that if object Y is a value of P for object X and object Z is a value of P for Y, then Z is also a value of P for X. Unique Property Saying that object P is type “UniqueProperty” is equivalent to saying that P is type property, and that if objects Y and Z are both values of P for object X, then Y and Z are the same object. UnambiguousProperty Saying that an object P is type “UnambiguousProperty” is equivalent to saying that P is type property, and that if object V is a value of P for both objects X and Y, then X and Y are the same object. Restriction, Qualification, and Ontology No axioms other than those stating that each of these are type “Class”. DAML-ONT Properties This section describes the axioms for the properties that are included in DAML-ONT. For each of these properties P, there is an axiom stating that P is type “Property”. The full logical specification of the axioms is available in [Fikes-McGuinness:2000]. disjointWith Saying that object C2 is a value of property “disjointWith” for object C1 is equivalent to saying that C1 and C2 are each type “Class”, that no object is both type C1 and type C2, and that there is at least one object that is type C1 or type C2. unionOf Saying that object L is a value of “unionOf” for object C1 is equivalent to saying that C1 is type “Class”, L is type “List”, every item in list L is type “Class”, and an object is type C1 if and only if it is type of one of the items of list L. disjointUnionOf Saying that object L is a value of “disjointUnionOf” for object C is equivalent to saying that L is a value of property “unionOf” for C (i.e., that class C is the union of the classes in list L) and that L is type “Disjoint” (i.e., the classes in list L are pairwise disjoint). intersectionOf Saying that object L is a value of “intersectionOf” for object C1 is equivalent to saying that C1 is type “Class”, L is type “List”, all of the items in list L are type “Class”, and an object is type C1 if and only if it is type of all of the items of list L. complementOf Saying that object C2 is a value of “complementOf” for object C1 is equivalent to saying that C2 is a value of “disjointWith” for C1 (i.e., C1 and C2 are disjoint classes) and all objects are either type C1 or type C2. oneOf Saying that object L is a value of “oneOf” for object C is equivalent to saying that C is type “Class”, L is type “List”, and the objects that are type C are exactly the items in list L. asClass Saying that object C is a value of “asClass” for object L is the equivalent of saying that something is of type C if and only if it is a member of the list L (i.e. it is the first of L or a member of the rest of L.) first Saying that object X is a value of “first” for object L is equivalent to saying that L is type “List”, L has at least one item, and the first item of L is X. rest Saying that object R is a value of “rest” for object L is equivalent to saying that L is type “List”, R is type “List”, L has at least one item, and L has the same items in the same order as list R with one additional object as its first item. item Saying that object X is a value of “item” for object L is equivalent to saying that L is type “List” and either X is a value of “first” for L (i.e., X is the first item in list L) or there is an object R that is a value of “rest” for L (i.e., there is a list R that is the rest of list L) and X is a value of “item” for R (i.e., X is an item in the list R). cardinality Saying that object N is a value of “cardinality” for object P is equivalent to saying that P is type “Property” and for all objects X, any list containing no repeated items and containing exactly those objects V such that V is a value of P for X is of length N. maxCardinality Saying that object N is a value of “maxCardinality” for object P is equivalent to saying that P is type “Property” and for all objects X, the length of any list containing no repeated items and containing exactly those objects V such that V is a value of P for X is equal to or less than N. minCardinality Saying that object N is a value of “minCardinality” for object P is equivalent to saying that P is type “Property” and for all objects X, there exists a list of length at least N that contains no repeated items and contains only objects V such that V is a value of P for X. inverseOf Saying that object P2 is a value of “inverseOf” for object P1 is equivalent to saying that P1 is type “Property”, P2 is type “Property”, and that object X2 is a value of P1 for object X1 if and only if X1 is a value of P2 for X2. restrictedBy If object R is a value of “restrictedBy” for object C, then R is type “Resource” and C is type “Class”. onProperty If object P is a value of “onProperty” for object RQ, then P is type “Property” and RQ is either type “Restriction” or type “Qualification”. toValue If object V is a value of “toValue” for object R, then R is type “Restriction”. If object R is a value of “restrictedBy” for object C, object P is a value of “onProperty” for R, and object V is a value of “toValue” for R, then for all objects I of type C, V is a value of P for I. (I.e., a “toValue” restriction of V on a property P on a class C constrains each object I of type C to have V as a value of property P.) toClass If object C is a value of “toClass” for object R, then R is type “Restriction” and C is type “Class”. If object R is a value of “restrictedBy” for object C1, object P is a value of “onProperty” for R, and object C2 is a value of “toClass” for R, then for all objects I and V, if I is of type C1 and V is a value of P for I, then V is type C2. (I.e., a “toValue” restriction of C2 on a property P on a class C1 constrains each P value of each object of type C1 to be type C2.) qualifiedBy If object Q is a value of “qualifiedBy” for object C, then Q is type “Qualification” and C is type “Class”. hasValue If object C is a value of “hasValue” for object Q, then C is type “Class” and Q is type “Qualification”. If object Q is a value of “qualifiedBy” for object C1, object P is a value of “onProperty” for Q, and object C2 is a value of “hasValue” for Q, then for all objects I of type C1, there exists an object V such that V is a value of P for I and V is type C2. (I.e., a “hasValue” restriction of C2 on a property P on a class C1 constrains each object of type C1 to have a value of type C2.) versionInfo If object V is a value of “versionInfo” for object O, then O is type “Ontology”. imports If object O2 is a value of “imports” for object O1, then O1 is type “Ontology” and O2 is type “Ontology”. equivalentTo Saying that object Y is a value of “equivalentTo” for object X is equivalent to saying that X and Y are the same object. default If object V is a value of “default” for object P, then P is type “Property”. Conclusions The ontology language for a semantic web needs to be able to express common elements such as classes, properties, restrictions, and objects in the domain. We have provided a historical perspective on the evolution of the initial ontology language for the DAML program. We introduced the language through example. We also provided an axiomatization of the language (and in doing so, also provided an axiomatization for the building blocks of the language—RDF). We showed a short proof using the axioms showing how they can be used to make the inferences mentioned in the introduction by example. We believe that this language is a useful starting point for describing web content. It builds on decades of research in frame-based systems, description logics, and web languages. It thus has the benefit of years of research on languages, complexity, and usability and may be positioned to be the foundation for the next evolution of web access. It also provided the merging point for the eventual DAML ontology language formed by more tightly integrating the OIL language into DAML-ONT. Acknowledgements DAML-ONT is the result work from many people. The US Defense Advanced Research Projects Agency funds the DAML project. The ontology language originated within the program but has been heavily influenced by work beyond DARPA, in particular by work from the European Union funded Semantic Web projects. This paper is authored by two of the three original editors of the language release, the DAML program director, and the co-author of the axiomatic semantics. We would explicitly like to acknowledge the impact of the other original co-editor—Dan Connolly—for his significant impact on the initial language release. The language has been influenced heavily by others including Tim Berners-Lee, Frank van Harmelen, Ian Horrocks, Dan Brickley, Mike Dean, Stefan Decker, Pat Hayes, Jeff Heflin, Drew McDermott, Peter Patel-Schneider, and Ralph R. Swick. The evolving list of major contributors is maintained on www.daml.org. DAML-ONT -has since merged into a new ontology language called DAML+OIL (see http://www.daml.org/2001/03/daml+oil-index for the release). We will be producing an updated paper reflecting the larger language. Also, DAML is expected to include a logic language (DAML-L) and a service language (DAML-S). References S. Bechhofer et al., “An Informal Description of OIL-Core and Standard OIL: A Layered Proposal for DAML-O,” www.ontoknowledge.org/oil/downl/dialects.pdf Tim Berners-Lee. Semantic Web Road Map. 1998. http://www.w3.org/DesignIssues/Semantic.html Tim Berners-Lee, David R. Karger , Lynn Andrea Stein , Ralph R. Swick, and Daniel J. Weitzner. Semantic Web Development. 2000. http://www.w3.org/2000/01/sw/DevelopmentProposal Alex Borgida, Ronald J. Brachman, Deborah L. McGuinness, and Lori Alperin Resnick. ``CLASSIC: A Structural Data Model for Objects'', Proceedings of the 1989 ACM SIGMOD International Conference on Management of Data, Portland, Oregon, June, 1989, pp. 59--67. Ronald J. Brachman, James G. Schmolze, `An Overview of the KL-ONE Knowledge Representation System', Cognitive Science, Vol 9(2), pp 171-216, 1985. 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. Vinay Chaudhri, Adam Farquhar, Richard Fikes, Peter Karp, and James Rice; “OKBC: A Programmatic Foundation for Knowledge Base Interoperability”, AAAI 1998. Adam Farquhar, Richard Fikes, and James Rice; “The Ontolingua Server: a Tool for Collaborative Ontology Construction”, Intl. Journal of Human-Computer Studies 46, 1997. Richard Fikes & Tom Kehler, "The Role of Frame-Based Representation in Reasoning", CACM 28(9): 904-920 (1985). Peter D. Karp, "The design space of frame knowledge representation systems", Technical Report 520, SRI International AI Center; available on line as ftp://www.ai.sri.com/pub/papers/karp-freview.ps.Z F. Donini, M. Lenzerini, D. Nardi, and W. Nutt. `The Complexity of Concept Languages', KR-91, pp 151-162, 1991. F. Donini, M. Lenzerini, D. Nardi, and W. Nutt. Tractable concept languages', IJCAI-91, pp 458-465, 1991. Richard Fikes and Deborah L. McGuinness. “An Axiomatic Semantics for DAML-ONT,” December 10, 2000. www.ksl.stanford.edu/people/dlm/daml-semantics . Dieter Fensel, Ian Horrocks, Frank van Harmelen, Stefan Decker, M. Erdmann, and M. Klein. OIL in a nutshell. In Proceedings of the European Knowledge Acquisition Conference (EKAW-2000), Lecture Notes In Artificial Intelligence. Springer-Verlag, 2000. Richard Fikes & Deborah L. McGuinness, "An Axiomatic Semantics for RDF, RDF Schema, and DAML+OIL", KSL Technical Report KSL-01-01, Stanford University, 2001; available on-line as http://www.ksl.stanford.edu/people/dlm/daml-semantics/abstract-axiomatic-semantics.html. J. Heflin and J. Hendler, “Semantic Interoperability on the Web,” Proc. Extreme Markup Languages 2000, Graphic Communications Assoc., Montreal, Canada 2000, pp. 111–120. Horrocks, I., Patel-Schneider, P., `Optimizing description logic subsumption', Journal of Logic and Computation, Vol 9(3), pp 267-293, 1999. I. Horrocks and U. Sattler: A description logic with transitive and inverse roles and role hierarchies. Journal of Logic and Computation, 9(3):385-410, 1999. I. Horrocks, U. Sattler, and S. Tobies. Practical reasoning for very expressive description logics. Logic Journal of the IGPL, 8(3):239-263, 1999. O. Lassila, “Web Metadata: A Matter of Semantics,” IEEE Internet Computing, vol. 2, no. 4, July/Aug. 1998, pp. 30–37. 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 . Robert M. MacGregor: Inside the LOOM Description Classifier. SIGART Bulletin 2(3): 88-92 (1991) Lynn Andrea Stein and Dan Connolly. Annotated DAML Ontology Markup. 2000. www.daml.org/2000/10/daml-walkthru