RE: Documents, Cars, Hills, and Valleys

> 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

Not true.  Every user that actually is forced to use a URL is quite
aware that they are getting "a web page".  This is exactly the language
that people use to talk about what they are doing when they type a URL
into their browser's location bar.  Ask any person off the street, "if
you type in something like http://blah into a web browser, what do you
get back?"  They will tell you "a web page".  Then ask them, "If I type
http://www.news.com, do I get back a web page with the news on it?" they
will say "yes".  Users are not so stupid or mystified as you seem to be
implying.

> to the information content, which is the "real" resource from their
> POV.

People are quite aware that "the news" is not something that exists
independent of being published by humans, editors, writers, etc.

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

You are confusing only yourself.  The fact that language can be
deconstructed and ambiguities can be artificially introduced is no
excuse for abandoning clarity.

> I'm simply proposing that we align or understanding of URIs with
> current practice rather than some change which demands use-cases in

Please show me a user who knows what a URL is, but doesn't think a URL
points to a "web page".  I am exactly saying that we should align with
current practice and stop trying to be too clever.

> 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

This is a totally orthogonal issue.  A namespace URI is a unique name,
period.  Until you need to make statements about a namespace or
dereference a namespace, then you don't need something that identifies
"the namespace".  When you *do* need to make assertions about a
namespace, use tdb.

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

No, I disagree.  The namespace URL in an XML doc is not being
"interpreted" as referring to any resource.  Maybe *you* think of it
that way, but the software just treats it as a unique name.

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

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

As far as I am concerned, the scheme: disambiguates the URI just fine.
Certainly further disambiguation may be necessary for schemes that are
less specific (like urn:), but I see no rational argument for trying to
override the clear and obvious semantics of schemes like http: and
mailto:

Received on Wednesday, 10 April 2002 15:10:06 UTC