Because of their format. I'm just curious if CMoS or any other similar source has anything to say about this.
This would be a substantial change in Zotero if we're going to consider short DOIs. Not for the DOI label clickability, but, for instance, duplicate detection (short DOIs and long DOIs should be considered duplicates, or at the very least not prevent duplicate detection, which may already be the case). We should probably not discard such DOIs from translators, but I also don't think that this format gives enough confidence to scan for such DOIs on webpages or in PDFs.
We could also consider automatically resolving short DOIs to long DOIs as they are entered into Zotero.
The other thing is that while shortdoi.org says that "Applications which resolve DOI names will treat the shortDOI identically to the original", this isn't exactly true, since, for instance, neither http://www.crossref.org/guestquery/ nor https://api.crossref.org/works/ know what to do with 10/aabbe but are OK with 10.1002/(SICI)1097-0258(19980815/30)17:15/16<1661::AID-SIM968>3.0.CO;2-2 Thus, we wouldn't be able to support short DOIs for Add by Identifier and, in the future, for automatic metadata retrieval/update for existing records.
I'm not against supporting the short format, I'm just trying to figure out how to support it in a way that doesn't cripple the user.
As a note for future reference, we could resolve shortDOIs to DOIs by checking the first redirect when following the shortDOI link. We couldn't do this, of course, if the client is offline.
Thus, we wouldn't be able to support short DOIs for Add by Identifier and, in the future, for automatic metadata retrieval/update for existing records.
hmm, hadn't considered that. That's more of a problem.
For the clicking issue, shouldn't the short DOI be stored as "10/aabe" anyway (not "shortdoi.org/10/aabe"?
of course it should (it resolves via doi.org/10/aabe anyway, no need for a separate resolver), but not sure where that helps/hurts?
Just to clarify, my initial concern was just that normal DOIs (such as "10.1002/(SICI)1097-0258(19980815/30)17:15/16<1661::AID-SIM968>3.0.CO;2-2") in the DOI field make the "DOI:" label clickable whereas shortDOIs (such as "10/aabbe") don’t. It would be nice if this functionality could be added (if just to facilitate looking up the normal DOI :-)).
Personally, I find shortDOIs rather attractive, and while I don’t really care which form is in the database, it’d sure be nice to be able to replace all DOIs by shortDOIs when formatting a printed bibliography. Technically, this would not appear to be too difficult (“http://shortdoi.org/10.1002/(SICI)1097-0258(19980815/30)17:15/16<1661::AID-SIM968>3.0.CO;2-2?format=json” returns the shortDOI “10/aabbe”), but the question is, would Zotero want to do this and/or store/cache shortDOIs locally, too? Thoughts?
Yes, that's understood -- aurimas concern is that if we allow for short dois (which I think we should and I believe so does he), we'll want to properly support them and not have other stuff break when users enter short DOIs into the DOI field.
My sense is that at least for the time being, converting to short DOIs on creating a bibliography is add-on territory. Obviously if we do it, it needs to be optional. It also means users need to be online--so there are a fair amount of variables that I don't think would be wise to introduce into mainstream Zotero right now, though if short DOIs become more commonly used, that's certainly something worth reconsidering.
not a big fan, to be honest. Field clutter is a very real concern and we're going to have too many fields already with those definitely needed. If we actually do want to fully support both, we would probably want to go the way aurimas suggests and automate behind the scenes. But as I said, I'd take a wait and see attitude on that.
Upgrade Storage
Ticket created
https://github.com/zotero/zotero/issues/696
This would be a substantial change in Zotero if we're going to consider short DOIs. Not for the DOI label clickability, but, for instance, duplicate detection (short DOIs and long DOIs should be considered duplicates, or at the very least not prevent duplicate detection, which may already be the case). We should probably not discard such DOIs from translators, but I also don't think that this format gives enough confidence to scan for such DOIs on webpages or in PDFs.
We could also consider automatically resolving short DOIs to long DOIs as they are entered into Zotero.
I agree we don't want to scan for short DOIs on webpages.
I'm not against supporting the short format, I'm just trying to figure out how to support it in a way that doesn't cripple the user.
As a note for future reference, we could resolve shortDOIs to DOIs by checking the first redirect when following the shortDOI link. We couldn't do this, of course, if the client is offline.
Both doi.org and crossref.org seem to be actively promoting shortDOIs (http://www.doi.org/resources.html, http://www.crossref.org/02publishers/doi_display_guidelines.html), and the fact that http://www.crossref.org/guestquery/ and https://api.crossref.org/works/ don’t accept shortDOIs is probably just an oversight on their part.
Personally, I find shortDOIs rather attractive, and while I don’t really care which form is in the database, it’d sure be nice to be able to replace all DOIs by shortDOIs when formatting a printed bibliography. Technically, this would not appear to be too difficult (“http://shortdoi.org/10.1002/(SICI)1097-0258(19980815/30)17:15/16<1661::AID-SIM968>3.0.CO;2-2?format=json” returns the shortDOI “10/aabbe”), but the question is, would Zotero want to do this and/or store/cache shortDOIs locally, too? Thoughts?
My sense is that at least for the time being, converting to short DOIs on creating a bibliography is add-on territory. Obviously if we do it, it needs to be optional. It also means users need to be online--so there are a fair amount of variables that I don't think would be wise to introduce into mainstream Zotero right now, though if short DOIs become more commonly used, that's certainly something worth reconsidering.