[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-info] Please help me understand the value of Handle



Opps. Cut and paste error resulting in one too many slashes. Please make that

http://dx.doi.org/10.1045/july2006-tansley

But it was a great opportunity to see a customized handle not found error for DOIs.

(Thanks to Stanley for pointing it out.)

Larry

On Mar 22, 2007, at 10:19 PM, Larry Lannom wrote:

Hi,

Yes, that's the basic idea - the handle, and any static links that use it, stays the same through attribute changes of the identified object, such as changes in location. So the links continue to work as the location, or any other attribute changes. Of course someone has to maintain that mapping, much like someone has to maintain the mapping between IP address and domain name (although the handles are intended to be more finely grained than that).

A couple of additions to your summary -

hdl.handle.net is not a handle server -- it is a proxy server (actually a set of proxy servers) that takes an HTTP GET and turns it into a handle resolution. So its a client to the complete set of handle servers in the world. And it talks to the set of Global handle servers to find out which local handle server(s) it can talk to to resolve every handle starting with a certain prefix.

And handles can map to things other than URLs. Every handle is a bundle of type/value pairs (or you can think of it as a distributed database of handle/type/value tuples). A lot of those types are URLs and some systems, like the set of hdl.handle.net proxy servers, are set up to basically operate on URLs, but you can use any type you like. Some types are administrative in nature (when a handle client talks to global it looks for a type of 'service information' that is a piece of structured data telling it all it needs, e.g., IPs, ports, public keys, to talk to the one or more handle servers that know about that prefix), and some are application oriented, such as producing menus associated with each link. Not too much has been done with that capability so far, outside of running the handle system itself, but this is starting to pick up, e.g., see the D-Lib article on the China Digital Museum Project which uses the handle system to track multiple locations.

(http://dx.doi.org//10.1045/july2006-tansley)

Larry

On Mar 22, 2007, at 8:04 PM, Michael Judd wrote:


Hi Tim,
I'm no handle expert but here goes...
Handles are just updatable mappings to URLs.
They allow you to publish URLs to documents that, as long as you maintain the mapping, will always resolve.
So in your example, originally you might have given the URL http:// hdl.handle.net/98765/todo to someone so that they could see the document at http://shield.mydomain.org/todo.txt.
(Any handle server should be able to resolve any handle, but since handle servers themselves are suseptable to hostname changes etc. you should use the cnri handle server (hdl.handle.net) when giving out handle URLs as it is guaranteed not to change.)
Back to your example, after your hostname change you would update 98765/todo to point to http://dagger.mydomain.org/todo.txt so that everyone who went to http://hdl.handle.net/98765/todo would continue to see the correct document.
Originally you may have had another document at http:// whatever.mydomain.org/whatever.txt that you created the handle http://hdl.handle.net/98765/whatever for. This handle will still be valid as long as http://whatever.mydomain.org/whatever.txt points to the document.
Handles with the same prefix (98765) don't have to resolve to the same server. The prefix is just used to locate the actual handle server.
Using DNS cnames and aliases you can keep URLs that simply move servers or change hostnames resolving. But what happens if an organizations domain name changes? Or what happens if the repository software the documents exist in changes, and all the relative links change? This is where the value of handles and other persistant URL schemes come.
That's how I see it anyway. :)
Cheers!


Regards,

Michael Judd

Nathan Campus, Griffith University.
Brisbane 4111. Australia.

m.judd@griffith.edu.au
07 3735 3801


Tim Donnelly <tim@coalliance.org> Sent by: handle-info-admin@cnri.reston.va.us 23/03/2007 07:39 AM Please respond to tim@coalliance.org


To handle-info@cnri.reston.va.us cc Subject [Handle-info] Please help me understand the value of Handle





I am confused on the way Handles work. Let me explain by way of an example.
I have a prefix, for the sake of argument 98765. I have created a handle 98765/todo that points to the URL http:// shield.mydomain.org/todo.txt. If I look at the handle in the Admin tool it shows a data value of the URL.


But, what happens if at some point in the future, the name of the host changes from shield.coalliance.org to dagger.mydomain.org? That handle is now broken, correct?

I thought the whole point of Handles was to create a way to be able to find information regardless of changes such as I described.

The way I envisioned the Handle service working is more like this:

98765 would actually resolve to http://shield.mydomain.org, therefore handles I create would only include the final destination at that location (todo.txt in my example above). So, the Handle 98765/todo would equal http://shield.mydomain.org/ todo.txt. Then, if I later changed shield to dagger, I would have to update my siteinfo with the Global Registry, telling it that all 98765 prefixes now belong to dagger.mydomain.org.

The way it appears to actually work to me is:

The 98765 prefix is simply used by the Global Registry to tell the proxy server which local handle server it should look to to resolve. So, the proxy server looks up 98765 and knows to send the request to my local server at IP 192.168.0.1. The local server then says "todo" is equal to the URL and redirects the users browser to that URL hard coded into the handle.

I have tested this by creating a Handle with the URL of todo.txt, no domain info included. When I attempt to resolve it I get an error that it cannot be found.

I'm sure this isn't making much sense but I am having a hard time wrapping my brain around these concepts.

Thanks in advance.

Tim Donnelly
Systems/Network Administrator
Colorado Alliance of Research Libraries
(303)759-3399 x106


_______________________________________________ Handle-Info mailing list Handle-Info@cnri.reston.va.us http://www.handle.net/ mailman/listinfo/handle-info







=========================================
Larry Lannom
Director of Information Management Technology
Corporation for National Research Initiatives (CNRI)
Suite 100, 1895 Preston White Dr, Reston, VA 20191

email:  llannom@cnri.reston.va.us
web: www.cnri.reston.va.us
tel:  703 620 8990



_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info