Re: [CODE4LIB] Assigning DOI for local content

2009-11-25 Thread Eric Hellman
On Nov 23, 2009, at 1:32 PM, Ross Singer wrote:

 On Mon, Nov 23, 2009 at 1:07 PM, Eric Hellman e...@hellman.net 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

2009-11-23 Thread 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 e...@hellman.net 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

2009-11-23 Thread Ross Singer
On Mon, Nov 23, 2009 at 1:07 PM, Eric Hellman e...@hellman.net 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

2009-11-23 Thread 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 e...@hellman.net 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 e...@hellman.net 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

2009-11-23 Thread 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: 
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/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:  
http://web.mit.edu/handle/www/purl-eval.html


Re: [CODE4LIB] Assigning DOI for local content

2009-11-23 Thread Ross Singer
On Mon, Nov 23, 2009 at 2:52 PM, Jonathan Rochkind rochk...@jhu.edu 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 strikehandle/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.





Re: [CODE4LIB] Assigning DOI for local content

2009-11-23 Thread 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 rochk...@jhu.edu 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 strikehandle/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, 

Re: [CODE4LIB] Assigning DOI for local content

2009-11-23 Thread 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 rochk...@jhu.edu 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 rochk...@jhu.edu
 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 

Re: [CODE4LIB] Assigning DOI for local content

2009-11-23 Thread 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 tomke...@gmail.com 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 rochk...@jhu.edu wrote:
 The actual handle ...


Re: [CODE4LIB] Assigning DOI for local content

2009-11-23 Thread 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 tomke...@gmail.com 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 rochk...@jhu.edu wrote:
  

The actual handle ...



  


Re: [CODE4LIB] Assigning DOI for local content

2009-11-23 Thread 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 tomke...@gmail.com 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 rochk...@jhu.edu wrote:
  

The actual handle ...



  


Re: [CODE4LIB] Assigning DOI for local content

2009-11-21 Thread 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

2009-11-20 Thread 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

2009-11-20 Thread Ross Singer
On Fri, Nov 20, 2009 at 2:23 PM, Eric Hellman e...@hellman.net 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

2009-11-19 Thread Tom Keays
On Tue, Nov 17, 2009 at 6:58 PM, Jodi Schneider
jodi.a.schnei...@gmail.com 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

2009-11-19 Thread 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 h...@u.library.arizona.edu 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

2009-11-19 Thread 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 h...@u.library.arizona.edu 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 h...@u.library.arizona.edu 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

2009-11-18 Thread 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

2009-11-18 Thread 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

2009-11-18 Thread 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

2009-11-18 Thread 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

2009-11-18 Thread Ross Singer
On Wed, Nov 18, 2009 at 12:19 PM, Han, Yan h...@u.library.arizona.edu 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.


[CODE4LIB] Assigning DOI for local content

2009-11-17 Thread 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.


Re: [CODE4LIB] Assigning DOI for local content

2009-11-17 Thread 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.

  


Re: [CODE4LIB] Assigning DOI for local content

2009-11-17 Thread 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

2009-11-17 Thread 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

2009-11-17 Thread 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.