Note: This page is the personal reflection of the POWDER chair and not endorsed or reviewed by W3C or the participants of the POWDER Working Group participants.

History of the POWDER Working Group

The Protocol for Web Description Resources has a long history. Work on providing a framework for describing resources began with the birth of the W3C itself and lead to the original Platform for Internet Content Selection [PICS], published between 1996 and 1997. The system was greeted with enthusiasm by the browser manufacturers with both Microsoft and Netscape including PICS-based content filters in their products. Microsoft has retained its PICS-based filter in Internet Explorer since that time, updating it recently in IE7 to make use of ICRA's current system [CA].

Alongside the enthusiasm, however, there was also significant criticism from organisations and individuals who saw PICS as a threat to free speech on the Web. This was argued against at the time [DJW] and, since then, even some of the most outspoken advocates of free speech have accepted that voluntary self-labelling of content empowers end users without censoring the Web.

But see how any discussion of labels immediately gets tangled up with issues of free speech and filtering? This is highly regrettable and not a little frustrating. Labels can be used for purely positive reasons too. PICS was only ever seen as a child protection measure although it was designed to facilitate the labelling of online resources for all manner of reasons: "For example, a labelling vocabulary could indicate the literary quality of an item rather than its appropriateness for children… PICS labels could help in finding particularly desirable materials" [PICS-FAQ].

PICS offered a great deal but, for whatever reasons, was not given a chance to do so. I explored some of this in a workshop at WWW2004.

By 2004 it was clear that more work was necessary if we were to realise the goal of being able to identify online resources that met an abstract set of criteria. Coincident with this was a desire expressed in the European Parliament for an "Interoperable system, of quality labels." The idea being that Web users across Europe would be able to identify websites of "higher quality" although quality was not defined. To projects were established: first the ICRA Labelling Working Group [LWG] in June 2004, superseded in November that year by the Quatro Project. These initiatives lead to the creation of an RDF-based labelling platform, RDF Content Labels [RDF-CL].

As the experience of those using it has shown, RDF-CL "works"—however, it does have significant and important flaws that need to be addressed. Furthermore, it has not been put through any standardisation process, thus, the W3C Content Label Incubator Group [WCL-XG] was established in February 2006. As detailed in its final report, the WCL-XG developed the full data model for Content Labels and raised a number of questions. The participants were clear that the work necessary to resolve the open questions and realise the data model in a working system should properly be conducted in a W3C Working Group.

While negotiations with W3C Team were under way for what would become POWDER, work didn't come to a complete stop. There were two face to face meetings held by XG members in readiness for the working group, the first of which was held at Vodafone's London offices (where, incidentally, is where much of the RDF-CL work was done originally).

That meeting focussed on preparing the message about POWDER, in particular to ensure that the working group charter received widely based support. Some time was also spent discussing whether resources should be grouped using an XML or RDF-based syntax. There was no clear resolution on this except to note that this remains an open question with no preconceptions about what the eventual answer may be.

The second post-XG final report face to face meeting was held at MIT in January 2007 and discussed more detail. Since the minutes of the meetings on the 25 and 26 January are publicly available [MIN] there is no need to give a blow by blow account here. However, I will highlight a couple of things. The group was pleased to welcome observers, particularly from the accessibility initiative and semantic web.

The name POWDER (Protocol for Web Description Resources) is designed to make two things clear:

1. That the aim is to provide descriptions. There is no constraint or even hint in the title of how such descriptions should be used. They should be seen as an aid to discovery, an indication of trust or quality, an expression of an opinion. Description Resources certainly should not be seen as an aid to filtering or, its pejorative cousin, censorship.
2. The descriptions are themselves resources. They can be authenticated, or rejected, certified, commented upon and tagged just like any other online resource.

Resource Grouping is the big issue for POWDER. Matching URIs against Regular Expressions is an easy way to create a group if URIs follow a pattern but this is not always the case. Conversely, there's no benefit in requiring group members to be enumerated. A group of resources cannot be the subject of a test—that requires a specific resource be tested—but a test result can be used as evidence for a claim made in respect of a group of resources.

We also discussed link relationship types. Do we need a specific link rel="POWDER"? And do we need to hint at what vocabularies might be used in the description available in the DR? There are arguments for and against:

For:
If you are interested in, say, mobileOK, you may not want to follow a link to a POWDER resource that describes the content using the ICRA vocabulary; thus rel="POWDER mobileOK" is useful.

Against:
If you're a content provider and you create a POWDER resource for mobileOK and include link rel="POWDER mobileOK" tags in your content and later decide to add ICRA descriptors, you then have to go back and update your link tags.

It was claimed during the meeting that the HTML profile can be used to define any new relationship type and I want to believe it—GRDDL uses it for instance but I remain sceptical. I've written about this since [IETF]. This remains an open issue for the WG to resolve.

