Re: [CODE4LIB] Assigning DOI for local content
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
