Status: initial draft, for testing and evaluation.
Feedback to www-rdf-logic,
please.
Lynn Andrea Stein, Dan Connolly, and Deborah McGuinness, eds.
$Revision: 2.0 $ of $Date: 2000/10/14 13:40:07 $ change history
This is an annotated walk through an example DAML Ontology. The example ontology demonstrates each of the features in DAML-ONT[DAML-ONT], an initial specification for DAML Ontologies.
Superscripted text refers to notes at the end of this document. The original example ontology is available separately.
DAML builds on existing Web technologies like Extensible Markup Language[XML] and Uniform Resource Identifiers[URI]. The references and suggested reading section cites introductory materials as well as official specifications for these technolgoies.
DAML-ONT, as of this draft, is written in RDF[RDF], i.e., DAML-ONT markup is a specific kind of RDF markup. RDF, in turn, is written in XML, using XML Namespaces[XMLNS], and URIs. If you are unfamiliar with RDF, the minimalist survival guide to RDF below may help get you started.
Thus, our example begins with an RDF start tag including three namespace declarations:
<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#" >
So 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.xmlns:rdf
The second declaration says that in this document, unprefixed element names
should be understood as referring to things drawn from the namespace called
http://www.daml.org/2000/10/daml-ont#. This is a convetional
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 documentunprefixedAttrs.
If you look at the bottom of this document, you'll see the matching closing tag, </rdf:RDF>.
The first thing we do inside this RDF is to assert that this is an ontology.
<Ontology about="">
This assertion is formulaic; the about attribute will typically be empty, indicating that the subject of this assertion is this document.Same-document reference
Then we give a couple properties of this ontology for documentation purposes:
<versionInfo>$Id: daml-ex.daml,v 1.2 2000/10/07 03:21:17 connolly Exp $</versionInfo>
<comment>An example ontology</comment>
followed by...
<imports resource="http://www.daml.org/2000/10/daml-ont"/>
Inside the Ontology element, we list any imported ontologies (using imports properties). This particular ontology depends only on the standard DAML ontology (used in the namespace definitions above).
Note that this (imports) tag is an empty element; the same tag starts and ends the element.
</Ontology>
Now, we begin our ontology definitions. First, we define a kind of thing called an animal. To do this, we use a Class tag. Class\
<Class ID="Animal">
This asserts that there is a Class known as Animal. It doesn't say anything else about what an animal is, etc. It is also not (necessarily) the sole source of information about Animals; we will see below how we can add to a definition made elsewhere.
However, by saying that its ID is Animal, we make it possible for others to
refer to the definition of Animal we're giving here. (This is done using the
uri of the containing page followed by #Animal.)
<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>
There are two types of animals, 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. SubClassOf
<Class ID="Female"> <subClassOf resource="#Animal"/> <disjointFrom resource="#Male"/> </Class>
Some animals are Female, too, but nothing can be both Male and Female (in this ontology) because these two classes are disjoint (using the disjointFrom tag):
Next, we define a property. A property -- or binary relation -- connects two items. In this case, we're defining the parent relation. 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.)
<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. It says that each thing-that-has-a-parent has two of them.
<domain resource="#Animal"/>
This element also describes the Property whose ID is parent. It says that the domain [Footnote: rdfs:domain] of the parent relation is Animals. That is, we're defining parent as a thing that an animal has.
We do this by asserting that there's a thing which is a domain -- a description of what kinds of things you can talk about the parents of -- and saying that the domain of this thing (the Property with ID parent) is the resource known as #Animal. What is the resource attribute? It is a reference to something. (Note: ID creates a reference-able description; resource refers to such a description.)
Each of these names -- Person, Man, and Woman -- refers to names in this document, since each reference begins with a #.
</Property>
That's all we have to say about this Property (whose ID = parent).
Now we'll define a Class with some attributes.
<Class ID="Person">
This element describes a kind of thing called a Person, and is referenceable as such.
<subClassOf resource="#Animal"/>
A Person's a kind of Animal (see definition of Animal, above).
The next few lines describe a domain-specific range restriction. To whit, 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 cliche, 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.
</Class>
That's the end of the Person class.
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. subProperty In addition, range is used to ensure that x's father must be a Man, and that x has only one father.
<Property ID="father"> <subProperty resource="#parent"/> <range resource="#Man"/> <cardinality>1</cardinality> </Property>
Mother is defined similarly 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>
See also UnambiguousProperty, a property whose object uniquely identifies its subject.
Sometimes, we like to refer to mothers using the synonym mom. The tag equivalentTo allows us to establish this synonymy:
<Property ID="mom"> <equivalentTo resource="#mother"/> </Property>
If x's parent is y, then y is x's child. This is defined using the inverseOf tag.
<Property ID="child"> <inverseOf resource="#parent"/> </Property>
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 specifiying it. A person may have zero or one job, no more:
<Property ID="occupation"> <maxCardinality>1</maxCardinality> </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 which 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's left when you consider everything except Persons).
A Man is a kind of Male Person
<Class ID="Man"> <subClassOf resource="#Person"/> <subClassOf resource="#Male"/> </Class>
...and a Woman's a Female Person.
<Class ID="Woman"> <subClassOf resource="#Person"/> <subClassOf resource="#Female"/> </Class>
Here is an example of further specifying a previously defined element by using the about attribute. These assertions about the thing described above with ID Person have no more and no less authority than the assetions made within the <Class ID="Person"> element. (Of course, if the two assertions were in different documents, had different authors, etc., they might have different authority.)
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.RDF extension
<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>
We can also define individuals, e.g., Adam:
<Person ID="Adam"> <label>Adam</label> <comment>Adam is a person.</comment> </Person>
A Person has a height, which is a Height. (height is a Property, or relation; Height is a Class, or kind of thing.)
<Property ID="height"> <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".RDF extension
<Class ID="Height"> <oneOf parseType="daml:collection"> <Height ID="short"/> <Height ID="medium"/> <Height ID="tall"/> </oneOf> </Class>
Finally, TallMan is the Class defined by intersecting TallThing and Man. The intersectionOf element also uses parsetype="daml:collection".RDF extension
<Class ID="TallMan"> <intersectionOf parseType="daml:collection"> <Class about="#TallThing"/> <Class about="#Man"/> </intersectionOf> </Class>
Finally, we end the rdf:RDF element.
</rdf:RDF>
This appendix is intended for those unfamiliar with RDF. It contains only enough information to enable you to read the annotated DAML markup example, and is not intended as a complete introduction to RDF, XML, or any other of the technologies on which DAML is based. See the suggested readings below for more information.
RDF is built on XML, which makes use of tags to structure information. Here are some example tags:
<aTag>...</aTag> <anEmptyTag/> <anotherTag with="an attribute">...</anoterTag> <aTag>with <anotherTag/> inside it</aTag> <tags>and<moreTags>and<moreTags>and...</moreTags></moreTags></tags>
The first thing after the open angle bracket is the tag name. The whole tag is often referred to by this name. So
<Class ID="Animal">
is a Class tag.
A tag ends with a closing angle bracket.
Some tags are start tags, and have matching end tags. The end tag has the same tag name as the opening tag, but begins with </ rather than simply <. For example,
<Class ID="Animal">
would be closed by the matching end tag
</Class>
From an opening tag to its matching closing tag is an element. Other tags can be embedded inside the element, but all such embedded elements must be closed inside the enclosing element. So <rdf:RDF> would begin an element that runs until an </rdf:RDF>. In this case, anything between the <rdf:RDF> and the matching </rdf:RDF> would be enclosed in the scope of this element.
An alternate way to specify an element that has nothing between its opening and its closing is to use a single tag with a slash immediately before the closing angle-bracket. Thus, the self-closing tag
<Class ID="Animal"/>
is the same as
<Class ID="Animal"></Class>
with nothing inside it.
An opening tag (or a self-closing tag) may contain things other than the tag name. These things after the tag name are attributes. Each attribute has a name, an equal sign, and an attribute value (generally enclosed in double quotes). So, for example, in the Class tag above,
ID="Animal"
is the attribute,
ID
is the attribute name, and
"Animal"
is the attribute value. Attributes are read as properties of the element in which they appear.
An RDF document is a collection of assertions in subject verb object (SVO) form. Within the obligatory RDF declaration (typically a tag that begins something like <rdf:RDF ...), each topmost element is the subject of a sentence. The next level of enclosed elements represent verb/object pairs for this sentence:
<Class ID="Male"> <subClassOf resource="#Animal"/> </Class>
Male is a subclass of Animal.
<Class ID="Female"> <subClassOf resource="#Animal"/> <disjointFrom resource="#Male"/> </Class>
Female is a subclass of Animal AND Female is disjoint from Male. The single subject -- Female -- is used to begin each of the verb-object assertions
<subClassOf resource="#Animal"/>
and
<disjointFrom resource="#Male"/>
A few attributes here require explanation.
ID creates a referenceable name, corresponding to the attribute value. So, for example, ID="Male" means that you can refer to Male and mean the thing described by the Class element above. Similarly, Female is a referenceable name.
The resource attribute, then, is simply a reference to such a name. In
<disjointFrom resource="#Male"/>
the resource attribute is used to indicate that the object of the assertion "Female is disjoint from" is the thing identified with the name Male. Note the prepended # to refer to the name. This indicates a reference to a name within the same containing document, i.e., a local name. It is also possible (e.g., by prepending a url before the #) to refer to a name defined elsewhere.
In the above example, each verb tag is self-closing. It is also possible to embed elements inside these verb elements, making objects which are themselves the subjects of subordinate clauses. This causes an alternation of subject verb subject verb ... sometimes called RDF striped syntax.
This draft draws on the work of many of the researchers in the DAML project, and from discussion with and review by Jim Hendler, Tim Berners-Lee, Ralph R. Swick, Deborah McGuinness, Pat Hayes, Drew McDermott, Stefan Decker, Richard Fikes, Frank van Harmelen, and Ian Horrocks.
also: example ontology
background: RDF: Resource Description Framework at W3C