The discussion turned to the resource grouping issue once more with emphasis on creating a package of Description Resources to cover a particular set of resources. As a result of the discussion we can offer a strawman for a Description Resource and a package of such resources.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:wdr="http://www.w3.org/2007/02/powder-ns#"
         xmlns:foaf="http://xmlns.com/foaf/0.1/"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:dcterms="http://purl.org/dc/terms/"
         xmlns:ex="http://example.org/vocabulary#">

  <wdr:Package rdf:ID="package">
    <wdr:hasPackageScope rdf:resource="#primaryScope" />  <!-- use owl:cardinality to require exactly 1 of these -->

    <wdr:hasDRs rdf:parseType="Collection">  <!-- collection construct is closed, so there are no more members -->
      <rdf:Description rdf:about="#dr_1" />
      <rdf:Description rdf:about="#dr_2" />
      <rdf:Description rdf:about="#dr_3" />
    </wdr:hasDRs>
  </wdr:Package>

  <wdr:Scope rdf:ID="primaryScope">
    <wdr:hasHost>example.org</wdr:hasHost>
  </wdr:Scope>

  <wdr:WDR rdf:ID="dr_1">
    <foaf:maker rdf:resource="http://labellingauthority.example.org/foaf.rdf#me" />
    <dcterms:issued>2006-09-01</dcterms:issued>
    <wdr:validUntil>2007-09-01</wdr:validUntil> 
    <wdr:hasScope> <!-- use owl:cardinality to require exactly 1 of these -->
      <wdr:Scope>
        <wdr:hasHost>example.org</wdr:hasHost>
        <wdr:hasURI>\.jpg$</wdr:hasURI>
        <wdr:UAstring>NOKIA</wdr:UAstring> <!-- placeholder for HTTP request variables -->
      </wdr:Scope>
    </wdr:hasScope>
    <wdr:hasDescription rdf:resource="#description_1" />
  </wdr:WDR>

  <wdr:WDR rdf:ID="dr_2">
    <foaf:maker rdf:resource="http://labellingauthority.example.org/foaf.rdf#me" />
    <dcterms:issued>2006-09-01</dcterms:issued>
    <wdr:validUntil>2007-09-01</wdr:validUntil> 
    <wdr:hasScope>
      <wdr:Scope>
        <wdr:hasHost>example.org</wdr:hasHost>
        <wdr:hasPath>foo</wdr:hasPath>
      </wdr:Scope>
    </wdr:hasScope>
    <wdr:hasDescription rdf:resource="#description_2" />
  </wdr:WDR>

  <wdr:WDR rdf:ID="dr_3">
    <foaf:maker rdf:resource="http://labellingauthority.example.org/foaf.rdf#me" />
    <dcterms:issued>2006-09-01</dcterms:issued>
    <wdr:validUntil>2007-09-01</wdr:validUntil> 
    <wdr:hasScope rdf:resource="#primaryScope" /> <!-- The last DR in list SHOULD point to same scope as package -->
    <wdr:hasDescription rdf:resource="#description_3" />
  </wdr:WDR>

  <rdf:Description rdf:ID="description_1">
    <ex:property1>value 1</ex:property1>
    <ex:property2>value 2</ex:property2>
  </rdf:Description> 

  <rdf:Description rdf:ID="description_2">
    <ex:property3>value 3</ex:property3>
    <ex:property4>value 4</ex:property4>
  </rdf:Description>

  <rdf:Description rdf:ID="description_3">
    <ex:property1>value 1</ex:property1>
    <ex:property4>value 4</ex:property4>
  </rdf:Description>

</rdf:RDF>

Each DR is self contained, comprising attribution, scope and the description. In other words, it says who is saying what about what.

The scope of the package is defined, in this case as "everything on example.org". OWL constrains mean that it is not possible to tamper with the data from outside by providing triples that extend this scope (without breaking the constraint). There is then an ordered list of DRs. This list is closed so that, again, it is not possible to corrupt the data from outside.

In seeking a description for a given resource, the processor will first examine the package scope. If the resource is on the example.org host then it can look at the first DR's scope which, in this spurious example, says that it's in scope if the resource is a JPEG image and is fetched using a Nokia device.

If that scope doesn't match, go on to DR 2 and finally DR 3. The last entry on the list has the same scope as the package as a whole, therefore the data set is complete. The group was most grateful to Fabien Gandon for his input during this discussion!

Finally the group discussed use of the FOAF and vCard vocabularies and raised the following issue.

We have used foaf:maker in our examples and wish to use things like foaf:
Organization etc. We need to consider 3 options:

1. Create our own and use owl:sameAs to reference the foaf terms

2. Use the foaf terms and liaise with FOAF community to help to firm up those 
terms we consider important

3. Support others in suggesting possible W3C standardisation of foaf-like vocab.

4. Use foaf as a best practice in examples but not put it in formal Rec. Not 
considered a good option due to importance of attribution in WDR. 

Boston F2F tending towards option 2. Looks promising, see http://danbri.org/
words/2006/09/23/158.

With this work behind us, the POWDER WG must now work towards a conclusion, seeking as much advice and opinion along the way as we can.

Phil Archer, FOSI/ICRA
POWDER chair.