Post details: Resolution of Open Questions from the Web Content Label XG in POWDER

Friday, January 16th 2009

Permalink 01:56:05 pm, Categories: Meeting summaries

Resolution of Open Questions from the Web Content Label XG in POWDER

The POWDER WG was formed following the Web Content Label Incubator Activity (WCL-XG). In its final report, the XG noted a total of 17 Open Questions, all of which have been resolved by POWDER. Note that cLabel was the term used in the XG: the equivalent term in POWDER is Description Resource (DR)

OQ 1:It is an open question whether there may be a requirement for some forms of cLabel that involve editing those resources.
The use cases presented do not call for DRs to be embedded within the content they describe. On the contrary, the expected use of POWDER strongly suggests that DRs should always be separate.
OQ 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.
The abstract model developed in the XG is the basis for POWDER: Description Resources (a recommendation track document).
OQ 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.
The mechanism is fully developed in POWDER.
OQ 4:If successful in securing a WG charter, the group will need to address how to resolve situations in which scoping statements do not match.
The WG has taken the view that it is not practical to make it impossible for DR authors to create scope statements - now called IRI sets - that do not conflict. The Outline Methodology section of the Grouping document together with the short section on the safe use of regular expressions make it clear that mistakes are possible. A simple to use tool has been created to allow DR authors to develop and test their IRI set definitions.
OQ 5:It is an open question as to whether access to label repositories should be governed by a standard protocol.
OQ 6:It is also an open question as to whether a repository should provide a bulk data transfer capability alongside whatever capabilities it offers for transfer of description, cLabels and packages.
Open Questions 5 and 6 are covered by Section 4.4 of the Description Resources document.
OQ 7: HTTP Link Header
The group has been active in promoting the reinstatement of the HTTP Link Header and in the discussion surrounding the registration of relationship types. The relevant Internet Draft is very likely to reach RFC status during the first half of 2009 - shortly after the anticipated time when POWDER will become a Recommendation. The WG therefore has retained discussion of HTTP Link in its documentation but has flagged the relevant section as informative.
OQ 8:The form of authentication and certification mechanisms for cLabels requires further study.
This remains true - however, such a study is to be carried out by the individual labelling authority such that an appropriate mechanism for the particular application is implemented rather than demanding a single 'one size fits all' approach. POWDER provides a number of features designed to allow various authentication methods.
OQ 9: There is also work to be done to more clearly define the roles of various players in the trust chain, such as labeling authority, certification provider etc.
Section 5 of the Description Resources document discusses several different trust models that might be applied to POWDER.
OQ 10:It is not clear how labels on transcluded elements relate to any labels on the content that initiates the transclusion.
The word 'transclusion' was misused here, however, it is the nature of HTTP and RDF that each description of a resource is made and processed separately. Therefore, elements within an HTML page may well have different descriptions from the page itself. DR authors should be aware of this.
OQ 11:It is not clear whether it is useful or necessary to identify individual portions of content and to assign them individual labels, or to be able to provide labels that refer only to the resource without any transclusion.
It was resolved that fragment identifiers would not be part of the grouping mechanism. However, they may be supported in the extension mechanism as discussed in Section 2.1 of the Grouping document.
OQ 12:It is also not clear how redirection of HTTP requests affect the interpretation of a cLabel that refers to the non-redirected URI but does not refer to the result of redirection.
This was resolved in relation to the conformance criteria for a POWDER Processor which SHOULD NOT, where IRI1 is in scope of a given DR and dereferencing it redirects to IRI2, automatically treat IRI2 as also being in scope of that DR.
OQ 13:It is not clear how the requirement that each cLabel must have a unique identity, so any modification to it, such as renewing its validity period, will result in the creation of a new cLabel, with a new URI fits in with the operation of large scale workflows, which cannot easily accommodate changes in associations between content and their labels, and consequently this is for further study.
This is covered in the Primer which advises the creation of a 'latest version' link which would redirect to the appropriate POWDER document.
OQ 14:On a related note, the group discussed the relationship between the validity of the label and the cache headers that may be attached to it, but came to no clear conclusion on this. One suggestion is that clients should not be required to use the valid-until date in a cLabel to decide whether to fetch the resource. LA's would be encouraged to use HTTP response cache features, e.g. by setting Cache-Control: max-age to correspond to the appropriate valid-until date.
This issue was resolved and is discussed in Section 5.2 of the Description resources document.
OQ 15:[This section is subject to further review and elaboration - e.g. which terms are mandatory, which are optional, how to provide a unique identifier for the vocabulary. Note also that some of the terms suggest that labels can be altered, and there is an open question as to whether this is in fact possible, given that each instance of a Content Label must have a unique and unambiguous ID. Equally it is important that when a label is 'renewed' that it is not then necessary to change all references to it. It may be possible to work around this by accessing labels by 30x redirection, but the rules applications would be required to follow remain to be discussed ]
The POWDER-S vocabulary is fully defined with a namespace document at http://www.w3.org/2007/05/powder-s. It is a minimal set of terms and classes that can be built on to suit different application environments.
OQ 16:If successful in securing a WG charter, WCL will need to define additional terms for certifying labels. Also, it may be possible to define tests for some of the vocabulary terms.
See Section 5 of the Description Resources document.
OQ 17: If successful in securing a WG charter, WCL would seek to:
— Produce a normative encoding of the WCL model in RDF. This would, of course, take into account any changes made to the model made by the WG itself. The discussion would be likely to include sample SPARQL queries etc. and guidance on making data available for property-based resource grouping.
— Show examples of cLabels encoded using RDFa.
— At least sketch encoding cLabels entirely in XML.
All of these features are present. The Description Resources document encodes the WCL model in both XML and RDF and includes an example of linking to a DR using RDFa. Sample SPARQL queries are provided in the Section 5 of the Formal Semantics document.

Having conducted this review, the working group therefore contends that the open questions posed in the incubator group have been answered.

Phil Archer,
POWDER WG Chair
16 December 2008.

Phil ARCHER

Comments, Pingbacks:

No Comments/Pingbacks for this post yet...