Archives for: April 2007

Monday, April 30th 2007

Permalink 12:00:00, Categories: Meeting summaries

Meeting Summary - 30 April 2007

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.
Cédric Kiss

Friday, April 27th 2007

Permalink 12:00:00, Categories: Meeting summaries

Meeting Summary - 26, 27 April 2007

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

Cédric Kiss

Monday, April 16th 2007

Permalink 12:00:00, Categories: Meeting summaries

Meeting Summary - 16 April 2007

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.

Cédric Kiss

Monday, April 2nd 2007

Permalink 12:00:00, Categories: Meeting summaries

Meeting Summary - 2 April 2007

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.
Cédric Kiss