RE: Documents, Cars, Hills, and Valleys

> That might have been a sustainable position once, but I'm afraid I
> don't think it can be now.

I don't buy this argument yet.

> Many, many things have HTTP interfaces allowing interaction and/or
> manipulation. When you use a web interface to a printer are you
> manipulating the printer or a document? When you make an online

You definitely aren't manipulating the printer.  You can't PUT a
printer, nor can you GET a printer.

> purchase are you dealing with the vendor or a document?

You are submitting a document (a purchase order).  You have no
guarantees that the vendor will ever even see your purchase order or do
anything about it.

> I think it's better simply not to try and choose between the
> candidate referents of a URI and single out one as canonical. Let the
> coffee pot URI be ambiguous between the document and the coffee pot,

Let's look at it another way; 99.99% of the time, when someone uses an
http://uri, they are referring to something that can be GET, PUT, or
POSTed (a document).  There are maybe 0.001% of cases where the person
wants that URI to identify a "thing" and *not* a document.  And the
cases where someone is using an http URI to refer to a "thing" are
completely non-standard and ad-hoc.  In other words, these 0.001% of
cases could just as easily use tdb: URIs, and they are only polluting
the URI space by using http:// improperly.

Or look at it yet another way; what clear use-cases exist today for
saying that an http:// URI does *not* identify a document?  What are the
scenarios that we break by saying that an http:// URI always identifies
a document?  What benefit can justify breaking the "common sense" that
an http:// URI identifies something that can be GET, PUT, or POSTed?

> you a referent. Document consumers will see a document, and coffee
> consumers will see a coffee pot: the two views are compatible.

No they are not.  How about a consumer (like an RDF database) which is
capable of seeing both documents and coffee pots?  The whole issue is
that the "tdb" of the URI is ambiguous unless you add some extra
metadata to disambiguate it.

P.S. And forcing a client to do a GET and ask for mime-types for a URI
is an absolutely unacceptable disambiguation mechanism.  If a URI
doesn't identify anything, then why call it an identifier?  If the real
"identity" comes from the mime-type list proffered through some API, why
not call the URI a "switchboard address"?

Received on Wednesday, 10 April 2002 01:36:12 UTC