POWDER Working Group Blog

The principal discussion point this week was the relationship type to be used on a link element pointing to a DR and what should be returned to a user agent following such a link. This follows the discussion held in Boston last month where Tim BL argued that we should use a link element such as <link rel="meta" type="application/xml+rdf" href="..." /> This should return triples that have the resource as their subject and, perhaps, a link to the full DR. In other words, server-side processing would support existing RDF clients. This creates a minimal barrier to adoption from a client perspective. However, it contrasts with the way the group has been thinking so far which is to define a relationship type of 'powder.' Following such a link would return one or more DRs. The problem is this - if we use the generic rel="meta" system then it's quite possible that the metadata would be extensive - and possibly largely irrelevant to the particular context. How can you get just the data you want? As much as requiring server-side processing presents a hurdle to adoption by content providers, requiring client-side processing presents a barrier to user agent adoption, especially in the mobile market. Somehow we need to make sure that the processing is minimised and always relevant to a particular context - is <this> mobileOK? Is <this> child-safe? These look a lot like potential SPARQL queries? Yes - so maybe we should encode the SPARQL query in the href attribute? We didn't discuss this in detail but it is possible. However, there is a generally feeling that the original rel='powder' approach has merit. Given that we plan to specify not only the semantics of a DR but also an XML schema for it, clients could process the data in a variety of (optimised) ways in narrow circumstances. One idea that was frowned upon was having two different representations of the same thing (i.e. and XML version that could be translated into an RDF version). There's a lot of thinking still to do on this topic but it was good to air the issues.

The group spent some time this week discussing internal logistics, for example, we have agreed that our next face to face meeting will be in Athens in Monday-Tuesday 21 - 22 January 2008. We then gave some thought to the Primer. Who is it for? What message should it convey? It was agreed that it must inform the reader of what POWDER is for and how to use it but that, of course, it was not meant to duplicate the main specification documents. Work on this will get under way before the end of the year. The final topic discussed was the comments made by the Semantic Web Coordination Group last week, in particular the discussion on reification. Further input will be sought from outside the group but in the meantime, work will progress in the other areas. For example, a new internal draft of the grouping document should be available for review by the group members before the end of the year.

The discussion about the 'new' structure for Description Resources has been actively pursued on the public list and we dare to hope that we're reaching a conclusion. There are many factors to bear in mind. Should we use semantic web technology at all? (yes). Can we just do everything in RDF without OWL? No - that's what we were trying to do and it has the real danger that an off the shelf tool kit would come to the wrong conclusion. OWL can help us to overcome this but there are pitfalls too. Finally, using 'just a bit of OWL' to cover a gap in what we need to express in what is essentially an RDF vocabulary is to miss out on the full expressivity and power of OWL. Is this what we want to do deliberately? Well, it's not that we want to cut off options, more that the use cases do not call for the full expressivity of OWL. In particular, we do not need a system that says 'If a resource has features A, B and C THEN it is X'. We need to be able to say 'ACME testing says that Web site A is an example of _this_' and then to be able to go to ACME testing and ask 'did you really say that?' Unless further comment is forthcoming, the editors will work on new drafts of the primary tech documents over the next week with the hope of getting them in the public domain next week. This will allow others to review what the group's planning and make comments as soon as possible.

The bulk of the meeting was taken up with a discussion of the 'new model' sketched out at the face to face meeting in Boston (see previous blog entry) and the follow up work done, particularly at NCSR. The group is aware that, at present at least, it does not have the necessary skills to work comfortably with OWL, rule languages and inferences. The model of defining a class of all things that are of a certain type (say, mobileOK) and then a class of things that are on a given Web site (say example.org) and then making the statement that "ACME testing says that the set of resources on example.org is a subset of the resources that are mobileOK' makes sense and can be conveyed in text and images, but rules are much more specialised and harder to work with for the non-expert. Since it is anticipated that it will be non-experts that create and work with DRs, this is a substantial problem. Machine processability is very important - Description Resources have to be machine processable. The question is how much manual work is acceptable or, at least, how much specifically POWDER processing is acceptable? This will be explored on the mailing list in the coming days and weeks. The group ended with some housekeeping issues concerning the timing of its weekly calls and the date for its next face to face meeting, provisionally scheduled for mid January in Athens. Finally there was a brief discussion about the rel="powder" issues. Observers at the face to face meeting suggested that rel="meta" was what we should use and furthermore, that any user agent following such a link should expect to receive back triples about that resource. This is something the group will return to in due course but it looks as if rel="powder" is probably not going to be necessary.

The group met in Boston with the aim of advancing its draft documents to Last Call… er… it didn’t quite go that way. However, the overall news is very positive. A problem that has dogged the development of POWDER since even before the establishment of the WCL Incubator Group appears to have been solved. Expanded upon by Dan Brickley during the XG process, it comes down to the fact that we want to make generalised statements about lots of resources at once when RDF is predicated on triples with a single resource, identified by a URI, as its subject. It has been suggested before that OWL might provide a way forward but a clear notion of how this could help has been as elusive as any other solution. Now we think we know – and it has the air of ‘is it really that simple?’ about it. The benefit of a gathering like TPAC – indeed the whole point of the event – is that you can ask other people what they think. So in the corridors and restaurants of the conference hotel views were sought from the likes of Eric Prud'hommeaux and David Booth with Dan Brickley being the recipient of a lot of IM traffic. But it was during the first day of the WG meeting that we were very pleased to be joined by several ‘observers’ including Max Froumentin, Fabien Gandon and Tim Berners-Lee. This was just the kind of input the group needed – although it felt a bit like anaesthesia-free surgery at the time. It was the next day when we were able to analyse all the input we’d received, begin to identify aspects that require further elaboration… and to work out a new timeline. The new model is best described using an example – that we want to assert that all resources on example.org are mobileOK. We first define the set of all things that are mobileOK (actually, we don’t – that’s the job of the Mobile Web Best Practices Working Group but you get the idea). Then we define an OWL class with the property restrictions that apply to the resources to be described, in this instance, resources that have the property of being available on example.org. If we now assert that the class of resources on example.org is a subclass of the class of resources that are mobileOK, OWL inference can tell us what we need to know. Recall that we always start with a particular candidate resource in mind, say, http://www.example.org/index.html. Is that an instance of the class of resources on example.org? Yes. What do we know about it? Well… now we know it’s mobileOK. But hang on, what about attribution? As the WG members emphasise over and over again, the absolute critical factor in POWDER is that you always know who has made the assertion that a particular thing is true. You can’t decide whether you trust an assertion if you don’t know who’s making it. A classic job for reification! Defining a class of things that are mobileOK is uncontentious, as is defining a class of things that are on example.org. The triple in which trust is important is the one that says that the example.org class is a sub class of the mobileOK class – so that’s the one that will be the focus of the reification data with our usual foaf:maker, dcterms:issued and wdr:validUntil properties. In the week following the meeting, some basic testing will be carried out at NCSR Demokritos in Athens, after which we’ll be able to put such examples online. Meanwhile all currently published documentation (i.e. anything published before November 8th 2007) must be treated with extreme caution – the forthcoming revisions are very substantial. A few further notes:

