Change doi to oadoi in CSL

nomarie
edited March 29, 2019
I am trying to tweak a citation style to output oaDOIs rather than simple DOIs. I have changed
text variable="DOI" prefix="https://doi.org/"/
to
text variable="DOI" prefix="https://oadoi.org/"/
in the relevant style. The output in Word shows https://oadoi.org/10.1093/ecco-jcc/jjx002.517 but only links the actual DOI portion, and still links that through doi.org (ie in this example the link from 10.1093/ecco-jcc/jjx002.517 leads to http://doi.org/10.1093/ecco-jcc/jjx002.517). How can I fix this?
  • bwiernik
    The linking behavior is hard coded in the processor. @adamsmith and @fbennett What are your thoughts about adding oadoi.org to the list of prefixes that citeproc-js handles?
  • adamsmith
    Impactstory has retired the oadoi URL and encourages use of the unpaywall API instead (see https://twitter.com/unpaywall_data/status/957384991360667648 )
    So I'm not too keen on adding this. I didn't realize citeproc had a hard-wired hyperlink for the DOI now, though?
  • nomarie
    Open to better ideas on how to get a link to an open version automatically displaying in a bibliography...?
  • fbennett
    Here is the current behavior.
    • If style applies "https://doi.org/" as prefix:
      • If input has "https://doi.org/" at the front, it is passed through and included in the link and the link text
      • If input has no URL prefix, "https://doi.org" is appended, and the consolidated string is passed through and included in the link and the link text
      • If input has another URL prefix, such as "https://oadoi.org/", that is passed through verbatim and included in the link and the link text.
    • If style applies no prefix, or some other prefix:
      • If input has "https://doi.org/" at the front, it is passed through to the link, and stripped in the link text (i.e. only the DOI is shown).
      • If input has no URL prefix at the front, "https://doi.org/" is appended on the link, and the raw value (the DOI only) is used for the link text.
      • If input has some other URL prefix at the front, that is passed through in the link, and included in the link text.
  • adamsmith
    Thanks. So we're seeing this one here:
    If style applies no prefix, or some other prefix [than https://doi.org] (...): If input has no URL prefix at the front, "https://doi.org/" is appended on the link, and the raw value (the DOI only) is used for the link text.
    These rules generally seem great, but this one does produce weird behavior when the prefix has https?://.+, but not doi.org. This is going to be rare, but I could see other cases e.g. where people want to specifically route through the CNKI DOI service. Not sure if those warrant a change or if that's getting too in-the-weeds.

    Does citeproc-js do anything for other URLs generated using a prefix? E.g. when I do <text variable="PMCID" prefix="https://www.ncbi.nlm.nih.gov/pmc/articles/"/> what does it do?
  • fbennett
    The new IDs don't yet receive any wrapper handling, so you would get the prefix on an plain string, with no link. That's ... probably not what is needed.

    On CKNI etc, is the domain of a DOI implicit in the number? If so, we could do something with that. Otherwise, forcing a single domain on everything is a risky heuristic. Splintering standards are a real headache. Bah, humbug.

    Happy for guidance on what IDs to add to the family and other tweaks!
  • fbennett
    If there are still issues with this, I can look into it if test items that illustrate the problems are available. To submit an item, join the public Jurism Test Submission group, sync, create a collection named for the style that shows the error, drop the item into it, and sync again.
  • adamsmith
    I don't think there's any need to change the current behavior, no.

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.