Table of Contents

• 1 Introduction
• 1.1 Participants
• 2 Detailed requirements
• 3 The abstract model of content labels
• 3.1 Grouping resources
• 3.1.1 Group membership defined by URI
• 3.1.1 Group membership defined by property
• 3.2 Linking resources to cLabels
• 4 The WCL vocabulary
• 5 Content label scope and semantics
• 6 System architecture
• 7 Encodings
• 8 Glossary
• 9 Links and References
• 10 Acknowledgements
• Appendix The original use cases and high level requirements

1 Introduction

The group was chartered to look for "... a way of making any number of assertions about a resource or group of resources." Furthermore "... those assertions should be testable in some way through automated means."

It quickly became apparent that the terminology used in that summation needed to be refined and clarified, however it was possible to construct a set of use cases that amply demonstrate the aims in more detail. A set of high level requirements was derived from the use cases that were then formalized for this report.

Throughout the Incubator Activity, decisions have been taken via consensus during regular telephone conferences and a face to face meeting. Discussion of the requirements and what can and cannot be inferred from a content label proving the most exhaustive. Based on that discussion it is possible to reformulate the output of the Web Content Labels Incubator Activity as:

"A way of making any number of assertions, using any number of vocabularies, about a resource or group of resources. The assertions are open to automatic authentication based on available data such as who made the assertions and when."

We have deliberately taken a very broad approach so that it is possible for both the resource creator and third parties to make assertions about all kinds of things, with no architectural limits on the kind of thing they are making claims about. For example, medical content labeling applications might be concerned with properties of the agencies and processes that produce Web content (e.g.. companies, people, and their credentials). By contrast, a mobile content labeling application might be more concerned with different kinds of information resource and their particular (and varying) representations as streams of bytes. That said, we have focused on Web resources rather than trying to define a universal labeling system for objects.

The following report sets out the detailed requirements derived from the original use cases and high level requirements (which are presented in the appendix). An abstract model; has been developed that encapsulates the issues discussed and discovered during the XG's work. Comments are also made on possible system architectures that can utilize content labels as well as a detailed glossary.

The Incubator Group is now seeking a charter to reform as a full Working Group on the W3C Recommendation Track. It is believed that the work done to date is substantial and has attracted significant support but there are some outstanding issues that need to be addressed:

1. The group believes that RDF is the most appropriate technology for encoding content labels, however, this can be done in different ways. Further, we recognize that there are alternative approaches and wish to explore those as well. The expectation is that, if a WG is formed, it will produce a normative RDF model along with sketches showing how the abstract model might be encoded using other technologies. Further notes are included on this aspect in the body of the report.
2. What advantages, if any, do content labels offer over PICS? What, if any, are the disadvantages? This issue has both policy and technology aspects that need to be given full consideration before the withdrawal of PICS as a Recommendation can be considered.

Carrying out these detailed and critical aspects of the WCL group's work on the Recommendation Track will ensure full scrutiny by the wider community, and enable greater interplay with, for example, the Mobile Web Best Practices Group [MWBP], The Rule Interchange Format WG [RIF] and the Evaluation and Repair Tools Working Group [ERT].

Throughout this report, we use cLabel as a short-form of content label.

2 Detailed requirements

Based on the use cases and the original high level requirements that were derived from them, a set of more detailed requirements was established. These have been loosely categorized for easier comprehension and care has been taken to use relevant terms as defined in the glossary.

Fundementals

