Re: Does a URI identify a "web page"?

Tim Berners-Lee wrote:

Summary: TimBL and I each have world views that are self-consistent but 
have failed to convince each other.  It seems unlikely that consensus is 
going to arise on this issue, so I'm not going to say anything else 
after today until I hear a genuinely new argument, which I haven't for 
some weeks now.

>> This is the application that my company sells, of which I wrote a 
>> large part.  It is implemented as an Apache module, and presents maps 
>> of information spaces.  For a large information space with millions of 
>> objects, clearly an effectively infinite number of useful maps can be 
>> drawn.
>> [...]
>> Anyhow, no matter how far I turn my head sideways and squint, it just 
>> doesn't feel correct to say that the URIs pointing into one of our map 
>> deployments represent, in any meaningful sense, a "web page".
> 
> So I picked the wrong word!
> Well, I tried to use the vernacular to hit a well-shared concept and 
> clearly missed.
> You maps definitely count.  They *are* information objects.  Even though 
> they
> may have representations  different for different browsers, the URI
> still identifies the fundamental information object.

I suppose if you try hard enough, but I am entirely unconvinced.  There 
is no information object anywhere that corresponds to a particular map's 
URI, there is an abstract resource that you can describe quite naturally 
in human language and which our software will compute representations of 
on demand.  They need not be information objects, a printed map 
delivered in an envelope would be a satisfactory representation.

    I can't actually
> see any reason for not calling it a web page.  you can bookmark it,
> clicking on a link to it makes it show up in a browser.  The concept of
> an HTTP resource - network information object - has nothing to do with the
> hoops your software jumps through to produce it.

There is no "fundamental" information object.  The only things that ever 
have material existence are the ephemeral representations.  I don't see 
how it helps to pretend that such an object exists.

> By the way I used the lose term "web page" they certianly were.
> I am happy to call them HTTP resources, or network information objects.

It seems reasonable to distinguish resources whose URI uses the "http" 
scheme.  I just don't believe they are necessarily network information 
objects.  If you're using the HTTP protocol, the representations (if 
any) are information objects retrievable by that protocol.  The resource 
however is not necessarily an information object.

>> 2. XML Namespace Names
>>
> This is tricky.  Namespaces, which are abstract things, are identified 
> by giving the URI of a specific authoritative (even if sometimes not 
> available) namespace document.
> That works.  Unless you actually think of the namespace as the information
> in the document, it is sloppy to talk about the xmlns= things as a 
> namespace,
> just as it is sloppy to write "Spouse:" instead of "Spouse's name" (or 
> "spouses SSN") on a form. It only really matters to those building the 
> software in this case.

No, no, no.  The namespaces recommendation is 100% perfectly clear that 
the URI identifies the namespace, not any particular electronic object. 
  This is the canonical example of an abstract object.  Namespaces 
include the markup vocabularies of HTML4, SVG, and a zillion 
application-specific markup languages out there.  A claim that these 
things are "electronic objects" is not well-supported by reality.  A 
claim that they are resources is supported by RFC2396.  They work fine 
without any instantiation of any kind at all.

=====================================================

The test of any scientific theory is how well it explains reality.  The 
pure REST approach which talks about resources and representations 
explains both of my use cases straightforwardly and allows the 
construction of software with appropriate expectations.  The information 
object centric approach requires a lot of strain and 
nudge-nudge-wink-wink and is feeling increasingly like the Ptolemaic 
model of planetary orbits.

Having said that, I don't expect you to agree.

Fortunately, we agree on the best practices (ambiguity is bad, etc) so 
it is now long past time to put HTTPRange-14 on a shelf and not invest 
any more irreplaceable time in it. -Tim

Received on Monday, 27 January 2003 16:42:25 UTC