1. The group must make significant efforts to engage with, and seek input from, the OWL community.
2. We need to try to make sure it is always clear when creating a Description Resource which class is a sub class of the other.
3. We will be doing a lot of testing to ensure that standard OWL reasoning does always produce the desired outcome (expect a full Test Suite as part of the POWDER document set).
4. Description Resources are about adding semantic data to the Web and all the normative documentation will be couched in Semantic Web terms. However, we do expect to be able to devise an XML-based approach that can be used to model simple DRs. The structure of such an XML instance will look superficially similar to the example DR in the current documentation and it will be possible to use a GRDDL engine to generate a DR from it.
5. There was some discussion about ‘the protocol part’. We expect to just use rel="meta" (cf. rel="powder") on link elements and need to look at services that can return triples about whatever resource includes such a link plus a triple pointing to the full DR data.
6. Tim BL in particular was concerned about the effect on processing efficiency of using things like ‘path contains’ and regular expressions to match against URIs in the Resource Grouping side of things. The group will take this into account in the light of the use cases for POWDER, however, as a first pass, we remain of the opinion that such flexibility is important, even if DR creators are encouraged to only use such features when absolutely necessary.
7. The group’s timeline has clearly slipped. We’re now planning to reach Last Call by the end of January with test suites completed, LC comments answered and the Primer finalised around the end of April (so we can seek transition to Proposed Recommendation). We plan to hold at least one outreach meeting in the Last Call phase (see previous event).
8. It follows that we expect to apply for a relatively small charter extension of 3 months to give us to the end of June to complete our work.

The meeting began with a quick tour of the latest version of the Grouping of Resources Document followed by a resolution for this to be published as our next working draft (TBA on this blog). There was then a discussion of the new use accessibility-centric cases that have been developed since receiving input from Liddy Nevile. Two revised use cases will replace the current use case 2.1.5. While looking at the Use Cases document, two further issues were discussed. Firstly requirement 3.3.4 Compact says: It must be possible to express DRs in a compact form. As pointed out by Dan Connolly, this is un-testable and therefore is to be dropped. A further requirement, 3.1.9 Standard Vocabularies says 'There must be standard vocabularies for assertions about DRs.' This has not been addressed yet and therefore it was resolved to create a new RDF property of wdr:certifies to provide such a standardised way of creating the certificate shown in section 6.2 of the current Description Resources draft. It was noted that the use of wdr:certifies and wdr:certifiedBy are independent of each other - i.e. using one does not entail using the other - although it's probably a good idea to do so. [Looking at the example now, it seems that wdr:certifies shouldn't be a property, rather it should be a sub Class of Descriptors]. This raised the issue of whether the grouping document should support definition of resources by reference to a hash of them so that a DR could indicate that it only applied to resources if they have remained unchanged. A proposal will be made to the group on this issue shortly (should we specify a limited number of hash types, such as with wdr:sha-1 or a more generic wdr:hash with a separate wdr:hashAlgorithm predicate?) The chair reported on the recent establishment of the HTTPBIS Working Group at the IETF and the statement in the charter: "The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic." On present evidence it seems unlikely therefore that the HTTP Link Header will be standardised although this working group would support such a move. The normative POWDER documents will not refer to usage of the HTTP Link header, however, informative documents will (because it's very useful and works!). The meeting closed with a realistic expectation of announcing Last Call on its Rec Track documents following the face to face meeting in Boston 8 - 9 November.

Work on the grouping of resources document has gone on for the last few weeks with significant questions still remaining. Specifically, attempts to devise a generic way to encode the data required to query any look up service has proved difficult, complex, messy, horrible - choose your adjective. As a result, the WG resolved to change the approach. It will be possible to define a Resource Set in terms of the properties of the resources within in it (e.g. the set of resources that are in the French language) and we'll make it possible to define characteristics of the HTTP Response Headers or body content. However, any look up service will be described in a separate (linked) document that could be written in natural language, WSDL or some other format. The idea is that a look up service operated by an organisation that regularly creates Description Resources, such as trustmark operator, would be at a location repeatedly cited in its DRs. In some ways this is similar to the HTML Profile concept. Following further discussion of the use case suggested by Liddy Nevile, the existing Use Cases and Requirements will be updated. The new use case makes more explicit use of profile matching as well as making a clear distinction between first and third party labelling. The group members whose primary concern is using POWDER for highlighting resources that meet accessibility criteria are taking on this document revision. Attention then turned to the Description Resources document. First of all, the group will create a profile document that can be cited in an HTML HEAD tag that defines rel="powder". Our documentation and examples can then point to this. This working group will join others in arguing that HTML Profile should be retained by the HTML 5 Working Group and not deprecated. The forthcoming Technical Plenary has a session on HTML 5 and XHTML 2 and this seems like an ideal opportunity to raise it. Discussion then turned to the more difficult issue of the HTTP Link Header. Efforts will be made to prove interest in this issue, in particular, by encouraging the re-issue of Mark Nottingham,'s IETF draft on the subject (or something very much like it). By coincidence, it was being discussed by Mark Nottingham almost simultaneously in the W3C IETF/HTTP WG mailing list and by him and Dan Connolly on this group's public mailing list a little later so getting HTTP Link and HTTP Profile headers seems at least possible. However, the group decided that if it proves not to be so, our own suggestion of using HTTP Link headers will move to the (non-normative) primer document, scheduled for publication later this year. Overall, the group is hoping to have new versions of the Grouping of Resources and Description Resources documents in the public domain by the end of the month and for these to be very close to being completed. The group will review them carefully at the face to face meeting in Boston in November and aim to move them to Last Call immediately afterwards.

The main topic of conversation this week was, again, the Grouping of Resources document. In particular, grouping my by property look up. The present published version of the document defines the includeConditional RDF property which states simply what property (properties) a resource must have to be a member of the Resource Set, without defining how to look it up. This is currently flagged as a feature at risk. The document goes on to suggest a method through which a look up system may be defined using simple HTTP requests. This section is going to be improved with a more well-defined syntax but is likely to remain more or less as is to handle a limited set of 'simple situations.' More complex look up systems using a Web Service require more thought! The feeling is that defining a completely generic structure in which any look up service can be encoded is probably not feasible. As a result the plan is to make a 'best effort' and then seek comment. The whole section on Resource Set membership through the properties is likely to be flagged as a feature at risk. The main reason for keeping it is that it should make it easier to publish DRs making use of existing database systems. There was some further discussion of which regular expression syntax to use. The issue has now come down to using either that defined by XML Schema or XPath functions. As we're only using REs for simple matching, only a simple syntax is required - so the issue is really whether the anchor characters should be explicit (XPath) or implicit (XML Schema). Next week's meeting will review the grouping of resources document again and will certainly aim to publish it, ideally as a Last Call. Finally, the group noted (and welcomed) the submission of a new use case by Liddy Nevile. The group's accessibility champion will review this carefully and advise the group on whether it should be added to the document or not.

The group focussed its attention on the new draft of the Grouping document (member only link)and discussed a few remaining issues. First of all it was resolved that the includeUserInfo and includeFragment properties would be dropped. A comment from Jeremy Carroll prompted the discussion. The use cases and group members' experience suggest that support for userInfo and fragments in Resource Set definitions would be of very limited usefulness and could potentially lead to security issues. It means that we're more focussed on Web Resources fetched using http/https but that seems the right move. Resource Definitions are extensible if ever userInfo and/or fragments are necessary. There was further discussion of the very real possibility of a DR containing a logical inconsistency (all the Resources that are Green are described as Red). This will be discussed in some length in the forthcoming Primer with tips on how to avoid it. For example, an XSLT will be available that renders a DR as a Web page that is easier to read and comprehend by the DR creator. The includeConditional and excludeConditional properties remain as a feature at risk - the group will be keen to receive feedback on this point. Meanwhile some new properties that have a data type of XML Literal will be added to the property look up system so that support for SOAP messaging is explicit. That is, a resource Set will be able to say 'post this XML instance to this URI and expect to get back this response.' In the same section, the document refers to an Internet Draft - advice is being sought on how to refer to another document in draft form. Having gone through the document, the Working Group has resolved that once the edits have been made as discussed above, it will seek transition to Last Call during the week commencing 1 October with a deadline for comments of 5 November - just ahead of the next scheduled face to face meeting.

Following last week's resolutions to seek transition of several documents to First Public Working Draft, they should be in the public domain this week. The group learned that its OWL vocabulary was the first to be published by a WG since the Best Practice document was published last year so there's a bit of work to do to get everything ready. The group will seek a lightning talk slot at the forthcoming Technical Plenary meeting in Boston. Attention then turned to comments received on the Grouping of Resources document. As resolved at the July face to face, the wildcard syntax for URI patterns will be enacted in the next draft. Art Barstow's comment is answered in full by the XML Schema document due for FPWD status this week. Jeremy Carroll's comment was noted. AS a result it is likely that specific support for the user info component of a URI will be dropped but this has not been fully resolved yet. His other comments will be acted upon. The discussion with Liam Quin concerning the regular expression syntax to be used resulted in the resolution that the POWDER WG will create a data type that reflects the XML Schema syntax as modified by XQuery functions. The syntax has less functionality than, say, Perl, however, it supports fully the kind of data validation envisaged for POWDER and is therefore suitable for this application. The remaining substantive issue discussed on the call was logical inconsistency. Specifically, if a Resource Set comprises "any resource that is blue" and the Descriptors declare those resources to be Red, there is no syntactic error, only a semantic one. Since this cannot be detected, the forthcoming Primer will include text warning of this and suggesting that DR creators test their DRs before releasing them. The group aims to resolve to seek transition of the grouping document to Last Call in next week's meeting. The LC period will be roughly the month of October leaving time for LC comments to be dealt with at the group's next face to face meeting in Boston in November. Meanwhile group members are beginning to think about implementation possibilities.

The group again looked at what has become a major discussion point: whether the Descriptors block is linked by a property of the DR itself or from the Resource Set. The group will be seeking input on this point, particularly from the semantic web community. Discussion then turned to the draft working group notes which are the namespace documents for the POWDER vocabulary and the XML schema that defines the relevant datatypes. A relatively brief run through the Description Resources document enabled the group to pass three resolutions to publish the documents as first public working drafts. The XML schema and DR documents will include text to highlight work to be done and the areas where external input is seen as being particularly critical. The working group members are anxious to put the documents in the public domain as soon as possible to elicit the maximum feedback! All being well these documents will be in the public domain week no later than Tuesday 25th September.

The first meeting back after the summer break began with a quick update of the current situation. The Use Cases document has been published in its updated, and hopefully final, form. We need to get an updated version of the Grouping of Resources document and a First Public Working draft of the Description Resources document done on the next couple of weeks ahead of various meetings at the end of the month that provide an excellent platform for promoting the group's work. Most of the meeting was spent working through the latest (member only) version of the DR doc. The issue of whether Descriptors should be linked from the DR or from the Resource Set will be resolved on the list in the next couple of days (where it's easier to show examples and list pros and cons) but the trend is towards linking from the RS. The textual summary of a DR (provided using dc:description) will normally be a summary of the whole DR but this doesn't prevent a dc:description being provided of, say, just the Descriptors. The discussion then turned to how to express package scope. The resolution was that as a minimum, you SHOULD defined a white space separated list of hosts covered by a package (using wdr:aboutHosts) and you MAY further define an RS but be warned that not all processors will honour it. Package scope is a processing hint - the DRs in the package are not guaranteed to cover all the resources given in the package scope. Work is being done on showing how to use DR data in a rules-based environment. It is anticipated that this will show how the data can be expressed precisely and efficiently and may lead to further improvements in the spec. The group discussed how to include multiple blocks of Descriptors in a single DR. The idea of a separate wdr:include predicate for this purpose was dropped in favour of simply using a parseType="Collection" attribute on the hasDescriptors predicate. The section on efficient data representation (using XML entity declarations etc.) will be moved the the POWDER Primer but will be referred to in the specification document. Finally, a proposal to make includeHosts mandatory in Resource Set definitions was not approved. Individual DR creators (a.k.a. labelling authorities) may operate Web Services where includeHosts is guaranteed to be present but this need not apply universally.

