Re: [CODE4LIB] Assigning DOI for local content

[Eric Hellman]

On Nov 23, 2009, at 1:32 PM, Ross Singer wrote:

> On Mon, Nov 23, 2009 at 1:07 PM, Eric Hellman  wrote:
> 
>> Does this answer your question, Ross?
> 
> Yes, sort of.  My question was not so much if you can resolve handles
> via bindings other than HTTP (since that's one of the selling points
> of handles) as it was "do people actually use this in the real world"?

Well, the short answer to that question is "yes."

I think the discussion veered out of the zone of my understanding the point of 
it. The original question related to whether a journal should register Crossref 
doi's, and the short answer to that, as far as I'm concerned,  is an emphatic 
"yes".

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

e...@hellman.net 
http://go-to-hellman.blogspot.com/

Re: [CODE4LIB] Assigning DOI for local content

[Jonathan Rochkind]

More info here too:

http://www.handle.net/introduction.html

This handle stuff is interesting, but I don't entirely understand it.

I guess if the Global Handle Service really went down, it would be 
similar to a root-level DNS server going down -- you'd be in trouble, 
somewhat mitigated by whatever data your local resolver had cached.


Of course, CNRI maintains several failover mirrors of the Global Handle 
Service for that reason. (Much as we'd hope all the root-level DNS 
servers are thorougly failover-ed).


Jonathan

Ben O'Steen wrote:

What happens if the main doi resolver goes down? I'd be interested to see
how well a local resolver works when blocked from this upstream server. Are
there any other upstream servers?

Ben

On Nov 23, 2009 10:10 PM, "Tom Keays"  wrote:

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  wrote:
  

The actual "handle" ...



  

Re: [CODE4LIB] Assigning DOI for local content

[Jonathan Rochkind]

What do you mean by a local resolver?  If you're talking about a local 
handle resolver adhering to the handle spec... well, then it depends on 
the handle spec I guess, which I don't know. But since all the handle 
documetnation keeps saying "like DNS", then I'd imagine it has similar 
(or better) redundancy built into it as DNS does. But I don't know.


Poking around on handle.net, it looks like the handle infrastructure 
supports this,but you would have had to actually configure 'backup' 
handle resolvers -- similar to DNS in that if the DNS for your domain 
goes down, and you _haven't_ gotten someone else at another location to 
be a 'backup' resolver for you, and specified them as a nameserver in 
your DNS record... then you're out of luck. But the protocol supports 
that, and if you have done it (as most everyone does with DNS), you're 
good.


I have no idea if 'most everyone' does it with handle or not, but handle 
supports it. Note that if dx.doi.org goes down, you obviously won't be 
able to resolve at dx.doi.org -- but IF it works as I think (I'm still 
confused), AND dx.doi.org has distributed their handles to a backup 
resolver, then you'd still be able to resolve via hdl.handle.net, or via 
your own local handle resolver (which will in turn find the backup 
resolver).


http://www.handle.net/lhs.html

Jonathan

Ben O'Steen wrote:

What happens if the main doi resolver goes down? I'd be interested to see
how well a local resolver works when blocked from this upstream server. Are
there any other upstream servers?

Ben

On Nov 23, 2009 10:10 PM, "Tom Keays"  wrote:

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  wrote:
  

The actual "handle" ...



  

Re: [CODE4LIB] Assigning DOI for local content

[Ben O'Steen]

What happens if the main doi resolver goes down? I'd be interested to see
how well a local resolver works when blocked from this upstream server. Are
there any other upstream servers?

Ben

On Nov 23, 2009 10:10 PM, "Tom Keays"  wrote:

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  wrote:
> The actual "handle" ...

Re: [CODE4LIB] Assigning DOI for local content

[Tom Keays]

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

Re: [CODE4LIB] Assigning DOI for local content

[Jonathan Rochkind]

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  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 handle 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 certa

Re: [CODE4LIB] Assigning DOI for local content

[Ross Singer]

On Mon, Nov 23, 2009 at 2:52 PM, Jonathan Rochkind  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 handle 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.
>>
>>
>

Re: [CODE4LIB] Assigning DOI for local content

[MJ Suhonos]

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: 


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.


The only potential advantage of PURLs that I can see is the ability to do 
partial redirects, eg. http://purl.org/redirect/xx --> 
http://some.server/long.path/x -- 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/xx --> http://handleserver1/xx and 
http://purl.org/handles/10.456/xx --> http://doiserver2/xx ...

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:  

Re: [CODE4LIB] Assigning DOI for local content

[Jonathan Rochkind]

Ross Singer wrote:


Also, with your use cases, would these services be impossible if the
only binding was HTTP?  
Well, here's the trick about handles, as I understand it.  A handle, for 
instance, a DOI, is "10.1074/jbc.M004545200". 

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

  

Re: [CODE4LIB] Assigning DOI for local content

[Roy Tennant]

But minting DOIs requires a Registration Agency which as far as I understand
it, requires $1,000 and approval from the International DOI Federation.[1]
Roy

[1] http://www.doi.org/handbook_2000/governance.html#7.2.2


On 11/23/09 11/23/09 € 10:07 AM, "Eric Hellman"  wrote:

> For example, if you don't want to rely on dx.doi.org as your gateway to the
> handle system for doi resolution, it would be quite easy for me to deploy my
> own gateway at dx.hellman.net. I might want to do this if a were an
> organization paranoid about security and didn't want to disclose to anybody
> what doi's my organization was resolving. Or, I might want to directly access
> metadata in the handle system that doesn't go through the http gateways, to
> provide a service other than resolution.
> 
> Does this answer your question, Ross?
> 
> 
> 
> On Nov 20, 2009, at 2:31 PM, Ross Singer wrote:
> 
>> On Fri, Nov 20, 2009 at 2:23 PM, Eric Hellman  wrote:
>>> Having incorporated the handle client software into my own stuff rather
>>> easily, I'm pretty sure that's not true.
>> 
>> Fair enough.  The technology is binding independent.
>> 
>> So you are using and sharing handles using some protocol other than HTTP?
>> 
>> I'm more interested in the sharing part of that question.  What is the
>> format of the handle identifier in this context?  What advantage does
>> it bring over HTTP?
>> 
>> -Ross.
> 
> Eric Hellman
> President, Gluejar, Inc.
> 41 Watchung Plaza, #132
> Montclair, NJ 07042
> USA
> 
> e...@hellman.net 
> http://go-to-hellman.blogspot.com/
> 

Re: [CODE4LIB] Assigning DOI for local content

[Ross Singer]

On Mon, Nov 23, 2009 at 1:07 PM, Eric Hellman  wrote:

> Does this answer your question, Ross?

Yes, sort of.  My question was not so much if you can resolve handles
via bindings other than HTTP (since that's one of the selling points
of handles) as it was "do people actually use this in the real world"?

Of course, it may be impossible to answer that question since, by your
example, such people may not actually be letting anybody know that
they're doing that (although you would probably be somebody with
insider knowledge on this topic).

