Assigning DOIs to dictionaries

James Hester jamesrhester at gmail.com
Mon Apr 27 08:14:44 BST 2020


Dear COMCIFS,

In the past we have discussed assigning DOIs to our CIF dictionaries via
the mechanism used by the IUCr for their publications. So far this
discussion has not yielded much fruit.  A DOI is quite useful as it allows
us to refer to other dictionaries via DOIs and URLs that are pretty much
guaranteed to not become outdated and are machine-actionable.

Instead of the IUCr publication mechanism it occurred to me that we might
use an outside service like Zenodo to deposit canonical dictionary
versions. How this would work is as follows:

(1) A new dictionary version would be approved using the current mechanisms
(2) The dictionary would be deposited at Zenodo using a COMCIFS or IUCr
official account and a DOI reserved (ie document is not yet published)
(3) This DOI would be edited into the dictionary if necessary
(4) Further technical editing would be undertaken as needed
(5) The final dictionary is published on the IUCr website and the 'Publish'
button pushed on Zenodo

Ideally the 'author' for Zenodo and citation purposes would be either
'COMCIFS' or 'IUCr'. The authentication password could reside with the
COMCIFS secretary(s). I have chosen Zenodo because it is not affiliated or
funded by a commercial entity and I have some experience publishing there,
but alternative suggestions are welcome.

The minor downsides I see with this scheme are that (1) the DOI would
contain the string 'zenodo', which is sort of against the spirit of the
underlying object being able to move locations (2) a data DOI such as that
delivered by Zenodo points to a 'landing page', not to the object itself.
The resources are instead linked from the landing page; as far as I can
tell these links are predictable (DOI URL + '/files/<filename>').  I'd
prefer an even simpler way to point a program at a DOI and get back the
file I wanted, but I digress.

Thoughts?

James.
-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iucr.org/pipermail/comcifs/attachments/20200427/946420bb/attachment.html>


More information about the comcifs mailing list