Re: POWDER: URIs or resources (1)

I think this is worse than a logical inconsistency.

It is that what the resource set formally says and how it is likely to 
be implemented don't match.

Let's take a more plausible and controversial stance ....

The Internet Freedom Example Coalition decide that they oppose all 
censorship on the web, and wish to undermine the work of ICRA and the 
others, which they perceive as censorship. So they set up their server 
so that

http://internet.freedom.example.org/get-it?http://porn.example.com/

effectively gets http://porn.example.com/ (with a hidden server side 
redirect)

so that it would be possible to see

http://internet.freedom.example.org/get-it?http://porn.example.com/

as an alias for

http://porn.example.com/

i.e. both URIs identify the same resource.

However, in practice, most POWDER implementations will be unaware of 
this fact, and a resource set such as

<ResourceSet>
   <excludeHosts>porn.example.com</excludeHosts>
</ResourceSet>

which, according to my reading of WDs, does, supposedly also exclude

http://internet.freedom.example.org/get-it?http://porn.example.com/

would, operationally, not exclude.

This divergenece between the effective operational semantics and the 
formal semantics strikes me as a 'bad thing'.
Since we know that operationally a POWDER processor will work with URIs 
not resources, I feel that a formal definition in terms of URIs is 
likely to be closer to the day-to-day realities than one in terms of 
resources.

Jeremy


Phil Archer wrote:
> 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...
> 
> Phil.
> 
> [1] 
> http://www.w3.org/blog/powder/2007/11/10/summary_of_face_to_face_meeting_held_dur_2007 
> 
> [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 14:56:25 UTC