 |
 |
Mike Taylor wrote: > Going back to someone's point about living in the real > world (sorry, I forget who), the Inconvenient Truth is that 90% of > programs and 99% of users, on seeing an http: URL, will try to treat > it as a link. They don't know any better. > And they can't know any better because there is no discernible difference to either a human being or a program. There is nothing about an http URI that tells you what it is being used as and whether there is anything at the other end until you send it out over the net where it will be processed by http.[*] So we have two things that are identical in form but very different in what we can do with them. Isn't this a bad idea? There are probably solutions to this; perhaps a particular port that indicates that the identifier cannot be dereferenced (I'll suggest 666) or one that gets data about the resource identified (11111 would do). But it seems to me that the best solution is to use a URI scheme that isn't the same as a URI scheme that is already used for a protocol. And before someone comes up with the statement that when you have a URL you don't know beforehand if you will get something or will get a 404 error, and therefore it's the same as a URI, let me remind you that 404 is indeed an *error code* that means 'Not found', which implies that *not finding anything* is an error. It can't, however, tell you if there *should* have been something there, or if there never was supposed to be something there, but it does mean that an error has occurred.And if you want to make the argument that one could return some other http return code, that implies having some program responding to the URI in response to http, which is a form of derefencing. If you're going to do that, you might as well include some real info about the thing identified. kc [*] This is one of the things that I've always disliked about the DOI -- it is an identifier for the resource, but it doesn't necessarily resolve to the resource. In fact, some DOIs resolve to the resource, some resolve to a page with metadata for the resource, some go to a publisher's home page and the resource isn't available in digital format. I understand why this is the case, but it makes it hard for humans and machines because isn't clear what you will get when you dereference a DOI (and you are encouraged to dereference them because they are a sales mechanism). I think that not getting what you want and expect when clicking on a link is one of the things that discourages users (machines just trundle happily along, but many of us are not machines). -- ----------------------------------- Karen Coyle / Digital Library Consultant [log in to unmask] http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet fx.: 510-848-3913 mo.: 510-435-8234 ------------------------------------