supreme genus

Substance

differentiae

material

subordinate genera

body

differentiae

animate

inanimate

subordinate differentiae genera

living

mineral

sensitive

insensitive

proximate genera

Animal

Plant

differentiae

rational

irrational

species

Human

beast

individual

Socrates

Plato

HarryPotter hasPet Hedwig . variables in first-order logic. where HarryPotter is the subject, A set of triples is called an RDF graph hasPet is the predicate, and Hed- (see Figure 1). In order to facilitate the wig is the object. The subject of a sharing and exchanging of graphs on triple is either an IRI or a blank node the Web, the RDF specification in- (an unlabeled node), while the ob- cludes an XML serialization. In RDF/ ject is an IRI, a blank node, or a lit- XML thetriplescanbe writtenas eral value (such as a string or integer). <rdf:Description

For example, we could use the triple: rdf:about=”#HarryPotter”> HarryPotter hasemail <hasPet

“ [e-mail]”. rdf:resource=”#Hedwig”/>
to capture information about Harry’s <hasEmail>harry.potter@
email address. The predicate of a triple hogwarts.net
is always an IRI called a “property.” IRIs </hasEmail>
are treated as names that identify par- </rdf:Description>
ticular resources. Blank nodes also de- where #HarryPotter and #Hedwig
note resources, but the exact resource are fragment identifiers.
being identified is not specified, behav- The RDF specification also extends
ing instead like existentially quantified the capabilities of the language by giv-
ing additional meaning to certain re-
sources. One of the most important is
rdf:type, a special property that cap-
tures the class-instance relationship;
where rdf is an abbreviation (called
a “namespace prefix”) for the string
www.w3.org/1999/02/22-rdf-syntax-ns#.
For example, we could use the triple:
immaterial HarryPotter rdf:type Wizard .
to represent the fact that Harry is an in-
stance of Wizard.
RDF provides a flexible mechanism
Spirit for adding structured annotations but
does little to address the problem of
understanding the meaning, or se-
mantics, of the terms in annotations.
One possible solution would be to fix
a set of terms to be used in annota-
tions and agree on their meaning. This
works well in constrained settings like
annotating documents; the Dublin
Core Metadata Initiative (dublincore.
org/schemas/) defines just such a set
of terms, including, for example, the
properties dc:title, dc:creator,
dc:subject, and dc:publisher.
However, this approach is limited with
respect to flexibility and extensibility;
only a fixed number of terms is defined,
and extending the set typically requires
a lengthy process in order to agree on
which terms to introduce, as well as on
their intended semantics. It may also
be impractical to impose a single set of
terms on all information providers.
An alternative approach is to agree
on a language that can be used to de-
fine the meaning of new terms (such
Aristotle etc.
as by combining and/or restricting ex-
isting ones). Such a language should
preferably be relatively simple and pre-