Also, with your use cases, would these services be impossible if the
only binding was HTTP?  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.

Re: [CODE4LIB] Assigning DOI for local content

[Eric Hellman]

For example, if you don't want to rely on dx.doi.org as your gateway to the 
handle system for doi resolution, it would be quite easy for me to deploy my 
own gateway at dx.hellman.net. I might want to do this if a were an 
organization paranoid about security and didn't want to disclose to anybody 
what doi's my organization was resolving. Or, I might want to directly access 
metadata in the handle system that doesn't go through the http gateways, to 
provide a service other than resolution.

Does this answer your question, Ross?



On Nov 20, 2009, at 2:31 PM, Ross Singer wrote:

> On Fri, Nov 20, 2009 at 2:23 PM, Eric Hellman  wrote:
>> Having incorporated the handle client software into my own stuff rather 
>> easily, I'm pretty sure that's not true.
> 
> Fair enough.  The technology is binding independent.
> 
> So you are using and sharing handles using some protocol other than HTTP?
> 
> I'm more interested in the sharing part of that question.  What is the
> format of the handle identifier in this context?  What advantage does
> it bring over HTTP?
> 
> -Ross.

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

e...@hellman.net 
http://go-to-hellman.blogspot.com/

Re: [CODE4LIB] Assigning DOI for local content

[Jodi Schneider]

I'm really interested to hear that DOIs are starting to have brand
recognition with (some) users. Thanks! -Jodi

Re: [CODE4LIB] Assigning DOI for local content

[Ross Singer]

On Fri, Nov 20, 2009 at 2:23 PM, Eric Hellman  wrote:
> Having incorporated the handle client software into my own stuff rather 
> easily, I'm pretty sure that's not true.

Fair enough.  The technology is binding independent.

So you are using and sharing handles using some protocol other than HTTP?

I'm more interested in the sharing part of that question.  What is the
format of the handle identifier in this context?  What advantage does
it bring over HTTP?

-Ross.

Re: [CODE4LIB] Assigning DOI for local content

[Eric Hellman]

Having incorporated the handle client software into my own stuff rather easily, 
I'm pretty sure that's not true.

On Nov 19, 2009, at 12:51 PM, Ross Singer wrote:
> The caveat being that the initial access point is provided via HTTP.
> 
> But then again, so is http://hdl.handle.net/, which, in fact, the only
> way currently in practice to dereference handles.

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

e...@hellman.net 
http://go-to-hellman.blogspot.com/

Re: [CODE4LIB] Assigning DOI for local content

[Ross Singer]

Back in 2007, I had a different job, different email address and lived
in a different state.  Things change.  If people are sending emails to
ross.sin...@gatech.edu to fix the library web services, they are going
to be sorely disappointed and should perhaps check
http://www.library.gatech.edu/about/staff.php for updates.

purl.org has been going through a massive architecture change for the
better part of a year now -- which has finally been completed.  It was
a slightly messy transition but they migrated from their homegrown
system to one designed by Zepheira.

I feel like predicting the demise of HTTP and worrying about a
services' ability to handle other protocols is unnecessary hand
wringing.

I still have a telephone (two, in fact).  Both my cell phone and VOIP
home phone are still able to communicate flawlessly with a POTS dial
phone.

My car still has an internal combustion engine based on petroleum.  It
still doesn't fly or even hover.  My wall outlets still accept a plug
made in the 1960s.

PURLs themselves are perfectly compatible with protocols other than HTTP:
http://purl.org/NET/rossfsinger/ftpexample

The caveat being that the initial access point is provided via HTTP.

But then again, so is http://hdl.handle.net/, which, in fact, the only
way currently in practice to dereference handles.

My point is, there's a lot of energy, resources and capital invested
in HTTP.  Even if it becomes completely obsolete, my guess I can still
type "http://purl.org/dc/terms"; in spdy://google.com/ and find
something about what I'm looking for.

-Ross.