1. It must be possible for both resource creators and third parties to make assertions about information resources
2. The assertions must be able to be expressed in terms chosen from different vocabularies. Such vocabularies might include, but are not limited to, those that describe a resource's 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. Existing vocabularies are preferred over newly defined ones
3. It must be possible to group information resources and have cLabels refer to that group of resources. For example, cLabels can refer to all the pages of a Web site, defined sections of a Web site, or all resources on multiple Web sites.
4. A cLabel must be the expression of assertions made only by the party that created it. It must not be necessary for assertions made by multiple parties to be included in a single cLabel.
5. cLabels 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 plus a series of detailed descriptors. Other examples include mobileOK and age-based classifications.
6. More than one cLabel can refer to the same resource or group of resources. Since conflicting labels are therefore permissible, the choice of which label(s) to trust lies with the end user.
7. It must be possible for a resource to refer to one or more cLabels. It follows that there must be a linking mechanism between content and labels.
8. cLabels must be able to point to any resource(s) independently of those resources.
9. It must be possible to make assertions about cLabels using appropriate vocabularies. For example, a cLabel can have metadata describing who created it, what its period of validity is, how to provide feedback about it, a who last verified it and when.
10. It must be possible for a cLabel to be associated with its metadata and vice versa.
11. cLabels, metadata statements and individual assertions should have unique and unambiguous identifiers.

Fitting in with commercial or other large scale workflows

1. It must be possible for cLabels and cLabel metadata to be authenticated.
2. It must be possible to create and edit cLabels without modifying the resources they describe.
3. It must be possible to identify a default cLabel for a group of resources and specify situations in which another cLabel overrides the default. i.e. it must be possible to say "everything on example.com is described by cLabel₁ except resources in section A for which cLabel₂ applies."

Encoding labels for humans and machines

1. It must be possible to express cLabels and cLabel metadata in a machine readable way.
2. The machine readable form of a cLabel and cLabel metadata must be defined by a formal grammar
3. cLabels must provide support for a human readable summary of the claims it contains
4. It must be possible to express cLabels and cLabel metadata in a compact form
5. Vocabularies and authentication data must be formally encoded and support URI references

3 The abstract model of content labels

The requirements in the previous section can be expressed in a more programmatic way as follows. A Content Label (cLabel) can carry a variety statements such as:

cLabel {
  That resource R has the property P1 is true
  That resource R has Property P2 that has value V
  That resource R meets WCAG 1.0 AA is true
  That resource R was created in accordance with satisfactory procedures is 
true
}

Where R may be either a single resource identified by its own URI or a group of resources. Membership of a group R may be defined either by pattern matching based on URIs or with reference to specified properties of resources. The latter case includes, but is not limited to, properties such as creation date, ISAN number etc.

Further, it is necessary to be able to make statements like:

metadata {
  cLabel was created by $organization
  {
    has the e-mail address mail@organization.org
    has a homepage at $url
    has a feedback page at $URL
    ...
  }
  cLabel was created on $date
  cLabel was last reviewed by $person
}

Finally, it is necessary to be able to send a real-time request to $organization seeking automatic confirmation that it was responsible for creating the cLabel, i.e. authenticating the label and the claims made. This amounts to making statements like:

authentication {
metadata and cLabel verified by $organization  
  { has email sss ... }
verified on $date}

Such a discussion leads us to the abstract model of cLabels as described in figure 3.1 and the following text.

Figure 3.1 Schematic diagram of the abstratc model for content labels.

A vocabulary collects together a number of related properties or aspects of a resource that may be useful in saying things about that resource. Those properties or aspects are identified by terms of the vocabulary. Each term is identified by a descriptor and may have constraints placed on the values that are appropriate for use with that descriptor. Further information may be associated with a descriptor such as test suites for checking value assignment. The scope of use of the vocabulary as a whole as well as the scope of individual terms may be noted. It is also possible to assign vocabulary terms to a thematically-defined sub-group known as a category.

An expression is a statement in respect of a resource that the aspect of the resource denoted by a descriptor chosen from a specific vocabulary has a certain value. A valid expression makes reference to a vocabulary term that exists and whose chosen value conforms to the constraints specified in the vocabulary.

An assertion is a specific type of expression which is said to be true by the entity that makes it.

A claim is a specific type of assertion, whose veracity can be ascertained, either by reference to the test conditions described in the relevant vocabulary term, or by observation and interpretation of the meaning of the term as given in its scope notes.

