Exact steps: Insert ZWS at the end of a first name field, leave that field, wait a few seconds, return to the field, copy the field’s content, paste into some editor with “show invisibles” enabled – the ZWS is gone.
Reason for using ZWS: citeprocs remove spaces after particles ending with an apostrophe. One name where this must not happen is “Lorenzo de’ Medici”, and entering this as [Medici][Lorenzo de’<ZWS>] has been working well so far.
I mentioned this (the problem and the ZWS hack) during the lengthy discussion on citeproc-js’s particle parser a while back that led to its current implementation, but it’s, admittedly, a very rare case, so it seems it was never taken care of in citeproc-js.
Unchecking "Get ShortDOI for new items" works correctly in the version 1.2.1 works. Thanks.
I found one "interesting" behaviour. If I change the short DOI to long DOI by the function of this plugin, then the long DOI is capitalized (for example 10.1021/ACS.EST.7B05125). Maybe it is not important but I will be rather to use small letters in the DOI.
In this case, the DOI downloaded by connector from journal web page is not capitalized. But you are right, it is not so important if the API sends back the capitalized DOI.
For idiots like me looking to convert shortDOIs to longDOIs, follow these steps: 1) select the references you want to change 2) right click them 3) Select: Manage DOIs 4) Select: Get long DOIs
@bwiernik A suggestion. Many chapters and books now also have DOI numbers. Could you consider allowing this plugin also process DOI strings in the Extra field when they are preceded by DOI: token?
Great tool and a very interesting discussion in this thread.
I wonder if there is a reason why the examples at shortdoi.org provide a short DOI handle as '10/aabbe', but the corresponding short HTTP URI as https://doi.org/aabbe. Both https://doi.org/aabbe and https://doi.org/10/aabbe resolve correctly to the original DOI and the website of the paper. But, why are there two versions?
Also, I find the example of in-text citations using short DOIs in Nature's COVID research updates interesting, e.g., "E. J. Anderson et al. N. Engl. J. Med. https://doi.org/fbxj; 2020." Could be very useful for short references on slides -- 'doi.org/fbxj' would be sufficient. If 'doi:' would get established in browsers as a protocol like 'http:', as originally expected, the short DOI link could be reduced to 'doi:fbxj'.
The 10/ is optional in the URL, but storing the shortDOI with it makes it clearer this is a shortDOI and not just some random string of characters.
You should not use shortDOIs in published papers—always use the full DOI there. Only use shortDOIs for things like slide presentations or social media posts.
I thought APA style, as an example, allows shortDOIs as optional--not suggested but allowed: "Section 9.36: When a DOI or URL is long or complex, you may use shortDOIs or shortened URLs if desired. Use the shortDOI service provided by the International DOI Foundation (http://shortdoi.org/) to create shortDOIs." source: Shortened URLs in APA Style references https://apastyle.apa.org/blog/shortened-urls
The APA manual suggests that URL shorteners or shortDOIs are okay. This is a terrible idea, and APA has been strongly criticized for it by folks who work in archiving the scholarly literature.
The shortDOI service, while still around, does not have much support from the DOI Foundation and I would not be surprised if it were discontinued. Using shortDOIs in print makes it much harder for citation indexers and other services to track items. Most publishers’ typesetting systems do not recognize shortDOIs as DOIs and will not format them correctly.
Commercial generic URL shorteners are even worse. Even if new shortDOIs are discontinued, we can be reasonably sure that existing ones will continue to resolve. That’s not the case with commercial URL shorteners. There is no guarantee that they will continue to work, potentially leaving readers with an opaque and broken URL in your references section.
I strongly recommend citing items using their actual DOI and full URLs.
I agree with your arguments in favor of long DOIs. But, there is a major technical difference between shortDOIs and shortURLs: shortDOIs are handled by the same centralized resolution service we use for long DOIs. This not the case for URL shortening services besides that the content of URLs cannot be considered permanent unless it is a reliable archive. So, there is persistent support for the resolution of existing shortDOIs. But, limited technical support by typesetting and tracking systems is a real problem, I agree.
But also, members of the DOI Foundation have inducted that they don’t like shortDOIs. It was a summer project that has caused various problems since it was implemented (like the ones I mentioned). ShortDOI won’t have persistence problems like other URL shorteners, but they aren’t DOIs, and they aren’t well-regarded by the DOI ecosystem, so you should limit their use within scholarly records.
Thank you for sharing your very interesting insights.
Investigating the DOI system a little further, I found out that the DOI is part of the Handle System (https://en.wikipedia.org/wiki/Handle_System) conceptually related to persistent uniform resource locators (https://en.wikipedia.org/wiki/Persistent_uniform_resource_locator). The '10' at the beginning of DOIs is the top-level prefix for DOI handles within the Handle System directing the handle resolution including shortDOIs. For example, the shortDOI '10/aabbe' is properly resolved by the handle system (https://hdl.handle.net/10/aabbe). In contrast, the 'aabbe' without the '10/' works for the DOI resolver (https://doi.org/aabbe) but not for the handle system (https://hdl.handle.net/aabbe) because the resolver cannot identify it as a DOI handle.
Related to our discussion about short URLs, I found out that there is a website archiving service creating short URLs as permanent handles pointing to the saved snapshot of a website, e.g., https://perma.cc/48VC-ZS62. It has the limitation that it is a paid service with a price of $0.25-1.50 per link or monthly subscriptions besides other account types. But, perma.cc is backed by many libraries, institutions, and law journals so that it seems it will last. I think perma.cc is an example of an archive and resolver service that addresses the two fundamental problems of short URLs we discussed earlier: reliability of the handle resolver and archiving a snapshot of a website for referencing/citations.
Are you sure about this? I've never heard anything of the kind and I've also never seen any performance issues at perma.cc (That said, web archives are not the same as PIDs: DOIs get you much more than just stability. The, increasingly realized, vision is of an interlinking graph of PIDs that create something akin to the vision of the semantic web.)
Are you sure you're not confusing this with WebCite, for which this has indeed been the case?
Perma.cc got a 700k grant in 2016 and we've been steadily adding URLs since about then with no warnings, outages, or issues (on the contrary, the perma.cc API is incredibly fast & reliable in my experience)
No question that the proper solution for citing websites and linking knowledge would be a distributed archiving and handle system hosted by an international organization or network committed to preserving data like libraries for books. The combination of archiving snapshots and creating persistent identifiers (PIDs) as handles for these snapshots like the perma.cc system allows for interlinking PIDs too. I don't see a fundamental difference in comparison to DOIs as long as both systems provide persistent handles and archived content. Regarding perma.cc, I reviewed the current status and found two relevant points: 1) all archived links have copies on archive.org using the same ID, e.g., the entry https://perma.cc/48VC-ZS62 corresponds to the backup https://archive.org/details/perma_cc_48VC-ZS62 as described in the Perma.cc Contingency Plan https://perma.cc/contingency-plan, and 2) the available stats show a substantial steady growth since 2013 with currently about 2 Mio. archived links/snapshots and corresponding PIDs.
Enabling the DOI Manager plugin in the Get Long DOIs mode causes the DOI to be changed from the valid 10.1110/ps.04682504 to an invalid 20100924123821341 on this Pubmed entry: https://pubmed.ncbi.nlm.nih.gov/15340161/
Otherwise the Pubmed translator saves correct DOI. There is also no problem if DOI Manager is set to "Verify DOIs only".
Any idea what is going on? Using 5.0.97-beta.29+2fd46157f with the Firefox connector 5.0.86.
Upgrade Storage
Reason for using ZWS: citeprocs remove spaces after particles ending with an apostrophe. One name where this must not happen is “Lorenzo de’ Medici”, and entering this as [Medici][Lorenzo de’<ZWS>] has been working well so far.
I mentioned this (the problem and the ZWS hack) during the lengthy discussion on citeproc-js’s particle parser a while back that led to its current implementation, but it’s, admittedly, a very rare case, so it seems it was never taken care of in citeproc-js.
@fbennett Could citeproc-js be adapted to accommodate this edge case?
I found one "interesting" behaviour. If I change the short DOI to long DOI by the function of this plugin, then the long DOI is capitalized (for example 10.1021/ACS.EST.7B05125). Maybe it is not important but I will be rather to use small letters in the DOI.
1) select the references you want to change
2) right click them
3) Select: Manage DOIs
4) Select: Get long DOIs
I love this plug in. Thanks!
I wonder if there is a reason why the examples at shortdoi.org provide a short DOI handle as '10/aabbe', but the corresponding short HTTP URI as https://doi.org/aabbe. Both https://doi.org/aabbe and https://doi.org/10/aabbe resolve correctly to the original DOI and the website of the paper. But, why are there two versions?
Also, I find the example of in-text citations using short DOIs in Nature's COVID research updates interesting, e.g., "E. J. Anderson et al. N. Engl. J. Med. https://doi.org/fbxj; 2020." Could be very useful for short references on slides -- 'doi.org/fbxj' would be sufficient. If 'doi:' would get established in browsers as a protocol like 'http:', as originally expected, the short DOI link could be reduced to 'doi:fbxj'.
You should not use shortDOIs in published papers—always use the full DOI there. Only use shortDOIs for things like slide presentations or social media posts.
The shortDOI service, while still around, does not have much support from the DOI Foundation and I would not be surprised if it were discontinued. Using shortDOIs in print makes it much harder for citation indexers and other services to track items. Most publishers’ typesetting systems do not recognize shortDOIs as DOIs and will not format them correctly.
Commercial generic URL shorteners are even worse. Even if new shortDOIs are discontinued, we can be reasonably sure that existing ones will continue to resolve. That’s not the case with commercial URL shorteners. There is no guarantee that they will continue to work, potentially leaving readers with an opaque and broken URL in your references section.
I strongly recommend citing items using their actual DOI and full URLs.
Investigating the DOI system a little further, I found out that the DOI is part of the Handle System (https://en.wikipedia.org/wiki/Handle_System) conceptually related to persistent uniform resource locators (https://en.wikipedia.org/wiki/Persistent_uniform_resource_locator). The '10' at the beginning of DOIs is the top-level prefix for DOI handles within the Handle System directing the handle resolution including shortDOIs. For example, the shortDOI '10/aabbe' is properly resolved by the handle system (https://hdl.handle.net/10/aabbe). In contrast, the 'aabbe' without the '10/' works for the DOI resolver (https://doi.org/aabbe) but not for the handle system (https://hdl.handle.net/aabbe) because the resolver cannot identify it as a DOI handle.
Related to our discussion about short URLs, I found out that there is a website archiving service creating short URLs as permanent handles pointing to the saved snapshot of a website, e.g., https://perma.cc/48VC-ZS62. It has the limitation that it is a paid service with a price of $0.25-1.50 per link or monthly subscriptions besides other account types. But, perma.cc is backed by many libraries, institutions, and law journals so that it seems it will last. I think perma.cc is an example of an archive and resolver service that addresses the two fundamental problems of short URLs we discussed earlier: reliability of the handle resolver and archiving a snapshot of a website for referencing/citations.
Perma.cc got a 700k grant in 2016 and we've been steadily adding URLs since about then with no warnings, outages, or issues (on the contrary, the perma.cc API is incredibly fast & reliable in my experience)
Otherwise the Pubmed translator saves correct DOI. There is also no problem if DOI Manager is set to "Verify DOIs only".
Any idea what is going on? Using 5.0.97-beta.29+2fd46157f with the Firefox connector 5.0.86.