I'm also having a problem with this (conference proceeding/book chapter):
dx.doi.org can resolve this:
10.3233/978-1-58603-942-4-115
but Zotero can't find it and gives the error "Lookup failed: Zotero could not find a record for the specified identifier. Please verify the identifier and try again."
http://dx.doi.org/10.3233/978-1-58603-942-4-115
I've updated translators (as the first part of this thread suggested), to no avail. (And the IOS translator just hangs here.)
There does appear to be a bug in the DOI lookup code-- this is the same behavior I noted above for 10.1016/S1479-8387(04)01102-6; the code Zotero uses to parse the responses from CrossRef is not flexible enough to handle book sections correctly. The explanation I gave above holds in this case too.
I don't have the time right now to make the necessary changes to the CrossRef translator; perhaps someone else who uses DOI in their field might take a look? It's probably just a matter of adding an additional section to the code to handle book sections.
I've pushed an updated version of the CrossRef translator that, in my (limited) testing, fixes saving of book chapters, as well as an issue I noticed in which creator roles (author, editor, etc.) weren't properly set. Your copy of Zotero should auto-update within 24 hours, or you can update manually by clicking Update Now in the General pane of the Zotero prefs.
The CrossRef API doesn't appear to be returning any data for Jodi's DOI, even though it redirects properly. ajlyon, are you seeing something different?
Please let us know if you run into any additional issues.
Alas, Zotero doesn't download the associated PDF file even though the link is there; is this a related problem or entirely different?
Entirely different. Zotero is getting the metadata from CrossRef, not the original site. To get the PDF, it would have to follow the resolver to the original site, check if it had a translator for that site, and then save from there instead, but that would be considerably slower, the metadata would potentially be of lower quality, the PDF would often not be accessible on the public page for off-campus users (without logging in through a proxy, etc.), and there's no mechanism currently for even knowing if a particular translator supports PDF-saving ahead of time. So, not an easy problem.
Okay ... perhaps then I need to look at the the translator for the Emerald site.
What got me onto the DOI issue was that at some Emerald pages, Zotero says "Save to Zotero (DOI)" rather than "Save to Zotero (Emerald Publishing)". I'll have to do some digging as I have figured out a pattern to this.
Dan, I was perhaps too hasty in saying that these were the same issue.
Looking more carefully, however, it's pretty easy to tell that Jodi's DOI is really just an ISBN-13, suffixed by the page number that the section starts on; that publication uses such a system for all the sections of that book. This seems more like a registry metadata issue than a Zotero one, although I can't say I understand it. There is a standard for registering ISBNs in the DOI system (ISBN-A, http://www.doi.org/factsheets/ISBN-A.html), but that doesn't use a prefix (like 10.3233 here), and there should be metadata in the registry anyway.
The
doi:10.1371/journal.pmed.0020138.g001
does unfortunately not work in Zotero, whereas
http://dx.doi.org/10.1371/journal.pmed.0020138.g001
succeeds.
I'm using Zotero 2.0.2. What can I do?
I'm grateful for any suggestions.
Are you intending to add the article to Zotero, or specifically the first illustration? The doi for the article is 10.1371/journal.pmed.0020138, without the .g001
The image itself probably doesn't have any metadata associated with it in crossref, so there would probably be no information for Zotero to save as an item.
To save the full article simply remove the ".g001" suffix after pasting into the "add item from identifier" box. It would be nice if Zotero could do this automatically actually, assuming such suffixes have a consistent format.
If you wanted the illustration only your best option is to resolve the doi (i.e. go to dx.doi.org/10.1371....), right click on the image and select Zotero -> save image as Zotero item.
I would like to add these DOI: 10.2902/1725-0463.2010.05.art4, (tested @ CrossRef and it works) but it doesn't work in Zotero. Furthermore, other Articles from "International Journal of Spatial Data Infrastructures Research" doesn't work with their DOI.
My Resolver is: http://worldcatlibraries.org/registry/gateway (v.1.0).
Every DOI I tried, doesn't work. Where is the problem?
When I try to add an item by entering its ISBN, the throbber just displays forever and nothing happens. Any ideas on what is going awry there?
I'm on a Mac (OS X 10.6.4), using FF 3.6.8 and am connected through my university's VPN client. I've also FF4.0b4 on the system (though it's not running while I work with FF3) and I'm using Firefox Sync. No other add-ons installed. Funny enough, it works on FF3.6.8 on Win7 + Firefox Sync + VPN...
I just created a backup of my zotero (Actions > Export library), synced my stuff with the zotero server, then synced my Firefox data with Firefox Sync [1] (click on the arrow symbol in the browser's lower right hand corner) closed and removed Firefox (both 3 and 4beta) and my Firefox Profile and reinstalled Firefox [2]. Downloaded Firefox sync, restarted Firefox, synced everything back, downloaded zotero, adjusted its settings, synced everything back and now it (Add Item by Identifier) works. Took about 10 minutes in total, I guess. :)
So, I suppose it was an issue with having FF beta installed, after all.
1) https://addons.mozilla.org/de/firefox/addon/10868/
2) http://getfirefox.com
Just noting that Export Library is not a proper backup method (and Zotero sync isn't really the right way to do it either). Reinstalling Firefox is also generally overkill for fixing problems, at least without further debugging—there aren't a huge number of ways a Firefox installation can become corrupted.
Here, IFIP Advances in Information and Communication Technology is being called a book series, and the volume E-Health is a book of type "other" in that series, specifically volume 335. The DOI refers specifically to a chapter in that book (a 2-page chapter at that!)... Something about this kooky setup is confusing the translator. If CrossRef listed the book as an "edited_book", then I think we'd handle it correctly.
This is an edge case and I wish CrossRef just used a well-defined common format. Unless you find that such books are particularly common, I'm not really inclined to spend the time re-engineering the translator to handle this well. You can still add the book by ISBN 978-3-642-15515-4 and make a book section of it in order to save some time.
I would like to add these DOI: 10.2902/1725-0463.2010.05.art4, (tested @ CrossRef and it works) but it doesn't work in Zotero. Furthermore, other Articles from "International Journal of Spatial Data Infrastructures Research" doesn't work with their DOI.
My Resolver is: http://worldcatlibraries.org/registry/gateway (v.1.0).
Every DOI I tried, doesn't work. Where is the problem?
here's what seems like the relevant line from the debug:
(3)(+0000002): HTTP GET http://www.crossref.org/openurl/?pid=zter:zter321&url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&rft_id=info%3Adoi/10.2902/1725-0463.2010.05.art4&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&noredirect=true&format=unixref
I'm not sure why, but while typing the DOI into the form on the front page of CrossRef works, it doesn't work on this page. (Fails with "DOI not found in CrossRef.") Unless there's something I'm missing, it might be worth reporting this to CrossRef.
This is the typical case of a DOI where the CrossRef OpenURL resolver doesn't resolve correctly, but the DOI redirect (dx.doi.org, for example) does work. I don't know why these happen, but Zotero can't resolve them since CrossRef doesn't seem to have data for that DOI.
If this is a frequent problem, contact the journal publisher and/or CrossRef and see what they say -- their lookup service is telling Zotero that it doesn't have data for this and other occasional DOIs.
I can't seem to add DOIs from the European Commission, such as:
10.2903/j.efsa.2010.1806
This resolves fine from dx.doi.org, but Zotero seems to have problems with it. Is this perhaps because the publications of the European Commission have their own registration authority separate from CrossRef? If Zotero really only works with DOIs registered by CrossRef, this should perhaps be clarified (or preferably fixed).
Correction: CrossRef seems to resolve the DOI above just fine. If I enter the DOI into a Zotero bibliographic record manually and click on the DOI, it goes directly to the right place as well.
When I add the PDF to my library and try to retrieve meta-data from it, it does retrieve a record, but a completely different one that's unrelated to the PDF. I"m not sure if this is related to the DOI problem or if it's something different though.
The redirect service does work, as you say. All I can tell you is that some DOIs work for redirection but their metadata isn't in the lookup system. As I said, you should contact CrossRef and/or the publishers if this is a frequent problem for you, since someone on their end is doing something wrong.
Does CrossRef have access to the meta-data for DOIs registered by different registration agencies? The DOIs I'm having trouble with are for documents published by the European Commission and presumably registered by their own registration agency, OPOCE (http://publications.europa.eu/).
If I asked CrossRef about metadata lookup for DOIs registered by OPOCE, would they even be able to help me?
If this is a design limitation that is not likely to be fixable, it would be helpful to document it someplace, so that users are aware that they can only add by DOI for DOIs registered by CrossRef.
yeah - that would seem to be the problem.
It might be interesting to see if OPOCE offers a similar lookup service to Crossref - in which case it would be possible to include that in the add by identifier section. But that' won't be long-term
If we find that there are entire classes of DOIs that are registered with a non-CrossRef service, I suppose we could make the lookup system fall back to other servers. Still, I think that all DOIs are supposed to have data in CrossRef.
Springer DOIs (which resolve fine via dx.doi.org) give me problems, frequently. Example: 10.1007/978-3-642-15464-5_30
I can't add by identifier. Second, I can't add with the page translator, since the Springer page translator sees the DOI, it tries first to add by DOI (and fails).
This continues to be a significant and disruptive problem for me.
Upgrade Storage
dx.doi.org can resolve this:
10.3233/978-1-58603-942-4-115
but Zotero can't find it and gives the error "Lookup failed: Zotero could not find a record for the specified identifier. Please verify the identifier and try again."
http://dx.doi.org/10.3233/978-1-58603-942-4-115
I've updated translators (as the first part of this thread suggested), to no avail. (And the IOS translator just hangs here.)
Other ideas?
Thanks!
-Jodi
I don't have the time right now to make the necessary changes to the CrossRef translator; perhaps someone else who uses DOI in their field might take a look? It's probably just a matter of adding an additional section to the code to handle book sections.
The CrossRef API doesn't appear to be returning any data for Jodi's DOI, even though it redirects properly. ajlyon, are you seeing something different?
Please let us know if you run into any additional issues.
Alas, Zotero doesn't download the associated PDF file even though the link is there; is this a related problem or entirely different?
For an exampl, see the DOI I originally gave, 10.1016/S1479-8387(04)01102-6
What got me onto the DOI issue was that at some Emerald pages, Zotero says "Save to Zotero (DOI)" rather than "Save to Zotero (Emerald Publishing)". I'll have to do some digging as I have figured out a pattern to this.
Looking more carefully, however, it's pretty easy to tell that Jodi's DOI is really just an ISBN-13, suffixed by the page number that the section starts on; that publication uses such a system for all the sections of that book. This seems more like a registry metadata issue than a Zotero one, although I can't say I understand it. There is a standard for registering ISBNs in the DOI system (ISBN-A, http://www.doi.org/factsheets/ISBN-A.html), but that doesn't use a prefix (like 10.3233 here), and there should be metadata in the registry anyway.
doi:10.1371/journal.pmed.0020138.g001
does unfortunately not work in Zotero, whereas
http://dx.doi.org/10.1371/journal.pmed.0020138.g001
succeeds.
I'm using Zotero 2.0.2. What can I do?
I'm grateful for any suggestions.
The image itself probably doesn't have any metadata associated with it in crossref, so there would probably be no information for Zotero to save as an item.
To save the full article simply remove the ".g001" suffix after pasting into the "add item from identifier" box. It would be nice if Zotero could do this automatically actually, assuming such suffixes have a consistent format.
If you wanted the illustration only your best option is to resolve the doi (i.e. go to dx.doi.org/10.1371....), right click on the image and select Zotero -> save image as Zotero item.
Thanks for your quick reply!
My Resolver is: http://worldcatlibraries.org/registry/gateway (v.1.0).
Every DOI I tried, doesn't work. Where is the problem?
Please help me.
Thank you
I'm on a Mac (OS X 10.6.4), using FF 3.6.8 and am connected through my university's VPN client. I've also FF4.0b4 on the system (though it's not running while I work with FF3) and I'm using Firefox Sync. No other add-ons installed. Funny enough, it works on FF3.6.8 on Win7 + Firefox Sync + VPN...
The number I tested with is 0142404675
Help, please. :)
So, I suppose it was an issue with having FF beta installed, after all.
1) https://addons.mozilla.org/de/firefox/addon/10868/
2) http://getfirefox.com
-Jodi
[1] 10.1007/978-3-642-15515-4_23
[2] http://dx.doi.org/10.1007/978-3-642-15515-4_23
Here, IFIP Advances in Information and Communication Technology is being called a book series, and the volume E-Health is a book of type "other" in that series, specifically volume 335. The DOI refers specifically to a chapter in that book (a 2-page chapter at that!)... Something about this kooky setup is confusing the translator. If CrossRef listed the book as an "edited_book", then I think we'd handle it correctly.
This is an edge case and I wish CrossRef just used a well-defined common format. Unless you find that such books are particularly common, I'm not really inclined to spend the time re-engineering the translator to handle this well. You can still add the book by ISBN 978-3-642-15515-4 and make a book section of it in order to save some time.
My Resolver is: http://worldcatlibraries.org/registry/gateway (v.1.0).
Every DOI I tried, doesn't work. Where is the problem?
Please help me.
Thank you
(3)(+0000002): HTTP GET http://www.crossref.org/openurl/?pid=zter:zter321&url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&rft_id=info%3Adoi/10.2902/1725-0463.2010.05.art4&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&noredirect=true&format=unixref
next Zotero reports not finding this in Crossref
If this is a frequent problem, contact the journal publisher and/or CrossRef and see what they say -- their lookup service is telling Zotero that it doesn't have data for this and other occasional DOIs.
I can't seem to add DOIs from the European Commission, such as:
10.2903/j.efsa.2010.1806
This resolves fine from dx.doi.org, but Zotero seems to have problems with it. Is this perhaps because the publications of the European Commission have their own registration authority separate from CrossRef? If Zotero really only works with DOIs registered by CrossRef, this should perhaps be clarified (or preferably fixed).
Thanks
When I add the PDF to my library and try to retrieve meta-data from it, it does retrieve a record, but a completely different one that's unrelated to the PDF. I"m not sure if this is related to the DOI problem or if it's something different though.
http://www.crossref.org/openurl/?pid=zter:zter321&url_ver=Z39.88-2004&req_dat=usr:pwd&rft_id=info:doi/10.2903/j.efsa.2010.1806&format=unixref&redirect=false
The redirect service does work, as you say. All I can tell you is that some DOIs work for redirection but their metadata isn't in the lookup system. As I said, you should contact CrossRef and/or the publishers if this is a frequent problem for you, since someone on their end is doing something wrong.
If I asked CrossRef about metadata lookup for DOIs registered by OPOCE, would they even be able to help me?
If this is a design limitation that is not likely to be fixable, it would be helpful to document it someplace, so that users are aware that they can only add by DOI for DOIs registered by CrossRef.
It might be interesting to see if OPOCE offers a similar lookup service to Crossref - in which case it would be possible to include that in the add by identifier section. But that' won't be long-term
10.1007/978-3-642-15464-5_30
I can't add by identifier. Second, I can't add with the page translator, since the Springer page translator sees the DOI, it tries first to add by DOI (and fails).
This continues to be a significant and disruptive problem for me.
-Jodi