A label is an abstraction, which is a specific type of resource and contains assertions and claims in respect of a group of resources.

A cLabel is a specific type of label that has assertions describing the circumstances of its creation and information about the entity that created it. Assertions may be made about a cLabel in a certificate.

A cLabel for a given resource is identified by processing a Ruleset. This is associated with one or more cLabels by direct inclusion of the cLabel within the Ruleset or by linkage. A Ruleset MAY define the scope of the cLabels it is associated with and MAY define a default cLabel for the resources within its scope. A Ruleset MAY define rules for applying a cLabel (other than the default, where defined) to a group of resources within its scope. If the scope is not defined explicitly, then processors MUST take the scope of the cLabels to be the set of resources that links to the Ruleset or individual cLabels.

A cLabel SHOULD include a short text summary of the assertions and claims in a form suitable for display to end users.

The processing model that follows from this is shown in figure 3.2.

Figure 3.2 Diagrammatic representation of the WCL processing model.

For a given resource, processing a Ruleset MUST return either 0 or 1 cLabels.

Multiple cLabels may be applied to a single resource either by including one cLabel within another, or by linking a resource to multiple Rulesets.

4. The WCL vocabulary

The abstract model presented in the previous section implies or calls directly for a number of vocabulary terms. For convenience, these are given below under a number of category headings.

4.1 Terms to aid the creation of a descriptive vocabulary

Category

Defined in the glossary

Descriptor

Defined in the glossary

4.2 Terms that support the structure of a cLabel

These can be used in addition to whatever descriptive vocabulary or vocabularies are used.

cLabel

Defined in the glossary

Ruleset

Defined in the glossary

Scope

Defined in the glossary

Default Label

Defined in the glossary

Rule

Defined in the glossary

Summary

Defined in the glossary

Include

Allows one cLabel to include another. A semantically more accurate term would be "is also described by" but "include" is more intuitive

Classification

A link to a classification that MAY be further decomposed into atomic statements.

4.3 Terms for describing aspects such as who created the labels? When etc.

Last reviewed

The date on which the labeled resources were last reviewed. This is a specialization of the Dublin Core Date element and SHOULD be expressed in the W3C date & time format [W3CDTF].

Reviewed by

The individual who reviewed the resource and verified the claims made in the cLabel.

Approved

The individual who checked the reviewer's verification of the claims made in the label.

Valid until

The date until which the cLabel or certificate SHOULD be treated as valid. This is a specialization of the Dublin Core Date element and SHOULD be expressed in the W3C date & time format [W3CDTF].

Withdrawn

The date on which the cLabel creator or certification authority withdrew the cLabel or certificate. This is a specialization of the Dublin Core Date element and SHOULD be expressed in the W3C date & time format [W3CDTF].

Test Result

A link to a test results, such as an EARL assertion.

NB: The Dublin Core Term Issued SHOULD be used to declare when a cLabel or certificate was issued (the DC Term 'Created' is more suited as a descriptor for when the labeled resource was created). As with the WCL descriptors 'Last reviewed', 'Valid until' and 'Wthdrawn', DC Terms 'Issued' is a specialization of the Dublin Core Date element and SHOULD be expressed in the W3C date & time format [W3CDTF].

4.4 Terms to describe the labeling authority

Any amount of such data can usefully be provided using existing vocabularies such as FOAF, Dublin Core and vCard, and we have listed those that an LA can reasonably be expected to provide. We have further defined a series of terms that SHOULD be provided by LAs (where applicable) and SHOULD be utilized by clients.

4.4.1 Terms from FOAF

Organization

Use this as the placeholder for terms describing the organization or individual that created the labels

name

Use this to give the full name of the LA

homepage

The URI of the homepage of the LA

mbox

The LA's primary e-mail address

4.4.2 Terms from Dublin Core

Description

A short description of the LA and its work. For WCL purposes, this SHOULD be limited to 400 characters, Use a term such as RDF's See Also to provide a more detailed description.

