W3C home > Mailing lists > Public > www-archive@w3.org > December 2007

Re: POWDER: URIs or resources (1)

From: Phil Archer <parcher@icra.org>
Date: Mon, 17 Dec 2007 13:56:54 +0000
Message-ID: <47668026.2040505@icra.org>
To: Jeremy Carroll <jjc@hpl.hp.com>
CC: www-archive@w3.org, "Carroll, Jeremy John" <jeremy.carroll@hp.com>, Dan Brickley <danbri@danbri.org>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, Ivan Herman <ivan@w3.org>, Bijan Parsia <bparsia@cs.man.ac.uk>

We (the WG) are aware of this kind of problem. The original model (i.e. 
the one described in the currently published docs) and the OWL/sub class 
model that we have been considering moving to since TPAC [1] both make 
it easy to make mistakes.

We have a section on this in the grouping document [2] which includes 
the line: "...it is perfectly possible to create a set definition that 
includes logical inconsistencies. A POWDER processor MUST, indeed can 
only, treat such Resource Set definitions as the Empty Set."

It's something we have discussed a lot - should we make it impossible, 
or at least, as difficult as possible, to make mistakes? In the end, we 
decided that no, we wouldn't. That's not blind arrogance, it's based on 
the fact that we expect policy makers (i.e. legally-minded cf. 
technically-minded people) to be involved in the DR process. The use 
cases are all pretty simple and, we for the most part, will simply 
define a resource set in terms of a domain name (as do the majority of 
current ICRA labels for example). Creating a complex resource set that 
includes and excludes sections of Web sites would be an exceptional use 
case. Whilst we don't wish to preclude uses in more complex situations, 
the essentially simple case should remain simple.

Not sure if that helps this along any...


[2] http://www.w3.org/TR/2007/WD-powder-grouping-20071031/#inconsistent

Jeremy Carroll wrote:
> A different point, that I didn't articulate in the summary message, and 
> which I hope reveals that the careful thought required by the 
> disciplines of RDF semantics has some value ...
> Consider the following example.
> foo.example.com and bar.example.com are sister sites
> They mirror each other in the following way:
> foo.example.com/bar  corresponds to bar.example.com
> and
> bar.example.com/foo corresponds to foo.example.com
> so that
> http://bar.example.com/foo/bar/foo/index.html
> returns
> http://foo.example.com/index.html
> which is in fact the same as
> http://foo.example.com/
> This means that every resource on both sites as an infinite number of 
> different URIs which identify it. (We may question the wisdom of the 
> example.com site design, but the designer thinks its sexy).
> Now, the /foo and /bar prefixes might be a bit of a nuisance, so perhaps 
> we should create a resource set that excludes them, i.e.
> <wdr:ResourceSet>
>   <wdr:includeSchemes>http</wdr:includeSchemes>
>   <wdr:includeHosts>example.com</wdr:includeHosts>
>   <wdr:excludePathStartsWith>/foo /bar</wdr:excludePathStartsWith>
> </wdr:ResourceSet>
> Does this resource set include http://foo.example.com/
> I suggest that the only reasonable intent is that it should, but that, 
> according to the current WD, it does not.
> As described above, http://foo.example.com/ is an alias for
> http://foo.example.com/bar/foo/, so the resource identified by 
> http://foo.example.com/ also has a URI http://foo.example.com/bar/foo/ 
> which is excluded, by the wdr:excludePathStartsWith
> From:
> http://www.w3.org/TR/2007/WD-powder-voc-20070925/#excludePathStartsWith
> [[
> This property defines a set of resources, that have a URI path component 
> starting with at least one of the values given in a white space 
> separated list, that is to be excluded when interpreting a Resource Set 
> definition.
> ]]
> ===
> The underlying problem is that naively we think of resources and URIs as 
> in one-to-one correspondence, but in fact it is one-to-many
> Jeremy
Received on Monday, 17 December 2007 13:57:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:17 UTC