On Thu, Nov 19, 2009 at 12:18 PM, Han, Yan  wrote:
> Please explain in more details, that will be more helpful.
> It has been a while. Back to 2007, I checked PURL's architecture, and it was 
> straightly handling web addresses only. Of course, current HTTP protocol is 
> not going to last forever, and there are other protocols in the Internet. The 
> coverage of PURL is not enough.
> From PURL's website, it still says " PURLs (Persistent Uniform Resource 
> Locators) are Web addresses that act as permanent identifiers in the face of 
> a dynamic and changing Web infrastructure." I am not sure what "web 
> addresses" means.  http://www.purl.org/docs/help.html#overview says " PURLs 
> are Persistent Uniform Resource Locators (URLs). A URL is simply an address 
> on the World Wide Web". We all know that "World Wide Web" is not "the 
> Internet". What if info resource can be accessed through other Internet 
> Protocols (FTP, VOIP, )?  This is the limitation of PURL.
> PURL is doing re-architecture, though I cannot find out more documentation.
> The Handle system is " The Handle System is a general purpose distributed 
> information system that provides efficient, extensible, and secure HDL 
> identifier and resolution services for use on networks such as the 
> Internet.". http://www.handle.net/index.html Notice the difference in 
> definition.
>
> Yan
>
>
> -Original Message-
> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Ross 
> Singer
> Sent: Wednesday, November 18, 2009 8:11 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Assigning DOI for local content
>
> On Wed, Nov 18, 2009 at 12:19 PM, Han, Yan  wrote:
>> Currently DOI uses Handle (technology) with it social framework (i.e. 
>> administrative body to manage DOI). In technical sense, PURL is not going to 
>> last long.
>
> I'm not entirely sure what this is supposed to mean (re: purl), but
> I'm pretty sure it's not true.
>
> I'm also pretty sure there's little to no direct connection between
> purl and doi despite a superficial similarity in scope.
>
> -Ross.
>

Re: [CODE4LIB] Assigning DOI for local content

[Han, Yan]

Please explain in more details, that will be more helpful. 
It has been a while. Back to 2007, I checked PURL's architecture, and it was 
straightly handling web addresses only. Of course, current HTTP protocol is not 
going to last forever, and there are other protocols in the Internet. The 
coverage of PURL is not enough. 
>From PURL's website, it still says " PURLs (Persistent Uniform Resource 
>Locators) are Web addresses that act as permanent identifiers in the face of a 
>dynamic and changing Web infrastructure." I am not sure what "web addresses" 
>means.  http://www.purl.org/docs/help.html#overview says " PURLs are 
>Persistent Uniform Resource Locators (URLs). A URL is simply an address on the 
>World Wide Web". We all know that "World Wide Web" is not "the Internet". What 
>if info resource can be accessed through other Internet Protocols (FTP, VOIP, 
>)?  This is the limitation of PURL. 
PURL is doing re-architecture, though I cannot find out more documentation.
The Handle system is " The Handle System is a general purpose distributed 
information system that provides efficient, extensible, and secure HDL 
identifier and resolution services for use on networks such as the Internet.". 
http://www.handle.net/index.html Notice the difference in definition. 

Yan


-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Ross 
Singer
Sent: Wednesday, November 18, 2009 8:11 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Assigning DOI for local content

On Wed, Nov 18, 2009 at 12:19 PM, Han, Yan  wrote:
> Currently DOI uses Handle (technology) with it social framework (i.e. 
> administrative body to manage DOI). In technical sense, PURL is not going to 
> last long.

I'm not entirely sure what this is supposed to mean (re: purl), but
I'm pretty sure it's not true.

I'm also pretty sure there's little to no direct connection between
purl and doi despite a superficial similarity in scope.

-Ross.

Re: [CODE4LIB] Assigning DOI for local content

[Tom Keays]

On Tue, Nov 17, 2009 at 6:58 PM, Jodi Schneider
 wrote:
> The first question is: what are they trying to accomplish by having DOIs?

DOIs are just a form of Handle, which is a persistent URL schema. I
don't think I need to explain what PURLs are designed to accomplish.

> If they're looking for persistent identifiers, I don't understand (a
> priori), why DOI is better, as an identifier scheme, than any other
> 'persistent identifier scheme' (ARK [1], PURL, Handle, etc[2]). (Though I
> really like CrossRef and the things they're doing.)

The advantage is that DOIs over other PURLs are used only for citation
purposes. As someone who works with a lot of students and faculty, I
have observed that DOIs are becoming familiar to them as a definitive
citation identifier. As more journals, publishing in an online
environment, stop using page numbers in their citations and turn
instead to article identifiers -- e.g., citations like this one:

Neylon C, Wu S (2009) Article-Level Metrics and the Evolution of
Scientific Impact. PLoS Biol 7(11): e1000242.
doi:10.1371/journal.pbio.1000242

then DOIs become the most consistently recognizable identifier for
constructing findable citations. So, you could use a PURL, but they
wouldn't be understood to mean the same thing.

Also, DOIs are not dependent on a single resolver -- i.e., you don't
have to send them through http://dx.doi.org/ although that's largely
been the case up to this point in time. PURLs tend to be
server-specific. We don't have to think too far back to recall an
instance when a PURL server failed, causing some temporary access
problems. Hopefully, DOIs are less vulnerable to this -- although this
certainly hasn't been tested.

And, responding to Jonathan, who said:
>investigating whether every cited article has a DOI and then making sure
>to include it... is non-trivial labor.

It certainly is if you have to go back and apply them to a backfile of
published articles. However, with the Code4Lib Journal, I've been
doing this all along in the articles I've edited. CrossRef has good
tools for finding this information and when that fails, I go to the
cited article itself. Some work, yes, but I figure that's part of my
job as an editor.

Tom

Re: [CODE4LIB] Assigning DOI for local content

[Ross Singer]

On Wed, Nov 18, 2009 at 12:19 PM, Han, Yan  wrote:
> Currently DOI uses Handle (technology) with it social framework (i.e. 
> administrative body to manage DOI). In technical sense, PURL is not going to 
> last long.

I'm not entirely sure what this is supposed to mean (re: purl), but
I'm pretty sure it's not true.

I'm also pretty sure there's little to no direct connection between
purl and doi despite a superficial similarity in scope.

-Ross.

Re: [CODE4LIB] Assigning DOI for local content

[Stuart Lewis]

To me, one of the most important selling points of DOIs over any of those other 
systems, is that the DOIs are starting to have brand-recognition with users. 
Faculty generally know what a DOI is, what it does, and the importance of 
having one, whereas they don't know what a PURL or a handle is. (I say this 
coming from a DSpace background where we have to explain what handles are, and 
usually end up saying "they're like DOIs" to which the audience starts nodding).


