POWDER Working Group Blog

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.