Subject

A brief text description of the subject(s) covered by the labels. Typically this will be in the form of keywords

4.4.3 Terms from vCard

Address (ADR)

vCard defines the following terms for postal addresses.

• Street
• Locality
• Post Code (Pcode)
• Country

Voice

The (voice) phone number

Fax

The LA's fax number (if applicable)

4.4.4 WCL-defined terms

Shortname

The acronym or short name for the LA

Authority for

A namespace of for a vocabulary for which the label creator is an authority. The element can be occur any number of times to declare multiple vocabulary namespaces

icon

A 16 x 16 pixel logo for the LA. This must be in either gif or png format

Public PGP key

The LA's public Key (if applicable)

Public digital certificate

The LA's public digital certificate (if applicable)

The 'Authority for' term is provided because although it is usual for an LA to issue labels from its own vocabulary, it may wish to include other vocabularies as well. Furthermore, additional vocabularies may be included in cLabels by the content provider or others and this term enables an LA to specify exactly for which descriptions it is and is not responsible.

5 Content label semantics

As defined in the glossary, a content label is a set of assertions made using one or more vocabularies to describe a resource or group of resources. In turn, an assertion is an expression that is claimed to be true.

It follows that a cLabel SHOULD be taken as the expression of an opinion held by an individual, organization or automaton at a particular point in time. It cannot be taken as proof, in a logical sense, that one or more of the assertions expressed in the cLabel is true as an empirical fact.

Furthermore, the content label is limited by the vocabularies used. That is, clients MUST NOT make any inference about a resource or group or resources based on the absence of any descriptor. To give a simple example of this. if a content label describes a resource solely in terms of its color, no inference can be drawn about its shape.

6 System architecture

Content Labels can be used in a variety of systems and it is not the XG's intention to define a single architecture. However. we do recommend that the following elements are present in any complete system.

• Content Labels served either from the labeled site or from a labeling authority
• Metadata about a given cLabel giving detail of who created it, when, its period of validity and so on (see WCL Vocabulary)
• An authentication route through which a client can make an automated request to the LA
• An API through which an LA makes available labels for a given resource
• An API though which an LA makes all its labels available as a single download

These elements can be combined in any number of ways, some of which are highlighted in the following sections.

6.1 The Quatro model

The Quatro project, co-funded by the European Union [SIP], combines the elements listed above into a basic architecture with 3 variations. In all cases, content is linked to the cLabel and the cLabelMetadata points to the Labeling Authority.

It should be noted that although every resource must be linked to the cLabel in this model, a client seeking that cLabel will only have to retrieve it once. After the data has been retrieved, whether from the labeled site or the LA database, no further network request is required for as long as the cLabel is held in cache by the client.

6.1.1 Onsite labels that may be edited

Fig 6.1 Diagrammatic representation of simple architecture in which data about resources is held on the same server as those resources. The cLabelMetadata provides a link to the LA which is able to authenticate the data.

Labels are hosted near to the resources they describe (typically the same website) and the LA's database supplies simple authentication. Since in this model content providers are allowed to edit their label to reflect changes in their content, the cLabel may not be exactly the same as the one issued. However the LA is able to assert that it trusts the content provider to make such changes faithfully.

6.1.2 Onsite labels that may not be edited

Fig 5.2 Diagrammatic representation of simple architecture in which data about resources is held on the same server as those resources. A hash of this data is sent to the LA (identified in the cLabelMetadata) which is then is able to authenticate the data by comparing it with the hash stored in its database.

This is similar to the previous model but differs in the important respect that the LA does not allow content providers to edit their cLabels. Therefore a hash of the label can be checked against data held by the LA to ensure label integrity.

6.1.3 cLabels delivered directly from the LA database

Fig 6.3 Diagrammatic representation of architecture in which all cLabel data is held by the Labeling Authority.