Stuart Lewis
IT Innovations Analyst and Developer
Te Tumu Herenga The University of Auckland Library
Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand
Ph: 64 9 373-7599 x81928
http://www.library.auckland.ac.nz/


On 18/11/2009, at 12:58 PM, Jodi Schneider wrote:

> The first question is: what are they trying to accomplish by having DOIs?
> 
> Do they have a long-term plan for persistence of their content? Financial
> plan?
> 
> If they're looking for persistent identifiers, I don't understand (a
> priori), why DOI is better, as an identifier scheme, than any other
> 'persistent identifier scheme' (ARK [1], PURL, Handle, etc[2]). (Though I
> really like CrossRef and the things they're doing.)
> 
> [1] http://www.cdlib.org/inside/diglib/ark/
> [2] http://www.persistent-identifier.de/english/204-examples.php
> 
> -Jodi
> 
> On Tue, Nov 17, 2009 at 11:44 PM, Bucknell, Terry <
> t.d.buckn...@liverpool.ac.uk> wrote:
> 
>> You should be able to find all the information you need about CrossRef fees
>> and rules at:
>> 
>> http://www.crossref.org/02publishers/20pub_fees.html
>> 
>> and
>> 
>> http://www.crossref.org/02publishers/59pub_rules.html
>> 
>> Information about the system of registering and maintaining DOIs is at:
>> 
>> http://www.crossref.org/help/
>> 
>> Note that as well as registering DOIs for the articles in LLT, LLT would be
>> obliged to link to the articles cited by LLT articles (for cited articles
>> that have DOIs too). Looking at the LLT site, it looks like they would have
>> to change their 'abstract' pages to 'abstract plus cited refs', or change
>> the way that their PDFs are created so that they include DOI links for cited
>> references. (Without this the whole system would fail: publishers would
>> expect traffic to come to them, but wouldn't have to send traffic
>> elsewhere).
>> 
>> I'd agree that DOIs are in general a Good Thing (and for e-books / e-book
>> chapters, and reference work entries as well as e-journal articles). The
>> CrossRef fees are deliberately set so as not to exclude single-title
>> publishers. Here's an example of a single-title, university-based e-journal
>> in the UK that provides DOIs, so it must be a CrossRef member:
>> http://www.bioscience.heacademy.ac.uk/journal/.
>> 
>> 
>> Terry Bucknell
>> Electronic Resources Manager
>> University of Liverpool
>> 
>> 
>> -Original Message-
>> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
>> Jonathan Rochkind
>> Sent: 17 November 2009 23:20
>> To: CODE4LIB@LISTSERV.ND.EDU
>> Subject: Re: [CODE4LIB] Assigning DOI for local content
>> 
>> So I have no actual experience with this.
>> 
>> But you have to pay for DOI's.  I've never done it, but I don't think
>> you neccesarily have to run your own purl server -- CrossRef takes care
>> of it.  Of course, if your documents are going to be moving all over the
>> place, if you run your own purl server and register your purls with
>> CrossRef, then when a document moves, you can update your local purl
>> server; otherwise, you can update CrossRef, heh.
>> 
>> It certainly is useful to have DOIs, I agree.  I would suggest they
>> should just contact cross-ref and get information on the cost, and what
>> their responsibilities are, and then they'll be able to decide.  If the
>> 'structure of their content' is journal articles, then, sure DOI is
>> pretty handy for people wanting to cite or link to those articles.
>> 
>> Jonathan
>> 
>> Ranti Junus wrote:
>>> Hi All,
>>> 
>>> I was asked by somebody from a college @ my institution whether they
>>> should go with assigning DOI for their journal articles:
>>> http://llt.msu.edu/
>>> 
>>> I can see the advantage of this approach and my first thought is more
>>> about whether they have resources in running their purl server, or
>>> whether they would need to do it through crossref (or any other
>>> agency.) Has anybody had any experience about this?
>>> 
>>> Moreover, are there other factors that one should consider (pros and
>>> cons) about this? Or, looking at the structure of their content,
>>> whether they ever need DOI? Any ideas and/or suggestions?
>>> 
>>> 
>>> Any insights about this is much appreciated.
>>> 
>>> 
>>> thanks,
>>> ranti.
>>> 
>>> 
>> 

Re: [CODE4LIB] Assigning DOI for local content

[Ranti Junus]

Fascinating. I learned a lot from these discussions. Thank you all so much!


ranti.

-- 
Bulk mail.  Postage paid.

Re: [CODE4LIB] Assigning DOI for local content

[Han, Yan]

Currently DOI uses Handle (technology) with it social framework (i.e. 
administrative body to manage DOI). In technical sense, PURL is not going to 
last long. 
Crossref handles DOI registration in U.S. In Europe and Aisa, they have other 
organizations to handle it. DOI is also currently going through ISO 
standardization process. The other fact is that DOI has the biggest number of 
usage than other Persistent Identifiers. More info can be found at 
http://www.doi.org/faq.html 

Yan

-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jodi 
Schneider
Sent: Tuesday, November 17, 2009 4:59 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Assigning DOI for local content

The first question is: what are they trying to accomplish by having DOIs?

Do they have a long-term plan for persistence of their content? Financial
plan?

