Re: Subgroup to handle semantics of HTTP etc?

On Oct 22, 2007, at 12:53 PM, Richard Cyganiak wrote:
> The point is that it partitions resources into two kinds: message- 
> conveyable resources, and other resources. And it establishes an  
> axiom, that a 200 response means we have a message-conveyable  
> resource.

Yes, but we don't convey the resource. We only convey a  
representation. To rephrase what you have said, my interpretation is  
that a 200 response means that we have denoted a resource,  
representations of which can be conveyed. However, there is nothing  
that I see that would indicate that the message receiver is  supposed  
to be able to reconstitute the "resource" from the message that is  
received. In fact, I would say we'd be pretty lucky in many cases if  
we are able to infer what resource is being denoted, mostly because  
of the uncertainty around what a representation actually is (other  
than a tuple of a series of bits and a mime type)

> therefore the URI identifies something message-conveyable,  
> therefore it cannot be a person, therefore it must identify just  
> the document.

Here is where the logical fails. There are many things that this can  
be if not the person. I'll leave this to your imagination, but do  
challenge me if you can't see more than the one choice once prompted.

> The value of httpRange-14, in my eyes, is simply this: It affirms  
> that web page URIs still identify web pages, even in the Semantic Web.

Web pages "the generic". This says that the URI identifies something  
that could have a representation which is html, or jpeg, or svg. But  
there is still a desire to be able to identify each of these  
individually. It matters, for instance, who you hire to do an update  
to each of these - they require different tools and skills to change.

It seems to me that if you want to be able to denote these with a  
URI, you are forced to accept that the appropriate response for a web  
server is to respond 303.

Remember the test I proposed, that you seems to agree to? If it's an  
information resource, you can't get a checksum of it. If you can  
checksum it, it can't be an information resource. Each of the three  
items I have suggested I want to denote have can be checksummed.

> I like the "Halpin Test" [1]:
>
> "I would say that if there is a URI that is used to identify a  
> resource one would want to make logical statements about, and these  
> statements do not apply to possible representations of that  
> resource, then one should use the "hash" or 303 redirection to  
> separate these URIs."
>
> To me, that's good enough as an every-day sniff test.

A good test, indeed. But suppose I am looking from the outside and  
want to make a statement about such resources. In other discussions  
we've concluded that pretty anything goes as far as what the possible  
representations can be. How am I, not the owner, able to figure out  
what the possible resources are? And what happens when I want to say  
more creative things than the owner thought of, things that do not  
apply equally to all the representations that she serves?

An how can I, as resource owner, decide that I want to mint a URI to  
denote things that some might call representations? How am I to do  
that. Take, as an example,  the zip files on http://mirror.nyi.net/ 
apache/lucene/java/ which has the following instructions.

It seems to me that it's pretty hard to argue that http:// 
mirror.nyi.net/apache/lucene/java/lucene-2.2.0-src.zip isn't intended  
to denote something that can be checksummed, hence not a resource.

-Alan

ps. Looking forward to having a drink together wednesday :)
> Signatures
>
> Many of the files have been digitally signed using GnuPG. If so,  
> there will be an accompanying file.asc signature file in the same  
> directory as the file (binaries/ or source/). The signing keys can  
> be found in the distribution directory at <http://www.apache.org/ 
> dist/lucene/java/KEYS>.
>
> Always download the KEYS file directly from the Apache site, never  
> from a mirror site.
>
> Always test available signatures, e.g.,
> $ pgpk -a KEYS
> $ pgpk lucene-1.4.tar.gz.asc
> or,
> $ pgp -ka KEYS
> $ pgp lucence-1.4.tar.gz.asc
> or,
> $ gpg --import KEYS
> $ gpg --verify lucene-1.4.tar.gz.asc

Received on Monday, 22 October 2007 20:22:34 UTC