wdr:certifiesto 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:certifiedByare 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:certifiesshouldn'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-1or a more generic
wdr:hashwith a separate
wdr:hashAlgorithmpredicate?) 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.
dc:description) will normally be a summary of the whole DR but this doesn't prevent a
dc:descriptionbeing 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:includepredicate 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
includeHostsmandatory 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.
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:
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:
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:
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" />
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.
<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.
owl:unionOfetc) or with white space separated lists as values of RDF properties. There is precedent for this in XHTML's role and link's
relattribute — i.e. they both take white space separated lists. Multiple set definitions that are presented as part of an RDF
Collectionseems 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.
hasIpwill take a single IP address as its value, and
hasIpRangewhich 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.com.cnetc. 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.
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
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
<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.
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 (
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 '
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.
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.