The group took the opportunity to go through several of its documents in detail over the course of the 2 days, beginning with the Grouping of Resources
document. There was a fairly brief discussion about some of the features that have been removed from earlier versions: grouping by property and CIDR block, for example, and the section on redirection. The changes have come about through a series of discussions with their resolution largely driven by practicality and ensuring that POWDER processing remains manageable. One action item not yet completed is an addition to the POWDER processor section of the DR doc to say that whether a particular processor includes redirected IRIs in a group is application-specific.
There was discussion about the canonicalisation section. It was agreed that the text should say that where a DR author knows of patterns that might erroneously lead to inclusion of IRIs in their group, perhaps through processing of IDNs, then he/she should add specific exclusions. As a test of the grouping mechanism and its canonicalisation steps, the group looked at a tool designed to implement this
. At present, everything except Punycode translation is included in this tool. Even the proposed new top level domains with no subdomain - such as http://example - still fit the model.
It was agreed that in/exclude query contains should only be allowed 0 or 1 times in line with more or less all the other POWDER IRI constraints.
The group then moved on to discuss the Description resources
document. This prompted a wide ranging debate about various issues, only the most substantial of which are discussed here.
In recent e-mail exchanges
it was decided that POWDER would support both foaf:maker and dcterms:creator but that our examples would almost all show the dcterms:creator version. This discussion continued at the face to face and in the end it was resolved that we would define our own term of 'issuedby' as both a POWDER element name and POWDER-S property. In the latter case it will be a sub property of both the FOAF and DC properties so that authors are free to use either foaf:Agent or dcterms:Agent classes.
The next substantive debate concerned how we handle some specific properties in the descriptor set. In general, properties in POWDER descriptor sets are transformed into property restrictions in the OWL class that takes the place of the descriptor set. This is inappropriate for some commonly used RDF and RDFS properties. As a result we will define POWDER element names of typeof, seealso, comment and label that will be transformed into rdf:type, rdfs:seeAlso, rdfs:comment and rdfs:label annotations respectively. Recognising that authors may, through habit, write these terms in a descriptor set anyway, the transform will also pick up on these properties and render them as if the element names had been used. In other words, you can do either and the POWDER transform will handle it.
The next question was "should it be possible to process POWDER without having an RDF processor?" Most of our examples show that the DR author is described in a separate file (these days commonly a FOAF file). Allowing that information to be embedded in a POWDER doc as shown in Example 2-2
strongly suggests that you will need an RDF parser in your POWDER Processor. Requiring an external reference lifts that requirement in some situations. However... a descriptor set can include arbitrary RDF (subject to certain restrictions) so the RDF parser is already required. End result - given that POWDER transports RDF - the group recognises that being able to process POWDER documents implies at least some ability within a POWDER Processor to parse and process RDF.
Day 1 ended and day 2 began with a discussion around the abouthosts element. The semantics of it are far from simple - POWDER would be a lot simpler without it, however, it plays too important a role to be dropped so we have to handle it. That said, it should only be used by DR authors where it is necessary and a warning to this effect will be added to the DR doc.
The group discussed the POWDER Processor at some length, particularly how they should handle abouthosts and how errors should be reported. There are two basic types of error that a PP may detect: errors in the data and errors in the processing. We assign the error code 100 and 200 to these respectively and suggest that specific implementations can then create their own error codes in the 1xx and 2xx ranges. To support this there'll be 3 new wrds properties: data_error, proc_error and err_code. These will be used in the RDF returned by the POWDER processor (PP) and where there is a data error, the triples will be 'about' the data source and where there is a processing error the triples will be 'about' the processor itself. One specific error, number 101, is defined to report that a DR refers to a descriptor set in another document that sets an abouthosts value which is not in the scope of the DR.
The full list of conformance criteria for a PP was agreed and will be in the next version of the DR doc.
There was some discussion around the issue of linking resources to POWDER docs. The DR document is OK as is but we have some follow up work to do to make sure that the @rel type of powder is registered/recognised. This will involve liaison with various groups and individuals.
The group was joined briefly by Dan Appelquist who was able to confirm the Mobile Web Best Practices Group's requirements for mobileOK. A full example of this will be included in the next version of the DR doc.
The discussion of the DR doc came to a close at that point. Changes arising from the discussion will be made in the coming days.
Attention turned briefly to the Formal Semantics
document. Ivan Herman has made several comments
some of which have in fact already been addressed in an as-yet unpublished update but there was significant discussion going on between Ivan, Jeremy Carroll and Stasinos Konstantopoulos (i.e. the people best-able to discuss the detail) and the F2F participants left the formal doc untouched for now.
The strong hope is that the next group telecon will resolve to publish updated versions of the Grouping Doc, DR doc and Formal doc. At least the first two of these (and all being well, all 3) will be the Last Call versions.
Attention then turned to the Primer.
This will be a Group Note and is more or less ready for First Public Working Draft now. The group discussed the existing content and what had to be put in place before FPWD. This amounts to an update of the various examples to match changes in the other documents and adding some place holders for further sections. POWDER has evolved into a complex technology and so the Primer has to tread a fine line between making the it overly complex (and so off-putting for potential users) and over simplified (and so becoming less useful). Over the course of the 2 days it was agreed that the group home page should contain links to other resources produced by group members and others - the Primer is there to stimulate interest in what POWDER can do and how it can fit in with real-world situations and then point readers to the relevant specification documents. The hope and expectation is that a first public working draft can be ready at the time of the Last Call announcement on the Rec Track documents.
The final document reviewed by the group was the Test Suite. Again, this is very close to FPWD standard and should be published alongside the Last Call announcement. The aim is to provide tests to match each MUST/MUST NOT statement in the Rec Track documents. Many are already defined in the Test Suite. Like the Primer, this document will end up as a Group Note.
The face to face meeting finally turned its attention to the timeline for the remainder of its charter (the end of 2008), Candidate Recommendation Exit Criteria and forthcoming key dates. In brief, it is expected that the formal exit criteria will be two independent implementations of a POWDER Processor and one implementation of the Semantic Extension. The latter will be created in Java and offered as an extension to Jena. Several WG members are planning implementations of various kinds that will demonstrate POWDER's key features:
Links to POWDER documents
The Semantic Extension
Important dates in the calendar are:
Last Call period on the three Rec Track documents will end on 29 August
16th September - POWDER outreach meeting at Yahoo!'s Mission College Campus
in Santa Clara, California. This is open to anyone but registration will be essential.
25th September - demonstration of POWDER in the European Quatro Plus project at the Safer Internet Forum
The group does not expect to have met its CR exit criteria by then but to have made significant progress towards it.
20 October - TPAC
. The WG hopes to use its meeting time to review CR Exit criteria and generally tidy up before seeking transition to Proposed Recommendation.
This is a tight schedule but reflects the fact that the group has already well exceeded its original charter and is anxious to complete its work within its extended charter period.
Finally, the group thanked its host (Kevin Smith of Vodafone). It was a productive meeting!