Assign DOIs to Fluid publications

[RaoOfPhysics]

The questions to be addressed here are, “Do we need a DOI for a Fluid publication?” and “Why do we need a DOI for a Fluid publication?” (See also #10)

• A DOI is a persistent and recognised identifier, that always resolves to wherever the specified content is hosted on the Web, independent of whether it moves to a different URL etc.
  • More info: https://www.doi.org/the-identifier/resources/faqs/
• There is a commitment from the DOI provider to always keep the metadata about the publication updated (including new URLs).
• A DOI is sometimes used as a proxy for “legitimacy” of a publication, but anyone can register to offer them.
• If persistency is sought, one approach would be to submit Fluid publications to the Internet Archive.
• The notes below are under the assumption that we would seek a DOI for at least those Fluid publications that the Fluid team produces as examples of reproduced research.

Publishing pathways

As discussed with @rolyp, we have three publication pathways/options:

1. Self-hosted content for Fluid team

• This step involves creation of an account with Crossref (⚠️ see https://www.crossref.org/fees/).
• We produce articles using GitHub Actions and host them on GitHub Pages (see What does an ideal Fluid publication look like? #10), for example.
• We treat each of these publications as reports/pre-prints (see record types: https://www.crossref.org/documentation/register-maintain-records/#what-types-of-records-can-be-registered-with-crossref) and then submit them for a DOI. Quoting from Crossref:
  • Preprints and posted content: includes preprints, eprints, working papers, reports, and other types of content that has been posted but not formally published.
  • Reports and working papers: this includes content that is published and likely has an ISSN.
• This is the simplest option from our perspective but doesn’t provide the article author with a DOI by default; one must deposit each record separately and manually.

2. Hosted by existing journal/publisher

• We could build a relationship/partnership (e.g. EDS), if they are interested in having interactive HTML publications, possibly hosted as additional material. i.e., the paper might have a static image on the main article, but it links to a page (hosted by the journal/publisher) where the interactive version is.
• N.B.: Elife also publishes environment/ecology papers. e.g.: https://elifesciences.org/reviewed-preprints/93694/figures, https://elifesciences.org/reviewed-preprints/93656/figures

3. Hosted by a new Fluid journal

• We could set up a new journal for Fluid publications that reproduce previous research (i.e. no novel research outputs, so that we don’t have to peer-review the science). It would work similar to JOSS in that it would not talk about research but about a component of research (in this case, reproduction of previously published visualisations but with new interactivity).
• The ideal way to do this would be to use Open Journal Systems (OJS; see also GitHub repo and Wikipedia entry.
  • With Crossref registration (as above, under №1), you can use the Crossref XML plugin for OJS (see documentation from OJS and Crossref to automate the creation of DOIs.
  • OJS is based on WordPress, but final publications are no made with WordPress. Instead submissions can be in the form of PDF or HTML, for example, and are simply treated as uploads by the system. See, for example, this paper in the test area for OJS, which has both PDF and HTML versions. So, an HTML Fluid publication could be added to the entry. OJS only requires metadata, such as title, authors, keywords, abstract, references etc.
  • OJS also has a review system, but this does not fully address Integrate peer review into computational pipeline #7.

[rolyp]

@RaoOfPhysics Thanks for this. Dropped back to “Planned” for now and we can pick this up later in the year.