RE: Documents, Cars, Hills, and Valleys

Joshua Allen wrote,
> > 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.

Not so. With the printer/scanner right here I can do a POST and have 
it suck in a document from its feeder tray and scan it. If that isn't
manipulating the device then I don't know what is.

It's quite true that I do this _by_ interacting with a document, but
I see no reason why either interaction should cancel the other out.
Both are happening, and which one you pay attention to is likely to
be determined by your interests (eg. if you're concerned with printers
you'll pay attention to the printer-action; if you're concerned with
web interfaces you'll pay attention to the document-action).

This isn't a particularly uncommon phenomenon either on or off the
web, eg. for a text book example, you turn on a light by flipping a
switch: the switch flipping doesn't trump the light illuminating.
Most of the time you're only interested in the light and the switch
is an irrelevant detail; OTOH, if you get a shock when you flip the
switch ...

> > purchase are you dealing with the vendor or a document?
>
> You are submitting a document (a purchase order).

You're doing both: making a purchase _by_ submitting a document.

> You have no guarantees that the vendor will ever even see your 
> purchase order or do anything about it.

True, but not unique to the web.

> > 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.

I think this is the crux of the argument.

I disagree, and I think you have it almost exactly the wrong way
around. Most web users are completely oblivious to both HTTP and the
documents transferred over it. Insofar as they think about it at all,
http://news.bbc.co.uk/ refers, not to a document, but to "Todays news
from the BBC", IOW they "see through" the protocol and the document
to the information content, which is the "real" resource from their
POV.

Insofar as meaning is determined by use this implies that in the
general user community URIs, http: or otherwise, typically don't
identify documents.

Naturally the general user community isn't the only one, and other 
communities have their own idiolects. In particular, the community
concerned with web infrastructure might well see things differently.
But then that's just to say that the URIs on their own are ambiguous:
specifying an idiolect would be one way of resolving that ambiguity.

> Or look at it yet another way; what clear use-cases exist today for
> saying that an http:// URI does *not* identify a document?

I'm simply proposing that we align or understanding of URIs with
current practice rather than some change which demands use-cases in
justification. It's current practice in the general user community to 
think of URIs as referring to things other than documents.

For that matter, what about the XML developer community? As things 
stand a namespace URI refers to an abstract (ie. non-retrievable) 
resource rather than any particular document. IMO many of the problems 
we've had with the interpretation of namespace URIs boils down to 
trying to square the circle of having a supposedly unambiguous URI 
refer simultaneously to two or more distinct resources.

> What are the scenarios that we break by saying that an http:// URI 
> always identifies a document?

Almost all the scenarios which matter to the general user community.

Online purchases are a good example. There's an implicit contract
involved in sumbitting a credit card number: an agreement between
the purchaser and the vendor that the vendor will deliver the goods
and that the purchaser empowers the vendor to bill their card. In
most legal systems contracts can only be made by legal persons ...
documents aren't legal persons.

> > 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.

I completely agree that RDF is in a awkward position here. But I don't
think that denial will help. You've already provided the answer ... 
you add some extra metadata to disambiguate ambiguous URIs.

Cheers,


Miles


**********************************************************************
This message is intended only for the use of the person(s) (the "intended recipient (s)") to whom it is addressed. It may contain information which is privileged and confidential. 
If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views of InterX plc. Any copyright in this message shall remain vested in InterX plc and the intended recipient may only copy the same for internal business purposes or as otherwise stated in this message.

**********************************************************************


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. 
http://www.star.net.uk
________________________________________________________________________

Received on Wednesday, 10 April 2002 06:00:11 UTC