 |
 |
Interesting stuff. I never really thought about it before that DOIs can be served up by the Handle server. E.G., http://dx.doi.org/10.1074/jbc.M004545200 <=> http://hdl.handle.net/10.1074/jbc.M004545200 But, even more surprising to me was realizing that Handles can be resolved by the DOI server. Or presumably any DOI server. http://hdl.handle.net/2027.42/46087 <=> http://dx.doi.org/2027.42/46087 I suppose I should have understood this point since the Handle service does sort of obliquely say this. http://www.handle.net/factsheet.html Anyway, good to have it made explicit. Tom On Mon, Nov 23, 2009 at 4:03 PM, Jonathan Rochkind <[log in to unmask]> wrote: > The actual "handle" is "10.1074/jbc.M004545200 ". If your software wants to > get a "handle" to give it to any handle resolver of it's choice, it's going > to have to parse the "doi:" or "info:" versions to get the handle out first. > The info version is a URI that has a DOI handle embedded in it. The doi > version is... um, I dunno, just a convention, I think, that has a DOI handle > embedded in it. > > Likewise, if your software had a URI, and was smart enough to know that the > URI "http://dx.doi.org/10.1074/jbc.M004545200" actually had a handle > embedded in it, it could strip the handle out, and then resolve it against > some other handle server that participates in the handle network, like > hdl.handle.net. But that would be kind of going against the principle to > treat URI's as opaque identifiers and not parse them for internal data. > > But me, I end up going against that principle all the time in actual > practice, actually for scenarios kind of analagous to, but less well-defined > and spec'd than, getting the actual "handle" out of the URI and resolving it > against some other service. For instance, getting an OCLCnum out of an > http://worldcat.oclc.org/ URI, to resolve against my local catalog that > knows something about OCLCnums, but doesn't know anything about > http://worldcat.oclc.org URIs that happen to have an OCLCnum embedded in > them. Or getting an ASIN out of a http://www.amazon.com/ URI, to resolve > against Amazon's _own_ web services, which ironically know something about > ASIN's but don't know anything about www.amazon.com URI's that have an ASIN > embedded in them. Actually quite analagous to getting the actual handle out > of an http://dx.doi.org or http://hdi.handle.net URI, in order to resolve > against the resolver of choice. > > Jonathan > > Ross Singer wrote: >> >> On Mon, Nov 23, 2009 at 2:52 PM, Jonathan Rochkind <[log in to unmask]> >> wrote: >> >> >>> >>> Well, here's the trick about handles, as I understand it. A handle, for >>> instance, a DOI, is "10.1074/jbc.M004545200". >>> >> >> Well, actually, it could be: >> 10.1074/jbc.M004545200 >> doi:10.1074/jbc.M004545200 >> info:doi/10.1074/jbc.M004545200 >> >> etc. But there's still got to be some mechanism to get from there to: >> http://dx.doi.org/10.1074/jbc.M004545200 >> or >> http://dx.hellman.net/10.1074/jbc.M004545200 >> >> I don't see why it's any different, fundamentally, than: >> >> http://purl.hellman.net/?purl=http%3A%2F%2Fpurl.org%2FNET%2Fdoi%2F10.1074%2Fjbc.M004545200 >> >> besides being prettier. >> >> Anyway, my argument wasn't that Purl was technologically more sound >> that handles -- Purl services have a major single-point-of-failure >> problem -- it's just that I don't buy the argument that handles are >> somehow superior because they aren't limited to HTTP. >> >> What I'm saying is that there plenty of valid reasons to value handles >> more than purls (or any other indirection service), but independence >> to HTTP isn't one of them. >> >> -Ross. >> >> >>> >>> While, for DOI handles, normally we resolve that using dx.doi.org, at >>> http://dx.doi.org/10.1074/jbc.M004545200, that is not actually a >>> requirement >>> of the handle system. You can resolve it through any handle server, over >>> HTTP or otherwise. Even if it's still over HTTP, it doesn't have to be at >>> dx.doi.org, it can be via any handle resolver. >>> >>> For instance, check this out, it works: >>> >>> http://hdl.handle.net/10.1074/jbc.M004545200 >>> >>> Cause the DOI is really just a subset of Handles, any resolver >>> participating >>> in the handle network can resolve em. In Eric's hypothetical use case, >>> that >>> could be a local enterprise handle resolver of some kind. (Although I'm >>> not >>> totally sure that would keep your usage data private; the documentation >>> I've >>> seen compares the handle network to DNS, it's a distributed system, I'm >>> not >>> sure in what cases handle resolution requests are sent 'upstream' by the >>> handle resolver, and if actual individual lookups are revealed by that or >>> not. But in any case, when Ross suggests -- "Presumably dx.hellman.net >>> would >>> need to harvest its metadata from somewhere, which seems like it would >>> leave >>> a footprint. It also needs some mechanism to stay in sync with the master >>> index." -- my reading this suggests this is _built into_ the handle >>> protocol, it's part of handle from the very start (again, the DNS >>> analogy, >>> with the emphasis on the distributed resolution aspect), you don't need >>> to >>> invent it yourself. The details of exactly how it works, I don't know >>> enough >>> to say. ) >>> >>> Now, I'm somewhat new to this stuff too, I don't completely understand >>> how >>> it works. Apparently hdl.handle.net can <strike>handle</strike> deal >>> with >>> any handle globally, while presumably dx.doi.org can only deal with the >>> subset of handles that are also DOIs. And apparently you can have a >>> handle >>> resolver that works over something other than HTTP too. (Although Ross >>> argues, why would you want to? And I'm inclined to agree). >>> >>> 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. >>> >>> Jonathan >>> >>> >>> >>> >>> >>>> >>>> Presumably dx.hellman.net would need to >>>> harvest its metadata from somewhere, which seems like it would leave a >>>> footprint. It also needs some mechanism to stay in sync with the >>>> master index. Your non-resolution service also seems to be looking >>>> these things up in realtime. Would a RESTful or SOAP API (*shudder*) >>>> not accomplish the same goal? >>>> >>>> Really, though, the binding argument here is less the issue here than >>>> if you believe http URIs are valid identifiers or not since there's no >>>> reason a URI couldn't be dereferenced via other bindings, either. >>>> >>>> -Ross. >>>> >>>> >>>> >> >> >