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.
825 lines
48 KiB
825 lines
48 KiB
<!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" lang="en" xml:lang="en">
|
|
<head>
|
|
<title>POWDER: Use Cases and Requirements</title>
|
|
<style type="text/css">
|
|
li, dt, dd {margin-top: 1em;}
|
|
ul, ol, dl {margin-top: 1em; margin-bottom: 1em;}
|
|
.comment {margin-left: 2em; font-style: italic;}
|
|
.example {padding: 0.5em; background-color: rgb(204, 255, 204);}
|
|
.oq {border-style: dotted; border-width: 1px; background-color:#ccffcc; padding:1em}
|
|
table.vocab {margin: 0 auto; border-collapse:collapse; border:thin solid black}
|
|
td, th {border:thin solid black; padding:0.5em}
|
|
caption {caption-side:bottom; padding-top:1em; margin:0 auto}
|
|
p.imgcaption {text-align:center; font-size:0.9em; font-weight:bold}
|
|
ul.toc {margin-top: auto; margin-bottom: auto;}
|
|
ul.toc li {margin-top: 0.5em;}
|
|
.del {text-decoration:line-through; background-color:#99ff99}
|
|
.new {background-color:#99ff99}
|
|
</style>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE"/>
|
|
</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>POWDER: Use Cases and Requirements</h1>
|
|
<h2>W3C Working Group Note 31 October 2007</h2>
|
|
<dl>
|
|
<dt>This version:</dt><dd><a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20071031/">http://www.w3.org/TR/2007/NOTE-powder-use-cases-20071031/</a></dd>
|
|
<dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/powder-use-cases/">http://www.w3.org/TR/powder-use-cases/</a></dd>
|
|
<dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070831/">http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070831/</a></dd>
|
|
<dt>Editor:</dt>
|
|
<dd>Phil Archer, Family Online Safety Institute</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007
|
|
<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 id="abstract">Abstract</h2>
|
|
|
|
<p>This document sets out the use cases and requirements that have motivated the development of the Protocol for Web Description Resources (POWDER).
|
|
The use cases address social and commercial needs to provide information about groups of Web resources, such as those available from a Web
|
|
site, to aid the annotation and/or personalization of content for end users in varying delivery contexts.</p>
|
|
|
|
<h2 id="status">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 a <a href="http://www.w3.org/2005/10/Process-20051014/tr#WGNote">W3C Working Group Note</a> of the POWDER Use Cases and Requirements, developed by the <a href="http://www.w3.org/2007/powder/">POWDER Working Group</a>
|
|
as part of the <a href="http://www.w3.org/2001/sw/">Semantic Web Activity</a>.
|
|
It is the third version of the document to be published, the revision being carried out largely to accommodate a
|
|
<a href="http://lists.w3.org/Archives/Public/public-powderwg/2007Sep/0012.html">new variant</a> on the accessibility use case that the working group felt was important.</p>
|
|
|
|
<p>The Working Group believes the document to be stable and therefore to be suitable as the basis for the group's ongoing work. The
|
|
differences between this document and the two previous versions can be found in the <a href="#changes">change log</a>.</p>
|
|
|
|
<p>Please send comments about this document to <a href="mailto:public-powderwg@w3.org">public-powderwg@w3.org</a> (with <a href="http://lists.w3.org/Archives/Public/public-powderwg/">public archive</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 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>
|
|
|
|
<h2 id="toc">Table of Contents</h2>
|
|
<div class="toc">
|
|
<ul class="toc">
|
|
<li>1 <a href="#intro">Introduction</a></li>
|
|
<li>2 <a href="#usecases">Use Cases</a>
|
|
<ul class="toc">
|
|
<li>2.1 <a href="#case1">Profile Matching</a>
|
|
<ul class="toc">
|
|
<li>2.1.1 <a href="#generic">Generic Profile Matching Use Case</a></li>
|
|
<li>2.1.2 <a href="#adaptSearch">Adaptive Search Results</a></li>
|
|
<li>2.1.3 <a href="#mokuc">mobileOK</a></li>
|
|
<li>2.1.4 <a href="#functional">Functional User Experience</a></li>
|
|
<li>2.1.5 <a href="#accessA">Web Accessibility A</a></li>
|
|
<li>2.1.6 <a href="#accessB">Web Accessibility B</a></li>
|
|
<li>2.1.7 <a href="#cpA">Child Protection A</a></li>
|
|
<li>2.1.8 <a href="#cpB">Child Protection B</a></li>
|
|
<li>2.1.9 <a href="#priv">Privileged Content</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>2.2 <a href="#case2">Trustmarks</a>
|
|
<ul class="toc">
|
|
<li>2.2.1 <a href="#browser">Browser Display</a></li>
|
|
<li>2.2.2 <a href="#compliance">Compliance Monitoring</a></li>
|
|
<li>2.2.3 <a href="#directdata">Direct Data Provision</a></li>
|
|
<li>2.2.4 <a href="#self">Description Authentication</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>2.3 <a href="#semantics">Semantic Annotation</a>
|
|
<ul class="toc">
|
|
<li>2.3.1 <a href="#semsearch">Semantic Search</a></li>
|
|
<li>2.3.2 <a href="#mlk">An Explicit Viewpoint</a></li>
|
|
<li>2.3.3 <a href="#tagsrus">User-Defined Tags</a></li>
|
|
<li>2.3.4 <a href="#case4">Rich Metadata for RSS/ATOM</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>2.4 <a href="#case6">Scalar Classification</a></li>
|
|
<li>2.5 <a href="#case7">Expressing Editorial Policy</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>3 <a href="#reqs">Requirements</a>
|
|
<ul class="toc">
|
|
<li>3.1 <a href="#fundamental">Fundamentals</a></li>
|
|
<li>3.2 <a href="#comWork">Fitting in with Commercial or Other Large Scale Workflows</a></li>
|
|
<li>3.3 <a href="#reqEnc">DRs for Humans and Machines</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>4 <a href="#ack">Acknowledgements</a></li>
|
|
<li>5 <a href="#refs">References</a></li>
|
|
<li>6 <a href="#changes">Change Log</a>
|
|
<ul>
|
|
<li>6.1 <a href="#rev1">Changes between first and second published versions</a></li>
|
|
<li>6.2 <a href="#rev2">Changes between previous and this version</a></li>
|
|
</ul></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<h2 id="intro">1 Introduction</h2>
|
|
<p>The development of the Protocol for Web Description Resources has been motivated by both commercial and social concerns.
|
|
On the social side, there is a demand for a system to identify content that meets certain criteria as they apply to specified
|
|
audiences. Commercially, there is a demand to be able to personalize content for a particular user or delivery context.</p>
|
|
|
|
<p>POWDER will address these demands by defining a method through which relatively small amounts of metadata, that can
|
|
be produced quickly and easily, can be applied to large amounts of content.</p>
|
|
|
|
<p>The use cases and requirements for POWDER were originally developed under the <a href="http://www.w3.org/2005/Incubator/wcl/">Web
|
|
Content Label Incubator Activity</a>. They have been revised and updated for this Working Group Note.</p>
|
|
|
|
|
|
<h2 id="usecases">2 Use cases</h2>
|
|
|
|
<h3 id="case1">2.1 Profile matching</h3>
|
|
<p>The generic use case for profile matching is that a user receives content suited to their
|
|
delivery context; that is, the combination of user preferences, device capabilities and current
|
|
state at the time of content delivery. Description Resources facilitate this decision by
|
|
making available rules about groups of Web resources to a Web Server. At request time the Web
|
|
Server can determine if there are any rules in the <acronym title="description resource">DR</acronym> which apply to the requested URI,
|
|
and respond to the User accordingly.</p>
|
|
|
|
<div style="border:thin solid black; padding:0 0.5em">
|
|
<p>This extended use case refers to the following terms.</p>
|
|
<h4 id="actors">Actors: </h4>
|
|
<div style="margin-left:1em">
|
|
<p><strong>User</strong>: A human who perceives and interacts with the Web.</p>
|
|
<p><strong>Device</strong>: Apparatus through which a user can perceive and interact with
|
|
the Web</p>
|
|
<p><strong>Server</strong>: The role adopted by an application when it is supplying
|
|
resources or resource manifestations.</p>
|
|
<p><strong>Network Operator</strong>: A mobile telephony and data infrastructure provider.</p>
|
|
<p><strong>Adaptation</strong>: a process of selection, generation or modification of Web
|
|
content to suit the given delivery context.</p>
|
|
</div>
|
|
|
|
<h4 id="ctypes">Content Types:</h4>
|
|
<p style="margin-left:1em"><strong>Web content</strong>: any resource retrievable via a URI over the World Wide Web
|
|
intended for direct user consumption (Web pages and audio/visual media types).</p>
|
|
</div>
|
|
|
|
<h4 id="generic">2.1.1 Generic Profile Matching Use Case</h4>
|
|
<div style="margin-left:1em">
|
|
<dl>
|
|
<dt>Step 1</dt>
|
|
<dd>User requests Web content via their device.</dd>
|
|
|
|
<dt>Step 2</dt>
|
|
<dd>A Server resolves the URI and determines that there is metadata associated with the resource that asserts access conditions.</dd>
|
|
|
|
<dt>Step 3</dt>
|
|
<dd>The Server matches the assertions in the metadata, to the user's delivery context.</dd>
|
|
</dl>
|
|
|
|
<p>Then <strong>either</strong></p>
|
|
<dl>
|
|
<dt>Step 4a</dt>
|
|
<dd>The Server interprets that there are no constraints on the user accessing the content,</dd>
|
|
<dt>Step 5a</dt>
|
|
<dd>The Server responds to the User with the full Web content.</dd>
|
|
</dl>
|
|
|
|
<p><strong>or</strong></p>
|
|
|
|
<dl>
|
|
<dt>Step 4b</dt>
|
|
<dd>The metadata asserts that the requested content is not appropriate to the current delivery context. </dd>
|
|
<dt>Step 5b</dt>
|
|
<dd>The Server adapts the content and responds to the User.</dd>
|
|
</dl>
|
|
<p>
|
|
This generic example uses the phrase 'delivery context'. This means different things in different circumstances. For
|
|
example, in sub use cases 2.1.2 and 2.1.3 it means the characteristics of the device being used to access the content, in
|
|
2.1.4 it's the connection bandwidth that is important, whereas in sub uses cases 2.1.5 - 2.1.7 the delivery context is
|
|
related to a profile of the end user. It is assumed that the relevant features of the delivery context will be determined using a
|
|
technique appropriate to the use case. For example, device characteristics are likely to be retrieved from a repository whilst child
|
|
protection software is likely to work with several sources of data in addition to Description Resources. Matching of resources
|
|
against end users is likely to involve reference to an Identity Management System which is beyond the scope of POWDER. </p>
|
|
</div>
|
|
|
|
<h4 id="adaptSearch">2.1.2 Adaptive Search Results</h4>
|
|
<ol>
|
|
<li>Anne enters a search string, 'Pianos', into a search engine, search.example.org.</li>
|
|
<li>The search engine notes the characteristics of Anne's device by retrieving a description from a Device Description Repository. </li>
|
|
<li>The search engine obtains a set of URIs that are relevant to the search key.</li>
|
|
<li>The search engine notes the characteristics of the content associated with each URI.</li>
|
|
<li>The search engine compares the device characteristics to the content characteristics.</li>
|
|
<li>The search engine removes the URIs of content that cannot be rendered by, or adapted to, Anne's device.</li>
|
|
<li>The search engine returns a list of the remaining URIs to Anne.</li>
|
|
<li>If Anne selects from one of the returned URIs, the identified content is delivered as is (if appropriate to the known device capabilities) or adapted accordingly.</li>
|
|
</ol>
|
|
|
|
<h4 id="mokuc">2.1.3 mobileOK</h4>
|
|
<ol>
|
|
<li>Dan wants to be able to access a directory of Web sites that will give an optimal user experience on his mobile phone. He enters
|
|
'Sausages' into search.example.com and checks the box that says 'MobileOK results only' [<a href="#mok">MOK</a>]</li>
|
|
<li>The search engine retrieves a set of URIs from its index and determines those resources with associated metadata describing their
|
|
characteristics. Any resources without such metadata are discarded.</li>
|
|
<li>The search engine inspects the metadata and determines which resources are declared to be conformant with mobileOK.</li>
|
|
<li>The search engine returns a list of the URIs of mobileOK conformant resources to Dan.</li>
|
|
<li>If Dan selects from one of the returned URIs, the identified content is delivered as is.</li>
|
|
</ol>
|
|
|
|
<h4 id="functional">2.1.4 Functional User Experience</h4>
|
|
<ol>
|
|
<li>Hwang visits a martial arts Web site through his laptop computer and requests a page of streaming video clips.</li>
|
|
<li>The Server's content management system detects that there is metadata associated with all URIs containing /video/ in their path.</li>
|
|
<li>The Server retrieves and inspects the metadata and discovers that only devices connecting at a minimum bandwidth of 150K will be able to
|
|
stream the videos. </li>
|
|
<li>The Server determines that Hwang's laptop is currently connected at a lower bandwidth. </li>
|
|
<li>The Server redirects Hwang to a page of images more appropriate to his bandwidth.</li>
|
|
</ol>
|
|
|
|
|
|
|
|
<h4 id="accessA">2.1.5 Web Accessibility A (third-party labeling, guidelines compliance, user choice)</h4>
|
|
<ol>
|
|
<li>
|
|
Iris is a member of a self-help group of volunteers who evaluate the
|
|
accessibility of Web content. The members evaluate compliance with the
|
|
Web Content Accessibility Guidelines [<a href="#wai">WAI</a>] and on the group's web server
|
|
they publish labels applicable to the web sites. The labels express
|
|
compliance as test results and use EARL, the Evaluation and Report Language [<a href="#earl">EARL</a>].
|
|
</li>
|
|
<li>
|
|
A Web search engine cooperates with the group and gathers metadata from the
|
|
labels it publishes. This enables it to include accessibility information in
|
|
search results and provide customized results lists for users who prioritize
|
|
compliance with particular checkpoints of the guidelines.
|
|
</li>
|
|
<li>
|
|
Janet wishes to shop for CDs online. She has limited dexterity and therefore
|
|
difficulty using a mouse. The search engine takes into account her
|
|
preference for web pages that facilitate keyboard navigation (for example
|
|
compliance with
|
|
<a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-device-independence" id="e200" title="WCAG 1.0 Guideline 9. Design for device-independence">WCAG
|
|
1.0 Guideline 9. Design for device-independence</a>). She searches for her
|
|
favorite artist through the Search engine's 'search shops' interface.<br/>
|
|
</li>
|
|
<li>
|
|
The search engine retrieves a set of URIs from its index that match the
|
|
search query and uses its database of label metadata assertions to indicate
|
|
which sites <b>do not comply</b> with WCAG 1.0 guideline 9, so that Iris can
|
|
choose those sites that do comply.
|
|
</li>
|
|
</ol>
|
|
|
|
<h4 id="accessB">2.1.6 Web Accessibility B (self labeling, content features, profile matching)</h4>
|
|
<ol>
|
|
<li>
|
|
Colin is a student at the world university. Colin sometimes studies at home
|
|
with special
|
|
<a href="http://www.w3.org/WAI/GL/Glossary/printable.html#def-braille" title="definition of Braille in WAI glossary">Braille</a>
|
|
equipment but likes to listen to course readings when he is on campus,
|
|
using a
|
|
<a href="http://www.w3.org/WAI/GL/Glossary/printable.html#def-screen-reader" title="Definition of screen reader in WAI Glossary">screen
|
|
reader</a> (profile 1). His sister Mary sometimes likes to work with
|
|
him, sharing a computer and describing what's happening, as they are
|
|
studying the same subjects (profile 2). When Mary is studying alone she
|
|
uses no assistive technology (profile 3). Between them therefore they have
|
|
three profiles of needs and preferences and may change between them. The
|
|
profiles impose different requirements on the resources that Colin and Mary
|
|
can use adequately.
|
|
</li>
|
|
<li>
|
|
The university's staff produce teaching materials in alternative versions to
|
|
suit different user needs as closely as possible. Staff are trained to
|
|
create labels describing the accessibility features of their materials with
|
|
AccessForAll Metadata [<a href="#afa">AFA</a>].</li>
|
|
<li>
|
|
The university's web site has an application that stores profiles of user
|
|
needs also expressed in AccessForAll Metadata. The system analyses content labels embedded in course
|
|
materials and uses rules to discover alternative versions of content
|
|
suitable for a user's active profile.
|
|
</li>
|
|
<li>
|
|
For Mary studying alone (profile 3) a complex diagram may be presented
|
|
as-is, but if she is studying with Colin they may select profile 2 and the
|
|
system discovers and delivers to them the same image of the diagram together
|
|
with a detailed text description. If Colin is alone he cannot see the image
|
|
and selects profile 1 to read only the text description.
|
|
</li>
|
|
</ol>
|
|
|
|
<h4 id="cpA">2.1.7 Child Protection A</h4>
|
|
<ol>
|
|
<li>Barry, who is 16 years old, has been sent a URI in an SMS message to his mobile phone. He clicks on the link, which unknown to him, is to an
|
|
adults-only area of a example.com.</li>
|
|
<li>The Network Operator has a child protection policy which allows parents to decide if they or their family can access certain content.
|
|
One technique it uses is to check any metadata references before responding to the User.</li>
|
|
<li>The Network Operator retrieves a metadata description from the Web portal, which declares that anything at the server adult.example.com
|
|
contains explicit nudity. The Network Operator determines from Barry's profile that his parents have asked such access to be restricted.</li>
|
|
<li>The Network Operator returns a Child Protection explanation page to Barry.</li>
|
|
</ol>
|
|
|
|
<h4 id="cpB" >2.1.8 Child protection B</h4>
|
|
<ol>
|
|
<li>Thomas creates a portal offering what he considers to be terrific content for children. He adds a Description Resource expressing the view
|
|
that all material available on the portal is suitable for children of all ages.</li>
|
|
<li>Independently, a large content classification company, classification.example.org, crawls Thomas's portal and classifies it as being safe for children.</li>
|
|
<li>Discovering this, Thomas updates his Description Resource with a link to the relevant entry in the online database operated at classification.example.org.</li>
|
|
<li>5 year old Briana visit's the portal. The parental control software installed by her parents notes the presence of the Description Resource and seeks confirmation
|
|
of the claim that the site is child-safe by following the link to the classification.example.org database, which her parents have deemed trustworthy.</li>
|
|
<li>On receiving such confirmation, access is granted and Briana enjoys the content Thomas has created.</li>
|
|
</ol>
|
|
|
|
<h4 id="priv">2.1.9 Privileged Content</h4>
|
|
<ol>
|
|
<li>Ray is a premium customer of exampleISP, an Internet Service Provider. They have a deal which allows him to access premium content on
|
|
other Web sites as long as he accesses it using exampleISP. Ray visits such a 3rd party, games.example.org</li>
|
|
<li>The games.example.org Server retrieves metadata which describes the group of resources reachable from their homepage.</li>
|
|
<li>The Server determines from the metadata assertions that all files whose suffix is .jad (to indicate a Java download) are for premium
|
|
users.</li>
|
|
<li>The Server determines from Ray's delivery context and exampleISP's identity management system that he is a premium customer</li>
|
|
<li>The Server responds with a page containing all links, available for Ray to download.</li>
|
|
</ol>
|
|
|
|
|
|
<p>Motivates:
|
|
<a href="#makeAssert">3.1.1 Making Assertions</a>;
|
|
<a href="#DRrole">3.1.2 The Role of a Description Resource</a>;
|
|
<a href="#grouping">3.1.3 Grouping</a>;
|
|
<a href="#compo">3.1.4 Composite Assertions</a>;
|
|
<a href="#refer">3.1.8 Reference</a>;
|
|
<a href="#stanVocab">3.1.9 Standard Vocabularies</a>;
|
|
<a href="#identity">3.1.10 Identity</a>;
|
|
<a href="#unambiguous">3.1.11 Unambiguous</a>;
|
|
<a href="#authentic">3.2.1 Authentication</a>;
|
|
<a href="#edit">3.2.2 Separation of Description and Resource</a>;
|
|
<a href="#machineRead">3.3.1 Machine-Readable</a>;
|
|
<a href="#formal">3.3.2 Formal Grammar</a>;
|
|
</p>
|
|
|
|
|
|
<h3 id="case2">2.2 Trustmarks</h3>
|
|
<p>There are several possible models in which assertions and claims can be made, authenticated and reported to the end user.
|
|
Each of the following has several elements in common but differs in details such as whether it is the content provider or
|
|
the trust mark operator that makes the original claim, whether the data is stored on the trust mark operator's servers or
|
|
alongside the content itself, and whether the trust mark operator provides the description or the authentication
|
|
for a description.</p>
|
|
|
|
|
|
<h4 id="browser">2.2.1 Browser Display</h4>
|
|
|
|
<p>Joseph installs a web browser plugin on his personal computer designed to aggregate and interpret safety/reliability
|
|
information about Web sites from various sources, such as reputation and accreditation services. The web browser
|
|
plugin provides a visual indication of whether the Web site that Joseph is currently visiting is considered trustworthy or not.</p>
|
|
|
|
<p>The plugin retrieves information about Web sites using several methods. One of these methods involves querying
|
|
the Description Resource associated with a Web site.</p>
|
|
|
|
<div style="text-align:center">
|
|
<img src="trustusecase.png" width="983" height="450" alt="Diagrammatic representation of Use case 2.2.1 (Trust Mark)" />
|
|
</div>
|
|
<p class="imgcaption">Diagrammatic representation of Use case 2.2.1 (Trust Mark)</p>
|
|
|
|
<p>Joseph visits a Web site to do some holiday shopping. The browser plugin identifies the site's Description Resource, which
|
|
asserts that the Web site has been certified by an accreditation service and provided with a trustmark.</p>
|
|
|
|
<p>The plugin determines that the accreditation and trustmark are provided by a known entity with a validation
|
|
mechanism in place. The plugin queries the accreditation service provider by submitting the assertion of
|
|
the Web site's accreditation.</p>
|
|
|
|
<p>The accreditation service provider validates the assertion of accreditation and provides a graphic file
|
|
containing a trustmark. The plugin displays the trustmark to Joseph along with a visual indication that
|
|
the Web site has a good reputation.</p>
|
|
|
|
|
|
<h4 id="compliance">2.2.2 Compliance Monitoring</h4>
|
|
|
|
<div style="border:thin solid black; padding:0 0.5em">
|
|
<p>This use case refers to the following terms.</p>
|
|
<dl>
|
|
<dt>Evaluator</dt>
|
|
<dd>Evaluates Web content and if it complies with rules, issues a label to the Web site owner.</dd>
|
|
<dt>Regulator</dt>
|
|
<dd>A body that oversees quality and accessibility of Web content. Needs to be able to read labels published by Web sites.</dd>
|
|
<dt>Robot</dt>
|
|
<dd>An automated system used by the Regulator to read labels on Web sites.</dd>
|
|
<dt>Authentication Service</dt>
|
|
<dd>A Web service that attests to the validity and authenticity of labels. Must be able to read the labels used by Evaluators.</dd>
|
|
<dt>Report generator</dt>
|
|
<dd>An application that collates and summarizes compliance information provided by the Robot in a form suitable for human users employed by the Regulator.</dd>
|
|
</dl>
|
|
</div>
|
|
<p>A government department (regulator) is responsible for overseeing the accessibility of all
|
|
Web sites produced by different levels of government: national and local. It has approved a number of
|
|
private-sector companies to carry out accessibility evaluation work but there is a need for some mechanism
|
|
for the evaluators to label the sites in a reliable and machine-readable way, to allow automated monitoring.</p>
|
|
|
|
<p>The evaluators provide Web sites with labels. Web site administrators embed links to the labels in their
|
|
pages. A robot used by the government department regularly crawls the Web sites and reads the labels, and
|
|
checks the data for authenticity and validity using a web service provided by a third-party Authentication
|
|
Service. A report generator produces progress reports and violation notices based on the information from
|
|
the data.</p>
|
|
|
|
<h4 id="directdata">2.2.3 Direct Data Provision</h4>
|
|
<p>The Example Trustmark Scheme reviews online traders, providing a trustmark for those that meet a set of published criteria.
|
|
The scheme operator wishes to make its trustmark available as machine-readable code as well as a graphic so that content
|
|
aggregators, search engines and end-user tools can recognize and process them in some way.</p>
|
|
|
|
<p>The trustmark operator maintains a database of sites it has approved and makes this available in two ways:</p>
|
|
|
|
<p>Firstly, the trusted site includes a link to the database. A user agent visiting the site detects and follows the
|
|
link to the trustmark scheme's database from which it can extract the description of the particular site in real time.</p>
|
|
|
|
<p>Secondly, the scheme operator makes the full database available in a single file for download and processing offline.</p>
|
|
|
|
<p>Since the actual data comes directly from the trustmark scheme operator, it is not open to corruption by the online trader and can
|
|
therefore be considered trustworthy to a large degree. To reduce the risk of spoofing, however, the data is digitally signed.</p>
|
|
|
|
|
|
<h4 id="self">2.2.4 Description Authentication</h4>
|
|
<p>Mrs. Bryanton teaches 8 year olds at her local school. An IT enthusiast, she makes her teaching materials available through
|
|
her personal Web site. She adds a Description Resource to her material that declares the subject matter and curriculum area.</p>
|
|
|
|
<p>In order to gain wider trust in her work she submits her site for review by her local education authority. That body
|
|
then publishes its own Description Resource that declares Mrs Bryanton's Description Resource to be accurate.</p>
|
|
|
|
<p>Motivates:
|
|
<a href="#makeAssert">3.1.1 Making Assertions</a>;
|
|
<a href="#DRrole">3.1.2 The Role of a Description Resource</a>;
|
|
<a href="#grouping">3.1.3 Grouping</a>;
|
|
<a href="#compo">3.1.4 Composite Assertions</a>;
|
|
<a href="#multiDRs">3.1.5 Multiple DRs</a>;
|
|
<a href="#independent">3.1.6 Independence</a>;
|
|
<a href="#attribution">3.1.7 Attribution</a>;
|
|
<a href="#refer">3.1.8 Reference</a>;
|
|
<a href="#stanVocab">3.1.9 Standard Vocabularies</a>;
|
|
<a href="#identity">3.1.10 Identity</a>;
|
|
<a href="#unambiguous">3.1.11 Unambiguous</a>;
|
|
<a href="#authentic">3.2.1 Authentication</a>;
|
|
<a href="#edit">3.2.2 Separation of Description and Resource</a>;
|
|
<a href="#testresult">3.2.4 Link to Test Results</a>;
|
|
<a href="#bulk">3.2.5 Bulk Data Transfer</a>;
|
|
<a href="#machineRead">3.3.1 Machine-Readable</a>;
|
|
<a href="#formal">3.3.2 Formal Grammar</a>;
|
|
<a href="#human">3.3.3 Human Readable</a>;
|
|
<a href="#images">3.3.4 Images</a>.
|
|
</p>
|
|
|
|
|
|
|
|
<h3 id="semantics">2.3 Semantic Annotation</h3>
|
|
<p>The use cases in this section highlight the potential benefit of Description Resources to content aggregators, search engines and related services.</p>
|
|
|
|
<p>Note, sections 2.3 and 2.4 in the <a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070525/">previous version</a> of this document have been rearranged
|
|
but the content is the same except for use case 2.3.1 which is new.</p>
|
|
|
|
<h4 id="semsearch">2.3.1 Semantic Search</h4>
|
|
<p>Raman in Bangalore publishes a globally popular sports website that
|
|
features Soccer, Gridiron, Gaelic football, and Australian rules
|
|
football channels. Raman wants to ensure that when users around the
|
|
world search for 'football' that the appropriate channel is included in
|
|
the search results, based on their country location. As such he
|
|
publishes an accurate description of each channel for search engines to
|
|
process.</p>
|
|
|
|
<p>Gautam in London likes to keep up to date with sport. He enters the
|
|
search term 'Football news' into a search engine which, based on his
|
|
location, gives priority to those resources in its index that have
|
|
metadata explicitly describing the content as being about the game of
|
|
soccer. As such Raman's soccer channel is included in the results. </p>
|
|
|
|
<p>Bill in Silicon Valley also enters the search term 'Football news' into
|
|
a search engine which, based on his location, gives priority to those
|
|
resources in its index that have metadata explicitly describing the
|
|
content as being about the game of Gridiron; and Raman's Gridiron
|
|
channel is included in the results. </p>
|
|
|
|
|
|
<h4 id="mlk">2.3.2 An Explicit Viewpoint</h4>
|
|
|
|
<p>Fred operates an antiracism education site which aggregates and curates content from around the Web. Fred wants to
|
|
label the resources that he aggregates such that educational and other institutions may harvest the resources and associated
|
|
commentary and metadata automatically for reuse within their instructional support systems, etc.</p>
|
|
|
|
<p>One of the ways in which Fred wants to curate resources is to say about them that they are pedagogically useful but
|
|
politically noxious. For example, some sites on the Web make claims about Martin Luther King, Jr that are motivated
|
|
by a racist ideology and are historically indefensible. Fred's vocabulary allows him to claim that such resources
|
|
are pedagogically useful for purposes of analysis, but that they are otherwise suspicious and should only be consumed by
|
|
students in an age-appropriate manner or with appropriate supervision, etc. In other words, Fred needs to be able to
|
|
make sharply divergent claims about resources: (1) that they are noteworthy, and (2) that they are, from his perspective,
|
|
dangerous or noxious or troublesome.</p>
|
|
|
|
|
|
<h4 id="tagsrus">2.3.3 User-Defined Tags</h4>
|
|
<p>The social book-marking site tags.r.us allows their users to tag any
|
|
resource and so provides a service through which people can annotate
|
|
both their own and others' resources.</p>
|
|
|
|
<p>Anders, a zoologist and tags.r.us user, finds a website about the dahut,
|
|
an allegedly undescribed animal that lives in the French Alps. Anders
|
|
wants to make sure that it is understood by readers that this is a
|
|
fictional character, but also that it is interesting to understand the full spectrum of
|
|
cryptozoological thinking, and thus tags it "fictional". </p>
|
|
|
|
<p>The word "fictional" is not very useful without context, so to enable
|
|
such user-defined tags to be shared with others, tags.r.us allows users
|
|
to assign a link between their own tags and a Description Resource,
|
|
that provides the context that it is about an alleged fictional animal.
|
|
An agent can thus use the tag as appropriate, processing the explicit
|
|
semantics provided by the DR but perhaps presenting other users with
|
|
Anders' original tags.</p>
|
|
|
|
<div style="text-align:center">
|
|
<img src="tagsrus3.png" width="471" height="348" alt="Diagrammatic representation of Use case 2.4.2 (User Defined Tags)" />
|
|
</div>
|
|
<p class="imgcaption">Diagrammatic representation of Use case 2.4.2 (User Defined Tags)</p>
|
|
|
|
<p>This use case is very similar to the previous one. The important difference between them being that in 2.3.2
|
|
the description is made using only explicit semantics. In this use case, user-defined tags (i.e. free text) are used but these are then associated
|
|
with a semantically explicit description. In both cases, the opinions expressed are relatively complex so that the semantics are
|
|
critical. Furthermore, these are also scenarios where there is unlikely to be any relationship between the content provider and
|
|
the individual describing the content.</p>
|
|
|
|
|
|
<h4 id="case4">2.3.4 Rich Metadata for RSS/ATOM</h4>
|
|
|
|
<p>Dave Cook's Web site offers reviews of children's films and the site is summarized in both RSS and ATOM feeds. Most of
|
|
the films reviewed have an MPAA rating of G and/or British Board of Film Classification rating of U. This is declared in
|
|
a rating for the channel as a whole. However, Dave includes reviews of some films rated PG-13 or 12 respectively which
|
|
is declared at the item level and overrides the channel level metadata.</p>
|
|
|
|
<p>The actual rating information comes from an online service operated by the relevant film classification board itself
|
|
and is identified using a URI and human-readable text. The movie itself is identified by either an ISAN number or
|
|
the relevant Internet Movie Database entry ID number. Trust is implicit given the source of
|
|
the data, which is indicated by a link to Dave's site's policy.</p>
|
|
|
|
<p>Separately, Fred combines Dave Cook's and other review feeds to provide alternative reviews of the movies by
|
|
transforming the ATOM feeds into RDF and creating an aggregate view using SPARQL queries.</p>
|
|
|
|
|
|
|
|
<p>Motivates:
|
|
<a href="#makeAssert">3.1.1 Making Assertions</a>;
|
|
<a href="#DRrole">3.1.2 The Role of a Description Resource</a>;
|
|
<a href="#grouping">3.1.3 Grouping</a>;
|
|
<!-- <a href="#compo">3.1.4 Composite Assertions</a>;-->
|
|
<a href="#multiDRs">3.1.5 Multiple DRs</a>;
|
|
<a href="#independent">3.1.6 Independence</a>;
|
|
<a href="#attribution">3.1.7 Attribution</a>;
|
|
<a href="#refer">3.1.8 Reference</a>;
|
|
<a href="#stanVocab">3.1.9 Standard Vocabularies</a>;
|
|
<a href="#identity">3.1.10 Identity</a>;
|
|
<a href="#unambiguous">3.1.11 Unambiguous</a>;
|
|
<a href="#authentic">3.2.1 Authentication</a>;
|
|
<a href="#edit">3.2.2 Separation of Description and Resource</a>;
|
|
<a href="#default">3.2.3 Default Description</a>;
|
|
<!--<a href="#testresult">3.2.4 Link to Test Results</a>;-->
|
|
<a href="#bulk">3.2.5 Bulk Data Transfer</a>;
|
|
<a href="#machineRead">3.3.1 Machine-Readable</a>;
|
|
<a href="#formal">3.3.2 Formal Grammar</a>;
|
|
<a href="#human">3.3.3 Human Readable</a>;
|
|
<a href="#tags">3.3.5 User-Generated Tags</a>.
|
|
</p>
|
|
|
|
|
|
<h3 id="case6">2.4 Scalar Classification</h3>
|
|
<p>A company named Advance Medical Inc. reviews medical literature on the Web based on a range of quality criteria
|
|
such as the qualifications of the author(s), the methodology used and the research evidence presented. The
|
|
criteria may be changed according to current scientific and professional developments. The review process
|
|
leads to medical literature being classified in two ways:</p>
|
|
|
|
<p><strong>Quality of Content</strong><br />
|
|
<span style="margin-left:1em"><strong>Level A:</strong> Excellent<br /></span>
|
|
<span style="margin-left:1em"><strong>Level B:</strong> Good<br /></span>
|
|
<span style="margin-left:1em"><strong>Level C:</strong> Acceptable</span></p>
|
|
|
|
<p><strong>Peer Review</strong><br />
|
|
<span style="margin-left:1em"><strong>Level A:</strong> Content has been subjected to peer review<br /></span>
|
|
<span style="margin-left:1em"><strong>Level B:</strong> Content has not been subject to peer review</span></p>
|
|
|
|
<p>The Quality of Content classification is scalar. i.e. meeting the criteria for Level A implies also meeting Level B
|
|
which in turn implies meeting Level C. In contrast, meeting Level A for Peer Review does not imply meeting Level B.</p>
|
|
|
|
<p>The company produces data that declares the classification levels and provides a summary of each document it has
|
|
reviewed. The data is stored in a metadata repository which can be accessed via the Web.</p>
|
|
|
|
<p>M.D. Smith uses the data in the repository to make decisions about heath care for specific clinical circumstances.</p>
|
|
|
|
<p>Motivates:
|
|
<a href="#makeAssert">3.1.1 Making Assertions</a>;
|
|
<a href="#DRrole">3.1.2 The Role of a Description Resource</a>;
|
|
<a href="#grouping">3.1.3 Grouping</a>;
|
|
<a href="#compo">3.1.4 Composite Assertions</a>;
|
|
<a href="#multiDRs">3.1.5 Multiple DRs</a>;
|
|
<a href="#independent">3.1.6 Independence</a>;
|
|
<a href="#attribution">3.1.7 Attribution</a>;
|
|
<!-- <a href="#refer">3.1.8 Reference</a>;-->
|
|
<a href="#stanVocab">3.1.9 Standard Vocabularies</a>;
|
|
<a href="#identity">3.1.10 Identity</a>;
|
|
<a href="#unambiguous">3.1.11 Unambiguous</a>;
|
|
<a href="#authentic">3.2.1 Authentication</a>;
|
|
<a href="#edit">3.2.2 Separation of Description and Resource</a>;
|
|
<!-- <a href="#default">3.2.3 Default Description</a>;-->
|
|
<a href="#testresult">3.2.4 Link to Test Results</a>;
|
|
<a href="#bulk">3.2.5 Bulk Data Transfer</a>;
|
|
<a href="#machineRead">3.3.1 Machine-Readable</a>;
|
|
<a href="#formal">3.3.2 Formal Grammar</a>;
|
|
<a href="#human">3.3.3 Human Readable</a>;
|
|
<a href="#images">3.3.4 Images</a>
|
|
</p>
|
|
|
|
<h2 id="case7">2.5 Expressing Editorial Policy</h2>
|
|
<p>VLCC, (the Very Large Content Company) offers millions of items of content which are delivered through a variety
|
|
of branded channels. Its strict editorial policies dictate that before publication, all content is reviewed by a
|
|
member of the editorial team who checks for compliance with those policies. This is encoded in a description covering
|
|
all its brands that states "VLCC works to ensure that all its content meets W3C Web Accessibility Initiative
|
|
level AA and is suitable for all audiences unless otherwise stated. If you find any of our content does not
|
|
meet these standards, please contact us."</p>
|
|
|
|
<p>The editor is responsible for adding two further descriptions:</p>
|
|
<ol>
|
|
<li>Key words (tags). For example: "News, Middle East", "Lifestyle, DIY, Decorating", "Entertainment, Celebrity Gossip."</li>
|
|
|
|
<li>An age-rating, taken from a set of pre-defined options. For example, content delivered through VLCC's 'Youth of Today' brand
|
|
is usually suitable for all ages, however, occasionally, content aimed at young adults is published that might be inappropriate for
|
|
younger children and is described by one of the other available ratings in line with the overall editorial policy.</li>
|
|
</ol>
|
|
|
|
|
|
<p>Motivates:
|
|
<a href="#makeAssert">3.1.1 Making Assertions</a>;
|
|
<a href="#DRrole">3.1.2 The Role of a Description Resource</a>;
|
|
<a href="#grouping">3.1.3 Grouping</a>;
|
|
<a href="#compo">3.1.4 Composite Assertions</a>;
|
|
<a href="#multiDRs">3.1.5 Multiple DRs</a>;
|
|
<!--<a href="#independent">3.1.6 Independence</a>; -->
|
|
<a href="#attribution">3.1.7 Attribution</a>;
|
|
<a href="#refer">3.1.8 Reference</a>;
|
|
<a href="#stanVocab">3.1.9 Standard Vocabularies</a>;
|
|
<a href="#identity">3.1.10 Identity</a>;
|
|
<a href="#unambiguous">3.1.11 Unambiguous</a>;
|
|
<a href="#authentic">3.2.1 Authentication</a>;
|
|
<a href="#edit">3.2.2 Separation of Description and Resource</a>;
|
|
<a href="#default">3.2.3 Default Description</a>;
|
|
<a href="#testresult">3.2.4 Link to Test Results</a>;
|
|
<a href="#machineRead">3.3.1 Machine-Readable</a>;
|
|
<a href="#formal">3.3.2 Formal Grammar</a>;
|
|
<a href="#human">3.3.3 Human Readable</a>;
|
|
<a href="#tags">3.3.5 User-Generated Tags</a>.
|
|
|
|
</p>
|
|
|
|
<h2 id="reqs">3 Requirements</h2>
|
|
<p>The following requirements are derived from the preceding use cases. They have been assigned to thematic groups as an aid to readability.</p>
|
|
|
|
<h3 id="fundamental">3.1 Fundamentals</h3>
|
|
|
|
<h4 id="makeAssert">3.1.1 Making Assertions</h4>
|
|
<p>It must be possible for both resource creators and third parties to make assertions about information resources.</p>
|
|
|
|
|
|
<h4 id="DRrole">3.1.2 The Role of a Description Resource</h4>
|
|
<p>A Description Resource, DR, must be able to describe aspects of
|
|
a group of information resources using terms chosen from different vocabularies. Such
|
|
vocabularies might include, but are not limited to, those that describe a
|
|
resource's subject matter, its suitability for children, its conformance
|
|
with accessibility guidelines and/or Mobile Web Best Practice, its
|
|
scientific accuracy and the editorial policy applied to its creation.</p>
|
|
|
|
<h4 id="grouping">3.1.3 Grouping</h4>
|
|
<p>It must be possible to define sets of resources and have DRs refer to those sets. For example, DRs can refer to all the
|
|
pages of a Web site, defined sections of a Web site, or all resources on multiple Web sites.</p>
|
|
|
|
|
|
<h4 id="compo">3.1.4 Composite Assertions</h4>
|
|
<p>DRs must support a single composite assertion taking the place of a number of other assertions. For example,
|
|
WAI AAA can be defined as WAI AA [<a href="#wai">WAI</a>] plus a series of detailed descriptors. Other
|
|
examples include <a href="#mok">mobileOK</a> and age-based classifications from a named authority.</p>
|
|
|
|
|
|
|
|
<h4 id="multiDRs">3.1.5 Multiple DRs</h4>
|
|
<p>It must be possible for more than one DR to refer to the same resource or group of resources.</p>
|
|
<p>Furthermore, it must be possible for a resource to refer to one or more DRs. It follows that there must be a linking mechanism between content and
|
|
descriptions.</p>
|
|
|
|
|
|
<h4 id="independent">3.1.6 Independence</h4>
|
|
<p>DRs must be able to point to any resource(s) independently of those resources.</p>
|
|
|
|
<h4 id="attribution">3.1.7 Attribution</h4>
|
|
<p>A DR must include assertions about itself using appropriate vocabularies. As a minimum, a DR must have data describing who
|
|
created it. Good practice would be to declare its period of validity, how to provide feedback about it, who last verified it and when etc.</p>
|
|
|
|
<h4 id="refer">3.1.8 Reference</h4>
|
|
<p>It must be possible for a DR to refer to other DRs or other sources of data that support the claims and assertions made.</p>
|
|
|
|
<h4 id="stanVocab">3.1.9 Standard Vocabularies</h4>
|
|
<p>There must be standard vocabularies for assertions about DRs.</p>
|
|
|
|
<h4 id="identity">3.1.10 Identity</h4>
|
|
<p>DRs, their components and individual assertions should have unique and unambiguous identifiers.</p>
|
|
|
|
<h4 id="unambiguous">3.1.11 Unambiguous</h4>
|
|
<p>Assertions within DRs should be made using descriptors that themselves have unique identifiers.</p>
|
|
|
|
|
|
<h3 id="comWork">3.2 Fitting in with Commercial or Other Large Scale Workflows</h3>
|
|
|
|
<h4 id="authentic">3.2.1 Authentication</h4>
|
|
<p>It must be possible for DRs to be authenticated.</p>
|
|
|
|
<h4 id="edit">3.2.2 Separation of Description and Resource</h4>
|
|
<p>It must be possible to create and edit DRs without modifying the resources they describe</p>
|
|
|
|
<h4 id="default">3.2.3 Default Description</h4>
|
|
<p>It must be possible to identify a default DR for a group of resources and provide an override at specific locations within the scope of the DR.</p>
|
|
|
|
<h4 id="testresult">3.2.4 Link to Test Results</h4>
|
|
<p>It must be possible to link DRs with specific test results that support the claims made.</p>
|
|
|
|
<h4 id="bulk">3.2.5 Bulk Data Transfer</h4>
|
|
<p>It must be possible for a data provider to make its repository of Description Resources available as a bulk download.</p>
|
|
|
|
<h3 id="reqEnc">3.3 DRs for Humans and Machines</h3>
|
|
|
|
<h4 id="machineRead">3.3.1 Machine-Readable</h4>
|
|
<p>It must be possible to express DRs in a machine-readable way.</p>
|
|
|
|
<h4 id="formal">3.3.2 Formal Grammar</h4>
|
|
<p>The machine-readable form of a DR must be defined by a formal grammar.</p>
|
|
|
|
<h4 id="human">3.3.3 Human Readable</h4>
|
|
<p>DRs must provide support for a human readable summary of the claims it contains.</p>
|
|
|
|
<h4 id="images">3.3.4 Images</h4>
|
|
<p>It must be possible to associate DRs with images.</p>
|
|
|
|
<h4 id="tags">3.3.5 User-Generated Tags</h4>
|
|
<p>It must be possible to encode user-generated tags in DRs.</p>
|
|
|
|
<!-- end requirements -->
|
|
|
|
<h2 id="ack">4 Acknowledgements</h2>
|
|
<p>The editor acknowledges the contributions of members of the <a href="http://www.w3.org/2007/powder/">POWDER WG</a>
|
|
and the <a href="http://www.w3.org/2005/Incubator/wcl/">WCL-XG</a> in compiling this document. In particular
|
|
Dan Appelquist, Dave Rooks, Pantelis Nasikas, Kjetil Kjernsmo, Kai-Dietrich Scheppe, Kendall Clark, Jo Rabin, Kevin Smith,
|
|
Alan Chuter, Zeph Harben, Liddy Nevile and Diana Pentecost.</p>
|
|
|
|
<h2 id="refs">5 References</h2>
|
|
<dl>
|
|
<dt><a name="mok" id="mok">MOK</a></dt>
|
|
<dd>MobileOK is a trustmark that can be applied to online content that meets criteria derived from the <a href="http://www.w3.org/TR/mobile-bp/#iddiv1126789288">Mobile Web Best Practices</a></dd>
|
|
<dt><a name="wai" id="wai">WAI</a></dt>
|
|
<dd>WAI Conformance is defined in the <a href="http://www.w3.org/TR/WAI-WEBCONTENT/">W3C Web Content Accessibility Guidelines</a></dd>
|
|
<dt><a name="earl" id="earl">EARL</a></dt>
|
|
<dd><a href="http://www.w3.org/WAI/intro/earl.php" title="Evaluation and Report Language">Evaluation and Report Language</a></dd>
|
|
<dt><a name="afa" id="afa">AFA</a></dt>
|
|
<dd><a href="http://www.imsglobal.org/accessibility/" title="more information on the IMS Gobal website">IMS AccessForAll Meta-data Specification</a></dd>
|
|
</dl>
|
|
<h2 id="changes">6 Change Log</h2>
|
|
<h3 id="rev1">6.1 Changes between <a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070525/">first</a>
|
|
and <a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070831/">second</a> published versions</h3>
|
|
<p>
|
|
The following changes have been made since the <a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070525/">previous version</a> of this document was published.
|
|
</p>
|
|
<ul>
|
|
<li>updated <a href="#status">Status of this Document</a> to reflect that this is an updated version</li>
|
|
<li>Removed “URI-applicable” from step 3 of the <a href="#generic">Generic Profile Matching Use Case</a> section</li>
|
|
<li>Replaced the word “URI” with “content” in step 4b of <a href="#generic">Generic Profile Matching Use Case</a> section</li>
|
|
<li>Added paragraph following step 5b of <a href="#generic">Generic Profile Matching Use Case</a> section</li>
|
|
<li>Renamed Child Protection use case to Child Protection A in section Child Protection A section</li>
|
|
<li>Added Child Protection use case B in section Child Protection B section</li>
|
|
<li>Added further detail to Privileged Content use case in 4th bullet point</li>
|
|
<li>Added note about re-ordering from previous version in section <a href="#semantics">Semantic Annotation</a></li>
|
|
<li>Added <a href="#semsearch">Semantic Search</a> section</li>
|
|
<li>Changed example used in <a href="#tagsrus">User-Defined Tags</a> section</li>
|
|
<li>Clarified that a DR may refer to either a DR or another source of data in the <a href="#refer">Reference</a> section</li>
|
|
</ul>
|
|
|
|
<h3 id="rev2">6.2 Changes between <a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070831/">previous</a> and this version</h3>
|
|
<ul>
|
|
<li>Updated status section, updated change log</li>
|
|
<li>Replaced <a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070831/#scenario4">original</a> Web Accessibility use case
|
|
with an <a href="#accessA">amended version</a> plus a <a href="#accessB">new variant</a> (sections 2.1.5 and 2.1.6). Subsequent sub sections of section 2.1 re-numbered.</li>
|
|
<li>IDs for each sub use case in section 2.1 amended</li>
|
|
<li>Original requirement <a href="http://www.w3.org/TR/2007/NOTE-powder-use-cases-20070831/#compact">3.3.4 Compact</a> and
|
|
references to it removed following <a href="http://lists.w3.org/Archives/Public/public-powderwg/2007Jun/0001.html">comment received</a>. Subsequent requirements renumbered accordingly.</li>
|
|
<li>Corrected erroneous anchor in Contents for section 3.3</li>
|
|
<li>Two names added to acknowledgements</li>
|
|
<li>Typos corrected</li>
|
|
</ul>
|
|
|
|
|
|
</body>
|
|
</html>
|