If they're looking for persistent identifiers, I don't understand (a
priori), why DOI is better, as an identifier scheme, than any other
'persistent identifier scheme' (ARK [1], PURL, Handle, etc[2]). (Though I
really like CrossRef and the things they're doing.)

[1] http://www.cdlib.org/inside/diglib/ark/
[2] http://www.persistent-identifier.de/english/204-examples.php

-Jodi

On Tue, Nov 17, 2009 at 11:44 PM, Bucknell, Terry <
t.d.buckn...@liverpool.ac.uk> wrote:

> You should be able to find all the information you need about CrossRef fees
> and rules at:
>
> http://www.crossref.org/02publishers/20pub_fees.html
>
> and
>
> http://www.crossref.org/02publishers/59pub_rules.html
>
> Information about the system of registering and maintaining DOIs is at:
>
> http://www.crossref.org/help/
>
> Note that as well as registering DOIs for the articles in LLT, LLT would be
> obliged to link to the articles cited by LLT articles (for cited articles
> that have DOIs too). Looking at the LLT site, it looks like they would have
> to change their 'abstract' pages to 'abstract plus cited refs', or change
> the way that their PDFs are created so that they include DOI links for cited
> references. (Without this the whole system would fail: publishers would
> expect traffic to come to them, but wouldn't have to send traffic
> elsewhere).
>
> I'd agree that DOIs are in general a Good Thing (and for e-books / e-book
> chapters, and reference work entries as well as e-journal articles). The
> CrossRef fees are deliberately set so as not to exclude single-title
> publishers. Here's an example of a single-title, university-based e-journal
> in the UK that provides DOIs, so it must be a CrossRef member:
> http://www.bioscience.heacademy.ac.uk/journal/.
>
>
> Terry Bucknell
> Electronic Resources Manager
> University of Liverpool
>
>
> -Original Message-
> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
> Jonathan Rochkind
> Sent: 17 November 2009 23:20
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Assigning DOI for local content
>
> So I have no actual experience with this.
>
> But you have to pay for DOI's.  I've never done it, but I don't think
> you neccesarily have to run your own purl server -- CrossRef takes care
> of it.  Of course, if your documents are going to be moving all over the
> place, if you run your own purl server and register your purls with
> CrossRef, then when a document moves, you can update your local purl
> server; otherwise, you can update CrossRef, heh.
>
> It certainly is useful to have DOIs, I agree.  I would suggest they
> should just contact cross-ref and get information on the cost, and what
> their responsibilities are, and then they'll be able to decide.  If the
> 'structure of their content' is journal articles, then, sure DOI is
> pretty handy for people wanting to cite or link to those articles.
>
> Jonathan
>
> Ranti Junus wrote:
> > Hi All,
> >
> > I was asked by somebody from a college @ my institution whether they
> > should go with assigning DOI for their journal articles:
> > http://llt.msu.edu/
> >
> > I can see the advantage of this approach and my first thought is more
> > about whether they have resources in running their purl server, or
> > whether they would need to do it through crossref (or any other
> > agency.) Has anybody had any experience about this?
> >
> > Moreover, are there other factors that one should consider (pros and
> > cons) about this? Or, looking at the structure of their content,
> > whether they ever need DOI? Any ideas and/or suggestions?
> >
> >
> > Any insights about this is much appreciated.
> >
> >
> > thanks,
> > ranti.
> >
> >
>

Re: [CODE4LIB] Assigning DOI for local content

[Rees, John (NIH/NLM) [E]]

And DOIs are just a managed implementation of Handles which the IDF created, so 
you could go the Handles route for free. But then you lose the CrossRef 
services, etc. if that is important to you.

John P. Rees, MA, MLIS
Curator, Archives and Modern Manuscripts
History of Medicine Division, MSC 3819
National Library of Medicine
8600 Rockville Pike
Bethesda, MD 20894




-Original Message-
From: Jodi Schneider [mailto:jodi.a.schnei...@gmail.com] 
Sent: Tuesday, November 17, 2009 6:59 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Assigning DOI for local content

The first question is: what are they trying to accomplish by having DOIs?

Do they have a long-term plan for persistence of their content? Financial
plan?

