The POWDER Working Group was formally closed yesterday, 24th November, 2009. The WG homepage is now locked and, until and unless another group updates the work, that really is the end of the process. But there were two more things that happened yesterday as well.
First was that the PICS Recommendations were marked as superseded by POWDER. The listing of documents on the Current Status page for PICS now includes links to the relevant up to date documents (not all of which are within POWDER) and each of the Recommendations themselves includes a prominent message that it has been superseded. PICS was a major piece of work right at the very beginning of W3C and many of its features are still apparent within POWDER. A comparison of the two is available separately.
The second event yesterday took place at at the European Commission in Luxembourg: the (successful!) final review for the Quatro Plus project. This project provided much of the impetus for the development of POWDER and it is fitting that these two final events took place simultaneously.
Looking back through the later posts in this blog, I see a glaring omission so let me correct that right away. Many individuals and the companies for which they work contributed to POWDER, many of them over a sustained period of time from initial identification of the problem through to the eventual solution. The danger in listing people is that you forget someone but let me do my best to list correctly the people who have made substantial contributions and/or given critical support at different times during the development process. My personal and sincere thanks to:
And, to the person/people I forgot to mention, my sincere apology.
Now all that's left to do is to exploit the technology. Asked to sum up what POWDER does, for Semantic Web folk I can do no better than to quote Dan Brickley explaining it to Brian McBride: "It solves the About Each Prefix problem." A slightly richer summary of POWDER might be: it allows you apply common RDF descriptions, such as Dublin Core metadata, CC licences, trustmarks and more, to whole groups of resources. It can be processed as XML or OWL (noting a semantic extension) and the output is always regular RDF triples.
Hope you find it useful.
The headline says it all!
See the announcement from W3C.
The W3C membership now has a chance to review the docs and approve (or not) the final transition to Recommendation. As far as the working group is concerned, the specification is complete. Work will continue, of course, on deployment and the development of new applications and community building. Although the specs are done, the work never stops...
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:
travel.example.comdomain are suitable for display on mobile devices.
broadcast.example.com/clipsare video clips that are suitable for all ages.
example.comare accessible for all users and meet WAI AA guidelines except those on
visual.example.comwhich are not suitable for users with impaired vision.
example.comexcept those with a path beginning with '
The charter sets out specific deliverables:
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.
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
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).
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
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!
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.
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.
Since making our second Last Call for comments at the end of last year we've responded to all of them and have been completing work on the tools - the processors, the XSLTs and so on - all of which has now been done.
So why aren't we at PR yet? There are a couple of reasons for this. There has been an ongoing battle between (WG member) Stasinos Konstantopoulos and (W3C team member) Eric Prud'hommeaux over whether the POWDER Semantic extension applies to the data layer or the application layer. The two protagonists have agreed to differ whilst the document has gone forward.
The second issue that has arisen concerns the other area that has prompted a lot of comment - the canonicalisation section of the grouping doc. Despite many changes over the last year or so and input from the Internationalisation WG, (W3C team member) Thomas Roessler spotted more problems with this section.
After a lot of e-mail bouncing around on, I'm sorry to say, a team-only list, I had a long conversation with Thomas and (Semantic Web lead) Ivan Herman. Some context:
The Semantic Web (RDF, OWL, SPARQL etc.) is written solely about URIs, not IRIs. Furthermore, all URIs are opaque strings - they have no meaning. This goes back to Jeremy Carroll's useful distinction between "http://www.example.com" and <http://www.example.com>. In other words, for RDF etc. our issue of processing URIs/IRIs as meaningful strings doesn't arise.
IRIs - that is, URIs written in things like Cyrillic script, Japanese Kanji etc. - are going to be more important in the coming 12 - 18 months (according to Thomas who, among other things, represents W3C at ICANN and so has a good grasp of such things). For POWDER not to be useful now and in the near future across all parts of the Web would limit its potential usefulness.
As we have discovered, the encoding of IRIs and International Domain Names is less than clear. However, there is a recognised path to take in this area which involves converting IRIs into ASCII - essentially converting IRIs to URIs.
It is not the POWDER WG's job or wish to solve the whole issue, neither is it within our ability to do so.
The POWDER to POWDER-BASE transform XSLT doesn't do any of the canonicalisation stuff, and it would be hard, if not impossible for it to do so. Therefore, strictly speaking, some form of pre-processing is already necessary before the XSLT is applied (the Perl script does do the canonicalisation but now needs a bit of work).
Given all of the above, the group was faced with a choice between either making significant edits in all its documents to talk only about URIs or, as we have done, further amending the canonicalisation section to introduce the ToASCII function as defined in RFC 3490. It is this change that has prompted the new Last Call announcement, open until Monday 27 April. The documents published on 3 April to coincide with the Last Call reflect all the changes made following comments received in the previous calls and, with the exception of the highlighted sections of the Grouping of Resources document on canonicalisation, are considered stable.
One important, although editorial, change worth highlighting is in the Description Resources document. The definition of the
describedby relationship type and the two POWDER Content Types is much improved.
describedby is now included in the IANA registry of ATOM Link relationship types.
The Test Suite has been significantly updated in the 3 April version and is now unlikely to change significantly (we may add some new tests for the canonicalisation section). Perhaps rather perversely, the test suite does include a test for the informative section on HTTP Link. The Primer is considered stable and very unlikely to change further.
Minor adjustments to the POWDER Processors are in progress and, notwithstanding changes prompted by the last call, the group is expecting to go to Proposed Recommendation in May.
:: Next Page >>