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

On Thursday, Jan 1, 1970, at 03:23 US/Eastern, Tim Bray wrote:

>
> 1. Antarctica's Visual Net
>
> 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 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.


>   That is to say, the representation returned by any one dereference 
> is not fundamental; it is ephemeral and neither the users nor the 
> programmers would for a second consider it to "be" the resource.

No, absolutely not.  Your example is a great one.

>  It feels perfectly comfortable to say that each of these URIs 
> identifies a resource and that our software emits representations.  It 
> feels perfectly natural to make RDF assertions about particular URIs 
> in the space without worrying about what representation you might see 
> next.  I'm sorry, I don't think these URIs identify web pages; they 
> identify resources.

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.


> 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.
In RDF one would to be clearer probably have written
  "foo: "     xml:namespace   <http://example.com/2003/foo#namespace>.

> Concluding notes:
> (a) In both of my examples, the resources identified by the URI map 
> fairly nicely onto the actual meaning of the English word "resource" - 
> one of Antarctica's maps is a resource in human-speak (that's why 
> people pay for the software), and if an XML Namespace (typically a 
> pre-coooked XML vocabulary with pre-cooked semantics) isn't a resource 
> as the word is normally used, I don't know what is.  My point is not 
> only is the Fielding formalism useful to programmers and 
> self-consistent, the terminology is useful to ordinary people.
>
> (b) In my vision of the semantic web, it makes all sorts of sense to 
> package up RDF assertions about Antarctica's maps or XML namespaces 
> and these could be really useful without pretending, against the 
> evidence, that either kind of URI actually points at a "web page".
>

I think Roy and I would agree that your maps are resources.  But 
resource is a term which is only defined as "that identified by a URI", 
so what does that mean?

Well, lets look at what its for - reference. If I access some thing -- 
say one of those maps -- and I refer a friend to it by URI, then I 
expect that friend to get essentially the same thing.     The essential 
message is the same.  If I refer someone to the repair manual for a 
robot, and they get an audio version, the web has worked.  If I refer 
someone to a repair manual for the robot and they get a sales brochure, 
it hasn't.
As you have said often and eloquently, ambiguity is basically bad.

- Time-varying documents ("the front page of the NYT") are important 
and valuable.
- Content negotiation is important for allowing technology evolution 
(GIF to PNG).
- Content negotiation is important for device independence, 
accessibility, and Internationalization.

Note that in the content negotiation cases it is really important that 
the essential
import or essence of all representations of the same resource be as 
close as possible.
Any difference is a regrettable compromise made necessary by 
circumstances.
Otherwise, I can agree to the "Terms and Conditions" and find that I've
agreed to a buy a timeshare condo.  Or whatever.

I do not think that content negotiation should be used for returning 
human-readable and machine-readable versions unless the human-readable 
versions of the document have been generated from the machine-readable 
ones, or one has otherwise ensured that they mean the same thing.





> -Tim

Received on Sunday, 26 January 2003 21:22:53 UTC