If they're looking for persistent identifiers, I don't understand (a
priori), why DOI is better, as an identifier scheme, than any other
'persistent identifier scheme' (ARK [1], PURL, Handle, etc[2]). (Though I
really like CrossRef and the things they're doing.)

[1] http://www.cdlib.org/inside/diglib/ark/
[2] http://www.persistent-identifier.de/english/204-examples.php

-Jodi

On Tue, Nov 17, 2009 at 11:44 PM, Bucknell, Terry <
t.d.buckn...@liverpool.ac.uk> wrote:

> You should be able to find all the information you need about CrossRef fees
> and rules at:
>
> http://www.crossref.org/02publishers/20pub_fees.html
>
> and
>
> http://www.crossref.org/02publishers/59pub_rules.html
>
> Information about the system of registering and maintaining DOIs is at:
>
> http://www.crossref.org/help/
>
> Note that as well as registering DOIs for the articles in LLT, LLT would be
> obliged to link to the articles cited by LLT articles (for cited articles
> that have DOIs too). Looking at the LLT site, it looks like they would have
> to change their 'abstract' pages to 'abstract plus cited refs', or change
> the way that their PDFs are created so that they include DOI links for cited
> references. (Without this the whole system would fail: publishers would
> expect traffic to come to them, but wouldn't have to send traffic
> elsewhere).
>
> I'd agree that DOIs are in general a Good Thing (and for e-books / e-book
> chapters, and reference work entries as well as e-journal articles). The
> CrossRef fees are deliberately set so as not to exclude single-title
> publishers. Here's an example of a single-title, university-based e-journal
> in the UK that provides DOIs, so it must be a CrossRef member:
> http://www.bioscience.heacademy.ac.uk/journal/.
>
>
> Terry Bucknell
> Electronic Resources Manager
> University of Liverpool
>
>
> -Original Message-
> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
> Jonathan Rochkind
> Sent: 17 November 2009 23:20
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Assigning DOI for local content
>
> So I have no actual experience with this.
>
> But you have to pay for DOI's.  I've never done it, but I don't think
> you neccesarily have to run your own purl server -- CrossRef takes care
> of it.  Of course, if your documents are going to be moving all over the
> place, if you run your own purl server and register your purls with
> CrossRef, then when a document moves, you can update your local purl
> server; otherwise, you can update CrossRef, heh.
>
> It certainly is useful to have DOIs, I agree.  I would suggest they
> should just contact cross-ref and get information on the cost, and what
> their responsibilities are, and then they'll be able to decide.  If the
> 'structure of their content' is journal articles, then, sure DOI is
> pretty handy for people wanting to cite or link to those articles.
>
> Jonathan
>
> Ranti Junus wrote:
> > Hi All,
> >
> > I was asked by somebody from a college @ my institution whether they
> > should go with assigning DOI for their journal articles:
> > http://llt.msu.edu/
> >
> > I can see the advantage of this approach and my first thought is more
> > about whether they have resources in running their purl server, or
> > whether they would need to do it through crossref (or any other
> > agency.) Has anybody had any experience about this?
> >
> > Moreover, are there other factors that one should consider (pros and
> > cons) about this? Or, looking at the structure of their content,
> > whether they ever need DOI? Any ideas and/or suggestions?
> >
> >
> > Any insights about this is much appreciated.
> >
> >
> > thanks,
> > ranti.
> >
> >
>

Re: [CODE4LIB] Assigning DOI for local content

[Eric Hellman]

The most important reason for a journal to submit its metadata to Crossref is 
to get citations in other journals to link to yours, and of course to get your 
citations linked to other journals.

The redirection system can be useful of course, but the link discovery system, 
and the fact that it's embedded in so many other publisher workflows, makes it 
invaluable.

Eric

On Nov 17, 2009, at 6:58 PM, Jodi Schneider wrote:

> The first question is: what are they trying to accomplish by having DOIs?
> 
> Do they have a long-term plan for persistence of their content? Financial
> plan?
> 
> If they're looking for persistent identifiers, I don't understand (a
> priori), why DOI is better, as an identifier scheme, than any other
> 'persistent identifier scheme' (ARK [1], PURL, Handle, etc[2]). (Though I
> really like CrossRef and the things they're doing.)
> 
> [1] http://www.cdlib.org/inside/diglib/ark/
> [2] http://www.persistent-identifier.de/english/204-examples.php
> 
> -Jodi
> 
> On Tue, Nov 17, 2009 at 11:44 PM, Bucknell, Terry <
> t.d.buckn...@liverpool.ac.uk> wrote:
> 
>> You should be able to find all the information you need about CrossRef fees
>> and rules at:
>> 
>> http://www.crossref.org/02publishers/20pub_fees.html
>> 
>> and
>> 
>> http://www.crossref.org/02publishers/59pub_rules.html
>> 
>> Information about the system of registering and maintaining DOIs is at:
>> 
>> http://www.crossref.org/help/
>> 
>> Note that as well as registering DOIs for the articles in LLT, LLT would be
>> obliged to link to the articles cited by LLT articles (for cited articles
>> that have DOIs too). Looking at the LLT site, it looks like they would have
>> to change their 'abstract' pages to 'abstract plus cited refs', or change
>> the way that their PDFs are created so that they include DOI links for cited
>> references. (Without this the whole system would fail: publishers would
>> expect traffic to come to them, but wouldn't have to send traffic
>> elsewhere).
>> 
>> I'd agree that DOIs are in general a Good Thing (and for e-books / e-book
>> chapters, and reference work entries as well as e-journal articles). The
>> CrossRef fees are deliberately set so as not to exclude single-title
>> publishers. Here's an example of a single-title, university-based e-journal
>> in the UK that provides DOIs, so it must be a CrossRef member:
>> http://www.bioscience.heacademy.ac.uk/journal/.
>> 
>> 
>> Terry Bucknell
>> Electronic Resources Manager
>> University of Liverpool
>> 
>> 
>> -Original Message-
>> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
>> Jonathan Rochkind
>> Sent: 17 November 2009 23:20
>> To: CODE4LIB@LISTSERV.ND.EDU
>> Subject: Re: [CODE4LIB] Assigning DOI for local content
>> 
>> So I have no actual experience with this.
>> 
>> But you have to pay for DOI's.  I've never done it, but I don't think
>> you neccesarily have to run your own purl server -- CrossRef takes care
>> of it.  Of course, if your documents are going to be moving all over the
>> place, if you run your own purl server and register your purls with
>> CrossRef, then when a document moves, you can update your local purl
>> server; otherwise, you can update CrossRef, heh.
>> 
>> It certainly is useful to have DOIs, I agree.  I would suggest they
>> should just contact cross-ref and get information on the cost, and what
>> their responsibilities are, and then they'll be able to decide.  If the
>> 'structure of their content' is journal articles, then, sure DOI is
>> pretty handy for people wanting to cite or link to those articles.
>> 
>> Jonathan
>> 
>> Ranti Junus wrote:
>>> Hi All,
>>> 
>>> I was asked by somebody from a college @ my institution whether they
>>> should go with assigning DOI for their journal articles:
>>> http://llt.msu.edu/
>>> 
>>> I can see the advantage of this approach and my first thought is more
>>> about whether they have resources in running their purl server, or
>>> whether they would need to do it through crossref (or any other
>>> agency.) Has anybody had any experience about this?
>>> 
>>> Moreover, are there other factors that one should consider (pros and
>>> cons) about this? Or, looking at the structure of their content,
>>> whether they ever need DOI? Any ideas and/or suggestions?
>>> 
>>> 
>>> Any insights about this is much appreciated.
>>> 
>>> 
>>> thanks,
>>> ranti.
>>> 
>>> 
>> 

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