The group's original Use Cases and Requirements document, first published in May, has now been updated in the light of comments received and following various discussions amongst group members. As a result we're now seeking publication of it as a revised Working Group Note (subject to one final edit being made). The group remains undecided on whether the Descriptors should be linked from the DR or from the Resource Set. This remains an open issue therefore but one that needs to be resolved as it has a substantial effect on the structure of DR. Those present were either uncommitted on this issue or in favour of retaining the link from the DR to the Descriptors. Those in the other camp need to show up to put the case! Progress has been made on the Description Resources document. This is the one that sets out what a DR actually is, what it's structure should be and how it should be linked from content etc. However, insufficient progress has been made for it to be submitted for first public working draft and so it remains an editors' working draft for now. After a brief discussion about forthcoming face to face meeting at the Technical Plenary in November, and scope for repeats of the stakeholder meeting held in Washington earlier this month, the meeting closed. The next telecon will be at the usual time on Monday 3rd September.

The meeting covered a lot of ground in a short time this week as we checked off a few open issues that needed looking at to allow progress on the Description Resources document. First of all it was resolved to define an RDF predicate for use in DRs that allows one descriptive block to include another. In RDF terms that means that the Descriptors Class can have predicates that 'include' other Classes. This will be useful for reducing the amount of repeated data in a set of DRs that describe larger web properties. We then, at last, agreed what to call the descriptive block: we will use hasDescriptors to link to a Class called Descriptors. N.B. The group skipped any discussion about whether to link the Resource Set or the DR itself to the Descriptors - the issue isn't fully resolved and discussion is continuing. The group spent a little time considering how an organisation that creates a lot of DRs might make its repository available in bulk in as compact a form as possible. An RDF dump of a large number of DRs will, for example, include a lot of similar triples with the foaf:maker predicate have an identical object. There doesn't appear to be a strong case to devise an inheritance model (which would be relatively complex and error prone) so it was decided that the most likely way to reduce the size of the data would be to use simple entity declarations. One issue - can you encode an entity within an entity? For example, can you do this: <!ENTITY foo "http://www.example.org?this=that&amp;the=other"> since it includes the &amp; entity? If not, this imposes a small restriction on what can be done to reduce the number of bytes needed to encode the data. It is, of course, true that the XML serialisation of RDF is highly verbose. N3 and Turtle being much more terse. Since we have resolved that we will also produce an XML Schema against which DRs may be validated, this may or may not not be applicable. The next topic was 'the protocol part' of the Protocol for Web Description Resources. In particular, establishing a system through which an agent may find the DR for a particular resource without having the GET the resource itself. The group discussed ideas such as defining a new MIME type that could be used in an HTTP Accept header, or a new HTTP Header to be used specifically to request DRs - even a new URI scheme like powder://www.example.org, but it was felt (quite strongly) that such steps were not warranted by the use cases. Rather, it was resolved that we would encourage the encoding of links from resources to DRs in HTTP Link Headers (the HTTP equivalent of the HTML <link rel="...> element. Thus a HEAD request would yield the URI of the relevant DR (or DR package). A full GET request of the resource would be necessary to extract the link to its DR (assuming it was present) if there was no HTTP Link header. Either way, crawlers would be able to identify DRs for given URIs without needing to recognise any new headers or MIME types. Finally, the group spent a short time discussing an updated version of the Use Cases and Requirements document. One issue remains unresolved but it is expected that next week's meeting will be able to resolve to publish an updated version of the UCR. It is also hoped that the Description Resources document will be sufficiently advanced to allow a transition request to first public working draft status.

