Re: [Fwd: Re: Approval of initial Dublin Core Interoperabiity Qualifiers]

At 00/05/05 09:21 -0400, Ray Denenberg wrote:
>Leslie Daigle wrote:
>
> >         c) URN is well-defined: there is a URI scheme, URN:,  ......
>
> >
> > Thus, hdl: ...... can be one or both of:
> >
> >         1. a URI scheme ...
> >
> >         2. a URN: namespace (i.e., carried in URNs).
> >
>
>Both the "one" and the "both", of "one or both", trouble me.

I can understand that. There is a famous saying in standards:
'The nice thing about standards is that there are so many
to choose from.' :-).

You would have an easier life if there were less choices, but
we already have these choices, and can't go back anymore.

There are many more situations in your life where you have
to choose. Do you offer some files over http or ftp? What
browser and other software do you use? What clothes do you
buy and wear? What do you eat every day? Life is full of
decisions, and that's the joy and pain of it.

Of course, if we can create community agreement on either of:
1) URNs, as understood by the urn: prefix and the related
    RFCs, were a market failure and won't be pursued anymore.
2) URNs, as understood by the urn: prefix and the related
    RFCs, should be pushed whenever possible.
then the rest is easy. I'm not sure it's easy to find
consensus either way, but that may change with time,
and the more people we have that say 'either way is fine,
if we can agree', the easier it is.

>For the "one" scenario: thus the handle folks (CNRI) need to decide whether to
>register hdl: as a URI scheme or a URN namespace.  Assuming that hdl fulfils
>the characteristics of a URN, on what basis do they make this choice?  And
>let's say they decide to register it as a URN namespace, and then another
>company develops a scheme that similarly meets the URN characteristics but
>registers it as a URI scheme. Won't this cause confusion?

>For the "both" scenario: I'm afraid I don't understand how it could be
>registered as both; or, I suppose I understand *how* it could, but not *why*.

Well, the odds of adaption are different if you register both;
having both may decrease investment in each and thus have both
fail, or it may help at least one, and thus be successful.
It would work easily if most uses of URIs would allow to list
alternatives, but starting with
    <a href='urn:hdl:xxx'>Click here</a><a href='hdl:xxx'>or here</a>
it's clumsy at least.

There is of course a third (at least) alternative:
Use an existing URI scheme. This is less technically 'cool',
and for certain functionality or scalability, you may have to
pull some 'tricks' (but there are already well known),
but it's much easier to deploy. Deploying new schemes is
clearly *very* hard, it mostly works if there is new functionality,
so that it can be deployed with the associated hard- and software.
tel: and tv: are probably some examples that may be successful.
PURLs also prove the point. Using http://handle.org/ or some such
instead of urn:hdl: or hdl: is an alternative that should be
seriously considered. You can still use the handle infrastructure
on the back end, and if necessary you can use things such as
ECMAScript and Java on the front end, and your deployment investment
as well as the risk associated with it is virtually zero.


Regards,   Martin.

Received on Tuesday, 9 May 2000 07:42:30 UTC