Use Cases covered?

I thought it might be a good exercise to go through the requirements 
listed in the use cases document we created way back [1] and provide 
evidence that we WG really has addressed the requirements. So here goes.

3.1.1 Making Assertions
It must be possible for both resource creators and third parties to make 
assertions about information resources.

Covered. Anyone can create a DR about any group of resources.


3.1.2 The Role of a Description Resource

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.

Covered. Any descriptive vocabulary may be used (i.e. any RDF 
vocabulary), as can free-text tags.


3.1.3 Grouping

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.

Covered. We have a whole document about this 
(http://www.w3.org/TR/2008/WD-powder-grouping-20081114/)


3.1.4 Composite Assertions

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 [WAI] plus a series of detailed descriptors. Other examples include 
mobileOK and age-based classifications from a named authority.

Covered. DRs may assert that a member of an IRI set is rdf:type ... and 
that class may itself have properties such as WCAG check points etc. The 
Mobile Web BP decided they didn't want to give granular descriptions of 
mobileOK conformance (but others may do so).


3.1.5 Multiple DRs

It must be possible for more than one DR to refer to the same resource 
or group of resources.

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.

Covered. See section 4 of the DR doc 
(http://www.w3.org/TR/2008/WD-powder-dr-20081114/#assoc)


3.1.6 Independence

DRs must be able to point to any resource(s) independently of those 
resources.

Covered. The discussion of the POWDER Processor makes it clear that a PP 
may be a source of reference for descriptions without any need for a 
link from the described reosurce 
(http://www.w3.org/TR/2008/WD-powder-dr-20081114/#powderprocessor).


3.1.7 Attribution

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.

Covered. The issuedby element is mandatory for all POWDER documents.

3.1.8 Reference

It must be possible for a DR to refer to other DRs or other sources of 
data that support the claims and assertions made.

Covered. The certifiedby and supportedby elements achieve this.



3.1.9 Standard Vocabularies

There must be standard vocabularies for assertions about DRs.

Covered. Where possible, we've used DC, FOAF etc. We have minted our own 
terms where necessary (such as validfrom).



3.1.10 Identity

DRs, their components and individual assertions should have unique and 
unambiguous identifiers.

Covered, in that POWDER documents have a URI of their own. However, 
individual DRs will often not have an ID of their own.

3.1.11 Unambiguous

Assertions within DRs should be made using descriptors that themselves 
have unique identifiers.

Covered. Any RDF vocabulary has identifiers for the terms etc.

3.2.1 Authentication

It must be possible for DRs to be authenticated.

It is possible - however, POWDER does not define a single 'must use' 
method for this. A range of suggestions are given.



3.2.2 Separation of Description and Resource

It must be possible to create and edit DRs without modifying the 
resources they describe

POWDER documents are separate from anything they describe.



3.2.3 Default Description

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.

Covered. This is achieved through ordered lists 
(http://www.w3.org/TR/2008/WD-powder-dr-20081114/#olDR)



3.2.4 Link to Test Results

It must be possible to link DRs with specific test results that support 
the claims made.

Covered - by using the supportedby element.


3.2.5 Bulk Data Transfer

It must be possible for a data provider to make its repository of 
Description Resources available as a bulk download.

Covered. Although POWDER does not specify how this may/should be be 
done. Large scare POWDER suppliers are encouraged to set up a triple 
store with a SPARQL endpoint etc.



3.3.1 Machine-Readable

It must be possible to express DRs in a machine-readable way.

Covered. In XML, RDF/OWL etc.


3.3.2 Formal Grammar

The machine-readable form of a DR must be defined by a formal grammar.

We have an XML schema (and a Relax NG schema on the way at the time of 
writing).


3.3.3 Human Readable

DRs must provide support for a human readable summary of the claims it 
contains.

Covered by the displaytext element.



3.3.4 Images

It must be possible to associate DRs with images.

Covered by the displayicon element.



3.3.5 User-Generated Tags

It must be possible to encode user-generated tags in DRs.

It is!


[1] http://www.w3.org/TR/powder-use-cases/#reqs



-- 
Phil Archer
w. http://philarcher.org/

Received on Monday, 9 February 2009 15:37:49 UTC