Following the face to face meting in Washington on 10 July, the working group members were joined by around 20 guests from various industry sectors that stand to benefit from POWDER. A full report on the event and the discussion held is available.

This week was a chance for those who were not able to be in Washington to catch up with last week's events and resolutions. The resolution taken in Washington to link the Descriptors from the resource Set was formally rescinded for two reasons: first there is little appreciable difference in processing requirement (which was one of the motivations for the Washington resolution) and, secondly, that a Resource Set may comprise multiple Resource Sets linked by OWL Set Operators. It isn't clear how one could validate that the Descriptors referred to the intended Resource Set. Since the resolution at the f2f meeting was passed but in a relatively luke-warm way, this week's telecon decided that it should be rescinded.

There was further discussion around the issue that vexed the face to face meeting, namely the relationship between caching and the validUntil date, how a commercial content provider could manage their DRs and so on. The example was brought up of a news front page. This could change at a moment's notice, rendering the description resource inaccurate, even if the validUntil date were set for a time as short as a day. The validUntil date could be set to, say, 30 seconds hence, however, that could put a significant and unacceptable load on the servers. Therefore it was resolved that the Primer document will include a discussion of the use of the property look up feature and how this might be used to refer to the Last Modified date for a resource. That is, a DR might describe a Resource Set if and only if it hasn't been modified since a given date/time.

A relatively small number of Working Group members met for a face to face meeting in Washington on Monday 9 and Tuesday 10 July. All resolutions were taken in the knowledge, and hope, that other members would review them and make any further comment. It is anticipated that some resolutions may be rescinded in the light of such comment.

The first topic for discussion was the comments received from the Web Application Formats Working Group's comments on POWDER's Grouping of Resources document, now available as a public working draft. As a result of the comments received, it was resolved " we create a new RDF predicate that will support the kind of wildcard-based URI pattern matching used by the WAF Group in their Enabling Read Access document. This entails making some changes to the predicate names for the regular Expression predicates and adding some explanatory text but it essentially an easy add-in to the grouping document.

The group then turned to discussing the Use Cases and Requirements document. This was a relatively easy discussion since almost all the suggestions were readily accepted. Specifically:

• The suggestion of a use case centred on database look up for child protection is accepted.
• The revised wording for the tags.r.us. use case is accepted.
• Use case 2.1.7 will be amended to make reference to 'An identity management system', therefore taking action derived from Patrick Petit's e-mail.
• Following Johannes Koch's e-mail, we will not specifically refer to EARL in the use Cases doc, as we have not referred to other technologies to which we might. However, the intention is to refer specifically to EARL when showing worked examples of linking to a test result.
• There will be a new use cases centred on semantic search as this is under-represented in the UCR doc.
• The UCR doc will be re-organised to create a semantic section to include the tags, RSS/Atom and new semantic search use cases.

During this discussion the group also considered the use of 'example' websites. There are instances in the UCR document and elsewhere where 'example.mobi' has been used. However, it was recognised by the group that RFC 2606 refers specifically to example.com, example.org and example.net and these will be used throughout POWDER documentation.

The bulk of the meeting was taken up discussing the Description Resources document. The ambitious hope is to get this ready to first public working draft status at the end of the month — which is not as unrealistic as it may seem since a lot of its content is set out in the WCL Incubator Report.

The group discussed the relative merits of dc:creator vs. foaf:maker. Since the latter has a range of foaf:Agent, its semantics are better suited to Description Resources and it will therefore be used. However, we'll put a note in the document that if we find a better term, we'll use it.

There was considerable discussion around the issue date for a DR and how this may differ from the date from which it is valid. An even longer debate centred on the relationship between a DR's valid until date and HTTP cache directives. As a result:

• We will use dcterms:issued as the issue/creation date of the DR.
• We will define our own terms for start and end dates, noting similar terms, being available, especially in PRISM (embargoed/expires).
• In the absence of a wdr:validFrom date, the dcterms:issued date is the valid from date.
• The group discussed how to include a text summary of the DR suitable for display to end users. The resolution was that DRs should use dc:description (and not define a wdr:summary predicate).
• Similarly, there will be no POWDER-defined predicate to support icons or logos. However, the document will " note that foaf:depiction may be used to describe either the creator (e.g. a logo), the descriptor (e.g. contains violence), or both (fooRaters says this is accessible)."

The next big topic was whether the descriptive part of the Description Resource should be linked from the DR or from the Resource Set. After many diagrams had been drawn and examples looked at, the resolution was taken that it should be linked from the Resource Set, the logic being that the descriptors describe the resources in the set. Summing all this up it was resolved: "that a DR should have a foaf:maker, dcterms:issued, wdr:validUntil date and, if appropriate, wdr:validFrom. All have max cardinality of 1. Informative text to be included encouraging use of all of these." A graph of a DR with these features (except wdr:validFrom) was generated.

The Class that contains the descriptors will be called Descriptors. The predicate linking the Resource Set to the Descriptors will be isDescribedBy which will be a sub-property of hasTag. This will have a range of rdf:resource and can therefore point to anything (such as a bunch of user-generated tags). isDescribedBy will have a range of wdr:Descriptors.

These various resolutions effectively define the structure of a DR. However, it should be noted in this public space that group members are already reviewing this structure, in particular, the resolution that the Descriptors should be linked from the RS, so there is still further discussion to be had.

The group then turned its attention to the idea of a package of DRs. The intention here is that a content provider can set up a common link across all resources that points to a package of DRs. Parsing that package yields descriptions for given resource groups. The question is whether the package has a scope and, if so, is it true that the DRs within the package MUST between them describe all the content within the package scope. Since this cannot be assured or enforced in an intelligent way, package scope will be a processing hint, not a guarantee that a given resource will be described by the DRs in a package (although it SHOULD be).

This discussion raised the issue of commercial workflow and the need for a default description. That is, the ability to encode that "resources on specific.example.org are like this, everything else on the example.org domain is like that." That's fine as long as it's true, but what about when the content changes and the description is no longer true.

Since caching is an integral part of the Web, a statement that "everything on example.org is blue and this statement is valid for a year" MUST mean just that. If a content provider changes their offering to red within that valid until period, a processor is quite within its 'rights' to use the original DR without fetching a new one to see if the colour has changed. Ancillary discussions looked at whether each different DR should have its own URI and how HTTP cache headers should be handled.

Out of this discussion came the need for a POWDER Primer. This will include advice that:

• Creators of DRs MUST be prepared to stand by their claims and assertions throughout the declared validity period.
• If content is likely to change frequently, then the validUntil date should therefore be set to a short time period.
• DRs SHOULD always be made available from a stable 'latest version' URI.
• An automated system can create a DR with a validUntil date of 'tomorrow' (or whenever is suitable). There is no requirement to make expired DRs available — although some content providers may wish to do so for auditing purposes. In this case, specific DRs that were available in the past will have their own URI
• HTTP Cache headers should, logically, reflect the semantics of ValidUntil. However, in case of difference, ValidUntil should be used to determine the time for which the DR can be relied on.

