Research and Data Objects

FAIR Principles

The FAIR Guiding Principles are suggestions for improving data reusability. Also reproducibility and transparency. Here the essence of it is described.

The idea

The paper states:

[good data management] is the key conduit leading to knowledge discovery and innovation.

We can imagine science as an activity of "solving the puzzle of knowledge together". Theories, observations, workflows, processing pipelines and algorithms, software and other data are the puzzle pieces. If the piece is (each term only briefly summarised, oversimplified):

• Findable: there is some place to query for it,
• Accessible: the object is explorable, downloadable,
• Interoperable: uses a common format rather than private,
• Reusable: contains permissive usage policies / license such that it can be reused in future research.

Benefits

Sharing data objects has many benefits:

• Researchers would earn citations through publishing data-objects.
• Software developers can also get recognition for their published data-objects;
• Peer-researchers can then test and reuse the results, while enhancing data-mining and have other areas.

And so forth.

For humans and machines

Different from other frameworks, FAIR is concerned about how non-human agents and tools would discover, retrieve and be able to use the data.

Sharing and finding data objects

Common repositories used for scientific objects are of two kinds:

• Special-purpose: World Wide Protein Data Bank (wwPDB), NOMAD and Materials Cloud (for materials)
• General-purpose: FigShare, Zenodo (CERN), GitHub.

Important

GitHub does not produce DOIs nor guarantees that the item is preserved (it can easily be deleted).

Tip

1. It's important to either inspect or create (for each case above) labels, description, license and other metadata.

2. There is a registry of research data repositories—re3data which is a useful starting point for finding not datasets or software, but a repository (and metadata such as where it's located, who controls it and so forth)

Citing Objects

The recommended practice is to link a dynamic DOI (that tracks versions), especially for software or datasets.

Zenodo handily combines a concept and version DOIs, mapping to the software project and version, respectively.

There are two issues, one on each side of the citation problem:

1. Developers are burdened to update the DOI's version, say in the README.
2. Researchers cite a paper DOI rather than dataset / software appears, or simply name the software.

To solve 1. a 2019 paper analysing citations of Zenodo objects suggests:

[recommended identifier] ideally represents the whole software project, which is less prone to impermanence. This recommendation does not require maintenance effort on the developer (...)

This is not the "recommended practice" of citing the version as well, but it is a first step. The next step would be to use and update the software DOI version.

Thoughts on non-paper citations

A clear limitation is that software dependencies don't get any credits, only the top level.

It seems common to also add a citation file format (file.cff) to GitHub repos which help when linking repository to Zenodo. Then we must add the Zenodo recommended citation choosing version or concept DOI, as described earlier.