Hi all, couldn't resist jumping in on this one: > But appears that the handle system is quite a bit more fleshed out than a > simple purl server, it's a distributed protocol-independent network. The > protocol-independent part may or may not be useful, but it certainly seems > like it could be, it doens't hurt to provide for it in advance. The > distributed part seems pretty cool to me. > > So if it's no harder to set up, maintain, and use a handle server than a Purl > server (this is a big 'if', I'm not sure if that's the case), and handle can > do everything purl can do and quite a bit more (I'm pretty sure that is the > case)... why NOT use handle instead of purl? It seems like handle is a more > fleshed out, robust, full-featured thing than purl.
I think it's also worth adding that handles (and DOIs) can also be used to create PURLs, eg. http://purl.org/handles/10.1074/jbc.M004545200 (which isn't a real link) -- in fact, there's no reason why you couldn't use a PURL server as a local handle resolver, aside from the fact that it wouldn't be participating in the handle network. See, for example: <http://www.ukoln.ac.uk/distributed-systems/poi/> One thing PURL has going for it is that it has defined meanings for HTTP response codes; these are similar to REST responses though I don't know if they're the same; the most recent documentation mentions that PURL servers are RESTful but I suspect this is part of the recent re-tooling of PURL. <http://purl.oclc.org/docs/help.html#rest> The only potential advantage of PURLs that I can see is the ability to do partial redirects, eg. http://purl.org/redirect/xxxxxx --> http://some.server/long.path/xxxxx -- though one could make the case that this might be useful for directing handle requests to the appropriate servers, eg. http://purl.org/handles/10.123/xxxxxx --> http://handleserver1/xxxxxx and http://purl.org/handles/10.456/xxxxxx --> http://doiserver2/xxxxxx ... Overall, I tend to agree that handles seem more flexible -- or at least, less tied to URL and HTTP -- than PURLs. Not having to rely on a specific server for resolution is a fairly major bonus (think DNS-style round-robin resolver querying for handles; not possible with PURLs). MJ PS. At the risk of reposting potentially old news: <http://web.mit.edu/handle/www/purl-eval.html>