Moving on, the group resolved that as well as creating an RDF/OWL based vocabulary, an XML Schema would also be defined which DRs MUST follow. The advantages of this is that it allows XML-only processors, i.e. non-semantic systems, to make use of Description Resources and that it provides a quick validation step for all processors.

The big drawback is that it prevents a DR creator specifying his/her own sub-properties and Classes and using those instead of the POWDER vocabulary (a semantic processor would understand the relationships, an XML processor would flag a validation error).

On balance it was felt that this was a price worth paying.

The final technical discussion was the link mechanism. After considerable thought it was agreed that we really wanted to see link/rel tags like this:

<link rel="powder" href="http://example.org/powder.rdf" type="application/rdf+xml" />

and its HTTP Header equivalent. This means defining a new relationship type of 'powder' and this will be communicated to the HTML working group, seeking its inclusion in HTML 5.

In addition, it MUST be possible to link HTML documents to Description resources using RDFa.

At the end of the meeting, the group agreed that it would suggest a session on the social aspects of the Web on the agenda for the W3C Technical Plenary meeting in November.

We're moving to First Working Draft! The Grouping of Resources document that has taken much of the group's time since it was chartered has now reached a level of maturity that makes it ready for publication as a first working draft. There are a few areas where the group is undecided and is seeking specific feedback but the principles are clear. The main substantive point made during the meeting was that where Resource Sets are defined in terms of query strings, if the given query strings include multiple name-value pairs separated by ampersands, then these should be split up by a POWDER processor so that the same name-value pairs may appear in any order in the candidate resource's URI and still yield a match. The group also considered the idea that different parts of the set definition be given different priorities. For example, include might override exclude. It was resolved NOT to develop such a mechanism. The group's second face to face meeting will take place next week in Washington, D.C. Telecons will continue throughout July but the group will go into recess for the month of August.

This week's meeting briefly discussed the recent IETF work on template URIs and decided that, although the draft has expired, we should adopt its approach and refer to the document as a non-normative source. There was then a discussion about the RDF property names to be used. In the end, using the roleNoun approach, it was resolved that the property names would be includeHosts, excludeHosts and their homologues. The bulk of the meeting was spent discussing the meaning of Resource Set definition such as: <wdr:ResourceSet> <wdr:includeHosts>example.org</wdr:includeHosts> <wdr:excludePathStartsWith>foo bar</wdr:excludePathStartsWith> </wdr:ResourceSet> The intention is that multiple values given for each RDF property should be combined with OR so this means "all resources on example.org except those with a path starting with foo OR bar." However, de Morgan's theorem states that NOT ( A OR B ) = NOT( A ) AND NOT( B ) So in fact to express the natural language statement in logical terms means that we need to combine the foo and bar values with AND. This means that the values of different RDF predicates will be treated differently but seems the logical way to proceed (pun very much intended!). Moving on, the group also considered the recent discussion that has taken place on the public mailing list concerning the linkage between POWDER and SKOS. The POWDER WG has yet to begin work on Description Resources as such but has noted the outcome of this public discussion and will take it fully into account when the time comes. Finally, the group recorded a vote of thanks to Kjetil Kjernsmo for his substantial contribution to the POWDER WG and the Content Label Incubator Activity that preceded it.

The meeting discussed most of the remaining issues in the Grouping of Resources document. It was resolved that we'll produce a separate document that describes the individual terms (i.e. Classes and properties) in the vocabulary as defined by both the Grouping and main POWDER docs. This will map directly from (and may even be auto-generated from) the actual RDF/OWL data. The discussion that has been taking place on the group's list about redirection was continued. The end result is that by default, if a URI leads to a redirect, that resources will only be a member of the Resource Set if the target URI is itself a member of the set as well. However, this behaviour can be overridden with a new property to be defined. i.e. a Resource Set definition may include a property that says "if redirected, follow the redirection and don't re-process to find out if the new resource is a member of the set." Finally we talked briefly about whether there should be some prioritisation of Resource Set properties. For example, saying that properties that include resources will take priority over those that exclude. There was no consensus on this and more work is being undertaken. The meeting ended with a discussion of the logistics surrounding the forthcoming face to face meeting in Washington.

The first order of business was to welcome our new Team Contact, Matt Womer. Known to some group members through the Mobile Web Best Practices Group Matt recently joined W3C from France Telecom's Boston office. The first agenda item was a decision to define a Resource Set as a sub class of OWL Class rather than an RDFS Class. Andrea Perego took the group through the reasons for this but essentially an OWL Class is more closely defined and can allow closed world logic to be performed. The RDF properties currently under discussion for the Resource Sets are things like 'hasAnySchemeFrom' and 'hasAnyHostFrom'. Can these be shortened without losing meaning? Probably yes, but should they? A similar discussion has been held recently in Ubiquitous Web circles and the DDWG which lead to an action to contact Rhys Lewis to find out more! The next discussion concerned whether there should be an RDF property 'hasExactQuery'. We already have queryContains (and queryNotContains) but should we have a more definite version as well? It was resolved that yes we should, however, we should also note that, by their very nature, Web pages generated by resolving URIs with query strings are dynamic and that a Resource Set may not therefore be fully defined even using this method. How should a Resource Set defined by URIs be affected if resolving the URIs leads to a redirection? Should the processor re-calculate whether the resource is or is not a member of the RS or not? The suggestion was made that a 301 9permanent) redirect should be included in the resource set but that other 300 codes should not. This will be discussed further on the mailing list. Finally the group talked about the forthcoming stakeholder meeting in Washington. The signs are very promising that there will be a co-sponsor for this, however the timing needs to be brought forward to the afternoon of Tuesday 10th July. It wasn't possible to resolve the outstanding issues and move to first public working draft of the Grouping of Resources document - maybe next week!

The group is getting close to publishing the first working draft of its Grouping of Resources document and addressed most of the outstanding issues during the meeting. First it was resolved that where regular expressions are used in Resource Set definitions, we will use the Perl 5 syntax. However, we will also note that alternatives are available, in particular, XML REs and and the new syntax under discussion in the X Query WG. Such alternatives may be used in the document if ready in time or in a future iteration of POWDER. The meeting was pleased to note the recent work done by Dan Brickley on the FOAF spec and the discussions under way to create a stable, long term hosting solution for it [1]. Thus the group is confident in using FOAF vocabulary terms in its documents. There was a brief discussion about the stakeholder meeting to be held following the group's next face to face meeting in Washington on July. The venue has now been agreed as AT&T's Innovations Center. Discussion then turned to the Grouping of Resources document. A remaining issue to be decided concerns RS definition by resource property. We want to support a look up system whereby a POWDER module can send a request to a URI and determine whether a candidate resource is or is not an element of the Resource Set by looking at the response. The issue is whether, and how, we should support multiple look up URIs. A proposal will be put to the group during the next week. There is also the issue of a logically inconsistent Resource Set definition - how should these be dealt with? Amazingly, the conjunction and disjunction section that had previously seemed so vexatious now seems to be settled. To do: As above plus: 1. Write normative section giving each RDF property and its constraints 2. Further feedback from the group Aim is to resolve to go to public working draft at next week's meeting. [1] http://lists.foaf-project.org/pipermail/foaf-dev/2007-May/008542.html

