DAML+OIL: An Ontology Language for the Semantic Web

wafflebazaarInternet and Web Development

Oct 21, 2013 (3 years and 9 months ago)


1094-7167/02/$17.00 ©2002 IEEE IEEE INTELLIGENT SYSTEMS
T h e S e m a n t i c W e b
An Ontology Language
for theSemantic Web
Deborah L. McGuinness and Richard Fikes,Stanford University
James Hendler,University of Maryland
Lynn Andrea Stein,Franklin W. Olin College of Engineering
y all measures,the Web is enormous and growing at a staggering rate,which has
made it increasingly difficult—and important—for both people and programs to
have quick and accurate access to Web information and services. The Semantic Web
offers a solution,capturing and exploiting the meaning of terms to transform the Web from
a platform that focuses on presenting information,
to a platform that focuses on understanding and rea-
soning with information.
To support Semantic Web development,the US
Defense Advanced Research Projects Agency
launched the DARPA Agent Markup Language
(DAML) initiative to fund research in languages,
tools,infrastructure,and applications that make Web
content more accessible and understandable.
Although the US government funds DAML,several
organizations—including US and European busi-
nesses and universities,and international consortia
such as the World Wide Web Consortium—have con-
tributed to work on issues related to DAML’s devel-
opment and deployment.
Our focus in this article is on DAML’s current
markup language,DAML+OIL,which is a proposed
starting point for the W3C’s Semantic Web Activ-
ity’s Ontology Web Language (OWL). Here,we
introduce DAML+OIL’s syntax and usage through
a set of examples,drawn from a wine knowledge
base used to teach novices how to build ontologies.
DAML+OIL: Early releases
As the sidebar “DAML Evolution” explains,
DAML+OIL evolved from a merger of DAML-
an earlier DAML ontology language,and the
Ontology Inference Layer (OIL),a description
The goal of this merger was to integrate the
formal foundations found in description logics
DAML and revise DAML-ONT in response to com-
munity comments.
Generally,compared with DAML-ONT,DAML+
OIL places much more emphasis on clear semantics,
using both our updated first-order logic (FOL)
semantics and a model-theoretic semantics (see
and www.daml.org/2000/12/model-theoretic-seman-
tics.html,respectively). DAML+OIL also introduced
several language constructors that increased the
expressive power of DAML.
The first version of DAML+OIL was released in
December 2000. Because a timely release was cru-
cial,the first version did not address data type inte-
gration. Among the new features the first release
introduced were
• Improved handling for some concepts,including
the top concept
• Local cardinality restrictions
• Cleaner,modified restriction semantics
• Integration of necessary and sufficient conditions
That version also included name changes for a few con-
structors and eliminated a few language features that
had unclear semantics or redundant usage. (A com-
plete discussion of the differences between DAML-
ONT and DAML+OIL’s first release appears else-
) The current version of DAML+OIL
(www.daml.org/2001/03) was released in March 2001;
DAML+OIL’s goal is
to support the
transformation of the
Web from being a
forum for information
presentation to a
resource for
it extends DAML+OIL with arbitrary data-
types from the XML Schema type system.
An introduction through
To capture terms and their meaning,a lan-
guage must describe object classes and rela-
tions between objects,and ground objects in
the domain of discourse. To introduce basic
DAML+OIL language notions,we’ll use an
extended example in the style of the Anno-
tated DAML+OIL Markup.
domain is wine and we use examples from
the Classic tutorial.
The examples use the
Resource Description Framework serialized
into XML (RDF/XML). The full DAML+OIL
ontology language is available at www.daml.
org,which includes several more-sophisti-
cated features that are beyond this article’s
scope. In addition,the sidebar “DAML
Resources” offers pointers to further infor-
mation sources.
Describing classes
An ontology consists of object descrip-
tions. To help us describe objects,we first
describe object types. If we’re interested in
wines and foods,for example,we describe
general classes,such as the wine class:
<daml:Class rdf:ID=“Wine”>
This states that there is a Class known as Wine;
it says nothing more about wine,nor does it
imply that it’s the sole source of information
about wine. However,stating that the RDF
IDis Wine lets us later add sentences that refer
to this basic wine description (using the URI
of the containing page,followed by #Wine).
The “RDF Namespaces” sidebar on page 77
offers details on the RDF namespace scheme.
Next,we annotate terms with labels and
<rdfs:comment> Wine is a class. It will be used for
pedagogical purposes.
This wine class illustrates two key ontolog-
ical idioms:label and comment. A label is a
brief identifier of the enclosing element,suit-
able for graphical representations of RDF
and so on. A comment is a natural language
description of the element it is included
within. Neither labels nor comments con-
tribute to the DAML’s logical interpretation.
To close the description,we use
Next,to describe a wine type,such as red
or white wine,we write
<daml:Class rdf:ID=“RedWine”>
<rdfs:subClassOf rdf:resource=“#Wine”/>
The subClassOf element asserts that its sub-
ject—RedWine—is a subclass of its object,
which is the resource identified by #Wine.
Similarly,we describe WhiteWine:
<daml:Class rdf:ID=“WhiteWine”>
<rdfs:subClassOf rdf:resource=“#Wine”/>
To state that no wine can be simultane-
ously a RedWine and a WhiteWine,we combine
the about tag and disjointWith tag:
<daml:Class rdf:about=“#WhiteWine”>
<rdfs:comment>no wine is both a red and a
white wine</rdfs:comment>
<daml:disjointWith rdf:resource=
Describing individuals
To introduce individuals,we use the same
syntax. For example,imagine that we want
to say that our favorite drink is a red wine,or
that a particular wine,Marietta Zinfandel,is
red. To do this,we must provide the syntax
for describing the individuals,MyFavoriteDrink
and MariettaZinfandel. We begin this DAML
statement with the type of thing we’re
describing,in this case RedWine:
<RedWine rdf:ID=“MyFavoriteDrink”>
<rdfs:comment>MyFavoriteDrink is a
<RedWine rdf:ID=“MariettaZinfandel”>
<rdfs:comment>MariettaZinfandel is a
Although we attach the label and comment
attributes to the individuals,MyFavoriteDrink and
MariettaZinfandel,neither carries semantics for
the computer or an automatic reasoner. How-
ever,they do use inference. Because we
know that MyFavoriteDrink is a RedWine and also
that MariettaZinfandel is a RedWine,and we know
that red wines are wines,we thus know that
MyFavoriteDrink and MariettaZinfandel are instances
of the class RedWine.
Describing properties
We use properties to relate individuals to
each other. So far,we have a simple class,
Wine,and two subclasses (RedWine and
WhiteWine) distinguished by color. Properties
let us introduce associated object properties,
such as a wine’s body and its sugar level. To
introduce the color property,we use
<daml:ObjectProperty rdf:ID=“hasWineColor”>
The property description begins much like
that of the class,basically stating that there is
a property called hasWineColor. Although some
of the wine knowledge base encodings use a
simple property-naming convention,such as
color,we use the convention with a leading
prefix,has,for clarity’s sake,to distinguish
properties that we could use with other
classes,and to state the domain restriction in
the name. To limit the kinds of individuals
that can fill the hasWineColor property,we must
state the property’s range. To do this,we
describe a class that represents valid wine
colors and use that as the property range:
<rdfs:range rdf:resource=“#WineColor”/>
That said,using a term such as WineColor
before it is described is perfectly valid.
Next,to state that the property applies to
things that are wine,we state the property’s
<rdfs:domain rdf:resource=“#WINE”/>
To close the hasWineColor property,we use
Because domains and ranges offer global
information about properties,using overly
restrictive domain or range restrictions can
create problems,such as limited reuse. In this
case,using a restrictive name for our prop-
erty was appropriate,clearly associating it
only with the wine domain. We also created
a similarly restrictive class for the range
restriction. However,as we now describe,it is
possible to restrict the property’s restriction,
rather than use global domain and range
SEPTEMBER/OCTOBER 2002 computer.org/intelligent
Property restrictions
So far,we’ve introduced the wine class,
but have not placed any restrictions on its
properties. We now add restrictions,which
gives the class internal structure:
<daml:Class rdf:about=“#Wine”>
<rdfs:comment> Wines must have a wine color,
and the filler for this property must be of the
type WineColor. (However, not everything with
a color of type WineColor is a wine).
<daml:Restriction daml:minCardinality=“1“>
<daml:onProperty rdf:resrouce=
<daml:onProperty rdf:resource=
<daml:toClass rdf:resource=
Wine is now a subclass of two restric-
tions:one that restricts the minimum
computer.org/intelligent IEEE INTELLIGENT SYSTEMS
The DAML Web ontology language has evolved over several
years. Here we offer a historical and motivational perspective
on its growth.
Research influences
Work on the DAML ontology languages was inspired by
three basic building blocks: Web integration, frame-based sys-
tems, and description logics.
Web integration
Our most critical requirement for DARPA Agent Markup
Language’s initial ontology language, DAML-ONT, was easy Web
integration with RDF
(with embedded XML) and RDF Schema.
This gives the language crucial backward compatibility with
existing Web standards, permitting interoperability with the
growing base of content and language tools, and also works for
users who are comfortable with existing languages. DAML-ONT
provided expressive power that went beyond RDF and RDF
Schema by capturing semantic relations in machine-readable
form using more expressive term descriptions and more precise
semantics. This is important for many reasons; arguably the most
salient is to facilitate agent intercommunication.
Frame-based systems
DAML-ONT was also influenced by systems that emphasized
paradigms supporting conceptual modeling. Many developers
perceived frame systems as acceptable and easy to use and
have embraced them relatively widely.
Thus, we were also
influenced by systems with a frame-based look and feel or
application programming interfaces such as Ontolingua,
Open Knowledge Base Connectivity (OKBC),
the Extensible
Ontology Languages (XOL and iXOL),
and General Frame
Protocol (GFP).
A particularly notable influence on our work was Simple
HTML Ontology Extensions,
which was the first frame-based
knowledge-representation language specifically designed for
Web use. SHOE extended HTML (and later XML) to permit the
description of classes and their properties, as well as Horn-
clause-like inference rules. We based many key Web-enable-
ment constructors in both DAML-ONT and DAML+OIL on SHOE
mechanisms. Given our goal to make the DAML ontology lan-
guage accessible to the masses, choosing paradigms that were
easy to explain and use was important.
Description logics
Our work on DAML-ONT was partially motivated by work in
description logics (www.dl.kr.org), which offers a formal foun-
dation for frame-based systems. Some early description-logic–
based systems include KL-One,
and Loom;
recent examples include Fact
and the Ontology Inference
Layer (OIL).
Description logics emphasize clear, unambiguous
languages supported by complete denotational semantics and
tractable reasoning algorithms. Researchers have heavily ana-
lyzed description logics to understand how constructors inter-
act and combine to impact tractable reasoning (see, for exam-
ple, work by Donini and colleagues
). Other work has stud-
ied reasoning algorithms to further their efficiency, including,
for example, work by Horrocks and colleagues.
Although our work on DAML-ONT drew generally on descrip-
tion logics research, we took particular inspiration from OIL, the
latest description logic. Researchers designed OIL to be an ex-
pressive description logic integrated with modern Web technol-
ogy. Finally, the ontology language drew inspiration from the
Knowledge Interchange Format, which is an FOL-based pro-
posed ANSI standard for knowledge interchange.
Early DAML language releases
DAML-ONT was initially released in October 2000.
The lan-
guage was subsequently taken over by a DAML language com-
mittee, which, in turn, expanded to become the Joint US/EU
ad hoc Agent Markup Language Committee. This committee
has been responsible for all other DAML ontology language
releases to date.
The initial release
DAML-ONT’s initial release was basically an extension of RDF
Schema vocabulary, with input from frame-based systems and
description logics. We chose initial constructors from use-case
analysis experience with RDF and XML (and a few other lan-
guages) and from SHOE use cases.
At that time, one of our primary goals was to produce a lan-
guage quickly so that experimentation could inform further
development. The DAML program rapidly formed an ontology
library for the larger community to submit, store, and reuse
the DAML ontologies. Along with timeliness, Web language
compatibility was the primary concern. Usability issues (related
to frame languages) and clean formal foundations (related to
description logics) were secondary.
Approaching DAML+OIL
Following the initial release, Richard Fikes and Deborah
McGuinness produced a FOL semantics for DAML-ONT,
gave the language a more precise foundation for semantic
analysis. Simultaneously, the joint committee began evolving the
language in accordance with needs expressed by reviewers and
the potential user community. Among those needs were for a
more formal specification of the language’s meaning. People in
the description logic community—which typically offers formal
DAML’s Evolution
T h e S e m a n t i c W e b
number of fillers for the hasWineColor prop-
erty and another that restricts the prop-
erty’s filler type. Each restriction actually
describes an anonymous class—the class
of all things that satisfy the restriction. In
the first case,it is the class of all things
that have at least one filler for the prop-
erty hasWineColor. The syntax here is a
cliché; that is,it is always used as shown,
except for
• The resource name in the OnProperty ele-
ment,which is the name of the restricted
• The resource associated with the toClass ele-
ment,which gives the name of the class to
which the property is restricted
In the earlier section,“Properties,” we
showed how to restrict the range of all uses
of the hasWineColor property. In the statement
above,however,we restrict the range of
hasWineColor only when it is used on the Wine
class. In general,stating toClass restrictions
locally to provide range restrictions results
in more extendable—and therefore more
reusable—ontologies. In the first wine
knowledge bases,for example,we had one
color property and restricted its range using a
toClass restriction on the Wine class,thereby
limiting its use on wines to the range of wine-
SEPTEMBER/OCTOBER 2002 computer.org/intelligent
semantic specifications with language descriptions—identified
sources of ambiguity. Users also identified where language
designers had differing interpretations of meanings. This moti-
vated both the FOL semantics effort to offer a clear specification
of meaning, while simultaneously motivating a true integration
of description logic principles into the DAML ontology language.
Because DAML-ONT’s goals were now very similar to those of
OIL, we naturally considered merging the best features of both
languages. OIL had several attractive qualities. First, one of its
goals was to be a Web ontology language with a firm formal
foundation, and the language was already designed and
documented. OIL developers had also carefully evaluated its
constructor choices so as to maintain tractability. Finally, OIL,
and later DAML+OIL, used SHIQ—a well-studied and fairly
expressive description logic with good formal properties—as an
underlying formal description logic (for more on SHIQ, includ-
ing the various properties represented by the acronym and vari-
ant description logics, see the Description Logic Handbook
appendix at http://titles.cambridge.org/catalogue.asp?isbn.
1.O. Lassila, “Web Metadata: A Matter of Semantics,” IEEE Internet
Computing, vol. 2, no. 4, July/Aug. 1998, pp. 30–37.
2.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.
3.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.
4.R. Fikes and T. Kehler, “The Role of Frame-Based Representation in
Reasoning,” Comm. ACM, vol. 28, no. 9, Sept. 1985, pp. 904–920.
5.P. D. Karp, The Design Space of Frame Knowledge Representation
Systems, tech. report 520, AI Center, SRI Int’l, Menlo Park, Calif.;
6.V. Chaudhri et al., OKBC: A Programmatic Foundation for Knowl-
edge Base Interoperability, AAAI Press, Menlo Park, Calif., 1998.
7.A. Farquhar, R. Fikes, and J. Rice, “The Ontolingua Server: A Tool
for Collaborative Ontology Construction,” Int’l. J. Human-
Computer Studies, vol. 46, no. 6, 1 June 1997, pp. 707–727.
8.P. D. Karp, V.K. Chaudhri, and J. F. Thomere, “XOL: An XML-Based
Ontology Exchange Language,” tech. note 559, AI Center, SRI Int’l,
Menlo Park, Calif., 1999.
9.S. Luke et al., “Ontology-Based Web Agents,” Proc. 1st Int’l Conf.
Autonomous Agents, ACM Press, New York, 1997, pp. 59–68.
10.J. Heflin, Towards the Semantic Web: Knowledge Representation
in a Dynamic Distributed Environment, doctoral dissertation, Com-
puter Science Dept., Univ. of Maryland, College Park, Md., 2001.
11.R. Brachman and J. Schmolze, “An Overview of the KL-ONE Knowl-
edge Representation System,” Cognitive Science, vol. 9, no. 2,
1985, pp. 171–216.
12.A. Borgida et al., “Classic: A Structural Data Model for Objects,”
Proc. 1989 ACM SIGMOD Int’l Conf. Management of Data, ACM
Press, New York, 1989, pp. 59–67.
13.R.M. MacGregor, “Inside the LOOM Description Classifier,” Sigart
Bulletin, vol. 2, no. 3, June 1991, pp. 88–92; http://dblp.uni-trier.de/
14.I. Horrocks, “FaCT and iFaCT,” Proc. Int’l Workshop on Description
Logics (DL 99), Technical Univ. of Aachen, Germany, 1999, pp. 133–
15.D. Fensel et al., “OIL: An Ontology Infrastructure for the Semantic Web,”
IEEE Intelligent Systems, vol. 16, no. 2, Mar./Apr. 2001, pp. 38–45.
16.F. Donini et al., “The Complexity of Concept Languages,” Proc. 2nd
Int’l Conf. on Principles of Knowledge Representation and Reason-
ing, Morgan Kaufmann, San Francisco, 1991, pp. 151–162.
17.F. Donini et al., “Tractable Concept Languages,” Int’l Joint Conf.
Artificial Intelligence (IJCAI 91), Morgan Kaufmann, San Francisco,
1991, pp. 458–465.
18.I. Horrocks and P. Patel-Schneider, “Optimizing Description Logic
Subsumption,” J. Logic and Computation, vol. 9, no. 3, 1999, pp.
19.I. Horrocks and U. Sattler, “A Description Logic with Transitive and
Inverse Roles and Role Hierarchies,” J. Logic and Computation, vol.
9, no. 3, June 1999, pp. 385–410; www3.oup.co.uk/logcom/hdb/
20.I. Horrocks, U. Sattler, and S. Tobies, “Practical Reasoning for Very
Expressive Description Logics,” Logic J. IGPL, vol. 8, no. 3, May 2000,
pp. 239–263; www3.oup.co.uk/igpl/Volume_08/Issue_03.
21.D. Connolly, L. Stein, and D. McGuinness, eds., DAML-ONT Initial
Release, Oct. 2000; www.daml.org/2000/10/daml-ont.html.
22.J. Heflin, J. Hendler, and S. Luke, “Applying Ontology to the Web:
A Case Study,” Int’l Work-Conf. Artificial and Natural Neural Net-
works (IWANN 99), Springer Verlag, Berlin, 1999, pp. 715–724.
23.R. Fikes and D.L. McGuinness, An Axiomatic Semantics for RDF,
RDF-Schema, and DAML-ONT, tech. report, Knowledge Systems
Laboratory, Stanford Univ., Stanford, Calif., Dec. 2000; www.ksl.
Colors, but letting us use the property color on
other classes as well.
Also,in the example above,we specified
a minimum cardinality on the hasWineColor
property,but not a maximum. If we had not
specified anything,a minimum cardinality
of 0 would be assumed. We can add a spe-
cific maximum cardinality,or,if we know
the exact number of fillers for a property,we
can use the cardinality property (instead of
making two statements,one with minCardinal-
ity and one with maxCardinality). In this case,we
could have stated
<daml:Class rdf:about=“#WINE”>
<rdfs:comment>Wines must have exactly one
wine color.
<daml:Restriction daml:cardinality=“1”>
<daml:onProperty rdf:resource=
We can set cardinality to any integer. In
special cases (as above) where the cardinal-
ity is one,we call it a UniqueProperty. As these
examples show,DAML offers multiple ways
of encoding meaning.
Class notations
To construct a class description that lets a
human or computer determine if something
is an instance of a class,we provide
<daml:Class rdf:about=”#RedWine”>
<rdfs:Class rdf:about=”#WINE”/>
<daml:onProperty rdf:resource=
<daml:hasValue rdf:resource=”#RED”/>
This creates a class exactly equivalent to those
things that are both wines and that have red as
the filler of the hasWineColor property. We can
deduce that anything with these two features
is an instance of the class RedWine. Similarly,
anything stated as an instance (or subclass) of
the class RedWine will have these two properties.
Thus,in our example above using the indi-
viduals MyFavoriteDrink and MariettaZinfandel, the
system could conclude that they are both
instances of Wine and instances of the class
with a Red filler for its hasWineColor property.
To create another individual wine,we can
<Wine rdf:ID=“CotturiZinfandel”>
<rdfs:comment>CotturiZinfandel is a Wine whose
color is red and whose maker is Cotturi.
<hasMaker rdf:resource=“#COTTURI”/>
<hasWineColor rdf:resource=“#Red”/>
This individual is automatically recognized
as an instance of the class RedWine,because
we know it is a Wine whose color is Red. Sim-
ilarly,if we had described a class of things
that have at least one color,we could recog-
nize CotturiZinfandel as an instance of that class
as well. Also,we’ve included a new property
in the CotturriZinfandel description named has-
Maker. Although it might be good practice in
conceptual modeling to introduce properties
before they are used,it is not a requirement
A FOL semantics for DAML+OIL
To fully specify a knowledge representa-
tion language,both the syntax and the
semantics of the language must be described.
The syntax description specifies which
strings of characters are legal statements in
the language,and the semantic description
specifies each legal statement’s intended
meaning. The semantics of a representation
language can be formally specified in multi-
ple ways. We have chosen here to specify an
equivalence-preserving translation from
DAML+OIL into FOL. The translation con-
sists of a mapping of DAML+OIL statements
into sentences in FOL accompanied by a set
of FOL axioms that constrain the possible
interpretations of the nonlogical symbols
(that is,the relation symbols,function sym-
bols,and constants) in the FOL sentences the
mapping produced. The translation into FOL
provides a semantics for DAML+OIL in that
any given axiomatization of a logical theory
represented in DAML+OIL is defined to be
logically equivalent to an axiomatization of
a theory represented in FOL,for which a
declarative semantics is known.
Why FOL?
The DAML+OIL specification submitted
to W3C includes both this FOL semantics
and a model-theoretic semantics.
model-theoretic semantics is in the tradi-
tional form,in which an interpretation func-
tion is named for each nonlogical symbol in
the language,and constraints are stated that
must hold for those interpretation functions.
This work complements the model-theoretic
semantics and makes the following addi-
tional contributions.
• Our translation into FOL enables the use of
traditional FOL automatic theorem provers
and problem solvers to answer queries and
search for logical inconsistencies in theo-
ries represented in DAML+OIL.
• Unlike standard descriptions of model-
theoretic semantics,the constraints on the
mappings are represented as axioms in a
language for which automatic reasoning
tools exist. These tools can thus be used to
critique the constraints for inconsistencies
computer.org/intelligent IEEE INTELLIGENT SYSTEMS
For more information on DAML, see the following resources.
• The DAML Web site, www.daml.org, has the ontology language’s full specifi-
cation, an example file, and annotated walkthroughs for both DAML-ONT and
DAML+OIL. The site also contains a DAML ontology library, numerous links to
related work, and DAML-related announcements.
• The World Wide Web Ontology working group site, www.w3.org/2001/sw/
WebOnt/, contains the initial language submission and updated W3C notes on
requirements, use cases, and recent OWL language details and documents.
• The OIL site, www.ontoknowledge.org/oil, has information on the OIL specifi-
cation, documentation, and semantics, and provides use cases. It also has a white
paper with a good introduction to OIL and its denotational semantics specifica-
tion (which was the starting point for the denotational semantics for DAML+OIL;
the latter is available at www.daml.org/2001/03/model-theoretic-semantics.html).
DAML Resources
T h e S e m a n t i c W e b
and redundancies,and determine whether
they entail (only) intended consequences.
Tools to support such critiques are partic-
ularly important for the semantic specifi-
cations of developing languages (such as
DAML+OIL),because they can help
developers debug and understand the con-
sequences of proposed language changes.
• Although it is possible to translate the cur-
rent version of DAML+OIL into a FOL
subset (into a description logic,for exam-
ple),DAML+OIL’s development plan is to
significantly expand its expressive power
to more fully support the expected repre-
sentational demands of Semantic Web on-
tologies. Using FOL translations and rea-
soning methods should both accommodate
and support this plan,and will become
increasingly necessary as the language’s
expressive power expands.
Mapping DAML+OIL to FOL
We map DAML+OIL to FOL using a sim-
ple rule for translating an RDF statement into
a first-order relational sentence. Because
DAML+OIL is simply a vocabulary of prop-
erties,classes,and constants added to RDF
and RDF Schema,and RDF Schema is sim-
ply a vocabulary of properties and classes
added to RDF,all statements in DAML+OIL
are RDF statements. A rule for mapping RDF
statements to FOL is thus sufficient for map-
ping DAML+OIL statements as well.
We produce a logical theory that is logi-
cally equivalent to a DAML+OIL knowledge
as follows:
• Translate the DAML+OIL knowledge
base from its concrete syntax into a col-
lection of RDF statements.
• Translate each RDF statement with prop-
erty P,subject S,and object O into a FOL
sentence of the form (PropertyValue P S O),
where PropertyValue denotes a ternary rela-
tion that relates a property and an entity (a
subject) to a value (an object) that the
property has for that entity.
• Add the axioms that constrain the allow-
able interpretations of the properties,
classes,and constants included in RDF,
RDF Schema,and DAML+OIL.
DAML+OIL’s concrete syntax is typically
something other than <property, subject, object>
triples. (The RDF specification,
for exam-
ple,describes an Extensible Markup Lan-
guage encoding as the concrete syntax for
RDF.) Thus,the first step of the translation
into FOL is a translation from a concrete syn-
tax into RDF statements. The only require-
ments we impose on that translation step is
that each element in the RDF statements it
produces be labeled with either
• A URI or a literal as given in the concrete
• A Skolem constant generated by the trans-
lator for an unlabeled element in the con-
crete syntax (each label generated for unla-
beled statement elements must be distinct)
This translation is designed to place min-
imal constraints on the interpretation of the
nonlogical symbols in the translated logical
theory and to enable the required axioms to
be expressible in FOL. In particular,it does
not require that we translate properties into
binary relations or that we translate classes
into unary relations. The translation there-
fore lets us state axioms that apply to all
properties and all classes (that is,that use a
universally quantified variable for the prop-
erty or class) without quantifying over the
relation in a relational sentence. Such axioms
are thus expressible in FOL.
The axiom language
DAML+OIL axioms are written in ANSI
Knowledge Interchange Format (KIF) using
standard FOL constructs and KIF-specific
relations and functions for integers,which
axiomatize the DAML+OIL properties deal-
ing with cardinality.
As we stated earlier,we translate the RDF
statement Property P of resource R has value V into
the KIF sentence (PropertyValue P R V). Because
the type property is central in RDF,we define
an additional binary relation called Type to
provide a more succinct translation of RDF
statements of the form Property ‘type’ of resource
R has value V. The meaning of the Type relation
is specified by the following axiom:
(<=> (Type ?r ?v) (PropertyValue type ?r ?v))
In KIF,<=> means “if and only if,” rela-
tional sentences have the form (<relation name>
<argument>*),and names with the first char-
acter “?” are variables. Also,if no explicit
quantifier is specified,variables are assumed
to be universally quantified. So,the axiom
above says that for all objects R andV, relation
Type holds for R and V if and only if relation
PropertyValue holds for object type,R,and V.
RDF axioms
Because DAML+OIL is specified as an
extension to the RDF and RDF Schema vocab-
ulary,our axiomatization includes axioms
describing the properties and classes in both
RDF and RDF Schema,as well as those in
DAML+OIL itself.
RDF language is a language for
• Declaring named resources to have type
Property or Class
• Declaring resources to have a given class as
SEPTEMBER/OCTOBER 2002 computer.org/intelligent
Because DAML+OIL is consistent with the RDF namespace scheme, we refer to
RDF namespaces and create a base namespace for work. All ontologies begin with
an RDF start tag and include an appropriate namespace specification. A typical
example of our namespace declaration is the one at the beginning of our wines
The rdf: prefix refers to the official W3C RDF namespace. This is a conventional RDF
declaration and appears verbatim at the beginning of almost every RDF document.
The two declarations following it refer to the XML Schema and RDF Schema data
type namespaces. The fourth declaration refers to namespace terms from www.
daml.org/2001/03/daml+oil#. This is a conventional DAML+OIL declaration and should
appear verbatim at the beginning of all current-generation DAML+OIL documents.
The final declaration states that unprefixed elements refer to terms in the ontology
itself (in this case, the wine example) and provides the ontology file’s location.
RDF Namespaces
a type (Clyde is type Elephant,for example)
• Stating that a given property of a given
resource has a given value (property Color
of Clyde has value Gray,for example)
In RDF,the type property declares that the
type of a resource R is T; such a declaration is
actually a statement that property type of
resource R has value T. Thus,an RDF knowl-
edge base consists entirely of statements of
the form,Property P of resource R has value V.
The axiomatization provides axioms
restricting the interpretation of the RDF
classes and properties. The axioms include
constraints,such as that the first argument of
relation PropertyValue must be a property; that
an entity cannot have both Property and Class as
types (that is,they are disjoint classes); and
that an RDF statement has exactly one property,
one object, and one subject.
RDF Schema axioms
RDF Schema is simply a vocabulary of
properties and classes added to RDF,and the
axiomatization restricts the possible inter-
pretations of those classes and properties.
The added vocabulary includes standard
properties such as subClassOf, subPropertyOf, range,
and domain. The axioms include constraints
such as these:a superclass of an object type
is also a type of that object; if an entity is a
value of another property’s subproperty,then
the entity is also a value of the other prop-
erty; a property value must have the range of
that property as a type; and an object that has
a value for a property must have that prop-
erty’s domain as a type.
DAML+OIL axioms
DAML+OIL is simply a vocabulary of
properties and classes added to RDF and
RDF Schema. The DAML+OIL axioms are
significantly more extensive than the axioms
for either RDF or RDF Schema. They include
constraints that
• Add 12 classes to the subclass taxonomy and
26 properties to the subproperty taxonomy
• Specify domain and range constraints for
each of the new classes and properties
• Define the class of all objects (Thing),the
empty class (Nothing),the class of properties
that are transitive,the class of properties
that can have at most one value for a given
object (UniqueProperty),the class of proper-
ties that can have a given value for at most
one object (UnambiguousProperty),the prop-
erty for stating that classes are disjoint (dis-
jointWith),the property for stating that prop-
erties are inverses of each other (inverseOf),
and the property for stating that classes are
complements of each other (complementOf)
• Define properties for stating the equiva-
lence of objects,classes,or properties
• Define properties for stating that a class is
a union,intersection,or disjoint intersec-
tion of a list of classes
• Define the various kinds of cardinality and
value restrictions
• Define lists and their properties
One of the challenges in writing the
DAML+OIL axioms was axiomatizing the
various cardinality restrictions that are
expressible in the language (minCardinality,max-
CardinalityQ,and so on) without adding a set
theory to FOL. We dealt with this issue by
writing a simple axiomatization of tuples and
their length,and then defined a type of tuple
that has no repeating elements. In those
axioms,we define the empty tuple,EmptyTu-
ple; the binary relation,Item,which relates a
tuple to each of its elements; the unary func-
tion,First, which maps a nonempty tuple to its
first element; the unary function,Rest,which
maps a nonempty tuple to the tuple consist-
ing of its second through last elements; the
unary function,Length,which maps a tuple to
the number of elements it has; and the unary
relation,NoRepeatsTuple,which is true of tuples
that have no repeating elements. The axiom
that defines the NoRepeatsTuple relation is
(<=> (NoRepeatsTuple ?t)
(and (Type ?t Tuple)
(or (= ?t EmptyTuple)
(= (Rest ?t) EmptyTuple)
(and (not (Item (Rest ?t)
(First ?t)))
(Rest ?t))))))
Given this axiomatization,we wrote
axioms for each of the cardinality restric-
tions. As an example,we offer one for cardi-
nality that expresses a constraint on the NoRe-
peatsTuple length and contains all of a given
property’s values at any one object:
(=> (and (PropertyValue onProperty ?r ?p)
(PropertyValue cardinality ?r ?n))
(forall (?i)
(<=> (Type ?i ?r)
(exists (?vl)
(and (NoRepeatsTuple ?vl)
(forall (?v)
(<=> (Item ?vl ?v)
?p ?i ?v)))
(= (Length ?v1) ?n)))))
Example translation and inference
Consider the following DAML+OIL
descriptions of class Wine and of wine My-
<daml:Class rdf:ID = “Wine”>
<rdfs:subClassOf rdf:resource = “Drink”/>
<daml:onProperty rdf:resource =
<daml:toClass rdf:resource = “WineColor”/>
<Wine rdf:ID = “MyFavoriteDrink”>
<has WineColor rdf:resource = “Red”/>
Those descriptions are equivalent to the
following RDF statements:
(rdf:type Wine daml:Class)
(rdfs:subClassOf Wine Drink)
(rdfs:subClassOf Wine GnR) [“GnR” is the generated
label for the unlabeled restriction.]
(rdf:type GnR daml:Restriction)
(daml:onProperty GnR has WineColor)
(daml:toClass GnR WineColor)
(rdf:type MyFavoriteDrink Wine)
(hasWineColor MyFavoriteDrink Red)
Our FOL semantics translate those RDF
statement semantics into the following FOL
(Type Wine daml:Class)
(PropertyValue rdfs:subClassOf Wine Drink)
computer.org/intelligent IEEE INTELLIGENT SYSTEMS
T h e S e m a n t i c W e b
DAML+OIL is simply a
vocabulary of properties and
classes added to RDF and RDF
(Type GnR daml:Restriction)
(PropertyValue rdfs:subClassOf Wine GnR)
(PropertyValue daml:onProperty GnR hasWineColor)
(PropertyValue daml:toClass GnR WineColor)
(Type MyFavoriateDrink Wine)
(PropertyValue has WineColor MyFavoriteDrink Red)
A FOL reasoner can infer from these sen-
tences and the DAML+OIL axioms that Red
is type WineColor. It makes that inference by
first inferring that Red is type GnR,using the
following subClassOf axiom:
(<=> (PropertyValue subClassOf ?csub ?csuper)
(and (Type ?csub rdfs:Class)
(Type ?csuper rdfs:Class)
(forall (?x) (=> (Type ?x ?csub)
(Type ?x ?csuper)))))
If the reasoner substitutes Wine for ?csub and
GnR for ?csuper,the axiom can be used to infer
the following:
(=> (PropertyValue subClassOf Wine GnR)
(=> (Type MyFavoriteDrink Wine)
(Type My FavoriteDrink GnR)))
Because (PropertyValue subClassOf Wine GnR) and
(Type MyFavoriteDrink Wine) are given,the reasoner
can infer (Type MyFavoriteDrink GnR). It can then
infer that Red is type WineColor using the axiom:
(=> (and (PropertyValue onProperty ?r ?p)
(PropertyValue toClass ?r ?c))
(forall (?i)
(<=> (Type ?i ?r)
(forall (?j)
(=> (PropertyValue
?p ?i ?j)
(Type ?j ?c))))))
The axiom says that if R is a toClass restric-
tion on class C for property P,then for all I,I
is type R if and only if all values J of P are type
C. If the reasoner substitutes GnR for ?r,hasWine-
Color for ?p,WineColor for ?c,and MyFavoriteDrink
for ?i,the axiom can be used to infer this:
(=> (PropertyValue hasWineColor MyFavoriteDrink ?j)
(Type ?j WineColor))
If the reasoner substitutes Red for ?j in that inter-
mediate result,it can infer (Type Red WineColor),
which is what we set out to prove.
Theorems for automatic reasoning
A primary motivation for developing a
translation of DAML+OIL into FOL was to
facilitate automatic query-answering—that is,
a deductive retrieval of objects that match a
given set of constraints—from a DAML+OIL
knowledge base. It would be difficult for a rea-
soner to use many of the axioms as written.
We therefore produced a set of theorems that
are inferable from the axioms for RDF,RDF
Schema,and DAML+OIL,and that are in the
Horn Clause form that is conducive to effec-
tive FOL theorem prover use. (A Horn Clause
is an implication of the form (=> (and a1 … an) c),
where each of a1, …, an,and c are atomic sen-
tences. In this case,an atomic sentence is
either an RDF statement or false.)
The theorems (which we list elsewhere
should state all of the RDF statements that
can be inferred about the knowledge base’s
vocabulary—that is,about constants that are
either explicitly mentioned in the knowledge
base or defined in the knowledge base lan-
guage (RDF,RDF Schema,or DAML+
OIL). So,for example,the theorems express
a consequence that an object is not an
instance of a class only if the complement of
the class is already a named class in the
knowledge base.
The theorems can be considered as the
axioms’“intended consequences” expressed
in forms that traditional FOL reasoners can
directly use. Any consequence that a FOL
reasoner is having difficulty making can be
expressed as a Horn clause,which a theorem
prover can attempt to prove from the axioms.
If the proof succeeds,then the Horn clause
is a theorem that a FOL reasoner can use
directly in future reasoning to infer the
intended consequence.
The most important theorems in terms of
facilitating reasoning are those involving the
various cardinality restrictions. The axioms
that define the semantics of cardinality
restrictions using a NoRepeatsTuple are difficult
for FOL reasoners to use effectively. For
example,such reasoners would have diffi-
culty using them to make standard inferences
about inconsistent cardinality restrictions
(such as when a maxCardinality restriction is less
than a corresponding minCardinality restriction)
and equality of property values (such as
when there are two values of a property for
an object that has a maxCardinality restriction of
1). The theorems support each of those stan-
dard inferences by providing a Horn clause
that a reasoner can use to directly make the
desired conclusion.
e’re developing DAML+OIL in
stages. Our initial aim was to cap-
ture term descriptions,as we’ve described
here. The DAML program is now working
on a query language and the integration of a
rule-encoding option. The next major lan-
guage enhancement,DAML-Logic (DAML-
L) will address encoding inference and gen-
eral implications. The DAML Services group
also built a Web service ontology,DAML-S,
which uses DAML+OIL to provide a foun-
dation for Web agents. DAML+OIL was sub-
as the starting point for the W3C
Semantic Web Activity’s OWL. The W3C’s
Web Ontology Working Group has produced
a set of requirements for OWL,as motivated
by a collection of use cases. DAML+OIL
meets the current requirements draft reason-
ably well,and the initial OWL language
description is quite similar to DAML+OIL.
We believe that DAML+OIL is a useful
starting point for describing Web content,
building on decades of research in frame-
based systems,description logics,and Web
languages. Given this foundation,and the
research benefits into languages,complex-
ity,and usability it provides,DAML+OIL
SEPTEMBER/OCTOBER 2002 computer.org/intelligent
DAML: DARPA Agent Markup Language
DAML-Logic:Forthcoming catch-all DAML languages that will address rules and
DAML+OIL:The DAML program’s current ontology language, which merges
DAML-ONT and the Ontology Inference Layer (OIL).
DAML-ONT:The DAML program’s initial ontology language
DAML-S:DAML’s Web services ontology
FOL:First-order logic
KIF: Knowledge Interchange Format, a FOL-based language for knowledge inter-
OIL:Ontology Inference Layer, a description logic
OWL:W3C’s Semantic Web Activity Ontology Web Language
RDF:Resource Description Framework
RDF Schema:A vocabulary of properties and classes added to RDF
could serve as a sound foundation for the
next evolution of Web access. Researchers
have already accepted DAML+OIL as a
starting point for Web semantics representa-
tion and used it for applications ranging from
military intelligence to medical and genetic
database integration. Among the current
development efforts are those focusing on
using DAML+OIL for managing large Web
sites and document and image collections,
integrating disparate databases,and provid-
ing Web services’ interoperability (for more
details,see the DAML Web page).
DAML+OIL is the result of the DAML pro-
gram and the DAML Joint Committee. This arti-
cle was written by two of the three original edi-
tors of the initial DAML language release,the
two authors of the FOL axioms,and the initial
DAML program director. All four authors are
members of the joint committee in charge of
developing of the language. Dan Connolly,one of
the original DAML-ONT coeditors,had a signifi-
cant impact on the initial language release. We
also acknowledge the efforts of the entire DAML
Joint Committee,in particular the editors of
DAML+OIL’s current release:Frank van
Harmelen,Ian Horrocks,and Peter Patel-
Schneider,who,among other things,updated the
original DAML-ONT documents to reflect
1.R.J. Brachman et al.,“Living with Classic:
When and How to Use a KL-ONE-like Lan-
guage,” Principles of Semantic Networks:
Explorations in the Representation of Knowl-
edge,John Sowa,ed.,Morgan Kaufmann,San
Francisco,1991,pp. 401–456.
2.D.L. McGuinness et al.,“DAML-ONT:An
Ontology Language for the Semantic Web,”
The Semantic Web,D. Fensel,J. et al.,eds.,
to be published by MIT Press,Cambridge,
Mass.,2002; www.daml.org/2000/10/daml-
3.S. Bechhofer et al.,“An Informal Description
of OIL-Core and Standard OIL:A Layered
Proposal for DAML-O,” Nov. 2002,www.
4 F. Baader et al.,eds.,The Description Logic
Handbook:Theory,Implementation and
Applications,Cambridge Univ. Press,Cam-
5.I. Horrocks et al.,Some Notes on the Differ-
ences between DAML+OIL and DAML+
ONT,Dec. 2000,www.daml.org/2000/12/
6.D. Connolly et al.,eds,Annotated DAML
Ontology Markup,World Wide Web Consor-
tium,Note 18,Dec. 2001,www.w3.org/TR/
7. D. McGuinness et al.,“Classic Knowledge
Representation System Tutorial,’’ Artificial
Intelligence Principles Research Dept.,AT&T
Labs Research,1994; www.bell-labs.com/
8.F. van Harmelen et al.,“A Model-Theoretic
Semantics for DAML+OIL (March 2001),”
W3C Note 18,World Wide Web Consortium,
Dec. 2001; www.w3.org/TR/2001/NOTE-
9.O. Lassila and R. Swick,Resource Descrip-
tion Framework (RDF) Model and Syntax
Specification,W3C Recommendation,World
Wide Web Consortium,1999; www.w3.org/
10.R. Fikes and D.L. McGuinness,An Axiomatic
Semantics for RDF,RDF-Schema,and DAML-
ONT,tech. report,Knowledge Systems Lab-
oratory,Stanford Univ.,Stanford,Calif.,Dec.
2000; www.ksl.stanford.edu/people/dlm/
11.D. Connolly et al.,eds.,DAML+OIL (March
2001) Reference Description,W3C Note 18,
World Wide Web Consortium,Dec. 2001;
For more information on this or any other com-
puting topic, please visit our Digital Library at
computer.org/intelligent IEEE INTELLIGENT SYSTEMS
T h e S e m a n t i c W e b
T h e A u t h o r s
Deborah L. McGuinness
is associate director and a senior research scien-
tist at the Knowledge Systems Laboratory of Stanford University. Her main
research areas include ontologies,description logics,reasoning systems,
environments for building and maintaining information,knowledge-enhanced
search,configuration,and intelligent commerce applications. She also runs
a consulting business dealing with ontologies and artificial intelligence for
business applications and serves on advisory boards for the American Asso-
ciation of Artificial Intelligence,the Semantic Web Science Foundation,
Knowledge Representation and Reasoning Inc.,Network Inference,Applied
Semantics,and Sandpiper Software. She received a PhD from Rutgers University in reasoning sys-
tems. Contact her at the Knowledge Systems Laboratory,Stanford Univ.,Stanford,CA 94305;
dlm@ksl.stanford.edu; www.ksl.stanford.edu/people/dlm.
Richard Fikes
is a professor of computer science at Stanford University and
the director of Stanford’s Knowledge Systems Laboratory,where he leads
projects focused on developing large-scale distributed repositories of com-
puter-interpretable knowledge,collaborative development of multiuse ontolo-
gies,enabling technology for the Semantic Web,and reasoning methods
applicable to large-scale knowledge bases. He is co-developer of the STRIPS
automatic planning system,the Knowledge Interchange Format,the Ontolin-
gua language and development environment,the Open Knowledge Base Con-
nectivity API for knowledge servers,and IntelliCorp’s KEE system. Contact
him at the Computer Science Dept.,Gates Bldg. 2A,Rm. 246,Stanford Univ.,Stanford,CA 94305;
James Hendler
is a professor of computer science at the University of Mary-
land and the Director of Semantic Web and Agent Technologies at the Mary-
land Information and Network Dynamics Laboratory. He received his PhD
in artificial intelligence from Brown University. He is a fellow of the Amer-
ican Association for Artificial Intelligence,a member of the US Air Force
Science Advisory Board,and the former Chief Scientist for Information Sys-
tems at DARPA. Contact him at the Dept. of Computer Science,Univ. of
Maryland,College Park,MD 20742; hendler@cs.umd.edu; www.cs.umd.
Lynn Andrea Stein
is a professor of computer science and engineering and
a founding faculty member of the Franklin W. Olin College of Engineering.
Her research interests include a broad subset of artificial intelligence and
computer science,including logic,software agents,cognitive robotics,object-
oriented programming,and computer science education. She received a PhD
from Brown University and an AB from Harvard and Radcliffe Colleges. She
is fellow of the KISS Institute for Practical Robotics. Contact her at the
Franklin W. Olin College of Eng.,1735 Great Plain Ave.,Needham,MA
02492; las@olin.edu.