e...@hellman.net 
http://go-to-hellman.blogspot.com/

Re: [CODE4LIB] Assigning DOI for local content

[Jodi Schneider]

On Tue, Nov 17, 2009 at 11:50 PM, Jonathan Rochkind wrote:

> Bucknell, Terry wrote:
>
>> Note that as well as registering DOIs for the articles in LLT, LLT would
>> be obliged to link to the articles cited by LLT articles (for cited articles
>> that have DOIs too).
>>
>
> Huh, I didn't know that. I understand the motivation, but investigating
> whether every cited article has a DOI and then making sure to include it...
> is non-trivial labor.
>

It does allow precise "cited by" measures:
http://www.crossref.org/citedby.html

This is where CrossRef's awesomeness comes in:
http://www.crossref.org/guestquery/#stqsearch

http://www.crossref.org/SimpleTextQuery/

as well as various experiments:
http://labs.crossref.org/
CrossRef does have certain free, lookup services which might be appropriate
for services like Umlaut, if you can sign a licensing agreement.

-Jodi


> Jonathan
>

Re: [CODE4LIB] Assigning DOI for local content

[Bucknell, Terry]

They automate the process for obtaining DOIs for cited articles. See 
http://www.crossref.org/01company/16fastfacts.html:

"In a separate process, the publisher also submits the citations contained in 
each deposited article to the Reference Resolver, the front-end component of 
the MDDB that allows for the retrieval of DOIs. This way, the publisher can, as 
part of its electronic production process, add outbound links to any of an 
article’s citations that point to content already registered in the CrossRef 
system. The CrossRef website includes technical specifications for querying and 
a demo of the DOI look-up process. If you know the DOI for an article, that’s 
all you need to know in order to locate it persistently. If a publisher changes 
the location of an article, it need only update the URL for the article in one 
place with CrossRef."


Terry Bucknell
Electronic Resources Manager
University of Liverpool

-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of 
Jonathan Rochkind
Sent: 17 November 2009 23:50
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Assigning DOI for local content

Bucknell, Terry wrote:
> Note that as well as registering DOIs for the articles in LLT, LLT would be 
> obliged to link to the articles cited by LLT articles (for cited articles 
> that have DOIs too).

Huh, I didn't know that. I understand the motivation, but investigating 
whether every cited article has a DOI and then making sure to include 
it... is non-trivial labor.

Jonathan

Re: [CODE4LIB] Assigning DOI for local content

[Jodi Schneider]

The first question is: what are they trying to accomplish by having DOIs?

Do they have a long-term plan for persistence of their content? Financial
plan?

If they're looking for persistent identifiers, I don't understand (a
priori), why DOI is better, as an identifier scheme, than any other
'persistent identifier scheme' (ARK [1], PURL, Handle, etc[2]). (Though I
really like CrossRef and the things they're doing.)

[1] http://www.cdlib.org/inside/diglib/ark/
[2] http://www.persistent-identifier.de/english/204-examples.php

-Jodi

On Tue, Nov 17, 2009 at 11:44 PM, Bucknell, Terry <
t.d.buckn...@liverpool.ac.uk> wrote:

> You should be able to find all the information you need about CrossRef fees
> and rules at:
>
> http://www.crossref.org/02publishers/20pub_fees.html
>
> and
>
> http://www.crossref.org/02publishers/59pub_rules.html
>
> Information about the system of registering and maintaining DOIs is at:
>
> http://www.crossref.org/help/
>
> Note that as well as registering DOIs for the articles in LLT, LLT would be
> obliged to link to the articles cited by LLT articles (for cited articles
> that have DOIs too). Looking at the LLT site, it looks like they would have
> to change their 'abstract' pages to 'abstract plus cited refs', or change
> the way that their PDFs are created so that they include DOI links for cited
> references. (Without this the whole system would fail: publishers would
> expect traffic to come to them, but wouldn't have to send traffic
> elsewhere).
>
> I'd agree that DOIs are in general a Good Thing (and for e-books / e-book
> chapters, and reference work entries as well as e-journal articles). The
> CrossRef fees are deliberately set so as not to exclude single-title
> publishers. Here's an example of a single-title, university-based e-journal
> in the UK that provides DOIs, so it must be a CrossRef member:
> http://www.bioscience.heacademy.ac.uk/journal/.
>
>
> Terry Bucknell
> Electronic Resources Manager
> University of Liverpool
>
>
> -Original Message-
> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
> Jonathan Rochkind
> Sent: 17 November 2009 23:20
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Assigning DOI for local content
>
> So I have no actual experience with this.
>
> But you have to pay for DOI's.  I've never done it, but I don't think
> you neccesarily have to run your own purl server -- CrossRef takes care
> of it.  Of course, if your documents are going to be moving all over the
> place, if you run your own purl server and register your purls with
> CrossRef, then when a document moves, you can update your local purl
> server; otherwise, you can update CrossRef, heh.
>
> It certainly is useful to have DOIs, I agree.  I would suggest they
> should just contact cross-ref and get information on the cost, and what
> their responsibilities are, and then they'll be able to decide.  If the
> 'structure of their content' is journal articles, then, sure DOI is
> pretty handy for people wanting to cite or link to those articles.
>
> Jonathan
>
> Ranti Junus wrote:
> > Hi All,
> >
> > I was asked by somebody from a college @ my institution whether they
> > should go with assigning DOI for their journal articles:
> > http://llt.msu.edu/
> >
> > I can see the advantage of this approach and my first thought is more
> > about whether they have resources in running their purl server, or
> > whether they would need to do it through crossref (or any other
> > agency.) Has anybody had any experience about this?
> >
> > Moreover, are there other factors that one should consider (pros and
> > cons) about this? Or, looking at the structure of their content,
> > whether they ever need DOI? Any ideas and/or suggestions?
> >
> >
> > Any insights about this is much appreciated.
> >
> >
> > thanks,
> > ranti.
> >
> >
>

