DAML-ONT: An Ontology Language for the Semantic Web
Deborah McGuinness
Gates Building 2A
Stanford University
Stanford, CA 94305
USA
650-723-9770
Richard Fikes
Gates Building 2A
Stanford University
Stanford, CA 94305
USA
650-723-9770
Lynn Andrea Stein
Franklin W. Olin College of Engineering
1735 Great Plain Avenue
Needham, MA 02495
USA
781-292-2525
James Hendler
DARPA/ISO
3701 N. Fairfax Dr.
Arlington, VA 22203
703-696-2238
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.[1]
An update to this paper that begins with DAML+OIL is in preparation and will be available from www.ksl.stanford.edu/people/dlm/ .
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.
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>
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.
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.
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.
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>
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[2]. 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[3].
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"/>
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.
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 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:
Ax1. (<=>[4] (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:
Ax2. (=>[5] (Type ?r ?c) (and (Type ?r Resource) (Type ?c Class)))[6]
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”, … .
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”.
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.
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)[7]
(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”.
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].
Ax3.
Every object is
type Thing.
Ax4.
Every object is not
type “Nothing”.
Ax5.
An object of type
“List” is also of type “Sequence”.
Ax6.
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.[8]
Ax7.
“Empty” and
“Nothing” are the same class.[9]
Ax8.
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.
Ax9.
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.
Ax10. 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.
No axioms other than those stating that each of these are type “Class”.
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].
Ax11. 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.
Ax12. 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.
Ax13. 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).
Ax14. 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.
Ax15. 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.
Ax16. 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.
Ax17. 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
Ax18. 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.
Ax19. 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.
Ax20. 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).
Ax21. 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.
Ax22. 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.
Ax23. 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.
Ax24. 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.
Ax25. If object R is a value of “restrictedBy”
for object C, then R is type “Resource” and C is type “Class”.
Ax26. 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”.
Ax27. If object V is a value of “toValue” for
object R, then R is type “Restriction”.
Ax28. 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.)
Ax29. If object C is a value of “toClass” for
object R, then R is type “Restriction” and C is type “Class”.
Ax30. 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.)
Ax31. If object Q is a value of “qualifiedBy” for
object C, then Q is type “Qualification” and C is type “Class”.
Ax32. If object C is a value of “hasValue” for
object Q, then C is type “Class” and Q is type “Qualification”.
Ax33. 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.)
Ax34. If object V is a value of “versionInfo” for
object O, then O is type “Ontology”.
Ax35. If object O2 is a value of “imports” for
object O1, then O1 is type “Ontology” and O2 is type “Ontology”.
Ax36. Saying that object Y is a value of
“equivalentTo” for object X is equivalent to saying that X and Y are the same
object.
Ax37. If object V is a value of “default” for
object P, then P is type “Property”.
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.
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).
1.
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
2.
Tim
Berners-Lee. Semantic Web Road
Map. 1998. http://www.w3.org/DesignIssues/Semantic.html
3.
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
4. 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.
5. Ronald J. Brachman, James G. Schmolze, `An Overview of the KL-ONE Knowledge Representation System', Cognitive Science, Vol 9(2), pp 171-216, 1985.
6. 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.
7. Vinay Chaudhri, Adam Farquhar, Richard Fikes, Peter Karp, and James Rice; “OKBC: A Programmatic Foundation for Knowledge Base Interoperability”, AAAI 1998.
8. Adam Farquhar, Richard Fikes, and James Rice; “The Ontolingua Server: a Tool for Collaborative Ontology Construction”, Intl. Journal of Human-Computer Studies 46, 1997.
9. Richard Fikes & Tom Kehler, "The Role of Frame-Based Representation in Reasoning", CACM 28(9): 904-920 (1985).
10. 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
11. F. Donini, M. Lenzerini, D. Nardi, and W. Nutt. `The Complexity of Concept Languages', KR-91, pp 151-162, 1991.
12. F. Donini, M. Lenzerini, D. Nardi, and W. Nutt. Tractable concept languages', IJCAI-91, pp 458-465, 1991.
13. Richard Fikes and Deborah L. McGuinness. “An Axiomatic Semantics for DAML-ONT,” December 10, 2000. www.ksl.stanford.edu/people/dlm/daml-semantics .
14. 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.
15. 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.
16. J. Heflin and J. Hendler, “Semantic Interoperability on the Web,” Proc. Extreme Markup Languages 2000, Graphic Communications Assoc., Montreal, Canada 2000, pp. 111–120.
17. Horrocks, I., Patel-Schneider, P., `Optimizing description logic subsumption', Journal of Logic and Computation, Vol 9(3), pp 267-293, 1999.
18. 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.
19. I. Horrocks, U. Sattler, and S. Tobies. Practical reasoning for very expressive description logics. Logic Journal of the IGPL, 8(3):239-263, 1999.
20. O. Lassila, “Web Metadata: A Matter of Semantics,” IEEE Internet Computing, vol. 2, no. 4, July/Aug. 1998, pp. 30–37.
21. 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 .
22. Robert M. MacGregor: Inside the LOOM Description Classifier. SIGART Bulletin 2(3): 88-92 (1991)
23. Lynn Andrea Stein and Dan Connolly. Annotated DAML Ontology Markup. 2000. www.daml.org/2000/10/daml-walkthru
[1] 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].
[2] The namespace prefix rdf is arbitrary. The name in this document would be the conventional choice.
[3] 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 .
[4] 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.
[5] KIF note: “=>” means “implies”.
[6] 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)”.
[7] The restriction is unnamed in the RDF markup. We use the arbitrary name “R” here to denote the restriction.
[8] The DAML-ONT property “disjointWith” is used to express pairwise disjointness.
[9] The DAML-ONT property “asClass” is used to express equivalence of classes.