shortDOIs should be clickable

nickbart
Normal DOIs are clickable, shortDOIs (http://shortdoi.org/) of the form "10/abcde" are not. Could this be fixed?
  • adamsmith
    clickable where?
  • nickbart
    Info tab of the right column, by clicking on "DOI:".
  • adamsmith
    I see, that shouldn't be too hard.
    Ticket created
    https://github.com/zotero/zotero/issues/696
  • aurimas
    Should short DOIs really be going into the DOI field though? Are they ok to be cited?
  • adamsmith
    they resolve via doi.org, so why shouldn't they be?
  • aurimas
    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.
  • adamsmith
    I find nothing on citing DOIs by anyone and I'm quite sure there's nothing by any of the big players.

    I agree we don't want to scan for short DOIs on webpages.
  • aurimas
    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.
  • bwiernik
    For the clicking issue, shouldn't the short DOI be stored as "10/aabe" anyway (not "shortdoi.org/10/aabe"?
  • adamsmith
    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?
  • bwiernik
    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?
    Ah, I misread what nickbart meant in his original post.
  • nickbart
    edited April 12, 2015
    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 :-)).

    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?
  • adamsmith
    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.
  • bwiernik
    In the fields update, would adding a separate field for short DOIs be reasonable in the event a user wants to store both the original and short forms?
  • adamsmith
    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.

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.

Sign In or Register to comment.