Re: [CODE4LIB] Assigning DOI for local content

[Jonathan Rochkind]

Bucknell, Terry wrote:

Note that as well as registering DOIs for the articles in LLT, LLT would be 
obliged to link to the articles cited by LLT articles (for cited articles that 
have DOIs too).


Huh, I didn't know that. I understand the motivation, but investigating 
whether every cited article has a DOI and then making sure to include 
it... is non-trivial labor.


Jonathan

Re: [CODE4LIB] Assigning DOI for local content

[Bucknell, Terry]

You should be able to find all the information you need about CrossRef fees and 
rules at:

http://www.crossref.org/02publishers/20pub_fees.html

and

http://www.crossref.org/02publishers/59pub_rules.html

Information about the system of registering and maintaining DOIs is at:

http://www.crossref.org/help/

Note that as well as registering DOIs for the articles in LLT, LLT would be 
obliged to link to the articles cited by LLT articles (for cited articles that 
have DOIs too). Looking at the LLT site, it looks like they would have to 
change their 'abstract' pages to 'abstract plus cited refs', or change the way 
that their PDFs are created so that they include DOI links for cited 
references. (Without this the whole system would fail: publishers would expect 
traffic to come to them, but wouldn't have to send traffic elsewhere).

I'd agree that DOIs are in general a Good Thing (and for e-books / e-book 
chapters, and reference work entries as well as e-journal articles). The 
CrossRef fees are deliberately set so as not to exclude single-title 
publishers. Here's an example of a single-title, university-based e-journal in 
the UK that provides DOIs, so it must be a CrossRef member: 
http://www.bioscience.heacademy.ac.uk/journal/.


Terry Bucknell
Electronic Resources Manager
University of Liverpool


-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of 
Jonathan Rochkind
Sent: 17 November 2009 23:20
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Assigning DOI for local content

So I have no actual experience with this.

But you have to pay for DOI's.  I've never done it, but I don't think 
you neccesarily have to run your own purl server -- CrossRef takes care 
of it.  Of course, if your documents are going to be moving all over the 
place, if you run your own purl server and register your purls with 
CrossRef, then when a document moves, you can update your local purl 
server; otherwise, you can update CrossRef, heh.

It certainly is useful to have DOIs, I agree.  I would suggest they 
should just contact cross-ref and get information on the cost, and what 
their responsibilities are, and then they'll be able to decide.  If the 
'structure of their content' is journal articles, then, sure DOI is 
pretty handy for people wanting to cite or link to those articles.

Jonathan

Ranti Junus wrote:
> Hi All,
>
> I was asked by somebody from a college @ my institution whether they
> should go with assigning DOI for their journal articles:
> http://llt.msu.edu/
>
> I can see the advantage of this approach and my first thought is more
> about whether they have resources in running their purl server, or
> whether they would need to do it through crossref (or any other
> agency.) Has anybody had any experience about this?
>
> Moreover, are there other factors that one should consider (pros and
> cons) about this? Or, looking at the structure of their content,
> whether they ever need DOI? Any ideas and/or suggestions?
>
>
> Any insights about this is much appreciated.
>
>
> thanks,
> ranti.
>
>   

Re: [CODE4LIB] Assigning DOI for local content

[Jonathan Rochkind]

So I have no actual experience with this.

But you have to pay for DOI's.  I've never done it, but I don't think 
you neccesarily have to run your own purl server -- CrossRef takes care 
of it.  Of course, if your documents are going to be moving all over the 
place, if you run your own purl server and register your purls with 
CrossRef, then when a document moves, you can update your local purl 
server; otherwise, you can update CrossRef, heh.


It certainly is useful to have DOIs, I agree.  I would suggest they 
should just contact cross-ref and get information on the cost, and what 
their responsibilities are, and then they'll be able to decide.  If the 
'structure of their content' is journal articles, then, sure DOI is 
pretty handy for people wanting to cite or link to those articles.


Jonathan

Ranti Junus wrote:

Hi All,

I was asked by somebody from a college @ my institution whether they
should go with assigning DOI for their journal articles:
http://llt.msu.edu/

I can see the advantage of this approach and my first thought is more
about whether they have resources in running their purl server, or
whether they would need to do it through crossref (or any other
agency.) Has anybody had any experience about this?

Moreover, are there other factors that one should consider (pros and
cons) about this? Or, looking at the structure of their content,
whether they ever need DOI? Any ideas and/or suggestions?


Any insights about this is much appreciated.


thanks,
ranti.

  

[CODE4LIB] Assigning DOI for local content

[Ranti Junus]

Hi All,

I was asked by somebody from a college @ my institution whether they
should go with assigning DOI for their journal articles:
http://llt.msu.edu/

I can see the advantage of this approach and my first thought is more
about whether they have resources in running their purl server, or
whether they would need to do it through crossref (or any other
agency.) Has anybody had any experience about this?

Moreover, are there other factors that one should consider (pros and
cons) about this? Or, looking at the structure of their content,
whether they ever need DOI? Any ideas and/or suggestions?


Any insights about this is much appreciated.


thanks,
ranti.

-- 
Bulk mail.  Postage paid.