DOI

Publishing Tasks: Phase 6 Sustainability + Accessibility

DOI

How to request a Digital Object Identifier (DOI)

The Programming Historian Digital Object Identifier Policy

---

How to request a Digital Object Identifier (DOI)

1. Our Publishing Manager will email [email protected] cc-ing Tim Haillay <[email protected]> and Annette Moore <[email protected]>

   Using the subject line Programming Historian DOI request:

   Dear Sussex Library Cataloging,

   We would like to request a new DOI for a forthcoming article in:

   • [SELECT APPROPRIATE LINE]
   • The Programming Historian (ISSN 2397-2068)
   • The Programming Historian en español (ISSN 2517-5769)
   • The Programming Historian en français (ISSN 2631-9462)
   • The Programming Historian em português (ISSN 2753-9296)

   Sincerely,

   [PUBLISHING MANAGER NAME]

2. Sussex will respond with a DOI string that will look something like 10.46430/phen0089.

3. Add a new YAML header field to the lesson PR and paste in the DOI precisely:

   doi: 10.46430/phen0089
   

When the Pull Request has been merged VERY IMPORTANT:

4. Check the XML has been updated. Wait 5-10 minutes until you are able to load the new lesson at its public URL. The XML is generated and published at the same time, and we need to make sure it's been updated publicly before moving on to the next step.

5. Respond to Sussex's email:

   The article with DOI [NEW DOI HERE] is now published. Please resubmit our publication XML to CrossRef:

   • [PICK APPROPRIATE LANGUAGE LINK]
   • https://programminghistorian.org/en/crossref.xml
   • https://programminghistorian.org/es/crossref.xml
   • https://programminghistorian.org/fr/crossref.xml
   • https://programminghistorian.org/pt/crossref.xml

6. Sussex will reply once the upload has completed.

   • In the unlikely event there are validation errors, they will email you as well as our shared [email protected] account.
   • If they reply that the upload was successful, confirm that the DOI correctly redirects to the published lesson. Then celebrate!

The Programming Historian Digital Object Identifier Policy

1. From May 2020, every article published by the Programming Historian will be assigned (or be in the process of being assigned) a DOI. The assigned DOI will resolve to the published URL at https://programminghistorian.org (e.g. https://programminghistorian.org/fr/lecons/analyse-corpus-antconc)
2. DOIs are unique identifiers for objects, meaning that the content of the object is expected to be largely consistent over time. If we wish to publish a new object that significantly updates the content of the former object, that means creating a new DOI.
3. We determine that not all changes to articles require creating a new document and registering a new DOI. Where changes to an article are requested or suggested, the decision on whether or not to make changes rest with the relevant Managing Editor. The Managing Editor must decide if the changes are 'Minor' or 'Major' (whilst many situations will be unique, examples are provided below for guidance). In most cases 'Major' revisions are discouraged, and we may suggest the article should be retired, and a new article proposed. For 'Minor' changes, edits will be made in the usual way and no new DOI will be requested. For 'Major' changes, Managing Editors will:
   • Make a new copy of the article with a sequentially increasing numerical suffix in the URL (e.g. /en/lessons/how-to-use-sparql-2, /en/lessons/how-to-use-sparql-3, et cetera)
   • If the article has not been copyedited (this will apply to most lessons published before Spring 2020), pass it through the Copyediting Process.
   • When the new version of the article is ready, move the original version of the article to the retired folder (e.g. /en/lessons/how-to-use-sparql to /en/lessons/retired/how-to-use-sparql)
   • Add a note to the retired version that there is a new version.
   • Add a note to the new version that points to the previous version.
   • Contact our DOI provider to notify them of both the new version of the article (so they can register a new DOI) and the revised URL for the previous version of the article.
4. In cases where articles have to be retired, we will contact our DOI provider with the revised URL for the article.

Examples of 'Minor' Changes

• Replacing a broken external link with a link to the Internet Archive version.
• Correcting errors in spelling or of fact.
• Revising formatting.
• Changes to article metadata (e.g. difficulty level).
• Changes to code that are approximately at the same level as correcting a matter of spelling or fact in the text itself.
• Pointing to solutions that will allow users of more recent operating systems to follow an older lesson (see for example this issue).

Examples of 'Major' Changes

• Revisions to the code base of or processes described in an article required as a result of substantial software changes (e.g. Python 2 to Python 3) or new recommended versions.
• Changes to the arrangement or order of an article.
• Replacement of datasets used in an article.

Agreed with our DOI partner - University of Sussex Library - in May 2020