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
“ harry.potter@hogwarts.net”. 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-