You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
6614 lines
315 KiB
6614 lines
315 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator"
|
|
content="HTML Tidy for Linux/x86 (vers 1st March 2002), see www.w3.org" />
|
|
|
|
<title>RDF Primer</title>
|
|
<style type="text/css">
|
|
/*<![CDATA[*/
|
|
.new { color: #FF0000 }
|
|
|
|
.example {font-family: monospace; }
|
|
|
|
.figure {
|
|
font-weight: bold;
|
|
text-align: center; }
|
|
|
|
.primative {
|
|
padding: 1em;
|
|
margin: 0.1em 3.5em 0.1em 0.1em;
|
|
background-color: #eddddd;
|
|
border: 1px solid #cfcfcf; }
|
|
|
|
.ptriple {
|
|
padding: 1em;
|
|
margin: 0.1em 3.5em 0.1em 0.1em;
|
|
background-color: #eedddd;
|
|
border: 1px solid #cfcfcf; }
|
|
|
|
.caveat {
|
|
padding: 1em;
|
|
margin: 0.1em 3.5em 0.1em 0.1em;
|
|
border: 1px solid #cfcfcf; }
|
|
|
|
.principle { background: #f7ebd7; color: black; border: solid black thin; padding: .1em; margin-left: 5%; margin-right: 5%}
|
|
|
|
div.example {
|
|
padding: 1em;
|
|
margin: 0.1em 3.5em 0.1em 0.1em;
|
|
background-color: #efeff5;
|
|
border: 1px solid #cfcfcf; }
|
|
|
|
div.exampleOuter {
|
|
/*
|
|
border: 4px double gray;
|
|
*/
|
|
margin: 0em;
|
|
padding: 0em;
|
|
}
|
|
|
|
div.exampleInner {
|
|
color: black;
|
|
/* tan */
|
|
/* background-color: #d2b48c; */
|
|
/* cyan */
|
|
/* background-color: #99ffff; */
|
|
/* mauve */
|
|
background-color: #efeff5;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 1px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px;
|
|
margin: 0em;
|
|
}
|
|
|
|
div.exampleInner pre {
|
|
margin-left: 0em;
|
|
margin-top: 0em;
|
|
margin-bottom: 0em;
|
|
font-family: monospace;
|
|
/* font-size: smaller */
|
|
}
|
|
|
|
body {
|
|
background-color: #FFFFFF;
|
|
}
|
|
|
|
div.c1 {text-align:center}
|
|
|
|
/*]]>*/
|
|
</style>
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD" />
|
|
</head>
|
|
|
|
<body>
|
|
<div class="head">
|
|
<a href="http://www.w3.org/"><img height="48" width="72"
|
|
alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a>
|
|
|
|
<h1 id="title">RDF Primer</h1>
|
|
|
|
<h2 id="hstatus">W3C Working Draft 23 January 2003</h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2003/WD-rdf-primer-20030123/">http://www.w3.org/TR/2003/WD-rdf-primer-20030123/</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/rdf-primer/">http://www.w3.org/TR/rdf-primer/</a></dd>
|
|
|
|
<dt>Previous version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-primer-20021111/">http://www.w3.org/TR/2002/WD-rdf-primer-20021111/</a></dd>
|
|
|
|
<dt>Editors:</dt>
|
|
|
|
<dd>Frank Manola, The MITRE Corporation, <a
|
|
href="mailto:fmanola@mitre.org">fmanola@mitre.org</a></dd>
|
|
|
|
<dd>Eric Miller, W3C, <a
|
|
href="mailto:em@w3.org">em@w3.org</a></dd>
|
|
|
|
<dt>Series Editor:</dt>
|
|
|
|
<dd>Brian McBride, Hewlett-Packard Laboratories, <a
|
|
href="mailto:bwm@hplb.hpl.hp.com">bwm@hplb.hpl.hp.com</a></dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
© 2003 <a href="http://www.w3.org/"><acronym
|
|
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
|
|
(<a href="http://www.lcs.mit.edu/"><acronym
|
|
title="Massachusetts Institute of Technology">MIT</acronym></a>,
|
|
<a href="http://www.ercim.org/"><acronym
|
|
title="European Research Consortium for Informatics and Mathematics">
|
|
ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>),
|
|
All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">
|
|
liability</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">
|
|
trademark</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software">software
|
|
licensing</a> rules apply.</p>
|
|
<hr title="Separator for header" />
|
|
</div>
|
|
|
|
<h2><a id="abstract" name="abstract">Abstract</a></h2>
|
|
|
|
<p>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
|
|
<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.</p>
|
|
|
|
<h2><a name="status" id="status"></a>Status of this Document</h2>
|
|
|
|
<p>This is a W3C <a href="http://www.w3.org/2001/sw/RDFCore/">RDF
|
|
Core Working Group</a> Last Call Working Draft produced as part of
|
|
the W3C <a href="http://www.w3.org/2001/sw/">Semantic Web
|
|
Activity</a> (<a href="http://www.w3.org/2001/sw/Activity">Activity
|
|
Statement</a>).</p>
|
|
|
|
<p>This document is in the Last Call review period, which ends on
|
|
21 February 2003. This document has been endorsed by the RDF Core
|
|
Working Group.</p>
|
|
|
|
<p>This document 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.</p>
|
|
|
|
<p>In conformance with <a
|
|
href="http://www.w3.org/Consortium/Process-20010719/#ipr">W3C
|
|
policy</a> requirements, known patent and <acronym
|
|
title="Intellectual Property Rights">IPR</acronym> constraints
|
|
associated with this Working Draft are detailed on the <a
|
|
href="http://www.w3.org/2001/sw/RDFCore/ipr-statements"
|
|
rel="disclosure">RDF Core Working Group Patent Disclosure</a>
|
|
page.</p>
|
|
|
|
<p>Comments on this document are invited and should be sent to the
|
|
public mailing list <a
|
|
href="mailto:www-rdf-comments@w3.org">www-rdf-comments@w3.org</a>.
|
|
An archive of comments is available at <a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-comments/">http://lists.w3.org/Archives/Public/www-rdf-comments/</a>.</p>
|
|
|
|
<p>This is a public W3C Last Call Working Draft for review by W3C
|
|
Members and other interested parties. This section describes the
|
|
status of this document at the time of its publication. It is a
|
|
draft document and may be updated, replaced, or obsoleted by other
|
|
documents at any time. It is inappropriate to use W3C Working
|
|
Drafts as reference material or to cite as other than "work in
|
|
progress". A list of current W3C Recommendations and other
|
|
technical documents can be found at <a
|
|
href="/TR/">http://www.w3.org/TR/</a>.</p>
|
|
|
|
<h2><a id="toc" name="toc">Table of Contents</a></h2>
|
|
|
|
<p class="toc"> 1. <a
|
|
href="#intro">Introduction</a><br />
|
|
2. <a href="#statements">Making Statements About
|
|
Resources</a><br />
|
|
2.1 <a
|
|
href="#basicconcepts">Basic Concepts</a><br />
|
|
2.2 <a href="#rdfmodel">The
|
|
RDF Model</a><br />
|
|
2.3 <a
|
|
href="#structuredproperties">Structured Property Values and Blank
|
|
Nodes</a><br />
|
|
2.4 <a
|
|
href="#typedliterals">Typed Literals</a><br />
|
|
2.5 <a
|
|
href="#conceptsummary">Concepts Summary</a><br />
|
|
3. <a href="#rdfxml">An XML Syntax for RDF:
|
|
RDF/XML</a><br />
|
|
3.1 <a
|
|
href="#basicprinciples">Basic Principles</a><br />
|
|
3.2 <a
|
|
href="#newresources">Abbreviating and Organizing RDF
|
|
URIrefs</a><br />
|
|
3.3 <a
|
|
href="#rdfxmlsummary">RDF/XML Summary</a><br />
|
|
4. <a href="#othercapabilities">Other RDF
|
|
Capabilities</a><br />
|
|
4.1 <a href="#containers">RDF
|
|
Containers</a><br />
|
|
4.2 <a href="#collections">RDF
|
|
Collections</a><br />
|
|
4.3 <a href="#reification">RDF
|
|
Reification</a><br />
|
|
4.4 <a href="#rdfvalue">More
|
|
on Structured Values: rdf:value</a><br />
|
|
5. <a href="#rdfschema">Defining RDF Vocabularies: RDF
|
|
Schema</a><br />
|
|
5.1 <a
|
|
href="#schemaclasses">Defining Classes</a><br />
|
|
5.2 <a
|
|
href="#properties">Defining Properties</a><br />
|
|
5.3 <a
|
|
href="#interpretingschema">Interpreting RDF Schema
|
|
Declarations</a><br />
|
|
5.4 <a
|
|
href="#otherschema">Other Schema Information</a><br />
|
|
5.5 <a
|
|
href="#richerschemas">Richer Schema Languages</a><br />
|
|
6. <a href="#applications">Some RDF Applications: RDF
|
|
in the Field</a><br />
|
|
6.1 <a
|
|
href="#dublincore">Dublin Core Metadata Initiative</a><br />
|
|
6.2 <a
|
|
href="#prism">PRISM</a><br />
|
|
6.3 <a
|
|
href="#xpackage">XPackage</a><br />
|
|
6.4 <a href="#rss">RSS 1.0:
|
|
RDF Site Summary</a><br />
|
|
6.5 <a
|
|
href="#cimxml">CIM/XML</a><br />
|
|
6.6 <a href="#geneont">Gene
|
|
Ontology Consortium</a><br />
|
|
6.7 <a
|
|
href="#devcap">Describing Device Capabilities and User
|
|
Preferences</a><br />
|
|
7. <a href="#otherparts">Other Parts of the RDF
|
|
Specification</a><br />
|
|
7.1 <a href="#semantics">RDF
|
|
Semantics</a><br />
|
|
7.2 <a href="#testcases">Test
|
|
Cases</a><br />
|
|
8. <a href="#references">References</a><br />
|
|
8.1 <a
|
|
href="#normative-references">Normative References</a><br />
|
|
8.2 <a
|
|
href="#informational-references">Informational References</a><br />
|
|
9. <a href="#acknowledgements">Acknowledgments</a></p>
|
|
|
|
<h3><a id="appendices" name="appendices">Appendices</a></h3>
|
|
|
|
<p class="appendix"> A. <a href="#identifiers">More on
|
|
Uniform Resource Identifiers (URIs)</a><br />
|
|
B. <a href="#documents">More on the Extensible Markup
|
|
Language (XML)</a></p>
|
|
<hr />
|
|
|
|
<div class="section">
|
|
<h2 id="introduction"><a id="intro" name="intro"></a>1.
|
|
Introduction</h2>
|
|
|
|
<p>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
|
|
<em>identified</em> on the Web, even when they can't be directly
|
|
<em>retrieved</em> on the Web. Examples include information about
|
|
items available from online shopping facilities (e.g.,
|
|
information about specifications, prices, and availability), or
|
|
the description of a Web user's preferences for information
|
|
delivery.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>RDF is based on the idea of identifying things using Web
|
|
identifiers (URIs), and describing resources in terms of simple
|
|
properties and property values. This enables RDF to represent
|
|
simple statements about resources as a <em>graph</em> 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 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 <a
|
|
href="#figure1">Figure 1</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig1dec16.png"
|
|
alt="An RDF Graph Describing Eric Miller" /><br />
|
|
<a id="figure1" name="figure1">Figure 1: An RDF Graph
|
|
Describing Eric Miller</a>
|
|
</div>
|
|
|
|
<p><a href="#figure1">Figure 1</a> illustrates that RDF uses URIs
|
|
to identify:</p>
|
|
|
|
<ul>
|
|
<li>individuals, e.g., Eric Miller, identified by
|
|
<tt>http://www.w3.org/People/EM/contact#me</tt></li>
|
|
|
|
<li>kinds of things, e.g., Person, identified by
|
|
<tt>http://www.w3.org/2000/10/swap/pim/contact#Person</tt></li>
|
|
|
|
<li>properties of those things, e.g., mailbox, identified by
|
|
<tt>http://www.w3.org/2000/10/swap/pim/contact#mailbox</tt></li>
|
|
|
|
<li>values of those properties, e.g. <tt>mailto:em@w3.org</tt>
|
|
as the value of the mailbox property (RDF also uses character
|
|
strings such as "Eric Miller" as the values of some
|
|
properties)</li>
|
|
</ul>
|
|
|
|
<p>RDF also provides an XML-based syntax (called RDF/XML) for
|
|
recording and exchanging these graphs. <a
|
|
href="#example1">Example 1</a> is a small chunk of RDF in RDF/XML
|
|
corresponding to the graph in <a href="#figure1">Figure
|
|
1</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example1" name="example1">Example 1: RDF/XML
|
|
Describing Eric Miller</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>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>.</p>
|
|
|
|
<p>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 can also describe cars, businesses, people, news
|
|
events, etc. In addition, RDF properties themselves have URIs, to
|
|
precisely identify the kind of relationship that exists between
|
|
the linked items.</p>
|
|
|
|
<p>The following documents contribute to the specification of
|
|
RDF:</p>
|
|
|
|
<ul>
|
|
<li><a href="http://www.w3.org/TR/rdf-concepts/">RDF Concepts
|
|
and Abstract Syntax</a> <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML
|
|
Syntax Specification</a> <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-schema/">RDF Vocabulary
|
|
Description Language 1.0: RDF Schema</a> <a
|
|
href="#ref-rdf-vocabulary">[RDF-VOCABULARY]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-mt/">RDF Semantics</a> <a
|
|
href="#ref-rdf-semantics">[RDF-SEMANTICS]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-testcases/">RDF Test
|
|
Cases</a> <a href="#ref-rdf-tests">[RDF-TESTS]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-primer/">RDF Primer</a>
|
|
(this document)</li>
|
|
</ul>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>What does RDF look like?</li>
|
|
|
|
<li>What information can RDF represent?</li>
|
|
|
|
<li>How is RDF information created, accessed, and
|
|
processed?</li>
|
|
|
|
<li>How can existing information be combined with RDF?</li>
|
|
</ul>
|
|
|
|
<p>The Primer is a <em>non-normative</em> 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 understand RDF, but they may not always
|
|
provide definitive or fully-complete answers. In such cases, you
|
|
should refer to the relevant normative parts of the RDF
|
|
specification. To help you do this, we provide links pointing to
|
|
the relevant parts of the normative specifications.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a id="statements" name="statements"></a>2. Making Statements
|
|
About Resources</h2>
|
|
|
|
<p>RDF is intended to provide a simple way to make statements
|
|
about Web resources, e.g., Web pages. In this section, we
|
|
describe the basic ideas behind the way RDF provides these
|
|
capabilities (the normative specification describing these
|
|
concepts is <a href="http://www.w3.org/TR/rdf-concepts/">RDF
|
|
Concepts and Abstract Syntax</a> <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a>).</p>
|
|
|
|
<div class="section">
|
|
<h3><a id="basicconcepts" name="basicconcepts"></a>2.1 Basic
|
|
Concepts</h3>
|
|
|
|
<p>Imagine that we want to state 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:</p>
|
|
|
|
<p class="ptriple"><tt><u>http://www.example.org/index.html</u>
|
|
has a <u>creator</u> whose value is <u>John Smith</u></tt></p>
|
|
|
|
<p>We've underlined parts of this statement to illustrate that,
|
|
in order to describe the properties of something, we need ways
|
|
to name, or identify, a number of things:</p>
|
|
|
|
<ul>
|
|
<li>We need a way to identify the thing we want to describe
|
|
(the Web page, in this case)</li>
|
|
|
|
<li>We need a way to identify a specific property (creator,
|
|
in this case) of the thing that we want to describe</li>
|
|
|
|
<li>We need a way to identify the thing we want to assign as
|
|
the value of this property (who the creator is), for the
|
|
thing we want to describe</li>
|
|
</ul>
|
|
|
|
<p>In this statement, we've used the Web page's URL (Uniform
|
|
Resource Locator) to identify it. In addition, we've used the
|
|
word "creator" to identify the property we want to talk about,
|
|
and the two words "John Smith" to identify the thing (a person)
|
|
we want to say is the value of this property.</p>
|
|
|
|
<p>We could state other properties of this Web page 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, to
|
|
specify the date the page was created, and the language in
|
|
which the page is written, we could write the additional
|
|
statements:</p>
|
|
|
|
<p class="ptriple"><tt><u>http://www.example.org/index.html</u>
|
|
has a <u>creation-date</u> whose value is <u>August 16,
|
|
1999</u></tt><br />
|
|
<tt><u>http://www.example.org/index.html</u> has a
|
|
<u>language</u> whose value is <u>English</u></tt></p>
|
|
|
|
<p>RDF is based on the idea that the things we want to describe
|
|
have <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-property">properties</a>
|
|
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 <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-subject">subject</a>.
|
|
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 <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-predicate">predicate</a>,
|
|
and the part that identifies the value of that property is
|
|
called the <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-object">object</a>.
|
|
So, taking the English statement</p>
|
|
|
|
<p class="ptriple"><tt><u>http://www.example.org/index.html</u>
|
|
has a <u>creator</u> whose value is <u>John Smith</u></tt></p>
|
|
|
|
<p>the RDF terms for the various parts of the statement
|
|
are:</p>
|
|
|
|
<ul>
|
|
<li>the <dfn>subject</dfn> is the URL
|
|
<tt>http://www.example.org/index.html</tt></li>
|
|
|
|
<li>the <dfn>predicate</dfn> is the word "creator"</li>
|
|
|
|
<li>the <dfn>object</dfn> is the phrase "John Smith"</li>
|
|
</ul>
|
|
|
|
<p>However, while English is good for communicating between
|
|
(English-speaking) humans, RDF is about making
|
|
<em>machine-processable</em> statements. To make these kinds of
|
|
statements suitable for processing by machines, we need two
|
|
things:</p>
|
|
|
|
<ul>
|
|
<li>a system of machine-processable identifiers that allows
|
|
us to identify a subject, predicate, or object in a statement
|
|
without any possibility of confusion with a similar-looking
|
|
identifier that might be used by someone else on the
|
|
Web.</li>
|
|
|
|
<li>a machine-processable language for representing these
|
|
statements and exchanging them between machines.</li>
|
|
</ul>
|
|
|
|
<p>Fortunately, the existing Web architecture provides both
|
|
these necessary facilities.</p>
|
|
|
|
<p>As we've seen, the Web already provides one form of
|
|
identifier, the <dfn>Uniform Resource Locator</dfn> (URL). We
|
|
used a URL in our 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 also like to be able to record information about many
|
|
things that, unlike Web pages, don't have network locations or
|
|
URLs.</p>
|
|
|
|
<p>The Web provides a more general form of identifier for these
|
|
purposes, called the <a
|
|
href="http://www.isi.edu/in-notes/rfc2396.txt">Uniform Resource
|
|
Identifier</a> (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, we can create a URI to refer to anything we want to talk
|
|
about, including</p>
|
|
|
|
<ul>
|
|
<li>network-accessible things, such as an electronic
|
|
document, an image, a service (e.g., "today's weather report
|
|
for Los Angeles"), or a group of other resources.</li>
|
|
|
|
<li>things that are not network-accessible, such as human
|
|
beings, corporations, and bound books in a library.</li>
|
|
|
|
<li>abstract concepts that don't physically exist, like the
|
|
concept of a "creator".</li>
|
|
</ul>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-URI-reference">URI
|
|
references</a> <a href="#ref-uri">[URIS]</a>. A URI reference
|
|
(or <em>URIref</em>) is a URI, together with an optional
|
|
<em>fragment identifier</em> 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 <em>resource</em> 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 <a
|
|
href="#identifiers">Appendix A</a> and <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a>.</p>
|
|
|
|
<p>To represent RDF statements in a machine-processable way,
|
|
RDF uses the <a
|
|
href="http://www.w3.org/TR/1998/REC-xml-19980210.html">Extensible
|
|
Markup Language</a> <a href="#ref-xml">[XML]</a>. 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 <em>RDF/XML</em>,
|
|
for use in representing RDF information, and for exchanging it
|
|
between machines. An example of RDF/XML was given in <a
|
|
href="#intro">Section 1</a>. That example (<a
|
|
href="#example1">Example 1</a>) 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 interpret that content. <a
|
|
href="#documents">Appendix B</a> provides further background on
|
|
XML in general. The specific RDF/XML syntax used for RDF is
|
|
described in more detail in <a href="#rdfxml">Section
|
|
3</a>.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="rdfmodel" name="rdfmodel"></a>2.2 The RDF Model</h3>
|
|
|
|
<p>Now that we've introduced RDF's basic statement concepts,
|
|
URI references for identifying things we want to talk about on
|
|
the Web, and RDF/XML as a machine-processable way of
|
|
representing RDF statements, we can describe how RDF lets us
|
|
use URIs to make statements about resources. In the
|
|
introduction, we said that RDF was based on the idea of
|
|
expressing simple statements about resources, where those
|
|
statements are built using subjects, predicates, and objects.
|
|
In RDF, we could represent our original English statement:</p>
|
|
|
|
<p class="ptriple"><tt><u>http://www.example.org/index.html</u>
|
|
has a <u>creator</u> whose value is <u>John Smith</u></tt></p>
|
|
|
|
<p>by an RDF statement having:</p>
|
|
|
|
<ul>
|
|
<li>a subject <tt>http://www.example.org/index.html</tt></li>
|
|
|
|
<li>a predicate
|
|
<tt>http://purl.org/dc/elements/1.1/creator</tt></li>
|
|
|
|
<li>and an object
|
|
<tt>http://www.example.org/staffid/85740</tt></li>
|
|
</ul>
|
|
|
|
<p>Note how we have used URIrefs 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 this further later in this
|
|
section.</p>
|
|
|
|
<p>RDF models statements as nodes and arcs in a graph. RDF's <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#section-data-model">graph
|
|
model</a> is defined in <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a>. In this notation,
|
|
a statement is represented by:</p>
|
|
|
|
<ul>
|
|
<li>a node for the subject, labeled with its URIref</li>
|
|
|
|
<li>a node for the object, labeled with its URIref</li>
|
|
|
|
<li>an arc for the predicate, labeled with its URIref,
|
|
directed from the subject node to the object node.</li>
|
|
</ul>
|
|
|
|
<p>So the RDF statement above would be represented by the graph
|
|
shown in <a href="#figure2">Figure 2</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig2dec16.png"
|
|
alt="A Simple RDF Statement" /><br />
|
|
<a id="figure2" name="figure2">Figure 2: A Simple RDF
|
|
Statement</a>
|
|
</div>
|
|
|
|
<p>Groups of statements are represented by corresponding groups
|
|
of nodes and arcs. So if we wanted to also represent the
|
|
additional statements</p>
|
|
|
|
<p class="ptriple"><tt><u>http://www.example.org/index.html</u>
|
|
has a <u>creation-date</u> whose value is <u>August 16,
|
|
1999</u></tt><br />
|
|
<tt><u>http://www.example.org/index.html</u> has a
|
|
<u>language</u> whose value is <u>English</u></tt></p>
|
|
|
|
<p>we could, by using suitable URIrefs to name the properties
|
|
"creation-date" and "language", use the graph shown in <a
|
|
href="#figure3">Figure 3</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig3dec16.png"
|
|
alt="Several Statements About the Same Resource" /><br />
|
|
<a id="figure3" name="figure3">Figure 3: Several Statements
|
|
About the Same Resource</a>
|
|
</div>
|
|
|
|
<p><a href="#figure3">Figure 3</a> illustrates that the objects
|
|
of RDF statements may be either resources identified by
|
|
URIrefs, or constant values (called <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#section-Literals">literals</a>)
|
|
represented by character strings, in order to represent certain
|
|
kinds of property values. Literals may not be the subjects or
|
|
predicates of RDF statements. (The simple character string
|
|
literals we will use for now are called <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-plain-literal">plain
|
|
literals</a>, to distinguish them from the <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-typed-literal">typed
|
|
literals</a> we will introduce in <a
|
|
href="#typedliterals">Section 2.4</a>. The various kinds of
|
|
literals that can be used in RDF statements are defined in <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a>.) 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).</p>
|
|
|
|
<p>Sometimes it is not convenient to draw graphs when
|
|
discussing them, so an alternative way of writing down the
|
|
statements, called <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-rdf-triple">triples</a>,
|
|
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), in that order.
|
|
The triples representing the three statements shown in <a
|
|
href="#figure3">Figure 3</a> would be written in full as:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<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" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 <em>graph model</em> of the statements. The
|
|
notation used to represent or depict the graph is
|
|
secondary.</p>
|
|
|
|
<p>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. For
|
|
convenience, we will use a shorthand way of writing triples in
|
|
the rest of this Primer, and also in other RDF specifications.
|
|
In this shorthand, we can substitute a <em>qualified name</em>
|
|
(or <em>QName</em>) without angle brackets as an abbreviation
|
|
of a full URI reference. A QName contains a prefix that has
|
|
been assigned to a namespace URI, followed by a colon, and then
|
|
a <em>local name</em> (QNames are discussed further in <a
|
|
href="#documents">Appendix B</a>). 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 will also make
|
|
extensive use in these examples of several "well-known" QName
|
|
prefixes (which we will use without explicitly specifying them
|
|
each time), defined as follows:<br />
|
|
<br />
|
|
prefix <tt>rdf:</tt>, namespace URI:
|
|
<tt>http://www.w3.org/1999/02/22-rdf-syntax-ns#</tt><br />
|
|
prefix <tt>rdfs:</tt>, namespace URI:
|
|
<tt>http://www.w3.org/2000/01/rdf-schema#</tt><br />
|
|
prefix <tt>dc:</tt>, namespace URI:
|
|
<tt>http://purl.org/dc/elements/1.1/</tt><br />
|
|
prefix <tt>daml:</tt>, namespace URI:
|
|
<tt>http://www.daml.org/2001/03/daml+oil#</tt><br />
|
|
prefix <tt>ex:</tt>, namespace URI:
|
|
<tt>http://www.example.org/</tt> (or
|
|
<tt>http://www.example.com/</tt>)<br />
|
|
prefix <tt>xsd:</tt>, namespace URI:
|
|
<tt>http://www.w3.org/2001/XMLSchema#</tt></p>
|
|
|
|
<p>We will also use variations on the "example" prefix
|
|
<tt>ex:</tt> as needed in the examples, where this will not
|
|
cause confusion, for example,<br />
|
|
<br />
|
|
prefix <tt>exterms:</tt>, namespace URI:
|
|
<tt>http://www.example.org/terms/</tt> (for terms used by our
|
|
example organization),<br />
|
|
prefix <tt>exstaff:</tt>, namespace URI:
|
|
<tt>http://www.example.org/staffid/</tt> (for our example
|
|
organization's staff identifiers),<br />
|
|
prefix <tt>ex2:</tt>, namespace URI:
|
|
<tt>http://www.domain2.example.org/</tt> (for a second example
|
|
organization), and so on.</p>
|
|
|
|
<p>Using our new shorthand, we can write the previous set of
|
|
triples as:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:index.html dc:creator exstaff:85740 .
|
|
|
|
ex:index.html exterms:creation-date "August 16, 1999" .
|
|
|
|
ex:index.html exterms:language "English" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The examples we've just given of RDF statements begin to
|
|
illustrate some of the advantages of using URIrefs as RDF's
|
|
basic way of identifying things. For instance, instead of
|
|
identifying the creator of the Web page in our first example by
|
|
the character string "John Smith", we've assigned 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 can be more precise in
|
|
our identification. That is, the creator of the page isn't 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 a URIref for the
|
|
creator of the page, it is a full-fledged resource, and we can
|
|
record additional information about him, such as his name, and
|
|
age, as in the graph shown in <a href="#figure4">Figure
|
|
4</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig4dec16.png"
|
|
alt="More Information About John Smith" /><br />
|
|
<a id="figure4" name="figure4">Figure 4: More Information
|
|
About John Smith</a>
|
|
</div>
|
|
|
|
<p>These examples also illustrate that RDF uses URIrefs as
|
|
<em>predicates</em> 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 the properties we use from
|
|
properties someone else may use that would otherwise be
|
|
identified by the same character string. For instance, in our
|
|
example, 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 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 that there are distinct
|
|
properties involved (even if a program cannot automatically
|
|
determine the distinct meanings). Another reason why it is
|
|
important to use URIrefs to identify properties is that it
|
|
allows us to treat RDF properties as resources themselves.
|
|
Since properties are resources, we can record descriptive
|
|
information 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.</p>
|
|
|
|
<p>Using URIrefs as subjects, predicates, and objects in RDF
|
|
statements allows us to begin to develop and use a shared
|
|
vocabulary on the Web, reflecting (and creating) a shared
|
|
understanding of the concepts we talk about. For example, in
|
|
the triple</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:index.html dc:creator exstaff:85740 .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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
|
|
<a href="#dublincore">Section 6.1</a>), 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, or any program, that understands
|
|
<tt>http://purl.org/dc/elements/1.1/creator</tt> will know
|
|
exactly what is meant by this relationship.</p>
|
|
|
|
<p>Of course, RDF's use of URIrefs doesn't solve all our
|
|
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.</p>
|
|
|
|
<p>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 actually "understand" such statements, of
|
|
course, but it can deal with them in a way that makes it seem
|
|
like it does. 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 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.</p>
|
|
|
|
<p>RDF statements are similar to a number of other formats for
|
|
recording information, such as:</p>
|
|
|
|
<ul>
|
|
<li>entries in a simple record or catalog listing describing
|
|
the resource in a data processing system.</li>
|
|
|
|
<li>rows in a simple relational database.</li>
|
|
|
|
<li>simple assertions in formal logic</li>
|
|
</ul>
|
|
|
|
<p>and information in these formats can be treated as RDF
|
|
statements, allowing RDF to be used to integrate data from many
|
|
sources.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="structuredproperties"
|
|
name="structuredproperties"></a>2.3 Structured Property Values
|
|
and Blank Nodes</h3>
|
|
|
|
<p>Things would be very simple if the only types of information
|
|
we had to record about things were obviously in the form of the
|
|
simple RDF statements 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
|
|
original example, we recorded the date the Web page was created
|
|
as a single <tt>exterms:creation-date</tt> property, with a
|
|
plain literal as its value. However, suppose we wanted to show,
|
|
as the value of the <tt>exterms:creation-date</tt> property,
|
|
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 whole address
|
|
out as a plain literal, as in the triple</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:address "1501 Grant Avenue, Bedford, Massachusetts 01730" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>However, suppose we wanted to record John's address as a
|
|
<em>structure</em> consisting of separate street, city, state,
|
|
and Zip code values? How do we do this in RDF?</p>
|
|
|
|
<p>We can represent such structured information in RDF by
|
|
considering the aggregate thing we want to talk about (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, we
|
|
create a new node to represent the concept of John Smith's
|
|
address, and assign that concept a new URIref to identify it,
|
|
say <tt>http://www.example.org/addressid/85740</tt> (which we
|
|
will abbreviate as <tt>exaddressid:85740</tt>). We then write
|
|
RDF statements (create additional arcs and nodes) with that
|
|
node as the subject, to represent the additional information,
|
|
producing the graph shown in <a href="#figure5">Figure
|
|
5</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig5dec16.png"
|
|
alt="Breaking Up John's Address" /><br />
|
|
<a id="figure5" name="figure5">Figure 5: Breaking Up John's
|
|
Address</a>
|
|
</div>
|
|
|
|
<p>or the triples:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:address exaddressid:85740 .
|
|
exaddressid:85740 exterms:street "1501 Grant Avenue" .
|
|
exaddressid:85740 exterms:city "Bedford" .
|
|
exaddressid:85740 exterms:state "Massachusetts" .
|
|
exaddressid:85740 exterms:Zip "01730" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Using this approach allows us to represent structured
|
|
information in RDF, but it can involve generating numerous
|
|
"intermediate" URIrefs 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
|
|
<em>drawing</em> of the graph representing the group of
|
|
statements shown in <a href="#figure5">Figure 5</a>, we didn't
|
|
really need the URIref we assigned to identify "John Smith's
|
|
address", since we could just as easily have drawn the graph as
|
|
in <a href="#figure6">Figure 6</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig6dec16.png" alt="Using a Blank Node" /><br />
|
|
<a id="figure6" name="figure6">Figure 6: Using a Blank
|
|
Node</a>
|
|
</div>
|
|
|
|
<p>In <a href="#figure6">Figure 6</a>, which is a perfectly
|
|
good RDF graph, we've used a node without a label to stand for
|
|
the concept of "John Smith's address". This unlabeled node, or
|
|
<a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-blank-node">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 <em>anonymous resources</em> in <a
|
|
href="#ref-rdfms">[RDF-MS]</a>.) However, we would need some
|
|
form of explicit identifier for that node if we wanted to
|
|
represent this graph as triples. To see this, we can try to
|
|
write the triples corresponding to what is shown in <a
|
|
href="#figure6">Figure 6</a>. What we would get would be
|
|
something like:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:address ??? .
|
|
??? exterms:street "1501 Grant Avenue" .
|
|
??? exterms:city "Bedford" .
|
|
??? exterms:state "Massachusetts" .
|
|
??? exterms:Zip "01730"
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 also need a way to differentiate
|
|
between these multiple blank nodes in a triples representation
|
|
of the graph. To do this, we use <a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-blank-node-id">blank
|
|
node identifiers</a>, having the form <tt>_:name</tt>, to
|
|
indicate the presence of blank nodes in triples. For instance,
|
|
in this example we might use the blank node identifier
|
|
<tt>_:johnaddress</tt> to refer to the blank node, in which
|
|
case the resulting triples might be:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:address _:johnaddress .
|
|
_:johnaddress exterms:street "1501 Grant Avenue" .
|
|
_:johnaddress exterms:city "Bedford" .
|
|
_:johnaddress exterms:state "Massachusetts" .
|
|
_:johnaddress exterms:Zip "01730" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 <a href="#figure6">Figure
|
|
6</a> 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 <em>single</em> 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.</p>
|
|
|
|
<p>At the beginning of this section, we noted that we can
|
|
represent aggregate structures, like John Smith's address, by
|
|
considering the aggregate thing we want to talk about as a
|
|
resource, and then making statements about that new resource.
|
|
This example illustrates an important aspect of RDF: RDF
|
|
directly represents only <em>binary</em> relationships, e.g.
|
|
the relationship between John Smith and the literal
|
|
representing his address. When we try to represent the
|
|
relationship between John and the group of separate
|
|
<em>components</em> of this address, we are dealing with an
|
|
<em>n-ary</em> (n-way) relationship (in this case, n=5) between
|
|
John and the street, city, state, and zip 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 this n-way relationship up
|
|
into a group of separate binary relationships. Blank nodes give
|
|
us one way to do this. Each time we have an n-ary relationship,
|
|
we can choose one of the participants as the subject of the
|
|
relationship (John in this case), and create a blank node to
|
|
represent the rest of the relationship (John's address in this
|
|
case). We can then represent the remaining participants in the
|
|
relationship (such as the city in our example) as separate
|
|
properties of the new resource represented by the blank
|
|
node.</p>
|
|
|
|
<p>Blank nodes also give us 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
|
|
<em>do</em> 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 may want to record information
|
|
about Jane's mailbox (e.g., the server it is on) as well as
|
|
about Jane herself (e.g., her current address), and using a
|
|
URIref for Jane based on her email address makes it difficult
|
|
to know which thing we're talking about. 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 may need to record information
|
|
about the Web page (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.</p>
|
|
|
|
<p>The fundamental problem is that using Jane's
|
|
<em>mailbox</em> as a stand-in for <em>Jane</em> isn't really
|
|
accurate: Jane and her mailbox are not the same thing, and
|
|
hence their identifiers should be different. When Jane herself
|
|
doesn't have a URI, a blank node gives us a more accurate way
|
|
of modeling this situation. We can represent Jane by a blank
|
|
node, and give the blank node an <tt>exterms:mailbox</tt>
|
|
property having the URIref <tt>mailto:jane@example.org</tt> as
|
|
its value. We can also assign the blank node an
|
|
<tt>rdf:type</tt> property with a value of
|
|
<tt>exterms:Person</tt> (we will discuss types in more detail
|
|
in the following sections), an <tt>exterms:name</tt> property
|
|
with a value of <tt>"Jane Smith"</tt>, and any other
|
|
descriptive information we might want to provide, as shown in
|
|
the following triples:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
_:jane exterms:mailbox mailto:jane@example.org .
|
|
_:jane rdf:type exterms:Person .
|
|
_:jane exterms:name "Jane Smith" .
|
|
_:jane exterms:empID "23748"
|
|
_:jane exterms:age "26" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>In practice, using blank nodes instead of URIrefs in these
|
|
cases doesn't change the way we actually handle this kind of
|
|
information very much. For example, if we know independently
|
|
that an email address uniquely identifies someone at
|
|
example.org (particularly if the address is unlikely to be
|
|
reused), we can still use that fact to associate information
|
|
about that person from multiple sources, even though the email
|
|
address is not the person's URI. For example, if we were to
|
|
find another piece of RDF on the web that described a book, and
|
|
gives the author's contact information as
|
|
<tt>mailto:jane@example.org</tt>, we might reasonably 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. This is discussed further in
|
|
<a href="#richerschemas">Section 5.5</a>.)</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="typedliterals" name="typedliterals"></a>2.4 Typed
|
|
Literals</h3>
|
|
|
|
<p>In the last section, we described how to handle situations
|
|
in which we needed to take property values represented by plain
|
|
literals, and break them up into structured values that
|
|
identify the individual parts of those property values. 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, we could
|
|
represent the value as a structure consisting of the month,
|
|
day, and year as separate pieces of information. However, so
|
|
far, we've followed the practice of representing any constant
|
|
values that serve as objects in RDF statements by these plain
|
|
(untyped) literals, even when we probably 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.</p>
|
|
|
|
<p>For example, in <a href="#figure4">Figure 4</a> we
|
|
illustrated an RDF graph recording information about John
|
|
Smith. In that graph, we recorded the value of John Smith's
|
|
<tt>exterms:age</tt> property as the plain literal "27", as
|
|
shown in <a href="#figure7">Figure 7</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig7dec16.png"
|
|
alt="Representing John Smith's Age" /><br />
|
|
<a id="figure7" name="figure7">Figure 7: Representing John
|
|
Smith's Age</a>
|
|
</div>
|
|
|
|
<p>In this case, our 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, an application reading that literal
|
|
"27" would only know to do that if the application was
|
|
explicitly given the information that the literal "27" was
|
|
intended to represent a number, and knew which number the
|
|
literal "27" was supposed to represent. The common practice in
|
|
programming languages or database systems is to provide this
|
|
kind of information by associating a <em>datatype</em> 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 <em>ten</em>, the number <em>two</em>,
|
|
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,
|
|
<a
|
|
href="http://www.w3.org/TR/rdf-concepts/#dfn-typed-literal">typed
|
|
literals</a> are used to provide this kind of information.</p>
|
|
|
|
<p>Using a typed literal, we could describe John Smith's age as
|
|
being the integer number <em>27</em> using the triple:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<http://www.example.org/staffid/85740> <http://www.example.org/terms/age> "27"^^<http://www.w3.org/2001/XMLSchema#integer> .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>or, using our QName simplification for writing long
|
|
URIs:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:age "27"^^xsd:integer .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>or as shown in <a href="#figure8">Figure 8</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig8dec16.png"
|
|
alt="A Typed Literal for John Smith's Age" /><br />
|
|
<a id="figure8" name="figure8">Figure 8: A Typed Literal for
|
|
John Smith's Age</a>
|
|
</div>
|
|
|
|
<p>Similarly, in the graph shown in <a href="#figure3">Figure
|
|
3</a> describing information about a Web page, we recorded the
|
|
value of the page's <tt>exterms:creation-date</tt> property as
|
|
the plain literal "August 16, 1999". However, using a typed
|
|
literal, we could describe the creation date of the Web page as
|
|
being the date <em>August 16, 1999</em>, using the triple:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:index.html exterms:creation-date "1999-08-16"^^xsd:date .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>or as shown in <a href="#figure9">Figure 9</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig9dec16.png"
|
|
alt="A Typed Literal for a Web Page's Creation Date" /><br />
|
|
<a id="figure9" name="figure9">Figure 9: A Typed Literal for
|
|
a Web Page's Creation Date</a>
|
|
</div>
|
|
|
|
<p>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, 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 is concerned, you can write any
|
|
pair of URIref and literal you want as a typed literal. This
|
|
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 different datatype
|
|
systems, but RDF would impose no extra conversions into and out
|
|
of a native set of RDF types.)</p>
|
|
|
|
<p>The actual interpretation of a typed literal (determining
|
|
the value it denotes) must be performed by an RDF processor
|
|
that is programmed to "understand" that datatype. In
|
|
particular, we've used XML Schema datatypes in the two examples
|
|
we've just presented, and will be using XML Schema datatypes in
|
|
most of our other examples as well (for one thing, XML Schema
|
|
data types have URIrefs we can use to refer to them, specified
|
|
in <a href="#ref-xmlschema2">[XML-SCHEMA2]</a>). XML Schema
|
|
datatypes 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 RDF processors will be
|
|
programmed to recognize these datatypes. However, RDF software
|
|
could be programmed to process other sets of datatypes as
|
|
well.</p>
|
|
|
|
<p>RDF datatype concepts also borrow a conceptual framework
|
|
from XML Schema datatypes <a
|
|
href="#ref-xmlschema2">[XML-SCHEMA2]</a> to more precisely
|
|
describe datatype requirements. RDF's use of this framework is
|
|
defined 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. For one thing, RDF has no way of knowing whether or not
|
|
a URIref 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 to understand that datatype. For example, you
|
|
could write the triple:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:age "pumpkin"^^xsd:integer .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>or the graph shown in <a href="#figure10">Figure 10</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig10dec16.png"
|
|
alt="An Invalid Typed Literal for John Smith's Age" /><br />
|
|
<a id="figure10" name="figure10">Figure 10: An Invalid Typed
|
|
Literal for John Smith's Age</a>
|
|
</div>
|
|
|
|
<p>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 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 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, RDF software not built to
|
|
understand the <tt>xsd:integer</tt> datatype would not be able
|
|
to recognize that "pumpkin" is not a valid
|
|
<tt>xsd:integer</tt>.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a name="conceptsummary" id="conceptsummary">2.5 Concepts
|
|
Summary</a></h3>
|
|
|
|
<p>Taken as a whole, RDF is 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 the <a
|
|
href="http://www.w3.org/TR/rdf-concepts/">RDF Concepts and
|
|
Abstract Syntax</a> <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a>, which should be
|
|
consulted for further information. Together with the <a
|
|
href="http://www.w3.org/TR/rdf-mt/">RDF Semantics</a> <a
|
|
href="#ref-rdf-semantics">[RDF-SEMANTICS]</a> document, <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a> provides the
|
|
definition of the abstract syntax for RDF, together with its
|
|
formal semantics (meaning).</p>
|
|
|
|
<p>However, in addition to the basic techniques for
|
|
representing RDF statements in diagrams (or triples) we've seen
|
|
so far, it should be clear that we also need a way for people
|
|
to define the <em>vocabularies</em> they intend to use in those
|
|
statements, including:</p>
|
|
|
|
<ul>
|
|
<li>defining types of things (like <tt>ex:Person</tt>)</li>
|
|
|
|
<li>defining properties (like <tt>ex:age</tt> and
|
|
<tt>ex:creation-date</tt>), and</li>
|
|
|
|
<li>defining the types of things that can serve as the
|
|
subjects or objects of statements involving those properties
|
|
(such as specifying that the value of an <tt>ex:age</tt>
|
|
property should always be an <tt>xsd:integer</tt>).</li>
|
|
</ul>
|
|
|
|
<p>The basis for describing such vocabularies in RDF is the <a
|
|
href="http://www.w3.org/TR/rdf-schema/">RDF Vocabulary
|
|
Description Language 1.0: RDF Schema</a> <a
|
|
href="#ref-rdf-vocabulary">[RDF-VOCABULARY]</a>, which will be
|
|
described in <a href="#rdfschema">Section 5</a>.</p>
|
|
|
|
<p>Additional background on the basic ideas underlying RDF, and
|
|
its role in providing a general language for describing Web
|
|
information, can be found in <a
|
|
href="#ref-webdata">[WEBDATA]</a>. 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 <a
|
|
href="#ref-sowa">[Sowa]</a>, <a href="#ref-cg">[CG]</a>, <a
|
|
href="#ref-kif">[KIF]</a>, <a href="#ref-hayes">[Hayes]</a>, <a
|
|
href="#ref-luger">[Luger]</a>, and <a
|
|
href="#ref-gray">[Gray]</a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a id="rdfxml" name="rdfxml"></a>3. An XML Syntax for RDF:
|
|
RDF/XML</h2>
|
|
|
|
<p>As 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 <em>RDF/XML</em>. Unlike triples, which are
|
|
intended as a shorthand notation, RDF/XML is the normative syntax
|
|
for writing RDF. RDF/XML is defined in the <a
|
|
href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML Syntax
|
|
Specification</a> <a href="#ref-rdf-syntax">[RDF-SYNTAX]</a>.
|
|
This section describes this RDF/XML syntax.</p>
|
|
|
|
<div class="section">
|
|
<h3><a name="basicprinciples" id="basicprinciples">3.1 Basic
|
|
Principles</a></h3>
|
|
|
|
<p>We can illustrate the basic ideas behind the RDF/XML syntax
|
|
using some of the examples we've presented already. Suppose we
|
|
want to represent one of our initial statements:</p>
|
|
|
|
<p class="ptriple"><tt><u>http://www.example.org/index.html</u>
|
|
has a <u>creation-date</u> whose value is <u>August 16,
|
|
1999</u></tt></p>
|
|
|
|
<p>The RDF graph for this single statement, after assigning a
|
|
URIref to the <tt>creation-date</tt> property, is shown in <a
|
|
href="#figure11">Figure 11</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig11dec16.png"
|
|
alt="A Simple RDF Statement" /><br />
|
|
<a id="figure11" name="figure11">Figure 11: A Simple RDF
|
|
Statement</a>
|
|
</div>
|
|
|
|
<p>with a triple representation of:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:index.html exterms:creation-date "August 16, 1999" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p><a href="#example2">Example 2</a> shows the RDF/XML syntax
|
|
corresponding to the graph in <a href="#figure11">Figure
|
|
11</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example2" name="example2">Example 2: RDF/XML for a
|
|
Simple RDF Statement</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>(we have added line numbers to use in explaining the
|
|
example).</p>
|
|
|
|
<p>This seems like a lot of overhead. We can understand better
|
|
what is going on by considering each part of this XML in turn
|
|
(a brief introduction to XML is provided in <a
|
|
href="#documents">Appendix B</a>).</p>
|
|
|
|
<p>Line 1, <tt><?xml version="1.0"?></tt>, is the XML
|
|
declaration, which indicates that the following content is XML,
|
|
and what version of XML it is.</p>
|
|
|
|
<p>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 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 the source for the RDF-specific terms used in
|
|
RDF/XML.</p>
|
|
|
|
<p>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 the source for
|
|
the specific terms defined by our 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
|
|
RDF/XML content, and to identify the sources of the terms we
|
|
are using.</p>
|
|
|
|
<p>Lines 4-6 provide the RDF/XML for the specific statement
|
|
we're representing. An obvious way to talk about any RDF
|
|
statement is to say it's a <em>description</em>, and that it's
|
|
<em>about</em> 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 4 indicates that we're starting a
|
|
<em>description</em> of a resource, and goes on to identify the
|
|
resource the statement is <em>about</em> (the subject of the
|
|
statement) using the <tt>rdf:about</tt> attribute to specify
|
|
the URIref of the subject resource. Line 5 provides a
|
|
<em>property element</em>, with the QName
|
|
<tt><exterms:creation-date></tt> as its tag, to hold the
|
|
plain literal <tt>August 19, 1999</tt> of the creation-date
|
|
property of the statement. It 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. 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.</p>
|
|
|
|
<p>Finally, Line 7 indicates the end of the <tt>rdf:RDF</tt>
|
|
element started on Line 2.</p>
|
|
|
|
<p><a href="#example2">Example 2</a> 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 are written as XML
|
|
<em>QNames</em>, consisting of a short <em>prefix</em> denoting
|
|
a namespace URI, together with a <em>local name</em> denoting a
|
|
namespace-qualified element or attribute, as described in <a
|
|
href="#documents">Appendix B</a>. The (namespace URIref, local
|
|
name) pair are chosen so that concatenating them forms the
|
|
URIref of the original node. The URIrefs of subject nodes are
|
|
written as XML attribute values. The nodes labeled by literals
|
|
(which are always object nodes) become element text content or
|
|
attribute values. (All these options are described in <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a>).</p>
|
|
|
|
<p>We could represent an RDF graph consisting of multiple
|
|
statements in RDF/XML by using RDF/XML similar to Lines 4-6 in
|
|
<a href="#example2">Example 2</a> to separately represent each
|
|
statement. For example, if we wanted to write the following two
|
|
statements:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:index.html exterms:creation-date "August 16, 1999" .
|
|
ex:index.html exterms:language "English" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>we could write the RDF/XML in <a href="#example3">Example
|
|
3</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example3" name="example3">Example 3: RDF/XML for Two
|
|
Statements</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p><a href="#example3">Example 3</a> is the same as <a
|
|
href="#example2">Example 2</a>, with the addition of lines 7-9,
|
|
a second <tt>rdf:Description</tt> element to represent the
|
|
second statement. We could represent an arbitrary number of
|
|
additional statements in the same way, using a separate
|
|
<tt>rdf:Description</tt> element for each additional statement.
|
|
As <a href="#example3">Example 3</a> 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.</p>
|
|
|
|
<p>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 <a href="#example3">Example
|
|
3</a>, 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, if we wanted to
|
|
represent the following group of statements about
|
|
http://www.example.org/index.html:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:index.html dc:creator exstaff:85740 .
|
|
ex:index.html exterms:creation-date "August 16, 1999" .
|
|
ex:index.html exterms:language "English" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>whose graph (the same as <a href="#figure3">Figure 3</a>) is
|
|
shown in <a href="#figure12">Figure 12</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig3dec16.png"
|
|
alt="Several Statements About the Same Resource" /><br />
|
|
<a id="figure12" name="figure12">Figure 12: Several
|
|
Statements About the Same Resource</a>
|
|
</div>
|
|
|
|
<p>we could write the RDF/XML as shown in <a
|
|
href="#example4">Example 4</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example4" name="example4">Example 4: Abbreviating
|
|
Multiple Properties</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>Compared with the previous two examples, <a
|
|
href="#example4">Example 4</a> adds an additional namespace
|
|
declaration (in Line 3), and an additional <tt>creator</tt>
|
|
property element (in Line 8). In addition, we've nested the
|
|
property elements for the three properties whose subject is
|
|
<tt>http://www.example.org/index.html</tt> within a single
|
|
<tt>rdf:Description</tt> element identifying that subject,
|
|
rather than writing a separate <tt>rdf:Description</tt> element
|
|
for each statement.</p>
|
|
|
|
<p>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 3.) The
|
|
<tt>exterms:language</tt> element in Line 7 is similar to the
|
|
<tt>exterms:creation-date</tt> element we defined in <a
|
|
href="#example2">Example 2</a>. Both these elements represent
|
|
properties with plain literals as property values, and such
|
|
elements are specified by enclosing the literal within start-
|
|
and end-tags corresponding to the property name. However, the
|
|
<tt>dc:creator</tt> element on Line 8 represents a property
|
|
whose value is <em>another resource</em>, rather than a
|
|
literal. If we had written the URIref of this resource as a
|
|
plain literal within start- and end-tags in the same way as we
|
|
wrote the literal values of the other elements, we would be
|
|
saying that the value of the <tt>dc:creator</tt> element was
|
|
the <em>character string</em>
|
|
<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, we've written the
|
|
<tt>dc:creator</tt> element using what XML calls an
|
|
<em>empty-element tag</em> (it has no separate end-tag), and
|
|
defined the property value 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 <em>value</em>, RDF/XML requires
|
|
that we write out the URIref, rather than abbreviating it as a
|
|
QName, as we've done in writing element and attribute
|
|
<em>names</em>.</p>
|
|
|
|
<p>It is important to understand that the RDF/XML in the <a
|
|
href="#example4">Example 4</a> is an <em>abbreviation</em>. The
|
|
RDF/XML in <a href="#example5">Example 5</a>, in which each
|
|
statement is written separately, describes exactly the same RDF
|
|
graph:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example5" name="example5">Example 5: Writing Example
|
|
4 as Separate Statements</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: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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>We will describe a few additional RDF/XML abbreviations in
|
|
the following sections. However, you should consult <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a> for a more thorough
|
|
description of the abbreviations that are available.</p>
|
|
|
|
<p>RDF/XML also allows us to represent graphs that include
|
|
nodes that have no URIrefs, i.e., <em>blank nodes</em>. For
|
|
example, <a href="#figure13">Figure 13</a> (taken from <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a>) 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/' ".</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig13dec16.png"
|
|
alt="A Graph Containing a Blank Node" /><br />
|
|
<a id="figure13" name="figure13">Figure 13: A Graph
|
|
Containing a Blank Node</a>
|
|
</div>
|
|
|
|
<p>This illustrates an idea we discussed in <a
|
|
href="#structuredproperties">Section 2.3</a>: 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.</p>
|
|
|
|
<p>RDF/XML provides several ways to represent blank nodes.
|
|
These are described in <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a>. The approach we will
|
|
illustrate here, which is the most direct approach, is to
|
|
assign a <em>blank node identifier</em> to the 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
|
|
with a blank node identifier as its value in places where the
|
|
URIref of a resource 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 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>, <a
|
|
href="#example6">Example 6</a> shows the RDF/XML corresponding
|
|
to <a href="#figure13">Figure 13</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example6" name="example6">Example 6: RDF/XML
|
|
Describing a Blank Node</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>In <a href="#example6">Example 6</a>, the blank node
|
|
identifier <tt>abc</tt> is used in Line 9 to identify the blank
|
|
node as the subject of several statements, and is used in 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 <a href="#ref-rdf-syntax">[RDF-SYNTAX]</a> 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.</p>
|
|
|
|
<p>Finally, the <em>typed literals</em> we described in <a
|
|
href="#typedliterals">Section 2.4</a> may be used as property
|
|
values instead of the plain literals 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.</p>
|
|
|
|
<p>For example, to change the statement from <a
|
|
href="#example2">Example 2</a> to use a typed literal instead
|
|
of a plain literal for the <tt>creation-date</tt> property, the
|
|
triple representation would be:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:index.html exterms:creation-date "1999-08-16"^^xsd:date .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>with corresponding RDF/XML syntax shown in <a
|
|
href="#example7">Example 7</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example7" name="example7">Example 7: RDF/XML Using a
|
|
Typed Literal</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>In Line 5 of <a href="#example7">Example 7</a>, 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.</p>
|
|
|
|
<p>For the most part, we will continue to use plain (untyped)
|
|
literals in our examples. However, you should be aware that
|
|
typed literals from appropriate datatypes, such as XML Schema
|
|
datatypes, can always be used instead.</p>
|
|
|
|
<p>Although additional abbreviated forms for writing RDF/XML
|
|
are available, the facilities we have illustrated so far
|
|
provide a simple but general way to serialize graphs in
|
|
RDF/XML. Using these facilities, an RDF graph is written in
|
|
RDF/XML as follows:</p>
|
|
|
|
<ul>
|
|
<li>All blank nodes are assigned blank node identifiers.</li>
|
|
|
|
<li>Each node is listed in turn as the subject of an
|
|
un-nested <code>rdf:Description</code> element, using an
|
|
<code>rdf:about</code> attribute if the node has a URIref, or
|
|
an <code>rdf:nodeID</code> attribute if the node is
|
|
blank.<br />
|
|
For each triple with this node as subject, an appropriate
|
|
property element is created, with either literal content
|
|
(possibly empty), an <code>rdf:resource</code> attribute
|
|
specifying the object of the triple (if the object node has a
|
|
URIref), or an <code>rdf:nodeID</code> attribute specifying
|
|
the object of the triple (if the object node is blank).</li>
|
|
</ul>
|
|
|
|
<p>Compared to some of the more abbreviated serialization
|
|
approaches described in <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a>, this simple
|
|
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.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a name="newresources" id="newresources">3.2 Abbreviating
|
|
and Organizing RDF URIrefs</a></h3>
|
|
|
|
<p>So far, we've been describing resources that we imagine have
|
|
been given URIrefs already. For instance, in our initial
|
|
examples, we provided descriptive information about
|
|
example.org's web page, whose URIref was
|
|
http://www.example.org/index.html. We referred to this resource
|
|
using an <tt>rdf:about</tt> attribute citing its full URIref.
|
|
Although RDF doesn't specify or control how URIrefs are
|
|
assigned to resources, sometimes we want to achieve the
|
|
<em>effect</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</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example8" name="example8">Example 8: RDF/XML for
|
|
example.com's Catalog</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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.com/terms/">
|
|
|
|
4. <rdf:Description rdf:ID="item10245">
|
|
5. <exterms:model>Overnighter</exterms:model>
|
|
6. <exterms:sleeps>2</exterms:sleeps>
|
|
7. <exterms:weight>2.4</exterms:weight>
|
|
8. <exterms:packedSize>14x56</exterms:packedSize>
|
|
9. </rdf:Description>
|
|
|
|
...other product descriptions...
|
|
|
|
10. </rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>(We've included the surrounding xml, RDF, and namespace
|
|
information in lines 1 through 3, and line 10, but this
|
|
information would only need to be defined once for the whole
|
|
catalog, not repeated for each entry in the catalog).</p>
|
|
|
|
<p><a href="#example8">Example 8</a> is similar to 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, 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 a <em>fragment identifier</em>, 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. The fragment identifier
|
|
<tt>item10245</tt> will be interpreted relative to a <em>base
|
|
URI</em>, 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>#</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>.</p>
|
|
|
|
<p>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 the document (in this case, the catalog) in
|
|
which it is defined. 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 the relative URIref
|
|
<tt>#item10245</tt> in an <tt>rdf:about</tt> attribute. This
|
|
would be understood as being a URIref defined relative to the
|
|
base URIref of the catalog. Using a similar abbreviation, we
|
|
could also have given the URIref of the tent 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 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
|
|
either case, 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, you can think of this use of a relative URIref as
|
|
either 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.</p>
|
|
|
|
<p>RDF located <em>outside</em> 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 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</a> might then be represented on
|
|
exampleRatings.com's web site as shown in <a
|
|
href="#example9">Example 9</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example9" name="example9">Example 9:
|
|
exampleRatings.com's Rating of the Tent</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
1. <?xml version="1.0"?>
|
|
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
3. xmlns:sportex="http://www.exampleRatings.com/terms/">
|
|
|
|
4. <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
|
|
5. <sportex:ratingBy>Richard Roe</sportex:ratingBy>
|
|
6. <sportex:numberStars>5</sportex:numberStars>
|
|
7. </rdf:Description>
|
|
8. </rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>In <a href="#example9">Example 9</a>, line 4 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.</p>
|
|
|
|
<p>These examples illustrate several points. First, even though
|
|
RDF doesn't specify or control how URIrefs are assigned to
|
|
resources (in this case, the various tents and other items in
|
|
the catalog), the <em>effect</em> 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 in an entry in this catalog, it's 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.)</p>
|
|
|
|
<p>These examples also illustrate one of the basic
|
|
architectural principles of the Web, which is that anyone
|
|
should be able say anything they want about existing resources
|
|
<a href="#ref-berners-lee98">[BERNERS-LEE98]</a>. 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. This is true not only
|
|
for situations like this one, in which one organization is
|
|
rating or commenting on resources 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
|
|
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, as this example
|
|
illustrates, by creating a separate document, and 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>.</p>
|
|
|
|
<p>The discussion above indicated that fragment identifiers
|
|
such as <tt>#item10245</tt> will be interpreted relative to a
|
|
<em>base URI</em>. By default, this base URI would be the URI
|
|
of the resource in which the fragment identifier 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 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.</p>
|
|
|
|
<p>To deal with such cases, RDF/XML supports <a
|
|
href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/">XML
|
|
Base</a> <a href="#ref-xml-base">[XML-BASE]</a>, which allows
|
|
an XML document to specify a base URI other than the URI of the
|
|
document itself. <a href="#example10">Example 10</a> shows how
|
|
we would define the catalog using XML Base:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example10" name="example10">Example 10: Using XML
|
|
Base in example.com's Catalog</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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.com/terms/"
|
|
4. xml:base="http://www.example.com/2002/04/products">
|
|
|
|
5. <rdf:Description rdf:ID="item10245">
|
|
6. <exterms:model>Overnighter</exterms:model>
|
|
7. <exterms:sleeps>2</exterms:sleeps>
|
|
8. <exterms:weight>2.4</exterms:weight>
|
|
9. <exterms:packedSize>14x56</exterms:packedSize>
|
|
10. </rdf:Description>
|
|
|
|
...other product descriptions...
|
|
|
|
11. </rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>In <a href="#example10">Example 10</a>, the
|
|
<tt>xml:base</tt> declaration in line 4 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 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.</p>
|
|
|
|
<p>So far, we've been talking about 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
|
|
<em>kinds</em> or <em>categories</em> is similar to the
|
|
programming language concept of objects having different
|
|
<em>types</em> or <em>classes</em>. 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 <em>class</em> of things, and the
|
|
subject of that property is considered to be an
|
|
<em>instance</em> of that category or class. Using
|
|
<tt>rdf:type</tt>, <a href="#example11">Example 11</a> shows
|
|
how example.com might indicate that our product description is
|
|
that of a tent:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example11" name="example11">Example 11: Describing a
|
|
Tent with <tt>rdf:type</tt></a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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.com/terms/"
|
|
4. xml:base="http://www.example.com/2002/04/products">
|
|
|
|
5. <rdf:Description rdf:ID="item10245">
|
|
6. <rdf:type rdf:resource="http://www.example.com/terms/Tent" />
|
|
7. <exterms:model>Overnighter</exterms:model>
|
|
8. <exterms:sleeps>2</exterms:sleeps>
|
|
9. <exterms:weight>2.4</exterms:weight>
|
|
10. <exterms:packedSize>14x56</exterms:packedSize>
|
|
11. </rdf:Description>
|
|
|
|
...other product descriptions...
|
|
|
|
12. </rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>In <a href="#example11">Example 11</a>, the
|
|
<tt>rdf:type</tt> property in Line 6 indicates that the
|
|
instance belongs to a class identified by the URIref
|
|
<tt>http://www.example.com/terms/Tent</tt>. In this case, we
|
|
imagine 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 we use the
|
|
absolute URIref of the class to refer to it. If example.com had
|
|
described these classes as part of the product catalog itself,
|
|
we could have used the relative URIref <tt>#Tent</tt> to refer
|
|
to it.</p>
|
|
|
|
<p>RDF itself does not define a vocabulary for defining
|
|
application-specific classes of things, such as <tt>Tent</tt>
|
|
in this example. Instead, such classes would be described in an
|
|
<em>RDF Schema</em>. The facilities provided by RDF for
|
|
describing application-specific classes and their properties
|
|
are discussed in <a href="#rdfschema">Section 5</a>. Other such
|
|
facilities for describing classes can also be defined, such as
|
|
the <em>DAML+OIL</em> and <em>OWL</em> languages described in
|
|
<a href="#richerschemas">Section 5.5</a>.</p>
|
|
|
|
<p>Since describing resources as instances of specific types or
|
|
classes is fairly common, RDF/XML provides a special
|
|
abbreviation for instances described as members of classes
|
|
using the <tt>rdf:type</tt> property. In this abbreviation, the
|
|
<tt>rdf:type</tt> property and its value are removed, and the
|
|
<tt>rdf:Description</tt> element is replaced by an element
|
|
whose name is the QName corresponding to the class URIref.
|
|
Using this abbreviation, example.com's tent from <a
|
|
href="#example11">Example 11</a> could also be described as
|
|
shown in <a href="#example12">Example 12</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example12" name="example12">Example 12: Abbreviating
|
|
the Tent's Type</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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.com/terms/"
|
|
4. xml:base="http://www.example.com/2002/04/products">
|
|
|
|
5. <exterms:Tent rdf:ID="item10245">
|
|
6. <exterms:model>Overnighter</exterms:model>
|
|
7. <exterms:sleeps>2</exterms:sleeps>
|
|
8. <exterms:weight>2.4</exterms:weight>
|
|
9. <exterms:packedSize>14x56</exterms:packedSize>
|
|
10. </exterms:Tent>
|
|
|
|
...other product descriptions...
|
|
|
|
11. </rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>Both <a href="#example11">Example 11</a> and <a
|
|
href="#example12">Example 12</a> illustrate that RDF statements
|
|
can be written in RDF/XML in a way that closely resembles
|
|
descriptions that might have been written directly in 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.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a name="rdfxmlsummary" id="rdfxmlsummary">3.3 RDF/XML
|
|
Summary</a></h3>
|
|
|
|
<p>The examples above have illustrated some of the basic ideas
|
|
behind the RDF/XML syntax. These examples provide enough
|
|
information to enable you to begin writing useful RDF/XML. For
|
|
a more thorough discussion of the principles behind the
|
|
modeling of RDF statements in XML (known as <em>striping</em>),
|
|
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 the <a
|
|
href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML Syntax
|
|
Specification</a> <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a id="othercapabilities" name="othercapabilities"></a>4.
|
|
Other RDF Capabilities</h2>
|
|
|
|
<p>RDF provides a number of additional capabilities, including
|
|
some built-in types and properties for representing groups of
|
|
resources and RDF statements, and capabilities for deploying RDF
|
|
information in the World Wide Web. These additional capabilities
|
|
are described in the following sections.</p>
|
|
|
|
<div class="section">
|
|
<h3><a name="containers" id="containers">4.1 RDF
|
|
Containers</a></h3>
|
|
|
|
<p>There is often a need to describe <em>groups</em> of things.
|
|
For example, 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
|
|
types and properties that can be used to describe such
|
|
groups.</p>
|
|
|
|
<p>First, RDF provides a <em>container vocabulary</em>
|
|
consisting of three predefined types (together with some
|
|
associated predefined properties). A <em>container</em> is a
|
|
resource that contains things. The contained things are called
|
|
<em>members</em>. The members of a container may be resources
|
|
or literals. RDF defines three types of containers:</p>
|
|
|
|
<ul>
|
|
<li><tt>rdf:Bag</tt></li>
|
|
|
|
<li><tt>rdf:Seq</tt></li>
|
|
|
|
<li><tt>rdf:Alt</tt></li>
|
|
</ul>
|
|
|
|
<p>A <em>Bag</em> (a resource having type <tt>rdf:Bag</tt>) is
|
|
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.</p>
|
|
|
|
<p>A <em>Sequence</em> or <em>Seq</em> (a resource having type
|
|
<tt>rdf:Seq</tt>) is 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.</p>
|
|
|
|
<p>An <em>Alternative</em> or <em>Alt</em> (a resource having
|
|
type <tt>rdf:Alt</tt>) is a group of resources or literals that
|
|
are <em>alternatives</em> (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.</p>
|
|
|
|
<p>To describe a resource as being one of these types of
|
|
containers, you give the resource an <tt>rdf:type</tt> property
|
|
whose value is one of the pre-defined 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 <em>members</em> of the container can be
|
|
described by defining a <em>container membership property</em>
|
|
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:_<em>n</em></tt>, where
|
|
<em>n</em> 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>, 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.</p>
|
|
|
|
<p>It is important to understand that while these types of
|
|
containers are described using pre-defined 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 <em>intended</em> 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 in <a
|
|
href="#newresources">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.</p>
|
|
|
|
<p>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, and Sue", you could describe the course by giving it a
|
|
<tt>s:students</tt> property whose value is a container of type
|
|
<tt>rdf:Bag</tt> (the group of students) and then, using the
|
|
container membership properties, describe the individual
|
|
students as being members of that container, as in the RDF
|
|
graph shown in <a href="#figure14">Figure 14</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig14dec16.png"
|
|
alt="A Simple Bag Container Description" /><br />
|
|
<a id="figure14" name="figure14">Figure 14: A Simple Bag
|
|
Container Description</a>
|
|
</div>
|
|
|
|
<p>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, even though the 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.</p>
|
|
|
|
<p>RDF/XML provides some special syntax and abbreviations to
|
|
make it simpler to describe such containers. For example, <a
|
|
href="#example13">Example 13</a> describes the graph shown in
|
|
<a href="#figure14">Figure 14</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example13" name="example13">Example 13: RDF/XML for
|
|
a Bag of Students</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:s="http://example.edu/students/vocab#">
|
|
|
|
<rdf:Description rdf:about="http://example.edu/courses/6.001">
|
|
<s:students>
|
|
<rdf:Bag>
|
|
<rdf:li rdf:resource="http://example.edu/students/Amy"/>
|
|
<rdf:li rdf:resource="http://example.edu/students/Tim"/>
|
|
<rdf:li rdf:resource="http://example.edu/students/John"/>
|
|
<rdf:li rdf:resource="http://example.edu/students/Mary"/>
|
|
<rdf:li rdf:resource="http://example.edu/students/Sue"/>
|
|
</rdf:Bag>
|
|
</s:students>
|
|
</rdf:Description>
|
|
</rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p><a href="#example13">Example 13</a> shows that RDF/XML
|
|
provides <tt>li</tt> 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> elements in forming the
|
|
corresponding graph. The element name <tt>li</tt> was chosen to
|
|
be mnemonic with the term "list item" from HTML. Note also the
|
|
use of a <tt><rdf:Bag></tt> element within the
|
|
<tt><s:students></tt> property element. The
|
|
<tt><rdf:Bag></tt> element is another example of the
|
|
abbreviation we used in <a href="#example12">Example 12</a>
|
|
that lets us replace both an <tt>rdf:Description</tt> element
|
|
and an <tt>rdf:type</tt> element with a single element. 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
|
|
<a href="#ref-rdf-syntax">[RDF-SYNTAX]</a>.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>As an illustration of an Alt container, the sentence "The
|
|
source code for X11 may be found at ftp.example.org,
|
|
ftp.example1.org, or ftp.example2.org" could be expressed in
|
|
the RDF graph shown in <a href="#figure15">Figure 15</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig15dec16.png"
|
|
alt="A Simple Alt Container Description" /><br />
|
|
<a id="figure15" name="figure15">Figure 15: A Simple Alt
|
|
Container Description</a>
|
|
</div>
|
|
|
|
<p><a href="#example14">Example 14</a> shows how the graph in
|
|
<a href="#figure15">Figure 15</a> could be written in
|
|
RDF/XML:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example14" name="example14">Example 14: RDF/XML for
|
|
an Alt Container</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: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://ftp.example2.org"/>
|
|
</rdf:Alt>
|
|
</s:DistributionSite>
|
|
</rdf:Description>
|
|
</rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The RDF in <a href="#figure15">Figure 15</a> <em>as
|
|
written</em> 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 <em>members</em> 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
|
|
an Alt is intended to behave, 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.</p>
|
|
|
|
<p>Alt containers are frequently used in conjunction with
|
|
language tagging. For example, a work whose title has been
|
|
translated into several languages might have its <tt>Title</tt>
|
|
property pointing to an Alt container holding each of the
|
|
language variants.</p>
|
|
|
|
<p>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 the author's names more accurately
|
|
represents the relationship than using a Bag (which might
|
|
suggest there are two <em>different</em> authors).</p>
|
|
|
|
<p>Users are free to choose their ways to describe groups of
|
|
resources, rather than using the ones described here. These RDF
|
|
containers are merely provided as common definitions that, if
|
|
generally used, could help make data involving groups of
|
|
resources more interoperable.</p>
|
|
|
|
<p>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 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.</p>
|
|
|
|
<p>Consider as an example the relationship between a writer and
|
|
her publications. We might have the sentence:</p>
|
|
|
|
<blockquote>
|
|
<p>Sue has written "Anthology of Time", "Zoological
|
|
Reasoning", and "Gravitational Reflections".</p>
|
|
</blockquote>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:Sue exterms:publication ex:AnthologyOfTime .
|
|
exstaff:Sue exterms:publication ex:ZoologicalReasoning .
|
|
exstaff:Sue exterms:publication ex:GravitationalReflections .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:Sue exterms:publication _:z
|
|
_:z rdf:type rdf:Bag .
|
|
_:z rdf:_1 ex:AnthologyOfTime .
|
|
_:z rdf:_2 ex:ZoologicalReasoning .
|
|
_:z rdf:_3 ex:GravitationalReflections .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>On the other hand, the sentence:</p>
|
|
|
|
<blockquote>
|
|
<p>The resolution was approved by the Rules Committee, having
|
|
members Fred, Wilma, and Dino.</p>
|
|
</blockquote>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:resolution exterms:approvedBy ex:Fred .
|
|
ex:resolution exterms:approvedBy ex:Wilma .
|
|
ex:resolution exterms:approvedBy ex:Dino .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>since these statements say that each member individually
|
|
approved the resolution.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:resolution exterms:approvedBy ex:rulesCommittee
|
|
ex:rulesCommittee rdf:type rdf:Bag .
|
|
ex:rulesCommittee rdf:_1 ex:Fred .
|
|
ex:rulesCommittee rdf:_2 ex:Wilma .
|
|
ex:rulesCommittee rdf:_3 ex:Dino .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Finally, when using these RDF containers, it is important to
|
|
understand that you are not <em>constructing</em> containers,
|
|
as you would a programming language data structure; instead,
|
|
you are <em>describing</em> containers (groups of things) that
|
|
actually exist. For instance, in the Rules Committee example
|
|
just given, the Rules Committee is an unordered group of
|
|
people, whether you describe it in RDF that way or not. When
|
|
you give the Rules Committee resource an <tt>rdf:type</tt>
|
|
property whose value is <tt>rdf:Bag</tt>, you are simply
|
|
describing the Rules Committee as having whatever
|
|
characteristics you associate with things of type
|
|
<tt>rdf:Bag</tt>, not constructing a particular data structure
|
|
to hold the members of the group (you could indicate that the
|
|
Rules Committee was a Bag without describing any members at
|
|
all). Similarly, when you use the container membership
|
|
properties, you are simply describing a container resource as
|
|
having certain things as members. You are not necessarily
|
|
saying that the things that you describe as members are the
|
|
<em>only</em> 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, not that they are the
|
|
only members of the Bag.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a name="collections" id="collections">4.2 RDF
|
|
Collections</a></h3>
|
|
|
|
<p>A limitation of the containers described in <a
|
|
href="#containers">Section 4.1</a> is that there is no way to
|
|
<em>close</em> them, i.e., to say "these are all the members of
|
|
the container". This is because, 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
|
|
<em>collections</em>. 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 <em>collection
|
|
vocabulary</em> 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>.</p>
|
|
|
|
<p>To illustrate this, you could represent the sentence "The
|
|
students in course 6.001 are Amy, Tim, and John" using the
|
|
graph shown in <a href="#figure16">Figure 16</a>:</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig16dec16.png"
|
|
alt="An RDF Collection (list structure)" /><br />
|
|
<a id="figure16" name="figure16">Figure 16: An RDF
|
|
Collection (list structure)</a>
|
|
</div>
|
|
|
|
<p>For each member of the collection, such as <tt>s:Amy</tt>,
|
|
there is a corresponding resource of type <tt>rdf:List</tt>.
|
|
This list resource is linked to the 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>rdf:rest</tt> property being the resource
|
|
<tt>rdf:nil</tt>. 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.</p>
|
|
|
|
<p>RDF/XML provides a special notation to make it easier to
|
|
describe collections. In RDF/XML, a collection is 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:parseType="Collection"</tt> attribute indicates
|
|
that the enclosed elements are to be used to create the
|
|
corresponding list structure in the RDF graph.</p>
|
|
|
|
<p>To illustrate how this works, the RDF/XML from <a
|
|
href="#example15">Example 15</a> would result in the RDF graph
|
|
shown in <a href="#figure16">Figure 16</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example15" name="example15">Example 15: RDF/XML for
|
|
a Collection of Students</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:s="http://example.edu/students/vocab#">
|
|
|
|
<rdf:Description rdf:about="http://example.edu/courses/6.001">
|
|
<s:students rdf:parseType="Collection">
|
|
<rdf:Description rdf:about="http://example.edu/students/Amy"/>
|
|
<rdf:Description rdf:about="http://example.edu/students/Tim"/>
|
|
<rdf:Description rdf:about="http://example.edu/students/John"/>
|
|
</s:students>
|
|
</rdf:Description>
|
|
</rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The use of <tt>rdf:parseType="Collection"</tt> always
|
|
indicates the construction of a list structure like the one
|
|
shown in <a href="#figure16">Figure 16</a>, which defines a
|
|
fixed finite list of items with a given length and terminated
|
|
by <tt>rdf:nil</tt>, and uses "new" blank nodes which are
|
|
unique to the list structure itself. However, RDF does not
|
|
<em>enforce</em> 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.
|
|
For example, it is not illegal to assert that a given node has
|
|
two distinct values of the <tt>rdf:first</tt> property, or to
|
|
simply omit part of the description of a collection. In
|
|
general, therefore, RDF applications which require collections
|
|
to be well-structured should be written to check that the
|
|
collection vocabulary is being used appropriately, in order to
|
|
be fully robust.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a name="reification" id="reification">4.3 RDF
|
|
Reification</a></h3>
|
|
|
|
<p>RDF applications sometimes need to make <em>statements about
|
|
statements</em>, for instance, to record information about when
|
|
a statement was made, who made it, or other similar
|
|
information. For example, consider a statement about the tent
|
|
we discussed in <a href="#newresources">Section 3.2</a>:</p>
|
|
|
|
<p class="ptriple"><tt><u>product item10245</u> has a
|
|
<u>weight</u> whose value is <u>2.4</u></tt></p>
|
|
|
|
<p>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 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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<strong>[[</strong>exproducts:item10245 exterms:weight "2.4" .<strong>]]</strong> dc:creator exstaff:85740 .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>That is, we want to be able to turn the original statement
|
|
into a resource, so that we can make it the subject of another
|
|
RDF statement that talks about it. RDF provides a built-in
|
|
vocabulary for modeling statements as resources. This modeling
|
|
is called <em>reification</em> in RDF, and a model of a
|
|
statement is called the <em>reification</em> of the
|
|
statement.</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 this vocabulary, a triple of the
|
|
form:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
foo rdf:type rdf:Statement .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>is a statement that the resource <tt>foo</tt> 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 to <tt>foo</tt>, then specify
|
|
the subject, predicate, and object components of that triple
|
|
<tt>foo</tt>.</p>
|
|
|
|
<p>Using this vocabulary, a <em>reification</em> of our
|
|
original triple:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exproducts:item10245 exterms:weight "2.4" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>is given by 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" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>(The node that is intended to refer to the first triple, the
|
|
blank node <tt>_:xxx</tt> in the reification, could be either a
|
|
blank node or a URIref.)</p>
|
|
|
|
<p>The <em>intended</em> interpretation of a reification like
|
|
this is that <tt>_:xxx</tt> should be understood as referring
|
|
to the original triple (as a whole), which is described by the
|
|
subject, predicate, and object triples in the reification. So,
|
|
using the reification, we would express the fact that the
|
|
original statement was made by John Smith using 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>Note that the intended interpretation is that the triple
|
|
that <tt>_:xxx</tt> refers to is a <em>particular instance</em>
|
|
of a triple in a particular RDF document, rather than some
|
|
arbitrary triple having the same subject, predicate, and
|
|
object. There could be several such triples that have the same
|
|
subject, predicate and object properties. Although a graph is
|
|
defined as a set of triples, several instances with the same
|
|
triple structure might occur in different documents. Thus,
|
|
without this understanding, it would be meaningful to claim
|
|
that <tt>_:xxx</tt> does not refer to the triple in the first
|
|
graph, but to some other triple with the same structure. This
|
|
particular interpretation of reification is used because
|
|
reification is intended to be used to express properties such
|
|
as dates of composition and source information, as in our
|
|
example, and these properties need to be applied to specific
|
|
instances of triples.</p>
|
|
|
|
<p>Note also that the assertion of the reified statement is not
|
|
the same as the assertion of the original statement, and
|
|
neither implies the other. That is, when someone asserts that
|
|
John said foo, they are not asserting foo themselves, just that
|
|
John said it. Conversely, when someone asserts foo, they are
|
|
not also asserting its reification, since 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 the <em>intended</em> interpretation of
|
|
reification in the discussion above because, while this may be
|
|
the interpretation that is generally intended when reification
|
|
is used, RDF reification does not actually capture all this
|
|
meaning. Specifically, RDF syntax by itself provides no 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 is a statement that has a subject
|
|
<tt>exproducts:item10245</tt>, 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>) is the same as some particular
|
|
statement in some particular RDF document.</p>
|
|
|
|
<p>To see this, given the original triple:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exproducts:item10245 exterms:weight "2.4" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>and the following reification of it, together with an
|
|
additional triple that associates John 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 that there is nothing that explicitly associates
|
|
<tt>_:xxx</tt> with the original triple, and hence would allow
|
|
you to say that John created it.</p>
|
|
|
|
<p>This does not mean that such "provenance" information 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, you
|
|
could make statements about the resource identified by that URI
|
|
and, based on some application-dependent understanding of how
|
|
those statements should be interpreted, 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 could certainly make statements about those individual
|
|
statements, using their URIs to identify them. In these cases,
|
|
you would not need to use the reification vocabulary at
|
|
all.</p>
|
|
|
|
<p>To see this, if our original triple had a URI, say
|
|
<tt>ex:statementfoo</tt>, then you could attribute that
|
|
statement to John simply by the statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:statementfoo dc:creator exstaff:85740 .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>with no use of the reification vocabulary.</p>
|
|
|
|
<p>In addition, you could use the reification vocabulary
|
|
directly according to the intended interpretation described
|
|
above, and have 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.</p>
|
|
|
|
<p>Finally, since the relation between triples and reifications
|
|
of triples in any RDF graph or graphs need not be one-to-one,
|
|
asserting a property about some resource described by a
|
|
reification does not necessarily mean that the same property
|
|
holds of another such resource, even if it has the same
|
|
components. For example, given the following 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" .
|
|
|
|
_: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 .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>it does not follow that:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
_:yyy dc:creator exstaff:85740 .
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a name="rdfvalue" id="rdfvalue">4.4 More on Structured
|
|
Values: rdf:value</a></h3>
|
|
|
|
<p>In <a href="#structuredproperties">Section 2.3</a>, we noted
|
|
that the RDF data model intrinsically supports only
|
|
<em>binary</em> relations; that is, a statement specifies a
|
|
relation between two resources. For example, the statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:manager exstaff:62345 .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>states that the relation "manager" holds between two
|
|
employees (presumably one manages the other).</p>
|
|
|
|
<p>However, in some cases we need to be able to represent
|
|
information involving higher arity relations (relations between
|
|
more than two resources) in RDF. We discussed one example of
|
|
this in <a href="#structuredproperties">Section 2.3</a>, 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 this as a relation, we'd have
|
|
seen that address was 5-ary relation of the form:</p>
|
|
|
|
<p class="ptriple"><tt>address(exstaff:85740, "1501 Grant
|
|
Avenue", "Bedford", "Massachusetts", "01730")</tt></p>
|
|
|
|
<p>We indicated that we can represent such structured
|
|
information in RDF by considering the aggregate thing we want
|
|
to talk about (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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exstaff:85740 exterms:address _:johnaddress .
|
|
_:johnaddress exterms:street "1501 Grant Avenue" .
|
|
_:johnaddress exterms:city "Bedford" .
|
|
_:johnaddress exterms:state "Massachusetts" .
|
|
_:johnaddress exterms:Zip "01730" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>(where <tt>_:johnaddress</tt> is the blank node identifier
|
|
of the blank node representing John's address.)</p>
|
|
|
|
<p>This is a general way to represent any n-ary relation in
|
|
RDF: 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 then specify an intermediate resource to
|
|
represent the rest of the relation (either with or without
|
|
assigning it a URI), and then give that new resource properties
|
|
representing the remaining components of the relation.</p>
|
|
|
|
<p>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, in our tent example in <a
|
|
href="#newresources">Section 3.2</a>, we gave the weight of the
|
|
particular tent we were describing as the plain literal "2.4",
|
|
i.e.,</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exproduct:item10245 exterms:weight "2.4" .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>In fact, a more complete description of the weight would
|
|
have been "2.4 kilograms" rather than just "2.4". To state
|
|
this, the value of the <tt>exterms:weight</tt> property would
|
|
need to have two components, the literal "2.4" and an
|
|
indication of the unit of measure (kilograms). In this
|
|
situation the literal "2.4" 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" (as we did in the triple above), relying on an
|
|
understanding of the context to fill in the unstated units
|
|
information.</p>
|
|
|
|
<p>In the RDF model a qualified property value of this kind is
|
|
considered as simply another kind of structured value. To
|
|
represent this, we use a separate resource 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 resource properties representing the individual parts of
|
|
the structured value. In this case, we need a property for the
|
|
literal "2.4", and a property for the unit "kilograms". RDF
|
|
provides a pre-defined <tt>rdf:value</tt> property to describe
|
|
the main value (if there is one) of a structured value. So in
|
|
this case, we would give the literal "2.4" as the value of the
|
|
<tt>rdf:value</tt> property, and 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>). The resulting
|
|
triples would be:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exproduct:item10245 exterms:weight _:weight10245 .
|
|
_:weight10245 rdf:value "2.4" .
|
|
_:weight10245 exterms:units exunits:kilograms .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>which can be exchanged using the RDF/XML shown in <a
|
|
href="#example16">Example 16</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example16" name="example16">Example 16: RDF/XML
|
|
using <tt>rdf:value</tt></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:exterms="http://www.example.org/terms/">
|
|
|
|
<rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
|
|
<exterms:weight rdf:parseType="Resource">
|
|
<rdf:value>2.4</rdf:value>
|
|
<exterms:units rdf:resource="http://www.example.org/units/kilograms" />
|
|
</exterms:weight>
|
|
</rdf:Description>
|
|
</rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>(<a href="#example16">Example 16</a> uses some additional
|
|
RDF/XML abbreviations that were not discussed in <a
|
|
href="#rdfxml">Section 3</a>, but are described in <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a>.)</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>You need not use <tt>rdf:value</tt> for these purposes
|
|
(e.g., you could assign your own property name, such as
|
|
<tt>ex:amount</tt>, in the example above), and RDF does not
|
|
associate any particular meaning with it. <tt>rdf:value</tt> is
|
|
simply provided as a convenience for use in these
|
|
commonly-occurring situations.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a id="rdfschema" name="rdfschema"></a>5. Defining RDF
|
|
Vocabularies: RDF Schema</h2>
|
|
|
|
<p>RDF provides a way to express simple statements about
|
|
resources, using named properties and values. However, RDF user
|
|
communities also need the ability 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 examples in <a
|
|
href="#newresources">Section 3.2</a> 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 with
|
|
various "example" namespace prefixes as the names of classes and
|
|
properties here as a reminder that in RDF these names are
|
|
actually <em>URI references</em>, as discussed in <a
|
|
href="#basicconcepts">Section 2.1</a>). 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 for specifying these things.
|
|
Instead, such classes and properties are described in an RDF
|
|
<em>vocabulary</em>. The facilities for describing RDF
|
|
vocabularies are specified in <a
|
|
href="http://www.w3.org/TR/rdf-schema/">RDF Vocabulary
|
|
Description Language 1.0: RDF Schema</a> <a
|
|
href="#ref-rdf-vocabulary">[RDF-VOCABULARY]</a>.</p>
|
|
|
|
<p>RDF Schema does not provide a specific vocabulary of
|
|
application-oriented 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 needed
|
|
to <em>specify</em> such classes and properties as part of a
|
|
vocabulary, and to indicate which classes and properties are
|
|
expected to be used together (for example, you might expect the
|
|
property <tt>ex3:jobTitle</tt> to be used in describing a
|
|
<tt>ex3:Person</tt>). In other words, RDF Schema provides a
|
|
<em>type system</em> 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
|
|
<em>classes</em>. 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 in class
|
|
<tt>ex:Animal</tt>. 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 will say
|
|
more about this point in <a href="#interpretingschema">Section
|
|
5.3</a>.</p>
|
|
|
|
<p>RDF Schema uses RDF itself to specify the RDF type system, by
|
|
providing a set of pre-defined RDF resources and properties,
|
|
together with their meanings, that can be used to describe
|
|
user-specific classes and properties. These additional RDF Schema
|
|
resources extend RDF to include a larger reserved vocabulary with
|
|
additional meaning. The RDF Schema (RDFS) vocabulary is defined
|
|
in a namespace identified by the URI reference
|
|
<tt>http://www.w3.org/2000/01/rdf-schema#"</tt> (in the examples,
|
|
we will use the prefix <tt>rdfs:</tt> to refer to this
|
|
namespace). We will illustrate RDF Schema's basic resources and
|
|
properties in the following sections.</p>
|
|
|
|
<div class="section">
|
|
<h3><a name="schemaclasses" id="schemaclasses">5.1 Describing
|
|
Classes</a></h3>
|
|
|
|
<p>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 <em>classes</em>. A
|
|
<em>class</em> in RDF Schema corresponds to the generic concept
|
|
of a <em>Type</em> or <em>Category</em>, 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 pages, people, document types,
|
|
databases or abstract concepts. Classes are described using the
|
|
RDFS-defined resources <tt>rdfs:Class</tt> and
|
|
<tt>rdfs:Resource</tt>, and the properties <tt>rdf:type</tt>
|
|
and <tt>rdfs:subClassOf</tt>.</p>
|
|
|
|
<p>For example, suppose we wanted to use RDF to provide
|
|
information about different kinds of motor vehicles. In RDF
|
|
Schema, we 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 <em>instances</em>. In this case, we
|
|
intend for the instances of our class to be resources that are
|
|
motor vehicles.</p>
|
|
|
|
<p>In RDF Schema, a <em>class</em> is any resource having an
|
|
<tt>rdf:type</tt> property whose value is the RDFS-defined
|
|
resource <tt>rdfs:Class</tt>. So our motor vehicle class would
|
|
be described by assigning the class a URIref, say
|
|
<tt>ex:MotorVehicle</tt> (using <tt>ex:</tt> to stand for the
|
|
namespace URIref
|
|
<tt>http://www.example.org/schemas/vehicles</tt>, we will use
|
|
in this example) and describing that resource with an
|
|
<tt>rdf:type</tt> property whose value is the RDFS-defined
|
|
resource <tt>rdfs:Class</tt>. That is, we would write the RDF
|
|
statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:MotorVehicle rdf:type rdfs:Class .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>As we indicated in <a href="#newresources">Section 3.2</a>,
|
|
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, if we wanted to describe a
|
|
resource <tt>ex:companyCar</tt> as being a motor vehicle, we
|
|
would write the RDF statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:companyCar rdf:type ex:MotorVehicle .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>(We are using a frequently-used 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)</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>After describing class <tt>ex:MotorVehicle</tt>, we 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 classes in the
|
|
same way as 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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:Van rdf:type rdfs:Class .
|
|
ex:Truck rdf:type rdfs:Class .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>and so on. However, we want to do more than just describe
|
|
the individual classes; we also want to indicate their special
|
|
relationship to class <tt>ex:MotorVehicle</tt>, i.e., that they
|
|
are specialized <em>kinds</em> of MotorVehicle. To do this, we
|
|
use the RDFS concept of <em>subclass</em>.</p>
|
|
|
|
<p>An RDF subclass represents a subset/superset relationship
|
|
between two classes. We describe this relationship using the
|
|
pre-defined <tt>rdfs:subClassOf</tt> property to relate the two
|
|
classes. For example, to state that <tt>ex:Van</tt> is a
|
|
subclass of <tt>ex:MotorVehicle</tt>, we would write the RDF
|
|
statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:Van rdfs:subClassOf ex:MotorVehicle .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The meaning of the <tt>rdfs:subClassOf</tt> relationship is
|
|
that if resource <tt>ex:companyVan</tt> is an instance of
|
|
<tt>ex:Van</tt>, then <tt>ex:companyVan</tt> is also implicitly
|
|
considered an instance of <tt>ex:Motorvehicle</tt> (that is,
|
|
you can "infer" or act as if <tt>ex:companyVan</tt> is an
|
|
instance of <tt>ex:MotorVehicle</tt> even if this is not
|
|
explicitly stated).</p>
|
|
|
|
<p>The <tt>rdfs:subClassOf</tt> property is
|
|
<em>transitive</em>. This means, for example, that if we have
|
|
the RDF statements:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:Van rdfs:subClassOf ex:MotorVehicle .
|
|
ex:MiniVan rdfs:subClassOf ex:Van .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>then <tt>ex:MiniVan</tt> is also implicitly a subclass of
|
|
<tt>ex:Motorvehicle</tt>. As a result, resources that are
|
|
instances of class <tt>ex:MiniVan</tt> are also considered
|
|
instances of class <tt>ex:Motorvehicle</tt> (as well as 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
|
|
classes are implicitly subclasses of class
|
|
<tt>rdfs:Resource</tt> (since the instances belonging to all
|
|
classes are resources).</p>
|
|
|
|
<p><a href="#figure17">Figure 17</a> shows the full class
|
|
hierarchy we have been discussing.</p>
|
|
|
|
<div class="figure">
|
|
<img src="fig17dec16.png"
|
|
alt="A Simple Class Hierarchy" /><br />
|
|
<a id="figure17" name="figure17">Figure 17: A Simple Class
|
|
Hierarchy</a>
|
|
</div>
|
|
|
|
<p>This schema could also be described by the triples:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:MotorVehicle rdf:type rdfs:Class .
|
|
ex:PassengerVehicle rdf:type rdfs:Class .
|
|
ex:Van rdf:type rdfs:Class .
|
|
ex:Truck rdf:type rdfs:Class .
|
|
ex:MiniVan rdf:type rdfs:Class .
|
|
|
|
ex:PassengerVehicle rdfs:subClassOf ex:MotorVehicle .
|
|
ex:Van rdfs:subClassOf ex:MotorVehicle .
|
|
ex:Truck rdfs:subClassOf ex:MotorVehicle .
|
|
|
|
ex:MiniVan rdfs:subClassOf ex:Van .
|
|
ex:MiniVan rdfs:subClassOf ex:PassengerVehicle .
|
|
</pre>
|
|
</div>
|
|
|
|
<p><a href="#example1">Example 17</a> shows how this schema
|
|
could be written in RDF/XML.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example17" name="example17">Example 17: The Vehicle
|
|
Class Hierarchy in RDF/XML</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:rdfs="http://www.w3.org/2000/01/rdf-schema#">
|
|
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>This RDF/XML 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 we
|
|
described in <a href="#newresources">Section 3.2</a>. 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> 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 in <a href="#figure17">Figure 17</a>). As noted in <a
|
|
href="#newresources">Section 3.2</a>, 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.</p>
|
|
|
|
<p>To refer to these classes in RDF instance data (e.g., data
|
|
describing individual vehicles of these classes) located
|
|
elsewhere, we would need to use the full URIrefs to identify
|
|
the classes. For example, to describe the resource
|
|
<tt>ex2:companyCar</tt> as an instance of the class
|
|
<tt>ex:MotorVehicle</tt> described in this schema, we could use
|
|
the RDF/XML shown in <a href="#example18">Example 18</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example18" name="example18">Example 18: An Instance
|
|
of <tt>ex:MotorVehicle</tt></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">
|
|
|
|
<rdf:Description rdf:ID="companyCar">
|
|
<rdf:type rdf:resource="http://example.org/schemas/vehicles#MotorVehicle"/>
|
|
</rdf:Description>
|
|
|
|
</rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="properties" name="properties">5.2 Describing
|
|
Properties</a></h3>
|
|
|
|
<p>In addition to describing the specific <em>classes</em> of
|
|
things they want to describe, user communities also need to be
|
|
able to describe specific <em>properties</em> 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 class <tt>rdf:Property</tt>,
|
|
and the RDFS-defined properties <tt>rdfs:domain</tt>,
|
|
<tt>rdfs:range</tt>, and <tt>rdfs:subPropertyOf</tt>.</p>
|
|
|
|
<p>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 the RDF
|
|
statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
exterms:weightInKg rdf:type rdf:Property .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 properties <tt>rdfs:range</tt> and
|
|
<tt>rdfs:domain</tt> to further describe application-specific
|
|
properties.</p>
|
|
|
|
<p>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 wanted to indicate that
|
|
the property <tt>ex:author</tt> had values that are instances
|
|
of class <tt>ex:Person</tt>, we would write the RDF
|
|
statements:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:Person rdf:type rdfs:Class .
|
|
ex:author rdf:type rdf:Property .
|
|
ex:author rdfs:range ex:Person .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 we are saying nothing 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 <em>all</em> of the classes
|
|
specified as the ranges, i.e., that any value of
|
|
<tt>ex:hasMother</tt> is <em>both</em> a <tt>ex:Female</tt>
|
|
<em>and</em> a <tt>ex:Person</tt>.</p>
|
|
|
|
<p>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 <a href="#typedliterals">Section
|
|
2.4</a>. For example, if we wanted to indicate that the
|
|
property <tt>ex:age</tt> had values from the XML Schema
|
|
datatype <tt>xsd:integer</tt>, we would write the RDF
|
|
statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:age rdf:type rdf:Property .
|
|
ex:age rdfs:range xsd:integer .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 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 class
|
|
<tt>rdfs:Datatype</tt>. To state that <tt>xsd:integer</tt> is a
|
|
datatype, we would write the RDF statement:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
xsd:integer rdf:type rdfs:Datatype .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a>). Such a statement
|
|
does <em>not</em> constitute a <em>definition</em> of a
|
|
datatype, e.g., in the sense that we are defining a new
|
|
datatype. There is no way to define datatypes in RDFS. As noted
|
|
in <a href="#typedliterals">Section 2.4</a>, datatypes are
|
|
defined externally to RDFS, and referred to in RDF statements
|
|
by their URIrefs. What this statement does is document the
|
|
existence of the datatype, and indicates explicitly that it is
|
|
being used in this schema.</p>
|
|
|
|
<p>The <tt>rdfs:domain</tt> property is used to indicate that a
|
|
particular property applies to a designated class. For example,
|
|
if we wanted to indicate that the property <tt>ex:author</tt>
|
|
applies to instances of class <tt>ex:Book</tt>, we would write
|
|
the RDF statements:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:Book rdf:type rdfs:Class .
|
|
ex:author rdf:type rdf:Property .
|
|
ex:author rdfs:domain ex:Book .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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:Book</tt> as subjects.</p>
|
|
|
|
<p>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 we are
|
|
saying nothing 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 <em>all</em> 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>
|
|
<em>and</em> a <tt>ex:MotorVehicle</tt> (illustrating the need
|
|
for care in specifying domains and ranges).</p>
|
|
|
|
<p>We can illustrate the use of these range and domain
|
|
descriptions by extending our 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</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example19" name="example19">Example 19: Some
|
|
Property Descriptions for the Vehicle Schema</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<rdf:Description rdf:ID="registeredTo">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:domain rdf:resource="#MotorVehicle"/>
|
|
<rdfs:range rdf:resource="#Person"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:ID="rearSeatLegRoom">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:domain rdf:resource="#PassengerVehicle"/>
|
|
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:ID="Person">
|
|
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer">
|
|
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Datatype"/>
|
|
</rdf:Description>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>Note that we have not used an <tt><rdf:RDF></tt>
|
|
element in <a href="#example19">Example 19</a> because we have
|
|
assumed we are adding this RDF/XML to the vehicle schema we
|
|
described earlier, identified by
|
|
<tt>http://example.org/schemas/vehicles</tt>. This same
|
|
assumption also allows us to use relative URIrefs like
|
|
<tt>#MotorVehicle</tt> to refer to other classes from that
|
|
schema.</p>
|
|
|
|
<p>RDF Schema provides a way to specialize <em>properties</em>
|
|
as well as classes. We describe this specialization
|
|
relationship between two properties using the pre-defined
|
|
<tt>rdfs:subPropertyOf</tt> property. For example, if
|
|
<tt>ex:primaryDriver</tt> and <tt>ex:driver</tt> are both
|
|
properties, we can describe these properties, and the fact that
|
|
<tt>ex:primaryDriver</tt> is a specialization of
|
|
<tt>ex:driver</tt>, by writing the RDF statements:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
ex:driver rdf:type rdf:Property .
|
|
ex:primaryDriver rdf:type rdf:Property .
|
|
ex:primaryDriver rdfs:subPropertyOf ex:driver .
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The meaning of the <tt>rdfs:subPropertyOf</tt> relationship
|
|
is that if an instance <tt>ex:fred</tt> is an
|
|
<tt>ex:primaryDriver</tt> of the instance
|
|
<tt>ex:companyVan</tt>, then <tt>ex:fred</tt> is implicitly
|
|
considered to also be an <tt>ex:primaryDriver</tt> of
|
|
<tt>ex:companyVan</tt>. The RDF/XML describing these properties
|
|
(assuming again that we are adding this to the vehicle schema
|
|
we described earlier) is shown in <a href="#example20">Example
|
|
20</a>.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example20" name="example20">Example 20: More
|
|
Properties for the Vehicle Schema</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<rdf:Description rdf:ID="driver">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:domain rdf:resource="#MotorVehicle"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:ID="primaryDriver">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:subPropertyOf rdf:resource="#driver"/>
|
|
</rdf:Description>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>A property may be a subproperty of zero, one or more
|
|
properties. All RDF <tt>rdfs:range</tt> and
|
|
<tt>rdfs:domain</tt> properties that apply to an RDF property
|
|
also apply to each of its subproperties. So in the above
|
|
example <tt>ex:primaryDriver</tt>, because of its subproperty
|
|
relationship to <tt>ex:driver</tt>, implicitly also has an
|
|
<tt>rdfs:domain</tt> of <tt>ex:MotorVehicle</tt>.</p>
|
|
|
|
<p><a href="#example1">Example 21</a> shows the RDF/XML for the
|
|
full vehicle schema, containing all the descriptions we've
|
|
given so far:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example21" name="example21">Example 21: The Full
|
|
Vehicle Schema</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: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:Description rdf:ID="Person">
|
|
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer">
|
|
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Datatype"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:ID="registeredTo">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:domain rdf:resource="#MotorVehicle"/>
|
|
<rdfs:range rdf:resource="#Person"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:ID="rearSeatLegRoom">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:domain rdf:resource="#PassengerVehicle"/>
|
|
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:ID="driver">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:domain rdf:resource="#MotorVehicle"/>
|
|
</rdf:Description>
|
|
|
|
<rdf:Description rdf:ID="primaryDriver">
|
|
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
|
|
<rdfs:subPropertyOf rdf:resource="#driver"/>
|
|
</rdf:Description>
|
|
|
|
</rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>Now that we've shown how to describe classes and properties
|
|
using RDF Schema, we can see what instances corresponding to
|
|
those descriptions might look like. For example, <a
|
|
href="#example22">Example 22</a> describes an instance of the
|
|
<tt>ex:PassengerVehicle</tt> class we described above, together
|
|
with some hypothetical values for its properties.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example22" name="example22">Example 22: An Instance
|
|
of <tt>ex:PassengerVehicle</tt></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">
|
|
|
|
<rdf:Description rdf:ID="johnSmithsCar">
|
|
<rdf:type rdf:resource="http://example.org/schemas/vehicles#PassengerVehicle"/>
|
|
<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"/>
|
|
</rdf:Description>
|
|
</rdf:RDF>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>We are assuming that this instance is described in a
|
|
separate document from the schema and, as before, that the
|
|
schema is the resource
|
|
<tt>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 to use
|
|
abbreviations such as <tt>ex:registeredTo</tt> to refer
|
|
unambiguously to properties described in that schema. However,
|
|
when we use the <tt>rdf:type</tt> property to indicate the
|
|
class membership of the instance, we must use the full URIref
|
|
of the class to refer to it (since we cannot use a QName
|
|
referencing the <tt>ex:</tt> namespace as a value of the
|
|
<tt>rdf:resource</tt> attribute.</p>
|
|
|
|
<p>Note that we can use an <tt>ex:registeredTo</tt> property 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 we use a typed literal
|
|
for the value of the <tt>ex:rearSetLegRoom</tt> property in our
|
|
instance, rather than a plain literal (i.e., we didn't say
|
|
<tt><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 be a typed
|
|
literal of that datatype in order to match the range
|
|
description (i.e., the range declaration does not "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,
|
|
so we can abbreviate it with the QName
|
|
<tt>ex:PasssengerVehicle</tt> rather than writing it as a full
|
|
URIref as we did in the earlier form.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="interpretingschema" name="interpretingschema">5.3
|
|
Interpreting RDF Schema Declarations</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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, using <em>domain</em> and <em>range</em> 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>.</p>
|
|
|
|
<p>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 <em>only</em> 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 <em>different</em> attribute. In other
|
|
words, the <em>scope</em> 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, <em>independent</em> of class
|
|
definitions, and have, by default, <em>global</em> scope
|
|
(although they may optionally be declared to apply only to
|
|
certain classes using domain specifications).</p>
|
|
|
|
<p>So, for example, 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,
|
|
this is a "benefit" which must be used with care, to insure
|
|
that properties are not mis-applied in inappropriate
|
|
situations.)</p>
|
|
|
|
<p>Another important difference is that RDF Schema descriptions
|
|
are not necessarily <em>prescriptive</em> 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 <em>constraints</em>. 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 <em>only</em> attribute defined for
|
|
class <tt>Book</tt>, the language will not allow an instance of
|
|
<tt>Book</tt> with some other attribute.</p>
|
|
|
|
<p>RDF Schema, on the other hand, provides schema information
|
|
as additional <em>descriptions</em> 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.</p>
|
|
|
|
<p>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
|
|
<em>constraint</em> 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").</p>
|
|
|
|
<p>Moreover, depending on how the application interprets the
|
|
property descriptions, a description of an instance might be
|
|
considered valid either <em>without</em> some of the
|
|
schema-specified properties (e.g., you might have 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 <em>additional</em> properties (you
|
|
might describe an instance of <tt>ex:Book</tt> with an
|
|
<tt>ex:technicalEditor</tt> property, even though you haven't
|
|
described such a property in your particular schema.)</p>
|
|
|
|
<p>In other words, statements in an RDF Schema are always
|
|
<em>descriptions</em>. They may also be <em>prescriptive</em>
|
|
(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.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="otherschema" name="otherschema">5.4 Other Schema
|
|
Information</a></h3>
|
|
|
|
<p>RDF Schema also provides a number of other 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. For further discussion of these properties,
|
|
you should consult <a
|
|
href="http://www.w3.org/TR/rdf-schema/">RDF Vocabulary
|
|
Description Language 1.0: RDF Schema</a> <a
|
|
href="#ref-rdf-vocabulary">[RDF-VOCABULARY]</a>.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="richerschemas" name="richerschemas">5.5 Richer
|
|
Schema Languages</a></h3>
|
|
|
|
<p>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. Other
|
|
richer schema capabilities that have been identified as useful
|
|
(but that are not provided by RDF Schema) include:</p>
|
|
|
|
<ul type="disc">
|
|
<li><em>cardinality constraints</em> on properties, e.g.,
|
|
that a Person has <em>exactly one</em> biological
|
|
father.</li>
|
|
|
|
<li>specifying that a given property (such as
|
|
<tt>hasAncestor</tt>) is <em>transitive</em>, e.g., that if A
|
|
<tt>hasAncestor</tt> B, and B <tt>hasAncestor</tt> C, then A
|
|
<tt>hasAncestor</tt> C.</li>
|
|
|
|
<li>specifying that a given property is a unique identifier
|
|
(or <em>key</em>) for instances of a particular class.</li>
|
|
|
|
<li>specifying that two different classes (having different
|
|
URIrefs) actually represent the same concept.</li>
|
|
|
|
<li>specifying that two different instances (having different
|
|
URIrefs) actually represent the same individual.</li>
|
|
|
|
<li>the ability to describe new classes in terms of
|
|
combinations (e.g., unions and intersections) of other
|
|
classes, or to say that two classes are disjoint (i.e., that
|
|
no resource is an instance of both classes).</li>
|
|
</ul>
|
|
|
|
<p>The additional capabilities mentioned above, in addition to
|
|
others, are the targets of <em>ontology</em> languages such as
|
|
<a href="http://www.w3.org/TR/daml+oil-reference">DAML+OIL</a>
|
|
<a href="#ref-damloil">[DAML+OIL]</a> and <a
|
|
href="http://www.w3.org/TR/owl-ref/">OWL</a> <a
|
|
href="#ref-owl">[OWL]</a>. 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
|
|
<em>semantics</em> 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 <a href="#applications">Section 6</a> 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 <a
|
|
href="http://www.w3.org/2001/sw/Activity">Semantic Web</a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a id="applications" name="applications"></a>6. Some RDF
|
|
Applications: RDF in the Field</h2>
|
|
|
|
<p>In the previous sections, we have described the general
|
|
capabilities of RDF and RDF Schema. While we have used examples
|
|
within those sections to illustrate those capabilities, and some
|
|
of those examples may have suggested potential RDF applications,
|
|
we have not yet discussed any <em>real</em> ones. In this
|
|
section, we 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.</p>
|
|
|
|
<div class="section">
|
|
<h3 id="dc"><a id="dublincore" name="dublincore">6.1 Dublin
|
|
Core Metadata Initiative</a></h3>
|
|
|
|
<p><em>Metadata</em> is <em>data about data</em>. 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.</p>
|
|
|
|
<p>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 <a
|
|
href="http://dublincore.org/">Dublin Core Metadata
|
|
Initiative</a>. 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" 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 Dublin
|
|
Core <tt>creator</tt> element 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</a> <a
|
|
href="#ref-dublin-core">[DC]</a>, and contain definitions for
|
|
the following properties:</p>
|
|
|
|
<ul type="disc">
|
|
<li><strong>Title</strong>: A name given to the
|
|
resource.</li>
|
|
|
|
<li><strong>Creator</strong>: An entity primarily responsible
|
|
for making the content of the resource.</li>
|
|
|
|
<li><strong>Subject</strong>: The topic of the content of the
|
|
resource.</li>
|
|
|
|
<li><strong>Description</strong>: An account of the content
|
|
of the resource.</li>
|
|
|
|
<li><strong>Publisher</strong>: An entity responsible for
|
|
making the resource available</li>
|
|
|
|
<li><strong>Contributor</strong>: An entity responsible for
|
|
making contributions to the content of the resource.</li>
|
|
|
|
<li><strong>Date</strong>: A date associated with an event in
|
|
the life cycle of the resource.</li>
|
|
|
|
<li><strong>Type</strong>: The nature or genre of the content
|
|
of the resource.</li>
|
|
|
|
<li><strong>Format</strong>: The physical or digital
|
|
manifestation of the resource.</li>
|
|
|
|
<li><strong>Identifier</strong>: An unambiguous reference to
|
|
the resource within a given context.</li>
|
|
|
|
<li><strong>Source</strong>: A Reference to a resource from
|
|
which the present resource is derived.</li>
|
|
|
|
<li><strong>Language</strong>: A language of the intellectual
|
|
content of the resource.</li>
|
|
|
|
<li><strong>Relation</strong>: A reference to a related
|
|
resource.</li>
|
|
|
|
<li><strong>Coverage</strong>: The extent or scope of the
|
|
content of the resource.</li>
|
|
|
|
<li><strong>Rights</strong>: Information about rights held in
|
|
and over the resource.</li>
|
|
</ul>
|
|
|
|
<p>Information using the Dublin Core elements may be
|
|
represented in any suitable language (e.g., in HTML 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 <a href="#ref-dublin-core">[DC]</a> is
|
|
the authoritative reference.</p>
|
|
|
|
<p>The first example, <a href="#example24">Example 24</a>,
|
|
describes a Web site home page using Dublin Core
|
|
properties:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example24" name="example24">Example 24: A Web Page
|
|
Described using Dublin Core Properties</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>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). Even if the initial letter were
|
|
identically uppercase, the XML namespace mechanism enables us
|
|
to distinguish between these two elements (one is
|
|
<tt>rdf:Description</tt>, and the other is
|
|
<tt>dc:description</tt>). Also, as a matter of interest, if you
|
|
access <a
|
|
href="http://purl.org/dc/elements/1.1/">http://purl.org/dc/elements/1.1/</a>
|
|
in a Web browser (as of the current writing), you will get an
|
|
RDF Schema declaration for <a
|
|
href="#ref-dublin-core">[DC]</a>.</p>
|
|
|
|
<p>Our second example, <a href="#example25">Example 25</a>,
|
|
describes a published magazine:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example25" name="example25">Example 25: Describing A
|
|
Magazine Using Dublin Core</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>In <a href="#example25">Example 25</a>, we've used (in the
|
|
third line from the bottom) the Dublin Core <em>qualifier</em>
|
|
<tt>isPartOf</tt> (from a separate namespace) to indicate that
|
|
this magazine is "part of" the previously-described web
|
|
site.</p>
|
|
|
|
<p>The third example, <a href="#example26">Example 26</a>,
|
|
describes a specific article in the magazine described in <a
|
|
href="#example25">Example 25</a>.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example26" name="example26">Example 26: Describing a
|
|
Magazine Article</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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: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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>In <a href="#example26">Example 26</a>, we've also used the
|
|
qualifier <tt>isPartOf</tt>, this time to indicate that this
|
|
article is "part of" the previously-described magazine.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="prism" name="prism">6.2 PRISM</a></h3>
|
|
|
|
<p><a
|
|
href="http://www.prismstandard.org/techdev/prismspec11.asp">PRISM:
|
|
Publishing Requirements for Industry Standard Metadata</a> <a
|
|
href="#ref-prism">[PRISM]</a> is a metadata specification
|
|
developed in the publishing industry. Magazine publishers and
|
|
their vendors formed the <a
|
|
href="http://www.prismstandard.org/">PRISM Working Group</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 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 emphasizes
|
|
<em>discovery</em>, <em>rights tracking</em>, and
|
|
<em>end-to-end metadata</em>.</p>
|
|
|
|
<p><em>Discovery:</em> 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 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.</p>
|
|
|
|
<p><em>Rights Tracking:</em> 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) defined in the
|
|
PRISM specification supports description of places, times, and
|
|
industries where content may or may not be used.</p>
|
|
|
|
<p><em>End-to-end metadata:</em> 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.</p>
|
|
|
|
<p>A PRISM description may be as simple as a few Dublin Core
|
|
properties with plain literal values. <a
|
|
href="#example27">Example 27</a> describes a photograph, giving
|
|
basic information on its title, photographer, format, etc.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example27" name="example27">Example 27: A PRISM
|
|
Description of a Photograph</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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">
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>PRISM also augments the Dublin Core to allow more detailed
|
|
descriptions. The augmentations are defined in three new
|
|
namespaces, generally cited using the prefixes <tt>prism:</tt>,
|
|
<tt>pcv:</tt>, and <tt>prl:</tt>.</p>
|
|
|
|
<p><tt>prism:</tt> This prefix refers to the main PRISM
|
|
namespace, whose URI is
|
|
<tt>http://prismstandard.org/namespaces/basic/1.0/</tt>. Most
|
|
of its properties 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.</p>
|
|
|
|
<p><tt>pcv:</tt> This prefix refers to the PRISM Controlled
|
|
Vocabulary namespace, whose URI is
|
|
<tt>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 <a href="#ref-bates96">[BATES96]</a>. 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 provides properties for specifying
|
|
terms in a vocabulary, the relations between terms, and
|
|
alternate names for the terms.</p>
|
|
|
|
<p><tt>prl:</tt> This prefix refers to the PRISM Rights
|
|
Language namespace, whose URI is
|
|
<tt>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 be "used", depending on conditions of time, geography,
|
|
and industry. This is believed to be an 80/20 tradeoff 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.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<dc:coverage>Greece</dc:coverage>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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> property are:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<dc:coverage>Greece</dc:coverage>
|
|
|
|
<dc:coverage rdf:resource="http://prismstandard.org/vocabs/ISO-3166/GR"/>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>(i.e., using either a plain literal or a URIref) and</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>(using a structured value).</p>
|
|
|
|
<p>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</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<prism:subject>Greece</prism:subject>
|
|
<dc:coverage>Greece</dc:coverage>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>or</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<prism:location>Greece</prism:location>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>We will close this section with two final examples. <a
|
|
href="#example28">Example 28</a> says that the image
|
|
(<tt>.../Corfu.jpg</tt>) cannot be used (<tt>#none</tt>) in the
|
|
tobacco industry (code 21 in SIC, the Standard Industrial
|
|
Classifications).</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example28" name="example28">Example 28: A PRISM
|
|
Description of an Image</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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">
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p><a href="#example29">Example 29</a> 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.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example29" name="example29">Example 29: Additional
|
|
Information about the Image from Example 28</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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/">
|
|
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="xpackage" name="xpackage">6.3 XPackage</a></h3>
|
|
|
|
<p>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 <a
|
|
href="http://www.xpackage.org/specification/">XML Package
|
|
(XPackage) specification</a> <a
|
|
href="#ref-xpackage">[XPACKAGE]</a> provides a framework for
|
|
defining such groupings, called <em>packages</em>. 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 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.</p>
|
|
|
|
<p>The XPackage framework is based upon XML, RDF, and the <a
|
|
href="http://www.w3.org/TR/xlink/">XML Linking Language</a> <a
|
|
href="#ref-xlink">[XLINK]</a>, and provides two RDF
|
|
vocabularies: one for general packaging descriptions, and
|
|
another specifically for describing XML resources. The XPackage
|
|
framework also allows customization through extension and/or
|
|
restriction.</p>
|
|
|
|
<p>One application of XPackage is the description of XHTML
|
|
documents and their supporting resources. An XHTML document
|
|
retrieved from a web site may rely on other resources such as
|
|
stylesheets 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</a> (with namespace declarations
|
|
removed for simplicity):</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example30" name="example30">Example 30: Outer
|
|
Elements of an XPackage Package Description Document</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0"?>
|
|
<xpackage:description>
|
|
<rdf:RDF>
|
|
|
|
(description of individual resources go here)
|
|
|
|
</rdf:RDF>
|
|
</xpackage:description>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>Resources (such as the XHTML document, stylesheets, and
|
|
images) are described within this package description document.
|
|
The XHTML document 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). Each resource description element may include
|
|
RDF properties from various ontologies. In <a
|
|
href="#example31">Example 31</a>, the document's MIME content
|
|
type ("application/xhtml+xml") is defined using a standard
|
|
XPackage property from the XPackage ontology,
|
|
<tt>xpackage:contentType</tt>. 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), resulting in a <tt>dc:creator</tt>
|
|
property. XPackage itself specifies an extension property set
|
|
specifically for XML-based resources, the XML ontology,
|
|
including specifying XML namespaces and stylesheets used with
|
|
the <tt>xmlprop:namespace</tt> and <tt>xmlprop:style</tt>
|
|
properties, respectively.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example31" name="example31">Example 31: A
|
|
Description of an XHTML Document</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<!--doc.html-->
|
|
<xpackage:resource rdf:about="urn:examples: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"/>
|
|
<xmlprop:style rdf:resource="urn:examples:xhtmldocument-stylesheet"/>
|
|
<xmlprop:annotation rdf:resource="urn:examples:xhtmldocument-annotation"/>
|
|
<dc:creator>Garret Wilson</dc:creator>
|
|
<xpackage:manifest>
|
|
<rdf:Bag>
|
|
<rdf:li rdf:resource="urn:examples:xhtmldocument-stylesheet"/>
|
|
<rdf:li rdf:resource="urn:examples:xhtmldocument-image"/>
|
|
</rdf:Bag>
|
|
</xpackage:manifest>
|
|
</xpackage:resource>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The <tt>xpackage:manifest</tt> property indicates that both
|
|
the stylesheet and image resources are necessary for
|
|
processing; those resources are described separately within the
|
|
package description document. The example stylesheet resource
|
|
description in <a href="#example32">Example 32</a> lists its
|
|
location ("stylesheet.css") using the XPackage ontology
|
|
<tt>xpackage:location</tt> property (which is compatible with
|
|
XLink), and shows through use of the XPackage ontology
|
|
<tt>xpackage:contentType</tt> property that it is a CSS
|
|
stylesheet ("text/css").</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example32" name="example32">Example 32: A Stylesheet
|
|
Resource Description</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<!--stylesheet.css-->
|
|
<xpackage:resource rdf:about="urn:examples:xhtmldocument-css">
|
|
<rdfs:comment>The document stylesheet.</rdfs:comment>
|
|
<xpackage:location xlink:href="stylesheet.css"/>
|
|
<xpackage:contentType>text/css</xpackage:contentType>
|
|
</xpackage:resource>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The full version of this example may be found in <a
|
|
href="#ref-xpackage">[XPACKAGE]</a>.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="rss" name="rss">6.4 RSS 1.0: RDF Site
|
|
Summary</a></h3>
|
|
|
|
<p>When you consider all of the information that you access on
|
|
the Web on a day-to-day basis: schedules, to-do lists, news
|
|
headlines, search results, "What's New", etc., it becomes
|
|
increasingly difficult to manage this information and integrate
|
|
it into a coherent whole as the sources and diversity of the
|
|
information increase. <a href="http://purl.org/rss/1.0">RSS
|
|
1.0</a> ("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 powerful and
|
|
extensible way of describing, managing and making available to
|
|
broad audiences relevant and timely information. It allows this
|
|
information to be made available in a rich and reusable way,
|
|
and is also perhaps the most widely deployed RDF application on
|
|
the web.</p>
|
|
|
|
<p>To give a simple example, the <a
|
|
href="http://www.w3.org/">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. 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 (<a href="http://purl.org/rss/1.0/">RSS
|
|
1.0</a>) news feed that makes the content in the center column
|
|
available to others to repurpose 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 <em>RSS readers</em> allow their users to keep track of
|
|
potentially hundreds of sites, without having to visit each one
|
|
in their browser.</p>
|
|
|
|
<div class="figure">
|
|
<a href="w3c-rss.crop.gif"><img src="fig18dec16.gif"
|
|
alt="The W3C Home Page" /></a><br />
|
|
<br />
|
|
<a id="figure18" name="figure18">Figure 18: The W3C Home
|
|
Page</a>
|
|
</div>
|
|
|
|
<p>Numerous sites all over the Web provide RSS 1.0 feeds. <a
|
|
href="#example33">Example 33</a> is an example of the <a
|
|
href="http://www.w3.org/2000/08/w3c-synd/home.rss">W3C
|
|
feed</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example33" name="example33">Example 33: An Example
|
|
of the W3C RSS 1.0 Feed</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>As <a href="#example33">Example 33</a> shows, the format is
|
|
designed for content that can be packaged into easily
|
|
distinguishable sections. News sites, web logs, sports scores,
|
|
stock quotes, and the like are all use-cases for RSS 1.0.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>Online aggregators - Sites such as <a
|
|
href="http://www.oreillynet.com/meerkat/index.php?&c=4743&t=ALL">
|
|
Meerkat</a> and <a
|
|
href="http://www.newsisfree.com/sources/info/906/">NewsIsFree</a>,
|
|
shown side-by-side in <a href="#figure19">Figure 19</a> (each
|
|
mirroring W3C's column of news). These gather feeds from
|
|
thousands of sources, and separate each of the
|
|
<tt><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.</li>
|
|
|
|
<li>Desktop Readers - Utilities such as <a
|
|
href="http://www.disobey.com/amphetadesk/">Amphetadesk</a>
|
|
and <a
|
|
href="http://ranchero.com/software/netnewswire/">NetNewsWire
|
|
Lite</a> allow their users to subscribe to hundreds of feeds
|
|
from their desktop. Readers customarily refresh each feed
|
|
once an hour, allowing users to stay up to date.</li>
|
|
|
|
<li>Scripts - RSS's original purpose was to allow webmasters
|
|
to include the content of another's site within their own.
|
|
RSS 1.0 is still used in this way, with many sites (<a
|
|
href="http://slashdot.org">Slashdot</a> for example)
|
|
incorporating RSS feeds on their front page.</li>
|
|
</ul>
|
|
|
|
<div class="figure">
|
|
<a href="meerkat-rss.crop.gif"><img src="fig19Adec16.gif"
|
|
alt="Meerkat RSS" /></a> <a
|
|
href="newsisfree-rss.crop.gif"><img src="fig19Bdec16.gif"
|
|
alt="NewsIsFree RSS" /></a><br />
|
|
<br />
|
|
<a id="figure19" name="figure19">Figure 19: MeerKat and
|
|
NewsIsFree</a>
|
|
</div>
|
|
|
|
<p>RSS 1.0 is extensible by design. By importing additional RDF
|
|
vocabularies (or <em>modules</em> 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 <a
|
|
href="http://web.resource.org/rss/1.0/">3 official modules</a>
|
|
and <a
|
|
href="http://web.resource.org/rss/1.0/modules/proposed.html">19
|
|
proposed modules</a> readily recognized by the community at
|
|
large. These modules range from the complete <a
|
|
href="http://web.resource.org/rss/1.0/modules/dc/">Dublin Core
|
|
module</a> to more specialized RSS-centric modules such as the
|
|
<a
|
|
href="http://web.resource.org/rss/1.0/modules/aggregation/">Aggregation
|
|
module</a>.</p>
|
|
|
|
<p>Care should be taken when discussing "RSS" is 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.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="cimxml" name="cimxml"></a>6.5 CIM/XML</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <a
|
|
href="http://www.epri.com/">Electric Power Research
|
|
Institute</a> (EPRI) a non-profit energy research consortium,
|
|
developed a <a href="http://standards.ces.com/cim/">Common
|
|
Information Model</a> (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 <a
|
|
href="http://www.langdale.com.au/CIMXML/">CIM/XML</a>, 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 <a href="http://www.nerc.com/">North American
|
|
Electric Reliability Council</a> (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 <a href="#ref-devos">[DWZ01]</a>.
|
|
[NB: This power industry CIM should not be confused with the
|
|
CIM developed by the Distributed Management Task Force for
|
|
defining management information for distributed software,
|
|
network, and enterprise environments. The DMTF CIM also has an
|
|
XML representation, but does not use RDF.]</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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
|
|
vocabulary, and uses RDF/XML as the language for exchanging
|
|
specific system models. <a href="#example34">Example 34</a>
|
|
shows examples of CIM/XML class and property definitions:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example34" name="example34">Example 34: Examples of
|
|
CIM/XML Class and Property Definitions</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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
|
|
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>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>CIM/XML uses only a subset of the complete RDF/XML syntax,
|
|
in order to simplify serialization of models. In addition,
|
|
CIM/XML implements some extensions to the RDF Schema vocabulary
|
|
(defined in the <tt>cims:</tt> namespace) to support inverse
|
|
roles and multiplicity (cardinality) constraints describing how
|
|
many instances of a given property are allowed for a given
|
|
resource 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</a> illustrate these
|
|
extensions:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example35" name="example35">Example 35: Some CIM/XML
|
|
Extensions of RDF Schema</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The <a href="http://www.omg.org/">Object Management
|
|
Group</a> has adopted an object interface standard to access
|
|
CIM power system models called the Data Access Facility <a
|
|
href="#ref-daf">[DAF]</a>. Like the CIM/XML language, the DAF
|
|
is based on the RDF model and shares the same 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.</p>
|
|
|
|
<p>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) and UML (and its XML
|
|
representations).</p>
|
|
|
|
<p>The need for additional declarative power illustrated by the
|
|
need to add cardinality constraints to CIM/XML shows the type
|
|
of requirement leading to the development of more powerful
|
|
RDF-based schema/ontology languages such as DAML+OIL or OWL
|
|
described in <a href="#richerschemas">Section 5.5</a>. Such
|
|
languages may be appropriate in supporting many similar
|
|
modeling applications in the future.</p>
|
|
|
|
<p>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).</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="geneont" name="geneont"></a>6.6 Gene Ontology
|
|
Consortium</h3>
|
|
|
|
<p>Structured metadata using controlled vocabularies such as <a
|
|
href="http://www.snomed.org/">SNOMED RT</a> (Systematized
|
|
Nomenclature of Medicine Reference Terminology) and <a
|
|
href="http://www.nlm.nih.gov/mesh/meshhome.html">MeSH</a>
|
|
(Medical Subject Headings) plays an important role in medicine,
|
|
enabling efficient literature searches and aiding in the
|
|
distribution and exchange of medical knowledge <a
|
|
href="#ref-cowan">[COWAN]</a>. At the same time, the field of
|
|
medicine is rapidly changing, and with that comes the need to
|
|
develop additional vocabularies.</p>
|
|
|
|
<p>The objective of the <a
|
|
href="http://www.geneontology.org/">Gene Ontology (GO)
|
|
Consortium</a> 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.</p>
|
|
|
|
<p>The three organizing principles of the GO are molecular
|
|
function, biological process and cellular 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 (actually, RDF/XML) formatted
|
|
versions, containing all three ontology files and all available
|
|
definitions, are generated monthly.</p>
|
|
|
|
<p>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 in the XML versions of
|
|
the ontologies because of its flexibility in representing these
|
|
graph structures, as well as its widespread tool support.</p>
|
|
|
|
<p><a href="#example36">Example 36</a> shows some sample GO
|
|
information from the <a
|
|
href="http://www.geneontology.org/doc/GO.doc.html">GO
|
|
documentation</a>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example36" name="example36">Example 36: Sample GO
|
|
Information</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p><a href="#example36">Example 36</a> illustrates that
|
|
<tt>go:term</tt> is the basic element. The GO has added its own
|
|
extensions to the RDF vocabulary (they do not use RDFS). 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".</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>ISS means "inferred from sequence similarity [with
|
|
<database:sequence_id>]"</li>
|
|
|
|
<li>IDA means "inferred from direct assay"</li>
|
|
|
|
<li>TAS means "traceable author statement"</li>
|
|
</ul>
|
|
|
|
<p>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>.</p>
|
|
|
|
<p>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 graph or network
|
|
structure, rather than being a strict hierarchy. The GO is also
|
|
another example in which the 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, 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
|
|
<a href="#richerschemas">Section 5.5</a>, become more widely
|
|
used.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="devcap" name="devcap">6.7 Describing Device
|
|
Capabilities and User Preferences</a></h3>
|
|
|
|
<p>In recent years a large number of new mobile devices for
|
|
browsing the 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 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 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.</p>
|
|
|
|
<p>A solution for addressing these problems is for a client to
|
|
encode its <em>delivery context</em> - 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 <a
|
|
href="#ref-diprinc">[DIPRINC]</a> for a definition of delivery
|
|
context). The W3C's Composite Capabilities/Preferences Profile
|
|
(CC/PP) specification <a href="#ref-ccpp">[CC/PP]</a> helps to
|
|
address this problem by defining a generic framework for
|
|
describing a delivery context.</p>
|
|
|
|
<p>The CC/PP framework defines a relatively simple structure -
|
|
a two-level hierarchy of components and attribute/value pairs.
|
|
A <em>component</em> may be used to capture a part of a
|
|
delivery context (e.g. network characteristics, software
|
|
supported by a device or the hardware characteristics of a
|
|
device). A component may contain one or more
|
|
<em>attributes</em>. For example a component that encodes user
|
|
preferences may contain an attribute to specify whether or not
|
|
<em>AudioOutput</em> is desired.</p>
|
|
|
|
<p>CC/PP defines its structure (the hierarchy described above)
|
|
using RDF Schema (see <a href="#ref-ccpp">[CC/PP]</a> for
|
|
details of the structure schema). A CC/PP <em>vocabulary</em>
|
|
defines specific components and their attributes. <a
|
|
href="#ref-ccpp">[CC/PP]</a>, however, does not define such
|
|
vocabularies. Instead, vocabularies are defined by other
|
|
organizations or applications (as described below). <a
|
|
href="#ref-ccpp">[CC/PP]</a> also does not define a protocol
|
|
for transporting an instance of a CC/PP vocabulary.</p>
|
|
|
|
<p>An instance of a CC/PP vocabulary is called a
|
|
<em>profile</em>. CC/PP attributes are encoded as RDF
|
|
properties in a profile. <a href="#example37">Example 37</a>
|
|
shows a profile fragment of user preferences for a user that
|
|
prefers an audio presentation:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example37" name="example37">Example 37: A CC/PP
|
|
Profile Fragment</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>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 <em>super</em>
|
|
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.</p>
|
|
|
|
<p>The Open Mobile Alliance has defined the User Agent Profile
|
|
(UAProf) <a href="#ref-uaprof">[UAPROF]</a> - 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: <em>HardwarePlatform</em>,
|
|
<em>SoftwarePlatform</em>, <em>NetworkCharacteristics</em> and
|
|
<em>BrowserUA</em>. 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</a> shows a fragment of UAProf's
|
|
<em>HardwarePlatform</em> component:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example38" name="example38">Example 38: A Fragment
|
|
of UAProf's HardwarePlatform Component</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The UAProf protocol supports both <em>static</em> profiles
|
|
and <em>dynamic</em> profiles. A <em>static</em> 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. <em>Dynamic</em> profiles are created on-the-fly
|
|
and consequently do not have an associated URI. They may
|
|
consist of a profile fragment containing a <em>difference</em>
|
|
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 <a
|
|
href="#ref-uaprof">[UAPROF]</a> for more information about
|
|
UAProf's protocol and its rules for resolving multiple
|
|
profiles.</p>
|
|
|
|
<p>Several other communities (i.e. 3GPP's TS 26.234 <a
|
|
href="#ref-3gpp">[3GPP]</a> and the WAP Forum's Multimedia
|
|
Messaging Service Client Transactions Specification <a
|
|
href="#ref-mms">[MMS-CTR]</a>) 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</a> is
|
|
shows such a profile:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="c1">
|
|
<a id="example39" name="example39">Example 39: A Profile
|
|
Using Several Vocabularies</a>
|
|
</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a id="otherparts" name="otherparts">7. Other Parts of the
|
|
RDF Specification</a></h2>
|
|
|
|
<p>In <a href="#intro">Section 1</a>, we indicated that the RDF
|
|
Specification consists of a number of documents (in addition to
|
|
this Primer):</p>
|
|
|
|
<ul>
|
|
<li><a href="http://www.w3.org/TR/rdf-concepts/">RDF Concepts
|
|
and Abstract Syntax</a> <a
|
|
href="#ref-rdf-concepts">[RDF-CONCEPTS]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML
|
|
Syntax Specification</a> <a
|
|
href="#ref-rdf-syntax">[RDF-SYNTAX]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-schema/">RDF Vocabulary
|
|
Description Language 1.0: RDF Schema</a> <a
|
|
href="#ref-rdf-vocabulary">[RDF-VOCABULARY]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-mt/">RDF Semantics</a> <a
|
|
href="#ref-rdf-semantics">[RDF-SEMANTICS]</a></li>
|
|
|
|
<li><a href="http://www.w3.org/TR/rdf-testcases/">RDF Test
|
|
Cases</a> <a href="#ref-rdf-tests">[RDF-TESTS]</a></li>
|
|
</ul>
|
|
|
|
<p>We have already discussed the subjects of the first three of
|
|
these documents, basic RDF concepts (in <a
|
|
href="#statements">Section 2</a>), the RDF/XML syntax (in <a
|
|
href="#rdfxml">Section 3</a>) and RDF Schema (in <a
|
|
href="#rdfschema">Section 5</a>). In this section, we briefly
|
|
describe the remaining documents, in order to explain their role
|
|
in the complete specification of RDF.</p>
|
|
|
|
<div class="section">
|
|
<h3><a id="semantics" name="semantics">7.1 RDF
|
|
Semantics</a></h3>
|
|
|
|
<p>As we've seen 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 <a href="#richerschemas">Section 5.5</a>. In order to serve
|
|
these purposes, the "meaning" of an RDF graph must be defined
|
|
in a very precise manner.</p>
|
|
|
|
<p>Exactly what constitutes the "meaning" of an RDF graph in a
|
|
broad sense may depend on many factors, including social
|
|
conventions, 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 in RDF). 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 <em>formal</em> meaning which determines, with
|
|
mathematical precision, the conclusions (or
|
|
<em>entailments</em>) that machines can draw from an RDF graph.
|
|
The <a href="http://www.w3.org/TR/rdf-mt/">RDF Semantics</a> <a
|
|
href="#ref-rdf-semantics">[RDF-SEMANTICS]</a> defines this
|
|
formal meaning, using a technique called <em>model theory</em>
|
|
for specifying the semantics of a formal language. In other
|
|
words, the RDF model theory provides the formal underpinnings
|
|
for all of the concepts we have described. 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.</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a id="testcases" name="testcases">7.2 Test Cases</a></h3>
|
|
|
|
<p>The <a href="http://www.w3.org/TR/rdf-testcases/">RDF Test
|
|
Cases</a> <a href="#ref-rdf-tests">[RDF-TESTS]</a> 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</a>, 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.</p>
|
|
|
|
<p>The test cases are divided into a number of categories:</p>
|
|
|
|
<ul>
|
|
<li>Positive and Negative Parser Tests: These test whether
|
|
RDF/XML parsers produce a correct N-triples output graph from
|
|
legal RDF/XML input documents, or correctly report errors if
|
|
the input documents are not legal RDF/XML.</li>
|
|
|
|
<li>Positive and Negative Entailment Tests: These test
|
|
whether proper entailments (conclusions) are or are not drawn
|
|
from sets of specified RDF statements.</li>
|
|
|
|
<li>Datatype-aware Entailment Tests: These are positive or
|
|
negative entailment tests that involve the use of datatypes,
|
|
and hence require additional support for the specific
|
|
datatypes involved in the tests.</li>
|
|
|
|
<li>Miscellaneous Tests: These are tests that do not fall
|
|
into one of the other categories.</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a name="references" id="references">8. References</a></h2>
|
|
|
|
<div class="section">
|
|
<h3><a name="normative-references"
|
|
id="normative-references">8.1 Normative References</a></h3>
|
|
|
|
<dl>
|
|
<dt><a id="ref-rdf-concepts"
|
|
name="ref-rdf-concepts"></a>[RDF-CONCEPTS]</dt>
|
|
|
|
<dd><i><a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-concepts-20021108/">Resource
|
|
Description Framework (RDF): Concepts and Abstract
|
|
Syntax</a></i>, Klyne G., Carroll J. (Editors), World Wide
|
|
Web Consortium, 08 November 2002 (work in progress). <a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-concepts-20021108/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/2002/WD-rdf-concepts-20021108/. The <a
|
|
href="http://www.w3.org/TR/rdf-concepts/">latest version</a>
|
|
is http://www.w3.org/TR/rdf-concepts/.</dd>
|
|
|
|
<dt><a id="ref-rdf-mime-type"
|
|
name="ref-rdf-mime-type"></a>[RDF-MIME-TYPE]</dt>
|
|
|
|
<dd><i><a
|
|
href="http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-01.txt">
|
|
Application/rdf+xml Media Type Registration</a></i>, Swartz
|
|
A., IETF Internet Draft, August 2002 (work in progress).
|
|
Version available at <a
|
|
href="http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-01.txt">
|
|
http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-01.txt</a>.</dd>
|
|
|
|
<dt><a id="ref-rdfms" name="ref-rdfms">[RDF-MS]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">Resource
|
|
Description Framework (RDF) Model and Syntax
|
|
Specification</a></cite>, Lassila O., Swick R. (Editors),
|
|
World Wide Web Consortium. 22 February 1999. <a
|
|
href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/. The <a
|
|
href="http://www.w3.org/TR/REC-rdf-syntax/">latest
|
|
version</a> is http://www.w3.org/TR/REC-rdf-syntax/.</dd>
|
|
|
|
<dt><a id="ref-rdf-semantics"
|
|
name="ref-rdf-semantics"></a>[RDF-SEMANTICS]</dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-mt-20021112/">RDF
|
|
Semantics</a></cite>, Hayes P. (Editor), World Wide Web
|
|
Consortium, 12 November 2002 (work in progress). <a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-mt-20021112/">This
|
|
version</a> is http://www.w3.org/TR/2002/WD-rdf-mt-20021112/.
|
|
The <a href="http://www.w3.org/TR/rdf-mt/">latest version</a>
|
|
is http://www.w3.org/TR/rdf-mt/.</dd>
|
|
|
|
<dt><a id="ref-rdf-syntax"
|
|
name="ref-rdf-syntax"></a>[RDF-SYNTAX]</dt>
|
|
|
|
<dd><i><a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-syntax-grammar-20021108/">
|
|
RDF/XML Syntax Specification (Revised)</a></i>, Beckett D.
|
|
(Editor), World Wide Web Consortium, 8 November 2002 (work in
|
|
progress). <a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-syntax-grammar-20021108/">
|
|
This version</a> is
|
|
http://www.w3.org/TR/2002/WD-rdf-syntax-grammar-20021108/.
|
|
The <a href="http://www.w3.org/TR/rdf-syntax-grammar/">latest
|
|
version</a> is http://www.w3.org/TR/rdf-syntax-grammar.</dd>
|
|
|
|
<dt><a id="ref-rdf-tests"
|
|
name="ref-rdf-tests"></a>[RDF-TESTS]</dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-testcases-20021112/">RDF
|
|
Test Cases</a></cite>, Grant J., Beckett D. (Editors), World
|
|
Wide Web Consortium, 12 November 2002 (work in progress). <a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-testcases-20021112/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/2002/WD-rdf-testcases-20021112/. The <a
|
|
href="http://www.w3.org/TR/rdf-testcases/">latest version</a>
|
|
is http://www.w3.org/TR/rdf-testcases/.</dd>
|
|
|
|
<dt><a id="ref-rdf-vocabulary"
|
|
name="ref-rdf-vocabulary"></a>[RDF-VOCABULARY]</dt>
|
|
|
|
<dd><i><a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-schema-20021112/">RDF
|
|
Vocabulary Description Language 1.0: RDF Schema</a></i>,
|
|
Brickley D., Guha R.V. (Editors), World Wide Web Consortium,
|
|
12 November 2002 (work in progress). <a
|
|
href="http://www.w3.org/TR/2002/WD-rdf-schema-20021112/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/2002/WD-rdf-schema-20021112/. The <a
|
|
href="http://www.w3.org/TR/rdf-schema/">latest version</a> is
|
|
http://www.w3.org/TR/rdf-schema/.</dd>
|
|
|
|
<dt><a id="ref-uri" name="ref-uri">[URIS]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.isi.edu/in-notes/rfc2396.txt">RFC 2396 -
|
|
Uniform Resource Identifiers (URI): Generic
|
|
Syntax</a></cite>, Berners-Lee T., Fielding R., Masinter L.,
|
|
IETF, August 1998. This document is
|
|
http://www.isi.edu/in-notes/rfc2396.txt.</dd>
|
|
|
|
<dt><a id="ref-xml" name="ref-xml">[XML]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible
|
|
Markup Language (XML) 1.0, Second Edition</a></cite>, Bray
|
|
T., Paoli J., Sperberg-McQueen C.M., Maler E. (Editors),
|
|
World Wide Web Consortium, 6 October 2000. <a
|
|
href="http://www.w3.org/TR/2000/REC-xml-20001006">This
|
|
version</a> is http://www.w3.org/TR/2000/REC-xml-20001006.
|
|
The <a href="http://www.w3.org/TR/REC-xml">latest version</a>
|
|
is http://www.w3.org/TR/REC-xml.</dd>
|
|
|
|
<dt><a id="ref-xml-base"
|
|
name="ref-xml-base">[XML-BASE]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/">XML
|
|
Base</a></cite>, Marsh J. (Editor), World Wide Web
|
|
Consortium, 27 June 2001. <a
|
|
href="http://www.w3.org/TR/2001/REC-xmlbase-20010627/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/2001/REC-xmlbase-20010627/. The <a
|
|
href="http://www.w3.org/TR/xmlbase/">latest version</a> is
|
|
http://www.w3.org/TR/xmlbase/.</dd>
|
|
|
|
<dt><a id="ref-namespaces"
|
|
name="ref-namespaces">[XML-NS]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces
|
|
in XML</a></cite>, Bray T., Hollander D., Layman A.
|
|
(Editors), World Wide Web Consortium, 14 January 1999. <a
|
|
href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/1999/REC-xml-names-19990114/. The <a
|
|
href="http://www.w3.org/TR/REC-xml-names/">latest version</a>
|
|
is http://www.w3.org/TR/REC-xml-names/.</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h3><a name="informational-references"
|
|
id="informational-references">8.2 Informational
|
|
References</a></h3>
|
|
|
|
<dl>
|
|
<dt><a id="ref-3gpp" name="ref-3gpp">[3GPP]</a></dt>
|
|
|
|
<dd><cite><a href="http://www.3gpp.org/specs/specs.htm">3GPP
|
|
TS 26.234.</a></cite> 3rd Generation Partnership Project;
|
|
Technical Specification Group Services and System Aspects;
|
|
Transparent end-to-end packet switched streaming service;
|
|
Protocols and codecs V5.2.0 (2002-09). <a
|
|
href="http://www.3gpp.org/specs/specs.htm">This document</a>
|
|
is available at http://www.3gpp.org/specs/specs.htm via
|
|
directory
|
|
ftp://ftp.3gpp.org/specs/2002-09/Rel-5/26_series/.</dd>
|
|
|
|
<dt><a id="ref-address-schemes"
|
|
name="ref-address-schemes">[ADDRESS-SCHEMES]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/Addressing/schemes.html">Addressing
|
|
Schemes</a></cite>, Connolly D., 2001. <a
|
|
href="http://www.w3.org/Addressing/schemes.html">This
|
|
document</a> is
|
|
http://www.w3.org/Addressing/schemes.html.</dd>
|
|
|
|
<dt><a id="ref-bates96" name="ref-bates96">[BATES96]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://is.gseis.ucla.edu/research/mjbates.html">Indexing
|
|
and Access for Digital Libraries and the Internet: Human,
|
|
Database, and Domain Factors</a></cite>, Bates M.J., 1996. <a
|
|
href="http://is.gseis.ucla.edu/research/mjbates.html">This
|
|
document</a> is
|
|
http://is.gseis.ucla.edu/research/mjbates.html.</dd>
|
|
|
|
<dt><a id="ref-berners-lee98"
|
|
name="ref-berners-lee98">[BERNERS-LEE98]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/DesignIssues/RDFnot.html">What the
|
|
Semantic Web can represent</a></cite>, Berners-Lee T., 1998.
|
|
<a href="http://www.w3.org/DesignIssues/RDFnot.html">This
|
|
document</a> is
|
|
http://www.w3.org/DesignIssues/RDFnot.html.</dd>
|
|
|
|
<dt><a id="ref-ccpp" name="ref-ccpp">[CC/PP]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/">
|
|
Composite Capability/Preference Profiles (CC/PP): Structure
|
|
and Vocabularies</a></cite>, Klyne G., Reynolds F., Woodrow
|
|
C., Ohto H., Butler, M., World Wide Web Consortium, 08
|
|
November 2002 (work in progress). <a
|
|
href="http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/">
|
|
This version</a> is
|
|
http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/. The
|
|
<a href="http://www.w3.org/TR/CCPP-struct-vocab/">latest
|
|
version</a> is http://www.w3.org/TR/CCPP-struct-vocab/.</dd>
|
|
|
|
<dt><a id="ref-cg" name="ref-cg">[CG]</a></dt>
|
|
|
|
<dd><cite>Conceptual Graphs</cite>, Sowa J., ISO working
|
|
document ISO/JTC1/SC32/WG2 N 000, 2 April 2001 (work in
|
|
progress). Available at <a
|
|
href="http://users.bestweb.net/~sowa/cg/cgstand.htm">http://users.bestweb.net/~sowa/cg/cgstand.htm</a>.</dd>
|
|
|
|
<dt><a id="ref-cowan" name="ref-cowan">[COWAN]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://seminars.seyboldreports.com/2002_new_york/files/presentations/014/cowan_john.ppt">
|
|
Metadata, Reuters Health Information, and Cross-Media
|
|
Publishing</a></cite> , Cowan, J., 2002. Presentation at
|
|
Seybold New York 2002 Enterprise Publishing Conference. <a
|
|
href="http://seminars.seyboldreports.com/2002_new_york/files/presentations/014/cowan_john.ppt">
|
|
This document</a> is
|
|
http://seminars.seyboldreports.com/seminars/2002_new_york/presentations/014/cowan_john.ppt.
|
|
An accompanying <a
|
|
href="http://seminars.seyboldreports.com/2002_new_york/files/transcripts/doc/transcript_EP7.doc">
|
|
transcript</a> is
|
|
http://seminars.seyboldreports.com/2002_new_york/files/transcripts/doc/transcript_EP7.doc</dd>
|
|
|
|
<dt><a id="ref-daf" name="ref-daf">[DAF]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://cgi.omg.org/docs/formal/01-06-01.pdf">Utility
|
|
Management System (UMS) Data Access Facility</a></cite>,
|
|
Object Management Group, OMG document formal/01-06-01, June
|
|
2001. <a
|
|
href="http://cgi.omg.org/docs/formal/01-06-01.pdf">This
|
|
document</a> is
|
|
http://cgi.omg.org/docs/formal/01-06-01.pdf.</dd>
|
|
|
|
<dt><a id="ref-damloil"
|
|
name="ref-damloil">[DAML+OIL]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/daml+oil-reference">DAML+OIL
|
|
(March 2001) Reference Description</a></cite>, Connolly D.,
|
|
van Harmelen F., Horrocks I., McGuinness D.L.,
|
|
Patel-Schneider P.F., Stein L.A., World Wide Web Consortium,
|
|
18 December 2001. <a
|
|
href="http://www.w3.org/TR/daml+oil-reference">This
|
|
document</a> is http://www.w3.org/TR/daml+oil-reference.</dd>
|
|
|
|
<dt><a id="ref-dublin-core"
|
|
name="ref-dublin-core">[DC]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://dublincore.org/documents/dces/">Dublin Core
|
|
Metadata Element Set, Version 1.1: Reference
|
|
Description</a></cite>, 02 July 1999. <a
|
|
href="http://dublincore.org/documents/dces/">This
|
|
document</a> is http://dublincore.org/documents/dces/.</dd>
|
|
|
|
<dt><a id="ref-diprinc" name="ref-diprinc">[DIPRINC]</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/TR/di-princ/">Device
|
|
Independence Principles.</a></cite> Gimson, R., Finkelstein,
|
|
S., Maes, S., Suryanarayana, L., World Wide Web Consortium,
|
|
18 September 2001 (work in progress). <a
|
|
href="http://www.w3.org/TR/2001/WD-di-princ-20010918/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/2001/WD-di-princ-20010918. The <a
|
|
href="http://www.w3.org/TR/di-princ/">latest version</a> is
|
|
http://www.w3.org/TR/di-princ/.</dd>
|
|
|
|
<dt><a id="ref-devos" name="ref-devos">[DWZ01]</a></dt>
|
|
|
|
<dd><cite><a href="http://www.langdale.com.au/PICA/">XML for
|
|
CIM Model Exchange</a></cite> , deVos A., Widergreen S.E.,
|
|
Zhu J., Proc. IEEE Conference on Power Industry Computer
|
|
Systems, Sydney, Australia, 2001. <a
|
|
href="http://www.langdale.com.au/PICA/">This document</a> is
|
|
http://www.langdale.com.au/PICA/.</dd>
|
|
|
|
<dt><a id="ref-gray" name="ref-gray">[GRAY]</a></dt>
|
|
|
|
<dd><cite>Logic, Algebra and Databases</cite>, Gray P., Ellis
|
|
Horwood Ltd., 1984. ISBN 0-85312-709-3, 0-85312-803-0,
|
|
0-470-20103-7, 0-470-20259-9.</dd>
|
|
|
|
<dt><a id="ref-hayes" name="ref-hayes">[HAYES]</a></dt>
|
|
|
|
<dd><cite>In Defense of Logic</cite>, Hayes P., Proceedings
|
|
from the International Joint Conference on Artificial
|
|
Intelligence, 1975, San Francisco. Morgan Kaufmann Inc.,
|
|
1977. Also in <cite>Computation and Intelligence: Collected
|
|
Readings</cite>, Luger G. (ed), AAAI press/MIT press, 1995.
|
|
ISBN 0-262-62101-0.</dd>
|
|
|
|
<dt><a id="ref-kif" name="ref-kif">[KIF]</a></dt>
|
|
|
|
<dd><cite>Knowledge Interchange Format</cite>, Genesereth M.,
|
|
draft proposed American National Standard NCITS.T2/98-004.
|
|
Available at <a
|
|
href="http://logic.stanford.edu/kif/dpans.html">http://logic.stanford.edu/kif/dpans.html</a>.</dd>
|
|
|
|
<dt><a id="ref-luger" name="ref-luger">[LUGER]</a></dt>
|
|
|
|
<dd><cite>Artificial Intelligence: Structures and Strategies
|
|
for Complex Problem Solving</cite> (3rd ed.), Luger G.,
|
|
Stubblefield W., Addison Wesley Longman, 1998. ISBN
|
|
0-805-31196-3.</dd>
|
|
|
|
<dt><a id="ref-mms" name="ref-mms">[MMS-CTR]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.openmobilealliance.org/">Multimedia
|
|
Messaging Service Client Transactions
|
|
Specification.</a></cite> WAP-206-MMSCTR-20020115-a. This
|
|
document is available at
|
|
http://www.openmobilealliance.org/.</dd>
|
|
|
|
<dt><a id="ref-nameaddress"
|
|
name="ref-nameaddress">[NAMEADDRESS]</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/Addressing/">Naming and
|
|
Addressing: URIs, URLs, ...</a></cite>, Connolly D., 2002. <a
|
|
href="http://www.w3.org/Addressing/">This document</a> is
|
|
http://www.w3.org/Addressing/.</dd>
|
|
|
|
<dt><a id="ref-owl" name="ref-owl">[OWL]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2002/WD-owl-ref-20021112/">OWL Web
|
|
Ontology Language 1.0 Reference</a></cite>, Dean M., Connolly
|
|
D., van Harmelen F., Hendler J., Horrocks I., McGuinness
|
|
D.L., Patel-Schneider P.F., Stein L.A. (Editors), World Wide
|
|
Web Consortium, 12 November 2002 (work in progress). <a
|
|
href="http://www.w3.org/TR/2002/WD-owl-ref-20021112/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/2002/WD-owl-ref-20021112/. The <a
|
|
href="http://www.w3.org/TR/owl-ref/">latest version</a> is
|
|
http://www.w3.org/TR/owl-ref/.</dd>
|
|
|
|
<dt><a id="ref-prism" name="ref-prism">[PRISM]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.prismstandard.org/techdev/prismspec11.asp">PRISM:
|
|
Publishing Requirements for Industry Standard
|
|
Metadata</a></cite>, Version 1.1, 19 February 2002. <a
|
|
href="http://www.prismstandard.org/techdev/prismspec11.asp">This
|
|
document</a> is
|
|
http://www.prismstandard.org/techdev/prismspec11.asp.</dd>
|
|
|
|
<dt><a id="ref-rdf-issue"
|
|
name="ref-rdf-issue">[RDFISSUE]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/2000/03/rdf-tracking/">RDF Issue
|
|
Tracking</a></cite>, McBride B., 2002. <a
|
|
href="http://www.w3.org/2000/03/rdf-tracking/">This
|
|
document</a> is http://www.w3.org/2000/03/rdf-tracking/.</dd>
|
|
|
|
<dt><a id="ref-rss" name="ref-rss">[RSS]</a></dt>
|
|
|
|
<dd><cite><a href="http://purl.org/rss/1.0/spec">RDF Site
|
|
Summary (RSS) 1.0</a></cite>, Beged-Dov G., Brickley D.,
|
|
Dornfest R., Davis I., Dodds L., Eisenzopf J., Galbraith D.,
|
|
Guha R.V., MacLeod K., Miller E., Swartz A., van der Vlist
|
|
E., 2000. <a href="http://purl.org/rss/1.0/spec">This
|
|
document</a> is http://purl.org/rss/1.0/spec.</dd>
|
|
|
|
<dt><a id="ref-sowa" name="ref-sowa">[SOWA]</a></dt>
|
|
|
|
<dd><cite>Knowledge Representation: Logical, Philosophical
|
|
and Computational Foundations</cite>, Sowa J., Brookes/Cole,
|
|
2000. ISBN 0-534-94965-7.</dd>
|
|
|
|
<dt><a id="ref-uaprof" name="ref-uaprof">[UAPROF]</a></dt>
|
|
|
|
<dd><cite><a href="http://www.openmobilealliance.org/">User
|
|
Agent Profile.</a></cite> OMA-WAP-UAProf-v1_1. This document
|
|
is available at http://www.openmobilealliance.org/.</dd>
|
|
|
|
<dt><a id="ref-webdata" name="ref-webdata">[WEBDATA]</a></dt>
|
|
|
|
<dd><cite><a href="http://www.w3.org/1999/04/WebData">Web
|
|
Architecture: Describing and Exchanging Data</a></cite>,
|
|
Berners-Lee T., Connolly D., Swick R., World Wide Web
|
|
Consortium, 7 June 1999. <a
|
|
href="http://www.w3.org/1999/04/WebData">This document</a> is
|
|
http://www.w3.org/1999/04/WebData.</dd>
|
|
|
|
<dt><a id="ref-xlink" name="ref-xlink">[XLINK]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2001/REC-xlink-20010627/">XML
|
|
Linking Language (XLink) Version 1.0</a></cite>, DeRose S.,
|
|
Maler E., Orchard D. (Editors), World Wide Web Consortium, 27
|
|
June 2001. <a
|
|
href="http://www.w3.org/TR/2001/REC-xlink-20010627/">This
|
|
version</a> is http://www.w3.org/TR/2001/REC-xlink-20010627/.
|
|
The <a href="http://www.w3.org/TR/xlink/">latest version</a>
|
|
is http://www.w3.org/TR/xlink/.</dd>
|
|
|
|
<dt><a id="ref-xmlschema2"
|
|
name="ref-xmlschema2">[XML-SCHEMA2]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">XML
|
|
Schema Part 2: Datatypes</a></cite>, Biron P., Malhotra A.
|
|
(Editors), World Wide Web Consortium. 2 May 2001. <a
|
|
href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">This
|
|
version</a> is
|
|
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. The <a
|
|
href="http://www.w3.org/TR/xmlschema-2/">latest version</a>
|
|
is http://www.w3.org/TR/xmlschema-2/.</dd>
|
|
|
|
<dt><a id="ref-xpackage"
|
|
name="ref-xpackage">[XPACKAGE]</a></dt>
|
|
|
|
<dd><cite><a
|
|
href="http://www.xpackage.org/specification/xpackage-draft-20021023.html">
|
|
XML Package (XPackage) 1.0</a></cite> , Wilson G., Open eBook
|
|
Forum Editor's Working Draft, 23 October 2002. <a
|
|
href="http://www.xpackage.org/specification/xpackage-draft-20021023.html">
|
|
This version</a> is
|
|
http://www.xpackage.org/specification/xpackage-draft-20021023.html.
|
|
The <a href="http://www.xpackage.org/specification/">latest
|
|
version</a> is http://www.xpackage.org/specification/.</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2><a id="acknowledgements" name="acknowledgements">9.
|
|
Acknowledgments</a></h2>
|
|
|
|
<p>This document has benefited from inputs from many members of
|
|
the <a href="http://www.w3.org/2001/sw/RDFCore/">RDF Core Working
|
|
Group</a>. 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.</p>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div class="section">
|
|
<h2 id="uri"><a id="identifiers" name="identifiers"></a>Appendix
|
|
A: More on Uniform Resource Identifiers (URIs)</h2>
|
|
|
|
<p>As we saw in <a href="#basicconcepts">Section 2.1</a>, the Web
|
|
provides a general form of identifier, called the <a
|
|
href="http://www.isi.edu/in-notes/rfc2396.txt">Uniform Resource
|
|
Identifier</a> (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 <em>URI schemes</em> (URI forms) have been
|
|
already been developed, and are being used, for various purposes.
|
|
Examples include:</p>
|
|
|
|
<ul>
|
|
<li><tt>http:</tt> (Hypertext Transfer Protocol, for Web
|
|
pages)</li>
|
|
|
|
<li><tt>mailto:</tt> (email addresses), e.g.,
|
|
mailto:em@w3.org</li>
|
|
|
|
<li><tt>ftp:</tt> (File Transfer Protocol)</li>
|
|
|
|
<li><tt>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)</li>
|
|
</ul>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/Addressing/schemes.html">Addressing
|
|
Schemes</a> <a href="#ref-address-schemes">[ADDRESS-SCHEMES]</a>,
|
|
and it is a good idea to consider adapting one of the existing
|
|
schemes for any specialized identification purposes you may have,
|
|
rather than trying to invent a new one.</p>
|
|
|
|
<p>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
|
|
special authority or permission to create a URI for something.
|
|
Also, you can create URIs for things you don't own, just as in
|
|
ordinary language you can use whatever name you like for things
|
|
you don't own.</p>
|
|
|
|
<p>As we also saw in <a href="#basicconcepts">Section 2.1</a>,
|
|
RDF uses <em>URI references</em> <a href="#ref-uri">[URIS]</a> to
|
|
name subjects, predicates, and objects in RDF statements. A URI
|
|
reference (or <em>URIref</em>) is a URI, together with an
|
|
optional <em>fragment identifier</em> 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>.</p>
|
|
|
|
<p>URIrefs may be either <em>absolute</em> or <em>relative</em>.
|
|
An <em>absolute</em> 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 <em>relative</em>
|
|
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>.</p>
|
|
|
|
<p><a href="#ref-rdf-concepts">[RDF-CONCEPTS]</a> 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. You should consult
|
|
<a href="#ref-rdf-syntax">[RDF-SYNTAX]</a> for further
|
|
details.</p>
|
|
|
|
<p>Both RDF and web browsers use URIrefs to identify things.
|
|
However, RDF and browsers interpret URIrefs in slightly different
|
|
ways. This is because RDF uses URIrefs <em>only</em> to identify
|
|
things, while browsers also use URIrefs to <em>retrieve</em>
|
|
things. Often there is no effective difference, but in some cases
|
|
the difference can be significant. One obvious difference is 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 <em>cannot</em> be retrieved on the 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 "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 page describing it (a subject discussed
|
|
further in <a href="#structuredproperties">Section 2.3</a>).
|
|
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.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<p><tt>http://www.example.org/index.html</tt><br />
|
|
<tt>http://www.example.org/index.html#Section2</tt></p>
|
|
|
|
<p>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
|
|
<em>identify</em> 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 mean that the HTML-defined containment relationship might
|
|
not exist, just that RDF doesn't assume that a relationship
|
|
exists based only on the fact that the URI parts of the URI
|
|
references are the same.)</p>
|
|
</div>
|
|
|
|
<div class="section">
|
|
<h2 id="xml"><a id="documents" name="documents"></a>Appendix B:
|
|
More on the Extensible Markup Language (XML)</h2>
|
|
|
|
<p>The <a
|
|
href="http://www.w3.org/TR/1998/REC-xml-19980210.html">Extensible
|
|
Markup Language</a> <a href="#ref-xml">[XML]</a> 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 <em>tags</em>. This
|
|
markup allows a processing program to interpret the various
|
|
pieces of content (called <em>elements</em>). 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. For example,
|
|
the following is a simple passage marked up using an XML-based
|
|
markup language:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<sentence><person webid="http://example.com/#johnsmith">I</person>
|
|
just got a new pet <animal>dog</animal>.</sentence>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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
|
|
<em>start-tag</em> <tt><animal></tt>, the element
|
|
<em>content</em>, and a matching <em>end-tag</em>
|
|
<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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<sentence>
|
|
<person webid="http://example.com/#johnsmith">I</person>
|
|
just got a new pet
|
|
<animal>dog</animal>.
|
|
</sentence>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 <em>empty-element tag</em>, as in
|
|
<tt><animal/></tt>.</p>
|
|
|
|
<p>In some cases, a start-tag (or empty-element tag) may contain
|
|
qualifying information other than the tag name, in the form of
|
|
<em>attributes</em>. 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).</p>
|
|
|
|
<p>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 <em>would</em> 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:</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<dfgre><reghh bjhbw="http://example.com/#johnsmith">I</reghh>
|
|
just got a new pet <yudis>dog</yudis>.</dfgre>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>To prevent confusion, it is necessary to uniquely identify
|
|
markup elements. This is done in XML using <a
|
|
href="http://www.w3.org/TR/REC-xml-names/">XML Namespaces</a> <a
|
|
href="#ref-namespaces">[XML-NS]</a>. A <em>namespace</em> 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 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. The following example illustrates the
|
|
use of an XML namespace.</p>
|
|
|
|
<div class="exampleOuter exampleInner">
|
|
<pre>
|
|
<my:sentence xmlns:my="http://example.com/xml/documents/">
|
|
<my:person my:webid="http://example.com/#johnsmith">I</my:person>
|
|
just got a new pet <my:animal>dog</my:animal>.
|
|
</my:sentence>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>In this example, the attribute
|
|
<tt>xmlns:my="http://example.com/xml/documents/"</tt> declares a
|
|
namespace for use in this piece of XML. It maps the
|
|
<em>prefix</em> <tt>my</tt> to the namespace URI
|
|
<tt>http://example.com/xml/documents/</tt>. The XML content can
|
|
then use <em>qualified names</em> (or <em>QNames</em>) like
|
|
<tt>my:person</tt> as tags. A QName contains a prefix that
|
|
identifies a namespace, followed by a colon, and then a <em>local
|
|
name</em> 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 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.</p>
|
|
|
|
<p>As noted in <a href="#basicconcepts">Section 2.1</a>, RDF
|
|
defines a particular XML markup language, called RDF/XML, which
|
|
is described in more detail in <a href="#rdfxml">Section
|
|
3</a>.</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div class="metadata">
|
|
<p><a href="metadata.rdf"><img border="0"
|
|
src="http://www.w3.org/RDF/icons/rdf_metadata_button.40"
|
|
alt="RDF/XML Metadata" /></a></p>
|
|
</div>
|
|
</body>
|
|
</html>
|
|
|