Post details: Last Call closed – preparing for Proposed Recommendation

Friday, May 1st 2009

Permalink 10:38:06 am, Categories: News

Last Call closed – preparing for Proposed Recommendation

The third Last Call period ended at the start of this week and lead to what amounts to errors being corrected in the IRI canonicalisation sections of the Grouping of Resources document (which was the focus of the call, see implementation experience). A small number of extra tests was added to the test suite to cover this important aspect of matching IRIs against POWDER documents. No changes were made to the Description Resources document or Primer.

The Formal Semantics document was reviewed by the OWL WG and the informative section on expressing POWDER in OWL 2 was subsequently updated. At the time of writing, we're dealing with a substantive comment from Michael Schneider. This is likely to lead to a rephrasing of Section 4.3 but no substantive change that would impact on implementations.

So, once that issue is resolved, the next step is Proposed Recommendation. As flagged previously, we're skipping Candidate Rec stage as we already have plenty of implementation experience to hand.

So is the work on POWDER really over 'bar the shouting' as the phrase goes? i.e. have we done what we set out to do? Let's see.

The charter says: The POWDER Working Group is chartered to specify an RDF vocabulary for specifying authorship of and authentication of Description Resources, a specification for associating a Description Resource with a class of Web resources, predicates for declaring classes of resources based on string functions of the resource URIs, and a protocol for accessing Description Resources. This seems well covered!

The charter gives specific examples of statements that must be expressible in POWDER:

  1. All resources on the travel.example.com domain are suitable for display on mobile devices.
  2. All resources on broadcast.example.com/clips are video clips that are suitable for all ages.
  3. All resources on example.com are accessible for all users and meet WAI AA guidelines except those on visual.example.com which are not suitable for users with impaired vision.
  4. Web crawlers are welcome to explore all resources on example.com except those with a path beginning with 'private'.

The first two are exemplified in the documents published by the group (see mobileOK and ICRA examples). The other two could easily be encoded in similar fashion using suitable vocabularies.

The charter sets out specific deliverables:

  1. A W3C Recommendation providing a normative encoding of description resources (we refer to it internally as 'the DR doc').
  2. A W3C Recommendation describing methods of defining groups of resources (referred to internally as 'the grouping doc).
  3. A W3C Recommendation providing an HTTP-based mechanism for locating and accessing description resources associated with a particular Web resource (see Section 4 of the DR doc).
  4. Subject to available resources, the group will develop a description resource validation tool. Done! (along with several other tools).

The charter also calls on the group to resolve the open questions raised by the Web Content Label Incubator Group: a previous blog entry covers that, which just leaves the requirements derived from the use cases. An exhaustive re-listing of the requirements and how they're covered would make a very dull and largely pointless blog entry but I'll pull out a few for special mention.

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. This is possible through the certified and supportedby terms discussed in Sections 5.2 and 5.3 of the DR doc. This also covers 3.2.4 Link to Test Results where the requirement is to be able to link to test results (perhaps encoded in EARL).

3.1.9 Standard Vocabularies

There must be standard vocabularies for assertions about DRs. Actually we kept the vocabulary to a minimum (i.e. reused existing ones as far as possible). However, terms such as issuedby, issued, validfrom and validuntil were introduced. issuedby caused particular debate as it is so close to terms in both the FOAF and DC vocabularies – but which one to support? Can we not support both? Which is the 'stable standard?'. Cue a lot of e-mails and discussion!

3.1.10 Identity

DRs, their components and individual assertions should have unique and unambiguous identifiers. Actually we haven't done this as such. POWDER documents have URIs and you can give individual descriptorsets identifiers but, largely due to RDF's lack of (formal) support for named graphs, each component of a DR does not have an identifier. Furthermore, we deliberately made sure that classes in POWDER-S documents typically had node IDs that can't be referenced externally so as to avoid assertions being added to those classes from external sources.

3.2 Fitting in with Commercial or Other Large Scale Workflows

This requirement — actually a heading for a whole set of requirements — is at the heart of the operational/semantic split. POWDER has to be as easy to use in a commercial, practical environment as possible. Hence the XML encoding and, in particular, the ordered lists of DRs through which we meet requirement 3.2.3 Default Description.

Unless something goes wrong, we should be ready to begin the transition to Proposed Recommendation process next week (or the week after as a worst case).

We really are nearly there.

Phil ARCHER

Comments, Pingbacks:

No Comments/Pingbacks for this post yet...