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.
>>>>
>>>>
>>>>
>>
>>
>