In this architecture, cLabels are delivered directly from the LA's database. Therefore there is no possibility for the label to be modified by the content provider and the source of the labels carries greater inherent trust. On the downside, this model places greater demands on the server infrastructure, system integration and bandwidth usage by the LA.

7 Encodings

As noted throughout this report, the group is seeking a Working Group charter and believes that this is the correct forum in which to define a normative encoding for cLabels. It is anticipated that the primary encoding will be in RDF but that alternatives will be considered. For example, extensions for RSS and ATOM to allow a default cLabel to be declared at the channel/feed level with overriding cLabels at item/entry level.

Several XG members have experience of working with a system that has not been fully standardized known as RDF Content Labels [RDF-CL]. Until and if a WG charter is secured, this method remains adequate, practical and meets a great many of the use cases and requirements set out by the XG. However, it is not a full encoding of the WCL abstract model, differing in the following respects:

1. RDF-CL seeks to limit the number of labels that can apply to a given resource to 1 (WCL allows any number).
2. RDF-CL has a much more limited mechanism for defining groups of resources than is set out in this report and its companion document.
3. RDF-CL offers parallel systems for providing labels, classifications and management information (creator, rights holder etc.). This has the potential to cause unnecessary confusion.
4. RDF-CL has some native support for labeling of movies and video games, but seeks to restrict the way this is done to a particular paradigm that is relatively inflexible. The issues are probably better handled through extensions to the WCL model.

Work has been done within the XG looking at how RDF-CL, and therefore a future RDF encoding of WCL, might be used in other circumstances.

For example, could content labels be developed as a microformat? Possibly, however, the lack of namespaces leaves open the possibility of confusion over common words and terms being used to describe content in different vocabularies/schemata.

RDFa has real potential since it lets us annotate XHTML documents with classes and properties from RDF vocabularies using namespaces and Qnames as in any xml document. There are two options to describe content with RDFa. Either use RDFa annotations in the XHTML document/resource as class names and inject namespaces as needed, or link from the document/resource to another XHTML document that contains the human representation of the labels (readable using any browser) and annotate the XHTML elements (div , span) with RDF class names and properties. In both cases GRDDL could be used to transform the XHTML instance to RDF that could be then queried using SPARQL. The first case covers the issues of defining groups.

The group also considered whether it would be feasible to treat an RDF-CL instance as XML (assuming the RDF were serialized in XML). This is certainly possible in that XSLT transforms were successfully carried out. However, it was a very fragile system that depended on the data being presented according to a particular structure. It is not suitable as a long term strategy.

If successful in securing a WG charter, WCL would seek to:

1. Produce a normative encoding of the WCL abstract model in RDF. This would, of course, take into account any changes made to the abstract model made by the WG itself. The discussion would be likely to include sample SPARQL queries etc. and guidance on making data available for property-based resource grouping.
2. Show examples of cLabels encoded using RDFa.
3. At least a sketch for encoding cLabels entirely in XML.

8 Glossary

The following terms are used throughout this report. Definitions have been collected from W3C glossaries where possible and provided a priori where necessary.

Assertion Any expression which is claimed to be true. [W3C definition source]

Authenticate, (n. authentication) To provide evidence that assertions made in a cLabel, cLabel metadata or a certificate are the authentic view of the entity that created them. Such evidence will typically be acquired by direct communication with that entity.

Category A thematically-related sub-group of terms within a vocabulary.

Certificate A cLabel containing assertions about the veracity of claims made in another cLabel.

Certification The process of verification of claims and the creation of a certificate.

Claim An assertion whose truth can be assessed by an independent party.

Content Label, cLabel A set of assertions made using one or more vocabularies to describe a resource or group of resources.

Content provider An entity (individual, organization or automaton) that provides resources in response to requests, whether or not the resource was created by that entity.

Default cLabel The cLabel that should be applied to any resource within the scope of a Ruleset in the absence of a rule to the contrary.

Descriptor An aspect of a resource about which it is possible to make assertions. For example, color, size and shape. A descriptor becomes a vocabulary term when it is associated with possible values.

