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

 >Using http://handle.org/ or some such

Right. In fact, that has been the case for some years now -- so this
handle (a DOI)

10.1000/170

can be resolved using a proxy server such as

http://hdl.handle.net/10.1000/170 or http://dx.doi.org/10.1000/170 or
http://hdl.loc.gov/10.1000/170

or in a URI-type syntax as

hdl:10.1000/170

which uses the handle protocol directly and which is, not surprisingly,
more efficient for handle resolution, but of course requires software
such as a browser extension that understands it, as a URI. To the best
of our knowledge most handle resolution currently goes through one or
another proxy server.

Larry

"Martin J. Duerst" wrote:
 >
 > 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 Thursday, 11 May 2000 02:00:49 UTC