- From: Joshua Allen <joshuaa@microsoft.com>
- Date: Mon, 22 Apr 2002 13:53:56 -0700
- To: "Dan Brickley" <danbri@w3.org>, "Tim Berners-Lee" <timbl@w3.org>
- Cc: "Aaron Swartz" <me@aaronsw.com>, "Sean B. Palmer" <sean@mysterylights.com>, "Mark Nottingham" <mnot@mnot.net>, "RDF-Interest" <www-rdf-interest@w3.org>
> Why make work for ourselves? What worldy benefit is there in coming up > with criteria for splitting the world into two huge disjoint categories: > 'things that can be named with http:-uris, and things that can't'? Sure, > the HTTP spec has woolly words about network / informational / resources But isn't that the problem with adding unnecessarily gratuitous ambiguity to something that most people consider to be a "web page"? It *is* making unnecessary work to say that an http URI identifies a car. And this doesn't apply to just http: URIs BTW, it also applies to mailto: URIs, etc. Why not just say that a mailto: URI identifies a mailbox, and anything else will require disambiguation? The argument that says that a mailto: or http: *should* be permitted to represent a car is the same argument as one that says that we should never just assume that someone *means* "bad" when they say "bad", because sometimes "bad" means "good". But you don't interrupt every utterance that uses the word "bad" and ask the person to disambiguate whether they mean "bad" in the Michael Jackson sense or not. In general, "bad" carries a default connotation, and other connotations have to be carefully disambiguated. I think it is entirely appropriate to do the same with http: and mailto: URNs. -J (A
Received on Monday, 22 April 2002 16:54:10 UTC