Copyright © 2003 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.
The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web. deleted text: It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, copyright and licensing information about a Web document, or the availability schedule for some shared resource. However, by generalizing the concept of a "Web resource", RDF can also be used to represent information about things that can be <em> identified </em> on the Web, even when they can't be directly <em> retrieved </em> on the Web. RDF provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. </p> <p> This Primer is designed to provide the reader with the basic knowledge required to effectively use RDF. It introduces the basic concepts of RDF and describes its XML syntax. It describes how to define RDF vocabularies using the RDF Vocabulary Description Language, and gives an overview of some deployed RDF applications. It also describes the content and purpose of other RDF specification documents.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a W3C Last Call Working Draft of the RDF Core Working Group Last Call Working Draft and has been produced as part of the W3C Semantic Web Activity ( Activity Statement ).
In response to last call comments on the 23 January 2003 working draft of the Primer, the descriptions of RDF datatypes, containers, collections, and reification have been clarified, material on RDF vocabularies and XML literals has been added, and numerous other editorial changes have been made. Additional changes have been made since the publication of the 05 September 2003 Primer Working Draft . Both sets of changes are described in the Changes section .
This document is in the Last Call review period, which ends on 21 February 07 November 2003. This Last Call publication consolidates changes and editorial improvements undertaken in response to feedback received during the previous Last Call publication of the RDFCore specifications which began on 23 January 2003. A list of the Last Call issues addressed by the Working Group is also available. This document has been endorsed by the RDF Core Working Group.
This document deleted text: incorporates material developed by the Working Group designed to provide the reader with the basic knowledge required to effectively use RDF in their particular applications. </p> <p> This document is being released for review by W3C Members and other interested parties to encourage feedback and comments, especially with regard to how the changes made affect existing implementations and content.
In conformance with W3C policy requirements, known patent and IPR constraints associated with this Working Draft are detailed on the RDF Core Working Group Patent Disclosure page.
Comments on this document are invited and should be sent to the public mailing list www-rdf-comments@w3.org . An archive of comments is available at http://lists.w3.org/Archives/Public/www-rdf-comments/ .
This is Publication as a deleted text: public W3C Last Call Working Draft for review does not imply endorsement by the W3C Members and other interested parties. Membership. This deleted text: section describes the status of this document at the time of its publication. It is a draft document and may be updated, replaced, replaced or obsoleted by other documents at any time. It is inappropriate to deleted text: use W3C Working Drafts as reference material or to cite this document as other than "work work in progress". progress. A list of current W3C Recommendations and other technical documents can be found at <a href="/TR/"> http://www.w3.org/TR/ </a>. http://www.w3.org/TR/.
1.
Introduction
2.
Making
Statements
About
Resources
2.1
Basic
Concepts
2.2
The
RDF
Model
2.3
Structured
Property
Values
and
Blank
Nodes
2.4
Typed
Literals
2.5
Concepts
Summary
3.
An
XML
Syntax
for
RDF:
RDF/XML
3.1
Basic
Principles
3.2
Abbreviating
and
Organizing
RDF
URIrefs
3.3
RDF/XML
Summary
4.
Other
RDF
Capabilities
4.1
RDF
Containers
4.2
RDF
Collections
4.3
RDF
Reification
4.4
More
on
Structured
Values:
rdf:value
4.5
XML
Literals
5.
Defining
RDF
Vocabularies:
RDF
Schema
5.1
Defining
Classes
5.2
Defining
Properties
5.3
Interpreting
RDF
Schema
Declarations
5.4
Other
Schema
Information
5.5
Richer
Schema
Languages
6.
Some
RDF
Applications:
RDF
in
the
Field
6.1
Dublin
Core
Metadata
Initiative
6.2
PRISM
6.3
XPackage
6.4
RSS
1.0:
RDF
Site
Summary
6.5
CIM/XML
6.6
Gene
Ontology
Consortium
6.7
Describing
Device
Capabilities
and
User
Preferences
7.
Other
Parts
of
the
RDF
Specification
7.1
RDF
Semantics
7.2
Test
Cases
8.
References
8.1
Normative
References
8.2
Informational
References
9.
Acknowledgments
A.
More
on
Uniform
Resource
Identifiers
(URIs)
B.
More
on
the
Extensible
Markup
Language
(XML)
C.
Changes
C.1
Changes
Between
the
23
January
2003
and
05
September
2003
Working
Drafts
C.2
Changes
Since
the
05
September
2003
Working
Draft
The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, copyright and licensing information about a Web document, or the availability schedule for some shared resource. However, by generalizing the concept of a "Web resource", RDF can also be used to represent information about things that can be identified on the Web, even when they can't cannot be directly retrieved on the Web. Examples include information about items available from online on-line shopping facilities (e.g., information about specifications, prices, and availability), or the description of a Web user's preferences for information delivery.
RDF is intended for situations in which this information needs to be processed by applications, rather than being only displayed to people. RDF provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. The ability to exchange information between different applications means that the information may be made available to applications other than those for which it was originally created.
RDF
is
based
on
the
idea
of
identifying
things
using
Web
identifiers
(URIs),
(called
Uniform
Resource
Identifiers
,
or
URIs
),
and
describing
resources
in
terms
of
simple
properties
and
property
values.
This
enables
RDF
to
represent
simple
statements
about
resources
as
a
graph
of
nodes
and
arcs
representing
the
resources,
and
their
properties
and
values.
To
make
this
discussion
somewhat
more
concrete
as
soon
as
possible,
the
group
of
statements
"there
is
someone
a
Person
identified
by
http://www.w3.org/People/EM/contact#me
,
whose
name
is
Eric
Miller,
whose
email
address
is
em@w3.org,
and
whose
title
is
Dr."
could
be
represented
as
the
RDF
graph
in
Figure
1
:
Figure 1 illustrates that RDF uses URIs to identify:
http://www.w3.org/People/EM/contact#me
</tt>
http://www.w3.org/2000/10/swap/pim/contact#Person
</tt>
http://www.w3.org/2000/10/swap/pim/contact#mailbox
</tt>
mailto:em@w3.org
</tt>
as
the
value
of
the
mailbox
property
(RDF
also
uses
character
strings
such
as
"Eric
Miller"
Miller",
and
values
from
other
datatypes
such
as
integers
and
dates,
as
the
values
of
deleted text:
some
properties)
RDF also provides an XML-based syntax (called RDF/XML) RDF/XML ) for recording and exchanging these graphs. Example 1 is a small chunk of RDF in RDF/XML corresponding to the graph in Figure 1 :
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#">
<contact:Person rdf:about="http://www.w3.org/People/EM/contact#me">
<contact:fullName>Eric Miller</contact:fullName>
<contact:mailbox rdf:resource="mailto:em@w3.org"/>
<contact:personalTitle>Dr.</contact:personalTitle>
</contact:Person>
</rdf:RDF>
Note
that
this
RDF/XML
also
contains
URIs,
as
well
as
properties
like
<tt>
mailbox
</tt>
and
<tt>
fullName
</tt>
(in
an
abbreviated
form),
and
their
respective
values
<tt>
em@w3.org
</tt>,
,
and
<tt>
Eric
Miller
</tt>.
.
Like HTML, this RDF/XML is machine processable, and, using URIs, can link pieces of information across the Web. However, unlike conventional hypertext, RDF URIs can refer to any identifiable thing, including things that may not be directly retrievable on the Web (such as the person Eric Miller). The result is that in addition to describing such things as Web pages, we RDF can also describe cars, businesses, people, news events, etc. In addition, RDF properties themselves have URIs, to precisely identify the kind of relationship relationships that exists exist between the linked items.
The following documents contribute to the specification of RDF:
This Primer is intended to provide an introduction to RDF and describe some existing RDF applications, to help information system designers and application developers understand the features of RDF and how to use them. In particular, the Primer is intended to answer such questions as:
The Primer is a non-normative document, which means that it does not provide a definitive specification of RDF. The examples and other explanatory material in the Primer are provided to help you readers understand RDF, but they may not always provide definitive or fully-complete answers. In such cases, deleted text: you should refer to the relevant normative parts of the RDF specification. specification should be consulted. To help you do in doing this, we provide the Primer describes the roles these other documents play in the complete specification of RDF, and provides links pointing to the relevant parts of the normative specifications, at appropriate places in the discussion.
It should also be noted that these RDF documents update and clarify previously-published RDF specifications , the Resource Description Framework (RDF) Model and Syntax Specification [RDF-MS] and the Resource Description Framework (RDF) Schema Specification 1.0 [RDF-S] . As a result, there have been some changes in terminology, syntax, and concepts. This Primer reflects the newer set of RDF specifications given in the bulleted list of RDF documents cited above. Hence, readers familiar with the older specifications, and with earlier tutorial and introductory articles based on them, should be aware that there may be differences between the current specifications and those previous documents. The RDF Issue Tracking document [RDFISSUE] can be consulted for a list of issues raised concerning the previous RDF specifications, and their resolution in the current specifications.
RDF is intended to provide a simple way to make statements about Web resources, e.g., Web pages. In this section, we describe This section describes the basic ideas behind the way RDF provides these capabilities (the normative specification describing these concepts is RDF Concepts and Abstract Syntax [RDF-CONCEPTS] ).
Imagine that we want trying to state deleted text: the fact that someone named John Smith created a particular Web page. A straightforward way to state this in English would be in the form of a simple statement such as:
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
creator
</u>
whose
value
is
<u>
John
Smith
</u>
</tt>
We've underlined parts Parts of this statement are emphasized to illustrate that, in order to describe the properties of something, we there need to be ways to name, or identify, a number of things:
In this statement, deleted text: we've used the Web page's URL (Uniform Resource Locator) is used to identify it. In addition, deleted text: we've used the word "creator" is used to identify the property we want to talk about, property, and the two words "John Smith" to identify the thing (a person) we want to say that is the value of this property.
We could state other Other properties of this Web page could be described by writing additional English statements of the same general form, using the URL to identify the page, and words (or other expressions) to identify the properties and their values. For example, deleted text: to specify the date the page was created, and the language in which the page is written, deleted text: we could write be described using the additional statements:
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
creation-date
</u>
whose
value
is
<u>
August
16,
1999
</u>
</tt>
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
language
</u>
whose
value
is
<u>
English
</u>
</tt>
RDF is based on the idea that the things we want to describe being described have properties which have values, and that resources can be described by making statements, similar to those above, that specify those properties and values. RDF uses a particular terminology for talking about the various parts of statements. Specifically, the part that identifies the thing the statement is about (the Web page in this example) is called the subject . The part that identifies the property or characteristic of the subject that the statement specifies (creator, creation-date, or language in these examples) is called the predicate , and the part that identifies the value of that property is called the object . So, taking the English statement
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
creator
</u>
whose
value
is
<u>
John
Smith
</u>
</tt>
the RDF terms for the various parts of the statement are:
http://www.example.org/index.html
</tt>
However, while English is good for communicating between (English-speaking) humans, RDF is about making machine-processable statements. To make these kinds of statements suitable for processing by machines, deleted text: we need two things: things are needed:
Fortunately, the existing Web architecture provides both these necessary facilities.
As we've seen, illustrated earlier, the Web already provides one form of identifier, the Uniform Resource Locator (URL). We used a A URL was used in our the original example to identify the Web page that John Smith created. A URL is a character string that identifies a Web resource by representing its primary access mechanism (essentially, its network "location"). However, we would it is also like important to be able to record information about many things that, unlike Web pages, don't do not have network locations or URLs.
The Web provides a more general form of identifier for these purposes, called the Uniform Resource Identifier (URI). URLs are a particular kind of URI. All URIs share the property that different persons or organizations can independently create them, and use them to identify things. However, URIs are not limited to identifying things that have network locations, or use other computer access mechanisms. In fact, deleted text: we can create a URI can be created to refer to anything we want that needs to talk about, be referred to in a statement, including
Because
of
this
generality,
RDF
uses
URIs
as
the
basis
of
its
mechanism
for
identifying
the
subjects,
predicates,
and
objects
in
statements.
To
be
more
precise,
RDF
uses
URI
references
[URIS]
.
A
URI
reference
(or
URIref
)
is
a
URI,
together
with
an
optional
fragment
identifier
at
the
end.
For
example,
the
URI
reference
<tt>
http://www.example.org/index.html#section2
</tt>
consists
of
the
URI
<tt>
http://www.example.org/index.html
</tt>
and
(separated
by
the
"#"
character)
the
fragment
identifier
<tt>
Section2
</tt>.
.
RDF
defines
a
resource
as
anything
that
is
identifiable
by
a
URI
reference,
so
using
URIrefs
allows
RDF
to
describe
practically
anything,
and
to
state
relationships
between
such
things
as
well.
URIrefs
and
fragment
identifiers
are
discussed
further
in
Appendix
A
</a>
,
and
in
[RDF-CONCEPTS]
.
To
represent
RDF
statements
in
a
machine-processable
way,
RDF
uses
the
Extensible
Markup
Language
[XML]
.
XML
was
designed
to
allow
anyone
to
design
their
own
document
format
and
then
write
a
document
in
that
format.
RDF
defines
a
specific
XML
markup
language,
referred
to
as
RDF/XML
,
for
use
in
representing
RDF
information,
and
for
exchanging
it
between
machines.
An
example
of
RDF/XML
was
given
in
Section
1
.
That
example
(
Example
1
)
used
tags
such
as
<tt>
<contact:fullName>
</tt>
and
<tt>
<contact:personalTitle>
</tt>
to
delimit
the
text
content
<tt>
Eric
Miller
</tt>
and
<tt>
Dr.
</tt>,
,
respectively.
Such
tags
allow
programs
written
with
an
understanding
of
what
the
tags
mean
to
property
properly
interpret
that
content.
Appendix
B
provides
further
background
on
XML
in
general.
The
specific
RDF/XML
syntax
used
for
RDF
is
described
in
more
detail
in
Section
3
.
Now that we've Section 2.1 has introduced RDF's basic statement concepts, the idea of using URI references deleted text: for identifying things we want to talk about on identify the Web, things referred to in RDF statements, and RDF/XML as a machine-processable way of representing to represent RDF statements, we can describe statements. With that background, this section describes how RDF lets us use uses URIs to make statements about resources. In the introduction, we The introduction said that RDF was based on the idea of expressing simple statements about resources, where those statements are built using subjects, predicates, each statement consists of a subject, a predicate, and objects. an object. In RDF, we could represent our original the English statement:
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
creator
</u>
whose
value
is
<u>
John
Smith
</u>
</tt>
could be represented by an RDF statement having:
http://www.example.org/index.html
</tt>
http://purl.org/dc/elements/1.1/creator
</tt>
http://www.example.org/staffid/85740
</tt>
Note how deleted text: we have used URIrefs are used to identify not only the subject of the original statement, but also the predicate and object, instead of using the words "creator" and "John Smith", respectively. We'll discuss respectively (some of the effects of using URIrefs in this further way will be discussed later in this section. section).
RDF models statements as nodes and arcs in a graph. RDF's graph model is defined in [RDF-CONCEPTS] . In this notation, a statement is represented by:
So the RDF statement above would be represented by the graph shown in Figure 2 :
Groups of statements are represented by corresponding groups of nodes and arcs. So if we wanted So, to also represent reflect the additional English statements
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
creation-date
</u>
whose
value
is
<u>
August
16,
1999
</u>
</tt>
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
language
</u>
whose
value
is
<u>
English
</u>
</tt>
we could, by using suitable URIrefs to name in the properties "creation-date" and "language", use RDF graph, the graph shown in Figure 3 </a>: could be used (using suitable URIrefs to name the properties "creation-date" and "language"):
Figure 3 illustrates that deleted text: the objects of in RDF statements may be either deleted text: resources identified by URIrefs, or constant values (called literals ) represented by character strings, in order to represent certain kinds of property values. Literals may not be the used as subjects or predicates of in RDF statements. In drawing RDF graphs, nodes that are URIrefs are shown as ellipses, while nodes that are literals are shown as boxes. (The simple character string literals we will use for now used in these examples are called plain literals , to distinguish them from the typed literals we will introduce to be introduced in Section 2.4 . The various kinds of literals that can be used in RDF statements are defined in [RDF-CONCEPTS] .) In drawing RDF graphs, nodes that represent resources identified by URIrefs are shown as ellipses, while nodes that represent literals are shown as boxes (labeled by the literal itself). .
Sometimes it is not convenient to draw graphs when discussing them, so an alternative way of writing down the statements, called triples , is also used. In the triples notation, each statement in the graph is written as a simple triple of subject, predicate, and object node labels (either URIref or literal), object, in that order. The triples representing For example, the three statements shown in Figure 3 would be written in full the triples notation as:
<http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/creator> <http://www.example.org/staffid/85740> . <http://www.example.org/index.html> <http://www.example.org/terms/creation-date> "August 16, 1999" . <http://www.example.org/index.html> <http://www.example.org/terms/language> "English" .
Each
triple
corresponds
to
a
single
arc
in
the
graph,
complete
with
the
arc's
beginning
and
ending
nodes
(the
subject
and
object
of
the
statement).
Unlike
the
drawn
graph
(but
like
the
original
statements),
the
triples
notation
requires
that
a
node
be
separately
identified
for
each
statement
it
appears
in.
So,
for
example,
<tt>
http://www.example.org/index.html
</tt>
appears
three
times
(once
in
each
triple)
in
the
triples
representation
of
the
graph,
but
only
once
in
the
drawn
graph.
However,
the
triples
represent
exactly
the
same
information
as
the
drawn
graph,
and
this
is
a
key
point:
what
is
fundamental
to
RDF
is
the
graph
model
of
the
statements.
The
notation
used
to
represent
or
depict
the
graph
is
secondary.
The
full
triples
notation
requires
that
URI
references
be
written
out
completely,
in
angle
brackets,
which,
as
the
example
above
illustrates,
can
result
in
very
long
lines.
lines
on
a
page.
For
convenience,
we
will
use
the
Primer
uses
a
shorthand
way
of
writing
triples
in
the
rest
of
this
Primer,
and
(the
same
shorthand
is
also
used
in
other
RDF
specifications.
In
this
shorthand,
we
can
substitute
a
specifications).
This
shorthand
substitutes
an
XML
qualified
name
(or
QName
)
without
angle
brackets
as
an
abbreviation
of
for
a
full
URI
reference.
reference
(QNames
are
discussed
further
in
Appendix
B
).
A
QName
contains
a
prefix
that
has
been
assigned
to
a
namespace
URI,
followed
by
a
colon,
and
then
a
local
name
</em>
(QNames
are
discussed
further
in
<a href="#documents">
Appendix
B
</a>
).
.
The
full
URIref
is
formed
from
the
QName
by
appending
the
local
name
to
the
namespace
URI
assigned
to
the
prefix.
So,
for
example,
if
the
QName
prefix
<tt>
foo
</tt>
is
assigned
to
the
namespace
URI
<tt>
http://example.org/somewhere/
</tt>,
,
then
the
QName
<tt>
foo:bar
</tt>
is
shorthand
for
the
URIref
<tt>
http://example.org/somewhere/bar
</tt>.
We
.
Primer
examples
will
also
deleted text:
make
extensive
use
deleted text:
in
these
examples
of
several
"well-known"
QName
prefixes
(which
we
will
use
without
(without
explicitly
specifying
them
each
time),
defined
as
follows:
prefix
<tt>
rdf:
</tt>,
,
namespace
URI:
<tt>
http://www.w3.org/1999/02/22-rdf-syntax-ns#
</tt>
prefix
<tt>
rdfs:
</tt>,
,
namespace
URI:
<tt>
http://www.w3.org/2000/01/rdf-schema#
</tt>
prefix
<tt>
dc:
</tt>,
,
namespace
URI:
<tt>
http://purl.org/dc/elements/1.1/
</tt>
prefix
<tt>
daml:
</tt>,
owl:
,
namespace
URI:
<tt>
http://www.daml.org/2001/03/daml+oil#
</tt>
http://www.w3.org/2002/07/owl#
prefix
<tt>
ex:
</tt>,
,
namespace
URI:
<tt>
http://www.example.org/
</tt>
(or
<tt>
http://www.example.com/
</tt>
)
prefix
<tt>
xsd:
</tt>,
,
namespace
URI:
<tt>
http://www.w3.org/2001/XMLSchema#
</tt>
We
will
also
use
Obvious
variations
on
the
"example"
prefix
<tt>
ex:
</tt>
will
also
be
used
as
needed
in
the
examples,
deleted text:
where
this
will
not
cause
confusion,
for
example,
instance,
prefix
<tt>
exterms:
</tt>,
,
namespace
URI:
<tt>
http://www.example.org/terms/
</tt>
(for
terms
used
by
our
an
example
organization),
prefix
<tt>
exstaff:
</tt>,
,
namespace
URI:
<tt>
http://www.example.org/staffid/
</tt>
(for
our
the
example
organization's
staff
identifiers),
prefix
<tt>
ex2:
</tt>,
,
namespace
URI:
<tt>
http://www.domain2.example.org/
</tt>
(for
a
second
example
organization),
and
so
on.
Using our this new shorthand, deleted text: we can write the previous set of triples can be written as:
ex:index.html dc:creator exstaff:85740 . ex:index.html dc:creator exstaff:85740 . ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html exterms:language "English" . ex:index.html exterms:language "English" .
Since
RDF
uses
URIrefs
instead
of
words
to
name
things
in
statements,
RDF
refers
to
a
set
of
URIrefs
(particularly
a
set
intended
for
a
specific
purpose)
as
a
vocabulary
.
Often,
the
URIrefs
in
such
vocabularies
are
organized
so
that
they
can
be
represented
as
a
set
of
QNames
using
a
common
prefix.
That
is,
a
common
namespace
URIref
will
be
chosen
for
all
terms
in
a
vocabulary,
typically
a
URIref
under
the
control
of
whoever
is
defining
the
vocabulary.
URIrefs
that
are
contained
in
the
vocabulary
are
formed
by
appending
individual
local
names
to
the
end
of
the
common
URIref.
This
forms
a
set
of
URIrefs
with
a
common
prefix.
For
instance,
as
illustrated
by
the
previous
examples,
an
organization
such
as
example.com
might
define
a
vocabulary
consisting
of
URIrefs
starting
with
the
prefix
http://www.example.org/terms/
for
terms
it
uses
in
its
business,
such
as
"creation-date"
or
"product",
and
another
vocabulary
of
URIrefs
starting
with
http://www.example.org/staffid/
to
identify
its
employees.
RDF
uses
this
same
approach
to
define
its
own
vocabulary
of
terms
with
special
meanings
in
RDF.
The
examples
we've
URIrefs
in
this
RDF
vocabulary
all
begin
with
http://www.w3.org/1999/02/22-rdf-syntax-ns#
,
conventionally
associated
with
the
QName
prefix
rdf:
.
The
RDF
Vocabulary
Description
Language
(described
in
Section
5
)
defines
an
additional
set
of
terms
having
URIrefs
that
begin
with
http://www.w3.org/2000/01/rdf-schema#
,
conventionally
associated
with
the
QName
prefix
rdfs:
.
(Where
a
specific
QName
prefix
is
commonly
used
in
connection
with
a
given
set
of
terms
in
this
way,
the
QName
prefix
itself
is
sometimes
used
as
the
name
of
the
vocabulary.
For
example,
someone
might
refer
to
"the
rdfs:
vocabulary".)
Using common URI prefixes provides a convenient way to organize the URIrefs for a related set of terms. However, this is just a convention. The RDF model only recognizes full URIrefs; it does not "look inside" URIrefs or use any knowledge about their structure. In particular, RDF does not assume there is any relationship between URIrefs just because they have a common leading prefix (see Appendix A for further discussion). Moreover, there is nothing that says that URIrefs with different leading prefixes cannot be considered part of the same vocabulary. A particular organization, process, tool, etc. can define a vocabulary that is significant for it, using URIrefs from any number of other vocabularies as part of its vocabulary.
In
addition,
sometimes
an
organization
will
use
a
vocabulary's
namespace
URIref
as
the
URL
of
a
Web
resource
that
provides
further
information
about
that
vocabulary.
For
example,
as
noted
earlier,
the
QName
prefix
dc:
will
be
used
in
Primer
examples,
associated
with
the
namespace
URIref
http://purl.org/dc/elements/1.1/
.
In
fact,
this
refers
to
the
Dublin
Core
vocabulary
described
in
Section
6.1
.
Accessing
this
namespace
URIref
in
a
Web
browser
will
retrieve
additional
information
about
the
Dublin
Core
vocabulary
(specifically,
an
RDF
schema).
However,
this
is
also
just
a
convention.
RDF
does
not
assume
that
a
namespace
URI
identifies
a
retrievable
Web
resource
(see
Appendix
B
for
further
discussion).
In the rest of the Primer, the term vocabulary will be used when referring to a set of URIrefs defined for some specific purpose, such as the set of URIrefs defined by RDF for its own use, or the set of URIrefs defined by example.com to identify its employees. The term namespace will be used only when referring specifically to the syntactic concept of an XML namespace (or in describing the URI assigned to a prefix in a QName).
URIrefs
from
different
vocabularies
can
be
freely
mixed
in
RDF
graphs.
For
example,
the
graph
in
Figure
3
uses
URIrefs
from
the
exterms:
,
exstaff:
,
and
dc:
vocabularies.
Also,
RDF
imposes
no
restrictions
on
how
many
statements
using
a
given
URIref
as
predicate
can
appear
in
a
graph
to
describe
the
same
resource.
For
example,
if
the
resource
ex:index.html
had
been
created
by
the
cooperative
efforts
of
several
staff
members
in
addition
to
John
Smith,
example.org
might
have
written
the
statements:
ex:index.html dc:creator exstaff:85740 .
ex:index.html dc:creator exstaff:27354 .
ex:index.html dc:creator exstaff:00816 .
These
examples
of
RDF
statements
begin
to
illustrate
some
of
the
advantages
of
using
URIrefs
as
RDF's
basic
way
of
identifying
things.
For
instance,
in
the
first
statement,
instead
of
identifying
the
creator
of
the
Web
page
deleted text:
in
our
first
example
by
the
character
string
"John
Smith",
we've
he
has
been
assigned
deleted text:
him
a
URIref,
in
this
case
(using
a
URIref
based
on
his
employee
number)
<tt>
http://www.example.org/staffid/85740
</tt>
.
An
advantage
of
using
a
URIref
in
this
case
is
that
we
the
identification
of
the
statement's
subject
can
be
more
precise
in
our
identification.
precise.
That
is,
the
creator
of
the
page
isn't
is
not
the
character
string
"John
Smith",
or
any
one
of
the
thousands
of
people
named
John
Smith,
but
the
particular
John
Smith
associated
with
that
URIref
(whoever
created
the
URIref
defines
the
association).
Moreover,
since
we
have
there
is
a
URIref
for
the
creator
of
the
page,
it
to
refer
to
John
Smith,
he
is
a
full-fledged
resource,
and
deleted text:
we
can
record
additional
information
can
be
recorded
about
him,
such
as
his
name,
and
age,
simply
by
adding
additional
RDF
statements
with
John's
URIref
as
deleted text:
in
the
graph
shown
in
subject.
For
example,
Figure
4
</a>:
shows
some
additional
statements
giving
John's
name
and
age.
These
examples
also
illustrate
that
RDF
uses
URIrefs
as
predicates
in
RDF
statements.
That
is,
rather
than
using
character
strings
(or
words)
such
as
"creator"
or
"name"
to
identify
properties,
RDF
uses
URIrefs.
Using
URIrefs
to
identify
properties
is
important
for
a
number
of
reasons.
First,
it
allows
us
to
distinguish
distinguishes
the
properties
we
one
person
may
use
from
different
properties
someone
else
may
use
that
would
otherwise
be
identified
by
the
same
character
string.
For
instance,
in
our
example,
the
example
in
Figure
4
,
example.org
uses
"name"
to
mean
someone's
full
name
written
out
as
a
character
string
literal
(e.g.,
"John
Smith"),
but
someone
else
may
intend
"name"
to
mean
something
different
(e.g.,
the
name
of
a
variable
in
a
piece
of
program
text).
A
program
encountering
"name"
as
a
property
identifier
on
the
Web
wouldn't
(or
merging
data
from
multiple
sources)
would
not
necessarily
be
able
to
distinguish
these
uses.
However,
if
example.org
writes
<tt>
http://www.example.org/terms/name
</tt>
for
its
"name"
property,
and
the
other
person
writes
<tt>
http://www.domain2.example.org/genealogy/terms/name
</tt>
for
hers,
we
can
keep
straight
the
fact
it
is
clear
that
there
are
distinct
properties
involved
(even
if
a
program
cannot
automatically
determine
the
distinct
meanings).
Another
reason
why
it
is
important
to
use
Also,
using
URIrefs
to
identify
properties
is
that
it
allows
us
to
treat
RDF
enables
the
properties
to
be
treated
as
resources
themselves.
Since
properties
are
resources,
we
can
record
descriptive
additional
information
can
be
recorded
about
them
(e.g.,
the
English
description
of
what
example.org
means
by
"name"),
simply
by
adding
additional
RDF
statements
with
the
property's
URIref
as
the
subject.
Using URIrefs as subjects, predicates, and objects in RDF statements allows us to begin to develop supports the development and use of a shared vocabulary on the Web, since people can discover and begin using vocabularies already used by others to describe things, reflecting deleted text: (and creating) a shared understanding of the concepts we talk about. those concepts. For example, in the triple
ex:index.html dc:creator exstaff:85740 . ex:index.html dc:creator exstaff:85740 .
the
predicate
<tt>
dc:creator
</tt>,
,
when
fully
expanded
as
a
URIref,
is
an
unambiguous
reference
to
the
"creator"
attribute
in
the
Dublin
Core
metadata
attribute
set
(discussed
further
in
Section
6.1
),
a
widely-used
set
of
attributes
(properties)
for
describing
information
of
all
kinds.
The
writer
of
this
triple
is
effectively
saying
that
the
relationship
between
the
Web
page
(identified
by
<tt>
http://www.example.org/index.html
</tt>
)
and
the
creator
of
the
page
(a
distinct
person,
identified
by
<tt>
http://www.example.org/staffid/85740
</tt>
)
is
exactly
the
concept
identified
by
<tt>
http://purl.org/dc/elements/1.1/creator
</tt>
.
Moreover,
anyone
else,
.
Another
person
familiar
with
the
Dublin
Core
vocabulary,
or
any
program,
that
understands
<tt>
http://purl.org/dc/elements/1.1/creator
</tt>
who
finds
out
what
dc:creator
means
(say
by
looking
up
its
definition
on
the
Web)
will
know
deleted text:
exactly
what
is
meant
by
this
relationship.
In
addition,
based
on
this
understanding,
people
can
write
programs
to
behave
in
accordance
with
that
meaning
when
processing
triples
containing
the
predicate
dc:creator
.
Of
course,
this
depends
on
increasing
the
general
use
of
URIrefs
to
refer
to
things
instead
of
using
literals;
e.g.,
using
URIrefs
like
exstaff:85740
and
dc:creator
instead
of
character
string
literals
like
John
Smith
and
creator
.
Even
then,
RDF's
use
of
URIrefs
doesn't
does
not
solve
all
our
identification
problems
because,
for
example,
people
can
still
use
different
URIrefs
to
refer
to
the
same
thing.
However,
the
fact
that
these
different
URIrefs
are
used
in
the
commonly-accessible
"Web
space"
creates
the
opportunity
both
to
identify
equivalences
among
these
different
references,
and
to
migrate
toward
the
use
of
common
references.
In
addition,
it
is
important
to
distinguish
between
any
meaning
that
RDF
itself
associates
with
terms
(such
as
dc:creator
in
the
previous
example)
used
in
RDF
statements
and
additional,
externally-defined
meaning
that
people
(or
programs
written
by
those
people)
might
associate
with
those
terms.
As
a
language,
RDF
directly
defines
only
the
graph
syntax
of
subject,
predicate,
and
object
triples,
certain
meanings
associated
with
URIrefs
in
the
rdf:
vocabulary,
and
certain
other
concepts
to
be
described
later,
as
normatively
defined
in
[RDF-CONCEPTS]
and
[RDF-SEMANTICS]
.
However,
RDF
does
not
define
the
meanings
of
terms
from
other
vocabularies,
such
as
dc:creator
,
that
might
be
used
in
RDF
statements.
Specific
vocabularies
will
be
created,
with
specific
meanings
assigned
to
the
URIrefs
defined
in
them,
externally
to
RDF.
RDF
statements
using
URIrefs
from
these
vocabularies
may
convey
the
specific
meanings
associated
with
those
terms
to
people
familiar
with
these
vocabularies,
or
to
RDF
applications
written
to
process
these
vocabularies,
without
conveying
any
of
these
meanings
to
an
arbitrary
RDF
application.
For example, people can associate meaning with a triple such as
ex:index.html dc:creator exstaff:85740 .
based
on
the
meaning
they
associate
with
the
appearance
of
the
word
"creator"
as
part
of
the
URIref
dc:creator
,
or
based
on
their
understanding
of
the
specific
definition
of
dc:creator
in
the
Dublin
Core
vocabulary.
However,
as
far
as
an
arbitrary
RDF
application
is
concerned
the
triple
might
as
well
be
something
like
fy:joefy.iunm ed:dsfbups fytubgg:85740 .
as
far
as
any
built-in
meaning
is
concerned.
Similarly,
any
natural
language
text
describing
the
meaning
of
dc:creator
that
might
be
found
on
the
Web
provides
no
additional
meaning
that
such
a
program
can
directly
use.
Of
course,
URIrefs
from
a
particular
vocabulary
can
be
used
in
RDF
statements
even
though
a
given
application
may
not
be
able
to
associate
any
special
meanings
with
them.
For
example,
generic
RDF
software
would
recognize
that
the
above
expression
is
an
RDF
statement,
that
ed:dsfbups
is
the
predicate,
and
so
on.
It
will
simply
not
associate
with
the
triple
any
special
meaning
that
the
vocabulary
developer
might
have
associated
with
a
URIref
like
ed:dsfbups
.
Moreover,
based
on
their
understanding
of
a
given
vocabulary,
people
can
write
RDF
applications
to
behave
in
accordance
with
the
special
meanings
assigned
to
URIrefs
from
that
vocabulary,
even
though
that
meaning
will
not
be
accessible
to
RDF
applications
not
written
in
that
way.
The
result
of
all
this
is
that
RDF
provides
a
way
to
make
statements
that
applications
can
more
easily
process.
Now
an
application
can't
cannot
actually
"understand"
such
statements,
of
course,
but
as
noted
above,
any
more
than
a
database
system
"understands"
terms
like
"employee"
or
"salary"
in
processing
a
query
like
SELECT
NAME
FROM
EMPLOYEE
WHERE
SALARY
>
35000
.
However,
if
an
application
is
appropriately
written,
it
can
deal
with
them
RDF
statements
in
a
way
that
makes
it
seem
like
it
does.
does
understand
them,
just
as
a
database
system
and
its
applications
can
do
useful
work
in
processing
employee
and
payroll
information
without
understanding
"employee"
and
"payroll".
For
example,
a
user
could
search
the
Web
for
all
book
reviews
and
create
an
average
rating
for
each
book.
Then,
the
user
could
put
that
information
back
on
the
Web.
Another
web
Web
site
could
take
that
list
of
book
rating
averages
and
create
a
"Top
Ten
Highest
Rated
Books"
page.
Here,
the
availability
and
use
of
a
shared
vocabulary
about
ratings,
and
a
shared
group
of
URIrefs
identifying
the
books
they
apply
to,
allows
individuals
to
build
a
mutually-understood
and
increasingly-powerful
(as
additional
contributions
are
made)
"information
base"
about
books
on
the
Web.
The
same
principle
applies
to
the
vast
amounts
of
information
that
people
create
about
thousands
of
subjects
every
day
on
the
Web.
RDF statements are similar to a number of other formats for recording information, such as:
and information in these formats can be treated as RDF statements, allowing RDF to be used to integrate data from many sources.
Things
would
be
very
simple
if
the
only
types
of
information
deleted text:
we
had
to
record
be
recorded
about
things
were
obviously
in
the
form
of
the
simple
RDF
statements
deleted text:
we've
illustrated
so
far.
However,
most
real-world
data
involves
structures
that
are
more
complicated
than
that,
at
least
on
the
surface.
For
instance,
in
our
the
original
example,
deleted text:
we
recorded
the
date
the
Web
page
was
created
is
recorded
as
a
single
<tt>
exterms:creation-date
</tt>
property,
with
a
plain
literal
as
its
value.
However,
suppose
deleted text:
we
wanted
to
show,
as
the
value
of
the
<tt>
exterms:creation-date
</tt>
property,
property
needed
to
record
the
month,
day,
and
year
as
separate
pieces
of
information?
Or,
in
the
case
of
John
Smith's
personal
information,
suppose
we
wanted
to
record
his
address.
We
might
write
the
John's
address
was
being
described.
The
whole
address
could
be
written
out
as
a
plain
literal,
as
in
the
triple
exstaff:85740 exterms:address "1501 Grant Avenue, Bedford, Massachusetts 01730" . exstaff:85740 exterms:address "1501 Grant Avenue, Bedford, Massachusetts 01730" .
However, suppose deleted text: we wanted to record John's address needed to be recorded as a structure consisting of separate street, city, state, and Zip postal code values? How do we do would this be done in RDF?
We
can
represent
such
structured
Structured
information
like
this
is
represented
in
RDF
by
considering
the
aggregate
thing
deleted text:
we
want
to
talk
about
be
described
(like
John
Smith's
address)
as
a
resource,
and
then
making
statements
about
that
new
resource.
So,
in
the
RDF
graph,
in
order
to
break
up
John
Smith's
address
into
its
component
parts,
deleted text:
we
create
a
new
node
is
created
to
represent
the
concept
of
John
Smith's
address,
and
assign
that
concept
with
a
new
URIref
to
identify
it,
say
<tt>
http://www.example.org/addressid/85740
</tt>
(which
we
will
abbreviate
(abbreviated
as
<tt>
exaddressid:85740
</tt>
).
deleted text:
We
then
write
RDF
statements
(create
additional
(additional
arcs
and
nodes)
can
then
be
written
with
that
node
as
the
subject,
to
represent
the
additional
information,
producing
the
graph
shown
in
Figure
5
:
or the triples:
exstaff:85740 exterms:address exaddressid:85740 . exstaff:85740 exterms:address exaddressid:85740 . exaddressid:85740 exterms:street "1501 Grant Avenue" . exaddressid:85740 exterms:street "1501 Grant Avenue" . exaddressid:85740 exterms:city "Bedford" . exaddressid:85740 exterms:city "Bedford" . exaddressid:85740 exterms:state "Massachusetts" . exaddressid:85740 exterms:state "Massachusetts" . exaddressid:85740 exterms:Zip "01730" . exaddressid:85740 exterms:postalCode "01730" .
Using
this
approach
allows
us
to
represent
This
way
of
representing
structured
information
in
RDF,
but
it
RDF
can
involve
generating
numerous
"intermediate"
URIrefs
such
as
exaddressid:85740
to
represent
aggregate
concepts
such
as
John's
address.
Such
concepts
may
never
need
to
be
referred
to
directly
from
outside
a
particular
graph,
and
hence
may
not
require
"universal"
identifiers.
In
addition,
in
the
drawing
of
the
graph
representing
the
group
of
statements
shown
in
Figure
5
,
deleted text:
we
didn't
really
need
the
URIref
deleted text:
we
assigned
to
identify
"John
Smith's
address",
address"
is
not
really
needed,
since
we
the
graph
could
just
as
easily
have
been
drawn
deleted text:
the
graph
as
in
Figure
6
:
In Figure 6 , which is a perfectly good RDF graph, we've used uses a node without a label URIref to stand for the concept of "John Smith's address". This deleted text: unlabeled node, or blank node </a>, serves its purpose in the drawing without needing a URIref, since the node itself provides the necessary connectivity between the various other parts of the graph. (Blank nodes were called anonymous resources in [RDF-MS] .) However, deleted text: we would need some form of explicit identifier for that node if we wanted is needed in order to represent this graph as triples. To see this, we can try trying to write the triples corresponding to what is shown in Figure 6 </a>. What we would get would be produce something like:
exstaff:85740 exterms:address ??? . exstaff:85740 exterms:address ??? . ??? exterms:street "1501 Grant Avenue" . ??? exterms:street "1501 Grant Avenue" . ??? exterms:city "Bedford" . ??? exterms:city "Bedford" . ??? exterms:state "Massachusetts" . ??? exterms:state "Massachusetts" . ??? exterms:Zip "01730" ??? exterms:postalCode "01730" .
where
???
stands
for
something
that
indicates
the
presence
of
the
blank
node.
Since
a
complex
graph
might
contain
more
than
one
blank
node,
we
would
there
also
need
needs
to
be
a
way
to
differentiate
between
these
multiple
different
blank
nodes
in
a
triples
representation
of
the
graph.
To
do
this,
we
As
a
result,
triples
use
blank
node
identifiers
,
having
the
form
<tt>
_:name
</tt>,
,
to
indicate
the
presence
of
blank
nodes
in
triples.
nodes.
For
instance,
in
this
example
we
might
use
the
a
blank
node
identifier
<tt>
_:johnaddress
</tt>
might
be
used
to
refer
to
the
blank
node,
in
which
case
the
resulting
triples
might
be:
exstaff:85740 exterms:address _:johnaddress . exstaff:85740 exterms:address _:johnaddress . _:johnaddress exterms:street "1501 Grant Avenue" . _:johnaddress exterms:street "1501 Grant Avenue" . _:johnaddress exterms:city "Bedford" . _:johnaddress exterms:city "Bedford" . _:johnaddress exterms:state "Massachusetts" . _:johnaddress exterms:state "Massachusetts" . _:johnaddress exterms:Zip "01730" . _:johnaddress exterms:postalCode "01730" .
In a triples representation of a graph, each distinct blank node in the graph is given a different blank node identifier. Unlike URIrefs and literals, blank node identifiers are not considered to be actual parts of the RDF graph (this can be seen by looking at the drawn graph in Figure 6 and noting that the blank node has no blank node identifier). Blank node identifiers are just a way of representing the blank nodes in a graph (and distinguishing one blank node from another) when the graph is written in triple form. Blank node identifiers also have significance only within the triples representing a single graph (two different graphs with the same number of blank nodes might independently use the same blank node identifiers to distinguish them, and it would be incorrect to assume that blank nodes from different graphs having the same blank node identifiers are the same). If it is expected that a node in a graph will need to be referenced from outside the graph, a URIref should be assigned to identify it.
At the The beginning of this section, we section noted that deleted text: we can represent aggregate structures, like John Smith's address, can be represented by considering the aggregate thing deleted text: we want to talk about be described as a separate resource, and then making statements about that new resource. This example illustrates an important aspect of RDF: RDF directly represents only binary relationships, e.g. the relationship between John Smith and the literal representing his address. When we try to represent Representing the relationship between John and the group of separate components of this address, we are address involves dealing with an n-ary (n-way) relationship (in this case, n=5) between John and the street, city, state, and zip postal code components. In order to represent such structures directly in RDF (e.g., considering the address as a group of street, city, state, and zip sub-components), we need to break postal code components), this n-way relationship must be broken up into a group of separate binary relationships. Blank nodes give us provide one way to do this. Each time we have an For each n-ary relationship, deleted text: we can choose one of the participants is chosen as the subject of the relationship (John in this case), and deleted text: create a blank node is created to represent the rest of the relationship (John's address in this case). We can then represent the The remaining participants in the relationship (such as the city in our this example) are then represented as separate properties of the new resource represented by the blank node.
Blank
nodes
also
give
us
provide
a
way
to
more
accurately
make
statements
about
resources
that
may
not
have
URIs,
but
that
are
described
in
terms
of
relationships
with
other
resources
that
do
have
URIs.
For
example,
when
making
statements
about
a
person,
say
Jane
Smith,
it
may
seem
natural
to
use
a
URI
based
on
that
person's
email
address
as
her
URI,
e.g.,
<tt>
mailto:jane@example.org
</tt>.
.
However,
this
approach
can
cause
problems.
For
example,
we
it
may
want
be
necessary
to
record
information
both
about
Jane's
mailbox
(e.g.,
the
server
it
is
on)
as
well
as
about
Jane
herself
(e.g.,
her
current
physical
address),
and
using
a
URIref
for
Jane
based
on
her
email
address
makes
it
difficult
to
know
which
thing
we're
talking
about.
whether
it
is
Jane
or
her
mailbox
that
is
being
described.
The
same
problem
exists
when
a
company's
Web
page
URL,
say
<tt>
http://www.example.com/
</tt>,
,
is
used
as
the
URI
of
the
company
itself.
Once
again,
we
it
may
need
be
necessary
to
record
information
about
the
Web
page
itself
(e.g.,
who
created
it
and
when)
as
well
as
about
the
company,
and
using
<tt>
http://www.example.com/
</tt>
as
an
identifier
for
both
makes
it
difficult
to
know
which
thing
we're
talking
about.
of
these
is
the
actual
subject.
The
fundamental
problem
is
that
using
Jane's
mailbox
as
a
stand-in
for
Jane
isn't
is
not
really
accurate:
Jane
and
her
mailbox
are
not
the
same
thing,
and
hence
their
identifiers
they
should
be
different.
identified
differently.
When
Jane
herself
doesn't
does
not
have
a
URI,
a
blank
node
gives
us
provides
a
more
accurate
way
of
modeling
this
situation.
deleted text:
We
can
represent
Jane
can
be
represented
by
a
blank
node,
and
give
the
that
blank
node
an
<tt>
used
as
the
subject
of
a
statement
with
exterms:mailbox
</tt>
as
the
property
having
and
the
URIref
<tt>
mailto:jane@example.org
</tt>
as
its
value.
We
can
also
assign
the
The
blank
node
could
also
be
described
with
an
<tt>
rdf:type
</tt>
property
with
having
a
value
of
<tt>
exterms:Person
</tt>
(we
will
discuss
types
(types
are
discussed
in
more
detail
in
the
following
sections),
an
<tt>
exterms:name
</tt>
property
with
having
a
value
of
<tt>
"Jane
Smith"
</tt>,
,
and
any
other
descriptive
information
we
that
might
want
to
provide,
be
useful,
as
shown
in
the
following
triples:
_:jane exterms:mailbox mailto:jane@example.org . _:jane exterms:mailbox <mailto:jane@example.org> . _:jane rdf:type exterms:Person . _:jane rdf:type exterms:Person . _:jane exterms:name "Jane Smith" . _:jane exterms:name "Jane Smith" . _:jane exterms:empID "23748" _:jane exterms:empID "23748" . _:jane exterms:age "26" . _:jane exterms:age "26" .
(Note
that
mailto:jane@example.org
is
written
within
angle
brackets
in
the
first
triple.
This
is
because
mailto:jane@example.org
is
a
full
URIref
in
the
mailto
URI
scheme,
rather
than
a
QName
abbreviation,
and
full
URIrefs
must
be
enclosed
in
angle
brackets
in
the
triples
notation.)
This
says,
accurately,
that
"there
is
a
resource
of
type
<tt>
exterms:Person
</tt>,
,
whose
electronic
mailbox
is
identified
by
<tt>
mailto:jane@example.org
</tt>,
,
whose
name
is
<tt>
Jane
Smith
</tt>,
,
etc."
That
is,
the
blank
node
can
be
read
as
"there
is
a
resource".
Statements
with
that
blank
node
as
subject
then
provide
information
about
the
characteristics
of
that
resource.
In
practice,
using
blank
nodes
instead
of
URIrefs
in
these
cases
doesn't
does
not
change
the
way
deleted text:
we
actually
handle
this
kind
of
information
is
handled
very
much.
For
example,
if
we
know
independently
it
is
known
that
an
email
address
uniquely
identifies
someone
at
example.org
(particularly
if
the
address
is
unlikely
to
be
reused),
deleted text:
we
can
still
use
that
fact
can
still
be
used
to
associate
information
about
that
person
from
multiple
sources,
even
though
the
email
address
is
not
the
person's
URI.
For
example,
In
this
case,
if
we
were
to
find
another
piece
of
some
RDF
is
found
on
the
web
Web
that
described
describes
a
book,
and
gives
the
author's
contact
information
as
<tt>
mailto:jane@example.org
</tt>,
we
,
it
might
reasonably
be
reasonable,
combining
this
new
information
with
the
previous
set
of
triples,
to
conclude
that
the
author's
name
is
Jane
Smith.
The
point
is
that
saying
something
like
"the
author
of
the
book
is
<tt>
mailto:jane@example.org
</tt>
"
is
typically
a
shorthand
for
"the
author
of
the
book
is
someone
whose
mailbox
is
<tt>
mailto:jane@example.org
</tt>
".
Using
a
blank
node
to
represent
this
"someone"
is
just
a
more
accurate
way
to
represent
the
real
world
situation.
(Incidentally,
some
RDF-based
schema
languages
allow
specifying
that
certain
properties
are
unique
identifiers.
identifiers
of
the
resources
they
describe.
This
is
discussed
further
in
Section
5.5
.)
Using
blank
nodes
in
this
way
can
also
help
avoid
the
use
of
literals
in
what
might
be
inappropriate
situations.
For
example,
in
describing
Jane's
book,
lacking
a
URIref
to
identify
the
author,
the
publisher
might
have
written
(using
the
publisher's
own
ex2terms:
vocabulary):
ex2terms:book78354 rdf:type ex2terms:Book .
ex2terms:book78354 ex2terms:author "Jane Smith" .
However, the author of the book is not really the character string "Jane Smith", but a person whose name is Jane Smith. The same information might be more accurately given by the publisher using a blank node, as:
ex2terms:book78354 rdf:type ex2terms:Book .
ex2terms:book78354 ex2terms:author _:author78354 .
_:author78354 rdf:type ex2terms:Person .
_:author78354 ex2terms:name "Jane Smith" .
This
essentially
says
"resource
ex2terms:book78354
is
of
type
ex2terms:Book
,
and
its
author
is
a
resource
of
type
ex2terms:Person
,
whose
name
is
Jane
Smith
."
Of
course,
in
this
particular
case
the
publisher
might
instead
have
assigned
its
own
URIrefs
to
its
authors
instead
of
using
blank
nodes
to
identify
them,
in
order
to
encourage
external
references
to
its
authors.
In
the
The
last
section,
we
section
described
how
to
handle
situations
in
which
deleted text:
we
needed
to
take
property
values
represented
by
plain
literals,
and
break
them
literals
had
to
be
broken
up
into
structured
values
that
identify
to
represent
the
individual
parts
of
those
property
values.
literals.
Using
this
approach,
instead
of,
say,
recording
the
date
a
Web
page
was
created
as
a
single
<tt>
exterms:creation-date
</tt>
property,
with
a
single
plain
literal
as
its
value,
deleted text:
we
could
represent
the
value
would
be
represented
as
a
structure
consisting
of
the
month,
day,
and
year
as
separate
pieces
of
information.
information,
using
separate
plain
literals
to
represent
the
corresponding
values.
However,
so
far,
we've
followed
the
practice
of
representing
any
all
constant
values
that
serve
as
objects
in
RDF
statements
have
been
represented
by
these
plain
(untyped)
literals,
even
when
we
the
intent
is
probably
deleted text:
intend
for
the
value
of
the
property
to
be
a
number
(e.g.,
the
value
of
a
<tt>
year
</tt>
or
<tt>
age
</tt>
property)
or
some
other
kind
of
more
specialized
value.
For
example,
deleted text:
in
Figure
4
deleted text:
we
illustrated
an
RDF
graph
recording
information
about
John
Smith.
In
that
graph,
we
That
graph
recorded
the
value
of
John
Smith's
<tt>
exterms:age
</tt>
property
as
the
plain
literal
"27",
as
shown
in
Figure
7
:
In
this
case,
our
the
hypothetical
organization
example.org
probably
intends
for
"27"
to
be
interpreted
as
a
number,
rather
than
as
the
string
consisting
of
the
character
"2"
followed
by
the
character
"7".
However,
"7"
(since
the
literal
represents
the
value
of
an
application
reading
"age"
property).
However,
there
is
no
information
in
Figure
7's
graph
that
explicitly
indicates
that
deleted text:
literal
"27"
would
only
know
should
be
interpreted
as
a
number.
Similarly,
example.org
also
probably
intends
for
"27"
to
do
be
interpreted
as
a
decimal
number,
i.e.,
the
value
twenty
seven
,
rather
than,
say,
as
an
octal
number,
i.e.,
the
value
twenty
three
.
However,
once
again
there
is
no
information
in
Figure
7's
graph
that
if
explicitly
indicates
this.
Specific
applications
might
be
written
with
the
application
was
understanding
that
they
should
interpret
values
of
the
exterms:age
property
as
decimal
numbers,
but
this
would
mean
that
proper
interpretation
of
this
RDF
would
depend
on
information
not
explicitly
given
provided
in
the
RDF
graph,
and
hence
on
information
that
the
literal
"27"
was
intended
would
not
necessarily
be
available
to
represent
a
number,
and
knew
which
number
the
literal
"27"
was
supposed
other
applications
that
might
need
to
represent.
interpret
this
RDF.
The
common
practice
in
programming
languages
or
database
systems
is
to
provide
this
kind
of
additional
information
about
how
to
interpret
a
literal
by
associating
a
datatype
with
the
literal,
in
this
case,
a
datatype
like
<tt>
decimal
</tt>
or
<tt>
integer
</tt>.
.
An
application
that
understands
the
datatype
then
knows,
for
example,
whether
the
literal
"10"
is
intended
to
represent
the
number
ten
,
the
number
two
,
or
the
string
consisting
of
the
character
"1"
followed
by
the
character
"0",
depending
on
whether
the
specified
datatype
is
<tt>
integer
</tt>,
<tt>
,
binary
</tt>,
,
or
<tt>
string
</tt>.
.
In
RDF,
typed
literals
are
used
to
provide
this
kind
of
information.
Using An RDF typed literal is formed by pairing a string with a URIref that identifies a particular datatype. This results in a single literal node in the RDF graph with the pair as the literal. The value represented by the typed literal is the value that the specified datatype associates with the specified string. For example, using a typed literal, deleted text: we could describe John Smith's age could be described as being the integer number 27 using the triple:
<http://www.example.org/staffid/85740> <http://www.example.org/terms/age> "27"^^<http://www.w3.org/2001/XMLSchema#integer> .
or, using our the QName simplification for writing long URIs:
exstaff:85740 exterms:age "27"^^xsd:integer .
or as shown in Figure 8 :
Similarly,
in
the
graph
shown
in
Figure
3
describing
information
about
a
Web
page,
deleted text:
we
recorded
the
value
of
the
page's
<tt>
exterms:creation-date
</tt>
property
was
written
as
the
plain
literal
"August
16,
1999".
However,
using
a
typed
literal,
deleted text:
we
could
describe
the
creation
date
of
the
Web
page
could
be
explicitly
described
as
being
the
date
August
16,
1999
,
using
the
triple:
ex:index.html exterms:creation-date "1999-08-16"^^xsd:date .
or as shown in Figure 9 :
deleted text:
As
these
examples
illustrate,
an
RDF
typed
literal
is
formed
by
explicitly
pairing
a
URIref
identifying
a
particular
datatype
(in
these
examples,
the
datatypes
<tt>
integer
</tt>
and
<tt>
date
</tt>
from
<a href="http://www.w3.org/TR/xmlschema-2/">
XML
Schema
Part
2:
Datatypes
</a>
<a href="#ref-xmlschema2">
[XML-SCHEMA2]
</a>
)
with
a
literal
that
the
datatype
uses
to
represent
the
intended
value.
In
each
case,
this
results
in
a
single
node
in
the
RDF
graph
with
the
pair
as
its
label.
</p>
<p>
Unlike
typical
programming
languages
and
database
systems,
RDF
has
no
built-in
set
of
datatypes
of
its
own,
such
as
datatypes
for
integers,
reals,
strings,
or
dates.
Instead,
deleted text:
it
relies
on
datatypes
defined
elsewhere
that
can
be
identified
by
a
<a href="http://www.w3.org/TR/rdf-concepts/#dfn-datatype-URI">
datatype
URI
</a>.
RDF
typed
literals
simply
provide
a
way
to
explicitly
indicate,
for
a
given
literal,
what
datatype
should
be
used
to
interpret
it.
As
far
as
RDF
The
datatypes
used
in
typed
literals
are
defined
externally
to
RDF,
and
identified
by
their
datatype
URIs
.
(There
is
concerned,
you
can
write
any
pair
of
one
exception:
RDF
defines
a
built-in
datatype
with
the
URIref
and
literal
you
want
rdf:XMLLiteral
to
represent
XML
content
as
a
typed
literal.
literal
value.
This
datatype
is
defined
in
[RDF-CONCEPTS]
,
and
its
use
is
described
in
Section
4.5
.)
For
instance,
the
examples
in
Figure
8
and
Figure
9
use
the
datatypes
integer
and
date
from
the
XML
Schema
datatypes
defined
in
XML
Schema
Part
2:
Datatypes
[XML-SCHEMA2]
.
An
advantage
of
this
approach
is
that
it
gives
RDF
the
flexibility
to
directly
represent
information
coming
from
different
sources
without
the
need
to
perform
type
conversions
between
these
sources
and
a
native
set
of
RDF
datatypes.
(Type
conversions
would
still
be
required
when
moving
information
between
systems
with
having
different
datatype
systems,
sets
of
datatypes,
but
RDF
would
impose
no
extra
conversions
into
and
out
of
a
native
set
of
RDF
types.)
datatypes.)
RDF datatype concepts are based on a conceptual framework from XML Schema datatypes [XML-SCHEMA2] , as described in RDF Concepts and Abstract Syntax [RDF-CONCEPTS] . This conceptual framework defines a datatype as consisting of:
xsd:date
,
this
set
of
values
is
a
set
of
dates.
xsd:date
defines
1999-08-16
as
being
a
legal
way
to
write
a
literal
of
this
type
(as
opposed,
say,
to
August
16,
1999
).
xsd:date
determines
that,
for
this
datatype,
the
string
1999-08-16
represents
the
date
August
16,
1999
.
The
lexical-to-value
mapping
is
a
factor
because
the
same
character
string
may
represent
different
values
for
different
datatypes.
Not
all
datatypes
are
suitable
for
use
in
RDF.
For
a
datatype
to
be
suitable
for
use
in
RDF,
it
must
conform
to
the
conceptual
framework
just
described.
This
basically
means
that,
given
a
character
string,
the
datatype
must
unambiguously
define
whether
or
not
the
string
is
in
its
lexical
space,
and
what
value
in
its
value
space
the
string
represents.
For
example,
the
basic
XML
Schema
datatypes
such
as
xsd:string
,
xsd:boolean
,
xsd:date
,
etc.
are
suitable
for
use
in
RDF.
However,
some
of
the
built-in
XML
Schema
datatypes
are
not
suitable
for
use
in
RDF.
For
example,
xsd:duration
does
not
have
a
well-defined
value
space,
and
xsd:QName
requires
an
enclosing
XML
document
context.
Lists
of
the
XML
Schema
datatypes
that
are
currently
considered
suitable
and
unsuitable
for
use
in
RDF
are
given
in
[RDF-SEMANTICS]
.
Since
the
value
that
a
given
typed
literal
denotes
is
defined
by
the
typed
literal's
datatype,
and,
with
the
exception
of
rdf:XMLLiteral
,
RDF
does
not
define
any
datatypes,
the
actual
interpretation
of
a
typed
literal
(determining
appearing
in
an
RDF
graph
(e.g.,
determining
the
value
it
denotes)
must
be
performed
by
an
RDF
processor
software
that
is
programmed
written
to
"understand"
correctly
process
not
only
RDF,
but
the
typed
literal's
datatype
as
well.
Effectively,
this
software
must
be
written
to
process
an
extended
language
that
datatype.
In
particular,
we've
used
includes
not
only
RDF,
but
also
the
datatype,
as
part
of
its
built-in
vocabulary.
This
raises
the
issue
of
which
datatypes
will
be
generally
available
in
RDF
software.
Generally,
the
XML
Schema
datatypes
that
are
listed
as
suitable
for
use
in
RDF
in
[RDF-SEMANTICS]
have
a
"first
among
equals"
status
in
RDF.
As
noted
already,
the
deleted text:
two
examples
we've
just
presented,
in
Figure
8
and
Figure
9
used
some
of
these
XML
Schema
datatypes,
and
the
Primer
will
be
using
XML
Schema
these
datatypes
in
most
of
our
its
other
examples
of
typed
literals
as
well
(for
one
thing,
XML
Schema
data
types
datatypes
already
have
assigned
URIrefs
we
that
can
use
be
used
to
refer
to
them,
specified
in
[XML-SCHEMA2]
).
These
XML
Schema
datatypes
deleted text:
have
a
"first
among
equals"
status
in
RDF.
They
are
treated
no
differently
than
any
other
datatype,
but
they
are
expected
to
be
the
most
widely
used,
and
therefore
the
most
likely
to
be
interoperable
among
different
software.
As
a
result,
it
is
expected
that
many
much
RDF
processors
software
will
also
be
programmed
written
to
recognize
process
these
datatypes.
However,
RDF
software
could
be
programmed
written
to
process
other
sets
of
datatypes
as
well.
well,
assuming
they
were
determined
to
be
suitable
for
use
with
RDF,
as
described
already.
In
general,
RDF
datatype
concepts
also
borrow
a
conceptual
framework
from
XML
Schema
software
may
be
called
on
to
process
RDF
data
that
contains
references
to
datatypes
<a href="#ref-xmlschema2">
[XML-SCHEMA2]
</a>
that
the
software
has
not
been
written
to
more
precisely
describe
datatype
requirements.
RDF's
use
of
this
framework
is
defined
process,
in
<a href="http://www.w3.org/TR/rdf-concepts/">
RDF
Concepts
and
Abstract
Syntax
</a>
<a href="#ref-rdf-concepts">
[RDF-CONCEPTS]
</a>.
</p>
<p>
The
flexibility
provided
by
RDF
typed
literals
comes
at
a
price.
which
case
there
are
some
things
the
software
will
not
be
able
to
do.
For
one
thing,
with
the
exception
of
rdf:XMLLiteral
,
RDF
itself
does
not
define
the
URIrefs
that
identify
datatypes.
As
a
result,
RDF
software,
unless
it
has
no
way
of
knowing
been
written
to
recognize
specific
URIrefs,
will
not
be
able
to
determine
whether
or
not
a
URIref
written
in
a
typed
literal
actually
identifies
a
datatype.
Moreover,
even
when
a
URIref
does
identify
a
datatype,
RDF
itself
does
not
define
the
validity
of
pairing
that
datatype
with
a
particular
literal.
This
validity
can
only
be
determined
by
software
built
written
to
understand
correctly
process
that
particular
datatype.
For example, you could write the typed literal in the triple:
exstaff:85740 exterms:age "pumpkin"^^xsd:integer .
or the graph shown in Figure 10 :
deleted text:
The
typed
literal
in
<a href="#figure10">
Figure
10
</a>
is
valid
RDF,
but
obviously
an
error
as
far
as
the
<tt>
xsd:integer
</tt>
datatype
is
concerned,
since
"pumpkin"
is
not
defined
as
being
deleted text:
a
legal
literal
for
<tt>
xsd:integer
</tt>.
</p>
<p>
In
general,
RDF
software
may
be
called
on
to
process
RDF
data
that
contains
datatypes
that
it
has
not
been
programmed
to
understand,
in
deleted text:
which
case
there
are
some
things
the
software
will
not
be
able
to
do.
This
includes
recognizing
whether
or
not
a
particular
string
represents
a
legal
value
for
a
particular
datatype.
In
this
case,
lexical
space
of
xsd:integer
.
RDF
software
not
built
written
to
understand
process
the
<tt>
xsd:integer
</tt>
datatype
would
not
be
able
to
recognize
that
"pumpkin"
is
not
this
error.
However, proper use of RDF typed literals provides more information about the intended interpretation of literal values, and hence makes RDF statements a valid <tt> xsd:integer </tt>. better means of information exchange among applications.
Taken as a whole, RDF is basically simple: nodes-and-arcs diagrams interpreted as statements about things identified by URIrefs. This section has presented an introduction to these concepts. As noted earlier, the normative (i.e., definitive) RDF specification describing these concepts is deleted text: the RDF Concepts and Abstract Syntax [RDF-CONCEPTS] , which should be consulted for further information. Together with The formal semantics (meaning) of these concepts is defined in the (normative) RDF Semantics [RDF-SEMANTICS] document, <a href="#ref-rdf-concepts"> [RDF-CONCEPTS] </a> provides the definition of the abstract syntax for RDF, together with its formal semantics (meaning). document.
However, in addition to the basic techniques for representing describing things using RDF statements in diagrams (or triples) we've seen discussed so far, it should be clear that we people or organizations also need a way deleted text: for people to define describe the vocabularies (terms) they intend to use in those statements, including: specifically, vocabularies for:
ex:Person
</tt>
)
ex:age
</tt>
and
<tt>
ex:creation-date
</tt>
),
and
ex:age
</tt>
property
should
always
be
an
<tt>
xsd:integer
</tt>
).
The basis for describing such vocabularies in RDF is the RDF Vocabulary Description Language 1.0: RDF Schema [RDF-VOCABULARY] , which will be described in Section 5 .
Additional background on the basic ideas underlying RDF, and its role in providing a general language for describing Web information, can be found in [WEBDATA] . RDF draws upon ideas from knowledge representation, artificial intelligence, and data management, including Conceptual Graphs, logic-based knowledge representation, frames, and relational databases. Some possible sources of background information on these subjects include [Sowa] [SOWA] , [CG] , [KIF] , [Hayes] [HAYES] , [Luger] [LUGER] , and [Gray] [GRAY] .
As deleted text: we described in Section 2, RDF's conceptual model is a graph. RDF provides an XML syntax for writing down and exchanging RDF graphs, called RDF/XML . Unlike triples, which are intended as a shorthand notation, RDF/XML is the normative syntax for writing RDF. RDF/XML is defined in the RDF/XML Syntax Specification [RDF-SYNTAX] . This section describes this RDF/XML syntax.
We can illustrate the The basic ideas behind the RDF/XML syntax can be illustrated using some of the examples deleted text: we've presented already. Suppose we want to represent one of our initial statements: Take as an example the English statement:
<tt>
<u>
http://www.example.org/index.html
</u>
has
a
<u>
creation-date
</u>
whose
value
is
<u>
August
16,
1999
</u>
</tt>
The
RDF
graph
for
this
single
statement,
after
assigning
a
URIref
to
the
<tt>
creation-date
</tt>
property,
is
shown
in
Figure
11
:
with a triple representation of:
ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html exterms:creation-date "August 16, 1999" .
(Note that a typed literal is not used for the date value in this example. Representing typed literals in RDF/XML will be described later in this section).
Example 2 shows the RDF/XML syntax corresponding to the graph in Figure 11 :
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 3. xmlns:exterms="http://www.example.org/terms/"> 4. <rdf:Description rdf:about="http://www.example.org/index.html"> 5. <exterms:creation-date>August 16, 1999</exterms:creation-date> 6. </rdf:Description> 7. </rdf:RDF>
(we have added line (Line numbers are added to use help in explaining the example).
This seems like a lot of overhead. We can It is easier to understand deleted text: better what is going on by considering each part of this XML in turn (a brief introduction to XML is provided in Appendix B ).
Line
1,
<tt>
<?xml
version="1.0"?>
</tt>,
,
is
the
XML
declaration,
declaration
,
which
indicates
that
the
following
content
is
XML,
and
what
version
of
XML
it
is.
Line
2
begins
an
<tt>
rdf:RDF
</tt>
element.
This
indicates
that
the
following
XML
content
(starting
here
and
ending
with
the
<tt>
</rdf:RDF>
</tt>
in
Line
line
7)
is
intended
to
represent
RDF.
Following
the
<tt>
rdf:RDF
</tt>
on
this
same
line
is
an
XML
namespace
declaration,
represented
as
an
<tt>
xmlns
</tt>
attribute
of
the
<tt>
rdf:RDF
</tt>
start-tag.
This
declaration
specifies
that
all
tags
in
this
content
prefixed
with
<tt>
rdf:
</tt>
are
part
of
the
namespace
identified
by
the
URIref
<tt>
http://www.w3.org/1999/02/22-rdf-syntax-ns#
</tt>.
This
namespace
is
.
URIrefs
beginning
with
the
source
string
http://www.w3.org/1999/02/22-rdf-syntax-ns#
are
used
for
deleted text:
the
RDF-specific
terms
used
in
RDF/XML.
from
the
RDF
vocabulary.
Line
3
specifies
another
XML
namespace
declaration,
this
time
for
the
prefix
<tt>
exterms:
</tt>.
.
This
is
expressed
as
another
<tt>
xmlns
</tt>
attribute
of
the
<tt>
rdf:RDF
</tt>
element,
and
specifies
that
the
namespace
URIref
<tt>
http://www.example.org/terms/
</tt>
is
to
be
associated
with
the
<tt>
exterms:
</tt>
prefix.
This
namespace
is
URIrefs
beginning
with
the
source
string
http://www.example.org/terms/
are
used
for
deleted text:
the
specific
terms
from
the
vocabulary
defined
by
our
the
example
organization,
example.org.
The
">"
at
the
end
of
line
3
indicates
the
end
of
the
<tt>
rdf:RDF
</tt>
start-tag.
Lines
1-3
are
general
"housekeeping"
necessary
to
indicate
that
we
are
defining
this
is
RDF/XML
content,
and
to
identify
the
sources
of
namespaces
being
used
within
the
terms
we
are
using.
RDF/XML
content.
Lines
4-6
provide
the
RDF/XML
for
the
specific
statement
we're
representing.
shown
in
Figure
11
.
An
obvious
way
to
talk
about
any
RDF
statement
is
to
say
it's
it
is
a
description
,
and
that
it's
it
is
about
the
subject
of
the
statement
(in
this
case,
about
http://www.example.org/index.html),
and
this
is
the
way
RDF/XML
represents
the
statement.
The
<tt>
rdf:Description
</tt>
start-tag
in
Line
line
4
indicates
that
we're
starting
the
start
of
a
description
of
a
resource,
and
goes
on
to
identify
the
resource
the
statement
is
about
(the
subject
of
the
statement)
using
the
<tt>
rdf:about
</tt>
attribute
to
specify
the
URIref
of
the
subject
resource.
Line
5
provides
a
property
element
,
with
the
QName
<tt>
<exterms:creation-date>
</tt>
exterms:creation-date
as
its
tag,
to
hold
represent
the
predicate
and
object
of
the
statement.
The
QName
exterms:creation-date
is
chosen
so
that
appending
the
local
name
creation-date
to
the
URIref
of
the
exterms:
prefix
(
http://www.example.org/terms/
)
gives
the
statement's
predicate
URIref
http://www.example.org/terms/creation-date
.
The
content
of
this
property
element
is
the
object
of
the
statement,
the
plain
literal
<tt>
August
19,
1999
</tt>
(the
value
of
the
creation-date
property
of
the
statement.
It
subject
resource).
The
property
element
is
nested
within
the
containing
<tt>
rdf:Description
</tt>
element,
indicating
that
this
property
applies
to
the
resource
specified
in
the
<tt>
rdf:about
</tt>
attribute
of
the
<tt>
rdf:Description
</tt>
element.
deleted text:
The
URIref
of
the
creation-date
property
corresponding
to
the
QName
<tt>
<exterms:creation-date>
</tt>
is
obtained
by
appending
the
name
<tt>
creation-date
</tt>
to
the
URIref
of
the
<tt>
exterms:
</tt>
prefix
(
<tt>
http://www.example.org/terms/
</tt>
),
giving
<tt>
http://www.example.org/terms/creation-date
</tt>.
Line
6
indicates
the
end
of
this
particular
<tt>
rdf:Description
</tt>
element.
Finally,
Line
7
indicates
the
end
of
the
<tt>
rdf:RDF
</tt>
element
started
on
Line
line
2.
Using
an
rdf:RDF
element
to
enclose
RDF/XML
content
is
optional
in
situations
where
the
XML
can
be
identified
as
RDF/XML
by
context.
This
is
discussed
further
in
[RDF-SYNTAX]
.
However,
it
does
not
hurt
to
provide
the
rdf:RDF
element
in
any
case,
and
Primer
examples
will
generally
(but
not
always)
provide
one.
Example 2 illustrates the basic ideas used by RDF/XML to encode an RDF graph as XML elements, attributes, element content, and attribute values. The URIref labels for properties and object nodes URIrefs of predicates (as well as some nodes) are written as XML QNames , consisting of a short prefix denoting a namespace URI, together with a local name denoting a namespace-qualified element or attribute, as described in Appendix B . The (namespace URIref, local name) pair are is chosen so that concatenating them forms the URIref of the original node. node or predicate. The URIrefs of subject nodes are written as XML attribute values. The values (URIrefs of object nodes may sometimes be written as attribute values as well). Literal nodes deleted text: labeled by literals (which are always object nodes) become element text content or attribute values. (All (Many of these options are described later in the Primer; all of these options are described in [RDF-SYNTAX] ).
We could represent an An RDF graph consisting of multiple statements can be represented in RDF/XML by using RDF/XML similar to Lines 4-6 in Example 2 to separately represent each statement. For example, deleted text: if we wanted to write the following two statements:
ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html exterms:language "English" . ex:index.html exterms:language "English" .
deleted text: we could write the RDF/XML in Example 3 </a>: could be used:
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 3. xmlns:exterms="http://www.example.org/terms/"> 4. <rdf:Description rdf:about="http://www.example.org/index.html"> 5. <exterms:creation-date>August 16, 1999</exterms:creation-date> 6. </rdf:Description> 7. <rdf:Description rdf:about="http://www.example.org/index.html"> 8. <exterms:language>English</exterms:language> 9. </rdf:Description> 10. </rdf:RDF>
Example
3
is
the
same
as
Example
2
,
with
the
addition
of
lines
7-9,
a
second
<tt>
rdf:Description
</tt>
element
to
represent
the
second
statement.
We
could
represent
an
An
arbitrary
number
of
additional
statements
could
be
written
in
the
same
way,
using
a
separate
<tt>
rdf:Description
</tt>
element
for
each
additional
statement.
As
Example
3
illustrates,
once
the
overhead
of
writing
the
XML
and
namespace
declarations
is
dealt
with,
writing
each
additional
RDF
statement
in
RDF/XML
is
both
straightforward
and
not
too
complicated.
The
RDF/XML
syntax
provides
a
number
of
abbreviations
to
make
common
uses
easier
to
write.
For
example,
it
is
typical
for
the
same
resource
to
be
described
with
several
properties
and
values
at
the
same
time,
as
in
Example
3
,
where
the
resource
<tt>
ex:index.html
</tt>
is
the
subject
of
several
statements.
To
handle
such
cases,
RDF/XML
allows
multiple
property
elements
representing
those
properties
to
be
nested
within
the
<tt>
rdf:Description
</tt>
element
that
identifies
the
subject
resource.
For
example,
deleted text:
if
we
wanted
to
represent
the
following
group
of
statements
about
http://www.example.org/index.html:
http://www.example.org/index.html
:
ex:index.html dc:creator exstaff:85740 . ex:index.html dc:creator exstaff:85740 . ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html exterms:language "English" . ex:index.html exterms:language "English" .
whose graph (the same as Figure 3 ) is shown in Figure 12 :
deleted text: we could write the RDF/XML deleted text: as shown in Example 4 </a>: could be written:
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 3. xmlns:dc="http://purl.org/dc/elements/1.1/" 4. xmlns:exterms="http://www.example.org/terms/"> 5. <rdf:Description rdf:about="http://www.example.org/index.html"> 6. <exterms:creation-date>August 16, 1999</exterms:creation-date> 7. <exterms:language>English</exterms:language> 8. <dc:creator rdf:resource="http://www.example.org/staffid/85740"/> 9. </rdf:Description> 10. </rdf:RDF>
Compared
with
the
previous
two
examples,
Example
4
adds
an
additional
namespace
declaration
(in
Line
line
3),
and
an
additional
<tt>
creator
</tt>
dc:creator
property
element
(in
Line
line
8).
In
addition,
deleted text:
we've
nested
the
property
elements
for
the
three
properties
whose
subject
is
<tt>
http://www.example.org/index.html
</tt>
are
nested
within
a
single
<tt>
rdf:Description
</tt>
element
identifying
that
subject,
rather
than
writing
a
separate
<tt>
rdf:Description
</tt>
element
for
each
statement.
Line
8
also
introduces
a
new
form
of
property
element.
(The
element
tag
also
uses
a
different
namespace
prefix,
the
new
namespace
prefix
<tt>
dc:
</tt>
we
defined
in
Line
line
3.)
The
<tt>
exterms:language
</tt>
element
in
Line
line
7
is
similar
to
the
<tt>
exterms:creation-date
</tt>
element
we
defined
used
in
Example
2
.
Both
these
elements
represent
properties
with
plain
literals
as
property
values,
and
such
elements
are
specified
written
by
enclosing
the
literal
within
start-
and
end-tags
corresponding
to
the
property
name.
However,
the
<tt>
dc:creator
</tt>
element
on
Line
line
8
represents
a
property
whose
value
is
another
resource
,
rather
than
a
literal.
If
deleted text:
we
had
written
the
URIref
of
this
resource
were
written
as
a
plain
literal
within
start-
and
end-tags
in
the
same
way
as
deleted text:
we
wrote
the
literal
values
of
the
other
elements,
we
this
would
be
saying
say
that
the
value
of
the
<tt>
dc:creator
</tt>
element
was
the
character
string
<tt>
http://www.example.org/staffid/85740
</tt>,
,
rather
than
the
resource
identified
by
that
literal
interpreted
as
a
URIref.
In
order
to
indicate
the
difference,
deleted text:
we've
written
the
<tt>
dc:creator
</tt>
element
is
written
using
what
XML
calls
an
empty-element
tag
(it
has
no
separate
end-tag),
and
deleted text:
defined
the
property
value
is
written
using
an
<tt>
rdf:resource
</tt>
attribute
within
that
empty
element.
The
<tt>
rdf:resource
</tt>
attribute
indicates
that
the
property
element's
value
is
another
resource,
identified
by
its
URIref.
Because
the
URIref
is
being
used
as
an
attribute
value
,
RDF/XML
requires
deleted text:
that
we
write
out
the
URIref,
URIref
to
be
written
out
(as
an
absolute
or
relative
URIref),
rather
than
abbreviating
it
as
a
QName,
QName
as
we've
was
done
in
writing
element
and
attribute
names
</em>.
(absolute
and
relative
URIrefs
are
discussed
in
Appendix
A
).
It is important to understand that the RDF/XML in deleted text: the Example 4 is an abbreviation . The RDF/XML in Example 5 , in which each statement is written separately, describes exactly the same RDF graph: graph (the graph of Figure 12 ):
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:exterms="http://www.example.org/terms/"> <rdf:Description rdf:about="http://www.example.org/index.html"> <exterms:creation-date>August 16, 1999</exterms:creation-date> </rdf:Description> <rdf:Description rdf:about="http://www.example.org/index.html"> <exterms:language>English</exterms:language> </rdf:Description> <rdf:Description rdf:about="http://www.example.org/index.html"> <dc:creator rdf:resource="http://www.example.org/staffid/85740"/> </rdf:Description> </rdf:RDF>
We The following sections will describe a few additional RDF/XML abbreviations in the following sections. However, you should consult abbreviations. [RDF-SYNTAX] for provides a more thorough description of the abbreviations that are available.
RDF/XML can also deleted text: allows us to represent graphs that include nodes that have no URIrefs, i.e., the blank nodes </em>. described in Section 2.3 . For example, Figure 13 (taken from [RDF-SYNTAX] ) shows a graph saying "the document 'http://www.w3.org/TR/rdf-syntax-grammar' has a title 'RDF/XML Syntax Specification (Revised)' and has an editor, the editor has a name 'Dave Beckett' and a home page 'http://purl.org/net/dajobe/' ".
This illustrates an idea deleted text: we discussed in Section 2.3 : the use of a blank node to represent something that does not have a URIref, but can be described in terms of other information. In this case, the blank node represents a person, the editor of the document, and the person is described by his name and home page.
RDF/XML
provides
several
ways
to
represent
graphs
containing
blank
nodes.
These
are
all
described
in
[RDF-SYNTAX]
.
The
approach
we
will
illustrate
illustrated
here,
which
is
the
most
direct
approach,
is
to
assign
a
blank
node
identifier
to
the
each
blank
node.
A
blank
node
identifier
serves
to
identify
a
blank
node
within
a
particular
RDF/XML
document
but,
unlike
a
URIref,
is
unknown
outside
the
document
in
which
it
is
assigned.
A
blank
node
is
referred
to
in
RDF/XML
using
an
<tt>
rdf:nodeID
</tt>
attribute
attribute,
with
a
blank
node
identifier
as
its
value
value,
in
places
where
the
URIref
of
a
resource
deleted text:
node
would
otherwise
appear.
Specifically,
a
statement
with
a
blank
node
as
its
subject
can
be
written
in
RDF/XML
using
an
<tt>
rdf:Description
</tt>
element
which
specifies
with
an
<tt>
rdf:nodeID
</tt>
attribute
instead
of
an
<tt>
rdf:about
</tt>
attribute.
Similarly,
a
statement
with
a
blank
node
as
its
object
can
be
written
using
a
property
element
with
an
<tt>
rdf:nodeID
</tt>
attribute
instead
of
an
<tt>
rdf:resource
</tt>
attribute.
Using
<tt>
rdf:nodeID
</tt>,
,
Example
6
shows
the
RDF/XML
corresponding
to
Figure
13
:
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 3. xmlns:dc="http://purl.org/dc/elements/1.1/" 4. xmlns:exterms="http://example.org/stuff/1.0/"> 5. <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"> 6. <dc:title>RDF/XML Syntax Specification (Revised)</dc:title> 7. <exterms:editor rdf:nodeID="abc"/> 8. </rdf:Description> 9. <rdf:Description rdf:nodeID="abc"> 10. <exterms:fullName>Dave Beckett</exterms:fullName> 11. <exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/> 12. </rdf:Description> 13. </rdf:RDF>
In
Example
6
,
the
blank
node
identifier
<tt>
abc
</tt>
is
used
in
Line
line
9
to
identify
the
blank
node
as
the
subject
of
several
statements,
and
is
used
in
Line
line
7
to
indicate
that
the
blank
node
is
the
value
of
a
resource's
<tt>
exterms:editor
</tt>
property.
The
advantage
of
using
a
blank
node
identifier
over
some
of
the
other
approaches
described
in
[RDF-SYNTAX]
is
that
using
a
blank
node
identifier
allows
the
same
blank
node
to
be
referred
to
in
more
than
one
place
in
the
same
RDF/XML
document.
Finally,
the
typed
literals
deleted text:
we
described
in
Section
2.4
may
be
used
as
property
values
instead
of
the
plain
literals
deleted text:
we
have
used
in
the
examples
so
far.
A
typed
literal
is
represented
in
RDF/XML
by
adding
an
<tt>
rdf:datatype
</tt>
attribute
specifying
a
datatype
URIref
to
the
property
element
containing
the
literal.
For
example,
to
change
the
statement
from
in
Example
2
to
use
a
typed
literal
instead
of
a
plain
literal
for
the
<tt>
creation-date
</tt>
property,
the
triple
representation
would
be:
ex:index.html exterms:creation-date "1999-08-16"^^xsd:date . ex:index.html exterms:creation-date "1999-08-16"^^xsd:date .
with corresponding RDF/XML syntax shown in Example 7 :
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 3. xmlns:exterms="http://www.example.org/terms/"> 4. <rdf:Description rdf:about="http://www.example.org/index.html"> 5. <exterms:creation-date rdf:datatype= "http://www.w3.org/2001/XMLSchema#date">1999-08-16 </exterms:creation-date> 6. </rdf:Description> 7. </rdf:RDF>
In
Line
line
5
of
Example
7
,
a
typed
literal
is
given
as
the
value
of
the
<tt>
ex:creation-date
</tt>
property
element
by
adding
an
<tt>
rdf:datatype
</tt>
attribute
to
the
element's
start-tag
to
specify
the
datatype.
The
value
of
this
attribute
is
the
URIref
of
the
datatype,
in
this
case,
the
URIref
of
the
XML
Schema
<tt>
date
</tt>
datatype.
Since
this
is
an
attribute
value,
the
URIref
must
be
written
out,
rather
than
using
the
QName
abbreviation
<tt>
xsd:date
</tt>
that
we
used
in
the
triple.
A
literal
appropriate
to
this
datatype
is
then
written
as
the
element
content,
in
this
case,
the
literal
<tt>
1999-08-16
</tt>,
,
which
is
the
literal
representation
for
August
16,
1999
in
the
XML
Schema
<tt>
date
</tt>
datatype.
For In the most part, we rest of the Primer, the examples will deleted text: continue to use typed literals from appropriate datatypes rather than plain (untyped) literals, in order to emphasize the value of typed literals in our examples. However, you should conveying more information about the intended interpretation of literal values. (The exceptions will be deleted text: aware that typed plain literals will continue to be used in examples taken from appropriate datatypes, actual applications that do not currently use typed literals, in order to accurately reflect the usage in those applications.)
Example
7
illustrates
that
using
typed
literals
requires
writing
an
rdf:datatype
attribute
with
a
URIref
identifying
the
datatype
for
each
element
whose
value
is
a
typed
literal.
As
noted
earlier,
RDF/XML
requires
that
URIrefs
used
as
attribute
values
must
be
written
out,
rather
than
abbreviated
as
a
QName.
XML
entities
can
be
used
in
RDF/XML
to
improve
readability
in
such
cases,
by
providing
an
additional
abbreviation
facility
for
URIrefs.
Essentially,
an
XML
entity
declaration
associates
a
name
with
a
string
of
characters.
When
the
entity
name
is
referenced
elsewhere
within
an
XML
document,
XML
processors
replace
the
reference
with
the
corresponding
string.
For
example,
the
ENTITY
declaration
(specified
as
part
of
a
DOCTYPE
declaration
at
the
beginning
of
the
RDF/XML
document):
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
defines
the
entity
xsd
to
be
the
string
representing
the
namespace
URIref
for
XML
Schema
datatypes,
can
always
datatypes.
This
declaration
allows
the
full
namespace
URIref
to
be
abbreviated
elsewhere
in
the
XML
document
by
the
entity
reference
&xsd;
.
Using
this
abbreviation,
Example
7
could
also
be
written
as
shown
in
Example
8
.
1. <?xml version="1.0"?>
2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4. xmlns:exterms="http://www.example.org/terms/">
5. <rdf:Description rdf:about="http://www.example.org/index.html">
6. <exterms:creation-date rdf:datatype="&xsd;date">1999-08-16
</exterms:creation-date>
7. </rdf:Description>
8. </rdf:RDF>
The
DOCTYPE
declaration
in
line
2
defines
the
entity
xsd
,
which
is
used
instead.
in
line
6.
The
use
of
XML
entities
as
an
abbreviation
mechanism
is
optional
in
RDF/XML,
and
hence
the
use
of
an
XML
DOCTYPE
declaration
is
also
optional
in
RDF/XML.
(For
readers
familiar
with
XML,
RDF/XML
is
only
required
to
be
"well-formed"
XML.
RDF/XML
is
not
designed
to
be
validated
against
a
DTD
by
a
validating
XML
processor.
This
is
discussed
more
fully
in
Appendix
B
,
which
provides
additional
information
about
XML).
For
readability
purposes,
examples
in
the
rest
of
the
Primer
will
use
the
XML
entity
xsd
as
just
described.
XML
entities
are
discussed
further
in
Appendix
B
.
As
illustrated
in
Appendix
B
,
other
URIrefs
(and,
more
generally,
other
strings)
can
also
be
abbreviated
using
XML
entities.
However,
the
URIrefs
for
XML
Schema
datatypes
are
the
only
ones
that
will
be
abbreviated
in
this
way
in
Primer
examples.
Although additional abbreviated forms for writing RDF/XML are available, the facilities deleted text: we have illustrated so far provide a simple but general way to serialize express graphs in RDF/XML. Using these facilities, an RDF graph is written in RDF/XML as follows:
rdf:Description
element,
using
an
rdf:about
attribute
if
the
node
has
a
URIref,
or
an
rdf:nodeID
attribute
if
the
node
is
blank.
rdf:resource
attribute
specifying
the
object
of
the
triple
(if
the
object
node
has
a
URIref),
or
an
rdf:nodeID
attribute
specifying
the
object
of
the
triple
(if
the
object
node
is
blank).
Compared to some of the more abbreviated deleted text: serialization approaches described in [RDF-SYNTAX] , this simple deleted text: serialization approach provides the most direct representation of the actual graph structure, and is particularly recommended for applications in which the output RDF/XML is to be used in further RDF processing.
So
far,
we've
been
describing
resources
the
examples
have
assumed
that
we
imagine
the
resources
being
described
have
been
given
URIrefs
already.
For
instance,
in
our
the
initial
examples,
we
examples
provided
descriptive
information
about
example.org's
web
Web
page,
whose
URIref
was
http://www.example.org/index.html.
We
referred
to
this
http://www.example.org/index.html
.
This
resource
was
identified
in
RDF/XML
using
an
<tt>
rdf:about
</tt>
attribute
citing
its
full
URIref.
Although
RDF
doesn't
does
not
specify
or
control
how
URIrefs
are
assigned
to
resources,
sometimes
we
want
it
is
desirable
to
achieve
the
deleted text:
<em>
effect
deleted text:
</em>
of
assigning
URIrefs
to
resources
that
are
part
of
an
organized
group
of
resources.
For
example,
suppose
a
sporting
goods
company,
example.com,
wanted
to
provide
an
RDF-based
catalog
of
its
products,
such
as
tents,
hiking
boots,
and
so
on,
as
an
RDF/XML
document,
identified
by
(and
located
at)
<tt>
http://www.example.com/2002/04/products
</tt>.
.
In
that
resource,
each
product
might
be
given
a
separate
RDF
description.
This
catalog,
along
with
one
of
these
descriptions,
the
catalog
entry
for
a
model
of
tent
called
the
"Overnighter",
might
be
written
in
RDF/XML
as
shown
in
<a href="#example8">
Example
8
9
:
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 3. xmlns:exterms="http://www.example.com/terms/"> 3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 4. xmlns:exterms="http://www.example.com/terms/"> deleted text: 4. <rdf:Description rdf:ID="item10245"> 5. <exterms:model>Overnighter</exterms:model> 5. <rdf:Description rdf:ID="item10245"> 6. <exterms:sleeps>2</exterms:sleeps> 6. <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model> 7. <exterms:weight>2.4</exterms:weight> 7. <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps> 8. <exterms:packedSize>14x56</exterms:packedSize> 8. <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight> 9. </rdf:Description> 9. <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize> 10. </rdf:Description> ...other product descriptions... 10. </rdf:RDF> 11. </rdf:RDF>
(We've included the (The surrounding xml, DOCTYPE, RDF, and namespace information is included in lines 1 through 3, 4, and line 10, 11, but this information would only need to be defined provided once for the whole catalog, not repeated for each entry in the catalog).
<a href="#example8">
Example
8
9
is
similar
to
deleted text:
our
previous
examples
in
the
way
it
represents
the
properties
(model,
sleeping
capacity,
weight)
of
the
resource
(the
tent)
being
described.
However,
in
line
4,
5,
the
<tt>
rdf:Description
</tt>
element
has
an
<tt>
rdf:ID
</tt>
attribute
instead
of
an
<tt>
rdf:about
</tt>
attribute.
Using
<tt>
rdf:ID
</tt>
indicates
that
we
are
using
specifies
a
fragment
identifier
,
given
by
the
value
of
the
<tt>
rdf:ID
</tt>
attribute
(
<tt>
item10245
</tt>
in
this
case,
which
might
be
the
catalog
number
assigned
by
example.com),
as
an
abbreviation
of
the
complete
URIref
of
the
resource
we
are
describing.
being
described.
The
fragment
identifier
<tt>
item10245
</tt>
will
be
interpreted
relative
to
a
base
URI
,
in
this
case,
the
URI
of
the
containing
catalog
document.
The
full
URIref
for
the
tent
is
formed
by
taking
the
base
URI
(of
the
catalog),
and
appending
<tt>
the
character
"
#
</tt>
"
(to
indicate
that
what
follows
is
a
fragment
identifier)
and
then
<tt>
item10245
</tt>
to
it,
giving
the
absolute
URIref
<tt>
http://www.example.com/2002/04/products#item10245
</tt>.
.
The
<tt>
rdf:ID
</tt>
attribute
is
somewhat
similar
to
the
ID
attribute
in
XML
and
HTML,
in
that
it
defines
a
name
which
must
be
unique
within
relative
to
the
document
current
base
URI
(in
this
case,
example,
that
of
the
catalog)
in
which
it
is
defined.
catalog).
In
this
case,
the
<tt>
rdf:ID
</tt>
attribute
appears
to
be
assigning
a
name
(
<tt>
item10245
</tt>
)
to
this
particular
kind
of
tent.
Any
other
RDF/XML
within
this
catalog
could
refer
to
the
tent
by
using
either
the
absolute
URIref
http://www.example.com/2002/04/products#item10245
,
or
the
relative
URIref
<tt>
#item10245
</tt>
in
an
<tt>
rdf:about
</tt>
attribute.
This
.
The
relative
URIref
would
be
understood
as
being
a
URIref
defined
relative
to
the
base
URIref
of
the
catalog.
Using
a
similar
abbreviation,
deleted text:
we
could
also
have
given
the
URIref
of
the
tent
could
also
be
given
by
specifying
<tt>
rdf:about="#item10245"
</tt>
in
the
catalog
entry
(i.e.,
by
specifying
the
relative
URIref
directly)
instead
of
<tt>
rdf:ID="item10245"
</tt>
.
The
As
an
abbreviation
mechanism,
the
two
forms
are
essentially
synonyms:
the
full
URIref
formed
by
RDF/XML
is
the
same
in
either
case:
<tt>
http://www.example.com/2002/04/products#item10245
</tt>.
In
.
However,
using
rdf:ID
provides
an
additional
check
when
assigning
a
set
of
distinct
names,
since
a
given
value
of
the
rdf:ID
attribute
can
only
appear
once
relative
to
the
same
base
URI
(the
catalog
document,
in
this
example).
Using
either
case,
form,
example.com
would
be
giving
the
URIref
for
the
tent
in
a
two-stage
process,
first
assigning
the
URIref
for
the
whole
catalog,
and
then
using
a
relative
URIref
in
the
description
of
the
tent
in
the
catalog
to
indicate
the
URIref
that
has
been
assigned
to
this
particular
kind
of
tent.
Moreover,
deleted text:
you
can
think
of
this
use
of
a
relative
URIref
as
can
be
thought
of
either
as
being
an
abbreviation
for
a
full
URIref
that
has
been
assigned
to
the
tent
independently
of
the
RDF,
or
as
being
the
assignment
of
the
URIref
to
the
tent
within
the
catalog.
RDF
located
outside
the
catalog
could
refer
to
this
tent
by
using
the
full
URIref,
i.e.,
by
concatenating
the
relative
URIref
<tt>
#item10245
</tt>
of
the
tent
to
the
base
URI
of
the
catalog,
forming
the
absolute
URIref
<tt>
http://www.example.com/2002/04/products#item10245
</tt>.
.
For
example,
an
outdoor
sports
web
Web
site
exampleRatings.com
might
use
RDF
to
provide
ratings
of
various
tents.
The
(5-star)
rating
given
to
the
tent
described
in
<a href="#example8">
Example
8
9
might
then
be
represented
on
exampleRatings.com's
web
Web
site
as
shown
in
<a href="#example9">
Example
9
10
:
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 3. xmlns:sportex="http://www.exampleRatings.com/terms/"> 3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 4. xmlns:sportex="http://www.exampleRatings.com/terms/"> deleted text: 4. <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245"> 5. <sportex:ratingBy>Richard Roe</sportex:ratingBy> 5. <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245"> 6. <sportex:numberStars>5</sportex:numberStars> 6. <sportex:ratingBy rdf:datatype="&xsd;string">Richard Roe</sportex:ratingBy> 7. </rdf:Description> 7. <sportex:numberStars rdf:datatype="&xsd;integer">5</sportex:numberStars> 8. </rdf:RDF> 8. </rdf:Description> 9. </rdf:RDF>
In
<a href="#example9">
Example
9
10
,
line
4
5
uses
an
<tt>
rdf:Description
</tt>
element
with
an
<tt>
rdf:about
</tt>
attribute
whose
value
is
the
full
URIref
of
the
tent.
The
use
of
this
URIref
allows
the
tent
being
referred
to
in
the
rating
to
be
precisely
identified.
These examples illustrate several points. First, even though RDF doesn't does not specify or control how URIrefs are assigned to resources (in this case, the various tents and other items in the catalog), the effect of assigning URIrefs to resources in RDF can be achieved by combining a process (external to RDF) that identifies a single document (the catalog in this case) as the source for descriptions of those resources, with the use of relative URIrefs in descriptions of those resources within that document. For instance, example.com could use this catalog as the central source where its products are described, with the understanding that if a product's item number isn't is not in an entry in this catalog, it's it is not a product known to example.com. (Note that RDF does not assume any particular relationship exists between two resources just because their URIrefs have the same base, or are otherwise similar. This relationship may be known to example.com, but it is not directly defined by RDF.)
These
examples
also
illustrate
one
of
the
basic
architectural
principles
of
the
Web,
which
is
that
anyone
should
be
able
say
anything
they
want
to
freely
add
information
about
an
existing
resources
resource,
using
any
vocabulary
they
please
[BERNERS-LEE98]
.
The
examples
further
illustrate
that
the
RDF
describing
a
particular
resource
does
not
need
to
be
located
all
in
one
place;
instead,
it
may
be
distributed
throughout
the
web.
Web.
This
is
true
not
only
for
situations
like
this
one,
in
which
one
organization
is
rating
or
commenting
on
resources
a
resource
defined
by
another,
but
also
for
situations
in
which
the
original
definer
of
a
resource
(or
anyone
else)
wishes
to
amplify
the
description
of
that
resource
by
providing
additional
information
about
it.
This
may
be
done
deleted text:
either
by
modifying
the
RDF
document
in
which
the
resource
was
originally
described,
to
add
the
properties
and
values
needed
to
describe
the
additional
information,
or,
information.
Or,
as
this
example
illustrates,
deleted text:
by
creating
a
separate
document,
and
document
could
be
created,
providing
the
additional
properties
and
values
in
<tt>
rdf:Description
</tt>
elements
that
refer
to
the
original
resource
via
its
URIref
using
<tt>
rdf:about
</tt>.
.
The
discussion
above
indicated
that
fragment
identifiers
relative
URIrefs
such
as
<tt>
#item10245
</tt>
will
be
interpreted
relative
to
a
base
URI
.
By
default,
this
base
URI
would
be
the
URI
of
the
resource
in
which
the
fragment
identifier
relative
URIref
is
used.
However,
in
some
cases
it
is
desirable
to
be
able
to
explicitly
specify
this
base
URI.
For
instance,
suppose
that
in
addition
to
the
catalog
located
at
<tt>
http://www.example.com/2002/04/products
</tt>,
,
example.org
wanted
to
provide
a
duplicate
catalog
on
a
mirror
site,
say
at
<tt>
http://mirror.example.com/2002/04/products
</tt>.
.
This
could
create
a
problem,
since
if
the
catalog
was
accessed
from
the
mirror
site,
the
URIref
for
our
the
example
tent
would
be
generated
from
the
URI
of
the
containing
document,
forming
<tt>
http://mirror.example.com/2002/04/products#item10245
</tt>,
,
rather
than
<tt>
http://www.example.com/2002/04/products#item10245
</tt>,
,
and
hence
would
apparently
refer
to
a
different
resource
than
the
one
intended.
Alternatively,
example.org
might
want
to
assign
a
base
URIref
for
its
set
of
product
URIrefs
without
publishing
a
single
source
document
whose
location
defines
the
base.
To deal with such cases, RDF/XML supports XML Base [XML-BASE] , which allows an XML document to specify a base URI other than the URI of the document itself. <a href="#example10"> Example 10 11 shows how deleted text: we would define the catalog would be described using XML Base:
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 3. xmlns:exterms="http://www.example.com/terms/" 3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 4. xml:base="http://www.example.com/2002/04/products"> 4. xmlns:exterms="http://www.example.com/terms/" 5. xml:base="http://www.example.com/2002/04/products"> deleted text: 5. <rdf:Description rdf:ID="item10245"> 6. <exterms:model>Overnighter</exterms:model> 6. <rdf:Description rdf:ID="item10245"> 7. <exterms:sleeps>2</exterms:sleeps> 7. <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model> 8. <exterms:weight>2.4</exterms:weight> 8. <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps> 9. <exterms:packedSize>14x56</exterms:packedSize> 9. <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight> 10. </rdf:Description> 10. <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize> 11. </rdf:Description> ...other product descriptions... 11. </rdf:RDF> 12. </rdf:RDF>
In
<a href="#example10">
Example
10
11
,
the
<tt>
xml:base
</tt>
declaration
in
line
4
5
specifies
that
the
base
URI
for
the
content
within
the
<tt>
rdf:RDF
</tt>
element
(until
another
<tt>
xml:base
</tt>
attribute
is
specified)
is
<tt>
http://www.example.com/2002/04/products
</tt>,
,
and
all
relative
URIrefs
cited
within
that
content
will
be
interpreted
relative
to
that
base,
no
matter
what
the
URI
of
the
containing
document
is.
As
a
result,
the
relative
URIref
of
our
the
tent,
<tt>
#item10245
</tt>,
,
will
be
interpreted
as
the
same
absolute
URIref,
<tt>
http://www.example.com/2002/04/products#item10245
</tt>,
,
no
matter
what
the
actual
URI
of
the
catalog
document
is,
or
whether
the
base
URIref
actually
identifies
a
particular
document
at
all.
So
far,
we've
been
talking
about
the
examples
have
used
a
single
product
description,
a
particular
model
of
tent,
from
example.com's
catalog.
However,
example.com
will
probably
offer
several
different
models
of
tents,
as
well
as
multiple
instances
of
other
categories
of
products,
such
as
backpacks,
hiking
boots,
and
so
on.
This
idea
of
things
being
classified
into
different
kinds
or
categories
is
similar
to
the
programming
language
concept
of
objects
having
different
types
or
classes
.
RDF
supports
this
concept
by
providing
a
predefined
property,
<tt>
rdf:type
</tt>.
.
When
an
RDF
resource
is
described
with
an
<tt>
rdf:type
</tt>
property,
the
value
of
that
property
is
considered
to
be
a
resource
that
represents
a
category
or
class
of
things,
and
the
subject
of
that
property
is
considered
to
be
an
instance
of
that
category
or
class.
Using
<tt>
rdf:type
</tt>,
<a href="#example11">
,
Example
11
12
shows
how
example.com
might
indicate
that
our
the
product
description
is
that
of
a
tent:
rdf:type
</tt>
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 3. xmlns:exterms="http://www.example.com/terms/" 3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 4. xml:base="http://www.example.com/2002/04/products"> 4. xmlns:exterms="http://www.example.com/terms/" 5. xml:base="http://www.example.com/2002/04/products"> deleted text: 5. <rdf:Description rdf:ID="item10245"> 6. <rdf:type rdf:resource="http://www.example.com/terms/Tent" /> 6. <rdf:Description rdf:ID="item10245"> 7. <exterms:model>Overnighter</exterms:model> 7. <rdf:type rdf:resource="http://www.example.com/terms/Tent"/> 8. <exterms:sleeps>2</exterms:sleeps> 8. <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model> 9. <exterms:weight>2.4</exterms:weight> 9. <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps> 10. <exterms:packedSize>14x56</exterms:packedSize> 10. <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight> 11. </rdf:Description> 11. <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize> 12. </rdf:Description> ...other product descriptions... 12. </rdf:RDF> 13. </rdf:RDF>
In
<a href="#example11">
Example
11
12
,
the
<tt>
rdf:type
</tt>
property
in
Line
6
line
7
indicates
that
the
resource
being
described
is
an
instance
belongs
to
a
of
the
class
identified
by
the
URIref
<tt>
http://www.example.com/terms/Tent
</tt>.
In
this
case,
we
imagine
.
This
assumes
that
example.com
has
described
its
classes
as
part
of
the
same
vocabulary
that
it
uses
to
describe
its
other
terms
(such
as
the
property
<tt>
exterms:weight
</tt>
),
so
deleted text:
we
use
the
absolute
URIref
of
the
class
is
used
to
refer
to
it.
If
example.com
had
described
these
classes
as
part
of
the
product
catalog
itself,
deleted text:
we
could
have
used
the
relative
URIref
<tt>
#Tent
</tt>
could
have
been
used
to
refer
to
it.
RDF
itself
does
not
define
a
vocabulary
provide
facilities
for
defining
application-specific
classes
of
things,
such
as
<tt>
Tent
</tt>
in
this
example.
example,
or
their
properties,
such
as
exterms:weight
.
Instead,
such
classes
would
be
described
in
an
RDF
Schema
</em>.
The
facilities
provided
by
schema
,
using
the
RDF
for
describing
application-specific
classes
and
their
properties
are
Schema
language
discussed
in
Section
5
.
Other
such
facilities
for
describing
classes
can
also
be
defined,
such
as
the
DAML+OIL
and
OWL
languages
described
in
Section
5.5
.
Since
describing
It
is
fairly
common
in
RDF
for
resources
to
have
rdf:type
properties
that
describe
the
resources
as
instances
of
specific
types
or
classes
is
fairly
common,
classes.
Such
resources
are
called
typed
nodes
in
the
graph,
or
typed
node
elements
in
the
RDF/XML.
RDF/XML
provides
a
special
abbreviation
for
instances
described
as
members
of
classes
using
the
<tt>
rdf:type
</tt>
property.
describing
these
typed
nodes.
In
this
abbreviation,
the
<tt>
rdf:type
</tt>
property
and
its
value
are
removed,
and
the
<tt>
rdf:Description
</tt>
element
for
the
node
is
replaced
by
an
element
whose
name
is
the
QName
corresponding
to
the
class
URIref.
value
of
the
removed
rdf:type
property
(a
URIref
that
names
a
class).
Using
this
abbreviation,
example.com's
tent
from
<a href="#example11">
Example
11
12
could
also
be
described
as
shown
in
<a href="#example12">
Example
12
13
:
1. <?xml version="1.0"?> 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 3. xmlns:exterms="http://www.example.com/terms/" 3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 4. xml:base="http://www.example.com/2002/04/products"> 4. xmlns:exterms="http://www.example.com/terms/" 5. xml:base="http://www.example.com/2002/04/products"> deleted text: 5. <exterms:Tent rdf:ID="item10245"> 6. <exterms:model>Overnighter</exterms:model> 6. <exterms:Tent rdf:ID="item10245"> 7. <exterms:sleeps>2</exterms:sleeps> 7. <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model> 8. <exterms:weight>2.4</exterms:weight> 8. <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps> 9. <exterms:packedSize>14x56</exterms:packedSize> 9. <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight> 10. </exterms:Tent> 10. <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize> 11. </exterms:Tent> ...other product descriptions... 11. </rdf:RDF> 12. </rdf:RDF>
Both
<a href="#example11">
Since
a
resource
may
be
described
as
an
instance
of
more
than
one
class,
a
resource
may
have
more
than
one
rdf:type
property.
However,
only
one
of
these
rdf:type
properties
can
be
abbreviated
in
this
way.
The
others
must
be
written
out
using
rdf:type
properties,
in
the
manner
illustrated
by
the
rdf:type
property
in
Example
11
</a>
12
.
In
addition
to
its
use
in
describing
instances
of
user-defined
classes
such
as
exterms:Tent
,
the
typed
node
abbreviation
is
also
commonly
used
in
RDF/XML
when
describing
instances
of
the
built-in
RDF
classes
(such
as
rdf:Bag
)
to
be
described
in
Section
4
,
and
the
built-in
RDF
Schema
classes
(such
as
rdfs:Class
)
to
be
described
in
Section
5
.
Both Example 12 and Example 13 illustrate that RDF statements can be written in RDF/XML in a way that closely resembles descriptions that might have been written directly in (non-RDF) XML. This is an important consideration, given the increasing use of XML in all kinds of applications, since it suggests that RDF could be used in these applications without requiring major changes in the way their information is structured.
The examples above have illustrated some of the basic ideas behind the RDF/XML syntax. These examples provide enough information to deleted text: enable you to begin writing useful RDF/XML. For a A more thorough discussion of the principles behind the modeling of RDF statements in XML (known as striping ), together with a presentation of the other RDF/XML abbreviations available, and other details and examples about writing RDF in XML, you should refer to is given in the (normative) RDF/XML Syntax Specification [RDF-SYNTAX] .
RDF provides a number of additional capabilities, including some such as built-in types and properties for representing groups of resources and RDF statements, and capabilities for deploying RDF information in the World Wide Web. representing XML fragments as property values. These additional capabilities are described in the following sections.
There is often a need to describe groups of things. For things: for example, deleted text: we might want to say that a book was created by several authors, or to list the students in a course, or the software modules in a package. RDF provides several pre-defined predefined (built-in) types and properties that can be used to describe such groups.
First, RDF provides a container vocabulary consisting of three predefined types (together with some associated predefined properties). A container is a resource that contains things. The contained things are called members . The members of a container may be resources (including blank nodes) or literals. RDF defines three types of containers:
rdf:Bag
</tt>
rdf:Seq
</tt>
rdf:Alt
</tt>
A
Bag
(a
resource
having
type
<tt>
rdf:Bag
</tt>
)
is
represents
a
group
of
resources
or
literals,
possibly
including
duplicate
members,
where
there
is
no
significance
in
the
order
of
the
members.
For
example,
a
Bag
might
be
used
to
describe
a
group
of
part
numbers
in
which
the
order
of
entry
or
processing
of
the
part
numbers
does
not
matter.
A
Sequence
or
Seq
(a
resource
having
type
<tt>
rdf:Seq
</tt>
)
is
represents
a
group
of
resources
or
literals,
possibly
including
duplicate
members,
where
the
order
of
the
members
is
significant.
For
example,
a
Sequence
might
be
used
to
describe
a
group
that
must
be
maintained
in
alphabetical
order.
An
Alternative
or
Alt
(a
resource
having
type
<tt>
rdf:Alt
</tt>
)
is
represents
a
group
of
resources
or
literals
that
are
alternatives
(typically
for
a
single
value
of
a
property).
For
example,
an
Alt
might
be
used
to
describe
alternative
language
translations
for
the
title
of
a
book,
or
to
describe
a
list
of
alternative
Internet
sites
at
which
a
resource
might
be
found.
An
application
using
a
property
whose
value
is
an
Alt
container
should
be
aware
that
it
can
choose
any
one
of
the
members
of
the
group
as
appropriate.
To
describe
a
resource
as
being
one
of
these
types
of
containers,
deleted text:
you
give
the
resource
is
given
an
<tt>
rdf:type
</tt>
property
whose
value
is
one
of
the
pre-defined
predefined
resources
<tt>
rdf:Bag
</tt>,
<tt>
,
rdf:Seq
</tt>,
,
or
<tt>
rdf:Alt
</tt>
(whichever
is
appropriate).
The
container
resource
(which
may
either
be
a
blank
node
or
a
resource
with
a
URIref)
denotes
the
group
as
a
whole.
The
members
of
the
container
can
be
described
by
defining
a
container
membership
property
for
each
member
with
the
container
resource
as
its
subject
and
the
member
as
its
object.
These
container
membership
properties
have
names
of
the
form
<tt>
rdf:_
n
</tt>,
,
where
n
is
a
decimal
integer
greater
than
zero,
with
no
leading
zeros,
e.g.,
<tt>
rdf:_1
</tt>,
<tt>
rdf_2
</tt>,
<tt>
rdf_3
</tt>,
,
rdf:_2
,
rdf:_3
,
and
so
on,
and
are
used
specifically
for
describing
the
members
of
containers.
Container
resources
may
also
have
other
properties
that
describe
the
container,
in
addition
to
the
container
membership
properties
and
the
<tt>
rdf:type
</tt>
property.
It
is
important
to
understand
that
while
these
types
of
containers
are
described
using
pre-defined
predefined
RDF
types
and
properties,
any
special
meanings
associated
with
these
containers,
e.g.,
that
the
members
of
an
Alt
container
are
alternative
values,
are
only
intended
meanings.
These
specific
container
types,
and
their
definitions,
are
provided
with
the
aim
of
establishing
a
shared
convention
among
those
who
need
to
describe
groups
of
things.
All
RDF
does
is
provide
the
types
and
properties
that
can
be
used
to
construct
the
RDF
graphs
to
describe
each
type
of
container.
RDF
has
no
more
built-in
understanding
of
what
a
resource
of
type
<tt>
rdf:Bag
</tt>
is
than
it
has
of
what
a
resource
of
type
<tt>
ex:Tent
</tt>,
that
we
discussed
(discussed
in
Section
3.2
</a>,
)
is.
In
each
case,
applications
must
be
written
to
behave
according
to
the
particular
meaning
involved
for
each
type.
This
point
will
be
expanded
on
in
the
following
examples.
A
typical
use
of
a
container
is
to
indicate
that
the
value
of
a
property
is
a
group
of
things.
For
example,
to
represent
the
sentence
"Course
6.001
has
the
students
Amy,
Tim,
John,
Mary,
Mohamed,
Johann,
Maria,
and
Sue",
you
could
describe
Phuong",
the
course
could
be
described
by
giving
it
a
<tt>
s:students
</tt>
property
(from
an
appropriate
vocabulary)
whose
value
is
a
container
of
type
<tt>
rdf:Bag
</tt>
(the
(
representing
the
group
of
students)
and
then,
students).
Then,
using
the
container
membership
properties,
deleted text:
describe
the
individual
students
could
be
identified
as
being
members
of
that
container,
group,
as
in
the
RDF
graph
shown
in
Figure
14
:
Since
the
value
of
the
<tt>
s:students
</tt>
property
in
this
example
is
described
as
a
Bag,
there
is
no
intended
significance
in
the
order
given
for
the
URIrefs
of
each
student,
the
students,
even
though
the
membership
properties
in
the
graph
have
integers
in
their
names.
It
is
up
to
applications
creating
and
processing
graphs
that
include
<tt>
rdf:Bag
</tt>
containers
to
ignore
any
(apparent)
order
in
the
names
of
the
membership
properties.
RDF/XML provides some special syntax and abbreviations to make it simpler to describe such containers. For example, <a href="#example13"> Example 13 14 describes the graph shown in Figure 14 :
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://example.edu/students/vocab#"> xmlns:s="http://example.org/students/vocab#"> <rdf:Description rdf:about="http://example.edu/courses/6.001"> <rdf:Description rdf:about="http://example.org/courses/6.001"> <s:students> <rdf:Bag> <rdf:li rdf:resource="http://example.edu/students/Amy"/> <rdf:li rdf:resource="http://example.org/students/Amy"/> <rdf:li rdf:resource="http://example.edu/students/Tim"/> <rdf:li rdf:resource="http://example.org/students/Mohamed"/> <rdf:li rdf:resource="http://example.edu/students/John"/> <rdf:li rdf:resource="http://example.org/students/Johann"/> <rdf:li rdf:resource="http://example.edu/students/Mary"/> <rdf:li rdf:resource="http://example.org/students/Maria"/> <rdf:li rdf:resource="http://example.edu/students/Sue"/> <rdf:li rdf:resource="http://example.org/students/Phuong"/> </rdf:Bag> </s:students> </rdf:Description> </rdf:RDF>
<a href="#example13">
Example
13
14
shows
that
RDF/XML
provides
<tt>
li
</tt>
rdf:li
as
a
convenience
element
to
avoid
having
to
explicitly
number
each
membership
property.
The
numbered
properties
<tt>
rdf:_1
</tt>,
<tt>
,
rdf:_2
</tt>,
,
and
so
on
are
generated
from
the
<tt>
li
</tt>
rdf:li
elements
in
forming
the
corresponding
graph.
The
element
name
<tt>
li
</tt>
rdf:li
was
chosen
to
be
mnemonic
with
the
term
"list
item"
from
HTML.
Note
also
the
use
of
a
<tt>
<rdf:Bag>
</tt>
element
nested
within
the
<tt>
<s:students>
</tt>
property
element.
The
<tt>
<rdf:Bag>
</tt>
element
is
another
example
of
the
abbreviation
deleted text:
we
used
in
<a href="#example12">
Example
12
13
that
lets
us
replace
replaces
both
an
<tt>
rdf:Description
</tt>
element
and
an
<tt>
rdf:type
</tt>
element
with
a
single
element.
element
when
describing
an
instance
of
a
type
(an
instance
of
rdf:Bag
in
this
case).
Since
no
URIref
is
specified,
the
Bag
is
a
blank
node.
Its
nesting
within
the
<tt>
<s:students>
</tt>
property
element
is
an
abbreviated
way
of
indicating
that
the
blank
node
is
the
value
of
this
property.
These
abbreviations
are
described
further
in
[RDF-SYNTAX]
.
The
graph
structure
for
an
<tt>
rdf:Seq
</tt>
container,
and
the
corresponding
RDF/XML,
are
similar
to
those
for
an
<tt>
rdf:Bag
</tt>
(the
only
difference
is
in
the
type,
<tt>
rdf:Seq
</tt>
).
Once
again,
although
an
<tt>
rdf:Seq
</tt>
container
is
intended
to
describe
a
sequence,
it
is
up
to
applications
creating
and
processing
the
graph
to
appropriately
interpret
the
sequence
of
integer-valued
property
names.
As an illustration of To illustrate an Alt container, the sentence "The source code for X11 may be found at ftp.example.org, ftp.example1.org, ftp1.example.org, or ftp.example2.org" ftp2.example.org" could be expressed in the RDF graph shown in Figure 15 :
<a href="#example14"> Example 14 15 shows how the graph in Figure 15 could be written in RDF/XML:
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://example.org/packages/vocab#"> <rdf:Description rdf:about="http://example.org/packages/X11"> <s:DistributionSite> <rdf:Alt> <rdf:li rdf:resource="ftp://ftp.example.org"/> <rdf:li rdf:resource="ftp://ftp.example1.org"/> <rdf:li rdf:resource="ftp://ftp1.example.org"/> <rdf:li rdf:resource="ftp://ftp.example2.org"/> <rdf:li rdf:resource="ftp://ftp2.example.org"/> </rdf:Alt> </s:DistributionSite> </rdf:Description> </rdf:RDF>
An
Alt
container
is
intended
to
have
at
least
one
member,
identified
by
the
property
<tt>
rdf:_1
</tt>.
.
This
member
is
intended
to
be
considered
as
the
default
or
preferred
value.
Other
than
the
member
identified
as
<tt>
rdf:_1
</tt>,
,
the
order
of
the
remaining
elements
is
not
significant.
The
RDF
in
Figure
15
as
written
states
simply
that
the
value
of
the
<tt>
s:DistributionSite
</tt>
site
property
is
the
Alt
container
resource
itself.
Any
additional
meaning
that
is
to
be
read
into
this
graph,
e.g.,
that
one
of
the
members
of
the
Alt
container
is
to
be
considered
as
the
value
of
the
<tt>
s:DistributionSite
</tt>
site
property,
or
that
<tt>
ftp://ftp.example.org
</tt>
is
the
default
or
preferred
value,
must
be
built
into
an
application's
understanding
of
how
the
intended
meaning
of
an
Alt
is
intended
to
behave,
container,
and/or
into
the
meaning
defined
for
the
particular
property
(
<tt>
s:DistributionSite
</tt>
in
this
case),
which
also
must
be
understood
by
the
application.
Alt
containers
are
frequently
used
in
conjunction
with
language
tagging.
(RDF/XML
permits
the
use
of
the
xml:lang
attribute
defined
in
[XML]
to
indicate
that
the
element
content
is
in
a
specified
language.
The
use
of
xml:lang
is
described
in
[RDF-SYNTAX]
,
and
illustrated
later
in
Section
6.2
.)
For
example,
a
work
whose
title
has
been
translated
into
several
languages
might
have
its
<tt>
Title
</tt>
title
property
pointing
to
an
Alt
container
holding
literals
representing
the
titles
expressed
in
each
of
the
language
variants.
The distinction between the intended meanings of a Bag and an Alt can be further illustrated by considering the authorship of the book "Huckleberry Finn". The book has exactly one author, but the author has two names (Mark Twain and Samuel Clemens). Either name is sufficient to specify the author. Thus using an Alt container of for the author's names more accurately represents the relationship than using a Bag (which might suggest there are two different authors).
Users are free to choose their own ways to describe groups of resources, rather than using the ones described here. RDF container vocabulary. These RDF containers are merely provided as common definitions that, if generally used, could help make data involving groups of resources more interoperable.
Sometimes there are clear alternatives to using these RDF container types. For example, a relationship between a particular resource and a group of other resources could be indicated by making the first resource the subject of multiple statements using the same property. This is structurally not the same as different from the resource being the subject of a single statement whose object is a container containing multiple members. In some cases, these two structures may have equivalent meaning, but in other cases they may not. The choice of which to use in a given situation should be made with this in mind.
Consider as an example the relationship between a writer and her publications. We might have publications, as in the sentence:
Sue has written "Anthology of Time", "Zoological Reasoning", and "Gravitational Reflections".
In this case, there are three resources each of which was written independently by the same writer. This could be expressed using repeated properties as:
exstaff:Sue exterms:publication ex:AnthologyOfTime . exstaff:Sue exterms:publication ex:AnthologyOfTime . exstaff:Sue exterms:publication ex:ZoologicalReasoning . exstaff:Sue exterms:publication ex:ZoologicalReasoning . exstaff:Sue exterms:publication ex:GravitationalReflections . exstaff:Sue exterms:publication ex:GravitationalReflections .
In this example there is no stated relationship between the publications other than that they were written by the same person. Each of the statements is an independent fact, and so using repeated properties would be a reasonable choice. However, this could just as reasonably be represented as a statement about the group of resources written by Sue:
exstaff:Sue exterms:publication _:z exstaff:Sue exterms:publication _:z . _:z rdf:type rdf:Bag . _:z rdf:type rdf:Bag . _:z rdf:_1 ex:AnthologyOfTime . _:z rdf:_1 ex:AnthologyOfTime . _:z rdf:_2 ex:ZoologicalReasoning . _:z rdf:_2 ex:ZoologicalReasoning . _:z rdf:_3 ex:GravitationalReflections . _:z rdf:_3 ex:GravitationalReflections .
On the other hand, the sentence:
The resolution was approved by the Rules Committee, having members Fred, Wilma, and Dino.
says
that
the
committee
as
a
whole
approved
the
resolution;
it
does
not
necessarily
state
that
each
committee
member
individually
voted
in
favor
of
the
resolution.
In
this
case,
it
would
be
potentially
misleading
to
model
this
sentence
as
three
separate
<tt>
exterms:approvedBy
</tt>
statements,
one
for
each
committee
member,
as
shown
below:
ex:resolution exterms:approvedBy ex:Fred . ex:resolution exterms:approvedBy ex:Fred . ex:resolution exterms:approvedBy ex:Wilma . ex:resolution exterms:approvedBy ex:Wilma . ex:resolution exterms:approvedBy ex:Dino . ex:resolution exterms:approvedBy ex:Dino .
since these statements say that each member individually approved the resolution.
In
this
case,
it
would
be
better
to
model
the
sentence
as
a
single
<tt>
exterms:approvedBy
</tt>
statement
whose
subject
is
the
resolution
and
whose
object
is
the
committee
itself.
The
committee
resource
could
then
be
described
as
a
Bag
whose
members
are
the
members
of
the
committee,
as
in
the
following
triples:
ex:resolution exterms:approvedBy ex:rulesCommittee ex:resolution exterms:approvedBy ex:rulesCommittee . ex:rulesCommittee rdf:type rdf:Bag . ex:rulesCommittee rdf:type rdf:Bag . ex:rulesCommittee rdf:_1 ex:Fred . ex:rulesCommittee rdf:_1 ex:Fred . ex:rulesCommittee rdf:_2 ex:Wilma . ex:rulesCommittee rdf:_2 ex:Wilma . ex:rulesCommittee rdf:_3 ex:Dino . ex:rulesCommittee rdf:_3 ex:Dino .
Finally,
when
When
using
deleted text:
these
RDF
containers,
it
is
important
to
understand
that
you
the
statements
are
not
constructing
containers,
as
you
would
in
a
programming
language
data
structure;
instead,
you
structure.
Instead,
the
statements
are
describing
containers
(groups
of
things)
that
actually
presumably
exist.
For
instance,
in
the
Rules
Committee
example
just
given,
the
Rules
Committee
is
an
unordered
group
of
people,
whether
deleted text:
you
describe
it
is
described
in
RDF
that
way
or
not.
When
you
give
Saying
that
the
deleted text:
Rules
Committee
resource
an
<tt>
rdf:type
</tt>
property
whose
value
is
<tt>
ex:rulesCommittee
has
type
rdf:Bag
</tt>,
you
are
simply
describing
is
not
saying
that
the
Rules
Committee
as
having
whatever
characteristics
you
associate
with
things
of
type
<tt>
rdf:Bag
</tt>,
not
is
a
data
structure,
or
constructing
a
particular
data
structure
to
hold
the
members
of
the
group
(you
could
indicate
that
the
(the
Rules
Committee
was
could
be
described
as
a
Bag
without
describing
any
members
at
all).
Instead,
it
is
describing
the
Rules
Committee
as
having
characteristics
corresponding
to
those
associated
with
a
Bag
container,
namely
that
it
has
members,
and
their
order
of
description
is
not
significant.
Similarly,
when
you
use
using
the
container
membership
properties,
you
are
properties
simply
describing
describes
a
container
resource
as
having
certain
things
as
members.
You
are
This
does
not
necessarily
saying
say
that
the
things
that
you
describe
described
as
members
are
the
only
members
that
exist.
For
example,
the
triples
given
above
to
describe
the
Rules
Committee
say
only
that
Fred,
Wilma,
and
Dino
are
members
of
the
Bag,
committee,
not
that
they
are
the
only
members
of
the
Bag.
committee.
Also,
Example
14
and
Example
15
illustrated
a
common
"pattern"
in
describing
containers,
regardless
of
the
type
of
container
involved
(e.g.,
use
of
a
blank
node
with
an
appropriate
rdf:type
property
to
represent
the
container
itself,
and
use
of
rdf:li
to
generate
sequentially-numbered
container
membership
properties).
However,
it
is
important
to
understand
that
RDF
does
not
enforce
this
particular
way
of
using
the
RDF
container
vocabulary,
and
so
it
is
possible
to
use
this
vocabulary
in
other
ways.
For
example,
in
some
cases
it
might
be
appropriate
to
use
a
container
resource
having
a
URIref
rather
than
using
a
blank
node.
Moreover,
it
is
possible
to
use
the
container
vocabulary
in
ways
that
may
not
describe
graphs
with
the
"well-formed"
structures
shown
in
the
previous
examples.
For
example,
Example
16
shows
the
RDF/XML
for
a
graph
similar
to
the
Alt
container
shown
in
Figure
15
,
but
which
writes
the
container
membership
properties
explicitly,
rather
than
using
rdf:li
to
generate
them:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://example.org/packages/vocab#">
<rdf:Description rdf:about="http://example.org/packages/X11">
<s:DistributionSite>
<rdf:Alt>
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/>
<rdf:_2 rdf:resource="ftp://ftp.example.org"/>
<rdf:_2 rdf:resource="ftp://ftp1.example.org"/>
<rdf:_5 rdf:resource="ftp://ftp2.example.org"/>
</rdf:Alt>
</s:DistributionSite>
</rdf:Description>
</rdf:RDF>
As
noted
in
[RDF-SEMANTICS]
,
RDF
imposes
no
"well-formedness"
conditions
on
the
use
of
the
container
vocabulary,
so
Example
16
is
perfectly
legal,
even
though
the
container
is
described
as
both
a
Bag
and
an
Alt,
it
is
described
as
having
two
distinct
values
of
the
rdf:_2
property,
and
it
does
not
have
rdf:_1
,
rdf:_3
,
or
rdf:_4
properties.
As a result, RDF applications that require containers to be "well-formed" should be written to check that the container vocabulary is being used appropriately, in order to be fully robust.
A
limitation
of
the
containers
described
in
Section
4.1
is
that
there
is
no
way
to
close
them,
i.e.,
to
say
"these
are
all
the
members
of
the
container".
This
is
because,
As
noted
in
Section
4.1
,
a
container
only
says
that
certain
identified
resources
are
members;
it
does
not
say
that
other
members
do
not
exist.
Also,
while
one
graph
may
describe
some
of
the
members,
there
is
no
way
to
exclude
the
possibility
that
there
is
another
graph
somewhere
that
describes
additional
members.
RDF
provides
support
for
describing
groups
containing
only
the
specified
members,
in
the
form
of
RDF
collections
.
An
RDF
collection
is
a
group
of
things
represented
as
a
list
structure
in
the
RDF
graph.
This
list
structure
is
constructed
using
a
predefined
collection
vocabulary
consisting
of
the
predefined
type
<tt>
rdf:List
</tt>,
,
the
predefined
properties
<tt>
rdf:first
</tt>
and
<tt>
rdf:rest
</tt>,
,
and
the
predefined
resource
<tt>
rdf:nil
</tt>.
.
To illustrate this, deleted text: you could represent the sentence "The students in course 6.001 are Amy, Tim, Mohamed, and John" Johann" could be represented using the graph shown in Figure 16 :
For
In
this
graph,
each
member
of
the
collection,
such
as
<tt>
s:Amy
</tt>,
there
,
is
the
object
of
an
rdf:first
property
whose
subject
is
a
deleted text:
corresponding
resource
of
type
<tt>
rdf:List
</tt>.
(a
blank
node
in
this
example)
that
represents
a
list.
This
list
resource
is
linked
to
the
deleted text:
collection
member
by
an
<tt>
rdf:first
</tt>
property,
and
to
the
rest
of
the
list
by
an
<tt>
rdf:rest
</tt>
property.
The
end
of
the
list
is
indicated
by
an
<tt>
the
rdf:rest
</tt>
property
being
having
as
its
object
the
resource
<tt>
rdf:nil
</tt>.
(the
resource
rdf:nil
represents
the
empty
list,
and
is
defined
as
being
of
type
rdf:List
).
This
structure
will
be
familiar
to
those
who
know
the
Lisp
programming
language.
As
in
Lisp,
the
<tt>
rdf:first
</tt>
and
<tt>
rdf:rest
</tt>
properties
allow
applications
to
traverse
the
structure.
Each
of
the
blank
nodes
forming
this
list
structure
is
implicitly
of
type
rdf:List
(that
is,
each
of
these
nodes
implicitly
has
an
rdf:type
property
whose
value
is
the
predefined
type
rdf:List
),
although
this
is
not
explicitly
shown
in
the
graph.
The
RDF
Schema
language
[RDF-VOCABULARY]
defines
the
properties
rdf:first
and
rdf:rest
as
having
subjects
of
type
rdf:List
,
so
the
information
about
these
nodes
being
lists
can
generally
be
inferred,
rather
than
the
corresponding
rdf:type
triples
being
written
out
all
the
time.
RDF/XML
provides
a
special
notation
to
make
it
easier
easy
to
describe
collections.
collections
using
graphs
of
this
form.
In
RDF/XML,
a
collection
is
can
be
described
by
a
property
element
that
has
the
attribute
<tt>
rdf:parseType="Collection"
</tt>,
,
and
that
contains
a
group
of
nested
elements
representing
the
members
of
the
collection.
The
<tt>
RDF/XML
provides
the
rdf:parseType
attribute
to
indicate
that
the
contents
of
an
element
are
to
be
interpreted
in
a
special
way.
In
this
case,
the
rdf:parseType="Collection"
</tt>
attribute
indicates
that
the
enclosed
elements
are
to
be
used
to
create
the
corresponding
list
structure
in
the
RDF
graph.
graph
(other
values
of
the
rdf:parseType
attribute
will
be
described
in
later
sections
of
the
Primer).
To
illustrate
how
this
rdf:parseType="Collection"
works,
the
RDF/XML
from
<a href="#example15">
Example
15
17
would
result
in
the
RDF
graph
shown
in
Figure
16
:
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://example.edu/students/vocab#"> xmlns:s="http://example.org/students/vocab#"> <rdf:Description rdf:about="http://example.edu/courses/6.001"> <rdf:Description rdf:about="http://example.org/courses/6.001"> <s:students rdf:parseType="Collection"> <rdf:Description rdf:about="http://example.edu/students/Amy"/> <rdf:Description rdf:about="http://example.org/students/Amy"/> <rdf:Description rdf:about="http://example.edu/students/Tim"/> <rdf:Description rdf:about="http://example.org/students/Mohamed"/> <rdf:Description rdf:about="http://example.edu/students/John"/> <rdf:Description rdf:about="http://example.org/students/Johann"/> </s:students> </rdf:Description> </rdf:RDF>
The
use
of
<tt>
rdf:parseType="Collection"
</tt>
in
RDF/XML
always
indicates
the
construction
of
defines
a
list
structure
like
the
one
shown
in
Figure
16
,
which
defines
i.e.,
a
fixed
finite
list
of
items
with
a
given
length
and
terminated
by
<tt>
rdf:nil
</tt>,
,
and
which
uses
"new"
blank
nodes
which
that
are
unique
to
the
list
structure
itself.
However,
RDF
does
not
enforce
this
particular
way
of
using
the
RDF
collection
vocabulary,
and
so
it
is
possible
to
use
this
vocabulary
in
other
ways,
some
of
which
may
not
describe
lists.
lists
or
closed
collections.
To
see
why,
note
that
the
graph
shown
in
Figure
16
could
also
be
written
in
RDF/XML
by
writing
out
the
same
triples
"in
longhand"
(without
using
rdf:parseType="Collection"
)
using
the
collection
vocabulary,
as
in
Example
18
:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://example.org/students/vocab#">
<rdf:Description rdf:about="http://example.org/courses/6.001">
<s:students rdf:nodeID="sch1"/>
</rdf:Description>
<rdf:Description rdf:nodeID="sch1">
<rdf:first rdf:resource="http://example.org/students/Amy"/>
<rdf:rest rdf:nodeID="sch2"/>
</rdf:Description>
<rdf:Description rdf:nodeID="sch2">
<rdf:first rdf:resource="http://example.org/students/Mohamed"/>
<rdf:rest rdf:nodeID="sch3"/>
</rdf:Description>
<rdf:Description rdf:nodeID="sch3">
<rdf:first rdf:resource="http://example.org/students/Johann"/>
<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
</rdf:Description>
</rdf:RDF>
As
noted
in
[RDF-SEMANTICS]
(and
as
was
the
case
for
the
container
vocabulary
described
in
Section
4.1
),
RDF
imposes
no
"well-formedness"
conditions
on
the
use
of
the
collection
vocabulary
so,
when
writing
triples
in
longhand,
it
is
possible
to
define
RDF
graphs
with
structures
other
than
the
well-structured
graphs
that
would
be
automatically
generated
by
using
rdf:parseType="Collection"
.
For
example,
it
is
not
illegal
to
assert
that
a
given
node
has
two
distinct
values
of
the
<tt>
rdf:first
</tt>
property,
to
create
structures
that
have
forked
or
non-list
tails,
or
to
simply
omit
part
of
the
description
of
a
collection.
Also,
graphs
defined
by
using
the
collection
vocabulary
in
longhand
could
use
URIrefs
to
identify
the
components
of
the
list
instead
of
blank
nodes
unique
to
the
list
structure.
In
general,
therefore,
this
case,
it
would
be
possible
to
create
triples
in
other
graphs
that
effectively
added
elements
to
the
collection,
making
it
non-closed.
As a result, RDF applications which that require collections to be well-structured well-formed should be written to check that the collection vocabulary is being used appropriately, in order to be fully robust. In addition, languages such as OWL [OWL] , which can define additional constraints on the structure of RDF graphs, can rule out some of these cases.
RDF
applications
sometimes
need
to
make
<em>
statements
about
describe
other
RDF
statements
</em>,
using
RDF,
for
instance,
to
record
information
about
when
a
statement
was
statements
were
made,
who
made
it,
them,
or
other
similar
information.
information
(this
is
sometimes
referred
to
as
"provenance"
information).
For
example,
consider
a
statement
about
the
tent
we
discussed
Example
9
in
Section
3.2
</a>:
</p>
<p class="ptriple">
<tt>
<u>
product
item10245
</u>
has
described
a
<u>
weight
</u>
whose
value
is
<u>
2.4
</u>
</tt>
</p>
<p>
particular
tent
with
a
triple
representation
of:
</p>
<div class="exampleOuter exampleInner">
<pre>
exproducts:item10245 exterms:weight "2.4" .
</pre>
</div>
<p>
Now,
suppose
we
wanted
to
say
in
RDF
that
this
statement
was
made
URIref
exproducts:item10245
,
offered
for
sale
by
John
Smith.
Since
in
RDF
we
can
only
make
statements
about
<em>
resources
</em>,
what
we
would
like
to
be
able
to
do
is
write
something
like:
example.com.
One
of
the
triples
from
that
description,
describing
the
weight
of
the
tent,
was:
<strong>[[</strong>exproducts:item10245 exterms:weight "2.4" .<strong>]]</strong> dc:creator exstaff:85740 . exproducts:item10245 exterms:weight "2.4"^^xsd:decimal .
That is, we want to and it might be able useful for example.com to turn the original statement into a resource, so record who provided that we can make it the subject particular piece of another RDF statement that talks about it. information.
RDF
provides
a
built-in
vocabulary
intended
for
modeling
statements
as
resources.
This
modeling
is
called
<em>
reification
</em>
in
RDF,
and
a
model
describing
RDF
statements.
A
description
of
a
statement
using
this
vocabulary
is
called
the
a
reification
of
the
statement.
deleted text:
</p>
<p>
The
RDF
reification
vocabulary
consists
of
the
type
<tt>
rdf:Statement
</tt>,
,
and
the
properties
<tt>
rdf:subject
</tt>,
<tt>
,
rdf:predicate
</tt>,
,
and
<tt>
rdf:object
</tt>.
In
.
However,
while
RDF
provides
this
reification
vocabulary,
care
is
needed
in
using
it,
because
it
is
easy
to
imagine
that
the
vocabulary
defines
some
things
that
are
not
actually
defined.
This
point
will
be
discussed
further
later
in
this
section.
Using
the
reification
vocabulary,
a
triple
reification
of
the
form:
statement
about
the
tent's
weight
would
be
given
by
assigning
the
statement
a
URIref
such
as
exproducts:triple12345
(so
statements
can
be
written
describing
it),
and
then
describing
the
statement
using
the
statements:
foo rdf:type rdf:Statement . exproducts:triple12345 rdf:type rdf:Statement . exproducts:triple12345 rdf:subject exproducts:item10245 . exproducts:triple12345 rdf:predicate exterms:weight . exproducts:triple12345 rdf:object "2.4"^^xsd:decimal .
is
a
statement
These
statements
say
that
the
resource
<tt>
foo
</tt>
identified
by
the
URIref
exproducts:triple12345
is
an
RDF
triple
in
some
RDF
document.
The
three
properties
<tt>
rdf:subject
</tt>,
<tt>
rdf:predicate
</tt>,
and
<tt>
rdf:object
</tt>,
when
applied
statement,
that
the
subject
of
the
statement
refers
to
deleted text:
<tt>
foo
</tt>,
then
specify
the
subject,
predicate,
resource
identified
by
exproducts:item10245
,
the
predicate
of
the
statement
refers
to
the
resource
identified
by
exterms:weight
,
and
the
object
deleted text:
components
of
the
statement
refers
to
the
decimal
value
identified
by
the
typed
literal
"2.4"^^xsd:decimal
.
Assuming
that
triple
<tt>
foo
</tt>.
the
original
statement
is
actually
identified
by
exproducts:triple12345
,
it
should
be
clear
by
comparing
the
original
statement
with
the
reification
that
the
reification
actually
does
describe
it.
The
conventional
use
of
the
RDF
reification
vocabulary
always
involves
describing
a
statement
using
four
statements
in
this
pattern;
the
four
statements
are
sometimes
referred
to
as
a
"reification
quad"
for
this
reason.
Using
reification
according
to
this
vocabulary,
convention,
example.com
could
record
the
fact
that
John
Smith
made
the
original
statement
about
the
tent's
weight
by
first
assigning
the
original
statement
a
<em>
URIref
(such
as
exproducts:triple12345
as
before),
describing
that
statement
using
the
reification
</em>
of
our
original
triple:
just
described,
and
then
adding
an
additional
statement
that
exproducts:triple12345
was
written
by
John
Smith
(using
a
URIref
to
identify
which
John
Smith
is
being
referred
to).
The
resulting
statements
would
be:
exproducts:item10245 exterms:weight "2.4" . exproducts:triple12345 rdf:type rdf:Statement . exproducts:triple12345 rdf:subject exproducts:item10245 . exproducts:triple12345 rdf:predicate exterms:weight . exproducts:triple12345 rdf:object "2.4"^^xsd:decimal . exproducts:triple12345 dc:creator exstaff:85740 .
is given by The original statement, together with the graph: reification and the attribution of the statement to John Smith, forms the graph shown in Figure 17 :
<div class="exampleOuter exampleInner">This graph could be written in RDF/XML as shown in Example 19 :
_:xxx rdf:type rdf:Statement . <?xml version="1.0"?> _:xxx rdf:subject exproducts:item10245 . <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> _:xxx rdf:predicate exterms:weight . <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:exterms="http://www.example.com/terms/" xml:base="http://www.example.com/2002/04/products"> _:xxx rdf:object "2.4" . <rdf:Description rdf:ID="item10245"> <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight> </rdf:Description> <rdf:Statement rdf:about="#triple12345"> <rdf:subject rdf:resource="http://www.example.com/2002/04/products#item10245"/> <rdf:predicate rdf:resource="http://www.example.com/terms/weight"/> <rdf:object rdf:datatype="&xsd;decimal">2.4</rdf:object> <dc:creator rdf:resource="http://www.example.com/staffid/85740"/> </rdf:Statement> </rdf:RDF>
(The
node
that
is
intended
to
refer
to
Section
3.2
introduced
the
first
triple,
use
of
the
blank
node
<tt>
_:xxx
</tt>
rdf:ID
attribute
in
RDF/XML
in
an
rdf:Description
element
to
abbreviate
the
reification,
could
be
either
a
blank
node
or
a
URIref.)
</p>
<p>
The
<em>
intended
</em>
interpretation
URIref
of
the
subject
of
a
reification
like
this
is
that
<tt>
_:xxx
</tt>
should
statement.
rdf:ID
can
also
be
understood
as
referring
used
in
a
property
element
to
automatically
produce
a
reification
of
the
deleted text:
original
triple
(as
a
whole),
which
is
described
by
that
the
subject,
predicate,
and
object
triples
in
property
element
generates.
Example
20
shows
how
this
could
be
used
to
produce
the
reification.
So,
same
graph
as
Example
19
:
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:exterms="http://www.example.com/terms/"
xml:base="http://www.example.com/2002/04/products">
<rdf:Description rdf:ID="item10245">
<exterms:weight rdf:ID="triple12345" rdf:datatype="&xsd;decimal">2.4
</exterms:weight>
</rdf:Description>
<rdf:Description rdf:about="#triple12345">
<dc:creator rdf:resource="http://www.example.com/staffid/85740"/>
</rdf:Description>
</rdf:RDF>
In
this
case,
specifying
the
reification,
we
would
express
attribute
rdf:ID="triple12345"
in
the
fact
that
exterms:weight
element
results
in
the
original
statement
was
made
by
John
Smith
using
triple
describing
the
graph:
tent's
weight:
_:xxx rdf:type rdf:Statement . exproducts:item10245 exterms:weight "2.4"^^xsd:decimal . _:xxx rdf:subject exproducts:item10245 .
plus the reification triples:
_:xxx rdf:predicate exterms:weight . exproducts:triple12345 rdf:type rdf:Statement . _:xxx rdf:object "2.4" . exproducts:triple12345 rdf:subject exproducts:item10245 . _:xxx dc:creator exstaff:85740 . exproducts:triple12345 rdf:predicate exterms:weight . exproducts:triple12345 rdf:object "2.4"^^xsd:decimal .
The
subject
of
these
reification
triples
is
a
URIref
formed
by
concatenating
the
base
URI
of
the
document
(given
in
the
xml:base
declaration),
the
character
"
#
"
(to
indicate
that
what
follows
is
a
fragment
identifier),
and
the
value
of
the
rdf:ID
attribute;
that
is,
the
triples
have
the
same
subject
exproducts:triple12345
as
in
the
previous
examples.
Note that asserting the intended interpretation reification is not the same as asserting the original statement, and neither implies the other. That is, when someone says that John said something about the triple weight of a tent, they are not making a statement about the weight of a tent themselves, they are making a statement about something John said. Conversely, when someone describes the weight of a tent, they are not also making a statement about a statement they made (since they may have no intention of talking about things called "statements").
The text above deliberately referred in a number of places to "the conventional use of reification". As noted earlier, care is needed when using the RDF reification vocabulary because it is easy to imagine that <tt> _:xxx </tt> refers the vocabulary defines some things that are not actually defined. While there are applications that successfully use reification, they do so by following some conventions, and making some assumptions, that are in addition to the actual meaning that RDF defines for the reification vocabulary, and the actual facilities that RDF provides to support it.
For one thing, it is important to note that in the conventional use of reification, the subject of the reification triples is assumed to identify a particular instance of a triple in a particular RDF document, rather than some arbitrary triple having the same subject, predicate, and object. This particular convention is used because reification is intended for expressing properties such as dates of composition and source information, as in the examples given already, and these properties need to be applied to specific instances of triples. There could be several deleted text: such triples that have the same subject, predicate predicate, and object properties. Although and, although a graph is defined as a set of triples, several instances with the same triple structure might occur in different documents. Thus, deleted text: without this understanding, it would be meaningful to claim that <tt> _:xxx </tt> does not refer to the triple in the first graph, but fully support this convention, there needs to be some other triple with means of associating the same structure. This particular interpretation subject of the reification is used because reification is intended to be used to express properties such as dates of composition and source information, as triples with an individual triple in our example, and these properties need to be applied some document . However, RDF provides no way to specific instances of triples. do this.
Note
also
that
For
instance,
in
the
assertion
of
examples
above,
there
is
no
explicit
information
in
either
the
reified
triples
or
the
RDF/XML
that
actually
indicates
that
the
original
statement
describing
the
tent's
weight
is
deleted text:
not
the
same
as
resource
exproducts:triple12345
,
the
assertion
resource
that
is
the
subject
of
the
original
statement,
four
reification
statements
and
deleted text:
neither
implies
the
other.
That
is,
when
someone
asserts
that
John
said
foo,
they
are
not
asserting
foo
themselves,
just
statement
that
John
said
Smith
created
it.
Conversely,
when
someone
asserts
foo,
they
are
not
also
asserting
its
reification,
since
This
can
be
seen
by
asserting
foo
they
are
not
also
saying
that
there
are
such
things
as
statements
that
they
intend
to
talk
about.
</p>
<p>
We
have
referred
to
looking
at
the
<em>
intended
</em>
interpretation
of
reification
drawn
graph
shown
in
the
discussion
above
because,
while
Figure
17
.
The
original
statement
is
certainly
part
of
this
may
be
graph,
but
as
far
as
the
interpretation
that
information
in
the
graph
is
generally
intended
when
reification
concerned,
exproducts:triple12345
is
used,
a
separate
resource,
rather
than
identifying
that
part
of
the
graph.
RDF
deleted text:
reification
does
not
actually
capture
all
this
meaning.
Specifically,
RDF
syntax
by
itself
provides
no
provide
a
built-in
way
to
"connect"
an
RDF
triple
to
its
reification.
All
that
the
graph:
</p>
<div class="exampleOuter exampleInner">
<pre>
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight .
_:xxx rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 .
</pre>
</div>
<p>
actually
says
is,
"there
of
indicating
how
a
URIref
like
exproducts:triple12345
is
associated
with
a
particular
statement
that
has
or
graph,
any
more
than
it
provides
a
subject
<tt>
exproducts:item10245
</tt>,
built-in
way
of
indicating
how
a
predicate
<tt>
exterms:weight
</tt>,
and
an
object
<tt>
2.4
</tt>,
and
John
made
it".
It
does
<em>
not
</em>
say
that
that
statement
(referred
to
by
<tt>
_:xxx
</tt>
)
URIref
like
exproducts:item10245
is
the
same
as
some
particular
statement
associated
with
an
actual
tent.
Associating
specific
URIrefs
with
specific
resources
(statements
in
some
particular
RDF
document.
this
case)
must
be
done
using
mechanisms
outside
of
RDF.
To
see
this,
given
Using
rdf:ID
as
shown
in
Example
20
generates
the
original
triple:
</p>
<div class="exampleOuter exampleInner">
<pre>
exproducts:item10245 exterms:weight "2.4" .
</pre>
</div>
<p>
reification
automatically,
and
provides
a
convenient
way
of
indicating
the
following
reification
URIref
to
be
used
as
the
subject
of
it,
together
with
an
additional
triple
that
associates
John
the
statements
in
the
reification.
Moreover,
it
provides
a
partial
"hook"
relating
the
triples
in
the
reification
with
the
reification:
</p>
<div class="exampleOuter exampleInner">
<pre>
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight .
_:xxx rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 .
</pre>
</div>
<p>
note
piece
of
RDF/XML
syntax
that
caused
them
to
be
created,
since
the
value
triple12345
of
the
rdf:ID
attribute
is
used
to
generate
the
URIref
of
the
subject
of
the
reification
triples.
However,
this
relationship
is
once
again
outside
RDF,
since
there
is
nothing
in
the
resulting
triples
that
explicitly
associates
<tt>
_:xxx
</tt>
with
says
that
the
original
triple,
triple
had
the
URIref
exproducts:triple12345
(RDF
does
not
assume
there
is
any
relationship
between
a
URIref
and
hence
would
allow
you
to
say
any
RDF/XML
that
John
created
it.
it
might
have
been
used
or
abbreviated
in).
This The lack of a built-in means for assigning URIrefs to statements does not mean that deleted text: such "provenance" information of this kind cannot be expressed in RDF, just that it cannot be done using only the meaning RDF associates with the reification vocabulary. For example, if an RDF document (say, a Web page) has a URI, deleted text: you could make statements could be made about the resource identified by that URI and, based on some application-dependent understanding of how those statements should be interpreted, an application could act as if those statements "distribute" over (apply equally to) all the statements in the document. Also, if some mechanism exists (outside of RDF) to assign URIs to individual RDF statements, then you statements could certainly make statements be made about those individual statements, using their URIs to identify them. In However, in these cases, you it would also not need be strictly necessary to use the reification vocabulary at all. in the conventional way.
To see this, if our assuming the original triple statement:
exproducts:item10245 exterms:weight "2.4"^^xsd:decimal .
had
a
URI,
say
<tt>
ex:statementfoo
</tt>,
then
you
could
attribute
that
URIref
of
exproducts:triple12345
,
the
statement
could
be
attributed
to
John
Smith
simply
by
the
statement:
ex:statementfoo dc:creator exstaff:85740 . exproducts:triple12345 dc:creator exstaff:85740 .
with
no
use
of
the
reification
vocabulary.
vocabulary
(although
the
description
of
exproducts:triple12345
as
having
rdf:type
rdf:Statement
might
also
be
helpful).
In addition, deleted text: you could use the reification vocabulary could be used directly according to the intended interpretation convention described above, and have along with an application-dependent understanding as to how to associate specific triples with their reifications. However, other applications receiving this RDF would not necessarily share this application-dependent understanding, and thus would not necessarily interpret the graphs appropriately.
Finally, since It is also important to note that the relation between triples and reifications interpretation of deleted text: triples in any RDF graph or graphs need not be one-to-one, asserting a property about some resource described by a reification does described here is not deleted text: necessarily mean that the same property holds as "quotation", as found in some languages. Instead, the reification describes the relationship between a particular instance of another such resource, even if it has a triple and the same components. resources the triple refers to. The reification can be read intuitively as saying "this RDF triple talks about these things", rather than (as in quotation) "this RDF triple has this form." For example, given instance, in the following graph: reification example used in this section, the triple:
_:xxx rdf:type rdf:Statement . _:xxx rdf:subject exproducts:item10245 . _:xxx rdf:predicate exterms:weight . _:xxx rdf:object "2.4" . _:yyy rdf:type rdf:Statement . _:yyy rdf:subject exproducts:item10245 . _:yyy rdf:predicate exterms:weight . _:yyy rdf:object "2.4" . _:xxx dc:creator exstaff:85740 . exproducts:triple12345 rdf:subject exproducts:item10245 .
it
describing
the
rdf:subject
of
the
original
statement
says
that
the
subject
of
the
statement
is
the
resource
(the
tent)
identified
by
the
URIref
exproducts:item10245
.
It
does
not
follow
that:
say
that
the
subject
of
the
statement
is
the
URIref
itself
(i.e.,
a
string
beginning
with
certain
characters),
as
quotation
would
do.
In Section 2.3 </a>, we noted that the RDF deleted text: data model intrinsically supports only binary relations; that is, a statement specifies a relation between two resources. For example, the statement:
exstaff:85740 exterms:manager exstaff:62345 . exstaff:85740 exterms:manager exstaff:62345 .
states
that
the
relation
"manager"
exterms:manager
holds
between
two
employees
(presumably
one
manages
the
other).
However, in some cases we need to be able it is necessary to represent information involving higher arity relations (relations between more than two resources) in RDF. We Section 2.3 discussed one example of this in <a href="#structuredproperties"> Section 2.3 </a>, this, where the problem was to represent the relationship between John Smith and his address information, and the value of John's address was a structured value of his street, city, state, and Zip. If we had tried to write postal code. Writing this as a relation, we'd have seen relation shows that this address was is a 5-ary relation of the form:
<tt>
address(exstaff:85740,
"1501
Grant
Avenue",
"Bedford",
"Massachusetts",
"01730")
</tt>
We indicated Section 2.3 noted that we can represent such this kind of structured information can be represented in RDF by considering the aggregate thing we want to talk about be described (here, the group of components representing John's address) as a separate resource, and then making separate statements about that new resource, as in the triples:
exstaff:85740 exterms:address _:johnaddress . exstaff:85740 exterms:address _:johnaddress . _:johnaddress exterms:street "1501 Grant Avenue" . _:johnaddress exterms:street "1501 Grant Avenue" . _:johnaddress exterms:city "Bedford" . _:johnaddress exterms:city "Bedford" . _:johnaddress exterms:state "Massachusetts" . _:johnaddress exterms:state "Massachusetts" . _:johnaddress exterms:Zip "01730" . _:johnaddress exterms:postalCode "01730" .
(where
<tt>
_:johnaddress
</tt>
is
the
blank
node
identifier
of
the
blank
node
representing
John's
address.)
This
is
a
general
way
to
represent
any
n-ary
relation
in
RDF:
deleted text:
you
select
one
of
the
participants
(John
in
this
case)
to
serve
as
the
subject
of
the
original
relation
(
<tt>
address
</tt>
in
this
case).
You
case),
then
specify
an
intermediate
resource
to
represent
the
rest
of
the
relation
(either
with
or
without
assigning
it
a
URI),
deleted text:
and
then
give
that
new
resource
properties
representing
the
remaining
components
of
the
relation.
In
the
case
of
John's
address,
none
of
the
individual
parts
of
the
structured
value
could
be
considered
the
"main"
value
of
the
<tt>
exterms:address
</tt>
property;
all
of
the
parts
contribute
equally
to
the
value.
However,
in
some
cases
one
of
the
parts
of
the
structured
value
is
often
thought
of
as
the
"main"
value,
with
the
other
parts
of
the
relation
providing
additional
contextual
or
other
information
that
qualifies
the
main
value.
For
example,
instance,
in
our
tent
example
Example
9
in
Section
3.2
,
deleted text:
we
gave
the
weight
of
the
a
particular
tent
we
were
describing
was
given
as
the
plain
decimal
value
2.4
using
a
typed
literal
"2.4",
,
i.e.,
exproduct:item10245 exterms:weight "2.4" . exproduct:item10245 exterms:weight "2.4"^^xsd:decimal .
In
fact,
a
more
complete
description
of
the
weight
would
have
been
"2.4
kilograms"
2.4
kilograms
rather
than
just
"2.4".
the
decimal
value
2.4
.
To
state
this,
the
value
of
the
<tt>
exterms:weight
</tt>
property
would
need
to
have
two
components,
the
typed
literal
"2.4"
for
the
decimal
value
and
an
indication
of
the
unit
of
measure
(kilograms).
In
this
situation
the
literal
"2.4"
decimal
value
could
be
considered
the
"main"
value
of
the
<tt>
exterms:weight
</tt>
property,
because
frequently
the
value
would
be
recorded
simply
as
the
value
"2.4"
typed
literal
(as
deleted text:
we
did
in
the
triple
above),
relying
on
an
understanding
of
the
context
to
fill
in
the
unstated
units
information.
In
the
RDF
model
a
qualified
property
value
of
this
kind
is
considered
as
simply
another
kind
of
structured
value.
To
represent
this,
deleted text:
we
use
a
separate
resource
is
used
to
represent
the
structured
value
as
a
whole
(the
weight,
in
this
case),
and
to
serve
as
the
object
of
the
original
statement.
We
then
give
that
That
resource
is
then
given
properties
representing
the
individual
parts
of
the
structured
value.
In
this
case,
we
need
there
should
be
a
property
for
the
typed
literal
"2.4",
representing
the
decimal
value,
and
a
property
for
the
unit
"kilograms".
unit.
RDF
provides
a
pre-defined
<tt>
predefined
rdf:value
</tt>
property
to
describe
the
main
value
(if
there
is
one)
of
a
structured
value.
So
in
this
case,
deleted text:
we
would
give
the
typed
literal
"2.4"
could
be
given
as
the
value
of
the
<tt>
rdf:value
</tt>
property,
and
deleted text:
give
the
resource
<tt>
exunits:kilograms
</tt>
as
the
value
of
an
<tt>
exterms:units
</tt>
property
(assuming
the
resource
<tt>
exunits:kilograms
</tt>
is
defined
in
a
example.org
schema
with
the
URIref
<tt>
http://www.example.org/units/kilograms
</tt>
).
as
part
of
example.org's
vocabulary).
The
resulting
triples
would
be:
exproduct:item10245 exterms:weight _:weight10245 . exproduct:item10245 exterms:weight _:weight10245 . _:weight10245 rdf:value "2.4" . _:weight10245 rdf:value "2.4"^^xsd:decimal . _:weight10245 exterms:units exunits:kilograms . _:weight10245 exterms:units exunits:kilograms .
which can be exchanged expressed using the RDF/XML shown in <a href="#example16"> Example 16 21 :
rdf:value
</tt>
<?xml version="1.0"?> <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> xmlns:exterms="http://www.example.org/terms/"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:exterms="http://www.example.org/terms/"> deleted text: <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245"> <exterms:weight rdf:parseType="Resource"> <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245"> <rdf:value>2.4</rdf:value> <exterms:weight rdf:parseType="Resource"> <exterms:units rdf:resource="http://www.example.org/units/kilograms" /> <rdf:value rdf:datatype="&xsd;decimal">2.4</rdf:value> </exterms:weight> <exterms:units rdf:resource="http://www.example.org/units/kilograms"/> </rdf:Description> </exterms:weight> </rdf:Description> </rdf:RDF> </rdf:RDF>
Example
16
21
uses
some
additional
RDF/XML
abbreviations
that
were
not
discussed
also
illustrates
a
second
use
of
the
rdf:parseType
attribute
introduced
in
<a href="#rdfxml">
Section
3
4.2
,
but
in
this
case,
rdf:parseType="Resource"
.
An
rdf:parseType="Resource"
attribute
is
used
to
indicate
that
the
contents
of
an
element
are
described
to
be
interpreted
as
the
description
of
a
new
(blank
node)
resource,
without
actually
having
to
write
a
nested
rdf:Description
element.
In
this
case,
the
rdf:parseType="Resource"
attribute
used
in
the
exterms:weight
property
element
indicates
that
a
blank
node
is
to
be
created
as
the
value
of
the
exterms:weight
property,
and
that
the
enclosed
elements
(
rdf:value
and
exterms:units
)
describe
properties
of
that
blank
node.
Further
details
on
rdf:parseType="Resource"
are
given
in
[RDF-SYNTAX]
</a>.)
.
The
same
approach
can
be
used
to
represent
quantities
using
any
units
of
measure,
as
well
as
values
taken
from
different
classification
schemes
or
rating
systems,
by
using
the
<tt>
rdf:value
</tt>
property
to
give
the
main
value,
and
using
additional
properties
to
identify
the
classification
scheme
or
other
information
that
further
describes
the
value.
You
There
is
no
need
not
to
use
<tt>
rdf:value
</tt>
for
these
purposes
(e.g.,
you
could
assign
your
own
a
user-defined
property
name,
such
as
<tt>
ex:amount
</tt>,
exterms:amount
,
could
have
been
used
instead
of
rdf:value
in
the
example
above),
Example
21
),
and
RDF
does
not
associate
any
particular
special
meaning
with
it.
<tt>
rdf:value
</tt>
.
rdf:value
is
simply
provided
as
a
convenience
for
use
in
these
commonly-occurring
situations.
Sometimes the value of a property needs to be a fragment of XML, or text that might contain XML markup. For example, a publisher might maintain RDF metadata that includes the titles of books and articles. While such titles are often just simple strings of characters, this is not always the case. For instance, the titles of books on mathematics may contain mathematical formulas that could be represented using MathML [MATHML] . Titles might also include markup for other reasons, such as for Ruby annotations [RUBY] , or for bidirectional rendering or special glyph variants (see, e.g., [CHARMOD] ).
RDF/XML
provides
a
special
notation
to
make
it
easy
to
write
literals
of
this
kind.
This
is
done
using
a
third
value
of
the
rdf:parseType
attribute.
Giving
an
element
the
attribute
rdf:parseType="Literal"
indicates
that
the
contents
of
the
element
are
to
be
interpreted
as
an
XML
fragment.
Example
22
illustrates
the
use
of
rdf:parseType="Literal"
:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xml:base="http://www.example.com/books">
<rdf:Description rdf:ID="book12345">
<dc:title rdf:parseType="Literal">
<span xml:lang="en">
The <em><br /></em> Element Considered Harmful.
</span>
</dc:title>
</rdf:Description>
</rdf:RDF>
The
RDF/XML
in
Example
22
describes
a
graph
containing
a
single
triple
with
subject
ex:book12345
,
and
predicate
dc:title
.
The
rdf:parseType="Literal"
attribute
in
the
RDF/XML
indicates
that
all
the
XML
within
the
<dc:title>
element
is
an
XML
fragment
that
is
the
value
of
the
dc:title
property.
In
the
graph,
this
value
is
a
typed
literal,
whose
datatype,
rdf:XMLLiteral
,
is
defined
in
[RDF-CONCEPTS]
specifically
to
represent
fragments
of
XML
(including
character
sequences
that
may
or
may
not
include
XML
markup).
The
XML
fragment
is
canonicalized
according
to
the
XML
Exclusive
Canonicalization
recommendation
[XML-XC14N]
.
This
causes
declarations
of
used
namespaces
to
be
added
to
the
fragment,
the
escaping
of
reserved
characters
such
as
"
<
",
"
>
",
and
"
&
",
the
expansion
of
empty-element
tags,
and
other
transformations.
(For
these
reasons,
and
the
fact
that
the
triples
notation
itself
requires
further
escaping,
the
actual
typed
literal
is
not
shown
here.
RDF/XML
provides
the
rdf:parseType="Literal"
attribute
so
that
RDF
users
will
not
have
to
deal
directly
with
these
transformations.
Those
interested
in
the
details
should
consult
[RDF-CONCEPTS]
and
[RDF-SYNTAX]
.)
Contextual
attributes,
such
as
xml:lang
and
xml:base
are
not
inherited
from
the
RDF/XML
document,
and,
if
required,
must,
as
shown
in
the
example,
be
explicitly
specified
in
the
XML
fragment.
This
example
illustrates
that
care
must
be
taken
in
designing
RDF
data.
It
might
appear
at
first
glance
that
titles
are
simple
strings
best
represented
as
plain
literals,
and
only
later
might
it
be
discovered
that
some
titles
contain
markup.
In
cases
where
the
value
of
a
property
may
sometimes
contain
markup
and
sometimes
not,
either
rdf:parseType="Literal"
should
be
used
throughout,
or
software
must
handle
both
plain
literals
and
literals
of
type
rdf:XMLLiteral
as
values
of
the
property.
RDF
provides
a
way
to
express
simple
statements
about
resources,
using
named
properties
and
values.
However,
RDF
user
communities
also
need
the
ability
to
define
the
vocabularies
(terms)
they
intend
to
use
in
those
statements,
specifically,
to
indicate
that
they
are
describing
specific
kinds
or
classes
of
resources,
and
will
use
specific
properties
in
describing
those
resources.
For
example,
the
company
example.com
from
our
the
examples
in
Section
3.2
would
want
to
describe
classes
such
as
<tt>
exterms:Tent
</tt>,
,
and
use
properties
such
as
<tt>
exterms:model
</tt>,
<tt>
,
exterms:weightInKg
</tt>,
,
and
<tt>
exterms:packedSize
</tt>
to
describe
them
(we
use
QNames
(QNames
with
various
"example"
namespace
prefixes
are
used
as
the
names
of
classes
and
properties
here
as
a
reminder
that
in
RDF
these
names
are
actually
URI
references
,
as
discussed
in
Section
2.1
).
Similarly,
people
interested
in
describing
bibliographic
resources
would
want
to
describe
classes
such
as
<tt>
ex2:Book
</tt>
or
<tt>
ex2:MagazineArticle
</tt>,
,
and
use
properties
such
as
<tt>
ex2:author
</tt>,
<tt>
,
ex2:title
</tt>,
,
and
<tt>
ex2:subject
</tt>
to
describe
them.
Other
applications
might
need
to
describe
classes
such
as
<tt>
ex3:Person
</tt>
and
<tt>
ex3:Company
</tt>,
,
and
properties
such
as
<tt>
ex3:age
</tt>,
<tt>
,
ex3:jobTitle
</tt>,
<tt>
,
ex3:stockSymbol
</tt>,
,
and
<tt>
ex3:numberOfEmployees
</tt>.
.
RDF
itself
provides
no
vocabulary
means
for
specifying
these
things.
defining
such
application-specific
classes
and
properties.
Instead,
such
classes
and
properties
are
described
in
as
an
RDF
<em>
vocabulary
</em>.
The
facilities
for
describing
vocabulary,
using
extensions
to
RDF
vocabularies
are
specified
in
provided
by
the
RDF
Vocabulary
Description
Language
1.0:
RDF
Schema
[RDF-VOCABULARY]
</a>.
,
referred
to
here
as
RDF
Schema
.
RDF
Schema
does
not
provide
a
deleted text:
specific
vocabulary
of
application-oriented
application-specific
classes
like
<tt>
exterms:Tent
</tt>,
<tt>
,
ex2:Book
</tt>,
,
or
<tt>
ex3:Person
</tt>,
,
and
properties
like
<tt>
exterms:weightInKg
</tt>,
<tt>
,
ex2:author
</tt>
or
<tt>
ex3:JobTitle
</tt>.
.
Instead,
it
provides
the
mechanisms
facilities
needed
to
specify
describe
such
classes
and
properties
as
part
of
a
vocabulary,
properties,
and
to
indicate
which
classes
and
properties
are
expected
to
be
used
together
(for
example,
you
might
expect
to
say
that
the
property
<tt>
ex3:jobTitle
</tt>
to
will
be
used
in
describing
a
<tt>
ex3:Person
</tt>
).
In
other
words,
RDF
Schema
provides
a
type
system
for
RDF.
The
RDF
Schema
type
system
is
similar
in
some
respects
to
the
type
systems
of
object-oriented
programming
languages
such
as
Java.
For
example,
RDF
Schema
allows
resources
to
be
defined
as
instances
of
one
or
more
classes
.
In
addition,
it
allows
classes
to
be
organized
in
a
hierarchical
fashion;
for
example
a
class
<tt>
ex:Dog
</tt>
might
be
defined
as
a
subclass
of
<tt>
ex:Mammal
</tt>
which
is
a
subclass
of
<tt>
ex:Animal
</tt>,
,
meaning
that
any
resource
which
is
in
class
<tt>
ex:Dog
</tt>
is
also
considered
to
be
implicitly
in
class
<tt>
ex:Animal
</tt>.
as
well.
However,
RDF
classes
and
properties
are
in
some
respects
very
different
from
programming
language
types.
RDF
class
and
property
descriptions
do
not
create
a
straightjacket
into
which
information
must
be
forced,
but
instead
provide
additional
information
about
the
RDF
resources
they
describe.
This
information
can
be
used
in
a
variety
of
ways.
We
ways,
which
will
say
more
about
this
point
be
discussed
in
Section
5.3
.
The
RDF
Schema
uses
RDF
itself
to
specify
facilities
are
themselves
provided
in
the
form
of
an
RDF
type
system,
by
providing
vocabulary;
that
is,
as
a
specialized
set
of
pre-defined
predefined
RDF
resources
deleted text:
and
properties,
together
with
their
meanings,
that
can
be
used
to
describe
user-specific
classes
and
properties.
These
additional
RDF
Schema
own
special
meanings.
The
resources
extend
in
the
RDF
to
include
a
larger
reserved
Schema
vocabulary
have
URIrefs
with
the
prefix
http://www.w3.org/2000/01/rdf-schema#
(conventionally
associated
with
the
QName
prefix
rdfs:
).
Vocabulary
descriptions
(schemas)
written
in
the
RDF
Schema
language
are
legal
RDF
graphs.
Hence,
RDF
software
that
is
not
written
to
also
process
the
additional
deleted text:
meaning.
The
RDF
Schema
deleted text:
(RDFS)
vocabulary
is
defined
in
can
still
interpret
a
namespace
identified
by
schema
as
a
legal
RDF
graph
consisting
of
various
resources
and
properties,
but
will
not
"understand"
the
URI
reference
<tt>
http://www.w3.org/2000/01/rdf-schema#"
</tt>
(in
additional
built-in
meanings
of
the
examples,
we
will
use
RDF
Schema
terms.
To
understand
these
additional
meanings,
RDF
software
must
be
written
to
process
an
extended
language
that
includes
not
only
the
prefix
<tt>
rdf:
vocabulary,
but
also
the
rdfs:
</tt>
to
refer
to
this
namespace).
We
vocabulary,
together
with
their
built-in
meanings.
This
point
will
be
illustrated
in
the
next
section.
The following sections will illustrate RDF Schema's basic resources and properties in the following sections. properties.
A
basic
step
in
any
kind
of
description
process
is
identifying
the
various
kinds
of
things
to
be
described.
RDF
Schema
refers
to
these
"kinds
of
things"
as
classes
.
A
class
in
RDF
Schema
corresponds
to
the
generic
concept
of
a
Type
or
Category
,
somewhat
like
the
notion
of
a
class
in
object-oriented
programming
languages
such
as
Java.
RDF
classes
can
be
used
to
represent
almost
any
category
of
thing,
such
as
web
Web
pages,
people,
document
types,
databases
or
abstract
concepts.
Classes
are
described
using
the
RDFS-defined
RDF
Schema
resources
<tt>
rdfs:Class
</tt>
and
<tt>
rdfs:Resource
</tt>,
,
and
the
properties
<tt>
rdf:type
</tt>
and
<tt>
rdfs:subClassOf
</tt>.
.
For
example,
suppose
we
an
organization
example.org
wanted
to
use
RDF
to
provide
information
about
different
kinds
of
motor
vehicles.
In
RDF
Schema,
we
example.org
would
first
need
a
class
to
represent
the
category
of
things
that
are
motor
vehicles.
The
resources
that
belong
to
a
class
are
called
its
instances
.
In
this
case,
we
intend
example.org
intends
for
the
instances
of
our
this
class
to
be
resources
that
are
motor
vehicles.
In
RDF
Schema,
a
class
is
any
resource
having
an
<tt>
rdf:type
</tt>
property
whose
value
is
the
deleted text:
RDFS-defined
resource
<tt>
rdfs:Class
</tt>.
.
So
our
the
motor
vehicle
class
would
be
described
by
assigning
the
class
a
URIref,
say
<tt>
ex:MotorVehicle
</tt>
(using
<tt>
(
using
ex:
</tt>
to
stand
for
the
deleted text:
namespace
URIref
<tt>
http://www.example.org/schemas/vehicles
</tt>,
we
will
use
in
this
example)
,
which
is
used
as
the
prefix
for
URIrefs
from
example.org's
vocabulary
)
and
describing
that
resource
with
an
<tt>
rdf:type
</tt>
property
whose
value
is
the
deleted text:
RDFS-defined
resource
<tt>
rdfs:Class
</tt>.
.
That
is,
we
example.org
would
write
the
RDF
statement:
ex:MotorVehicle rdf:type rdfs:Class . ex:MotorVehicle rdf:type rdfs:Class .
As
deleted text:
we
indicated
in
Section
3.2
,
the
property
<tt>
rdf:type
</tt>
is
used
to
indicate
that
a
resource
is
an
instance
of
a
class.
So,
having
described
<tt>
ex:MotorVehicle
</tt>
as
a
class,
deleted text:
if
we
wanted
to
describe
a
resource
<tt>
ex:companyCar
</tt>
exthings:companyCar
would
be
described
as
deleted text:
being
a
motor
vehicle,
we
would
write
vehicle
by
the
RDF
statement:
ex:companyCar rdf:type ex:MotorVehicle . exthings:companyCar rdf:type ex:MotorVehicle .
(We
are
using
(This
statement
uses
a
frequently-used
common
convention
that
class
names
are
written
with
an
initial
uppercase
letter,
while
property
and
instance
names
are
written
with
an
initial
lowercase
letter.
However,
this
convention
is
not
required
in
RDFS)
RDF
Schema.
The
statement
also
assumes
that
example.org
has
decided
to
define
separate
vocabularies
for
classes
of
things,
and
instances
of
things.)
The
resource
<tt>
rdfs:Class
</tt>
itself
has
an
<tt>
rdf:type
</tt>
of
<tt>
rdfs:Class
</tt>.
.
A
resource
may
be
an
instance
of
more
than
one
class.
After
describing
class
<tt>
ex:MotorVehicle
</tt>,
we
,
example.org
might
want
to
describe
additional
classes
representing
various
specialized
kinds
of
motor
vehicle,
e.g.,
passenger
vehicles,
vans,
minivans,
and
so
on.
We
can
describe
these
These
classes
can
be
described
in
the
same
way
as
deleted text:
we
described
class
<tt>
ex:MotorVehicle
</tt>,
,
by
assigning
a
URIref
for
each
new
class,
and
writing
RDF
statements
describing
these
resources
as
classes,
e.g.,
writing:
ex:Van rdf:type rdfs:Class . ex:Van rdf:type rdfs:Class . ex:Truck rdf:type rdfs:Class . ex:Truck rdf:type rdfs:Class .
and
so
on.
However,
we
want
to
do
more
than
just
these
statements
by
themselves
only
describe
the
individual
classes;
we
classes.
example.org
may
also
want
to
indicate
their
special
relationship
to
class
<tt>
ex:MotorVehicle
</tt>,
,
i.e.,
that
they
are
specialized
kinds
of
MotorVehicle.
deleted text:
To
do
this,
we
use
the
RDFS
concept
of
<em>
subclass
</em>.
An
RDF
subclass
represents
a
subset/superset
This
kind
of
specialization
relationship
between
two
classes.
We
describe
this
relationship
classes
is
described
using
the
pre-defined
<tt>
predefined
rdfs:subClassOf
</tt>
property
to
relate
the
two
classes.
For
example,
to
state
that
<tt>
ex:Van
</tt>
is
a
subclass
specialized
kind
of
<tt>
ex:MotorVehicle
</tt>,
we
,
example.org
would
write
the
RDF
statement:
ex:Van rdfs:subClassOf ex:MotorVehicle . ex:Van rdfs:subClassOf ex:MotorVehicle .
The
meaning
of
the
<tt>
this
rdfs:subClassOf
</tt>
relationship
is
that
any
instance
of
class
ex:Van
is
also
an
instance
of
class
ex:MotorVehicle
.
So
if
resource
<tt>
ex:companyVan
</tt>
exthings:companyVan
is
an
instance
of
<tt>
ex:Van
</tt>,
then
<tt>
ex:companyVan
</tt>
then,
based
on
the
declared
rdfs:subClassOf
relationship,
RDF
software
written
to
understand
the
RDF
Schema
vocabulary
can
infer
the
additional
information
that
exthings:companyVan
is
also
deleted text:
implicitly
considered
an
instance
of
<tt>
ex:Motorvehicle
</tt>
(that
is,
you
can
"infer"
or
act
ex:MotorVehicle
.
This
example
of
exthings:companyVan
illustrates
the
point
made
earlier
about
RDF
Schema
defining
an
extended
language.
RDF
itself
does
not
define
the
special
meaning
of
terms
from
the
RDF
Schema
vocabulary
such
as
rdfs:subClassOf
.
So
if
<tt>
ex:companyVan
</tt>
an
RDF
schema
defines
this
rdfs:subClassOf
relationship
between
ex:Van
and
ex:MotorVehicle
,
RDF
software
not
written
to
understand
the
RDF
Schema
terms
would
recognize
this
as
a
triple,
with
predicate
rdfs:subClassOf
,
but
it
would
not
understand
the
special
significance
of
rdfs:subClassOf
,
and
not
be
able
to
draw
the
additional
inference
that
exthings:companyVan
is
also
an
instance
of
<tt>
ex:MotorVehicle
</tt>
even
if
this
is
not
explicitly
stated).
.
The
<tt>
rdfs:subClassOf
</tt>
property
is
transitive
.
This
means,
for
example,
that
if
we
have
given
the
RDF
statements:
ex:Van rdfs:subClassOf ex:MotorVehicle . ex:Van rdfs:subClassOf ex:MotorVehicle . ex:MiniVan rdfs:subClassOf ex:Van . ex:MiniVan rdfs:subClassOf ex:Van .
RDF
Schema
defines
ex:MiniVan
</tt>
is
as
also
implicitly
being
a
subclass
of
<tt>
ex:Motorvehicle
</tt>.
ex:MotorVehicle
.
As
a
result,
RDF
Schema
defines
resources
that
are
instances
of
class
<tt>
ex:MiniVan
</tt>
are
as
also
considered
being
instances
of
class
<tt>
ex:Motorvehicle
</tt>
ex:MotorVehicle
(as
well
as
being
instances
of
class
<tt>
ex:Van
</tt>
).
A
class
may
be
a
subclass
of
more
than
one
class
(for
example,
<tt>
ex:MiniVan
</tt>
may
be
a
subclass
of
both
<tt>
ex:Van
</tt>
and
<tt>
ex:PassengerVehicle
</tt>
).
All
RDF
Schema
defines
all
classes
are
implicitly
as
subclasses
of
class
<tt>
rdfs:Resource
</tt>
(since
the
instances
belonging
to
all
classes
are
resources).
<a href="#figure17"> Figure 17 18 shows the full class hierarchy we have been discussing. being discussed in these examples.
(To
simplify
the
figure,
the
rdf:type
properties
relating
each
of
the
classes
to
rdfs:Class
are
omitted
in
Figure
18
.
In
fact,
RDF
Schema
defines
both
the
subjects
and
objects
of
statements
that
use
the
rdfs:subClassOf
property
to
be
resources
of
type
rdfs:Class
,
so
this
information
could
be
inferred.
However,
in
actually
writing
schemas,
it
is
good
practice
to
explicitly
provide
this
information.)
This schema could also be described by the triples:
ex:MotorVehicle rdf:type rdfs:Class . ex:MotorVehicle rdf:type rdfs:Class . ex:PassengerVehicle rdf:type rdfs:Class . ex:PassengerVehicle rdf:type rdfs:Class . ex:Van rdf:type rdfs:Class . ex:Van rdf:type rdfs:Class . ex:Truck rdf:type rdfs:Class . ex:Truck rdf:type rdfs:Class . ex:MiniVan rdf:type rdfs:Class . ex:MiniVan rdf:type rdfs:Class . ex:PassengerVehicle rdfs:subClassOf ex:MotorVehicle . ex:PassengerVehicle rdfs:subClassOf ex:MotorVehicle . ex:Van rdfs:subClassOf ex:MotorVehicle . ex:Van rdfs:subClassOf ex:MotorVehicle . ex:Truck rdfs:subClassOf ex:MotorVehicle . ex:Truck rdfs:subClassOf ex:MotorVehicle . ex:MiniVan rdfs:subClassOf ex:Van . ex:MiniVan rdfs:subClassOf ex:Van . ex:MiniVan rdfs:subClassOf ex:PassengerVehicle . ex:MiniVan rdfs:subClassOf ex:PassengerVehicle .
<a href="#example1"> Example 17 23 shows how this schema could be written in RDF/XML.
<?xml version="1.0"?> <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://example.org/schemas/vehicles"> <rdf:Description rdf:ID="MotorVehicle"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> </rdf:Description> <rdf:Description rdf:ID="PassengerVehicle"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdf:Description> <rdf:Description rdf:ID="Truck"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdf:Description> <rdf:Description rdf:ID="Van"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdf:Description> <rdf:Description rdf:ID="MiniVan"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:subClassOf rdf:resource="#Van"/> <rdfs:subClassOf rdf:resource="#PassengerVehicle"/> </rdf:Description> </rdf:RDF>
This
As
discussed
in
Section
3.2
in
connection
with
Example
13
,
RDF/XML
provides
an
abbreviation
for
describing
resources
having
an
rdf:type
property
(
typed
nodes
).
Since
RDF
Schema
classes
are
RDF
resources,
this
abbreviation
can
be
applied
to
the
description
of
classes.
Using
this
abbreviation,
the
schema
could
also
be
described
as
shown
in
Example
24
:
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base="http://example.org/schemas/vehicles">
<rdfs:Class rdf:ID="MotorVehicle"/>
<rdfs:Class rdf:ID="PassengerVehicle">
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Truck">
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Van">
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>
<rdfs:Class rdf:ID="MiniVan">
<rdfs:subClassOf rdf:resource="#Van"/>
<rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdfs:Class>
</rdf:RDF>
Similar typed node abbreviations will be used throughout the rest of this section.
The
RDF/XML
in
Example
23
and
Example
24
introduces
names,
such
as
<tt>
MotorVehicle
</tt>,
,
for
the
resources
(classes)
that
it
describes
using
<tt>
rdf:ID
</tt>,
,
to
give
the
effect
of
"assigning"
URIrefs
relative
to
the
schema
document
as
deleted text:
we
described
in
Section
3.2
.
rdf:ID
is
useful
here
because
it
both
abbreviates
the
URIrefs,
and
also
provides
an
additional
check
that
the
value
of
the
rdf:ID
attribute
is
unique
against
the
current
base
URI
(usually
the
document
URI).
This
helps
pick
up
repeated
rdf:ID
values
when
defining
the
names
of
classes
and
properties
in
RDF
schemas.
Relative
URIrefs
based
on
these
names
can
then
be
used
in
other
class
definitions
within
the
same
schema
(e.g.,
as
we
used
<tt>
#MotorVehicle
</tt>
is
used
in
the
description
of
the
other
classes).
The
full
URIref
of
this
class,
assuming
that
the
schema
itself
was
the
resource
<tt>
http://example.org/schemas/vehicles
</tt>,
,
would
be
<tt>
http://example.org/schemas/vehicles#MotorVehicle
</tt>
(as
shown
(shown
in
<a href="#figure17">
Figure
17
18
).
As
noted
in
Section
3.2
,
to
ensure
that
the
references
to
these
schema
classes
would
be
consistently
maintained
even
if
the
schema
were
relocated
or
copied
(or
to
simply
assign
a
base
URIref
for
the
schema
classes
without
assuming
they
are
all
published
at
a
single
location),
the
class
descriptions
could
also
include
an
explicit
<tt>
xml:base="http://example.org/schemas/vehicles"
</tt>
declaration.
Use
of
an
explicit
xml:base
declaration
is
considered
good
practice,
and
one
is
provided
in
both
examples.
To
refer
to
these
classes
in
RDF
instance
data
(e.g.,
data
describing
individual
vehicles
of
these
classes)
located
elsewhere,
we
example.org
would
need
to
use
identify
the
full
classes
either
by
writing
absolute
URIrefs,
by
using
relative
URIrefs
together
with
an
appropriate
xml:base
declaration,
or
by
using
QNames
together
with
an
appropriate
namespace
declaration
that
allows
the
QNames
to
be
expanded
to
deleted text:
identify
the
classes.
proper
URIrefs.
For
example,
deleted text:
to
describe
the
resource
<tt>
ex2:companyCar
</tt>
exthings:companyCar
could
be
described
as
an
instance
of
the
class
<tt>
ex:MotorVehicle
</tt>
described
in
this
schema,
we
could
use
the
schema
of
Example
24
by
the
RDF/XML
shown
in
<a href="#example18">
Example
18
</a>:
25
:
ex:MotorVehicle
</tt>
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/schemas/vehicles"> xmlns:ex="http://example.org/schemas/vehicles#" xml:base="http://example.org/things"> deleted text: <rdf:Description rdf:ID="companyCar"> deleted text: <rdf:type rdf:resource="http://example.org/schemas/vehicles#MotorVehicle"/> </rdf:Description> <ex:MotorVehicle rdf:ID="companyCar"/> </rdf:RDF>
Note
that
the
QName
ex:MotorVehicle
,
when
expanded
using
the
namespace
declaration
xmlns:ex="http://example.org/schemas/vehicles#"
,
becomes
the
full
URIref
http://example.org/schemas/vehicles#MotorVehicle
,
which
is
the
correct
URIref
for
the
MotorVehicle
class
as
shown
in
Figure
18
.
The
xml:base
declaration
xml:base="http://example.org/things"
is
provided
to
allow
the
rdf:ID="companyCar"
to
expand
to
the
proper
exthings:companyCar
URIref
(since
a
QName
cannot
be
used
as
the
value
of
the
rdf:ID
attribute).
In
addition
to
describing
the
specific
classes
of
things
they
want
to
describe,
user
communities
also
need
to
be
able
to
describe
specific
properties
that
characterize
those
classes
of
things
(such
as
<tt>
rearSeatLegRoom
</tt>
to
describe
a
passenger
vehicle).
In
RDF
Schema,
properties
are
described
using
the
RDF-defined
RDF
class
<tt>
rdf:Property
</tt>,
,
and
the
RDFS-defined
RDF
Schema
properties
<tt>
rdfs:domain
</tt>,
<tt>
,
rdfs:range
</tt>,
,
and
<tt>
rdfs:subPropertyOf
</tt>.
.
All
properties
in
RDF
are
described
as
instances
of
class
<tt>
rdf:Property
</tt>.
.
So
a
new
property,
such
as
<tt>
exterms:weightInKg
</tt>,
,
is
described
by
assigning
the
property
a
URIref,
and
describing
that
resource
with
an
<tt>
rdf:type
</tt>
property
whose
value
is
the
resource
<tt>
rdf:Property
</tt>.
That
is,
we
would
write
,
for
example,
by
writing
the
RDF
statement:
exterms:weightInKg rdf:type rdf:Property . exterms:weightInKg rdf:type rdf:Property .
RDF
Schema
also
provides
vocabulary
for
describing
how
properties
and
classes
are
intended
to
be
used
together
in
RDF
data.
The
most
important
information
of
this
kind
is
supplied
by
using
the
RDFS-defined
RDF
Schema
properties
<tt>
rdfs:range
</tt>
and
<tt>
rdfs:domain
</tt>
to
further
describe
application-specific
properties.
The
<tt>
rdfs:range
</tt>
property
is
used
to
indicate
that
the
values
of
a
particular
property
are
instances
of
a
designated
class.
For
example,
if
we
example.org
wanted
to
indicate
that
the
property
<tt>
ex:author
</tt>
had
values
that
are
instances
of
class
<tt>
ex:Person
</tt>,
we
,
it
would
write
the
RDF
statements:
ex:Person rdf:type rdfs:Class . ex:Person rdf:type rdfs:Class . ex:author rdf:type rdf:Property . ex:author rdf:type rdf:Property . ex:author rdfs:range ex:Person . ex:author rdfs:range ex:Person .
These
statements
indicate
that
<tt>
ex:Person
</tt>
is
a
class,
<tt>
ex:author
</tt>
is
a
property,
and
that
RDF
statements
using
the
<tt>
ex:author
</tt>
property
have
instances
of
<tt>
ex:Person
</tt>
as
objects.
A
property,
say
<tt>
ex:hasMother
</tt>,
,
can
have
zero,
one,
or
more
than
one
range
property.
If
<tt>
ex:hasMother
</tt>
has
no
range
property,
then
deleted text:
we
are
saying
nothing
is
said
about
the
values
of
the
<tt>
ex:hasMother
</tt>
property.
If
<tt>
ex:hasMother
</tt>
has
one
range
property,
say
one
specifying
<tt>
ex:Person
</tt>
as
the
range,
this
says
that
the
values
of
the
<tt>
ex:hasMother
</tt>
property
are
instances
of
class
<tt>
ex:Person
</tt>.
.
If
<tt>
ex:hasMother
</tt>
has
more
than
one
range
property,
say
one
specifying
<tt>
ex:Person
</tt>
as
its
range,
and
another
specifying
<tt>
ex:Female
</tt>
as
its
range,
this
says
that
the
values
of
the
<tt>
ex:hasMother
</tt>
property
are
resources
that
are
instances
of
all
of
the
classes
specified
as
the
ranges,
i.e.,
that
any
value
of
<tt>
ex:hasMother
</tt>
is
both
a
<tt>
ex:Female
</tt>
and
a
<tt>
ex:Person
</tt>.
.
This
last
point
may
not
be
obvious.
However,
stating
that
the
property
ex:hasMother
has
the
two
ranges
ex:Female
and
ex:Person
involves
making
two
separate
statements:
ex:hasMother rdfs:range ex:Female .
ex:hasMother rdfs:range ex:Person .
For any given statement using this property, say:
exstaff:frank ex:hasMother exstaff:frances .
in
order
for
both
the
rdfs:range
statements
to
be
correct,
it
must
be
the
case
that
exstaff:frances
is
both
an
instance
of
ex:Female
and
of
ex:Person
.
The
<tt>
rdfs:range
</tt>
property
can
also
be
used
to
indicate
that
the
value
of
a
property
is
given
by
a
typed
literal,
as
discussed
in
Section
2.4
.
For
example,
if
we
example.org
wanted
to
indicate
that
the
property
<tt>
ex:age
</tt>
had
values
from
the
XML
Schema
datatype
<tt>
xsd:integer
</tt>,
we
,
it
would
write
the
RDF
statement:
statements:
ex:age rdf:type rdf:Property . ex:age rdf:type rdf:Property . ex:age rdfs:range xsd:integer . ex:age rdfs:range xsd:integer .
The
datatype
<tt>
xsd:integer
</tt>
is
identified
by
its
URIref
(the
full
URIref
being
<tt>
http://www.w3.org/2001/XMLSchema#integer
</tt>
).
This
URIref
can
be
used
without
explicitly
stating
in
the
RDF
Schema
schema
that
it
identifies
a
datatype.
However,
it
is
often
useful
to
explicitly
state
that
a
given
URIref
identifies
a
datatype.
This
can
be
done
using
the
RDFS-defined
RDF
Schema
class
<tt>
rdfs:Datatype
</tt>.
.
To
state
that
<tt>
xsd:integer
</tt>
is
a
datatype,
we
example.org
would
write
the
RDF
statement:
xsd:integer rdf:type rdfs:Datatype . xsd:integer rdf:type rdfs:Datatype .
This
statement
says
that
<tt>
xsd:integer
</tt>
is
the
URIref
of
a
datatype
(which
is
assumed
to
conform
to
the
requirements
for
RDF
datatypes
described
in
[RDF-CONCEPTS]
).
Such
a
statement
does
not
constitute
a
definition
of
a
datatype,
e.g.,
in
the
sense
that
we
are
example.org
is
defining
a
new
datatype.
There
is
no
way
to
define
datatypes
in
RDFS.
RDF
Schema.
As
noted
in
Section
2.4
,
datatypes
are
defined
externally
to
RDFS,
RDF
(and
to
RDF
Schema),
and
referred
to
in
RDF
statements
by
their
URIrefs.
What
this
This
statement
does
is
simply
serves
to
document
the
existence
of
the
datatype,
and
indicates
indicate
explicitly
that
it
is
being
used
in
this
schema.
The
<tt>
rdfs:domain
</tt>
property
is
used
to
indicate
that
a
particular
property
applies
to
a
designated
class.
For
example,
if
we
example.org
wanted
to
indicate
that
the
property
<tt>
ex:author
</tt>
applies
to
instances
of
class
<tt>
ex:Book
</tt>,
we
,
it
would
write
the
RDF
statements:
ex:Book rdf:type rdfs:Class . ex:Book rdf:type rdfs:Class . ex:author rdf:type rdf:Property . ex:author rdf:type rdf:Property . ex:author rdfs:domain ex:Book . ex:author rdfs:domain ex:Book .
These
statements
indicate
that
<tt>
ex:Person
</tt>
ex:Book
is
a
class,
<tt>
ex:author
</tt>
is
a
property,
and
that
RDF
statements
using
the
<tt>
ex:author
</tt>
property
have
instances
of
<tt>
ex:Book
</tt>
as
subjects.
A
given
property,
say
<tt>
exterms:weight
</tt>,
,
may
have
zero,
one,
or
more
than
one
domain
property.
If
<tt>
exterms:weight
</tt>
has
no
domain
property,
then
deleted text:
we
are
saying
nothing
is
said
about
the
resources
that
<tt>
exterms:weight
</tt>
properties
may
be
used
with
(any
resource
could
have
a
<tt>
exterms:weight
</tt>
property).
If
<tt>
exterms:weight
</tt>
has
one
domain
property,
say
one
specifying
<tt>
ex:Book
</tt>
as
the
domain,
this
says
that
the
<tt>
exterms:weight
</tt>
property
applies
to
instances
of
class
<tt>
ex:Book
</tt>.
.
If
<tt>
exterms:weight
</tt>
has
more
than
one
domain
property,
say
one
specifying
<tt>
ex:Book
</tt>
as
the
domain
and
another
one
specifying
<tt>
ex:MotorVehicle
</tt>
as
the
domain,
this
says
that
any
resource
that
has
a
<tt>
exterms:weight
</tt>
property
is
an
instance
of
all
of
the
classes
specified
as
the
domains,
i.e.,
that
any
resource
that
has
a
<tt>
exterms:weight
</tt>
property
is
both
a
<tt>
ex:Book
</tt>
and
a
<tt>
ex:MotorVehicle
</tt>
(illustrating
the
need
for
care
in
specifying
domains
and
ranges).
We
can
illustrate
As
in
the
case
of
rdfs:range
,
this
last
point
may
not
be
obvious.
However,
stating
that
the
property
exterms:weight
has
the
two
domains
ex:Book
and
ex:MotorVehicle
involves
making
two
separate
statements:
exterms:weight rdfs:domain ex:Book .
exterms:weight rdfs:domain ex:MotorVehicle .
For any given statement using this property, say:
exthings:companyCar exterms:weight "2500"^^xsd:integer .
in
order
for
both
the
rdfs:domain
statements
to
be
correct,
it
must
be
the
case
that
exthings:companyCar
is
both
an
instance
of
ex:Book
and
of
ex:MotorVehicle
.
The
use
of
these
range
and
domain
descriptions
can
be
illustrated
by
extending
our
the
vehicle
schema,
adding
two
properties
<tt>
ex:registeredTo
</tt>
and
<tt>
ex:rearSeatLegRoom
</tt>,
,
a
new
class
<tt>
ex:Person
</tt>,
,
and
explicitly
describing
the
datatype
<tt>
xsd:integer
</tt>
as
a
datatype.
The
<tt>
ex:registeredTo
</tt>
property
applies
to
any
<tt>
ex:MotorVehicle
</tt>
and
its
value
is
a
<tt>
ex:Person
</tt>.
.
For
the
sake
of
this
example,
<tt>
ex:rearSeatLegRoom
</tt>
applies
only
to
instances
of
class
<tt>
ex:PassengerVehicle
</tt>.
.
The
value
is
an
<tt>
xsd:integer
</tt>
giving
the
number
of
centimeters
of
rear
seat
legroom.
These
descriptions
are
shown
in
<a href="#example19">
Example
19
26
:
<rdf:Description rdf:ID="registeredTo"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="registeredTo"> <rdfs:domain rdf:resource="#MotorVehicle"/> <rdfs:range rdf:resource="#Person"/> </rdf:Description> </rdf:Property> deleted text: <rdf:Description rdf:ID="rearSeatLegRoom"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="rearSeatLegRoom"> <rdfs:domain rdf:resource="#PassengerVehicle"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/> </rdf:Description> <rdfs:range rdf:resource="&xsd;integer"/> <rdf:Description rdf:ID="Person"> </rdf:Property> deleted text: <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> </rdf:Description> <rdfs:Class rdf:ID="Person"/> deleted text: <rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer"> deleted text: <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Datatype"/> </rdf:Description> <rdfs:Datatype rdf:about="&xsd;integer"/>
Note
that
deleted text:
we
have
not
used
an
<tt>
<rdf:RDF>
</tt>
element
is
not
used
in
<a href="#example19">
Example
19
</a>
26
,
because
we
have
it
is
assumed
deleted text:
we
are
adding
this
RDF/XML
is
being
added
to
the
vehicle
schema
deleted text:
we
described
earlier,
identified
by
<tt>
http://example.org/schemas/vehicles
</tt>.
in
Example
24
.
This
same
assumption
also
allows
us
to
the
use
of
relative
URIrefs
like
<tt>
#MotorVehicle
</tt>
to
refer
to
other
classes
from
that
schema.
RDF
Schema
provides
a
way
to
specialize
properties
as
well
as
classes.
We
describe
this
This
specialization
relationship
between
two
properties
is
described
using
the
pre-defined
<tt>
predefined
rdfs:subPropertyOf
</tt>
property.
For
example,
if
<tt>
ex:primaryDriver
</tt>
and
<tt>
ex:driver
</tt>
are
both
properties,
we
can
example.org
could
describe
these
properties,
and
the
fact
that
<tt>
ex:primaryDriver
</tt>
is
a
specialization
of
<tt>
ex:driver
</tt>,
,
by
writing
the
RDF
statements:
ex:driver rdf:type rdf:Property . ex:driver rdf:type rdf:Property . ex:primaryDriver rdf:type rdf:Property . ex:primaryDriver rdf:type rdf:Property . ex:primaryDriver rdfs:subPropertyOf ex:driver . ex:primaryDriver rdfs:subPropertyOf ex:driver .
The
meaning
of
the
<tt>
this
rdfs:subPropertyOf
</tt>
relationship
is
that
if
an
instance
<tt>
ex:fred
</tt>
exstaff:fred
is
an
<tt>
ex:primaryDriver
</tt>
of
the
instance
<tt>
ex:companyVan
</tt>,
,
then
<tt>
ex:fred
</tt>
is
implicitly
considered
to
RDF
Schema
defines
exstaff:fred
as
also
be
being
an
<tt>
ex:primaryDriver
</tt>
ex:driver
of
<tt>
ex:companyVan
</tt>.
.
The
RDF/XML
describing
these
properties
(assuming
again
that
we
are
adding
this
it
is
being
added
to
the
vehicle
schema
deleted text:
we
described
earlier)
in
Example
24
)
is
shown
in
<a href="#example20">
Example
20
27
.
<rdf:Description rdf:ID="driver"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="driver"> <rdfs:domain rdf:resource="#MotorVehicle"/> </rdf:Description> </rdf:Property> deleted text: <rdf:Description rdf:ID="primaryDriver"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="primaryDriver"> <rdfs:subPropertyOf rdf:resource="#driver"/> </rdf:Description> </rdf:Property>
A
property
may
be
a
subproperty
of
zero,
one
or
more
properties.
All
RDF
<tt>
Schema
rdfs:range
</tt>
and
<tt>
rdfs:domain
</tt>
properties
that
apply
to
an
RDF
property
also
apply
to
each
of
its
subproperties.
So
So,
in
the
above
example
<tt>
example,
RDF
Schema
defines
ex:primaryDriver
</tt>,
as
also
having
an
rdfs:domain
of
ex:MotorVehicle
,
because
of
its
subproperty
relationship
to
<tt>
ex:driver
</tt>,
implicitly
also
has
an
<tt>
rdfs:domain
</tt>
of
<tt>
ex:MotorVehicle
</tt>.
.
<a href="#example1"> Example 21 28 shows the RDF/XML for the full vehicle schema, containing all the descriptions deleted text: we've given so far:
<?xml version="1.0"?> <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://example.org/schemas/vehicles"> <rdf:Description rdf:ID="MotorVehicle"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> </rdf:Description> <rdfs:Class rdf:ID="MotorVehicle"/> deleted text: <rdf:Description rdf:ID="PassengerVehicle"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:Class rdf:ID="PassengerVehicle"> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdf:Description> </rdfs:Class> deleted text: <rdf:Description rdf:ID="Truck"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:Class rdf:ID="Truck"> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdf:Description> </rdfs:Class> <rdf:Description rdf:ID="Van"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:Class rdf:ID="Van"> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdf:Description> </rdfs:Class> deleted text: <rdf:Description rdf:ID="MiniVan"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <rdfs:Class rdf:ID="MiniVan"> <rdfs:subClassOf rdf:resource="#Van"/> <rdfs:subClassOf rdf:resource="#PassengerVehicle"/> </rdf:Description> <rdf:Description rdf:ID="Person"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> </rdf:Description> </rdfs:Class> <rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer"> <rdfs:Class rdf:ID="Person"/> deleted text: <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Datatype"/> deleted text: </rdf:Description> <rdfs:Datatype rdf:about="&xsd;integer"/> deleted text: <rdf:Description rdf:ID="registeredTo"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="registeredTo"> <rdfs:domain rdf:resource="#MotorVehicle"/> <rdfs:range rdf:resource="#Person"/> </rdf:Description> </rdf:Property> deleted text: <rdf:Description rdf:ID="rearSeatLegRoom"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="rearSeatLegRoom"> <rdfs:domain rdf:resource="#PassengerVehicle"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/> </rdf:Description> <rdfs:range rdf:resource="&xsd;integer"/> </rdf:Property> deleted text: <rdf:Description rdf:ID="driver"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="driver"> <rdfs:domain rdf:resource="#MotorVehicle"/> </rdf:Description> </rdf:Property> deleted text: <rdf:Description rdf:ID="primaryDriver"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:Property rdf:ID="primaryDriver"> <rdfs:subPropertyOf rdf:resource="#driver"/> </rdf:Description> </rdf:Property> </rdf:RDF>
Now
that
we've
Having
shown
how
to
describe
classes
and
properties
using
RDF
Schema,
deleted text:
we
can
see
what
instances
corresponding
to
using
those
descriptions
might
look
like.
classes
and
properties
can
now
be
illustrated.
For
example,
<a href="#example22">
Example
22
29
describes
an
instance
of
the
<tt>
ex:PassengerVehicle
</tt>
class
deleted text:
we
described
above,
in
Example
28
,
together
with
some
hypothetical
values
for
its
properties.
ex:PassengerVehicle
</tt>
<?xml version="1.0"?> <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> xmlns:ex="http://example.org/schemas/vehicles"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/schemas/vehicles#" xml:base="http://example.org/things"> deleted text: <rdf:Description rdf:ID="johnSmithsCar"> deleted text: <rdf:type rdf:resource="http://example.org/schemas/vehicles#PassengerVehicle"/> <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/> <ex:PassengerVehicle rdf:ID="johnSmithsCar"> <ex:rearSeatLegRoom <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/> rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">127</ex:rearSeatLegRoom> <ex:rearSeatLegRoom <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/> rdf:datatype="&xsd;integer">127</ex:rearSeatLegRoom> </rdf:Description> <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/> </rdf:RDF> </ex:PassengerVehicle> </rdf:RDF>
We
are
assuming
This
example
assumes
that
this
the
instance
is
described
in
a
separate
document
from
the
schema
and,
as
before,
that
schema.
Since
the
schema
is
the
resource
<tt>
has
an
xml:base
of
http://example.org/schemas/vehicles
</tt>.
So
we
provide
,
the
namespace
declaration
<tt>
xmlns:ex="http://example.org/schemas/vehicles"
</tt>
to
refer
to
the
schema,
which
allows
the
instance
data
xmlns:ex="http://example.org/schemas/vehicles#"
is
provided
to
use
abbreviations
allow
QNames
such
as
<tt>
ex:registeredTo
</tt>
in
the
instance
data
to
refer
unambiguously
be
properly
expanded
to
the
URIrefs
of
the
classes
and
properties
described
in
that
schema.
However,
when
we
use
the
<tt>
rdf:type
</tt>
property
to
indicate
the
class
membership
of
the
An
xml:base
declaration
is
also
provided
for
this
instance,
we
must
use
to
allow
rdf:ID="johnSmithsCar"
to
expand
to
the
full
proper
URIref
independently
of
the
class
to
refer
to
it
(since
we
cannot
use
a
QName
referencing
the
<tt>
ex:
</tt>
namespace
as
a
value
location
of
the
<tt>
rdf:resource
</tt>
attribute.
actual
document.
Note
that
deleted text:
we
can
use
an
<tt>
ex:registeredTo
</tt>
property
can
be
used
in
describing
this
instance
of
<tt>
ex:PassengerVehicle
</tt>,
,
because
<tt>
ex:PassengerVehicle
</tt>
is
a
subclass
of
<tt>
ex:MotorVehicle
</tt>.
.
Note
also
that
deleted text:
we
use
a
typed
literal
is
used
for
the
value
of
the
<tt>
ex:rearSetLegRoom
</tt>
property
in
our
this
instance,
rather
than
a
plain
literal
(i.e.,
we
didn't
say
<tt>
rather
than
stating
the
value
as
<ex:rearSeatLegRoom>127</ex:rearSeatLegRoom>
</tt>
).
Because
the
schema
describes
the
range
of
this
property
as
an
<tt>
xsd:integer
</tt>,
,
the
value
of
the
property
must
should
be
a
typed
literal
of
that
datatype
in
order
to
match
the
range
description
(i.e.,
the
range
declaration
does
not
automatically
"assign"
a
datatype
to
a
plain
literal).
</p>
<p>
As
we
discussed
in
<a href="#newresources">
Section
3.2
</a>,
the
RDF/XML
syntax
provides
an
abbreviation
for
instances
defined
as
members
of
classes
using
the
<tt>
rdf:type
</tt>
property.
Using
this
abbreviation,
we
could
describe
this
same
instance
as
shown
in
<a href="#example23">
Example
23
</a>:
</p>
<div class="exampleOuter">
<div class="c1">
<a id="example23" name="example23">
Example
23:
An
Abbreviation
of
the
Instance
from
Example
22
</a>
</div>
<div class="exampleInner">
<pre>
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://example.org/schemas/vehicles">
<ex:PassengerVehicle rdf:ID="johnSmithsCar">
<ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
<ex:rearSeatLegRoom
rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">127</ex:rearSeatLegRoom>
<ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/>
</ex:PassengerVehicle>
</rdf:RDF>
</pre>
</div>
</div>
<p>
In
<a href="#example23">
Example
23
</a>
the
class
is
identified
by
an
element
name
(
<tt>
ex:PasssengerVehicle
</tt>
)
rather
than
as
the
value
of
an
<tt>
rdf:resource
</tt>
attribute,
literal,
and
so
deleted text:
we
can
abbreviate
it
with
the
QName
<tt>
ex:PasssengerVehicle
</tt>
rather
than
writing
it
as
a
full
URIref
as
we
did
in
typed
literal
of
the
earlier
form.
appropriate
datatype
must
be
explicitly
provided).
As noted earlier, the RDF Schema type system is similar in some respects to the type systems of object-oriented programming languages such as Java. However, RDF differs from most programming language type systems in several important respects.
One
important
difference
is
that
instead
of
describing
a
class
as
having
a
collection
of
specific
properties,
an
RDF
schema
describes
properties
as
applying
to
specific
classes
of
resource,
resources,
using
domain
and
range
properties.
For
example,
a
typical
object-oriented
programming
language
might
define
a
class
<tt>
Book
</tt>
with
an
attribute
called
<tt>
author
</tt>
having
values
of
type
<tt>
Person
</tt>.
.
A
corresponding
RDF
schema
would
describe
a
class
<tt>
ex:Book
</tt>,
,
and,
in
a
separate
description,
a
property
<tt>
ex:author
</tt>
having
a
domain
of
<tt>
ex:Book
</tt>
and
a
range
of
<tt>
ex:Person
</tt>.
.
The
difference
between
these
approaches
may
seem
to
be
only
syntactic,
but
in
fact
there
is
an
important
difference.
In
the
programming
language
class
description,
the
attribute
<tt>
author
</tt>
is
part
of
the
description
of
class
<tt>
Book
</tt>,
,
and
applies
only
to
instances
of
class
<tt>
Book
</tt>.
.
Another
class
(say,
<tt>
softwareModule
</tt>
)
might
also
have
an
attribute
called
<tt>
author
</tt>,
,
but
this
would
be
considered
a
different
attribute.
In
other
words,
the
scope
of
an
attribute
description
in
most
programming
languages
is
restricted
to
the
class
or
type
in
which
it
is
defined.
In
RDF,
on
the
other
hand,
property
descriptions
are,
by
default,
independent
of
class
definitions,
and
have,
by
default,
global
scope
(although
they
may
optionally
be
declared
to
apply
only
to
certain
classes
using
domain
specifications).
So,
for
example,
As
a
result,
an
RDF
schema
could
describe
a
property
<tt>
exterms:weight
</tt>
without
a
domain
being
specified.
This
property
could
then
be
used
to
describe
instances
of
any
class
that
might
be
considered
to
have
a
weight.
One
benefit
of
the
RDF
property-based
approach
is
that
it
becomes
easier
to
extend
the
use
of
property
definitions
to
situations
that
might
not
have
been
anticipated
in
the
original
description.
(Of
course,
At
the
same
time,
this
is
a
"benefit"
which
must
be
used
with
care,
to
insure
that
properties
are
not
mis-applied
in
inappropriate
situations.)
situations.
Another
result
of
the
global
scope
of
RDF
property
descriptions
is
that
it
is
not
possible
in
an
RDF
schema
to
define
a
specific
property
as
having
locally-different
ranges
depending
on
the
class
of
the
resource
it
is
applied
to.
For
example,
in
defining
the
property
ex:hasParent
,
it
would
be
desirable
to
be
able
to
say
that
if
the
property
is
used
to
describe
a
resource
of
class
ex:Human
,
then
the
range
of
the
property
is
also
a
resource
of
class
ex:Human
,
while
if
the
property
is
used
to
describe
a
resource
of
class
ex:Tiger
,
then
the
range
of
the
property
is
also
a
resource
of
class
ex:Tiger
.
This
kind
of
definition
is
not
possible
in
RDF
Schema.
Instead,
any
range
defined
for
an
RDF
property
applies
to
all
uses
of
the
property,
and
so
ranges
should
be
defined
with
care.
However,
while
such
locally-different
ranges
cannot
be
defined
in
RDF
Schema,
they
can
be
defined
in
some
of
the
richer
schema
languages
discussed
in
Section
5.5
.
Another
important
difference
is
that
RDF
Schema
descriptions
are
not
necessarily
prescriptive
in
the
way
programming
language
type
declarations
typically
are.
For
example,
if
a
programming
language
declares
a
class
<tt>
Book
</tt>
with
an
<tt>
author
</tt>
attribute
having
values
of
type
<tt>
Person
</tt>,
,
this
is
usually
interpreted
as
a
group
of
constraints
.
The
language
will
not
allow
the
creation
of
an
instance
of
<tt>
Book
</tt>
without
an
<tt>
author
</tt>
attribute,
and
it
will
not
allow
an
instance
of
<tt>
Book
</tt>
with
an
<tt>
author
</tt>
attribute
that
does
not
have
a
<tt>
Person
</tt>
as
its
value.
Moreover,
if
<tt>
author
</tt>
is
the
only
attribute
defined
for
class
<tt>
Book
</tt>,
,
the
language
will
not
allow
an
instance
of
<tt>
Book
</tt>
with
some
other
attribute.
RDF
Schema,
on
the
other
hand,
provides
schema
information
as
additional
descriptions
of
resources,
but
does
not
prescribe
how
these
descriptions
should
be
used
by
an
application.
For
example,
suppose
an
RDF
schema
states
that
an
<tt>
ex:author
</tt>
property
has
an
<tt>
rdfs:range
</tt>
of
class
<tt>
ex:Person
</tt>.
.
This
is
simply
an
RDF
statement
that
RDF
statements
containing
<tt>
ex:author
</tt>
properties
have
instances
of
<tt>
ex:Person
</tt>
as
objects.
This
schema-supplied
information
might
be
used
in
different
ways.
One
application
might
interpret
this
statement
as
specifying
part
of
a
template
for
RDF
data
it
is
creating,
and
use
it
to
ensure
that
any
<tt>
ex:author
</tt>
property
has
a
value
of
the
indicated
(
<tt>
ex:Person
</tt>
)
class.
That
is,
this
application
interprets
the
schema
description
as
a
constraint
in
the
same
way
that
a
programming
language
might.
However,
another
application
might
interpret
this
statement
as
providing
additional
information
about
data
it
is
receiving,
information
which
may
not
be
provided
explicitly
in
the
original
data.
For
example,
this
second
application
might
receive
some
RDF
data
that
includes
an
<tt>
ex:author
</tt>
property
whose
value
is
a
resource
of
unspecified
class,
and
use
this
schema-provided
statement
to
conclude
that
the
resource
must
be
an
instance
of
class
<tt>
ex:Person
</tt>.
.
A
third
application
might
receive
some
RDF
data
that
includes
an
<tt>
ex:author
</tt>
property
whose
value
is
a
resource
of
class
<tt>
ex:Corporation
</tt>,
,
and
use
this
schema
information
as
the
basis
of
a
warning
that
"there
may
be
an
inconsistency
here,
but
on
the
other
hand
there
may
not
be".
Somewhere
else
there
may
be
a
declaration
that
resolves
the
apparent
inconsistency
(e.g.,
a
declaration
to
the
effect
that
"a
Corporation
is
a
(legal)
Person").
Moreover,
depending
on
how
the
application
interprets
the
property
descriptions,
a
description
of
an
instance
might
be
considered
valid
either
without
some
of
the
schema-specified
properties
(e.g.,
you
there
might
have
be
an
instance
of
<tt>
ex:Book
</tt>
without
an
<tt>
ex:author
</tt>
property,
even
if
<tt>
ex:author
</tt>
is
described
as
having
a
domain
of
<tt>
ex:Book
</tt>
),
or
with
additional
properties
(you
(there
might
describe
be
an
instance
of
<tt>
ex:Book
</tt>
with
an
<tt>
ex:technicalEditor
</tt>
property,
even
though
you
haven't
described
the
schema
describing
class
ex:Book
does
not
describe
such
a
property
in
your
particular
schema.)
property).
In other words, statements in an RDF Schema schema are always descriptions . They may also be prescriptive (introduce constraints), but only if the application interpreting those statements wants to treat them that way. All RDF Schema does is provide a way of stating this additional information. Whether this information conflicts with explicitly specified instance data is up to the application to determine and act upon.
RDF
Schema
deleted text:
also
provides
a
number
of
other
built-in
properties,
which
can
be
used
to
provide
documentation
and
other
information
about
an
RDF
schema
or
about
instances.
For
example
the
<tt>
rdfs:comment
</tt>
property
can
be
used
to
provide
a
human-readable
description
of
a
resource.
The
<tt>
rdfs:label
</tt>
property
can
be
used
to
provide
a
more
human-readable
version
of
a
resource's
name.
The
<tt>
rdfs:seeAlso
</tt>
property
can
be
used
to
indicate
a
resource
that
might
provide
additional
information
about
the
subject
resource.
The
<tt>
rdfs:isDefinedBy
</tt>
property
is
a
subproperty
of
<tt>
rdfs:seeAlso
</tt>,
,
and
can
be
used
to
indicate
a
resource
that
(in
a
sense
not
specified
by
RDF;
e.g.,
the
resource
may
not
be
an
RDF
schema)
"defines"
the
subject
resource.
deleted text:
For
further
discussion
of
these
properties,
you
should
consult
RDF
Vocabulary
Description
Language
1.0:
RDF
Schema
[RDF-VOCABULARY]
</a>.
should
be
consulted
for
further
discussion
of
these
properties.
As
with
a
number
of
the
built-in
RDF
properties
such
as
rdf:value
,
the
uses
described
for
these
RDF
Schema
properties
are
only
their
intended
uses.
[RDF-SEMANTICS]
defines
no
special
meanings
for
these
properties,
and
RDF
Schema
does
not
define
any
constraints
based
on
these
intended
uses.
For
example,
there
is
no
constraint
specified
that
the
object
of
a
rdfs:seeAlso
property
must
provide
additional
information
about
the
subject
of
the
statement
in
which
it
appears.
RDF Schema provides basic capabilities for describing RDF vocabularies, but additional capabilities are also possible, and can be useful. These capabilities may be provided through further development of RDF Schema, or in other languages. languages based on RDF. Other richer schema capabilities that have been identified as useful (but that are not provided by RDF Schema) include:
ex:hasAncestor
)
is
transitive
,
e.g.,
that
if
A
<tt>
hasAncestor
</tt>
ex:hasAncestor
B,
and
B
<tt>
hasAncestor
</tt>
ex:hasAncestor
C,
then
A
<tt>
hasAncestor
</tt>
ex:hasAncestor
C.
ex:hasPlayers
property
has
11
values,
while
for
a
basketball
team
the
same
property
should
have
only
5
values.
The additional capabilities mentioned above, in addition to others, are the targets of ontology languages such as DAML+OIL [DAML+OIL] and OWL [OWL] . Both these languages are based on RDF and RDF Schema (and both currently provide all the additional capabilities mentioned above). The intent of such languages is to provide additional machine-processable semantics for resources, that is, to make the machine representations of resources more closely resemble their intended real world counterparts. While such capabilities are not necessarily needed to build useful applications using RDF (see Section 6 for a description of a number of existing RDF applications), the development of such languages is a very active subject of work as part of the development of the Semantic Web .
In the The previous sections, we sections have described the general capabilities of RDF and RDF Schema. While deleted text: we have used examples within were used in those sections to illustrate those capabilities, and some of those examples may have suggested potential RDF applications, we have those sections did not yet discussed actually discuss any real ones. In this section, we applications. This section will describe some actual deployed RDF applications, showing how RDF supports various real-world requirements to represent and manipulate information about a wide variety of things.
Metadata is data about data . Specifically, the term refers to data used to identify, describe, or locate information resources, whether these resources are physical or electronic. While structured metadata processed by computers is relatively new, the basic concept of metadata has been used for many years in helping manage and use large collections of information. Library card catalogs are a familiar example of such metadata.
The
Dublin
Core
is
a
set
of
"elements"
(properties)
for
describing
documents
(and
hence,
for
recording
metadata).
The
element
set
was
originally
developed
at
the
March
1995
Metadata
Workshop
in
Dublin,
Ohio.
The
Dublin
Core
has
subsequently
been
modified
on
the
basis
of
later
Dublin
Core
Metadata
workshops,
and
is
currently
maintained
by
the
Dublin
Core
Metadata
Initiative
.
The
goal
of
the
Dublin
Core
is
to
provide
a
minimal
set
of
descriptive
elements
that
facilitate
the
description
and
the
automated
indexing
of
document-like
networked
objects,
in
a
manner
similar
to
a
library
card
catalog.
The
Dublin
Core
metadata
set
is
intended
to
be
suitable
for
use
by
resource
discovery
tools
on
the
Internet,
such
as
the
"webcrawlers"
"Webcrawlers"
employed
by
popular
World
Wide
Web
search
engines.
In
addition,
the
Dublin
Core
is
meant
to
be
sufficiently
simple
to
be
understood
and
used
by
the
wide
range
of
authors
and
casual
publishers
who
contribute
information
to
the
Internet.
Dublin
Core
elements
have
become
widely
used
in
documenting
Internet
resources
(we
have
already
used
the
(the
Dublin
Core
<tt>
creator
</tt>
element
has
already
been
used
in
earlier
examples).
The
current
elements
of
the
Dublin
Core
are
defined
in
the
<a href="http://dublincore.org/documents/dces/">
Dublin
Core
Metadata
Element
Set,
Version
1.1:
Reference
Description
[DC]
,
and
contain
definitions
for
the
following
properties:
Information
using
the
Dublin
Core
elements
may
be
represented
in
any
suitable
language
(e.g.,
in
HTML
Meta
meta
elements).
However,
RDF
is
an
ideal
representation
for
Dublin
Core
information.
The
examples
below
represent
the
simple
description
of
a
set
of
resources
in
RDF
using
the
Dublin
Core
vocabulary.
Note
that
the
specific
Dublin
Core
RDF
vocabulary
shown
here
is
not
intended
to
be
authoritative.
The
Dublin
Core
Reference
Description
[DC]
is
the
authoritative
reference.
The first example, <a href="#example24"> Example 24 30 , describes a Web site home page using Dublin Core properties:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://www.dlib.org"> <dc:title>D-Lib Program - Research in Digital Libraries</dc:title> <dc:description>The D-Lib program supports the community of people with research interests in digital libraries and electronic publishing.</dc:description> <dc:publisher>Corporation For National Research Initiatives</dc:publisher> <dc:date>1995-01-07</dc:date> <dc:subject> <rdf:Bag> <rdf:li>Research; statistical methods</rdf:li> <rdf:li>Education, research, related topics</rdf:li> <rdf:li>Library use Studies</rdf:li> </rdf:Bag> </dc:subject> <dc:type>World Wide Web Home Page</dc:type> <dc:format>text/html</dc:format> <dc:language>en</dc:language> </rdf:Description> </rdf:RDF>
Note
that
both
RDF
and
the
Dublin
Core
define
an
(XML)
element
called
"Description"
(although
the
Dublin
Core
element
name
is
written
in
lower
case).
lowercase).
Even
if
the
initial
letter
were
identically
uppercase,
the
XML
namespace
mechanism
enables
deleted text:
us
to
distinguish
between
these
two
elements
to
be
distinguished
(one
is
<tt>
rdf:Description
</tt>,
,
and
the
other
is
<tt>
dc:description
</tt>
).
Also,
as
a
matter
of
interest,
if
you
access
accessing
http://purl.org/dc/elements/1.1/
(the
namespace
URI
used
to
identify
the
Dublin
Core
vocabulary
in
this
example)
in
a
Web
browser
(as
of
the
current
writing),
you
writing)
will
get
retrieve
an
RDF
Schema
declaration
for
[DC]
.
Our The second example, <a href="#example25"> Example 25 31 , describes a published magazine:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/05contents.html"> <dc:title>DLIB Magazine - The Magazine for Digital Library Research - May 1998</dc:title> <dc:description>D-LIB magazine is a monthly compilation of contributed stories, commentary, and briefings.</dc:description> <dc:contributor>Amy Friedlander</dc:contributor> <dc:publisher>Corporation for National Research Initiatives</dc:publisher> <dc:date>1998-01-05</dc:date> <dc:type>electronic journal</dc:type> <dc:subject> <rdf:Bag> <rdf:li>library use studies</rdf:li> <rdf:li>magazines and newspapers</rdf:li> </rdf:Bag> </dc:subject> <dc:format>text/html</dc:format> <dc:identifier rdf:resource="urn:issn:1082-9873"/> <dcterms:isPartOf rdf:resource="http://www.dlib.org"/> </rdf:Description> </rdf:RDF>
In
<a href="#example25">
Example
25
</a>,
we've
used
31
uses
(in
the
third
line
from
the
bottom)
the
Dublin
Core
qualifier
<tt>
isPartOf
</tt>
(from
a
separate
namespace)
vocabulary
)
to
indicate
that
this
magazine
is
"part
of"
the
previously-described
web
Web
site.
The third example, <a href="#example26"> Example 26 32 , describes a specific article in the magazine described in <a href="#example25"> Example 25 30 .
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/miller/05miller.html"> <dc:title>An Introduction to the Resource Description Framework</dc:title> <dc:creator>Eric J. Miller</dc:creator> <dc:description>The Resource Description Framework (RDF) is an infrastructure that enables the encoding, exchange and reuse of structured metadata. rdf is an application of xml that imposes needed structural constraints to provide unambiguous methods of expressing semantics. rdf additionally provides a means for publishing both human-readable and machine-processable vocabularies designed to encourage the reuse and extension of metadata semantics among disparate information communities. the structural constraints rdf imposes to support the consistent encoding and exchange of standardized metadata provides for the interchangeability of separate packages of metadata defined by different resource description communities. </dc:description> <dc:publisher>Corporation for National Research Initiatives</dc:publisher> <dc:subject> <rdf:Bag> <rdf:li>machine-readable catalog record formats</rdf:li> <rdf:li>applications of computer file organization and access methods</rdf:li> </rdf:Bag> </dc:subject> <dc:rights>Copyright @ 1998 Eric Miller</dc:rights> <dc:rights>Copyright © 1998 Eric Miller</dc:rights> <dc:type>Electronic Document</dc:type> <dc:format>text/html</dc:format> <dc:language>en</dc:language> <dcterms:isPartOf rdf:resource="http://www.dlib.org/dlib/may98/05contents.html"/> </rdf:Description> </rdf:RDF>
In
<a href="#example26">
Example
26
</a>,
we've
32
also
used
uses
the
qualifier
<tt>
isPartOf
</tt>,
,
this
time
to
indicate
that
this
article
is
"part
of"
the
previously-described
magazine.
Computer
languages
and
file
formats
do
not
always
make
explicit
provision
for
embedding
metadata
with
the
data
it
describes.
In
many
cases,
the
metadata
has
to
be
specified
as
a
separate
resource
and
explicitly
linked
to
the
data
(this
has
been
done
for
the
RDF
metadata
that
describes
the
Primer;
there
is
an
explicit
link
to
this
metadata
at
the
end
of
the
Primer).
However,
applications
and
languages
are
increasingly
making
explicit
provision
for
embedding
metadata
directly
with
the
data.
For
example,
the
W3C's
Scalable
Vector
Graphics
language
[SVG]
(another
XML-based
language)
provides
an
explicit
metadata
element
for
recording
metadata
along
with
other
SVG
data.
Any
XML-based
metadata
language
can
be
used
inside
this
element.
[SVG]
includes
the
example
shown
in
Example
33
of
how
to
embed
metadata
describing
an
SVG
document
in
the
SVG
document
itself.
The
example
uses
the
Dublin
Core
vocabulary,
and
RDF/XML
for
recording
the
metadata.
<?xml version="1.0"?>
<svg width="4in" height="3in" version="1.1"
xmlns = 'http://www.w3.org/2000/svg'>
<desc xmlns:myfoo="http://example.org/myfoo">
<myfoo:title>This is a financial report</myfoo:title>
<myfoo:descr>The global description uses markup from the
<myfoo:emph>myfoo</myfoo:emph> namespace.</myfoo:descr>
<myfoo:scene><myfoo:what>widget $growth</myfoo:what>
<myfoo:contains>$three $graph-bar</myfoo:contains>
<myfoo:when>1998 $through 2000</myfoo:when> </myfoo:scene>
</desc>
<metadata>
<rdf:RDF
xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
xmlns:dc = "http://purl.org/dc/elements/1.1/" >
<rdf:Description rdf:about="http://example.org/myfoo"
dc:title="MyFoo Financial Report"
dc:description="$three $bar $thousands $dollars $from 1998 $through 2000"
dc:publisher="Example Organization"
dc:date="2000-04-11"
dc:format="image/svg+xml"
dc:language="en" >
<dc:creator>
<rdf:Bag>
<rdf:li>Irving Bird</rdf:li>
<rdf:li>Mary Lambert</rdf:li>
</rdf:Bag>
</dc:creator>
</rdf:Description>
</rdf:RDF>
</metadata>
</svg>
Adobe's Extensible Metadata Platform (XMP) is another example of technology that allows metadata about a file to be embedded into the file itself. XMP uses RDF/XML as the basis of its metadata representation. A number of Adobe products already support XMP.
<a href="http://www.prismstandard.org/techdev/prismspec11.asp"> PRISM: Publishing Requirements for Industry Standard Metadata [PRISM] is a metadata specification developed in the publishing industry. Magazine publishers and their vendors formed the deleted text: <a href="http://www.prismstandard.org/"> PRISM Working Group deleted text: </a> to identify the industry's needs for metadata and define a specification to meet them. Publishers want to use existing content in many ways in order to get a greater return on the investment made in creating it. Converting magazine articles to HTML for posting on the web Web is one example. Licensing it to aggregators like LexisNexis is another. All of these are "first uses" of the content; typically they all go live at the time the magazine hits the stands. The publishers also want their content to be "evergreen". It might be used in new issues, such as in a retrospective article. It could be used by other divisions in the company, such as in a book compiled from the magazine's photos, recipes, etc. Another use is to license it to outsiders, such as in a reprint of a product review, or in a retrospective produced by a different publisher. This overall goal requires a metadata approach which that emphasizes discovery , rights tracking , and end-to-end metadata .
Discovery: Discovery is a general term for finding content which encompasses searching, browsing, content routing, and other techniques. Discussions of discovery frequently center on a consumer searching a public web Web site. However, discovering content is much broader than that. The audience may consist of consumers, or it may consist of internal users such as researchers, designers, photo editors, licensing agents, etc. To assist discovery, PRISM provides properties to describe the topics, formats, genre, origin, and contexts of a resource. It also provides means for categorizing resources using multiple subject description taxonomies.
Rights Tracking: Magazines frequently contain material licensed from others. Photos from a stock photo agency are the most common type of licensed material, but articles, sidebars, and all other types of content may be licensed. Simply knowing if content was licensed for one-time use, requires royalty payments, or is wholly-owned by the publisher is a struggle. PRISM provides elements for basic tracking of such rights. A separate namespace (vocabulary) vocabulary defined in the PRISM specification supports description of places, times, and industries where content may or may not be used.
End-to-end metadata: Most published content already has metadata created for it. Unfortunately, when content moves between systems, the metadata is frequently discarded, only to be re-created later in the production process at considerable expense. PRISM aims to reduce this problem by providing a specification that can be used in multiple stages in the content production pipeline. An important feature of the PRISM specification is its use of other existing specifications. Rather than create an entirely new thing, the group decided to use existing specifications as much as possible, and only define new things where needed. For this reason, the PRISM specification uses XML, RDF, Dublin Core, and well as various ISO formats and vocabularies.
A PRISM description may be as simple as a few Dublin Core properties with plain literal values. <a href="#example27"> Example 27 34 describes a photograph, giving basic information on its title, photographer, format, etc.
<?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="en-US"> <rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg"> <rdf:Description rdf:about="http://travel.example.com/2000/08/Corfu.jpg"> <dc:title>Walking on the Beach in Corfu</dc:title> <dc:description>Photograph taken at 6:00 am on Corfu with two models </dc:description> <dc:creator>John Peterson</dc:creator> <dc:contributor>Sally Smith, lighting</dc:contributor> <dc:format>image/jpeg</dc:format> </rdf:Description> </rdf:RDF>
PRISM
also
augments
the
Dublin
Core
to
allow
more
detailed
descriptions.
The
augmentations
are
defined
in
as
three
new
namespaces,
vocabularies
,
generally
cited
using
the
prefixes
<tt>
prism:
</tt>,
<tt>
,
pcv:
</tt>,
,
and
<tt>
prl:
</tt>.
.
<tt>
prism:
</tt>
This
prefix
refers
to
the
main
PRISM
namespace,
vocabulary,
whose
terms
use
the
URI
is
<tt>
prefix
http://prismstandard.org/namespaces/basic/1.0/
</tt>.
.
Most
of
its
the
properties
in
this
vocabulary
are
more
specific
versions
of
properties
from
the
Dublin
Core.
For
example,
more
specific
versions
of
<tt>
dc:date
</tt>
are
provided
by
properties
like
<tt>
prism:publicationTime
</tt>,
<tt>
,
prism:releaseTime
</tt>,
<tt>
,
prism:expirationTime
</tt>,
,
etc.
<tt>
pcv:
</tt>
This
prefix
refers
to
the
PRISM
Controlled
Vocabulary
namespace,
(pcv)
vocabulary,
whose
terms
use
the
URI
is
<tt>
prefix
http://prismstandard.org/namespaces/pcv/1.0/
</tt>.
.
Currently,
common
practice
for
describing
the
subject(s)
of
an
article
is
by
supplying
descriptive
keywords.
Unfortunately,
simple
keywords
do
not
make
a
great
difference
in
retrieval
performance,
due
to
the
fact
that
different
people
will
use
different
keywords
[BATES96]
.
Best
practice
is
to
code
the
articles
with
subject
terms
from
a
"controlled
vocabulary".
The
vocabulary
should
provide
as
many
synonyms
as
possible
for
its
terms
in
the
vocabulary.
This
way
the
controlled
terms
provide
a
meeting
ground
for
the
keywords
supplied
by
the
searcher
and
the
indexer.
The
PRISM
Controlled
Vocabulary
(pcv)
namespace
pcv
vocabulary
provides
properties
for
specifying
terms
in
a
vocabulary,
the
relations
between
terms,
and
alternate
names
for
the
terms.
<tt>
prl:
</tt>
This
prefix
refers
to
the
PRISM
Rights
Language
namespace,
vocabulary,
whose
terms
use
the
URI
is
<tt>
prefix
http://prismstandard.org/namespaces/prl/1.0/
</tt>.
.
Digital
Rights
Management
is
an
area
undergoing
considerable
upheaval.
There
are
a
number
of
proposals
for
rights
management
languages,
but
none
are
clearly
favored
throughout
the
industry.
Because
there
was
no
clear
choice
to
recommend,
the
PRISM
Rights
Language
(PRL)
was
defined
as
an
interim
measure.
It
provides
properties
which
let
people
say
if
an
item
can
or
can't
cannot
be
"used",
depending
on
conditions
of
time,
geography,
and
industry.
This
is
believed
to
be
an
80/20
tradeoff
trade-off
which
will
help
publishers
begin
to
save
money
when
tracking
rights.
It
is
not
intended
to
be
a
general
rights
language,
or
allow
publishers
to
automatically
enforce
limits
on
consumer
uses
of
the
content.
PRISM uses RDF because of its abilities for dealing with descriptions of varying complexity. Currently, a great deal of metadata uses simple character string (plain literal) values, such as:
<dc:coverage>Greece</dc:coverage>
Over
time
the
developers
of
PRISM
expect
uses
of
the
PRISM
specification
to
become
more
sophisticated,
moving
from
simple
literal
values
to
more
structured
values.
In
fact,
that
range
of
values
is
a
situation
being
faced
now.
Some
publishers
already
use
sophisticated
controlled
vocabularies,
others
are
barely
using
manually-supplied
keywords.
To
illustrate
this,
some
examples
of
the
different
kinds
of
values
that
can
be
given
for
the
<tt>
coverage
</tt>
dc:coverage
property
are:
<dc:coverage>Greece</dc:coverage> <dc:coverage rdf:resource="http://prismstandard.org/vocabs/ISO-3166/GR"/>
(i.e., using either a plain literal or a URIref) URIref to identify the country) and
<dc:coverage> <pcv:Descriptor rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR"> <pcv:label xml:lang="en">Greece</pcv:label> <pcv:label xml:lang="fr">Grece</pcv:label> </pcv:Descriptor> </dc:coverage>
(using a structured value). value to provide both a URIref and names in various languages).
Note also that there are properties whose meanings are similar, or subsets of other properties. For example, the geographic subject of a resource could be given with
<prism:subject>Greece</prism:subject> <dc:coverage>Greece</dc:coverage>
or
<prism:location>Greece</prism:location>
Any of those properties might use the simple literal value, or a more complex structured value. Such a range of possibilities cannot be adequately described by DTDs, or even by the newer XML Schemas. While there is a wide range of syntactic variations to deal with, RDF's graph model has a simple structure - a set of triples. Dealing with the metadata in the triples domain makes it much easier for older software to accommodate content with new extensions.
We
will
close
this
This
section
closes
with
two
final
examples.
<a href="#example28">
Example
28
35
says
that
the
image
(
<tt>.../Corfu.jpg
</tt>
.../Corfu.jpg
)
cannot
be
used
(
<tt>
#none
</tt>
)
in
the
tobacco
industry
(code
21
in
SIC,
the
Standard
Industrial
Classifications).
<rdf:RDF xmlns:prism="http://prismstandard.org/namespaces/basic/1.0/" xmlns:prl="http://prismstandard.org/namespaces/prl/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg"> <rdf:Description rdf:about="http://travel.example.com/2000/08/Corfu.jpg"> <dc:rights rdf:parseType="Resource" xml:base="http://prismstandard.org/vocabularies/1.0/usage.xml"> <prl:usage rdf:resource="#none"/> <prl:industry rdf:resource="http://prismstandard.org/vocabs/SIC/21"/> </dc:rights> </rdf:Description> </rdf:RDF>
<a href="#example29"> Example 29 36 says that the photographer for the Corfu image was employee 3845, better known as John Peterson. It also says that the geographic coverage of the photo is Greece. It does so by providing, not just a code from a controlled vocabulary, but a cached version of the information for that term in the vocabulary.
<?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:pcv="http://prismstandard.org/namespaces/pcv/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:base="http://wanderlust.com/"> xml:base="http://travel.example.com/"> <rdf:Description rdf:about="/2000/08/Corfu.jpg"> <dc:identifier rdf:resource="/content/2357845" /> <dc:creator> <pcv:Descriptor rdf:about="/emp3845"> <pcv:label>John Peterson</pcv:label> </pcv:Descriptor> </dc:creator> <dc:coverage> <pcv:Descriptor rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR"> <pcv:label xml:lang="en">Greece</pcv:label> <pcv:label xml:lang="fr">Grece</pcv:label> </pcv:Descriptor> </dc:coverage> </rdf:Description> </rdf:RDF>
Many situations involve the need to maintain information about structured groupings of resources and their associations that are, or may be, used as a unit. The XML Package (XPackage) specification [XPACKAGE] provides a framework for defining such groupings, called packages . XPackage specifies a framework for describing the resources included in such packages, the properties of those resources, their method of inclusion, and their relationships with each other. XPackage applications include specifying the stylesheets style sheets used by a document, declaring the images shared by multiple documents, indicating the author and other metadata of a document, describing how namespaces are used by XML resources, and providing a manifest for bundling resources into a single archive file.
The XPackage framework is based upon XML, RDF, and the XML Linking Language [XLINK] , and provides two multiple RDF vocabularies: one for general packaging descriptions, and another specifically several other vocabularies for describing XML resources. The XPackage framework also allows customization through extension and/or restriction. providing supplemental resource information useful to package processors.
One application of XPackage is the description of XHTML documents and their supporting resources. An XHTML document retrieved from a web Web site may rely on other resources such as stylesheets style sheets and image files that also need to be retrieved. However, the identities of these supporting resources may not be obvious without processing the entire document. Other information about the document, such as the name of its author, may also not be available without processing the document. XPackage allows such descriptive information to be stored in a standard way in a package description document containing RDF. The outer elements of a package description document describing such an XHTML document might look like <a href="#example30"> Example 30 37 (with namespace declarations removed for simplicity):
<?xml version="1.0"?> <xpackage:description> <rdf:RDF> (description of individual resources go here) </rdf:RDF> </xpackage:description>
Resources
(such
as
the
XHTML
document,
stylesheets,
style
sheets,
and
images)
are
described
within
this
package
description
deleted text:
document.
The
XHTML
document
deleted text:
resource
itself
is
described
using
an
RDF
resource
description
element
<tt>
<xpackage:resource>
</tt>
from
the
XPackage
<em>
ontology
</em>
(the
term
XPackage
uses
for
a
vocabulary).
standard
RDF/XML
syntax.
Each
resource
description
element
may
include
RDF
properties
from
various
ontologies.
vocabularies
(XPackage
uses
the
term
"ontology"
for
what
RDF
calls
a
"vocabulary").
In
<a href="#example31">
Example
31
38
,
the
document's
MIME
content
type
("application/xhtml+xml")
is
defined
using
a
standard
XPackage
property
from
the
XPackage
ontology,
<tt>
xpackage:contentType
</tt>.
MIME
vocabulary,
mime:contentType
.
Another
property,
the
document's
author
(in
this
case,
"Garret
Wilson"),
is
described
using
a
property
from
the
Dublin
Core
(which
is
considered
a
<em>
custom
ontology
</em>
in
XPackage),
vocabulary,
defined
outside
of
XPackage,
resulting
in
a
<tt>
dc:creator
</tt>
property.
Besides
the
main
packaging
vocabulary,
XPackage
itself
specifies
an
extension
property
set
specifically
supplemental
vocabularies
for
XML-based
resources,
the
XML
ontology,
including
specifying
XML
namespaces
describing
files
(such
as
file:size
),
for
providing
MIME
information
(such
as
mime:contentType
),
for
providing
Unicode
information
(such
as
unicode:script
),
and
stylesheets
used
with
the
<tt>
xmlprop:namespace
</tt>
for
describing
XML-based
resources
(such
as
x:namespace
and
<tt>
xmlprop:style
</tt>
properties,
respectively.
x:style
).
<?xml version="1.0"?> <xpackage:description xmlns:xpackage="http://xpackage.org/namespaces/2003/xpackage#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:mime="http://xpackage.org/namespaces/2003/mime#" xmlns:x="http://xpackage.org/namespaces/2003/xml#" xmlns:xlink="http://www.w3.org/1999/xlink"> <rdf:RDF> <!--doc.html--> <xpackage:resource rdf:about="urn:examples:xhtmldocument-doc"> <rdf:Description rdf:about="urn:example:xhtmldocument-doc"> <rdfs:comment>The XHTML document.</rdfs:comment> <xpackage:location xlink:href="doc.html"/> <xpackage:contentType>application/xhtml+xml</xpackage:contentType> <xmlprop:namespace rdf:resource="http://www.w3.org/1999/xhtml"/> <mime:contentType>application/xhtml+xml</mime:contentType> <xmlprop:style rdf:resource="urn:examples:xhtmldocument-stylesheet"/> <x:namespace rdf:resource="http://www.w3.org/1999/xhtml"/> <xmlprop:annotation rdf:resource="urn:examples:xhtmldocument-annotation"/> <x:style rdf:resource="urn:example:xhtmldocument-stylesheet"/> <dc:creator>Garret Wilson</dc:creator> <xpackage:manifest> <xpackage:manifest rdf:parseType="Collection"> <rdf:Bag> <rdf:Description rdf:about="urn:example:xhtmldocument-stylesheet"/> <rdf:li rdf:resource="urn:examples:xhtmldocument-stylesheet"/> <rdf:Description rdf:about="urn:example:xhtmldocument-image"/> <rdf:li rdf:resource="urn:examples:xhtmldocument-image"/> </xpackage:manifest> </rdf:Bag> </rdf:Description> deleted text: </xpackage:manifest> </xpackage:resource> </rdf:RDF> </xpackage:description>
The
<tt>
xpackage:manifest
</tt>
property
indicates
that
both
the
stylesheet
style
sheet
and
image
resources
are
necessary
for
processing;
those
resources
are
described
separately
within
the
package
description
document.
The
example
stylesheet
style
sheet
resource
description
in
<a href="#example32">
Example
32
39
lists
its
location
within
the
package
("stylesheet.css")
using
the
general
XPackage
ontology
<tt>
vocabulary
xpackage:location
</tt>
property
(which
is
compatible
with
XLink),
and
shows
through
use
of
the
XPackage
ontology
<tt>
xpackage:contentType
</tt>
MIME
vocabulary
mime:contentType
property
that
it
is
a
CSS
stylesheet
style
sheet
("text/css").
<?xml version="1.0"?> <xpackage:description xmlns:xpackage="http://xpackage.org/namespaces/2003/xpackage#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:mime="http://xpackage.org/namespaces/2003/mime#" xmlns:x="http://xpackage.org/namespaces/2003/xml#" xmlns:xlink="http://www.w3.org/1999/xlink"> <rdf:RDF> <!--stylesheet.css--> <xpackage:resource rdf:about="urn:examples:xhtmldocument-css"> <rdf:Description rdf:about="urn:example:xhtmldocument-css"> <rdfs:comment>The document stylesheet.</rdfs:comment> <rdfs:comment>The document style sheet.</rdfs:comment> <xpackage:location xlink:href="stylesheet.css"/> <xpackage:contentType>text/css</xpackage:contentType> <mime:contentType>text/css</mime:contentType> </rdf:Description> </xpackage:resource> </rdf:RDF> </xpackage:description>
The full version of this example may be found in [XPACKAGE] .
When you consider all People sometimes need to access a wide variety of deleted text: the information deleted text: that you access on the Web on a day-to-day basis: basis, such as schedules, to-do lists, news headlines, search results, "What's New", etc., etc. As the sources and diversity of the information on the Web increases, it becomes increasingly difficult to manage this information and integrate it into a coherent whole as the sources and diversity of the information increase. whole. RSS 1.0 ("RDF Site Summary") is an RDF vocabulary that provides a lightweight multipurpose extensible metadata description and syndication format. In short, RSS 1.0 is a lightweight, yet powerful deleted text: and extensible way of describing, managing and making available to broad audiences relevant and timely information. It allows this describing information to be made available in a rich and reusable way, for timely, large-scale distribution and reuse. RSS 1.0 is also perhaps the most widely deployed RDF application on the web. Web.
To give a simple example, the W3C home page </a>, shown in <a href="#figure18"> Figure 18 </a>, is a primary point of contact with the public and serves in part to disseminate information about the deliverables of the Consortium. An example of the W3C home page as of a certain date is shown in Figure 19 . The center column of news items changes frequently. To support the timely dissemination of this information, the W3C Team has implemented an RDF Site Summary ( RSS 1.0 ) news feed that makes the content in the center column available to others to repurpose reuse as they will. News syndication sites may merge the headlines into a summary of the day's latest news, others may display the headlines as links as a service to their readers, and, increasingly, individuals may subscribe to this feed with a desktop application. These desktop RSS readers allow their users to keep track of potentially hundreds of sites, without having to visit each one in their browser.
Numerous sites all over the Web provide RSS 1.0 feeds. <a href="#example33"> Example 33 40 is an example of the W3C feed </a>: (from a different date):
<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <channel rdf:about="http://www.w3.org/2000/08/w3c-synd/home.rss"> <title>The World Wide Web Consortium</title> <description>Leading the Web to its Full Potential...</description> <link>http://www.w3.org/</link> <dc:date>2002-10-28T08:07:21Z</dc:date> <items> <rdf:Seq> <rdf:li rdf:resource="http://www.w3.org/News/2002#item164"/> <rdf:li rdf:resource="http://www.w3.org/News/2002#item168"/> <rdf:li rdf:resource="http://www.w3.org/News/2002#item167"/> </rdf:Seq> </items> </channel> <item rdf:about="http://www.w3.org/News/2002#item164"> <title>User Agent Accessibility Guidelines Become a W3C Proposed Recommendation</title> <description>17 October 2002: W3C is pleased to announce the advancement of User Agent Accessibility Guidelines 1.0 to Proposed Recommendation. Comments are welcome through 14 November. Written for developers of user agents, the guidelines lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological). The companion Techniques Working Draft is updated. Read about the Web Accessibility Initiative. (News archive)</description> <link>http://www.w3.org/News/2002#item164</link> <dc:date>2002-10-17</dc:date> </item> <item rdf:about="http://www.w3.org/News/2002#item168"> <title>Working Draft of Authoring Challenges for Device Independence Published</title> <description>25 October 2002: The Device Independence Working Group has released the first public Working Draft of Authoring Challenges for Device Independence. The draft describes the considerations that Web authors face in supporting access to their sites from a variety of different devices. It is written for authors, language developers, device experts and developers of Web applications and authoring systems. Read about the Device Independence Activity (News archive)</description> <link>http://www.w3.org/News/2002#item168</link> <dc:date>2002-10-25</dc:date> </item> <item rdf:about="http://www.w3.org/News/2002#item167"> <title>CSS3 Last Call Working Drafts Published</title> <description>24 October 2002: The CSS Working Group has released two Last Call Working Drafts and welcomes comments on them through 27 November. CSS3 module: text is a set of text formatting properties and addresses international contexts. CSS3 module: Ruby is properties for ruby, a short run of text alongside base text typically used in East Asia. CSS3 module: The box model for the layout of textual documents in visual media is also updated. Cascading Style Sheets (CSS) is a language used to render structured documents like HTML and XML on screen, on paper, and in speech. Visit the CSS home page. (News archive)</description> <link>http://www.w3.org/News/2002#item167</link> <dc:date>2002-10-24</dc:date> </item> </rdf:RDF> deleted text:
As <a href="#example33"> Example 33 40 shows, the format is designed for content that can be packaged into easily distinguishable sections. News sites, web Web logs, sports scores, stock quotes, and the like are all use-cases for RSS 1.0.
The RSS feed can be requested by any application able to "speak" HTTP. More recently, however, RSS 1.0 applications are splitting into three different categories:
<item>
</tt>
s
out,
and
add
them
together
again
into
one
large
group.
The
whole
group
is
then
made
searchable.
In
this
way,
one
can
search
for
the
latest
news
on,
for
example,
"Java"
from
perhaps
thousands
of
sites,
without
having
to
search
them
all.
RSS 1.0 is extensible by design. By importing additional RDF vocabularies (or modules as they are known within the RSS development community), the RSS 1.0 author can provide large amounts of metadata and handling instructions to the recipient of the file. Modules can, as with more general RDF vocabularies, be written by anyone. Currently there are 3 official modules and 19 proposed modules readily recognized by the community at large. These modules range from the complete Dublin Core module to more specialized RSS-centric modules such as the Aggregation module .
Care should be taken when discussing "RSS" is in the scope of RDF. There are currently two RSS specification strands. One strand (RSS 0.91,0.92,0.93,0.94 and 2.0) does not use RDF. The other strand (RSS 0.9 and 1.0) does.
Electric utilities use power system models for a number of different purposes. For example, simulations of power systems are necessary for planning and security analysis. Power system models are also used in actual operations, e.g., by the Energy Management Systems (EMS) used in energy control centers. An operational power system model can consist of thousands of classes of information. In addition to using these models in-house, utilities need to exchange system modeling information, both in planning, and for operational purposes, e.g., for coordinating transmission and ensuring reliable operations. However, individual utilities use different software for these purposes, and as a result the system models are stored in different formats, making the exchange of these models difficult.
In order to support the exchange of power system models, utilities needed to agree on common definitions of power system entities and relationships. To support this, the Electric Power Research Institute (EPRI) a non-profit energy research consortium, developed a deleted text: <a href="http://standards.ces.com/cim/"> Common Information Model </a> (CIM). (CIM) [CIM] . The CIM specifies common semantics for power system resources, their attributes, and relationships. In addition, to further support the ability to electronically exchange CIM models, the power industry has developed CIM/XML , a language for expressing CIM models in XML. CIM/XML is an RDF application, using RDF and RDF Schema to organize its XML structures. The North American Electric Reliability Council (NERC) (an industry-supported organization formed to promote the reliability of electricity delivery in North America) has adopted CIM/XML as the standard for exchanging models between power transmission system operators. The CIM/XML format is also going through an IEC international standardization process. An excellent discussion of CIM/XML can be found in [DWZ01] . [NB: This power industry CIM should not be confused with the CIM developed by the Distributed Management Task Force for defining representing management information for distributed software, network, and enterprise environments. The DMTF CIM also has an XML representation, but does not currently use RDF.] RDF, although independent research is underway in that direction.]
The CIM can represent all of the major objects of an electric utility as object classes and attributes, as well as their relationships. CIM uses these object classes and attributes to support the integration of independently developed applications between vendor specific EMS systems, or between an EMS system and other systems that are concerned with different aspects of power system operations, such as generation or distribution management.
The
CIM
is
specified
as
a
set
of
class
diagrams
using
the
Unified
Modeling
Language
(UML).
The
base
class
of
the
CIM
is
the
<tt>
PowerSystemResource
</tt>
class,
with
other
more
specialized
classes
such
as
<tt>
Substation
</tt>,
<tt>
,
Switch
</tt>,
,
and
<tt>
Breaker
</tt>
being
defined
as
subclasses.
CIM/XML
represents
the
CIM
as
an
RDF
schema
Schema
vocabulary,
and
uses
RDF/XML
as
the
language
for
exchanging
specific
system
models.
<a href="#example34">
Example
34
41
shows
examples
of
CIM/XML
class
and
property
definitions:
<rdfs:Class rdf:ID="PowerSystemResource"> <rdfs:label xml:lang="en">PowerSystemResource</rdfs:label> <rdfs:comment>"A power system component that can be either an individual element such as a switch or a set of elements such as an substation. PowerSystemResources that are sets such as a substation. PowerSystemResources that are sets could be members of other sets. For example a Switch is a member of a Substation and a Substation could be a member of a division of a Company"</rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID="Breaker"> <rdfs:label xml:lang="en">Breaker</rdfs:label> <rdfs:subClassOf rdf:resource="#Switch" /> <rdfs:comment>"A mechanical switching device capable of making, carrying, and breaking currents under normal circuit conditions and also making, carrying for a specified time, and breaking currents under specified abnormal circuit conditions e.g. those of short circuit. The typeName is the type of breaker, e.g., oil, air blast, vacuum, SF6."</rdfs:comment> </rdfs:Class> <rdf:Property rdf:ID="Breaker.ampRating"> <rdfs:label xml:lang="en">ampRating</rdfs:label> <rdfs:domain rdf:resource="#Breaker" /> <rdfs:range rdf:resource="#CurrentFlow" /> <rdfs:comment>"Fault interrupting rating in amperes"</rdfs:comment> </rdf:Property> deleted text:
CIM/XML
uses
only
a
subset
of
the
complete
RDF/XML
syntax,
in
order
to
simplify
serialization
of
expressing
the
models.
In
addition,
CIM/XML
implements
some
extensions
to
the
RDF
Schema
vocabulary
(defined
in
the
<tt>
cims:
</tt>
namespace)
to
vocabulary.
These
extensions
support
the
description
of
inverse
roles
and
multiplicity
(cardinality)
constraints
describing
how
many
instances
of
a
given
property
are
allowed
for
a
given
resource
deleted text:
from
the
CIM
UML
diagrams
(allowable
values
for
a
multiplicity
declaration
are
zero-or-one,
exactly-one,
zero-or-more,
one-or-more).
The
properties
in
<a href="#example35">
Example
35
42
illustrate
these
extensions:
extensions
(which
are
identified
by
a
cims:
QName
prefix):
<rdf:Property rdf:ID="Breaker.OperatedBy"> <rdfs:label xml:lang="en">OperatedBy</rdfs:label> <rdfs:domain rdf:resource="#Breaker" /> <rdfs:range rdf:resource="#ProtectionEquipment" /> <cims:inverseRoleName rdf:resource="#ProtectionEquipment.Operates" /> <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" /> <rdfs:comment>"Circuit breakers may be operated by protection relays."</rdfs:comment> </rdf:Property> <rdf:Property rdf:ID="ProtectionEquipment.Operates"> <rdfs:label xml:lang="en">Operates</rdfs:label> <rdfs:domain rdf:resource="#ProtectionEquipment" /> <rdfs:range rdf:resource="#Breaker" /> <cims:inverseRoleName rdf:resource="#Breaker.OperatedBy" /> <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" /> <rdfs:comment>"Circuit breakers may be operated by protection relays."</rdfs:comment> </rdf:Property>
EPRI has conducted successful interoperability tests using CIM/XML to exchange real-life, large-scale models (involving, in the case of one test, data describing over 2000 substations) between a variety of vendor products, and validating that these models would be correctly interpreted by typical utility applications. Although the CIM was originally intended for EMS systems, it is also being extended to support power distribution and other applications as well.
The Object Management Group has adopted an object interface standard to access CIM power system models called the Data Access Facility [DAF] . Like the CIM/XML language, the DAF is based on the RDF model and shares the same deleted text: RDFS CIM schema. However, while CIM/XML enables a model to be exchanged as a document, DAF enables an application to access the model as a set of objects.
CIM/XML illustrates the useful role RDF can play in supporting XML-based exchange of information that is naturally expressed as entity-relationship or object-oriented classes, attributes, and relationships (even when that information will not necessarily be Web-accessible). In these cases, RDF provides a basic structure for the XML in support of identifying objects, and using them in structured relationships. This connection is illustrated by a number of applications using RDF/XML for information interchange, as well as a number of projects investigating linkages between RDF (or ontology languages such as DAML+OIL) OWL) and UML (and its XML representations). </p> <p> The need for additional declarative power illustrated by the CIM/XML's need to add extend RDF Schema to support cardinality constraints to CIM/XML shows and inverse relationships also illustrates the type kinds of requirement leading requirements that have led to the development of more powerful RDF-based schema/ontology languages such as DAML+OIL or and OWL described in Section 5.5 . Such languages may be appropriate in supporting many similar modeling applications in the future.
Finally, CIM/XML also illustrates an important fact for those looking for additional examples of "RDF in the Field": sometimes languages are described as "XML" languages, or systems are described as using "XML", and the "XML" they are actually using is RDF/XML, i.e., they are RDF applications. Sometimes it is necessary to go fairly far into the description of the language or system in order to find this out (in some examples that have been found, RDF is never explicitly mentioned at all, but sample data clearly shows it is RDF/XML). Moreover, in applications such as CIM/XML, the RDF that is created will not be readily found on the Web, since it is intended for information exchange between software components rather than for general access (although future scenarios could be imagined in which more of this type of RDF would become Web-accessible).
Structured metadata using controlled vocabularies such as SNOMED RT (Systematized Nomenclature of Medicine Reference Terminology) and MeSH (Medical Subject Headings) plays an important role in medicine, enabling more efficient literature searches and aiding in the distribution and exchange of medical knowledge [COWAN] . At the same time, the field of medicine is rapidly changing, and with that comes the need to develop additional vocabularies.
The objective of the Gene Ontology (GO) Consortium [GO] is to provide controlled vocabularies to describe specific aspects of gene products. Collaborating databases annotate their gene products (or genes) with GO terms, providing references and indicating what kind of evidence is available to support the annotations. The use of common GO terms by these databases facilitates uniform queries across them. The GO ontologies are structured to allow both attribution and querying to be performed at different levels of granularity. The GO vocabularies are dynamic, since knowledge of gene and protein roles in cells is accumulating and changing.
The three organizing principles of the GO are molecular function, function , biological process , and cellular component. component . A gene product has one or more molecular functions and is used in one or more biological processes; it may be, or may be associated with, one or more cellular components. Definitions of the terms within all three of these ontologies are contained in a single (text) definition file. XML deleted text: (actually, RDF/XML) formatted versions, containing all three ontology files and all available definitions, are generated monthly.
Function, process and component are represented as directed acyclic graphs (DAGs) or networks. A child term may be an "instance" of its parent term (isa relationship) or a component of its parent term (part-of relationship). A child term may have more than one parent term and may have a different class of relationship with its different parents. Synonyms and cross-references to external databases are also represented in the ontologies. RDF was chosen for use GO uses RDF/XML facilities to represent the relationships between terms in the XML versions of the ontologies ontologies, because of its flexibility in representing these graph structures, as well as its widespread tool support. At the same time, GO currently uses non -RDF nested XML structures within the term descriptions, so the language used is not pure RDF/XML.
<a href="#example36"> Example 36 43 shows some sample GO information from the GO documentation :
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE go:go> <go:go xmlns:go="http://www.geneontology.org/xml-dtd/go.dtd#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <go:version timestamp="Wed May 9 23:55:02 2001" /> <rdf:RDF> <go:term rdf:about="http://www.geneontology.org/go#GO:0003673"> <go:accession>GO:0003673</go:accession> <go:name>Gene_Ontology</go:name> <go:definition></go:definition> </go:term> <go:term rdf:about="http://www.geneontology.org/go#GO:0003674"> <go:accession>GO:0003674</go:accession> <go:name>molecular_function</go:name> <go:definition>The action characteristic of a gene product.</go:definition> <go:part-of rdf:resource="http://www.geneontology.org/go#GO:0003673" /> <go:dbxref> <go:database_symbol>go</go:database_symbol> <go:reference>curators</go:reference> </go:dbxref> </go:term> <go:term rdf:about="http://www.geneontology.org/go#GO:0016209"> <go:accession>GO:0016209</go:accession> <go:name>antioxidant</go:name> <go:definition></go:definition> <go:isa rdf:resource="http://www.geneontology.org/go#GO:0003674" /> <go:association> <go:evidence evidence_code="ISS"> <go:dbxref> <go:database_symbol>fb</go:database_symbol> <go:reference>fbrf0105495</go:reference> </go:dbxref> </go:evidence> <go:gene_product> <go:name>CG7217</go:name> <go:dbxref> <go:database_symbol>fb</go:database_symbol> <go:reference>FBgn0038570</go:reference> </go:dbxref> </go:gene_product> </go:association> <go:association> <go:evidence evidence_code="ISS"> <go:dbxref> <go:database_symbol>fb</go:database_symbol> <go:reference>fbrf0105495</go:reference> </go:dbxref> </go:evidence> <go:gene_product> <go:name>Jafrac1</go:name> <go:dbxref> <go:database_symbol>fb</go:database_symbol> <go:reference>FBgn0040309</go:reference> </go:dbxref> </go:gene_product> </go:association> </go:term> </rdf:RDF> </go:go>
<a href="#example36">
Example
36
43
illustrates
that
<tt>
go:term
</tt>
is
the
basic
element.
The
In
some
cases,
the
GO
has
added
defined
its
own
extensions
to
the
terms
rather
than
using
RDF
vocabulary
(they
do
not
use
RDFS).
Schema.
For
example,
term
<tt>
GO:0016209
</tt>
has
the
element
<tt>
<go:isa
rdf:resource="http://www.geneontology.org/go#GO:0003674"
/>
</tt>.
.
This
tag
represents
the
relationship
"
<tt>
GO:0016209
</tt>
isa
<tt>
GO:0003674
</tt>
",
or,
in
English,
"Antioxidant
is
a
molecular
function."
Another
specialized
relationship
is
<tt>
go:part-of
</tt>.
.
For
example,
<tt>
GO:0003674
</tt>
has
the
element
<tt>
<go:part-of
rdf:resource="http://www.geneontology.org/go#GO:0003673"
/>
</tt>.
.
This
says
that
"Molecular
function
is
part
of
the
Gene
Ontology".
Every annotation must be attributed to a source, which may be a literature reference, another database or a computational analysis. The annotation must indicate what kind of evidence is found in the cited source to support the association between the gene product and the GO term. A simple controlled vocabulary is used to record evidence. Examples include:
The
<tt>
go:dbxref
</tt>
element
represents
the
term
in
an
external
database,
and
<tt>
go:association
</tt>
represents
the
gene
associations
of
each
term.
<tt>
go:association
</tt>
can
have
both
<tt>
go:evidence
</tt>,
,
which
holds
a
<tt>
go:dbxref
</tt>
to
the
evidence
supporting
the
association,
and
a
<tt>
go:gene_product
</tt>,
,
which
contains
the
gene
symbol
and
<tt>
go:dbxref
</tt>.
.
These
elements
illustrate
that
the
GO
XML
syntax
is
not
"pure"
RDF/XML,
since
the
nesting
of
other
elements
within
these
elements
does
not
conform
to
the
alternate
node/predicate
arc
"stripes"
described
in
Sections
2.1
and
2.2
of
[RDF-SYNTAX]
.
The GO illustrates a number of interesting points. First, it shows that the value of using XML for information exchange can be enhanced by structuring that XML using RDF. This is particularly true for data that has a an overall graph or network structure, rather than being a strict hierarchy. The GO is also another example in which the data using RDF will not necessarily appear for direct use on the Web (although the files are Web-accessible). It is also another example of data which is, on the surface, described as "XML", but on closer examination is RDF/XML. In addition, uses RDF/XML facilities (albeit not "pure" RDF/XML). Finally, the GO illustrates the role RDF can play as a basis for representing ontologies. This role will be further enhanced once richer RDF-based languages for specifying ontologies, such as the DAML+OIL or OWL languages discussed in Section 5.5 , become more widely used. In fact, a Gene Ontology Next Generation project is currently developing a representation of the GO ontologies in these richer languages.
In recent years a large number of new mobile devices for browsing the web Web have appeared. Many of these devices have highly divergent capabilities including a wide range of input and output capabilities as well as different levels of language support. Mobile devices may also have widely differing network connectivity capabilities. Users of these new devices expect a usable presentation regardless of the device's capabilities or the current network characteristics. Likewise, users want their dynamically changing preferences (e.g. turn audio on/off) to be considered when content or an application is presented. The reality, however, is that device heterogeneity heterogeneity, and the lack of a standard way for users to convey their preferences to the server, may result in: content that cannot be stored on the device, content that cannot be displayed displayed, or content that violates the desires of the user. Additionally, the resulting content may take too long to convey over the network to the client device.
A solution for addressing these problems is for a client to encode its delivery context - the device's capabilities, the user's preferences, the network characteristics, etc. - in such a way that a server can use the context to customize content for the device and user (see [DIPRINC] for a definition of delivery context). The W3C's Composite Capabilities/Preferences Profile (CC/PP) specification [CC/PP] helps to address this problem by defining a generic framework for describing a delivery context.
The CC/PP framework defines a relatively simple structure - a two-level hierarchy of components and attribute/value pairs. A component may be used to capture a part of a delivery context (e.g. network characteristics, software supported by a device device, or the hardware characteristics of a device). A component may contain one or more attributes . For example a component that encodes user preferences may contain an attribute to specify whether or not AudioOutput is desired.
CC/PP defines its structure (the hierarchy described above) using RDF Schema (see [CC/PP] for details of the structure schema). A CC/PP vocabulary defines specific components and their attributes. [CC/PP] , however, does not define such vocabularies. Instead, vocabularies are defined by other organizations or applications (as described below). [CC/PP] also does not define a protocol for transporting an instance of a CC/PP vocabulary.
An instance of a CC/PP vocabulary is called a profile . CC/PP attributes are encoded as RDF properties in a profile. <a href="#example37"> Example 37 44 shows a profile fragment of user preferences for a user that prefers an audio presentation:
<ccpp:component> <rdf:Description rdf:ID="UserPreferences"> <rdf:type rdf:resource="http://www.example.org/profiles/prefs/v1_0#UserPreferences"/> <ex:AudioOutput>Yes</ex:AudioOutput> <ex:Graphics>No</ex:Graphics> <ex:Languages> <rdf:Seq> <rdf:li>en-cockney</rdf:li> <rdf:li>en</rdf:li> </rdf:Seq> </ex:Languages> </rdf:Description> </ccpp:component>
There are several advantages to using RDF in this application. First, a profile encoded via CC/PP may include attributes that were defined in schemas created by different organizations. RDF is a natural fit for these profiles because no single organization is likely to create a super schema for the aggregated profile data. A second advantage of RDF is that it facilitates (by virtue of its graph-based data model) the insertion of arbitrary attributes (RDF properties) into a profile. This is particularly useful for profiles that include frequently changing data such as location information.
The Open Mobile Alliance has defined the User Agent Profile (UAProf) [UAPROF] - a CC/PP-based framework that includes a vocabulary for describing device capabilities, user agent capabilities, network characteristics, etc., as well as a protocol for transporting a profile. UAProf defines six components including: HardwarePlatform , SoftwarePlatform , NetworkCharacteristics and BrowserUA . It also defines several attributes for each of its components although a component's attributes are not fixed - they may be supplemented or overridden. <a href="#example38"> Example 38 45 shows a fragment of UAProf's HardwarePlatform component:
<prf:component> <rdf:Description rdf:ID="HardwarePlatform"> <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20021113#HardwarePlatform"/> <prf:ScreenSizeChar>15x6</prf:ScreenSizeChar> <prf:BitsPerPixel>2</prf:BitsPerPixel> <prf:ColorCapable>No</prf:ColorCapable> <prf:BluetoothProfile> <rdf:Bag> <rdf:li>headset</rdf:li> <rdf:li>dialup</rdf:li> <rdf:li>lanaccess</rdf:li> </rdf:Bag> </prf:BluetoothProfile> </rdf:Description> </prf:component>
The UAProf protocol supports both static profiles and dynamic profiles. A static profile is accessed via a URI. This has several advantages: a client's request to a server only contains a URI rather a potentially verbose XML document (thus minimizing over the air traffic); the client does not have to store and/or create the profile; the implementation burden on a client is relatively light-weight. Dynamic profiles are created on-the-fly and consequently do not have an associated URI. They may consist of a profile fragment containing a difference from a static profile, but they may also contain unique data that is not included in the client's static profile. A request may contain any number of static profiles and dynamic profiles. However, the ordering of the profiles is important as later profiles override earlier profiles in the request. See [UAPROF] for more information about UAProf's protocol and its rules for resolving multiple profiles.
Several other communities (i.e. 3GPP's TS 26.234 [3GPP] and the WAP Forum's Multimedia Messaging Service Client Transactions Specification [MMS-CTR] ) have defined vocabularies based on CC/PP. As a result, a profile may take advantage of the distributed nature of RDF and include components defined from various vocabularies. <a href="#example39"> Example 39 46 deleted text: is shows such a profile:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#" xmlns:mms="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#" xmlns:pss="http://www.3gpp.org/profiles/PSS/ccppschema-YYYYMMDD#"> <rdf:Description rdf:ID="SomeDevice"> <prf:component> <rdf:Description rdf:ID="Streaming"> <rdf:type rdf:resource="http://www.3gpp.org/profiles/PSS/ccppschema-PSS5#Streaming"/> <pss:AudioChannels>Stereo</pss:AudioChannels> <pss:VideoPreDecoderBufferSize>30720</pss:VideoPreDecoderBufferSize> <pss:VideoInitialPostDecoderBufferingPeriod>0</pss:VideoInitialPostDecoderBufferingPeriod> <pss:VideoDecodingByteRate>16000</pss:VideoDecodingByteRate> </rdf:Description> </prf:component> <prf:component> <rdf:Description rdf:ID="MmsCharacteristics"> <rdf:type rdf:resource="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#Streaming"/> <mms:MmsMaxMessageSize>2048</mms:MmsMaxMessageSize> <mms:MmsMaxImageResolution>80x60</mms:MmsMaxImageResolution> <mms:MmsVersion>2.0</mms:MmsVersion> </rdf:Description> </prf:component> <prf:component> <rdf:Description rdf:ID="PushCharacteristics"> <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20010330#PushCharacteristics"/> <prf:Push-MsgSize>1024</prf:Push-MsgSize> <prf:Push-MaxPushReq>5</prf:Push-MaxPushReq> <prf:Push-Accept> <rdf:Bag> <rdf:li>text/html</rdf:li> <rdf:li>text/plain</rdf:li> <rdf:li>image/gif</rdf:li> </rdf:Bag> </prf:Push-Accept> </rdf:Description> </prf:component> </rdf:Description> </rdf:RDF>
The definition of a delivery context and the data within a context will continually evolve. Consequently, RDF's inherent extensibility, and thus support for dynamically changing vocabularies, make RDF a good framework for encoding a delivery context.
In Section 1 </a>, we indicated that the RDF Specification consists of a number of documents (in addition to this Primer):
We have The Primer has already discussed the subjects of the first three several of these documents, basic RDF concepts (in Section 2 ), the RDF/XML syntax (in Section 3 ) and RDF Schema (in Section 5 ). In this section, we This section briefly describe describes the remaining documents, documents (even though there have already been numerous references to [RDF-SEMANTICS] as well), in order to explain their role in the complete specification of RDF.
As we've seen discussed in the preceding sections, RDF is intended to be used to express statements about resources in the form of a graph, using specific vocabularies (names of resources, properties, classes, etc.). RDF is also intended to be the foundation for more advanced languages, such as those discussed in Section 5.5 . In order to serve these purposes, the "meaning" of an RDF graph must be defined in a very precise manner.
Exactly what constitutes the "meaning" of an RDF graph in a broad very general sense may depend on many factors, including social conventions, conventions within a user community to interpret user-defined RDF classes and properties in specific ways, comments in natural language, or links to other content-bearing documents ( <a href="#ref-rdf-concepts"> [RDF-CONCEPTS] </a> provides further discussion of the various notions of meaning documents. As noted briefly in RDF). Much Section 2.2 , much of the meaning conveyed in these forms will not be directly accessible to machine processing, although this meaning may be used by human interpreters of the RDF information, or by programmers writing software to perform various kinds of processing on that RDF information. However, RDF statements also have a formal meaning which determines, with mathematical precision, the conclusions (or entailments ) that machines can draw from an a given RDF graph. The RDF Semantics [RDF-SEMANTICS] document defines this formal meaning, using a technique called model theory for specifying the semantics of a formal language. [RDF-SEMANTICS] also defines the semantic extensions to the RDF language represented by RDF Schema, and by individual datatypes. In other words, the RDF model theory provides the formal underpinnings for all of the concepts we have described. RDF concepts. Based on the semantics defined in the model theory, it is simple to translate an RDF graph into a logical expression with essentially the same meaning.
The RDF Test Cases [RDF-TESTS] supplement the textual RDF specifications with test cases (examples) corresponding to particular technical issues addressed by the RDF Core Working Group. To help describe these examples, the Test Cases document introduces a notation called <a href="http://www.w3.org/TR/2002/WD-rdf-testcases-20021112/#ntriples"> N-Triples , which provides the basis for the triples notation used throughout this Primer. The test cases are published in machine-readable form at Web locations referenced by the Test Cases document, so developers can use these as the basis for automated testing of RDF software.
The test cases are divided into a number of categories:
The test cases are not a complete specification of RDF, and are not intended to take precedence over the normative specification documents. However, they are intended to illustrate the intent of the RDF Core Working Group with respect to the design of RDF, and developers may find these test cases helpful should the wording of the specifications be unclear on any point of detail.
This document has benefited from inputs from many members of the RDF Core Working Group . Specific thanks are due to Art Barstow, Dave Beckett, Dan Brickley, Ron Daniel, Ben Hammersley, Martyn Horner, Graham Klyne, Sean Palmer, Patrick Stickler, Aaron Swartz, Ralph Swick, and Garret Wilson who, together with the many people who commented on earlier versions of the Primer, provided valuable contributions to this document.
In addition, this document contains a significant contribution from Pat Hayes, Sergey Melnik, and Patrick Stickler, who led the development of the RDF datatype facilities described in the RDF family of specifications.
Frank Manola also thanks The MITRE Corporation , Frank's employer during most of the preparation of this document, for its support of his RDF Core Working Group activities under a MITRE Sponsored Research grant.
Note: This section is intended to provide a brief introduction to URIs. The definitive specification of URIs is RFC 2396 [URIS] , which should be consulted for further details. Additional discussion of URIs can also be found in Naming and Addressing: URIs, URLs, ... [NAMEADDRESS] .
As we saw discussed in Section 2.1 , the Web provides a general form of identifier, called the Uniform Resource Identifier (URI), for identifying (naming) resources on the Web. Unlike URLs, URIs are not limited to identifying things that have network locations, or use other computer access mechanisms. A number of different URI schemes (URI forms) have been already been developed, and are being used, for various purposes. Examples include:
http:
</tt>
(Hypertext
Transfer
Protocol,
for
Web
pages)
mailto:
</tt>
(email
addresses),
e.g.,
mailto:em@w3.org
ftp:
</tt>
(File
Transfer
Protocol)
urn:
</tt>
(Uniform
Resource
Names,
intended
to
be
persistent
location-independent
resource
identifiers),
e.g.,
<tt>
urn:isbn:0-520-02356-0
</tt>
(for
a
book)
deleted text: URIs are defined in <a href="http://www.isi.edu/in-notes/rfc2396.txt"> RFC 2396 </a> <a href="#ref-uri"> [URIS] </a>. Some additional discussion of URIs can be found in <a href="http://www.w3.org/Addressing/"> Naming and Addressing: URIs, URLs, ... </a> <a href="#ref-nameaddress"> [NAMEADDRESS] </a>. A list of existing URI schemes can be found in Addressing Schemes [ADDRESS-SCHEMES] , and it is a good idea to consider adapting one of the existing schemes for any specialized identification purposes you may have, purposes, rather than trying to invent a new one.
No
one
person
or
organization
controls
who
makes
URIs
or
how
they
can
be
used.
While
some
URI
schemes,
such
as
URL's
<tt>
http:
</tt>,
,
depend
on
centralized
systems
such
as
DNS,
other
schemes,
such
as
<tt>
freenet:
</tt>,
,
are
completely
decentralized.
This
means
that,
as
with
any
other
kind
of
name,
you
don't
need
no
one
needs
special
authority
or
permission
to
create
a
URI
for
something.
Also,
you
anyone
can
create
URIs
for
to
refer
to
things
you
don't
they
do
not
own,
just
as
in
ordinary
language
you
anyone
can
use
whatever
name
you
they
like
for
things
you
don't
they
do
not
own.
As
deleted text:
we
also
saw
noted
in
Section
2.1
,
RDF
uses
URI
references
[URIS]
to
name
subjects,
predicates,
and
objects
in
RDF
statements.
A
URI
reference
(or
URIref
)
is
a
URI,
together
with
an
optional
fragment
identifier
at
the
end.
For
example,
the
URI
reference
<tt>
http://www.example.org/index.html#section2
</tt>
consists
of
the
URI
<tt>
http://www.example.org/index.html
</tt>
and
(separated
by
the
"#"
character)
the
fragment
identifier
<tt>
Section2
</tt>.
.
URIrefs
may
be
either
absolute
or
relative
.
An
absolute
URIref
refers
to
a
resource
independently
of
the
context
in
which
the
URIref
appears,
e.g.,
the
URIref
<tt>
http://www.example.org/index.html
</tt>.
.
A
relative
URIref
is
a
shorthand
form
of
an
absolute
URIref,
where
some
prefix
of
the
URIref
is
missing,
and
information
from
the
context
in
which
the
URIref
appears
is
required
to
fill
in
the
missing
information.
For
example,
the
relative
URIref
<tt>
otherpage.html
</tt>,
,
when
appearing
in
a
resource
<tt>
http://www.example.org/index.html
</tt>,
,
would
be
filled
out
to
the
absolute
URIref
<tt>
http://www.example.org/otherpage.html
</tt>.
.
A
URIref
without
a
URI
part
is
considered
a
reference
to
the
current
document
(the
document
in
which
it
appears).
So,
an
empty
URIref
within
a
document
is
considered
equivalent
to
the
URIref
of
the
document
itself.
A
URIref
consisting
of
just
a
fragment
identifier
is
considered
equivalent
to
the
URIref
of
the
document
in
which
it
appears,
with
the
fragment
identifier
appended
to
it.
For
example,
within
<tt>
http://www.example.org/index.html
</tt>,
,
if
<tt>
#section2
</tt>
appeared
as
a
URIref,
it
would
be
considered
equivalent
to
the
absolute
URIref
<tt>
http://www.example.org/index.html#section2
</tt>.
.
[RDF-CONCEPTS] notes that RDF graphs (the abstract models) do not use relative URIrefs, i.e., the subjects, predicates, and objects (and datatypes in typed literals) in RDF statements must always be identified independently of any context. However, a specific concrete RDF syntax, such as RDF/XML, may allow relative URIrefs to be used as a shorthand for absolute URIrefs in certain situations. RDF/XML does permit such use of relative URIrefs, and some of the RDF/XML examples in this Primer illustrate such uses. deleted text: You should consult [RDF-SYNTAX] should be consulted for further details.
Both RDF and web Web browsers use URIrefs to identify things. However, RDF and browsers interpret URIrefs in slightly different ways. This is because RDF uses URIrefs only to identify things, while browsers also use URIrefs to retrieve things. Often there is no effective difference, but in some cases the difference can be significant. One obvious difference is that when a URIref is used in a browser, there is the expectation that it identifies a resource that can actually be retrieved: that something is actually "at" the location identified by the URI. However, in RDF a URIref may be used to identify something, such as a person, that cannot be retrieved on the web. Web. People sometimes use RDF together with a convention that, when a URIref is used to identify an RDF resource, a page containing descriptive information about that resource will be placed on the web Web "at" that URI, so that the URIref can be used in a browser to retrieve that information. This can be a useful convention in some circumstances, although it creates a difficulty in distinguishing the identity of the original resource from the identity of the web Web page describing it (a subject discussed further in Section 2.3 ). However, this convention is not an explicit part of the definition of RDF, and RDF itself does not assume that a URIref identifies something that can be retrieved.
Another difference is in the way URIrefs with fragment identifiers are handled. Fragment identifiers are often seen in the URLs that identify HTML documents, where they serve to identify a specific place within the document identified by the URL. In normal HTML usage, where URI references are used to retrieve the indicated resources, the two URIrefs:
<tt>
http://www.example.org/index.html
</tt>
<tt>
http://www.example.org/index.html#Section2
</tt>
are related (they both refer to the same document, the second one identifying a location within the first one). However, as noted already, RDF uses URI references purely to identify resources, not to retrieve them, and RDF assumes no particular relationship between these two URIrefs. As far as RDF is concerned, they are syntactically different URI references, and hence may refer to unrelated things. (This doesn't This does not mean that the HTML-defined containment relationship might not exist, just that RDF doesn't does not assume that a relationship exists based only on the fact that the URI parts of the URI references are the same.) same.
Carrying this point further, RDF does not assume that there is any relationship between URI references that share a common leading string, whether there is a fragment identifier or not. For example, as far as RDF is concerned, the two URIrefs:
http://www.example.org/foo.html
http://www.example.org/bar.html
have
no
particular
relationship
even
though
both
of
them
start
with
the
string
http://www.example.org/
.
To
RDF,
they
are
simply
different
resources,
because
their
URIrefs
are
different.
(They
may
in
fact
be
two
files
located
in
the
same
directory,
but
RDF
does
not
assume
this
or
any
other
relationship
exists).
Note: This section is intended to provide a brief introduction to XML. The definitive specification of XML is [XML] , which should be consulted for further details.
The Extensible Markup Language [XML] was designed to allow anyone to design their own document format and then write a document in that format. Like HTML documents (Web pages), XML documents contain text. This text consists primarily of plain text content, and markup in the form of tags . This markup allows a processing program to interpret the various pieces of content (called elements ). In HTML, the set of permissible tags, and their interpretation, is defined by the HTML specification. However, XML allows users to define their own markup languages (tags and the structures in which they can appear) adapted to their own specific requirements. requirements (the RDF/XML language described in Section 3 is one such XML markup language). For example, the following is a simple passage marked up using an XML-based markup language:
<sentence><person webid="http://example.com/#johnsmith">I</person> just got a new pet <animal>dog</animal>.</sentence>
Elements
delimited
by
tags
(
<tt>
<sentence>
</tt>,
<tt>
,
<person>
</tt>,
,
etc.)
are
introduced
to
reflect
a
particular
structure
associated
with
the
passage.
The
tags
allow
a
program
written
with
an
understanding
of
these
particular
elements,
and
the
way
they
are
structured,
to
properly
interpret
the
passage.
For
example,
one
of
the
elements
in
this
example
is
<tt>
<animal>dog</animal>
</tt>.
.
This
consists
of
the
start-tag
<tt>
<animal>
</tt>,
,
the
element
content
,
and
a
matching
end-tag
<tt>
</animal>
</tt>.
.
This
<tt>
animal
</tt>
element,
together
with
the
<tt>
person
</tt>
element,
are
nested
as
part
of
the
content
of
the
<tt>
sentence
</tt>
element.
The
nesting
is
possibly
clearer
(and
closer
to
some
of
the
more
"structured"
XML
contained
in
the
rest
of
this
Primer)
if
the
sentence
is
written:
<sentence> <person webid="http://example.com/#johnsmith">I</person> just got a new pet <animal>dog</animal>. </sentence>
In
some
cases,
an
element
may
have
no
content.
This
can
be
written
either
by
enclosing
no
content
within
the
pair
of
delimiting
start-
and
end-tags,
as
in
<tt>
<animal></animal>
</tt>,
,
or
by
using
a
shorthand
form
of
tag
called
an
empty-element
tag
,
as
in
<tt>
<animal/>
</tt>.
.
In
some
cases,
a
start-tag
(or
empty-element
tag)
may
contain
qualifying
information
other
than
the
tag
name,
in
the
form
of
attributes
.
For
example,
the
start-tag
of
the
<tt>
<person>
</tt>
element
contains
the
attribute
<tt>
webid="http://example.com/#johnsmith"
</tt>
(presumably
identifying
the
specific
person
referred
to).
An
attribute
consists
of
a
name,
an
equal
sign,
and
a
value
(enclosed
in
quotes).
This
particular
markup
language
uses
the
words
"sentence,"
"person,"
and
"animal"
as
tag
names
in
an
attempt
to
convey
some
of
the
meaning
of
the
elements;
and
they
would
convey
meaning
to
an
English-speaking
person
reading
it,
or
to
a
program
specifically
written
to
interpret
this
vocabulary.
However,
there
is
no
built-in
meaning
here.
For
example,
to
non-English
speakers,
or
to
a
program
not
written
to
understand
this
markup,
the
element
<tt>
<person>
</tt>
may
mean
absolutely
nothing.
Take
the
following
passage,
for
example:
<dfgre><reghh bjhbw="http://example.com/#johnsmith">I</reghh> just got a new pet <yudis>dog</yudis>.</dfgre>
To a machine, this passage has exactly the same structure as the previous example. However, it is no longer clear to an English-speaker what is being said, because the tags are no longer English words. Moreover, others may have used the same words as tags in their own markup languages, but with completely different intended meanings. For example, "sentence" in another markup language might refer to the amount of time that a convicted criminal must serve in a penal institution. So additional mechanisms must be provided to help keep XML vocabulary straight.
To prevent confusion, it is necessary to uniquely identify markup elements. This is done in XML using XML Namespaces [XML-NS] . A namespace is just a way of identifying a part of the Web (space) which acts as a qualifier for a specific set of names. A namespace is created for an XML markup language by creating a URI for it. By qualifying tag names with the URIs of their namespaces, anyone can create their own tags and properly distinguish them from tags with identical spellings created by others. A useful practice convention that is sometimes followed is to create a Web page to describe the markup language (and the intended meaning of the tags) and use the URL of that Web page as the URI for its namespace. However, this is just a convention, and neither XML nor RDF assumes that a namespace URI identifies a retrievable Web resource. The following example illustrates the use of an XML namespace.
<my:sentence xmlns:my="http://example.com/xml/documents/"> <user:sentence xmlns:user="http://example.com/xml/documents/"> <my:person my:webid="http://example.com/#johnsmith">I</my:person> <user:person user:webid="http://example.com/#johnsmith">I</user:person> just got a new pet <my:animal>dog</my:animal>. just got a new pet <user:animal>dog</user:animal>. </my:sentence> </user:sentence>
In
this
example,
the
attribute
<tt>
xmlns:my="http://example.com/xml/documents/"
</tt>
xmlns:user="http://example.com/xml/documents/"
declares
a
namespace
for
use
in
this
piece
of
XML.
It
maps
the
prefix
<tt>
my
</tt>
user
to
the
namespace
URI
<tt>
http://example.com/xml/documents/
</tt>.
.
The
XML
content
can
then
use
qualified
names
(or
QNames
)
like
<tt>
my:person
</tt>
user:person
as
tags.
A
QName
contains
a
prefix
that
identifies
a
namespace,
followed
by
a
colon,
and
then
a
local
name
for
an
XML
tag
or
attribute
name.
By
using
namespace
URIs
to
distinguish
specific
groups
of
names,
and
qualifying
tags
with
the
URIs
of
the
namespaces
they
come
from,
as
in
this
example,
we
don't
have
there
is
no
need
to
worry
about
tag
names
conflicting.
Two
tags
having
the
same
spelling
are
considered
the
same
only
if
they
also
have
the
same
namespace
URIs.
Every XML document is required to be well-formed . This means the XML document must satisfy a number of syntactic conditions, for example, that every start-tag must have a matching end-tag, and that elements must be properly nested within other elements (elements may not overlap). The complete set of well-formedness conditions is defined in [XML] .
In
addition,
an
XML
document
may
optionally
include
an
XML
document
type
declaration
to
define
additional
constraints
on
the
structure
of
the
document,
and
to
support
the
use
of
predefined
units
of
text
within
the
document.
The
document
type
declaration
(introduced
with
DOCTYPE
)
contains
or
points
to
declarations
that
define
a
grammar
for
the
document.
This
grammar
is
known
as
a
document
type
definition
,
or
DTD
.
The
declarations
in
a
DTD
specify
such
things
as
which
XML
elements
and
attributes
may
appear
in
XML
documents
corresponding
to
the
DTD,
the
relationships
of
these
elements
and
attributes
(e.g.,
which
elements
can
be
nested
within
which
other
elements,
or
which
attributes
may
appear
with
which
elements),
and
whether
elements
or
attributes
are
required
or
optional.
The
document
type
declaration
can
point
to
a
set
of
declarations
located
outside
the
document
(called
the
external
subset
,
which
can
be
used
to
allow
common
declarations
to
be
shared
among
multiple
documents),
can
include
the
declarations
directly
in
the
document
(called
the
internal
subset
),
or
can
have
both
internal
and
external
DTD
subsets.
The
complete
DTD
for
a
document
consists
of
both
subsets
taken
together.
A
simple
example
of
an
XML
document
with
a
document
type
declaration
is
shown
in
Example
47
:
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "http://www.example.org/dtds/hello.dtd">
<greeting>Hello, world!</greeting>
In
this
case,
the
document
has
only
an
external
DTD
subset,
and
the
system
identifier
http://www.example.org/dtds/hello.dtd
provides
its
location
(a
URIref).
An XML document is valid if it has an associated document type declaration and the document complies with the constraints defined by the document type declaration.
An RDF/XML document is only required to be well-formed XML; it is not intended to be validated against an XML DTD (or an XML Schema), and [RDF-SYNTAX] does not specify a normative DTD that could be used for validating arbitrary RDF/XML (an appendix of [RDF-SYNTAX] does provide a non-normative example schema for RDF/XML). As a result, more detailed discussion of XML DTD grammars is beyond the scope of this Primer. Further information on XML DTDs and XML validation can be found in [XML] , and the numerous books on XML.
However, there is one use of XML document type declarations that is relevant to RDF/XML, and that is their use in defining XML entities . An XML entity declaration essentially associates a name with a string of characters. When the entity name is used elsewhere within an XML document, XML processors replace the entity name with the corresponding string. This provides a way to abbreviate long strings such as URIrefs, and can help make XML documents containing such strings more readable. Using a document type declaration just to declare XML entities is allowed, and can be useful, even when (as in RDF/XML) the documents are not intended to be validated.
In
RDF/XML
documents,
entities
are
generally
declared
within
the
document
itself,
i.e.,
using
only
an
internal
DTD
subset
(one
reason
for
this
is
that
RDF/XML
is
not
intended
to
be
validated,
and
non-validating
XML
processors
are
not
required
to
process
external
DTD
subsets).
For
example,
providing
the
document
type
declaration
shown
in
Example
48
at
the
beginning
of
an
RDF/XML
document
allows
the
URIrefs
in
that
document
for
the
rdf
,
rdfs
,
and
xsd
namespaces
to
be
abbreviated
as
&rdf;
,
&rdfs;
,
and
&xsd;
respectively,
as
shown
in
the
example.
<?xml version='1.0'?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
]>
<rdf:RDF
xmlns:rdf = "&rdf;"
xmlns:rdfs = "&rdfs;"
xmlns:xsd = "&xsd;">
...RDF statements...
</rdf:RDF>
This appendix documents changes (other than very minor editorial changes) made since the 23 January 2003 last call Working Draft of the RDF Primer.
This section documents changes made since the 23 January 2003 last call Working Draft that are reflected in the 05 September 2003 Working Draft of the RDF Primer. Each entry contains:
Change Entries:
rdf:parseType
This section documents changes made since the 05 September 2003 Working Draft of the RDF Primer.
Change Entries:
mailto:jane@example.org
within
angle
brackets
since
this
is
a
mailto
URI
and
not
a
QName.
rdf:RDF
element
can
be
omitted
where
the
XML
can
be
determined
to
be
RDF/XML
by
context.
DOCTYPE
for
declaring
entities
does
not
mean
that
full
XML
validation
is
applicable
to
RDF/XML.