For now, I have been storing DOI values for various items in the Extra field like this: DOI: 10.1037/11019-008
While this won't insert the dois automatically while citing, it does keep them handy for doing final finishing touches on manuscripts.
At some point, I read on the forums that common fields (such as PMID and PMCID) stored in Extra like this might be automatically migrated when fields are updated in the future. I'm not sure whether this will be the case, but again, having the data available will make moving it to the correct field faster.
At some point, I read on the forums that common fields (such as PMID and PMCID) stored in Extra like this might be automatically migrated when fields are updated
this will definitely happen for PMID and PMCID, which are officially supported in Extra (e.g. they're actually extracted for citations). I at least wouldn't rely on it for any other field, though we'll certainly consider it. If you want to keep that possibility alive, you want every ID on a new line starting with the ID label followed by a colon, i.e. exactly the way PMID and PMCID are displayed now. But again, absolutely no guarantee beyond those two.
Very good to hear; I've been editing the Citeproc JSON by hand before sending it on to Pandoc, editing everything other than journal articles to record the DOI properly.
I've been sticking the DOI in as a URL; perhaps this isn't quite as good an approach, since it means losing any other URL. Still, I would imagine that I'm not the only one doing this, and this could be another automated detection process to run upon migration to the upcoming version.
I think DOI is a reasonable candidate for migration and can be quite reliably validated (at least to make sure that it looks like a DOI). I don't think Dan would have any issue with us migrating that field from Extra. Would be great to hear a word from him though.
The workaround explained there also works for Zotero: Add a DOI to a Zotero item of the type "book", for instance, by putting the line {:DOI:10.1037/11019-008} somewhere in the "extra" field. It will then beautifully make its way into the citation of the item.
contrary to some of the very old posts above, using DOI: 10.1037/11019-008 is now officially supported and will be picked up by citation styles and be migrated when other items types get DOI fields (which all of them will)
Upgrade Storage
DOI: 10.1037/11019-008
While this won't insert the dois automatically while citing, it does keep them handy for doing final finishing touches on manuscripts.
At some point, I read on the forums that common fields (such as PMID and PMCID) stored in Extra like this might be automatically migrated when fields are updated in the future. I'm not sure whether this will be the case, but again, having the data available will make moving it to the correct field faster.
If you want to keep that possibility alive, you want every ID on a new line starting with the ID label followed by a colon, i.e. exactly the way PMID and PMCID are displayed now. But again, absolutely no guarantee beyond those two.
I've been sticking the DOI in as a URL; perhaps this isn't quite as good an approach, since it means losing any other URL. Still, I would imagine that I'm not the only one doing this, and this could be another automated detection process to run upon migration to the upcoming version.
The workaround explained there also works for Zotero: Add a DOI to a Zotero item of the type "book", for instance, by putting the line
{:DOI:10.1037/11019-008}
somewhere in the "extra" field. It will then beautifully make its way into the citation of the item.
DOI: 10.1037/11019-008is now officially supported and will be picked up by citation styles and be migrated when other items types get DOI fields (which all of them will)