Expression An instance of a vocabulary term and its value.

Information resource A resource which has the property that all of its essential characteristics can be conveyed in a message. [W3C definition source]

Labeling Authority (acronym LA) An organization that provides infrastructure for the generation and authentication of content labels.

Resource Anything that might be identified by a URI. [W3C definition source]

Resource creator The individual or organization that created the resource.

Rule In the specific context of WCL, a rule defines a group of resources and a cLabel that applies to all resources in that group.

Ruleset A block of data that can be processed to determine which of a set of cLabels, if any, should be applied to a given resource.

Schema (pl., schemata) A document that describes an XML or RDF vocabulary. Any document which describes, in a formal way, a language or parameters of a language.[ W3C definition source]

Scope The set to which a resource must belong if any cLabel included within or linked from a Ruleset is to be applied.

Summary A short summary of the description provided of the resource by the cLabel, suitable for display to end users.

Trustmark A sign (machine processable and/or human perceivable) that a certificate has been issued.

Valid A cLabel is valid if it has an associated schema or schemata and if it complies with the constraints expressed therein. [Adapted W3C definition]

Verification The process of assessing the correctness of claims.

Vocabulary A collection of vocabulary terms, usually linked to a document that defines the precise meaning of the descriptors and the domain in which the vocabulary is expected to be used. When associated with a schema, attributes are expressed as URI references. [This definition is an amalgam of those provided in Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0 and OWL Web Ontology Language Guide.]

Vocabulary term An attribute that can describe one or more resources using a defined set of values or data type. Attributes may be expressed as a URI reference. See also descriptor and expression.

Well-formed Syntactically legal. [W3C definition source]

8 Links and references

Dublin Core

http://dublincore.org/

FOAF

http://www.foaf-project.org/

EARL

Evaluation And Report Language

GROUP

URI Pattern Matching for Groups of Resources

Dublin Core Date

Defined in the Dublin Core Registry

W3CDTF

http://www.w3.org/TR/NOTE-datetime

vCard

IMC specification; W3C Note on encoding vCard in RDF/XML

PROFILE

The global structure of an HTML document: Meta data profiles

MNOTT

See Mark Nottingham's current work on Links HTTP Response Headers, for example Bringing Back the Link - With a Twist

RDF

http://www.w3.org/RDF

QUATRO

http://www.quatro-project.org/

SIP

http://europa.eu.int/saferinternet

RDF-CL

http://www.w3.org/2004/12/q/doc/content-labels-schema.htm

ATOM

http://www.atomenabled.org/developers/syndication/atom-format-spec.php

RDFa

http://www.w3.org/TR/xhtml-rdfa-primer/

GRDDL

Gleaning Resource Descriptions from Dialects of Languages

SPARQL

SPARQL Query Language for RDF

9 Acknowledgements

The editors acknowledge significant contributions from:

• Kal Ahmed, Techquila
• Dan Appelquist, Vodafone Group Services
• Dan Brickley
• Kendall Clark
• Kjetil Kjernsmo, Opera Software
• Pantelis Nasikas, Institute of Informatics & Telecommunications (IIT), NCSR
• Diana Pentecost, AOL Inc.
• Dave Rooks, Segala
• Kai-Dietrich Scheppe, T-Online

Appendix 1

The use cases

Use Case 1: Profile matching

The original use case given in the charter has been simplified by reducing the number of essential actors to three:

• CONTENT PROVIDER (metadata provider)
• PORTAL PROVIDER (metadata consumer)
• END USER

One can imagine a range of scenarios with very similar characteristics that amount to "sub-use cases."

Sub use case 1A: END USER discovers content appropriate to their device ["MobileOK"]

Fig 1. Diagrammatic version of sub-use case 1A.

