Upgrade StorageDon't import DOIs from JSTOR?
JSTOR frequently creates ID numbers for its articles that resemble DOIs, but are not registered with an DOI registrar (e.g., https://www.jstor.org/stable/20003731 has the internal ID: 10.2307/20003731). I don't know why JSTOR thinks this is a good idea. Zotero imports these as DOIs. As a result, my library has a lot of DOI fields filled with broken DOIs.
I think that importing fake DOIs into users' databases is a much bigger problem than not importing a valid DOI, as I don't imagine many users are going to check to see whether the imported DOIs are valid. So, I propose not importing DOIs from JSTOR at all. If JSTOR uses a consistent prefix for this fake DOIs (e.g., maybe "10.2307"), perhaps the translator could instead only discard these DOIs?
I think that importing fake DOIs into users' databases is a much bigger problem than not importing a valid DOI, as I don't imagine many users are going to check to see whether the imported DOIs are valid. So, I propose not importing DOIs from JSTOR at all. If JSTOR uses a consistent prefix for this fake DOIs (e.g., maybe "10.2307"), perhaps the translator could instead only discard these DOIs?
This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
a) all JSTOR DOIs are sham and
b) all DOIs with the 2307 prefix are sham
and then proceed accordingly. Trying to think about who to ask. @zuphilip any ideas?
https://doi.org/10.2307
Unfortunately, JSTOR uses the same structure for actual DOIs:
https://www.jstor.org/stable/1157615
https://doi.org/10.2307/1157615
As for sham DOIs:
https://www.jstor.org/stable/20003731
https://doi.org/10.2307/20003731
So it seems like Zotero would either have to try to resolve the DOI before saving it or just assume that all JSTOR DOIs are sham.
(Man I wish JSTOR would listen to the complaints/CrossRef's begging them not to do this.)
AFAIS we use this http://api.crossref.org/works/10.2307/20003731/agency for testing, and it seems this API call now returns always ok, even when the individual DOI is fake. Maybe we could just drop the
/agencypart here...Fake DOI isn't there:
TY - JOUR
TI - Migration, Knowledge and Social Interaction: Expatriate Labour within Investment Banks
AU - Beaverstock, Jonathan V.
AB -
C1 - Full publication date: Dec., 1996
EP - 470
IS - 4
PB - [Royal Geographical Society (with the Institute of British Geographers), Wiley]
PY - 1996
SN - 00040894, 14754762
SP - 459
T2 - Area
UR - http://www.jstor.org/stable/20003731
VL - 28
ER -
Real one is:
TY - JOUR
TI - Kinship Terminology and the Initial Vowel
AU - Whiteley, W. H.
AB -
C1 - Full publication date: Jul., 1959
DO - 10.2307/1157615
EP - 262
IS - 3
PB - [Cambridge University Press, International African Institute]
PY - 1959
SN - 00019720, 17500184
SP - 253
T2 - Africa: Journal of the International African Institute
UR - http://www.jstor.org/stable/1157615
VL - 29
ER -
Any further problems let us know & thanks for reporting.