Re: Documents, Cars, Hills, and Valleys

>> You manipulate and view it with things that you
>> might call 'documents' (although I prefer Jeff Mogul's attempt [1] at a
>> more precise terminology).
> The documents however, and the cars are different, for HTTP.
> This is not a property of URIs. It is a fact of HTTP.

Of course. However, the documents/representations/instances are not 
identified by the URI; the resource is.

When you see a car, you're perceiving light bouncing off it; however, 
when you say "that car," you mean the car, not the light.

>> Otherwise, what are CGI/ASP/JSP/CFM/PHP/XSLT/etc. scripts?
> They are not themselevs on the web. As Roy would say, don't confuse
> the resource with its implementation. If your home page is implemented
> with a cgi script, that doesn't mean it *is* a cgi script.
> Some php3-implmeneted resources actually have a link to the php3-script
> as a separate resource.  That asside, the script isn't a resource on
> the web any more than the cooling fan of the server which runs the 
> script is
> the resource.

Exactly. So, what is "the resource" in this case? 
is generated by XSLT (by an offline process, but lets put that aside for 
a second). Its representations are composed from a template and a few 
RSS feeds; there is no single "document" that is identified by

I'd characterise this particular resource as a bunch of information that 
I'm interested in telling other people, including some links; it's 
information (quite convenient, seeing that everyone seems to agree the 
Web is an information space). While that (and much of the information on 
the Web) is abstract, I think people here are asserting that information 
can also be concrete.

> Because if you adopt the notion that
> <http;//> a :Person.
> I would be forced to conclude that you, Mark, will expire
> alas too soon: [1]
> Expires: Thu, 11 Apr 2002 09:14:08 GMT
> <> a :Person;
>          http:expires "20020411T091408".
> which gives you only a few hours. Sad.

Ah, I won't be killed that easily! Expires indicates the freshness 
lifetime of the representation, not the resource.

(In fact, if you perform your request again (and again...), I think 
you'll find that I have a new lease on life; if I can keep that server 
up, I'll achieve immortality! Lucky it's running Unix... (Note to self - 
thank mod_expires author profusely))

>> Because AFAIK all homepages *are* documents or scripts or some other
>> form of machine-based state, not gateways to people (counterexamples
>> gratefully accepted). This situation, however, shouldn't be used to
>> justify a restrictive characterisation of the resources which happen to
>> be identified with the scheme 'http'.
>> It may be interesting to look at other schemes and see how they 
>> restrict
>> what is identified. From what I can see, schemes which can be
>> dereferenced - whether it be imap, ftp or tel - tend to restrict how 
>> you
>> access something, rather than define what something is. A 'tel' URI
>> might identify a person, an answering machine, or dial-a-date.
> That would be very fuzzy thinking.  The notion of a telphone number is
> a very commonly understood one.  They have certain very nice properties.
> You can use them indirectly, through a property to identify someone
> but they are NOT that person.   a "tel:" URI does not identify
> a person (idenify in the sense of the I in URI).
> You can write
> :mark a :Person;  contact:home [ contact:phone "+1-123-456-7890" ].
> and that may indeed identify Mark.  And the concepts of  home
> and phone number as relationships may be good or bad or indifferent in
> your application. But the phone number space identifies endpoints
> in the POTS protocol, things with which there is an expectation
> (from the POTS protocol definition) that
> one can establsih some form of limited bandidth communication
> but that is all.

Well, I'm glad I fuzzed over this way; your explanation is illuminating. 
You seem to be saying that URIs identify endpoints which might act as 
interfaces to resources, instead of the resources themselves (or at 
least in some schemes). Correct?

>> On that point, I'm a bit surprised that TBL advocates the document view
>> (or perhaps I just misunderstand the framing of the issue).
> I only advocate it for HTTP.
> You, your home page, and your phone number are all distinct.
> It is important never to give the same URI.
> Properties make it trivial to indirectly identify someone though their
> home page or their telephone number.
> In natural language, these things don't matter, but when building
> machines, they do.

I don't disagree with this; however, I don't think it's necessary or 
correct to limit the identifying capabilities of HTTP URIs to 
"documents" in order to achieve this.

Received on Wednesday, 10 April 2002 22:26:51 UTC