W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

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

From: David Orchard <dorchard@bea.com>
Date: Mon, 27 Jan 2003 11:21:24 -0800
To: "'Tim Berners-Lee'" <timbl@w3.org>, "'Tim Bray'" <tbray@textuality.com>
Cc: "'Roy T. Fielding'" <fielding@apache.org>, "'Sandro Hawke'" <sandro@w3.org>, <www-tag@w3.org>
Message-ID: <00cd01c2c63e$fd34c080$990ba8c0@beasys.com>

TimBL,

I reread your message many times.  BTW, I sadly have to say that I only have
time to read messages posted by TAG members on this thread due to the
"firehose" effect.  I must also admit I haven't really understood what new
information has come up that would cause us to re-open the deferred issue.

I just don't get where you are going with this message.  Everything sounded
to me like you agreed with Tim Bray.  Ambiguity bad.  And you said "expect
to get essentially the same thing", not "must get essentially the same
thing".  I do apoligize again for not being able to track all this, but
isn't this one of the key points, that URIs do allow for ambiguity about the
ephemeral resources (aka spoons?) and Semantic Web has to live with it?

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Tim Berners-Lee
> Sent: Sunday, January 26, 2003 6:23 PM
> To: Tim Bray
> Cc: Roy T. Fielding; Sandro Hawke; www-tag@w3.org
> Subject: 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 Monday, 27 January 2003 15:04:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:15 GMT