The first half of the meeting was spent looking at the work plan between now and the Technical Plenary in November. The next face to face meeting of the group will be on Monday and Tuesday 9–10 July in Washington DC, followed by a stakeholder meeting the following Wednesday morning. It is hoped that the Grouping of Resources document can move to Last Call following that meeting and that the POWDER document (the one that will describe how DRs are to be constructed) can be prepared to First Working Draft. The aim is to advance both documents such that the LC phase can end immediately before the TP. That's going to be a tough schedule but, well, the group thinks it's a good target. The group therefore resolved to have a f2f meeting during the Tech Plenary week in November. The discussion then turned to what it means if a DR has no scope — it was resolved that a DR with no scope is invalid - i.e. a DR must describe a defined set of resources. But what if a Resource Set is defined outside the context of a DR? it was resolved that a resource set with no defining characteristics, i.e. <wdr:ResourceSet /> is the Empty Set. Finally, we turned to talking about naming different key Classes. This follows some internal confusion over 'description' and 'description resource'. The resolution was that we should call a DR a 'Descriptive Resource' (not, not Description Resource) and retain the terms Attribution, Scope and Description for a DR's components. It is to be noted that support for this was lukewarm and we may return to the issue in future.

Subject to a few final editorial edits, the group resolved to request publication of its use case and requirements document as a Working Group Note. There was then further discussion on the issue of grouping by resources, in particular conjunction and disjunction. This is being discussed on the public mailing list with several options under discussion. The plan of action now is: First to work on the possible grouping of resources by resource property. If this proves to be possible in a relatively straightforward way, then it remains important. If, however, it seems that grouping by property presents substantial problems then the group will consider dropping this all together. The use cases do not make grouping by resource property an explicit requirement. Dropping grouping by resource property may make the conjunction and disjunction issue easier to solve. For now it looks as if we will be handling conjunction and disjunction using both the OWL-based approach (i.e. use owl:unionOf etc) or with white space separated lists as values of RDF properties. There is precedent for this in XHTML's role and link's rel attribute — i.e. they both take white space separated lists. Multiple set definitions that are presented as part of an RDF Collection seems doomed to repeat a lot of data, probably unnecessarily, so this is receiving less favour. The XML-based option (option 6) is still very much on the table too. Other issues were discussed in relative brevity. First, we will define two RDF properties to handle grouping by IP address. hasIp will take a single IP address as its value, and hasIpRange which will take a CIDR block. The group looked at a proposal to support group definition by top, second and third level domain. e.g. has2LevelDomain. This would have some advantages for some users but would be prone to causing confusion, especially in countries where the convention is to use a third level domain, e.g example.co.uk, example.com.au, example.com.cn etc. On balance, this proposal was not adopted. Finally, comparison of IRIs and URIs with strings in set definition will be done following canonicalization that will include rendering all strings in UTF-8 with percent triples all converted to their actual characters.

A shorter than usual call this week coming soon after the face to face last week. The meeting focussed particularly on the use cases and requirements document, now in draft form. Members will be reviewing the use cases that relate particularly to their area of interest. WG members who were not in WCL-XG, where the original use cases and requirements were developed, are asked to review the document as a whole to ensure that it meets their needs as well. There was then an internal discussion about the putative press event in Washington later this year: the messaging and the audience. Finally, we talked about the desire to support user generated tags in DRs, using SKOS. This may require additional properties within SKOS itself or, perhaps, POWDER will define its own. There is some urgency in this work so it is proceeding slightly ahead of its more natural place in the discussion around the Description Resources themselves which will begin once the use cases and Grouping of Resources documents are in the public domain.

Day 1: POWDER + BPWG

On Thursday 26th, there was a joint meeting with the Mobile Web Best Practices group which gave us a chance to explore some of the issues surrounding mobileOK as it affects both groups. The chair presented a slide that he's been showing to various audiences that tries to show a vision of how DRs can fit into what happens on the Web now, particularly in terms of identifying sites that meet specified criteria. This generated discussion around the idea of blogging/linking to/supporting DRs as an aid to trust, particularly with respect to blog spam.

We then looked at the use cases. The POWDER use cases are being prepared for publication soon. These are based on those developed for the WCL-XG but need some revision. Particularly use case 1 which is "the mobileOK use case". Actions were assigned to make sure it is re-written and shared with MWBP before publication. The same use case can be re-phrased as 'the accessibility use case', the 'child protection use case' and the 'trust use case' — really it's the matching resources to delivery context/end user use case.

We looked at ways to codify that adherence to mobileOK Pro (the name for the upper level of mobileOK conformance) always implies adherence to mobileOK Basic. Essentially, one is a sub-class of the other. There was then what amounted to a preview of the discussion planned for the following day on resource grouping with some comment from BP. Test implementations of mobileOK will be important test implementations of POWDER, so there's a lot of overlap here.

An important part of the discussion was why mobileOK needs to be encoded in POWDER? There are simpler ways of tagging resources. The reasoning is that POWDER supports: 1) Independent certification of the claim to be mobileOK; 2) Detail of the the result of each test (pass, fail or warn); 3) DRs can contain descriptions from any namespace and so can serve many purposes. None of these would be true of, say <meta name="mobileOK" content="Basic" />

There was a discussion about whether a link/rel tag that points from a resource to a DR should include, or be able to include, a hint of the description that would be found in that DR. In other words, something like <link rel="POWDER mobileOK"… Thus an agent seeking mobileOK information would know to follow the link. There are arguments for this, particularly in terms of efficiency of processing. However, the arguments against were felt to be stronger. These centre around the need to go back and change all the link/rel tags every time you add a new description to a DR. It was resolved therefore that we would NOT seek to propose this, however, POWDER will define some queries that can be run against a DR to determine whether a particular descriptive vocabulary is used (such as mobileOK).

On a related theme, should we define a 'well-known location' for DRs? This was discussed, particularly in the light of the fact that POWDER is chartered to offer a solution to prevent this being necessary — not just for POWDER but for other protocols such as P3P and robots.txt. The resolution was that no, we will not specify a 'well known location' (or similar), but will rely on link/rel tags to point to DR files.

A discussion on the groups' timelines lead to an agreement that Mobile Web Best Practices should seek publication of the first working draft of its mobileOK Description Resources document simultaneously with POWDER's forthcoming Description Resources document. It is hoped that this will occur around July 2007 (both groups have f2f meetings scheduled that month although these will not be co-located).

Finally, MWBP asked that it be possible within a DR to refer to any checker used to make the claim of mobileOK conformance, whether or not that checker was available online or not.

Day 2 (POWDER only)

We began the day by looking at the work of the Rule Interchange Format WG. This prompted a solid discussion of the pros and cons of the approach we've taken so far in wanting to define resource groups in terms of data to be processed versus coding the definition directly in rules. Several Rule languages are available (such as N3 Rules, SWRL etc.) but none is (yet) recognised as a full standard/Recommendation. The result of the discussion was that POWDER will define a resource group in terms of data but, importantly, will give examples of how these can be transformed into rules programmatically.

There was considerable discussion around our expected use of terms from the FOAF vocabulary. In particular, terms marked as "unstable" in that document. We are pleased to note that the ERT WG has had similar discussions as it affects EARL. We discussed the possibility of defining our own terms but agreed that a) it is, of course, much better to use existing vocabularies and b) that the FOAF vocabulary is actually pretty stable, even the terms that are marked as unstable. Therefore we resolved that we would seek to promote the stabilisation of relevant terms by the FOAF community. If these efforts prove unsuccessful by September, we will return to the subject and consider, reluctantly, creating our own terms.

A short discussion was held regarding the use cases as these will be discussed at length on the next telecon. However, new use cases are being drafted.

