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.
1607 lines
73 KiB
1607 lines
73 KiB
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
|
|
<title>Protocol for Web Description Resources (POWDER): Primer</title>
|
|
<style type="text/css">
|
|
.ednote {
|
|
border: 1px dashed black;
|
|
background-color: #FFc0c0;
|
|
color: inherit;
|
|
}
|
|
.ednote:before {
|
|
content: "Editorial Note: ";
|
|
font-weight: bold;
|
|
}
|
|
.new {
|
|
border: 1px dashed black;
|
|
background-color: #FFFF80;
|
|
color: inherit;
|
|
}
|
|
.new:before {
|
|
content: "New Text: ";
|
|
font-weight: bold;
|
|
}
|
|
.todo {
|
|
border: 1px dashed black;
|
|
background-color: #80ffff;
|
|
color: inherit;
|
|
}
|
|
.todo:before {
|
|
content: "Todo: ";
|
|
font-weight: bold;
|
|
}
|
|
.requirement {
|
|
background-color: #DDDD80;
|
|
color: inherit;
|
|
border: 1px black solid;
|
|
padding: 0.5em;
|
|
}
|
|
|
|
.requirement:before {
|
|
content: "Requirement: ";
|
|
font-weight: bold;
|
|
}
|
|
|
|
|
|
.example {padding: 0.5em; background-color: rgb(204, 255, 204); border:thin dotted black; white-space:nowrap; overflow:auto}
|
|
p.caption {font-weight:bold}</style>
|
|
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE"/>
|
|
</head>
|
|
|
|
<body>
|
|
<!-- HEADER -->
|
|
|
|
<div class="head">
|
|
<a href="http://www.w3.org/"><img alt="W3C"
|
|
src="http://www.w3.org/Icons/w3c_home" height="48" width="72" /></a>
|
|
|
|
<h1>Protocol for Web Description Resources (POWDER): Primer</h1>
|
|
|
|
<h2>W3C Working Group Note 1 September 2009</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/2009/NOTE-powder-primer-20090901/">http://www.w3.org/TR/2009/NOTE-powder-primer-20090901/</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/powder-primer/">http://www.w3.org/TR/powder-primer/</a></dd>
|
|
<dt>Previous version</dt>
|
|
<dd><a href="http://www.w3.org/TR/2009/NOTE-powder-primer-20090604/">http://www.w3.org/TR/2009/NOTE-powder-primer-20090604/</a></dd>
|
|
<dt>Editor:</dt>
|
|
<dd>Kai Scheppe, Deutsche Telekom AG</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
© 2009 <a href="http://www.w3.org/"><acronym
|
|
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
|
|
href="http://www.csail.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>
|
|
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply. </p>
|
|
<hr />
|
|
</div>
|
|
|
|
<h2 class="notoc">Abstract</h2>
|
|
|
|
<p>POWDER — the Protocol for Web Description Resources — provides
|
|
a mechanism to describe and discover Web resources and helps the users to
|
|
make a decision whether a given resource is of interest. There are a variety
|
|
of use cases: from providing a better means to describing Web resources and
|
|
creating trustmarks to aiding content discovery, child protection and
|
|
Semantic Web searches.</p>
|
|
|
|
<p>There are two varieties of POWDER: a complex, semantically rich variety,
|
|
called POWDER-S, and a much simpler version, just called POWDER, which is
|
|
intended as the primary transport mechanism for Description Resources.
|
|
POWDER-S can be generated automatically from POWDER.</p>
|
|
<!-- ABSTRACT -->
|
|
<hr />
|
|
<!-- SOTD -->
|
|
|
|
<h2>Status of this Document</h2>
|
|
|
|
<p><em>This section describes the status of this document at the time of its
|
|
publication. Other documents may supersede this document. A list of current
|
|
W3C publications and the latest revision of this technical report can be
|
|
found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a>
|
|
at http://www.w3.org/TR/.</em></p>
|
|
|
|
|
|
<p>This is the fourth publication of the document as a Working Group Note by the
|
|
<a href="http://www.w3.org/2007/powder/">POWDER Working Group</a> which does not expect to publish further versions.
|
|
There have been no changes since the <a href="http://www.w3.org/TR/2009/NOTE-powder-test-20090403/">previous version</a>.</p>
|
|
|
|
<p>Publication of this Note is synchronized with several other documents:</p>
|
|
<ul>
|
|
<li><a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/">POWDER: Description Resources</a> (Recommendation)</li>
|
|
<li><a href="http://www.w3.org/TR/2009/REC-powder-grouping-20090901/">POWDER: Grouping of Resources</a> (Recommendation)</li>
|
|
<li><a href="http://www.w3.org/TR/2009/REC-powder-formal-20090901/">POWDER: Formal Semantics</a> (Recommendation)</li>
|
|
<li><a href="http://www.w3.org/TR/2009/NOTE-powder-test-20090604/">POWDER: Test Suite</a> (Working Group Note)</li>
|
|
</ul>
|
|
|
|
<p>To send comments, please use the
|
|
public mailing list (<a href="mailto:public-powderwg@w3.org">public-powderwg@w3.org</a>), an <a href="http://lists.w3.org/Archives/Public/public-powderwg/">archived
|
|
mailing list</a>. See <a href="http://www.w3.org/Mail/">W3C mailing list and archive usage guidelines</a>.</p>
|
|
|
|
<p>Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is
|
|
a draft document and may be updated, replaced or obsoleted by other documents at any time. It is
|
|
inappropriate to cite this document as other than work in progress.</p>
|
|
|
|
<p>This document has been produced as part of the <a href=
|
|
"http://www.w3.org/2001/sw/">Semantic Web Activity</a>, following the procedures set out for the <a href="http://www.w3.org/Consortium/Process/">W3C Process</a>.</p>
|
|
<p> This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/40243/status">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>
|
|
|
|
<hr />
|
|
<!-- CONTENTS -->
|
|
|
|
<h2 id="ToC">Table of Contents</h2>
|
|
<ol>
|
|
<li><a href="#What">What is POWDER?</a></li>
|
|
<li><a href="#would">Why would I want to use POWDER?</a>
|
|
<ul>
|
|
<li><a href="#Grouping">Grouping</a></li>
|
|
<li><a href="#Data">Data retrieval efficiency</a></li>
|
|
<li><a href="#Profile">Profile matching</a></li>
|
|
<li><a href="#Trustmarks">Trustmarks</a></li>
|
|
<li><a href="#Semantic">Semantic Annotation</a></li>
|
|
<!-- <li><a href="#richmeta">Rich Meta Data</a> </li> -->
|
|
</ul>
|
|
</li>
|
|
<li><a href="#does">How does POWDER work in the real world?</a>
|
|
<ul>
|
|
<li><a href="#Trustmarks2">Trustmarks</a>
|
|
<ul>
|
|
<li><a href="#VISUAL">Visual notification</a></li>
|
|
<li><a href="#MONITORING">Monitoring</a></li>
|
|
<li><a href="#Descriptio">Description authentication</a> </li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Accessibil">Accessibility</a></li>
|
|
<li><a href="#MobileOK">MobileOK</a></li>
|
|
<li><a href="#Child">Child Protection</a></li>
|
|
<li><a href="#Functional">Functional User Experience</a></li>
|
|
<li><a href="#Privileged">Privileged Content</a></li>
|
|
<li><a href="#Semantics">Semantics</a>
|
|
<ul>
|
|
<li><a href="#Search">Search</a></li>
|
|
<li><a href="#Distinguis">Distinguishing opinion</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#POWDER">How do I use POWDER?</a>
|
|
<ul>
|
|
<li><a href="#create">How do I create a Description Resource?</a></li>
|
|
<li><a href="#publish">How do I publish a DR?</a></li>
|
|
<li><a href="#ensuretrust">How do I make my DR more
|
|
trustworthy?</a></li>
|
|
<li><a href="#find">How do I find DRs for a document?</a></li>
|
|
<li><a href="#process-docs">How do I process POWDER documents?</a></li>
|
|
<li><a href="#process1">How do I process POWDER-S?</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#What1">What do I need to use POWDER?</a> </li>
|
|
<li><a href="#powder-s">POWDER-S</a></li>
|
|
<li><a href="#examples">Examples</a>
|
|
<ul>
|
|
<li><a href="#ICRA1">ICRA Labelling</a></li>
|
|
<li><a href="#example_mobileOK">mobileOK</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Acknowledg">Acknowledgements</a> </li>
|
|
<li><a href="#References">References</a> </li>
|
|
</ol>
|
|
<hr />
|
|
<!-- What is it? -->
|
|
|
|
<h2><a name="What" id="What">1. What is POWDER?</a></h2>
|
|
|
|
<p>POWDER is an abbreviation for "Protocol for Web Description Resources."
|
|
The goal of the working group has been to develop a mechanism that allows not
|
|
only the provision of descriptions but also a way to apply them to groups of
|
|
online resources and for the authentication of those descriptions.</p>
|
|
|
|
<p>The primary 'unit of information' within POWDER is the <strong>Description
|
|
Resource</strong> (DR), which comprises:</p>
|
|
<ul>
|
|
<li>attribution (assertions about both the circumstances of its own
|
|
creation and the entity that created it);</li>
|
|
<li>scope (to which resources does the description apply);</li>
|
|
<li>the description itself.</li>
|
|
</ul>
|
|
|
|
<p>There are two varieties of POWDER:</p>
|
|
<ul>
|
|
<li>a simple version, called POWDER;</li>
|
|
<li>a semantically rich variety, called POWDER-S.</li>
|
|
</ul>
|
|
|
|
<p>The simple version has relatively loose, human-readable 'operational
|
|
semantics,' and is written in XML.</p>
|
|
|
|
<p>The semantically-rich version, known as POWDER-S, allows POWDER to harness
|
|
the Semantic Web at large and encodes formal semantics that underpin the
|
|
operational semantics. </p>
|
|
|
|
<p>There is a third, transitory version of POWDER, called POWDER-BASE, which
|
|
is intended for processors and is not of concern for this document. A
|
|
"Gleaning Resource Descriptions from Dialects of Languages" (<a
|
|
href="http://www.w3.org/TR/grddl/">GRDDL)</a> transform, may automatically
|
|
generate POWDER-S as RDF/OWL from a POWDER document. The details of this
|
|
transformation are defined in the [<a href="#formal">FORMAL</a>] document.
|
|
XSLTs are available to support this. Alternatively, POWDER-S may be written
|
|
directly.</p>
|
|
|
|
<p>There is no restriction on which form to use, but it should be noted that
|
|
the simple version is intended as the primary exchange mechanism between
|
|
systems. All POWDER tools should process POWDER. Using the POWDER-S form is
|
|
optional, so that a processor may not necessarily understand this form.</p>
|
|
|
|
<p>POWDER-S is designed to facilitate incorporation of POWDER information in
|
|
larger RDF-based systems and it should be noted that such systems will need
|
|
to implement a Semantic Extension to do this (see <a href="#process1">How do
|
|
I process POWDER-S</a>).</p>
|
|
|
|
<p>Importantly, POWDER allows a variety of questions to be answered about a
|
|
given Web resource or group of resources, without having to actually retrieve
|
|
and inspect the resource(s).</p>
|
|
|
|
<p>At first a Description Resource is simply a claim: somebody is making some
|
|
statement about a given resource, or group of resources. However, most users
|
|
would have to trust the person that made the claim before deciding whether to
|
|
trust the data. If a DR is made available directly by a well-known content
|
|
provider that is trusted to uphold a certain level of quality, then the data
|
|
might readily be trusted. However, this will not always be sufficient. Since
|
|
a DR may be published by anyone, anywhere, to describe anything, an end user
|
|
may reasonably want to query the cited author of the DR to ask questions such
|
|
as: Did you really make that claim? And, if so, when? Would you make the same
|
|
claim today?</p>
|
|
|
|
<p>For some situations this might still not be sufficient for the end user.
|
|
To facilitate the further extension of trust a means has been provided to
|
|
allow certification of DRs. A Description Resource that has been certified
|
|
immediately gains in trust, through the verification by a third and trusted
|
|
party of the original claims made by the DR author.</p>
|
|
|
|
<p>Through the combination of these tools various questions can be answered
|
|
using a Description Resource, without having to retrieve the resource
|
|
itself.</p>
|
|
|
|
<p>The following are examples of questions that could be asked using
|
|
POWDER:</p>
|
|
<ul>
|
|
<li>Which resources does the DR describe?</li>
|
|
<li>What is the description?</li>
|
|
<li>Who has created the description?</li>
|
|
<li>When was the description created?</li>
|
|
<li>Until when is the description considered valid?</li>
|
|
<li>From when is the description considered valid?</li>
|
|
<li>Does anybody agree with this description?</li>
|
|
<li>Do other descriptions exist about this group of resources?</li>
|
|
</ul>
|
|
|
|
<p>The POWDER Suite consists of the following documents, in order of
|
|
recommended reading </p>
|
|
<ol>
|
|
<li><a href="http://www.w3.org/TR/powder-primer">POWDER: Primer</a> - this
|
|
document.</li>
|
|
<li><a href="http://www.w3.org/TR/powder-use-cases/">POWDER: Use Cases and
|
|
Requirements</a> - the premises upon which POWDER was created.</li>
|
|
<li><a href="http://www.w3.org/TR/powder-dr/">POWDER: Description
|
|
Resources</a> - the definition and structure of Description Resources
|
|
(DR).</li>
|
|
<li><a href="http://www.w3.org/TR/powder-grouping/">POWDER: Grouping of
|
|
Resources</a> - the method by which sets of resources may be defined to
|
|
which DRs apply.</li>
|
|
<li><a href="http://www.w3.org/TR/powder-formal/">POWDER: Formal
|
|
Semantics</a> - a detailed description of the formal semantics of
|
|
POWDER-S and of the GRDDL transformation process.</li>
|
|
<li><a href="http://www.w3.org/TR/powder-test/">POWDER: Test Suite</a> -
|
|
provides data against which conformant POWDER applications may be
|
|
tested.</li>
|
|
<li><a href="http://www.w3.org/TR/powder-voc/">POWDER: Web Description
|
|
Resources (WDRS) POWDER-S Vocabulary</a> - the definition of the RDF
|
|
vocabulary that is used to express POWDER-S.</li>
|
|
<li><a href="http://www.w3.org/2007/05/powder">XML Schema for POWDER and
|
|
POWDER-BASE</a> - the namespace document/schema for POWDER</li>
|
|
</ol>
|
|
|
|
<p>There are a variety of tools available to aid in the implementation of
|
|
POWDER.</p>
|
|
<ol>
|
|
<li>POWDER Validator</li>
|
|
<li>POWDER Processor - PERL based</li>
|
|
<li>POWDER-S Processing kit</li>
|
|
<li>POWDER Processor - PHP based</li>
|
|
<li>TransOnto - a semantic POWDER Processor</li>
|
|
<li>POWDER to POWDER-BASE transformation tool</li>
|
|
<li>POWDER to POWDER-BASE XSLT (using XSLT2)</li>
|
|
<li>POWDER-BASE to POWDER-S XSLT</li>
|
|
<li>POWDER Grouping Tester</li>
|
|
</ol>
|
|
<p>Details and newest versions can be found at the <a
|
|
href="http://www.w3.org/2007/powder/">POWDER home page</a>. </p>
|
|
|
|
<h2><a name="would" id="would">2. Why would I want to use POWDER?</a></h2>
|
|
|
|
<p>The amount of information on the web grows continually. Conversely, the
|
|
amount of time people have to devote to this information seems to be
|
|
decreasing. To cope with these constraints (too much information and too
|
|
little time), users need a system where more customized content is delivered
|
|
to them in the most personalized way. Basically the average user wants to get
|
|
online, find what they want and move on.</p>
|
|
|
|
<p>From an End User's Perspective, POWDER:</p>
|
|
<ul>
|
|
<li>delivers more of what you asked for and less of what you don't
|
|
want;</li>
|
|
<li>allows you to judge the trustworthiness of information found on the
|
|
Web;</li>
|
|
<li>brings the best of the Web to your browser.</li>
|
|
</ul>
|
|
|
|
<p>From a Publisher's Perspective, POWDER:</p>
|
|
<ul>
|
|
<li>is an easy and inexpensive way to describe lots of things at once (such
|
|
as everything on a Web site);</li>
|
|
<li>is open to authentication so that others know they can trust your
|
|
data;</li>
|
|
<li>opens up your data to the Semantic Web, without having to know anything
|
|
about RDF</li>
|
|
</ul>
|
|
|
|
<p>From a Service Provider's Perspective, POWDER:</p>
|
|
<ul>
|
|
<li>supports real-time content personalization;</li>
|
|
<li>makes discovering relevant & trustworthy content easier;</li>
|
|
<li>identifies online resources that meet criteria that are not solely
|
|
based on popularity.</li>
|
|
</ul>
|
|
|
|
<p>Use Cases That Have Driven the Development of POWDER Include:</p>
|
|
<ul>
|
|
<li>context-aware content discovery and delivery</li>
|
|
<li>content personalization (e.g. for accessibility, delivery context,
|
|
child protection)</li>
|
|
<li>interoperable, machine-readable trustmarks</li>
|
|
</ul>
|
|
|
|
<p>POWDER offers a much more dependable means by which to deliver the most
|
|
relevant information without putting the onus on the user to verify and
|
|
validate every aspect. Both information providers and information consumers
|
|
are interested in getting the highest return for their individual investment
|
|
of time and effort.</p>
|
|
|
|
|
|
|
|
<h3><a name="Grouping" id="Grouping">Grouping</a></h3>
|
|
|
|
<p>This is one of the most powerful overarching features of POWDER and one
|
|
that has been an unresolved challenge until now. It allows one to offer
|
|
semantically rich information about entire groups of online resources with
|
|
both flexibility and precision in the way the group is defined. A processor
|
|
may use a single POWDER document to extract information about many - perhaps
|
|
huge numbers of - other resources. In addition, the maintenance of such
|
|
Description Resources is simplified by support for defining many descriptions
|
|
in a single document.</p>
|
|
|
|
<p>The methods for grouping resources range from the individual listing of
|
|
IRIs, through the specification of things like domain names and paths, to the
|
|
matching of IRIs against regular expressions. Requests made to a POWDER
|
|
Processor, however, are always handled at the level of an individual
|
|
resource. The RDF returned will be triples about that resource, allowing an
|
|
application to analyze the data and decide how to act case by case.</p>
|
|
|
|
<p>N.B. POWDER uses the term IRI (Internationalized Resource Identifier [<a
|
|
href="#iri">IRI</a>]). The more common term URI is a subset of IRIs, so that
|
|
all URIs are also IRIs.</p>
|
|
|
|
<h3><a name="Data" id="Data">Data retrieval efficiency</a></h3>
|
|
|
|
<p>Traditionally, meta information is always linked to a single resource and
|
|
is usually embedded within it, as is the case, for example, with the HTML
|
|
META element where the attributes are chosen and the values are given by the
|
|
author. When metadata is embedded in content in this way, the complete
|
|
resource has to be retrieved in full to then determine if it is of interest
|
|
or not.</p>
|
|
|
|
<p>POWDER describes online resources that may be of interest to a user or a
|
|
system. The keyword is "may", because the requester can decide prior to
|
|
resource retrieval whether the resource should be retrieved at all, based on
|
|
information provided by a Description Resource. This makes information
|
|
retrieval more efficient and precise by reducing network traffic and server
|
|
load. From a user perspective it means greater personalization and less
|
|
irrelevant content.</p>
|
|
|
|
<h3><a name="Profile" id="Profile">Profile matching</a></h3>
|
|
|
|
<p>POWDER allows profile matching - that is, the retrieval of resources
|
|
according to user preferences, device capabilities and current state at the
|
|
time of content delivery. The use cases [<a href="#usecases">USECASES</a>]
|
|
deal with adaptive search results based on context, suitability for mobile
|
|
devices, functional user experiences based on capabilities, web
|
|
accessibility, child protection and privileged content.</p>
|
|
|
|
<h3><a name="Trustmarks" id="Trustmarks">Trustmarks</a></h3>
|
|
|
|
<p>Resources and the DRs that describe them may be connected to each other in
|
|
a web of trust. Partners in this web may be certification authorities that
|
|
verify the truthfulness of claims made in Description Resources. Other
|
|
partners may be repositories of thematically linked URIs, such as white lists
|
|
for web sites that are recommended for children.</p>
|
|
|
|
<p>There are several possible models in which assertions and claims can be
|
|
made, authenticated and reported to the end user. The Use Cases and
|
|
Requirements document lists several use cases which have a number of elements
|
|
in common but differ in details such as whether it is the content provider or
|
|
the trustmark operator that makes the original claim, whether the data is
|
|
stored on the trustmark operator's servers or alongside the content itself,
|
|
and whether the trustmark operator provides the description or the
|
|
authentication for a description.</p>
|
|
|
|
<h3><a name="Semantic" id="Semantic">Semantic Annotation</a></h3>
|
|
|
|
<p>POWDER makes it easy for annotations to be created and published
|
|
independently of the relevant content. Such annotations may cover large
|
|
amounts of content as it is created with only occasional changes needed to
|
|
the annotations. This matches typical content production workflows where
|
|
different individuals are often responsible for the two tasks. In situations
|
|
where annotation can only be done by the content author, all too often
|
|
content is published without any meaningful metadata.</p>
|
|
|
|
<p>Cost-effective, trusted annotations have a significant potential benefit
|
|
to content aggregators, search engines and related services.</p>
|
|
|
|
<p>Semantic Searches could return results filtered for location-based
|
|
cultural parameters. Information provided on the Web can affect users in
|
|
different ways depending on the context in which it is retrieved. For
|
|
example, nudity on a medical website dealing with breast cancer may be fully
|
|
appropriate if it is known prior to retrieval what the context of the content
|
|
is. Content promoting discrimination may be appropriate for analysis purposes
|
|
but may be served with additional contextual information in other
|
|
circumstances. Semantic annotation also allows the disambiguation of terms
|
|
such as 'football.'</p>
|
|
|
|
<p>Furthermore a POWDER document can be used as a set of instructions that
|
|
allow a crawler to follow up on all links, pointing to DR in POWDER
|
|
documents, to automatically create a triple store about those resources. This
|
|
could be used in conjunction with XML-based site maps to create triples by
|
|
processing those site maps.</p>
|
|
|
|
<p>In summary, POWDER empowers users to find more of what they ask for and
|
|
less of what they don't.</p>
|
|
|
|
<h2><a name="does" id="does">3. How does POWDER work in the real
|
|
world?</a></h2>
|
|
|
|
<p>The previous section describes the benefits of POWDER and the reasons why
|
|
it is a compelling method for defining relatively small amounts of data that
|
|
can be applied to large amounts of content.</p>
|
|
|
|
<p>The following are brief examples of how POWDER applications work.</p>
|
|
|
|
<h3><a name="Trustmarks2" id="Trustmarks2">Trustmarks</a></h3>
|
|
|
|
<p>POWDER offers various possible methods by which trust claims and
|
|
assertions can be made and used.</p>
|
|
|
|
<h4><a name="VISUAL" id="VISUAL">Visual notification</a></h4>
|
|
|
|
<p>A user could install a browser plug-in designed to provide an indication
|
|
(such as a visual logo or audible alarm) that a Web site is trustworthy or
|
|
not. The plug-in would rely on various sources such as reputation and
|
|
accreditation services to determine trustworthiness.</p>
|
|
|
|
<h4><a name="MONITORING" id="MONITORING">Monitoring</a></h4>
|
|
|
|
<p>This can be particularly valuable in cases where certain sites are
|
|
required by law or other regulations to provide a certain level of content or
|
|
access. Once those sites have been approved and tagged as having met specific
|
|
standards, an automated process can aid the discovery and regular review of
|
|
the site's content and its DR for continued authenticity and validity. This
|
|
could go as far as generating a report for the evaluating party.</p>
|
|
|
|
<h4><a name="Descriptio" id="Descriptio">Description authentication</a></h4>
|
|
|
|
<p>A Web site operator submits their work to a trusted organization that can
|
|
authenticate the work and provide a Description Resource that identifies the
|
|
site as accurate or trustworthy.</p>
|
|
|
|
<h3><a name="Accessibil" id="Accessibil">Accessibility</a></h3>
|
|
|
|
<p>POWDER enables search engines and portals, if they so choose, to provide
|
|
customized links for users who prioritize compliance with particular
|
|
accessibility checks. For example, an organization might review Web sites to
|
|
determine their level of compliance with accessibility guidelines [<a
|
|
href="#wcag">WCAG</a>]. The reviewed Web sites can be duly tagged as
|
|
compliant using a DR supported by a test result expressed in [<a
|
|
href="#earl">EARL</a>]. The search engine/portal can then present or perhaps
|
|
highlight the best sites based on a user's preference settings and the tags
|
|
on the reviewed Web sites. The system can be highly granular so that the
|
|
links presented to a user with limited manual dexterity (to resources that
|
|
support keyboard navigation) would differ from those presented to a user with
|
|
a visual impairment.</p>
|
|
|
|
<h3><a name="MobileOK" id="MobileOK">MobileOK</a></h3>
|
|
|
|
<p>In a similar fashion to the accessibility case, POWDER may be used to
|
|
identify resources that conform to W3C mobileOK [<a href="#mok">MOK</a>]. A
|
|
user wanting to browse the Web using his mobile phone may request that the
|
|
search provider favor links suitable for display on his device. When the
|
|
search engine retrieves a set of links from its index, it determines which
|
|
have an associated mobileOK descriptor, and presents those before the
|
|
remainder. </p>
|
|
|
|
<p>[Example: <a href="#example_mobileOK">mobileOK</a>]</p>
|
|
|
|
<h3><a name="Child" id="Child">Child Protection</a></h3>
|
|
|
|
<p>Online child protection, as well as the continuation of offline child
|
|
protection, is a priority for any responsible site or service provider,
|
|
whether directed at children or not.</p>
|
|
|
|
<p>A service provider may include a feature that offers parents the ability
|
|
to determine the type or level of content they would allow their child to
|
|
view. In today's market, most, if not all, service providers do offer some
|
|
degree of parental controls. A hypothetical Web site that sells an array of
|
|
merchandise can use POWDER to accurately describe their content as either
|
|
being child appropriate or intended just for adults. While most of their
|
|
content and products are appropriate for all ages, there are also numerous
|
|
pages showing "adult" toys. When a child whose setting allows him only to
|
|
view content that is age appropriate accesses this online retailer through
|
|
the family network he will only be able to view the content that is deemed
|
|
age appropriate and not that in the adult category.</p>
|
|
|
|
<p>[Example: <a href="#ICRA1">ICRA Labelling</a>]</p>
|
|
|
|
<h3><a name="Functional" id="Functional">Functional User Experience</a></h3>
|
|
|
|
<p>Web pages and whole Web sites containing any type of rich assets such as
|
|
video/streaming video or audio can be tagged with that information using
|
|
POWDER. A search engine, content aggregation or adaptation service can then
|
|
determine whether a user is accessing content via a low or high bandwidth
|
|
connection and return only those pages that contain assets and images that
|
|
will be supported by that user's connection speed.</p>
|
|
|
|
<h3><a name="Privileged" id="Privileged">Privileged Content</a></h3>
|
|
|
|
<p>A user pays an extra fee to his ISP in order to have privileged access to
|
|
third-party premium content. When he accesses a premium page on one of these
|
|
third-party Web sites via his ISP, the server is able to recognize him as a
|
|
paying customer and deliver the content that has been described as premium by
|
|
an associated Description Resource.</p>
|
|
|
|
<p>Additionally in that fashion a user may be informed that he will not be
|
|
able to access said content because he is not a paying customer.</p>
|
|
|
|
<h3><a name="Semantics" id="Semantics">Semantics</a></h3>
|
|
|
|
<p>Sites can use Description Resources to communicate the subject matter of
|
|
their content more accurately and with greater relevance to user requests.</p>
|
|
|
|
<h4><a name="Search" id="Search">Search</a></h4>
|
|
|
|
<p>Because the same term can suggest two distinctly different meanings, the
|
|
judicious use of Description Resources can go a long way in making a site
|
|
more valuable to a greater number of people. An owner of a global sports site
|
|
can provide descriptors that are accurate enough so that users searching on
|
|
the term "football" can receive the portions of the available content
|
|
relating to the specific game that the user's location suggests is what they
|
|
are searching for information about.</p>
|
|
|
|
<h4><a name="Distinguis" id="Distinguis">Distinguishing opinion</a></h4>
|
|
|
|
<p>By developing an appropriate and detailed vocabulary, Description
|
|
Resources can be used to identify the value of a site as being either of
|
|
value in its own right or as an excellent example of something that is
|
|
intrinsically bad (in the opinion of the DR author).</p>
|
|
|
|
<h2><a name="POWDER" id="POWDER">4. How do I use POWDER?</a></h2>
|
|
|
|
<p>Usage of POWDER is dependent on the intended results.</p>
|
|
<ul>
|
|
<li>If the goal is to simply provide meta data in a new and efficient
|
|
fashion, it is enough to create Description Resources in XML which can be
|
|
read and used by the appropriate tools</li>
|
|
<li>If the goal is to use such meta data semantically, it is necessary to
|
|
convert the XML document into RDF data.</li>
|
|
</ul>
|
|
|
|
<p>The process is a sequence and can be stepped through all the way or
|
|
terminated at the appropriate place to obtain the desired result. </p>
|
|
|
|
<p>For someone who wishes to describe content:</p>
|
|
<ol>
|
|
<li>Create one or more Description Resources within a POWDER document and
|
|
make it available on the Web. <br />
|
|
This requires no more than the generation of an XML document that
|
|
contains the necessary components of a Description Resource.<br />
|
|
No further steps are necessary, other than publishing, to create a
|
|
Description Resource and thus offer this meta data publicly. <br />
|
|
<br />
|
|
</li>
|
|
<li>Make the POWDER document discoverable<br />
|
|
This is no more than making sure that DRs can be accessed by the intended
|
|
audience, most likely the Web.<br />
|
|
You should link from the described resources to the POWDER document. <br
|
|
/>
|
|
It is also possible to describe someone else's content.<br />
|
|
<br />
|
|
</li>
|
|
<li>Add trust to your descriptions<br />
|
|
Trust is an integral component of POWDER documents. Choose a method,
|
|
ranging from simply publishing your document, thereby making a claim, to
|
|
providing fully certified POWDER documents with supporting resources to
|
|
add trust to your DRs. </li>
|
|
</ol>
|
|
|
|
<p>For someone who wants to access RDF triples obtained from POWDER
|
|
documents:</p>
|
|
<ol>
|
|
<li>A POWDER processor must be used to read and process POWDER documents to
|
|
obtain RDF triples that describe specific Web resources. Refer to the [<a
|
|
href="#dr">DR</a>] document for POWDER processor details. </li>
|
|
<li>Now an RDF querying tool could be used to retrieve:
|
|
<ul>
|
|
<li>descriptions of a resource </li>
|
|
<li>the set of resources that have a given property, e.g. all web pages
|
|
that are mobileOK</li>
|
|
</ul>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>As an alternative, someone may want to draw inferences based on the data
|
|
contained in POWDER documents.<br />
|
|
Drawing an inference means deriving implicit information from known facts.
|
|
<br />
|
|
For example:</p>
|
|
<ul>
|
|
<li>I know that everything on example.com conforms to accessibility level
|
|
AA</li>
|
|
<li>A resource of interest is located on example.com</li>
|
|
</ul>
|
|
|
|
<p>Therefore that particular resource conforms to accessibility level AA.</p>
|
|
|
|
<p>In order to do so, the following steps should be followed.</p>
|
|
<ol>
|
|
<li>Convert the POWDER document into a POWDER-S document (intended for
|
|
semantic web usage, via the GRDDL transform defined in the Formal
|
|
Semantics document [<a href="#formal">FORMAL</a>]<br />
|
|
</li>
|
|
<li>Now an inference engine must be used to retrieve the property of a
|
|
given resource. <br />
|
|
For this step it is important to realize that an extension to RDF/OWL has
|
|
to be implemented in the reasoning engine in order to support and utilize
|
|
POWDER-S</li>
|
|
</ol>
|
|
|
|
<p>Following the example above we could now determine which resources on
|
|
example.com are AA conformant, as well as the conformance level of a given
|
|
resource.</p>
|
|
|
|
<h3><a name="create" id="create">How do I create a Description
|
|
Resource?</a></h3>
|
|
|
|
<p>The first step is to create a skeleton POWDER document in XML and declare
|
|
the namespaces:</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder
|
|
xmlns="http://www.w3.org/2007/05/powder#"
|
|
xmlns:ex="http://example.org/vocab#">
|
|
</powder></pre>
|
|
|
|
<p>Any descriptive vocabularies may be used which are identified by a
|
|
namespace. The POWDER namespace is required.</p>
|
|
|
|
<p>The "ex" namespace used above is a fictitious example to denote that any
|
|
namespace may be used.</p>
|
|
|
|
<p>Next we need to say who has created the document. All POWDER documents
|
|
have exactly one <code>attribution</code> element, and within that an
|
|
<code>issuedby</code> element. This points to details of the person or
|
|
organization that has published the POWDER document. Exactly which details is
|
|
for the publisher to decide, but a name and a homepage address should usually
|
|
be included, perhaps along with contact details. POWDER authors may use
|
|
either the Friend of a Friend [<a href="#foaf">FOAF</a>] vocabulary or the
|
|
Dublin Core [<a href="#dc">DC</a>] to do this.</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder
|
|
xmlns="http://www.w3.org/2007/05/powder#"
|
|
xmlns:ex="http://example.org/vocab#"
|
|
<b><attribution>
|
|
<issuedby src="http://authority.example.org/company.rdf#me" />
|
|
</attribution></b>
|
|
</powder></pre>
|
|
|
|
<p>An individual or organization may publish many Description Resources.
|
|
Therefore it is more convenient to define the profile information, describing
|
|
that individual or organization, in a single file and refer to it from each
|
|
POWDER document as it is created. The above example points to a profile as
|
|
listed below. Notice the rdf:ID="me", which is referred to by the #me in the
|
|
above example.</p>
|
|
|
|
<p>The publisher's profile would look similar to this:</p>
|
|
<pre><?xml version="1.0"?>
|
|
<rdf:RDF
|
|
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
xmlns:foaf="http://xmlns.com/foaf/0.1/">
|
|
<foaf:Organization rdf:ID="me">
|
|
<foaf:name>The POWDER Company</foaf:name>
|
|
<foaf:homepage rdf:resource="http://authority.example.org" />
|
|
</foaf:Organization>
|
|
</rdf:RDF></pre>
|
|
|
|
<p>A POWDER document will typically also include information about when it
|
|
was created (our example was created on 14 December 2007).</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder
|
|
xmlns="http://www.w3.org/2007/05/powder#">
|
|
<attribution>
|
|
<issuedby src="http://authority.example.org/company.rdf#me" />
|
|
<strong><issued>2007-12-14T00:00:00</issued></strong>
|
|
</attribution>
|
|
</powder></pre>
|
|
|
|
<p>Next an actual Description Resource (DR) is added. This example POWDER
|
|
document will contain a single Description Resource, as the <code>dr</code>
|
|
element.</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder
|
|
xmlns="http://www.w3.org/2007/05/powder#">
|
|
<attribution>
|
|
<issuedby src="http://authority.example.org/company.rdf#me" />
|
|
<issued>2007-12-14T00:00:00</issued>
|
|
</attribution>
|
|
<strong><dr>
|
|
</dr></strong>
|
|
</powder></pre>
|
|
|
|
<p>The Description Resource itself must contain at least one set of IRIs.
|
|
This is the scope of the Description Resource - i.e. what it describes. IRIs
|
|
are a superset of the well known Uniform Resource Identifier (URI) with the
|
|
expansion of also allowing international characters. If multiple IRI sets are
|
|
included within a DR, then the scope is all the IRIs in all the IRI sets.</p>
|
|
|
|
<p>In this case, the scope is 'everything on example.com'. This is done using
|
|
the <code>includehosts</code> element. There are other elements available
|
|
which are described in detail in the Grouping of Resources document [<a
|
|
href="#group">GROUP</a>]. All Description Resources must contain at least one
|
|
iriset element, and this cannot be empty and cannot contain any elements from
|
|
any other namespace.</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder
|
|
xmlns="http://www.w3.org/2007/05/powder#">
|
|
<attribution>
|
|
<issuedby src="http://authority.example.org/company.rdf#me" />
|
|
<issued>2007-12-14T00:00:00</issued>
|
|
</attribution>
|
|
<dr>
|
|
<strong><iriset>
|
|
<includehosts>example.com</includehosts>
|
|
</iriset></strong>
|
|
</dr>
|
|
</powder></pre>
|
|
|
|
<p>The final key element of a Description Resource is the actual description.
|
|
There are two ways of providing this.</p>
|
|
<ul>
|
|
<li>As RDF (in a "descriptor set")</li>
|
|
<li>As one or more tags (in a "tag set")</li>
|
|
</ul>
|
|
|
|
<p>A DR must contain at least one of either a descriptor set or tag set, none
|
|
of which may be empty. Subject to that condition, any number of tag sets and
|
|
descriptor sets may be included. The example DR states that in the opinion of
|
|
the entity referenced by the <code>issuedby</code> element, all resources
|
|
within its scope are described by all descriptive elements. </p>
|
|
|
|
<p>We'll add one of these to our example: a descriptor set. It may contain
|
|
RDF/XML properties with literal values (including XML literals) or resources
|
|
identified by an IRI. In addition, a textual and/or graphic summary that can
|
|
be displayed to end users may be included in a descriptor set using the
|
|
<code>displaytext</code> and <code>displayicon</code> elements as shown in
|
|
the completed example below. Notice that the namespace used in the descriptor
|
|
set is also highlighted.</p>
|
|
|
|
<div class="example">
|
|
<p class="caption">Generic Example of a POWDER Document Containing a Single
|
|
Description Resource. </p>
|
|
|
|
<p>This is a repeat of Example 2-1 in the Description Resources document [<a
|
|
href="#dr">DR</a>]</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder xmlns="http://www.w3.org/2007/05/powder#"
|
|
<b>xmlns:ex="http://example.org/vocab#</b>">
|
|
|
|
<attribution>
|
|
<issuedby src="http://authority.example.org/company.rdf#me" />
|
|
<issued>2007-12-14T00:00:00</issued>
|
|
</attribution>
|
|
|
|
<dr>
|
|
|
|
<iriset>
|
|
<includehosts>example.com</includehosts>
|
|
</iriset>
|
|
|
|
<b><descriptorset>
|
|
<ex:color>red</ex:color>
|
|
<ex:shape>square</ex:shape>
|
|
<displaytext>Everything on example.com is red and square</displaytext>
|
|
<displayicon src="http://authority.example.org/icon.png" />
|
|
</descriptorset></b>
|
|
|
|
</dr>
|
|
|
|
</powder></pre>
|
|
</div>
|
|
|
|
|
|
|
|
<p>Of course, much more complicated structures are possible than this simple
|
|
example.</p>
|
|
|
|
<p>The following example uses an ordered list of DRs. In such a list 0 or 1,
|
|
DRs will apply to a given resource. A processor will work through the list
|
|
until the first match is found. This feature is designed to make it easy to
|
|
add POWDER descriptions to existing content within established workflows.
|
|
Effectively it enables a list of exception to be created, ending with the
|
|
general case.</p>
|
|
|
|
<p>NOTE: The example below contains an <code>abouthosts</code> element which
|
|
may be used by a processor to decide if a list, perhaps a long list, need be
|
|
processed at all. Here we know that only resources on example.com are
|
|
described in the ordered list, however it is important to recognize that this
|
|
does not guarantee that all resources on example.com are described.</p>
|
|
|
|
<div class="example">
|
|
<p class="caption">Example of a POWDER document which contains an ordered
|
|
list</p>
|
|
|
|
<p>This is a repeat of from Example 2-6 in the Description Resources document
|
|
[<a href="#dr">DR</a>]</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder xmlns="http://www.w3.org/2007/05/powder#"
|
|
xmlns:ex="http://example.org/vocab#">
|
|
|
|
<attribution>
|
|
<issuedby src="http://authority.example.org/company.rdf#me" />
|
|
<issued>2007-12-14T00:00:00</issued>
|
|
<abouthosts>example.com</abouthosts>
|
|
</attribution>
|
|
|
|
<ol>
|
|
|
|
<dr>
|
|
<iriset>
|
|
<includehosts>example.com</includehosts>
|
|
<includepathstartswith>/foo</includepathstartswith>
|
|
</iriset>
|
|
<descriptorset>
|
|
<ex:color>blue</ex:color>
|
|
</descriptorset>
|
|
</dr>
|
|
|
|
<dr>
|
|
<iriset>
|
|
<includehosts>example.com</includehosts>
|
|
</iriset>
|
|
<descriptorset>
|
|
<ex:color>red</ex:color>
|
|
</descriptorset>
|
|
</dr>
|
|
|
|
</ol>
|
|
|
|
</powder></pre>
|
|
</div>
|
|
|
|
<p>The example above encodes the following assertion made by the entity
|
|
described at http://authority.example.org/company.rdf#me: all web resources
|
|
with paths on example.com that start with /foo are blue, all other resources
|
|
on example.com are red. </p>
|
|
|
|
<p>POWDER offers other methods of defining the scope of DRs that are designed
|
|
to increase flexibility. For example, it is possible for the scope of a DR to
|
|
be the union of two or more IRI sets, meaning that an IRI that is a member of
|
|
any IRI set is described. The following example describes resources that are
|
|
available from example.com where the path starts with /foo AND those at
|
|
example.org where the path starts with /bar.</p>
|
|
|
|
<div class="example">
|
|
<p class="caption">Example of a POWDER document with two IRI sets</p>
|
|
|
|
<p>This is a repeat of Example 2-8 in the Description Resources document [<a
|
|
href="#dr">DR</a>]</p>
|
|
<pre><?xml version="1.0"?>
|
|
<powder xmlns="http://www.w3.org/2007/05/powder#"
|
|
xmlns:ex="http://example.org/vocab#">
|
|
<attribution>
|
|
<issuedby src="http://authority.example.org/company.rdf#me" />
|
|
<issued>2007-12-14T00:00:00</issued>
|
|
</attribution>
|
|
|
|
<dr>
|
|
<iriset>
|
|
<includehosts>example.com</includehosts>
|
|
<includepathstartswith>/foo</includepathstartswith>
|
|
</iriset>
|
|
|
|
<iriset>
|
|
<includehosts>example.org</includehosts>
|
|
<includepathstartswith>/bar</includepathstartswith>
|
|
</iriset>
|
|
|
|
<descriptorset>
|
|
<ex:color>red</ex:color>
|
|
<ex:shape>square</ex:shape>
|
|
<displaytext>Everything on example.com/foo, and everything on example.org/bar, is red and square</displaytext>
|
|
<displayicon src="http://example.org/icon.png" />
|
|
</descriptorset>
|
|
</dr>
|
|
</powder></pre>
|
|
</div>
|
|
|
|
<h3><a name="publish" id="publish">How do I publish a DR?</a></h3>
|
|
|
|
<p>Like any other resource on the Web, POWDER documents can only be found if
|
|
you know where to look or you can follow a link from where you already are.
|
|
Individuals or organizations whose activities include reviewing and
|
|
describing online content will be able to set up and advertise the existence
|
|
of a repository of Description Resources.</p>
|
|
|
|
<p>There are several methods of linking from a resource to a POWDER document
|
|
that describes it. <br />
|
|
First of all, HTML documents can include a link element in much the same way
|
|
as is common for linking to CSS style sheets, RSS/ATOM feeds, etc.</p>
|
|
<pre><link rel="describedby" href="powder.xml" type="application/powder+xml"/></pre>
|
|
|
|
<p>The relationship type (rel) of "describedby" tells user agents that the
|
|
file contains a description of the resource and the mime type tells it that
|
|
it is a POWDER document. The value of the href is the IRI of the POWDER
|
|
document. </p>
|
|
|
|
<p>Just as with stylesheets, it's important to include this link on all
|
|
described pages, so it is best included in the document template.</p>
|
|
|
|
<p>When using HTML link elements in this way, authors should also refer to
|
|
POWDER's <a href="http://www.w3.org/2007/11/powder-profile">profile
|
|
document</a> as shown below, if using an HTML version that supports it.</p>
|
|
<pre><html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head profile="http://www.w3.org/2007/11/powder-profile">
|
|
<meta name="wdr.issuedby" content="http://authority.example.org/company.rdf#me"/>
|
|
<link rel="describedby" href="powder.xml" type="application/powder+xml"/>
|
|
<title>Welcome to example.com </title>
|
|
</head>
|
|
<body>
|
|
<p>Today's content is ....</p>
|
|
</body>
|
|
</html></pre>
|
|
|
|
|
|
|
|
<p>Adding this makes the relationship type "describedby" clear and allows
|
|
content authors to include data about the POWDER document within the
|
|
described resource. As shown in the example above, this can include
|
|
information about who has issued the DRs (issuedby), so that a user agent
|
|
that recognizes and trusts that Description Resource author will be more
|
|
confident that the data available is trustworthy and therefore that the link
|
|
is worth following.<ins></ins></p>
|
|
|
|
<p>Whilst HTML link elements do make POWDER documents discoverable, the
|
|
preferred method is to configure the server to include an HTTP Response
|
|
Header that does the same job.</p>
|
|
<pre>Link: <powder.xml>; rel="describedby"; type="application/powder+xml";</pre>
|
|
|
|
<p>This has several distinct advantages:</p>
|
|
<ol>
|
|
<li>It allows all resources, not just HTML documents, to point to a POWDER
|
|
document.</li>
|
|
<li>It allows the POWDER document to be discovered and parsed
|
|
<em>before</em> the described content is parsed.</li>
|
|
<li>In some content production environments the process of configuring
|
|
servers can be easier to achieve and lead to longer-term stability than
|
|
changing templates.</li>
|
|
</ol>
|
|
|
|
<p>Where POWDER documents are discoverable via HTTP Link: headers, a user
|
|
agent or Web crawler can discover them by doing an HTTP HEAD request which
|
|
may affect how, or indeed whether, a subsequent GET request is made. </p>
|
|
|
|
<p>The describedby relationship type is made available as an RDF property,
|
|
where a more formal relationship between a POWDER document and a resource
|
|
that it describes is required. This may be used, for example, in XHTML
|
|
documents annotated with RDFa as described in section 4.1.3 of the
|
|
Description Resources document [<a href="#dr">DR</a>]. One important benefit
|
|
of using RDFa to link to POWDER documents is that it allows you to point to a
|
|
description of the destination of a hyperlink.</p>
|
|
|
|
<p>As an example of this, imagine an XHTML document about a rock band that
|
|
includes hyperlinks to ring tones, images and videos.</p>
|
|
|
|
<div class="example" id="rdfa-eg">
|
|
<p class="caption">An XHTML/RDFa Fragment with Hyperlinks described using
|
|
POWDER</p>
|
|
<pre><ul>
|
|
<li><a href="/clips/low_res_clip.mpg"
|
|
rev="wdrs:describedby"
|
|
about="/powder.xml">30" clip</a></li>
|
|
|
|
<li><a href="/videos/full_video.mpg"
|
|
rev="wdrs:describedby"
|
|
about="/powder.xml">Full 10 minute video</a></li>
|
|
|
|
<li><a href="/tones/ring_tone1.mp3"
|
|
rev="wdrs:describedby"
|
|
about="/powder.xml">Ring Tone</a></li>
|
|
|
|
…
|
|
|
|
</ul></pre>
|
|
|
|
<p class="caption">powder.xml</p>
|
|
<pre><ol>
|
|
<dr>
|
|
<iriset>
|
|
<includehosts>example.com</includehosts>
|
|
<includepathcontains>/videos/</includepathcontains>
|
|
</iriset>
|
|
<tagset>
|
|
<tag>Large download</tag>
|
|
<label>Only suitable for download via high-bandwidth connections</label>
|
|
</tagset>
|
|
</dr>
|
|
|
|
<dr>
|
|
<iriset>
|
|
<includehosts>example.com</includehosts>
|
|
</iriset>
|
|
<descriptorset>
|
|
<typeof src="http://www.w3.org/2008/06/mobileOK#conformant" />
|
|
</descriptorset>
|
|
</dr>
|
|
</ol></pre>
|
|
</div>
|
|
|
|
<p>This ordered list of DRs states that resources on the example.com host
|
|
where the IRI path includes /videos/ are large downloads. All other resources
|
|
on example.com are conformant with mobileOK [<a href="#mok">MOK</a>]. By
|
|
taking note of the available descriptions, the user agent may display the
|
|
links differently on different devices (or chose not to display them at
|
|
all).</p>
|
|
|
|
<p>Notice a couple of points here:</p>
|
|
<ol>
|
|
<li>Use of the "rev" attribute which reverses the relationship so that
|
|
"powder.xml" is "about" the hyperlink.</li>
|
|
<li>The same POWDER document contains both the DRs and can therefore be
|
|
used from cache.</li>
|
|
</ol>
|
|
|
|
<h3><a name="ensuretrust" id="ensuretrust">How do I make my DR more
|
|
trustworthy?</a></h3>
|
|
|
|
<p>Trust is a critical aspect of Description Resources; however, trust is
|
|
very much a matter of opinion. The level of trust demanded of a given DR will
|
|
depend on what the description says and to what use it will be put. For
|
|
example, an individual user finding a DR that declares a Web site to offer
|
|
children's birthday party ideas can make his/her own assessment of its
|
|
quality and usefulness. In contrast, a multi-million dollar business will
|
|
need very strong assurance that a DR declaring a Web site to be medically
|
|
accurate and freely available is trustworthy before including it in a portal
|
|
of high quality, license-free health care materials. For this reason, we do
|
|
not define a single trust mechanism that must be used. Rather, there are a
|
|
variety of different methods of adding trust to DRs, some of which may be
|
|
used in combination.</p>
|
|
<ul>
|
|
<li>Publish the DR in a trusted location, for example under the main domain
|
|
for a well-known content provider.</li>
|
|
<li>Provide links to the author of a DR. Use the <code>authenticate</code>
|
|
property to point from the author's profile to information about how a
|
|
user (or user agent) can verify a DR. This is not limited to persons, but
|
|
can be used for organizations and other entities.</li>
|
|
<li>Provide validity and issue date information. This will let users know
|
|
how up to date the claim is.</li>
|
|
<li>Have claims certified by independent and trusted third parties.</li>
|
|
<li>Point to such certifications by using the <code>certifiedby</code>
|
|
property.</li>
|
|
<li>Link to supporting information using the <code>supportedby</code>
|
|
property. This points to further DRs or other Web resources that contain
|
|
information supporting the claim made.</li>
|
|
</ul>
|
|
|
|
<p>Where applicable, we define vocabulary terms designed to aid the building
|
|
of trust.</p>
|
|
|
|
<p>The methods cited here do not comprise an exhaustive list. Other
|
|
techniques, such as XML Signature [<a href="#xmlsig">XMLSIG</a>] and Web of
|
|
Trust [<a href="#wot">WOT</a>], may be equally applicable. Trust is a human
|
|
judgment that can only be made by weighing the likelihood that the data is
|
|
true against the consequences of it being false. This judgment is highly
|
|
dependent on the circumstances under which the need to extend trust arises.
|
|
It is clear, however, that Description Resources are unlikely to be trusted
|
|
in isolation and that both their publishers and consumers will only benefit
|
|
from their existence if one or more techniques for enhancing trust are
|
|
employed.</p>
|
|
|
|
<p>These methods would also serve to increase trust placed in the meta
|
|
information provided for Web documents in general. Today's meta data, such as
|
|
the keywords provided in META elements, can have little value as this
|
|
mechanism has been abused to such a degree that renders it practically
|
|
useless from an informational point of view. Search engines do not place much
|
|
stock on keywords to give any indication about the relevance of a given Web
|
|
page to a given topic and use different means, such as incoming links, as a
|
|
basis for page ranking. False claims made in meta information, intended to
|
|
lure the user into clicking on a link to a resource, also serve to lower the
|
|
value of meta information.</p>
|
|
|
|
<p>Also, a less deliberate yet still disturbing, fact about meta information
|
|
is aging. As meta information is not kept up to date, it loses its relevance
|
|
to the content it describes. POWDER elevates meta information once again into
|
|
the spotlight by allowing a third-party to certify the veracity of the meta
|
|
information given, declare the date of the verification, and define a date
|
|
after which the certificate will no longer be valid.</p>
|
|
|
|
<h3><a name="find" id="find">How do I find DRs for a document?</a></h3>
|
|
|
|
<p>DRs should describe reflect Web resources in their current state. This
|
|
requires that DRs are kept up-to-date and will thus change frequently.
|
|
Therefore it is important to provide a link to the "latest" version of DR
|
|
document, which has the added benefit of providing a DR history. If a request
|
|
is then made for this document, an HTTP 302 redirect can be used to point the
|
|
requesting client to the actual, current POWDER document.</p>
|
|
|
|
<p>A further option would be querying a known repository of DRs. Since the
|
|
creation of DRs is not limited to the author or provider of a Web resource,
|
|
repositories of DRs may be created by companies or special interest groups,
|
|
for example those specializing in standards compliance certification or child
|
|
protection. These may then be queried to obtain descriptions and scope
|
|
information. For example, a large content provider, upon planning to switch
|
|
from regular meta data to POWDER, could, in a first step, create one or
|
|
several DR documents. The scope would be set such as to cover all areas of
|
|
the content provider's content. Meta elements and various other information
|
|
may be copied into the DR documents. Insertion of the appropriate link in the
|
|
web resource, pointing to the correct DR, would be the last step prior to
|
|
publication of the DR documents.</p>
|
|
|
|
<p>Personal collections of DRs may be traded or passed between users of
|
|
social networks or other groupings of similar interests. Search engines'
|
|
indexes may also contain references to publically available DRs.</p>
|
|
|
|
<p>In short, DRs are normal documents that may be discovered in all the usual
|
|
ways that other documents are discovered on the Web.</p>
|
|
|
|
<h3><a name="process-docs" id="process-docs">How do I process POWDER
|
|
documents?</a></h3>
|
|
|
|
<p>A POWDER Processor accepts queries for descriptions of specific resources
|
|
which it generates by reading POWDER documents and returning RDF triples.
|
|
There is a minimal set of requirements for a conformant POWDER processor
|
|
given in the Description Resources document [<a href="#dr">DR</a>] where
|
|
implementers are encouraged to go further than the minimum. A POWDER
|
|
Processor may act as a gateway to a repository of DRs and use that as its
|
|
only source of data, or it may be more generalized, accepting both the IRI to
|
|
be described and one or more POWDER documents as the source from which to
|
|
generate the description. The application environment will determine which
|
|
factors are important but it is of course useful to think about usability,
|
|
error trapping and potential extensions of its functionality.</p>
|
|
|
|
<h3><a name="process1" id="process1">How do I process POWDER-S?</a></h3>
|
|
|
|
<p>The operational semantics, meaning the XML file, are underpinned by formal
|
|
semantics. A GRDDL transform is associated with the POWDER namespace that
|
|
allows the XML data to be rendered and processed as RDF/OWL.</p>
|
|
|
|
<p>However, RDF/OWL cannot currently interpret string values of RDF
|
|
properties as International Resource Identifiers (IRI). In other words the
|
|
string "http://example.org" is not necessarily recognized as the web address
|
|
(IRI) http://example.org.</p>
|
|
|
|
<p>To allow this to happen a semantic extension has to be created that makes
|
|
this definition and relates to the <code>matchesregex</code> property. The
|
|
extension is defined in <a href="#formal">POWDER: Formal Semantics</a></p>
|
|
|
|
<h2><a name="What1" id="What1">5. What do I need to use POWDER?</a></h2>
|
|
|
|
<h3 id="basic_reqs">Basic requirements</h3>
|
|
|
|
<p>No special knowledge is needed to understand plain POWDER. </p>
|
|
|
|
<p>The examples provided in the documents should be sufficient to begin using
|
|
POWDER with only rudimentary knowledge of markup languages.</p>
|
|
|
|
<p>You will need to be able to publish (upload) the POWDER web descriptions
|
|
to some location (server) where people can reach (download) them.</p>
|
|
|
|
<p>This may be the same location as the web resources themselves.</p>
|
|
|
|
<h3 id="create_dr">Creation of a DR</h3>
|
|
|
|
<p>The creation of a DR could be accomplished via online tools provided by
|
|
companies who offer repositories of DRs or created by hand with a desktop
|
|
editor in the simple form outlined in this document. In that case all that is
|
|
needed, if so desired, is to link from the web resource to the DR via a link
|
|
element or other mechanism as outlined here.</p>
|
|
|
|
<h2><a name="powder-s" id="powder-s">6. POWDER-S</a></h2>
|
|
|
|
<p>POWDER-S is not be dealt with in great detail in this document since it is
|
|
essentially an extension of RDF and OWL which are fully documented elsewhere.
|
|
The interested reader is encouraged to consult the [<a
|
|
href="#formal">FORMAL</a>] specification, which outlines POWDER-S
|
|
exhaustively.</p>
|
|
|
|
<p>The FORMAL specification provides the necessary underpinning for POWDER
|
|
and POWDER-S such that processing done on these types of documents can be
|
|
conformant and consistent with existing Semantic Web technologies.
|
|
Furthermore, the Grouping specification [<a href="#group">GROUP</a>] also
|
|
outlines the support for non-url environments, e.g. ISBN codes or similar
|
|
resources.</p>
|
|
|
|
<p>It should be noted, however, that the creation of POWDER-S documents
|
|
requires the implementation of an RDF extension in the reasoning engine.</p>
|
|
|
|
<p>See Section 4.3 POWDER-S IRI Set Semantics in the Formal document [<a
|
|
href="#formal">FORMAL</a>] for details.</p>
|
|
|
|
<div class="example">
|
|
<p class="caption">Generic example of a POWDER-S Document Containing a Single
|
|
Description Resource</p>
|
|
|
|
<p>This is a repeat of Example 2-3 from the Description resources document
|
|
[<a href="#dr">DR</a>]</p>
|
|
<pre>1 <?xml version="1.0"?>
|
|
2 <rdf:RDF
|
|
3 xmlns:wdrs="http://www.w3.org/2007/05/powder-s#"
|
|
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
5 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
|
|
6 xmlns:owl="http://www.w3.org/2002/07/owl#"
|
|
7 xmlns:ex="http://example.org/vocab#">
|
|
8
|
|
9 <owl:Ontology rdf:about="">
|
|
10 <wdrs:issuedby rdf:resource="http://authority.example.org/company.rdf#me" />
|
|
11 <wdrs:issued>2007-12-14T00:00:00</wdrs:issued>
|
|
12 </owl:Ontology>
|
|
13
|
|
14 <owl:Class rdf:nodeID="iriset_1">
|
|
15 <owl:equivalentClass>
|
|
16 <owl:Class>
|
|
17 <owl:intersectionOf rdf:parseType="Collection">
|
|
18 <owl:Restriction>
|
|
19 <owl:onProperty rdf:resource="http://www.w3.org/2007/05/powder-s#matchesregex" />
|
|
20 <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">\:\/\/(([^\/\?\#]*)\@)?([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/</owl:hasValue>
|
|
21 </owl:Restriction>
|
|
22 </owl:intersectionOf>
|
|
23 </owl:Class>
|
|
24 </owl:equivalentClass>
|
|
25 </owl:Class>
|
|
26
|
|
27 <owl:Class rdf:nodeID="descriptorset_1">
|
|
28 <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
|
|
29 <rdfs:subClassOf>
|
|
30 <owl:Class>
|
|
31 <owl:intersectionOf rdf:parseType="Collection">
|
|
32 <owl:Restriction>
|
|
33 <owl:onProperty rdf:resource="http://example.org/vocab#color" />
|
|
34 <owl:hasValue>red</owl:hasValue>
|
|
35 </owl:Restriction>
|
|
36 <owl:Restriction>
|
|
37 <owl:onProperty rdf:resource="http://example.org/vocab#shape" />
|
|
38 <owl:hasValue>square</owl:hasValue>
|
|
39 </owl:Restriction>
|
|
40 </owl:intersectionOf>
|
|
41 </owl:Class>
|
|
42 </rdfs:subClassOf>
|
|
43 <wdrs:text>Everything on example.com is red and square</wdrs:text>
|
|
44 <wdrs:logo rdf:resource="http://example.org/icon.png" />
|
|
45 </owl:Class>
|
|
46
|
|
47 <rdf:Description rdf:nodeID="iriset_1">
|
|
48 <rdfs:subClassOf rdf:nodeID="#descriptorset_1"/>
|
|
49 </rdf:Description>
|
|
50
|
|
51 </rdf:RDF></pre>
|
|
</div>
|
|
|
|
<p>Line-by-line explanation:</p>
|
|
<dl>
|
|
<dt>Lines 1-7</dt>
|
|
<dd>Document header: with namespace declarations</dd>
|
|
<dt>Lines 9-12</dt>
|
|
<dd>Attribution: Each POWDER-S document is an OWL ontology and the
|
|
attribution section is an ontology header.</dd>
|
|
<dt>Lines 14-25</dt>
|
|
<dd>Scope: An OWL class acts as the IRI set. It is this class that makes
|
|
use of the <code>matchesregex</code> property which is only understood
|
|
by software that implements the semantic extension which confers
|
|
membership of the class on resources whose IRIs match the given regular
|
|
expression(s). <span id="xq">The regular expression syntax used is defined by XML
|
|
schema as modified by XQuery 1.0 and XPath 2.0 Functions and
|
|
Operators [<a href="#xqxp">XQXP</a>].</span></dd>
|
|
<dt>Lines 27-45</dt>
|
|
<dd>Description: These are the actual descriptors.</dd>
|
|
<dt>Lines 47-49</dt>
|
|
<dd>Assertion: The encoding of the DR is completed by asserting that the
|
|
IRI set is a subclass of the descriptor set. This is the crucial step
|
|
that allows the inference to be drawn about members of the IRI set.</dd>
|
|
</dl>
|
|
|
|
<h2><a name="examples" id="examples">7. Examples</a></h2>
|
|
|
|
<h3><a name="ICRA1" id="ICRA1">ICRA Labelling</a></h3>
|
|
|
|
<p>The <a href="http://www.icra.org/vocabulary/" name="ICRA" id="ICRA">ICRA
|
|
vocabulary</a> facilitates what is intended to be a culturally neutral
|
|
description of online content in terms that may reflect parental concerns
|
|
around the world. Such descriptions, especially where backed up by
|
|
third-party checks, can be useful in delivering appropriate content to
|
|
different target groups, particularly children.</p>
|
|
|
|
<p>In the following scenario, we imagine that example.com publishes content
|
|
across its portal that does not include any sex, nudity, violence or other
|
|
potentially offensive or harmful material, <strong>except</strong> in its
|
|
night life section, where references to alcohol, tobacco and potentially
|
|
offensive language are to be found, especially as it invites users to post
|
|
reviews of bars, pubs and clubs they have visited. Since all pages relevant
|
|
to the night life section have a URL of the form
|
|
http://www.example.com/nightlife... it is able to describe its own content in
|
|
the following POWDER document.</p>
|
|
|
|
<div class="example">
|
|
<p class="caption">Example: ICRA labelling <a
|
|
href="icra_example.xml">[XML]</a></p>
|
|
<pre>1 <?xml version="1.0"?>
|
|
2 <powder xmlns="http://www.w3.org/2007/05/powder#"
|
|
3 xmlns:foaf="http://xmlns.com/foaf/0.1/"
|
|
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
5 xmlns:icra="http://www.icra.org/rdfs/vocabulary2008#">
|
|
6
|
|
7 <attribution>
|
|
8 <issuedby src="http://www.example.com/company.rdf#me" />
|
|
<issued>2008-06-02T00:00:00</issued>
|
|
15 <certifiedby src="http://independent.example.org?verify=http%3A%2F%2Fwww.example.com%2Fpowder.xml" />
|
|
16 </attribution>
|
|
17
|
|
18 <ol>
|
|
19 <dr>
|
|
20 <iriset>
|
|
21 <includehosts>example.com</includehosts>
|
|
22 <includepathstartswith>/nightlife</includepathstartswith>
|
|
23 </iriset>
|
|
24
|
|
25 <descriptorset>
|
|
26 <icra:nz>1</icra:nz>
|
|
27 <icra:sz>1</icra:sz>
|
|
28 <icra:vz>1</icra:vz>
|
|
29 <icra:lb>1</icra:lb>
|
|
30 <icra:lc>1</icra:lc>
|
|
31 <icra:ha>1</icra:ha>
|
|
32 <icra:hb>1</icra:hb>
|
|
33 <icra:dz>1</icra:dz>
|
|
34 <icra:ua>1</icra:ua>
|
|
35 <icra:pa>1</icra:pa>
|
|
36 <displaytext>
|
|
No nudity; No sexual material; No violence;
|
|
Profanity or swearing; Mild expletives;
|
|
Depiction of tobacco or its use; Depiction of alcohol or its use;
|
|
No potentially disturbing material;
|
|
User-generated content such as chat rooms and message boards (moderated);
|
|
Contains advertising
|
|
</displaytext>
|
|
37 </descriptorset>
|
|
38 </dr>
|
|
39
|
|
40 <dr>
|
|
41 <iriset>
|
|
42 <includehosts>example.com</includehosts>
|
|
43 <span id="typo"><excludepathstartswith>/nightlife</excludepathstartswith></span>
|
|
44 </iriset>
|
|
45
|
|
46 <descriptorset>
|
|
47 <icra:nz>1</icra:nz>
|
|
48 <icra:sz>1</icra:sz>
|
|
49 <icra:vz>1</icra:vz>
|
|
50 <icra:lz>1</icra:lz>
|
|
51 <icra:hz>1</icra:hz>
|
|
52 <icra:dz>1</icra:dz>
|
|
53 <icra:uz>1</icra:uz>
|
|
54 <icra:pa>1</icra:pa>
|
|
55 <displaytext>
|
|
No nudity; No sexual material; No violence;
|
|
No potentially offensive language;
|
|
No potentially harmful activities;
|
|
No potentially disturbing material;
|
|
No user-generated content; Contains advertising
|
|
</displaytext>
|
|
56 </descriptorset>
|
|
57 </dr>
|
|
58 </ol>
|
|
59
|
|
60 </powder></pre>
|
|
</div>
|
|
|
|
|
|
|
|
<p>The document contains two Description Resources that reflect the two
|
|
different types of content on (the fictional) example.com. This document
|
|
makes use of POWDER's ordered list feature such that <strong>every</strong>
|
|
page on example.com, irrespective of its content, can be linked to the same
|
|
file. This can be done by including a link element in each page's HTML
|
|
thus:</p>
|
|
|
|
<p><code><link rel="describedby" href="/powder.xml" type="application/powder+xml"
|
|
title="ICRA labels" /></code></p>
|
|
|
|
<p>but is more efficiently done by configuring the example.com server(s) to
|
|
include the equivalent HTTP Link header thus:</p>
|
|
|
|
<p><code>Link: </powder.xml>; rel="describedby";
|
|
type="application/powder+xml";</code></p>
|
|
|
|
<p>A user agent, such as a content aggregation service, can now support
|
|
different policies with respect to the resources available from example.com.
|
|
It may, for example, choose not to include the night life section for all its
|
|
customers, or conversely to promote that section as it is a better fit for
|
|
its own target market.</p>
|
|
|
|
<p>Notice also that example.com has referred to an independent certification
|
|
body in Line 15. A user agent might be satisfied that example.com's
|
|
description of its own content is sufficiently trustworthy to be of use or it
|
|
may choose to query the service operated by http://independent.example.org
|
|
before conferring trust on the data. In the specific case of ICRA
|
|
descriptions, it is often the case that a description of content as being
|
|
potentially harmful or offensive is trusted more readily than descriptions of
|
|
content as being suitable for children. Thus external verification mechanisms
|
|
can have varying degrees of importance even within a single domain of
|
|
interest.</p>
|
|
|
|
<h3><a name="example_mobileOK" id="example_mobileOK">mobileOK</a></h3>
|
|
|
|
<p>mobileOK is a standard that deals with content that is rendered within a
|
|
mobile context and adheres to a set of guidelines called the mobileOK Basic
|
|
Tests. Claiming mobileOK has been one of the major use cases of POWDER and
|
|
the example below outlines how this claim can be made using a POWDER
|
|
document.</p>
|
|
|
|
<div class="example">
|
|
<p class="caption">Example: mobileOK (from Example 5-3: A DR Claiming
|
|
Conformance to mobileOK Basic, Supported By the mobileOK Basic Checker [<a
|
|
href="mobileOK_example.xml">XML</a>]</p>
|
|
<pre>1 <?xml version="1.0"?>
|
|
2 <powder xmlns="http://www.w3.org/2007/05/powder#">
|
|
|
|
3 <attribution>
|
|
4 <issuedby src="http://www.example.com/company.rdf#me" />
|
|
5 <issued>2008-06-25T00:00:00</issued>
|
|
6 <supportedby src="http://validator.w3.org/mobile/" />
|
|
7 </attribution>
|
|
|
|
8 <dr>
|
|
9 <iriset>
|
|
10 <includehosts>example.com</includehosts>
|
|
11 </iriset>
|
|
|
|
12 <descriptorset>
|
|
13 <typeof src="http://www.w3.org/2008/06/mobileOK#conformant" />
|
|
14 <displaytext>The example.com website conforms to mobileOK</displaytext>
|
|
15 <displayicon src="http://www.w3.org/2005/11/MWI-Icons/mobileOK.png" />
|
|
16 </descriptorset>
|
|
17 </dr>
|
|
|
|
18 </powder></pre>
|
|
</div>
|
|
|
|
<p>The above example shows a POWDER document which contains information about
|
|
who has made the claim, when the claim was made and, in this particular case,
|
|
also lists a supporting link to the <a
|
|
href="http://validator.w3.org/mobile/">W3C mobileOK Checker</a>. The Checker
|
|
is used to test conformance.</p>
|
|
|
|
<p>Next the DR contains the resources to which this claim applies and the
|
|
descriptors. In Semantic Web terms, the <code>typeof</code> element is a
|
|
shorthand for <code>rdf:type</code> and asserts that all resources on
|
|
example.com are instances of the mobileOK Class. Descriptive text and an icon
|
|
are also provided.</p>
|
|
<hr />
|
|
|
|
<h2><a name="Acknowledg" id="Acknowledg">8. Acknowledgements</a></h2>
|
|
|
|
<p>The editor gratefully acknowledges the substantial contributions made
|
|
by:</p>
|
|
<dl>
|
|
<dt>Phil Archer - Institute of Informatics & Telecommunications (IIT), NCSR "Demokritos" (formerly with FOSI)</dt>
|
|
<dt>Alan Chuter - Technosite</dt>
|
|
<dt>Diana Pentecost, AOL LLC</dt>
|
|
</dl>
|
|
<hr />
|
|
<!-- REFERENCES -->
|
|
|
|
<h2><a name="References" id="References">9. References</a></h2>
|
|
<dl>
|
|
<dt><a id="dc" name="dc">[DC</a>]</dt>
|
|
<dd><cite><a href="http://dublincore.org/">Dublin Core Metadata
|
|
Initiative</a></cite> This information is at http://dublincore.org/</dd>
|
|
<dt><a id="dr" name="dr">[DR]</a></dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc3987.txt">Protocol for Web
|
|
Description Resources (POWDER): Description Resources </a></cite>, P.
|
|
Archer, K. Smith, A. Perego. This document is at
|
|
http://www.w3.org/TR/powder-dr </dd>
|
|
<dt><a id="earl" name="earl">[EARL</a>]</dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/EARL10/">Evaluation and Report
|
|
Language (EARL) 1.0 Schema</a></cite> Schema Document 23 March 2007,
|
|
Shadi Abou-Zahra. This document is at http://www.w3.org/TR/EARL10/</dd>
|
|
<dt><a id="foaf" name="foaf">[FOAF</a>]</dt>
|
|
<dd><cite><a href="http://xmlns.com/foaf/spec/">FOAF Vocabulary
|
|
Specification</a></cite> Namespace Document 24 May 2007, D. Brickley,
|
|
L. Miller. This document is at http://xmlns.com/foaf/spec/ </dd>
|
|
<dt><a id="formal" name="formal">[FORMAL]</a></dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/powder-formal/">Protocol for Web
|
|
Description Resources (POWDER): Formal Semantics</a></cite> 2008, S.
|
|
Konstantopoulos, P. Archer. This document is at
|
|
http://www.w3.org/TR/powder-formal/</dd>
|
|
<dt><a id="grddl" name="grddl">[GRDDL]</a></dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/grddl/">Gleaning Resource
|
|
Descriptions from Dialects of Languages (GRDDL)</a></cite> W3C
|
|
Recommendation 11 September 2007. D. Connolly. This document is at
|
|
http://www.w3.org/TR/grddl/</dd>
|
|
<dt><a id="group" name="group">[GROUP]</a></dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/powder-grouping/">Protocol for
|
|
Web Description Resources (POWDER): Grouping of Resources</a></cite>,
|
|
A. Perego, P. Archer. This document is at
|
|
http://www.w3.org/TR/powder-grouping/</dd>
|
|
<dt><a id="iri" name="iri">[IRI]</a></dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc3987.txt">Internationalized
|
|
Resource Identifiers (IRIs)</a></cite>, M. Drst, M. Suignard. IETF,
|
|
January 2005. This document is at
|
|
http://www.ietf.org/rfc/rfc3987.txt</dd>
|
|
<dt><a name="mok" id="mok">[MOK]</a></dt>
|
|
<dd><a href="http://www.w3.org/TR/mobileOK/">W3C mobileOK Scheme 1.0</a>,
|
|
J. Rabin. This document is at http://www.w3.org/TR/mobileOK/</dd>
|
|
<dt><a id="testsuite" name="testsuite">[TESTS]</a></dt>
|
|
<dd><cite><a
|
|
href="http://www.w3.org/TR/powder-test/">Protocol for
|
|
Web Description Resources (POWDER): Test Suite</a></cite> 2008, A.
|
|
Kukurikos. This document is at
|
|
http://www.w3.org/2007/powder/Group/powder-test/</dd>
|
|
<dt><a id="usecases" name="usecases">[USECASES]</a></dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/powder-use-cases/">POWDER: Use
|
|
Cases and Requirements</a></cite> W3C Working Group Note 31 October
|
|
2007, P. Archer. This document is at
|
|
http://www.w3.org/TR/powder-use-cases/</dd>
|
|
<dt><a name="wcag" id="wcag">[WCAG]</a></dt>
|
|
<dd><a href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility
|
|
Guidelines 2.0</a>, B. Caldwell, M. Cooper, L. Guarino Reid, G.
|
|
Vanderheiden. This document is at http://www.w3.org/TR/WCAG20/</dd>
|
|
<dt><a name="xmlsig" id="xmlsig">[XMLSIG]</a></dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/xmldsig-core/">XML-Signature
|
|
Syntax and Processing</a></cite>, Donald. Eastlake, J. Reagle, D. Solo
|
|
(Eds). W3C Recommendation 12 February 2002. this document is at
|
|
http://www.w3.org/TR/xmldsig-core/</dd>
|
|
<dt><a name="wot" id="wot">[WOT]</a></dt>
|
|
<dd><cite><a href="http://xmlns.com/wot/0.1/">Web Of Trust RDF
|
|
Ontology</a></cite>, D. Brickley. This document is at
|
|
http://xmlns.com/wot/0.1/</dd>
|
|
<dt id="xqxp">[XQXP]</dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/xpath-functions/">XQuery 1.0 and XPath 2.0 Functions and Operators</a></cite>, A. Malhotra, J. Melton, N. Walsh. W3C Recommendation, 23 January 2007. This document is at http://www.w3.org/TR/xpath-functions/</dd>
|
|
|
|
</dl>
|
|
|
|
<h2 id="change">10. Changes since <a href="http://www.w3.org/TR/2009/NOTE-powder-primer-20090604/">previous version</a> (published 4 June 2009).</h2>
|
|
<ul>
|
|
<li><a href="#typo">Typso corrected</a> following e-mail from <a href="http://lists.w3.org/Archives/Public/public-powderwg/2009Jun/0004.html">Paul Denning</a>.</li>
|
|
<li>Media type corrected throughout to say <code>application/powder+xml</code> cf. <code>text/powder.xml</code></li>
|
|
</ul>
|
|
|
|
|
|
</body>
|
|
</html>
|