1. END USER visits portal
2. END USER's device profile is extracted with reference to a separate metadata store
3. END USER searches for a topic of interest.
4. PORTAL PROVIDER matches END USER's device profile with contentprofiles provided by CONTENT PROVIDER.
5. PORTAL PROVIDER provides search results matching this topic.
6. PORTAL PROVIDER filters results based on the metadata encoded in the content with regard to the "mobile friendliness" of the content/presentation in question and the known properties of the device profile according to business rules.

Sub use-case B: END USER discovers content appropriate to their age-group ["Child Protection"]

Fig 2. Diagrammatic version of sub-use case 1B.

1. END USER visits portal
2. END USER's user profile is extracted from a repository, perhaps the portal's own.
3. END USER searches for a topic of interest.
4. PORTAL PROVIDER matches END USER's age with content profiles provided by CONTENT PROVIDER.
5. PORTAL PROVIDER provides search results matching this topic.
6. PORTAL PROVIDER filters results based on the metadata encoded in the content with regard to the "child friendliness" of the content/presentation in question and the known age of the user according to local business rules.

Use case 2: Trustmark Scheme operator to content portal

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.

The trustmark operator maintains a database of sites it has approved and makes this available in two ways:

First, the labelled site includes a link to the database. This can be achieved in a variety of ways such as an XHTML Link tag, an HTTP Response Header or even a digital watermark in an image. 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.

Secondly, the scheme operator makes the full database available in a single file for download and processing offline.

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.

Use case 3: Website to end-user

Mrs Chaplin teaches 7 year olds at her local school. An IT enthusiast, she makes her teaching materials available through her personal website. She adds metadata to her material that describes the subject matter and curriculum area. In order to gain wider trust in her work she submits her site for review by her local education authority and a trustmark scheme. Both reviewers offer Mrs Chaplin a digitally signed, machine-readable version of their trustmark that she can add to her site. She merges these into a single pool of metadata to which she adds content descriptors from a recognized vocabulary that declare the site to contain no sex or violent content. She adds her own digital signature to the metadata. The set of digital signatures allow user-agents to identify the origin of the various assertions made. As in use case 2, links from the content itself point to this metadata.

Since the metadata is on the website itself, user agents are unlikely to take the assertions made in the metadata at face value. Unlike the trustmark operator, the local authority does not operate a web service that can support the label, it does, however, digitally sign its labels and publishes its public key on its website. This can be used to verify that it is indeed the local education authority that issued the relevant data in the label.

Separately, a user-agent can interrogate the trustmark operator's database in real time to check whether Mrs Chaplin is authorized to make the assertions relevant to their namespace. Furthermore, the use of a recognized vocabulary for the content description means that a content analyser trained to work with that vocabulary can give a probabilistic assessment of the accuracy of the relevant data.

Taken together, these multiple sources of data can provide confidence in the quality of the content and the local authority trustmark which is not directly testable. The multiple data sources may be further supported by recognising that Mrs Chaplin's work is cited in many online bookmarks, blog entries and postings to education-related message boards.

Use Case 4: Rich Metadata for RSS/ATOM

Dave Cook's website 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.

The actual rating information comes from an online service operated by the relevant film classification board itself and is identified using a URL and human-readable text. The movie itself is identified by either an ISAN number or the relevant Internet Movie Database entry ID number. As with use case 2, trust is implicit given the source of the data, which is indicated by a link to Dave's site's policy.

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.

Use Case 5: MLK and the KKK

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.

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.

Use Case 6: Scalar Classification

A company named Advance Medical Inc. reviews medical literature on the Web based on a range of quality criteria such as effectiveness and research evidence. The criteria may be changed according to current scientific and professional developments. The review process leads to literature being classified as belonging to one of 5 levels as follows.

• Level A : clear evidence.
• Level B : supportive evidence.
• Level C : poor evidence.
• Level D : expert opinion with explicit critical appraisal.
• Level E : no evidence.

The company produces label data that declares the classification level value and provides a summary of each document. The label data is stored in a metadata repository which can be accessed via the Web.

M.D. Smith uses the label data in the repository to make decisions about heath care for specific clinical circumstances.