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>

Reply via email to