The bulk of the meeting was devoted to the resource grouping document and many resolutions were taken. In addition to giving as clear explanations as we are able, we will also define groups using set notation and talk in terms of 'sets of resources.' This should aid clarity of thinking and give the document more rigour. Further, we agreed that the grouping document shall be renamed to POWDER: Grouping of Resources and the short name we seek in the TR space is 'powder-resource-groups' (and you can bet that discussion wasn't over in 5 minutes!).

Set definition by IRIs will, of course, be supported. We need to check the details of this as it affects canonicalisation.

We then turned to the properties we plan to use for defining a set in terms of URIs and URI components. Having resolved that a property like hasScheme would take a string and imply a matching rule, we needed to discuss which matching rule would be appropriate (startsWith, endsWith, exact or contains). Some terms were changed, some were added but we have a list that will be shown in the next version of the document. N.B. Non-Web URIs are covered by virtue of the hasURI property which allows a Regular Expression to be matched against the full URI.

We then hit our first area where the group can't reach consensus: how the different properties should be combined. How do we encode a set definition as being resources on example.org OR example.net where the path starts with either foo or bar? 5 possible methods are under discussion.

Option 1: Multiple instances of the same property are combined with logical OR, different properties are combined with logical AND. Thus we would encode the example as:

<wdr:Set>
  <wdr:hasHost>example.org</wdr:hasHost>
  <wdr:hasHost>example.net</wdr:hasHost>
  <wdr:pathStartsWith>foo</wdr:pathStartsWith>
  <wdr:pathStartsWith>bar</wdr:pathStartsWith>
</wdr:Set>

For: this 'looks right' to some.
Against: It is rather vague and relies on several assumptions being made. Can't use OWL cardinality.

Option 2: All properties of Set are combined with logical AND but we introduce a new property and class that allows properties to be combined with OR thus:

<wdr:Set>
  <wdr:includes>
    <wdr:unionOf>
      <wdr:hasHost>example.org</wdr:hasHost>
      <wdr:hasHost>example.net</wdr:hasHost>
    </wdr:unionOf>
  </wdr:includes>

  <wdr:includes>
    <wdr:unionOf>
      <wdr:pathStartsWith>foo</wdr:pathStartsWith>
      <wdr:pathStartsWith>bar</wdr:pathStartsWith>
    </wdr:unionOf>
  </wdr:includes>
</wdr:Set>

For: Logical, Sem-Web friendly.
Against: what a lot of processing!

Option 3: Properties are combined with logical AND but they take a white space separated list, members of which are combined with OR.

<wdr:Set>
  <wdr:hasHost>example.org example.net</wdr:hasHost>
  <wdr:pathStartsWith>foo bar</wdr:pathStartsWith>
</wdr:Set>

For: compact, logical, can use OWL cardinality.
Against: Processing may be heavy.

Option 4: Allow multiple Scope statements in a DR and combine those with OR.

<wdr:WDR>
  <wdr:hasScope>
    <wdr:Set>
      <wdr:hasHost>example.org</wdr:hasHost>
      <wdr:pathStartsWith>bar</wdr:pathStartsWith>
    </wdr:Set>
  </wdr:hasScope>

  <wdr:hasScope>
    <wdr:Set>
      <wdr:hasHost>example.org</wdr:hasHost>
      <wdr:pathStartsWith>foo</wdr:pathStartsWith>
    </wdr:Set>
  </wdr:hasScope>

  <wdr:hasScope>
    <wdr:Set>
      <wdr:hasHost>example.net</wdr:hasHost>
      <wdr:pathStartsWith>foo</wdr:pathStartsWith>
    </wdr:Set>
  </wdr:hasScope>

  <wdr:hasScope>
    <wdr:Set>
      <wdr:hasHost>example.net</wdr:hasHost>
      <wdr:pathStartsWith>bar</wdr:pathStartsWith>
    </wdr:Set>
  </wdr:hasScope>
  ...
</wdr:WDR>

For: Logically consistent. Maintains tight control on individual set definition. Allows easy integration with sets defined by property. May aid processing efficiency.
Against: Allows multiple scope statements so that the scope of a DR is not closed - others can publish additional scope statements. Thus security is dependent on recognising the source of the scope statements.

Option 5: None of the above — just use the Regular Expression property hasURI. Options 1 - 4 all use properties that match a string against a component of a URI. The hasURI property matches a RegEx against the whole thing so we could write our example as

<wdr:Set>
  <wdr:hasURI>^(([^:/?#]+):)?(//[^:/?#]+\.)*example\.(org|net)/(foo|bar)</wdr:hasURI>
</wdr:Set>

For: Most sets are expected to be simple. If you need to write a complex Set definition, you probably know Regular Expressions or know someone who does (and they'd probably be written by machine anyway). So we can decide that all properties in the Set should be combined with AND, use OWL cardinality etc.
Against: Goes against some of the design goals in that it requires knowledge of Regular Expressions. Also, they are error prone which may lead to resources being included or excluded by mistake. Finally it can't work with sets defined by resource properties (see next topic).

End result — we will include these options in the first public working draft and seek feedback.

At the end of the meeting we discussed two further issues briefly.

A possible method to define a set by resource property is:

1  <wdr:Set>
2    <wdr:hasProperty>
3      <wdr:Property>
4        <ex:colour>red</ex:colour>
5      </wdr:Property>
6    <wdr:hasProperty>
7    <wdr:propLookUp rdf:resource="$URI" />
8    <wdr:method>HEAD</wdr:method>
9    <wdr:resultContains>#ff0000</wdr:resultContains>
10 </wdr:Set>

Lines 2 - 6 allow the DR creator to specify that the resources must be red to be in the Set. Line 7 provides a URI that can be queried. This can be to any service that returns a result, thus it doesn't specify that a particular protocol must be used. It must support including the URI of the candidate resource (i.e. the resource whose membership of the set we are testing). Line 8 says that an HTTP HEAD request is sufficient and line 9 says that if the response contains 'ff0000' then the candidate resource is indeed red.

Very early days on this — lots to think about. One question that keeps coming up — do we actually need to support set definition by resource property? At present, any such section of the document should be considered as a 'feature at risk' in the W3C sense.

Finally, the group recognised a need to discuss support within POWDER for user-generated tags, probably drawing on SKOS.

—Phil Archer

The meeting focussed on a member-only draft of the grouping document. It is hoped that this will be ready for publication as a first working draft following the face to face meeting next week in Darmstadt.

It was resolved that we will support resource grouping by IP address and that Classless Inter-Domain Routing (CIDR) will be the basis for this, i.e. it will be possible to define a group of resources using CIDR.

There was then considerable discussion about the trade-off between simplicity and flexibility when defining a group by URI pattern matching. One approach would be to define a set of RDF properties, such as hasScheme, hasHost, hasPath and a set of properties such as plainText, startWith, endsWith etc. plus regularExpression so that any URI component could be expressed in a very explicit way. For example:

<wdr:Scope>
  <wdr:hasScheme>
    <wdr:Scheme>
      <wdr:value>http</wdr:value>
      <wdr:type>startsWith</wdr:value>
      <wdr:stringType>plainText</wdr:stringType>
    </wdr:Scheme>
  </wdr:hasScheme>
</wdr:Scope>

This defines the scope (group) as any resource resolved from a URI with a scheme beginning with http. startsWith might be replaced with 'exact' to exclude https, and plainText could be replaced with regularExpression, providing a very flexible system. It was felt though that this is a very cumbersome system that should be simplified somehow. There are two principle ways in which this could be done - make the data more compact or simplify the data model. The latter approach was chosen. Thus, two resolutions were taken: first that the RDF properties relating to URI components will _always_ have a string value; and that the strings will _always_ have a defined matching style. For example, hasHost is likely to always take 'endsWith'.

Thus the same data as above can be expressed thus:

<wdr:Scope>
  <wdr:hasScheme>http</wdr:hasScheme>
</wdr:Scope>

Clearly, there is a reduction in flexibility here, however, flexibility is largely maintained by the hasURI property which will always take a regular expression as its value.

There will be no telecon next Monday, 30th April. The next meeting is the face to face meeting in Darmstadt, the next telecon will be on Monday 30th April.

This week began with a welcome to Zeph Harben of TRUSTe. The focus of the meeting was the document setting out current thinking on resource grouping. Will scope statements always be written by machine or will they also be written by hand? This is pertinent to the decision on whether grouping statements should only ever be written in relatively terse Regular Expressions or whether a simpler string-based approach is also desirable. The end result is that we will use both — that is, strings when that's all that is required by still retain support for Regular Expressions. The discussion then turned to scoping by property. Is this necessary? If so, how can it be done? If you have to fetch the resource to find out if it is a member of a group does that not defeat the object of DRs? Although the use cases that motivate the group's charter are centred on things like trustmarks and labels for things like accessibility, child protection, eCommerce and mobileOK, POWDER should not be restricted to this and one can fairly quickly envisage a use case where scoping by property becomes useful. For example, the statement "all blue T-shirts in this store are made from bleach-free cotton" implies knowledge of a particular item before the bleach-free cotton claim can be relevant. Other cases call for different mechanisms to come into play. If a content provider has an established data system that can return data about particular items then that can be used to define membership, or not, of a set. There is a good deal of work to do on this but the resolution was taken that we wish to support scoping by properties by various means Finally the group noted the Rule Interchange Format Working Group has got various documents ready for review. Pantelis Nasikas will take part in a telecon with the RIF WG in the near future on behalf of POWDER. There will be no meeting next week. Next meeting is 16th April.

The meeting began by welcoming Diana Pentecost from AOL LLC (she had participated in the WCL Incubator Activity too). The group also discussed a few administrative matters, in particular, a renewed commitment to discussing technical matters on the public mailing list rather than on the member-only list. The bulk of the meeting was concerned with possible approaches to resource grouping. One such approach—an evolution of what has been discussed in the XG and latterly in the WG—is described in an e-mail to the public list. Andrea Perego is working on an alternative approach based on N3 Rules. There will be a post to the public list on this very shortly. The former method presents the data needed to define a group of resources and leaves it to implementers to decide how to actually process it. The latter presents one or more rules to be applied to a given resource to decide whether it is a member of a group or not. There are advantages and disadvantages on both sides which should prompt further debate. Finally, the group discussed holding a public/press event allied to a face to face meeting in Washington DC in early July. This will allow group members to present their view of POWDER and its potential.

The meeting welcomed Jonathan Dugan, technical consultant at Stanford University and head of Matson Systems (www.matsonsystems.com). Jonathan brings a different perspective on the potential uses of POWDER unrelated to things like trustmarks and child protection which proves the flexibility and applicability of the technology. Good! The group looked at the recently added "History of the group" document at [1]. In particular at the strawman of Description Resources. There was a discussion over whether support for UAStrings as a condition in resource grouping broke the One Web ideal, i.e. if the metadata changed depending which device you used to access a URI, does this break the Web? Since the main intent of the One Web philosophy is to deliver content where its intended use has been maintained, irrespective of the requesting device, the usage of UAString would not be detrimental. In fact it would aid it, by making it possible to serve the request in a more device oriented fashion. For example, if a resource allows you to alter the font size but the device accessing it doesn't, then claiming that the text can be read at varying font sizes clearly isn't true. Therefore, it was decided that support for returning different descriptions based on the UAstring was acceptable (it had been proposed in the charter review period). Since DRs are wholly dependent on the grouping of resources, it was RESOLVED to begin work on the grouping document first. Work will begin on this as soon as possible. We then began to go through the open questions raised in the XGR. Open Question 1: "It is an open question whether there may be a requirement for some forms of cLabel that involve editing those resources." [2] This was discussed at length. Should we describe how to embed DRs in HTML? Video? (which format?) There is no closed list of resource types in which it may be desirable to embed a DR. Further, the essence of Description Resources is that they can describe many resources at once. There are well established methods of including metadata in resources. RDFa provides a method of including RDF triples in HTML docs. Many, if not all, online resources can include links to data and if that data needs to describe a particular resource and show that it has not changed since it was described, a hash can be used. It was also noted that processing RDFa requires more steps than following a link to external RDF and processing that. As a result it was RESOLVED "No - not a requirement." Open Question 2: Should WCL-XG be successful in securing a WG charter, the abstract model for resource grouping will itself come under full scrutiny with a view to its publication either as a WG Note or a full Recommendation in its own right.[3] It has already been resolved that the Working Group will begin work on the grouping document. Open Question 3: The mechanism for exposing properties of resources should by preference be both standard and be cLabel based. However, the precise workings of this have not been examined and are for further study [4]. This was not resolved by the end of the meeting and will be discussed again next time, however, the mood seems to be that POWDER should concentrate on providing a grouping mechanism based on pattern matching against URIs with support for explicit listing, and not concern itself with group definition by properties. The desire is to be able to describe resources without having to fetch them and have a look at them! However, POWDER should support the making of assertions - that is, statements whose veracity can be checked by retrieving the resource itself. So one can make a statement such as "all the T-shirts in the drawer are blue", the veracity of which can really only be checked by opening the draw, removing a T-shirt and noting its colour. Although we wish to support assertions like this, we are primarily concerned with describing online resources, rather than real world objects, so there is a limit to the expressivity we need to support. To be continued. Finally we briefly discussed the possibility of a short press/open event in Washington D.C. in early July where the group would present its work and the potential of the technology. Again, this discussion will be continued.

The POWDER WG's first telephone conference call allowed members to introduce themselves and for the establishment of various logistics. It was resolved that the regular weekly meetings will take place on Mondays at 17.00 Central European Time, i.e. 08.00 PDT, 11.00 EST, 16.00 UK, 17.00 CET, 18.00 EET. The first such meeting will be on Monday 19th March. Details of the first face to face meeting were discussed. There will be a joint meeting with Mobile Web Best Practices on Thursday 26th April from 14.00 and a full day dedicated to POWDER on Friday 27th. Meetings to be held at Deutsche Telekom's premises in Darmstadt. The group resolved to report its activities through a public blog in addition to its public mailing list. Chair to produce summaries of each meeting to be circulated to the member only list prior to publication ca. 2 days after the meeting (this is the first such entry). Dave Rooks (Segala) and Andrea Perego (Candidate Invited Expert from UNINSUBRIA) will act as editors of the expected Recommendations: Description Resources and Resource Grouping respectively (with help from the rest of the group!) Finally, the list below shows the people identified to act as liaisons with other W3C working groups cited in the charter: Mobile Web Best Practices (Kai Scheppe) Rule Interchange Format (Pantelis Nasikas) Web Accessibility Initiative (WAI) (Alan Chuter/Dave Rooks) Technical Architecture Group (Kai Scheppe) Semantic Web Deployment Working Group (Kjetil Kjernsmo/Phil Archer) Device Independence Working Group (Kevin Smith) XML Activity (TBA)