I'm not neccesarily arguing anything. I think either way _could_ work,
or _could_ end up not working as well as the other one.
I think that it's harder for someone to mint an info uri without knowing
what they are doing. If a uri is in the info registry, you know someone
at least had to think about it.
If you just happen to find an http URI on the web.... you don't even
know that someone meant to "mint a URI" at all, it might have been
intended merely for resolution via the HTTP protocol.
If it _was_ intended as a URI, and controlled appropriately, then indeed
it can do anything an info: URI can do, I agree.
>> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
>> Jonathan Rochkind
>> Sent: Wednesday, April 01, 2009 1:23 PM
>> To: [log in to unmask]
>> Subject: Re: [CODE4LIB] resolution and identification
>> Houghton,Andrew wrote:
>>> Organizations need to have a clear understanding of what they are
>>> URIs for.
>> Precisely. And in the real world... they don't always have that.
> Then one could contend that they should not be minting URIs, this is
> why they get into trouble. No clear policy on what a URI identifies,
> when is it appropriate to create aliases and when URI aliases are
> created making sure you use appropriate HTTP mechanisms to redirect
> them or indicate that they are URI alias. They also need to understand
> the difference between URIs for Real World Objects, Generic Documents
> and Web Documents. Failure to understand these issues and you will
> create a mess.
>> ONE of the benefits of info is that the registry process forces minters
>> to develop that clear understanding (to some extent), and documents it
>> for later users. There are also other pros and cons.
> Right, but your argument seems to be that you have all these HTTP URIs
> so rather than sort it out, using appropriate standards based mechanisms,
> lets create yet another URI to add to all the other URI aliases?