DOI ending with a period, not resolving

I think this is a minor bug, but when a DOI ends with a period in the "DOI" field, it does not resolve correctly.

For instance "10.4140/TCP.n.2019.109." , leads here "" when clicking "DOI" (Go to this item online) in the standalone.

Perhaps the period is trimmed because it's more likely a mistake? Probably not a best practice to have a DOI end with a period?

Thanks, hope this isn't duplicate or insufficient detail.

  • A DOI should not end in a period, so you should remove that from your data. When clicking the button in Zotero, it cleans extra text before or after the DOI, but it doesn’t do that when generating citations.
  • @bwiernik, try the DOI provided. It actually ends in a period. Whether or not it should, the publisher assigned that designation and it works via, but not without the final period. (I haven't seen that before.)
  • @djross3 is right. While it's probably not a great idea, there's nothing illegal about a DOI ending in a period as here.

    Technical: I think Zotero is calling ZU.cleanDOI on the DOI before resolving this, which raises a number of questions:
    1. Should ZU.cleanDOI remove trailing periods in DOIs
    pro: we're likely going to see many cases where periods are incorrectly included in DOIs, especially in URL notation
    con: it's not always correct, see this example
    Assuming ZU.cleanDOI is left unchanged
    2. Should ZU.cleanDOI be called when using add by identifier (it currently does)
    pro: people paste DOIs incorrectly (e.g. as URL, with doi: prefix, etc.) and this fixes that.
    con: The above DOI won't resolve and there's no way to make it resolve

    3. Should Zotero call ZU.cleanDOI when resolving DOIs
    pro: it'll resolve incorrectly entered DOIs
    con: it won't resolve the DOI above

    I'm unsure about 1 and 2, but I think 3 is pretty clear cut: The current behavior is undesirable. People shouldn't have incorrect DOIs in their metadata since they also produce incorrect citations, so Zotero shouldn't expect them, especially not as it breaks other behavior (without any workarounds).
  • edited July 14, 2020
    (And an odd question: in principle, should such a citation, in formats that typically end the whole bibliographic entry with a dot, end in two dots ".." or just one "."? Anyone copying and pasting wouldn't know to copy the dot, and while the double dot might be confusing, at least it would be a visual indicator that something is different.)

    adamsmith, I agree that 3 is intuitively wrong right now.
    For 1, I agree about parsing a URL or formatted bibliography, etc., but if provided directly as metadata by the publisher, maybe don't trim anything, if the translators can make that distinction?
    As for 2, why not try both and then fall back to adding a dot? I guess that would double the number of requests made for any failed lookup, but it's possible. (And assuming that only a dot would be stripped from the end, and no other alternatives. I'm not sure about that! Or, if necessary, remember the original input and revert to that if the trimmed version doesn't work, or instead you could try the original input first and if it resolves, great, if not try trimming-- assuming there's no 'security'/bug-avoiding feature with trimming to strip illegal characters from the input.)
  • This is (unpleasant) news to me. I frequently see DOI strings at the end of a sentence and the sentence concludes with a period. When I copy the DOI I exclude the period. I do not immediately test every DOI to see if it resolves before I copy it into my database record. Is this something that CrossRef and other DOI registries should address with their systems? I find it more than a bit creepy that "10.4140/TCP.n.2019.109." will resolve and "10.4140/TCP.n.2019.109" will not. As a test, I added periods to more-standard DOI numbers and the DOI with added periods do not resolve. This affects me similarly to fingernails on a blackboard.
  • For those interested, here are the two relevant bits of code:
    The code for resolving DOIs from the item pane:
    Would be easy to not clean up or to just clean up anything preceding 10.

    And ZU.cleanDOI
    So it indeed removes final commas and periods
  • I totally thought that the final character needed to be alphanumeric
Sign In or Register to comment.