index.html 48.1 KB

Raw Blame History Permalink

<!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> &copy; 2007
<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</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 &quot;fictional&quot; 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 &quot;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.&quot;</p>

<p>The editor is responsible for adding two further descriptions:</p>
<ol>
  <li>Key words (tags). For example: &quot;News, Middle East&quot;, &quot;Lifestyle, DIY, Decorating&quot;, &quot;Entertainment, Celebrity Gossip.&quot;</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 &#8220;URI-applicable&#8221; from step 3 of the <a href="#generic">Generic Profile Matching Use Case</a> section</li>
<li>Replaced the word &#8220;URI&#8221; with &#8220;content&#8221; 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>