<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>A Taxonomy of Tools and Approaches for FAIRification</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Dario Mangione</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Leonardo Candela</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Donatella Castelli</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo” - Consiglio Nazionale delle Ricerche</institution>
          ,
          <addr-line>Via G. Moruzzi 1, Pisa, 56121</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>The FAIR principles have drawn a lot of attention since their publication in 2016. A broad range of stakeholders is confronting the implementation of these guiding principles in diverse contexts. This paper identifies and discusses the tools and approaches emerging from stakeholders' experiences adopting the FAIR principles in practice. In particular, 225 open access grey literature papers (namely, deliverables, milestones and data management plans) on FAIRification have been scrutinised to infer tools and approaches in use. The wealth of emerging tools (477) has been carefully analysed and organised into a comprehensive map highlighting the significant classes of instruments supporting FAIRification. A critical discussion on this collection of tools and approaches and the FAIRification completes the paper.</p>
      </abstract>
      <kwd-group>
        <kwd>eol&gt;FAIR</kwd>
        <kwd>Survey and overview</kwd>
        <kwd>Systematic literature review</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        FAIR principles [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] have been introduced as an essential guide for data producers and publishers
in implementing good data management supporting manual and automated deposition,
exploration, sharing, and reusing data. In this context, ‘data’ also refers to all scholarly digital research
objects, e.g. algorithms, tools, and workflows leading to a research result, and ‘metadata’ play
a key role. The Digital Library community has a long lasting experience on topics related
to FAIRness, e.g. on metadata quality [2]. The initial FAIR principles have been revamped to
match better the peculiarity of software [3, 4] and computational workflows [ 5]. Applying
these principles to a significant part of the outputs of the research process is meant to ensure
transparency, reproducibility, and reusability.
      </p>
      <p>The need for FAIR data management is widely recognised, and there is a lot of discussion on
the identification of actions required to make it the standard practice in science. Some are already
in place at a diferent level of spreading and practice. For example, many funders demand their
projects to produce data management plans according to these principles. Tools are emerging
that measure the repositories’ ability to comply with these principles, and services publicly
describe their level of fairness as a measure of quality. These concrete activities are based on
their interpretation of the FAIR objectives and principles to a greater or lesser implementation
extent.</p>
      <p>Indeed, FAIR principles have been introduced to guide approaches for improving the
findability, accessibility, interoperability, and reusability of digital resources [6]. A few years after
publishing these principles, due to the growing of meanings associated with them, the need
has emerged to clarify what FAIR is not. In the literature and the diferent presentations on the
subject, it is now explained, for example, that “FAIR is not a standard . . . FAIR is not equal to
RDF, Linked Data, or the Semantic Web . . . FAIR is not just about humans being able to find,
access, reformat and finally reuse data . . . FAIR is not equal to Open . . . FAIR is not a Life Science
hobby” [7]. All in all, communities are called to implement “their own” solution for responding
to the FAIR principles. This degree of freedom has led to a proliferation of approaches and
technologies around the FAIRification process, i.e. the process of making digital resources FAIR.
Although generic workflows governing it have been defined [ 8], there are no supporting means
for communities in identifying suitable technologies and approaches that can be leveraged to
respond to community-specific FAIRification needs.</p>
      <p>This paper introduces and discusses a taxonomy of tools and approaches exploited in concrete
FAIRification activities by analysing a corpus of recently published 225 open access grey
literature (namely, data management plans, deliverables, and milestones), leading to the identification
of 477 tools. The identified tools are diferent and support various FAIRification process phases.
The produced taxonomy is intended to be a tool itself, supporting communities involved in
FAIRification tasks by suggesting common approaches and technologies successfully used by
others and gaps be filled by new ones. The paper also critically discusses the current state of
the art emerging from such a study, identifying steps still needed to spread the FAIR approach.</p>
      <p>The paper is organised as follows. Section 2 describes the methodology underlying this study.
Section 3 classifies and describes the approaches and methods for FAIRification exploited by
diverse projects and initiatives. Section 4 critically discusses the findings emerging from the
investigation. Finally, Section 5 concludes the paper.</p>
    </sec>
    <sec id="sec-2">
      <title>2. Methodology</title>
      <p>A systematic mapping study approach [9] has been exploited to achieve the study’s goals. In
particular, the study is implemented by a structured process where existing literature relevant
to the research topic is identified, categorised, and analysed.</p>
      <p>Like any systematic mapping study, the first step consisted in identifying the literature
of interest. In particular, the study focused on grey literature. FAIRification is a practical
process often documented by Technical Reports, Project Deliverables or Data Management
Plans. Moreover, it was decided to leverage OpenAIRE contents to identify the literature of
interest because FAIRification is a duty of research projects funded by the European Commission
and other funding bodies. These projects are called to make their deliverables available via
OpenAIRE. This decision also allows the collection of software artefacts somehow correlated to
FAIRification processes.</p>
      <p>To identify the literature of interest, we started with the most straightforward query and
searched for the terms ‘FAIR’ and ‘FAIRification’ and focused on publications having type
‘Report’, ‘Project Deliverable’, and ‘Project Milestone’. The term ‘FAIR’ brings in a lot on “false
positive”; thus, we excluded terms like ‘trade’, ‘value’, ‘play’, ‘treatment’, ‘price’, ‘indivisibility’,
‘division’, ‘africa’, ‘tax’, ‘equality’, ‘trial’, ‘admission’, ‘agreement’, ‘payment’. We also restrict
the time range of the results to the period 2016-2021 because FAIR principles were oficially
published in 2016. This process resulted in 487 publications.</p>
      <p>To improve the recall and the precision of the search, we contacted OpenAIRE colleagues
to be provided with the complete list of keywords and subjects accompanying the selected
publications. After revising this list of keywords, we asked for the papers annotated with the
chosen keywords. Compared with the previous ones, the results of this “snowballing” allowed
us to enrich the initial corpus. The number of identified publications becomes 567 plus 389
software entries explicitly annotated with the selected keywords and subjects.
ise 150
d
u
t
Sd 100
e
h
s
i
l
bu 50
P
0
2016
2017
2018
2019
2020
2021</p>
      <p>The resulting corpus of grey literature and software is documented by a file accompanying
this paper [10].</p>
      <p>Not knowing the extent of the references to tools employed for achieving the FAIRness
of resources in the identified corpus, whose dates range from 2021 to 2016, we decided to
conduct the analysis backwards, starting from the documents published in 2021 until obtaining
a significant set of entries that would allow us to build and test a taxonomy of tools.</p>
      <p>The sample on which the taxonomy is based consists of 477 unique elements, further reduced
to 277 items of immediate interest to the analysis. The diference between the number of
items collected and the elements considered valid for the study depended on the willingness to
consider tools usually cited in diferent contexts, as well as the inclusion of elements currently
not accessible, not identifiable by their name or acronym, removed or simply with descriptions
that did not allow us to assess the relevance of their functions concerning the FAIR principles.</p>
    </sec>
    <sec id="sec-3">
      <title>3. Analysis</title>
      <p>The analysis is based on the manual scrutiny of a refined and final corpus consisting of 225
publications published between 2020 and 20211, and 95 software entries, which produced a
list of 477 items among tools and services related to the FAIRification process of (meta)data,
software and workflows.</p>
      <p>
        The entries were initially organised using the self-assessed information characterising the
resources declared by the resource owner, if any. In particular: (i) the tool or service category;
(ii) the reference to the FAIR guiding principle the tool or service responds to by using the
corresponding identifier of the FAIR principle; ( iii) the domain in which the tool or service
is used; (iv) the FAIRness scope of the tool or service, diferentiating among (meta)data [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ],
software [3, 4], and workflows [5].
      </p>
      <p>Because of the heterogeneity of the results obtained, it became necessary to create an
initial classification for normalising the tool/service categories, which became the basis for the
development of the taxonomy. As for the normalisation of the declared domains, the Frascati
framework is used [11] (see Figure 2 for the actual domain distribution of the tools and services
deemed valid for creating the taxonomy).</p>
      <sec id="sec-3-1">
        <title>Social sciences</title>
      </sec>
      <sec id="sec-3-2">
        <title>Natural sciences</title>
      </sec>
      <sec id="sec-3-3">
        <title>Medical and health sciences</title>
      </sec>
      <sec id="sec-3-4">
        <title>Humanities and the arts</title>
      </sec>
      <sec id="sec-3-5">
        <title>Engineering and technology</title>
      </sec>
      <sec id="sec-3-6">
        <title>Agricultural and veterinary sciences</title>
      </sec>
      <sec id="sec-3-7">
        <title>Cross-domain</title>
        <p>0
50
100
150</p>
        <sec id="sec-3-7-1">
          <title>3.1. Initial FAIR principle-based categories</title>
          <p>Each FAIR principle was analysed from the point of view of the class of tools and services
required for its implementation (see Table 1 below). The discussions and clarifications given in
[6] were taken into account.</p>
          <p>Eight of the fifteen FAIR principles (namely, F1, F2, F3, F4, I1, R1.1, R1.2, and R1.3) led us to
create five candidate classes: ( i) GUPRI creation and management service; (ii) Metadata helper;
(iii) Indexing and discovery service; (iv) Licence helper; (v) Converter. To the first five FAIR
principles-driven classes, we added (vi) Assessment tool to include the tools and services used to
assess a resource’s overall FAIRness and, consequently, interesting all FAIR recommendations
1We observed that publications preceding it were mainly referring to either tools already referred by publications
in the corpus or tools no longer existing or superseded by new ones.</p>
        </sec>
      </sec>
      <sec id="sec-3-8">
        <title>FAIR Principle</title>
      </sec>
      <sec id="sec-3-9">
        <title>F1: (Meta) data are assigned globally unique and persistent identifiers</title>
      </sec>
      <sec id="sec-3-10">
        <title>F2: Data are described with rich metadata</title>
      </sec>
      <sec id="sec-3-11">
        <title>F3: Metadata clearly and explicitly include the identifier of the data they describe</title>
      </sec>
      <sec id="sec-3-12">
        <title>F4: (Meta)data are registered or indexed in a searchable resource</title>
      </sec>
      <sec id="sec-3-13">
        <title>A1: (Meta)data are retrievable by their identifier using a standardised communication protocol</title>
      </sec>
      <sec id="sec-3-14">
        <title>A1.1: The protocol is open, free and universally implementable</title>
      </sec>
      <sec id="sec-3-15">
        <title>A1.2: The protocol allows for an authentication and authorisation where necessary</title>
      </sec>
      <sec id="sec-3-16">
        <title>A2: Metadata should be accessible even when the data is no longer available</title>
      </sec>
      <sec id="sec-3-17">
        <title>I1: (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation</title>
      </sec>
      <sec id="sec-3-18">
        <title>I2: (Meta)data use vocabularies that follow the FAIR principles</title>
      </sec>
      <sec id="sec-3-19">
        <title>I3: (Meta)data include qualified references to other (meta)data</title>
      </sec>
      <sec id="sec-3-20">
        <title>R1: (Meta)data are richly described with a plurality of accurate and relevant attributes</title>
      </sec>
      <sec id="sec-3-21">
        <title>R1.1: (Meta)data are released with a clear and accessible data usage licence</title>
      </sec>
      <sec id="sec-3-22">
        <title>R1.2: (Meta)data are associated with detailed provenance</title>
      </sec>
      <sec id="sec-3-23">
        <title>R1.3: (Meta)data meet domain-relevant community standards</title>
        <p>(see Table 2). The following sections present the resulting taxonomy and describe the identified
classes.</p>
        <sec id="sec-3-23-1">
          <title>3.2. Taxonomy of FAIR tools</title>
          <p>By analysing and integrating the 477 tool and service entries obtained through the scrutiny of
the grey literature, we have created a taxonomy of FAIR tools structured in seven main classes:
(i) GUPRI helper; (ii) Metadata helper; (iii) Indexing and discovery service; (iv) Converter; (v)
Licence helper; (vi) Assessment tool; (vii) DMP tool.</p>
          <p>The seventh category, DMP tool, was added at a later stage (i.e. during the analysis of the
collected items) to accommodate the tools that allow the creation of data management plans.
Although debatable, this decision was taken because, despite these tools not directly impact on
the FAIRness of a resource, they nevertheless provide a coherent reference framework for its
management and consequently the possibility of its adherence to the FAIR guidelines.</p>
          <p>The seven main classes are generally disjoined except for Metadata helper and Converter,
since there are tools that fall under the first category that also include a converter function, i.e.
a metadata helper can also be a converter, although this functionality is not its focal role.</p>
          <p>Figure 3 also associates the categories of tools with the FAIR principles they contribute to.
3.2.1. GUPRI helper
Globally unique, persistent and machine-resolvable identifiers (GUPRI) are the primary elements
to be set for both data and metadata being suggested by the F1 principle. Every FAIRness activity
is called to use tools and approaches helping to generate unambiguous identifiers that will
continue to work even when the “asset” target of the FAIRification activity is going to disappear,
thus becoming no longer available. Because of this role, services and technologies for GUPRI
should guarantee the long term availability of the identifiers assigned to the FAIRified assets.
The need to have identifiers with specific characteristics was discussed in previous works
[12, 13, 14]. In particular, these earlier works highlighted how web-based identifiers were with
us well before the FAIR advent and that their core role and eficacy is guaranteed only under
some settings (namely, the sustainability and governance of the specific system).</p>
          <p>This category consists of 33 instances divided between (i) GUPRI creation and management
service (32 entries); and (ii) GUPRI finder (1 entry). The first category includes the providers
ofering GUPRI registration services, with Handle system implementations (e.g. DOI, ePIC,
EUDAT B2HANDLE) and Open Researcher and Contributor ID (ORCID) being the most cited.
The latter consist of the services that ofer a registry providing indexing and search capabilities
for finding a GUPRI-related provider, with PID Services Registry [15] being its only instance.</p>
          <p>The Handle System [16] is a proprietary registry of the Corporation for National Research
Initiatives (CNRI) administered by the DONA Foundation, providing a resolution system upon
which single Handle.Net software instances are built. The DOI System [17], developed and
maintained by the International DOI Foundation, is the most cited implementation of the Handle
system and among GUPRIs in the corpus. It ensures the persistence of the handles through a
federation of registration agencies, among which the most cited in the documents are Crossref
[18] and DataCite [19], mainly via Zenodo.
3.2.2. Metadata helper
While, ontologically speaking, the existence of a GUPRI is enough to assert that something
unique exists and being resolvable it also allows to locate it, metadata enables to find and
identify the associated resource by filtering among similar resources through the accumulation
of characteristics.</p>
          <p>Metadata helpers allow defining the metadata accompanying a resource or altering already
existing ones, both manually or automatically, whether they are embedded or stored as a
separate file. They also allow the identification of possible metadata directly from the resource
to enrich its description, to suggest the appropriate value for a metadata field or check the
conformance of the existing metadata against a standard.</p>
          <p>Based on the 65 tools and services we found in the grey literature and on the functions above,
we distinguish metadata helpers among five subclasses, namely ( i) Metadata editor (38 entries);
(ii) Metadata extractor (6 entries); (iii) Metadata tracker (13 entries); (iv) Metadata validator (7
entries); and (v) Metadata assistant (1 entry).</p>
          <p>Following the FAIR principles order, at the most basic level the metadata editors allow
uncontrolled user input, enabling F2, F3 and R1.2, but they can include functions to enable I1, I3
and/or R1.3 by referring to knowledge representation languages and community standards and
by validating and/or suggesting the input. They can also include functions to convert between
knowledge representation languages, metadata schemas or file formats, thus also pertaining to
the converter category. OpenRefine [ 20], for example, can be seen as a metadata editor, allowing
to simply alter a description template or, by using an RDF (Resource Description Framework)
extension, as a metadata converter since it enables its user to export the structured data to RDF.</p>
          <p>The metadata editor category is quite heterogeneous since it encompasses tools from
spreadsheets template generators (like the SIOS Excel template generator [21] for creating Darwin
Core compliant descriptions) to mapping tools (like the CIDOC CRM-oriented FORTH-ICS
Mapping Memory Manager (3M) [22], which uses the 3M Editor for assisting in the creation
of the mappings, suggesting and validating the user input). Moreover, it is not uncommon for
metadata editors to ofer an integrated validation tool for checking the compliance of the output
to a metadata schema, and generally for metadata helpers to share functions. For these reasons,
the subclasses of the metadata helpers are usually not disjoint; their instances are classified on
a prime function basis.</p>
          <p>Metadata extractor encompasses the tools that enable parsing, identification and extraction of
metadata, ranging from general-purpose extractors like Apache Tika [23] to metadata specific
ones, like Nanopub JupyterLab Extension [24], which helps to extract Nanopublications from a
python notebook.</p>
          <p>The metadata tracker category is strictly linked with the R1.2 principle since it consists of tools
that allow metadata collection in concomitance with the data workflow, including information
on data acquisition, generation and processing. While the functionalities of these tools may
vary, all of them share the capability of enabling an environment that fosters traceability and
reproducibility at least at some point during the data lifecycle. The category includes nbcomet
[25], which is a Jupyter notebook extension that regularly saves snapshots and logs every
action performed in the notebook, but also workflow managers like Taverna [ 26] and data
management systems like openBIS (open Biology Information System) [27], that automates
(meta)data ingestion while providing data provenance tracking and which is designed to be
integrated with workflow managers.</p>
          <p>Metadata validators check the conformance of a resource to a metadata standard, contributing
to the enablement of the I1 and R1.3 principles. This category encompasses single-standard
oriented validators, for instance (a) the METS Validator [28] provided by the Finnish Digital
Preservation Service for Research Data, that checks a METS file against the national digital
preservation specification, or ( b) the CF (Climate and Forecasts) Checker [29], that validates a
netCDF file against the CF metadata conventions, and multi-format checkers like OCTOPUS
[30], which validates against the SeaDataNet ODV, netCDF and MedAtlas standards. The latter
is also an example of a multifunctional tool, combining a validator, a converter from and to
SeaDataNet standards, an editor for splitting a SeaDataNet file and an extractor.</p>
          <p>
            The last subclass of the metadata helper category is metadata assistant. This category
includes tools that help insert metadata based on controlled vocabularies, contributing to the
standardisation of the descriptions produced and, consequently, the fulfilment of the R1.3
principle. While some metadata editors include an auto-completion feature, the only instance
found in the examined literature that is dedicated to this task is CEDAR OnDemand [31], a
browser extension that helps standardise repository descriptions by recognising the input fields
and suggesting the relevant terms from NCBO (National Center for Biomedical Ontology)
BioPortal vocabularies.
3.2.3. Indexing and discovery service
The Indexing and Discovery service category is by far the most populated category in the
taxonomy, consisting of 123 entries distributed in three subclasses; (i) Registry (54 entries); (ii)
Repository (67 entries); and (iii) Indexing and discovery service finder (4 entries). It includes all
services and tools used for indexing metadata, for discovering the related resources, ultimately
enabling the F4 principle and covering the whole accessibility, as well as those that allow the
indexing and discovery of the services themselves (e.g. re3data [
            <xref ref-type="bibr" rid="ref2">32</xref>
            ] enabling data repositories
discovery). These tools are characterised by the modalities of access to the resources they
provide and the type of resources managed.
          </p>
          <p>
            By modality of access, it is possible to distinguish between repositories (e.g. Zenodo [
            <xref ref-type="bibr" rid="ref3">33</xref>
            ]
or FigShare [
            <xref ref-type="bibr" rid="ref4">34</xref>
            ]), which store, index and allow the discovery of resources, and registries (e.g.
BARTOC.org [
            <xref ref-type="bibr" rid="ref5">35</xref>
            ] or bio.tools [
            <xref ref-type="bibr" rid="ref6">36</xref>
            ]), which index metadata and allow the discovery of resources
from diferent repositories. Registries do not store resources on their own rather, they refer
to the specific repositories for access and ultimately constitute a catalogue consisting of the
metadata describing the resources.
          </p>
          <p>
            The distinction between repositories and registries become blurred when referring to semantic
artefacts [
            <xref ref-type="bibr" rid="ref7">37</xref>
            ]. In this case, the metadata registry and metadata repository categories tend to
overlap since metadata schemas can be stored in a database by registering the element sets and
their constituting elements. Still, it was adopted as a distinguishing characteristic of a semantic
artefact repository the access to single elements of a semantic artefact. Based on this distinction,
the above-mentioned BARTOC.org (Basic Register of Thesauri, Ontologies &amp; Classifications) is
considered a registry for semantic artefacts. At the same time, the NERC Vocabulary Server
(NVS) [
            <xref ref-type="bibr" rid="ref8">38</xref>
            ] is categorised as a semantic artefact repository.
          </p>
          <p>
            The analysis showed that there are four types of resources managed by indexing and discovery
services, namely (i) data, (ii) semantic artefacts, defined as “machine-actionable and -readable
formalisation of a conceptualisation, enabling sharing and reuse by humans and machines”
[
            <xref ref-type="bibr" rid="ref7">37</xref>
            ] (e.g. thesauri, ontologies), (iii) software, and (iv) workflows . It is possible to specialise the
repository and registry classes further to highlight the types of resources they focus on, although
catch-all ones exist. WorkflowHub [
            <xref ref-type="bibr" rid="ref9">39</xref>
            ] is an example of a registry dedicated to computational
workflows, while GitHub [
            <xref ref-type="bibr" rid="ref10">40</xref>
            ] is a representative case of a software repository.
          </p>
          <p>
            Zenodo is, without any doubt, the most cited repository solution in the corpus. It is an
example of a catch-all repository accepting all of the mentioned types of resources. By assigning
a DOI to every registered resource, it is also used as a FAIRifying solution in combination with
other services like GitHub, which does not reserve a GUPRI for the deposited code, or ARGOS
[
            <xref ref-type="bibr" rid="ref11">41</xref>
            ], that uses Zenodo for publishing DMPs.
3.2.4. Converter
The converter category includes the tools and services that convert data or metadata between
models and formats, enabling the transition to community-adopted standards and the
combination of resources across diferent domains and organisations. This class of tools is linked to the
I1 and R1.3 principles.
          </p>
          <p>It consists of 39 tools that, following the distinction between (meta)data formats and data
models, are arranged in two subclasses: (i) data converter (26 entries), transforming data between
ifle formats, enabling R1.3, and ( ii) metadata converter (13 entries), that enables I1 and/or R1.3
principles by allowing the transformation to and between knowledge representation languages.</p>
          <p>
            Elements of the first subclass are ImageMagick, which among its functions allows converting
images from and to a multitude of formats, and Tabula [
            <xref ref-type="bibr" rid="ref12">42</xref>
            ], which transforms data rows in a
textual PDF file into a CSV.
          </p>
          <p>
            Examples of the second subclass are OpenRefine and the similar excel2rdf [
            <xref ref-type="bibr" rid="ref13">43</xref>
            ]. The latter
tool allows the conversion of an Excel-based vocabulary to a SKOS RDF one, and between
metadata formats, like CMD2DC [
            <xref ref-type="bibr" rid="ref14">44</xref>
            ], which transforms the CMD resource descriptions used
by the CLARIN’s Component Metadata Infrastructure (CMDI) to Dublin Core.
3.2.5. Licence helper
This category, consisting of 4 entries, includes the tools that help choose a licence for a resource
by answering a questionnaire, , facilitating the R1.1 principle. The questionnaire can be more or
less detailed, depending on the number of licences taken into consideration, including the type
of resource, actual ownership, identification, use and distribution requirements, and providing
in some instances the possibility to obtain a machine-readable version of it. For example, the
Creative Commons’ License Chooser [
            <xref ref-type="bibr" rid="ref15">45</xref>
            ] lets users select the most appropriate licence among
the six Creative Commons licence types. In contrast, the EUDAT B2SHARE license selector
[46] allows users to choose among twenty-two diferent licences, also distinguishing between
software and data-oriented licences. Both produce a machine-readable version of the chosen
licence, the first in XMP format, the latter in JSON.
3.2.6. Assessment tool
The assessment of the FAIRness of a resource is not strictly a FAIRifying function per se. It does
not contribute to implementing any of the fifteen guiding lines. However, assessment tools
allow the uptake of the FAIR principles by validating the overall conformity of a resource to a
set of criteria or metrics.
          </p>
          <p>Based on the clarity, granularity and measurability of the implemented metrics, and ultimately
on their machine-actionability, the evaluation process can be automated or manual. In both
cases, it consists in following a questionnaire-like approach. For automated tools, the objectivity
of the evaluation criteria allows efective feedback on the resource FAIRness. For manual tools,
being a self-assessment, it is more a matter of encouraging the data curators’ awareness of the
FAIR principles.</p>
          <p>Tools and services in this category are consequently cross-principles and specialised into (i)
Automated assessment tool (4 entries), when the machine-accessible metadata of the resource
is automatically compared with predefined metrics following the submission of the GUPRIs
identifying the resources; (ii) Manual assessment tool (7 entries), if the FAIRness score of a
resource is based on manually filling in a questionnaire; and ( ( iii) Assessment tool finder (1
entry), encompassing the services dedicated to the discovery of assessment tools.</p>
          <p>F-UJI and FAIR-Aware [47] respectively exemplify well the first two categories. Developed
by FAIRsFAIR and based on fifteen core metrics that, being aligned with the FAIR principles
and the CoreTrustSeal requirements, systematically measure the extent to which research data
objects are FAIR. F-UJI is an automated assessment tool that evaluates the FAIRness of datasets
against the FAIRsFAIR Data Object Assessment Metrics, according to the aggregated resource
metadata, through GUPRI creation and management services and repository indexing and
discovery services. FAIR-Aware helps researchers understand how to increase the FAIRness of
a dataset before depositing it in a repository by a ten-step questionnaire.</p>
          <p>Finally, the assessment tool finder category encompasses the indexing and discovery services
dedicated to the FAIR assessment tool, with FAIRassist [48] (developed as a component of
FAIRsharing [49]) as the only FAIR assessment tool registry found in the examined corpus.
3.2.7. DMP tool
As previously mentioned, the inclusion in the presented taxonomy of a DMP tool category
may be questionable since its services do not act directly on the resources. However, we
decided to incorporate it because, by creating a reference for the resource lifecycle management,
establishing how the resources have to be stored, curated, shared and preserved, these tools
afect the FAIRness of a resource, particularly its reusability [50, 51].</p>
          <p>This class includes eight services that noticeably share the same main function of
providing step-by-step guidance in creating a data management plan by filling in annotated forms.
Still, they may vary appreciably in additional functions, for instance by supporting machine
actionability, allowing to simultaneously collaborate to the realisation of the DMP, ofering
customisable templates or providing a platform to share them. For example, the ARGOS tool
developed by OpenAIRE and based on OpenDMP allows the collaborative creation of a
machineactionable DMP by supporting its versioning, the assignment of a licence and a DOI (through
Zenodo) and its publishing.</p>
          <p>They can also vary in domain coverage like the ARIADNEplus DMP Researcher Template for
Archaeological Datasets that is manifestly domain-specific.</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>4. Discussion</title>
      <p>The analysis conducted in this study highlights how FAIRness approaches are envisaged and
implemented in recent projects and initiatives. Although it is not possible to claim that the
conducted research is exhaustive of the topic of FAIRness, the implemented methodology
guarantees high coverage concerning FAIRness initiatives and related tools.</p>
      <p>The problem addressed by the study is intrinsically complex because interpretations of FAIR
principles and solutions often depend on settings characterising the application context.</p>
      <p>A deeper analysis would need to complement the knowledge obtained from the selected
documents with details collected “in the field” on how the various communities have practically
decided to organise themselves to implement the FAIR principles.</p>
      <p>The “interpretability” of the FAIR principles [6] introduces vagueness making it challenging
to compare diverse experiences and uses of the tools.</p>
      <p>The continuous evolution represents another element to be taken into account. Communities’
plans and approaches might be rethought to meet better FAIR principles and expectations
resulting from early attempts to make data (more generally, resources) FAIR and to exploit
released data. As a consequence of these evolutions, new tools may emerge.</p>
      <p>The nature and heterogeneity of the examined material made it possible to observe trends
that would otherwise be dificult to appreciate.</p>
      <p>There is a tendency to include concepts that are not strictly pertinent to the FAIR principles,
although related. For example, accessibility often overlaps with open accessibility, a concept
related to open access that does not find a direct acknowledgement in the FAIRness since FAIR
data does not mean open data [7]. Open accessibility is linked more to the licences associated
with the resources, hence to reusability, than to accessibility itself, which is defined without
mentioning open access. Similarly, it is likely to see the concept of reusability intuitively
associated with preservation, pursued by depositing the resources into a repository, even if the
latter is not mentioned in the definition of reuse given by the principles.</p>
      <p>Privileging certain elements of FAIRness over others is another clear trend. For instance, in
the case of reuse point R1.1, and therefore the aspect related to the licence, it is mentioned while
neglecting the others.</p>
      <p>It is also possible to see unexpected tools mentioned in a FAIRness context, e.g. tools linked to
collaboration or dissemination, including content management systems, wikis, infrastructures
and journals.</p>
      <p>By not specifying implementations, the fifteen points in which the guidelines are articulated
remain substantially open to interpretation [52] from which this study is no exception. The
categories in which the taxonomy is structured result from an analysis of the FAIR principles,
which led us to create an equivalence relation between the tool functions and the fifteen
guidelines.</p>
      <p>While the F2 principle states that the concept of rich metadata is defined in R1, thus creating
a direct link between findability and reusability, our interpretation of the F2 principle limits the
“rich metadata” only to those that allow to find a resource and to distinguish it from similar ones.
In fact, it is arguable that metadata enabling findability should be a subset of those contributing
to the reusability of a resource and as such the minimum requirements for its description, that
should be defined on a community basis. This view is based on a vision of the FAIR principles
as incremental tasks mainly build upon the metadata associated with the resources. Therefore,
the F2-related tools and services are not always associated also with reusability.</p>
      <p>Similarly, the distinction between tools enabling I1 and those that foster R1.3 is founded
on the diference between knowledge representation languages, including their serialisations,
and metadata formats. Following this rationale, a tool enabling machine-actionability, without
specifying the metadata standard used, is considered just I1-related.</p>
      <p>Moreover, some principles are just cited as a general reference, as in the case of accessibility,
or are not associated with any tool, such as I2. That is because accessibility depends directly on
F1 and on the protocols and policies implemented by registries and repositories rather than a
category of tools, while I2 introduces a recursive element among the principles without creating
the need for additional categories.</p>
      <p>An interesting point highlighted by this study, albeit not unexpected given the number of
diferent implementation contexts and the inherent complexity of the matter, is the lack of
unique solutions for ensuring the FAIRness of resources. Even the most integrated solutions
found in the corpus (for example, Fairdata.fi [ 53], which is a nationwide solution promoted
by the Finnish Ministry of Education and Culture providing services for storing, describing,
indexing, searching and publishing research data) can not cover all of the specific needs arising
from the diferent resource types and scientific workflows.</p>
      <p>The need to support the sharing of FAIRness implementation experiences and solutions is
actual, and concrete approaches are needed, as demonstrated in [52, 54]. The FAIR Convergence
Matrix [52] is a collaborative online resource aiming at creating machine-actionable descriptions
of FAIR implementation choices made by diferent domain communities. The concept of FAIR
Implementation Profile [ 54] aims at capturing by a FAIR object itself the comprehensive set of
implementation choices made at the discretion of individual communities of practice. These
tools are envisaged to be used to track the evolving landscape of FAIR implementations and
inform about them.</p>
    </sec>
    <sec id="sec-5">
      <title>5. Conclusion and Prospects</title>
      <p>Several initiatives are promoting the FAIRification of science assets to improve their findability,
accessibility, interoperability and reusability for both humans and machines. Communities
responsible for these assets are implementing diverse strategies and approaches to respond to
the FAIR guiding principles.</p>
      <p>This paper reported the result of a systematic collection and analysis of the tools developed
and exploited by scientific communities in their FAIRification activities. A taxonomy organising
the various tools into seven major classes is introduced and discussed. This taxonomy is a
helpful instrument for understanding the state of the art regarding FAIRification activities,
supporting communities of practice confronting with FAIRification activities and helping to
develop innovative solutions and strategies improving and filling existing gaps in supporting
FAIRification processes.</p>
      <p>To further develop the taxonomy, it is planned to systematically assess its eficacy in concrete
settings by establishing a dialogue with communities of practice and initiatives engaged in
FAIRness activities and systematically analysing the FAIRness approaches documented by FAIR
Implementation Profiles [54].</p>
    </sec>
    <sec id="sec-6">
      <title>Acknowledgments</title>
      <p>This work has received funding from the European Union’s Horizon 2020 research and
innovation programme under Blue Cloud project (grant agreement No. 862409), DESIRA project (grant
agreement No. 818194), EOSC-Pillar project (grant agreement No. 857650), and
SoBigDataPlusPlus (grant agreement No. 871042).</p>
      <p>Author Contributions According to CRediT taxonomy, authors contributed as follows:
DM performed Methodology, Investigation, Data Curation, Writing - Original Draft, Writing
- Review &amp; Editing, Visualization; LC performed Conceptualization, Methodology, Writing
Review &amp; Editing, Supervision, and Funding acquisition; DC performed Conceptualization,
Writing - Review &amp; Editing, Supervision, and Funding acquisition.
principles for scientific data management and stewardship, Scientific Data 3 (2016) 160018.
doi:10.1038/sdata.2016.18.
[2] A. Tani, L. Candela, D. Castelli, Dealing with metadata quality: The legacy of digital library
eforts, Inf. Process. Manag. 49 (2013) 1194–1205. URL: https://doi.org/10.1016/j.ipm.2013.
05.003. doi:10.1016/j.ipm.2013.05.003.
[3] A.-L. Lamprecht, L. Garcia, M. Kuzak, C. Martinez, R. Arcila, E. Martin Del Pico,
V. Dominguez Del Angel, S. van de Sandt, J. Ison, P. A. Martinez, P. McQuilton, A.
Valencia, J. Harrow, F. Psomopoulos, J. L. Gelpi, N. Chue Hong, C. Goble, S.
CapellaGutierrez, Towards FAIR principles for research software, Data Science 3 (2020) 37–59.
doi:10.3233/DS-190026.
[4] D. S. Katz, M. Gruenpeter, T. Honeyman, Taking a fresh look at FAIR for research software,</p>
      <p>Patterns 2 (2021) 100222. doi:10.1016/j.patter.2021.100222.
[5] C. Goble, S. Cohen-Boulakia, S. Soiland-Reyes, D. Garijo, Y. Gil, M. R. Crusoe, K. Peters,
D. Schober, FAIR Computational Workflows, Data Intelligence 2 (2020) 108–121. doi: 10.
1162/dint_a_00033.
[6] A. Jacobsen, R. de Miranda Azevedo, N. Juty, D. Batista, S. Coles, R. Cornet, M. Courtot,
M. Crosas, M. Dumontier, C. T. Evelo, C. Goble, G. Guizzardi, K. K. Hansen, A. Hasnain,
K. Hettne, J. Heringa, R. W. Hooft, M. Imming, K. G. Jefery, R. Kaliyaperumal, M. G.
Kersloot, C. R. Kirkpatrick, T. Kuhn, I. Labastida, B. Magagna, P. McQuilton, N. Meyers,
A. Montesanti, M. van Reisen, P. Rocca-Serra, R. Pergl, S.-A. Sansone, L. O. B. da Silva Santos,
J. Schneider, G. Strawn, M. Thompson, A. Waagmeester, T. Weigel, M. D. Wilkinson, E. L.
Willighagen, P. Wittenburg, M. Roos, B. Mons, E. Schultes, FAIR Principles: Interpretations
and Implementation Considerations, Data Intelligence 2 (2020) 10–29. doi:10.1162/
dint_r_00024.
[7] B. Mons, C. Neylon, J. Velterop, M. Dumontier, L. O. B. da Silva Santos, M. D. Wilkinson,
Cloudy, increasingly FAIR; revisiting the FAIR data guiding principles for the european open
science cloud, Information Services &amp; Use 37 (2017) 49–56. doi:10.3233/ISU-170824.
[8] A. Jacobsen, R. Kaliyaperumal, L. O. B. da Silva Santos, B. Mons, E. Schultes, M. Roos,
M. Thompson, A Generic Workflow for the Data FAIRification Process, Data Intelligence
2 (2020) 56–65. doi:10.1162/dint_a_00028.
[9] K. Petersen, R. Feldt, S. Mujtaba, M. Mattsson, Systematic mapping studies in software
engineering, in: Proceedings of the 12th International Conference on Evaluation and
Assessment in Software Engineering, EASE’08, BCS Learning &amp; Development Ltd., Swindon,
GBR, 2008, pp. 68–77.
[10] D. Mangione, L. Candela, D. Castelli, A taxonomy of tools and approaches for fairification,
2022. doi:10.5281/zenodo.6037508.
[11] OECD, Frascati Manual 2015, Guidelines for Collecting and Reporting Data on Research
and Experimental Development„ OECD Publishing, 2015. URL: https://www.oecd-ilibrary.
org/content/publication/9789264239012-en. doi:10.1787/9789264239012-en.
[12] J. A. McMurry, N. Juty, N. Blomberg, T. Burdett, T. Conlin, N. Conte, M. Courtot, J. Deck,
M. Dumontier, D. K. Fellows, A. Gonzalez-Beltran, P. Gormanns, J. Grethe, J. Hastings, J.-K.
Hériché, H. Hermjakob, J. C. Ison, R. C. Jimenez, S. Jupp, J. Kunze, C. Laibe, N. Le Novère,
J. Malone, M. J. Martin, J. R. McEntyre, C. Morris, J. Muilu, W. Müller, P. Rocca-Serra,
S.-A. Sansone, M. Sariyar, J. L. Snoep, S. Soiland-Reyes, N. J. Stanford, N. Swainston,
N. Washington, A. R. Williams, S. M. Wimalaratne, L. M. Winfree, K. Wolstencroft, C. Goble,
C. J. Mungall, M. A. Haendel, H. Parkinson, Identifiers for the 21st century: How to design,
provision, and reuse persistent identifiers to maximize utility and impact of life science
data, PLOS Biology 15 (2017) 1–18. URL: https://doi.org/10.1371/journal.pbio.2001414.
doi:10.1371/journal.pbio.2001414.
[13] N. Juty, S. M. Wimalaratne, S. Soiland-Reyes, J. Kunze, C. A. Goble, T. Clark, Unique,
Persistent, Resolvable: Identifiers as the Foundation of FAIR, Data Intelligence 2 (2020)
30–39. URL: https://doi.org/10.1162/dint_a_00025. doi:10.1162/dint_a_00025.
[14] J. Klump, R. Huber, 20 years of persistent identifiers – which systems are here to stay?,</p>
      <p>Data Science Journal 16 (2017). doi:10.5334/dsj-2017-009.
[15] DataCite, 2022, PID services registry, URL: pidservices.org.
[16] Corporation for National Research Initiatives, 2022, Handle.net registry, URL: handle.net.
[17] International DOI Foundation, 2022, The doi system.
[18] G. Hendricks, D. Tkaczyk, J. Lin, P. Feeney, Crossref: The sustainable source of
communityowned scholarly metadata, Quantitative Science Studies 1 (2020) 414–427. doi:10.1162/
qss_a_00022.
[19] J. Brase, Datacite - a global registration agency for research data, in: 2009 Fourth
International Conference on Cooperation and Promotion of Information Resources in
Science and Technology, 2009, pp. 257–261. doi:10.1109/COINFO.2009.66.
[20] R. Verborgh, M. De Wilde, Using OpenRefine, Packt, 2013.
[21] Svalbard Integrated Arctic Earth Observing System, 2022, Nansen legacy excel template
generator, URL: https://sios-svalbard.org/cgi-bin/darwinsheet/index.cgi.
[22] Y. Marketakis, N. Minadakis, H. Kondylakis, K. Konsolaki, G. Samaritakis, M. Theodoridou,
G. Flouris, M. Doerr, X3ML mapping framework for information integration in cultural
heritage and beyond, International Journal on Digital Libraries 18 (2017) 301–319. URL:
https://doi.org/10.1007/s00799-016-0179-1. doi:10.1007/s00799-016-0179-1.
[23] C. A. Mattmann, J. L. Zitting, Tika in Action, Manning, 2011.
[24] R. Richardson, 2021, Nanopubjl, URL: https://github.com/fair-workflows/NanopubJL/tree/
v0.3.0.
[25] A. Rule, 2022, nbcomet, URL: https://github.com/activityhistory/nbcomet.
[26] T. Oinn, M. Addis, J. Ferris, D. Marvin, M. Senger, M. Greenwood, T. Carver, K. Glover,
M. R. Pocock, A. Wipat, P. Li, Taverna: a tool for the composition and enactment of
bioinformatics workflows, Bioinformatics 20 (2004) 3045–3054. URL: https://doi.org/10.
1093/bioinformatics/bth361. doi:10.1093/bioinformatics/bth361.
[27] A. Bauch, I. Adamczyk, P. Buczek, F.-J. Elmer, K. Enimanev, P. Glyzewski, M. Kohler,
T. Pylak, A. Quandt, C. Ramakrishnan, C. Beisel, L. Malmström, R. Aebersold, B. Rinn,
openBIS: a flexible framework for managing and analyzing complex data in biology
research, BMC Bioinformatics 12 (2011) 468. URL: https://doi.org/10.1186/1471-2105-12-468.
doi:10.1186/1471-2105-12-468.
[28] National digital preservation services, 2022, METS Validation Tool, URL: https://www.</p>
      <p>digitalpreservation.fi/en/mets-validator.
[29] R. Hatcher, 2022, Cf checker, URL: https://github.com/cedadev/cf-checker.
[30] SeaDataNet, 2022, OCTOPUS, URL: https://www.seadatanet.org/Software/OCTOPUS.
[31] S. A. C. Bukhari, M. Martínez-Romero, M. J. O’Connor, A. L. Egyedi, D. Willrett, J. Graybeal,
[46] EUDAT, 2022, License selector, URL: https://github.com/ufal/public-license-selector.
[47] A. Devaraju, M. Mokrane, L. Cepinskas, R. Huber, P. Herterich, J. de Vries, V. Akerman,
H. L’Hours, J. Davidson, M. Diepenbroek, From conceptualization to implementation:
FAIR assessment of research data objects, Data Science Journal 20 (2021). doi:10.5334/
dsj-2021-004.
[48] FAIRSharing, 2022, FAIRAssist, URL: fairassist.org.
[49] S.-A. Sansone, P. McQuilton, P. Rocca-Serra, A. Gonzalez-Beltran, M. Izzo, A. L. Lister,
M. Thurston, the FAIRsharing Community, Fairsharing as a community approach to
standards, repositories and policies, Nature Biotechnology 37 (2019) 358–367. doi:10.
1038/s41587-019-0080-8.
[50] N. A. Smale, K. Unsworth, G. Denyer, E. Magatova, D. Barr, A review of the history,
advocacy and eficacy of data management plans, International Journal of Digital Curation
15 (2020). doi:10.2218/ijdc.v15i1.525.
[51] S. Jones, R. Pergl, R. Hooft, T. Miksa, R. Samors, J. Ungvari, R. I. Davis, T. Lee, Data
management planning: How requirements and solutions are beginning to converge, Data
Intelligence 2 (2020). doi:10.1162/dint_a_00043.
[52] H. P. Sustkova, K. M. Hettne, P. Wittenburg, A. Jacobsen, T. Kuhn, R. Pergl, J. Slifka,
P. McQuilton, B. Magagna, S.-A. Sansone, M. Stocker, M. Imming, L. Lannom, M. Musen,
E. Schultes, FAIR Convergence Matrix: Optimizing the Reuse of Existing FAIR-Related
Resources, Data Intelligence 2 (2020) 158–170. doi:10.1162/dint_a_00038.
[53] Ministry of Education and Culture, Finland, 2022, Fairdata services, URL: fairdata.fi.
[54] E. Schultes, B. Magagna, K. M. Hettne, R. Pergl, M. Suchánek, T. Kuhn, Reusable FAIR
implementation profiles as accelerators of FAIR convergence, in: G. Grossmann, S. Ram
(Eds.), Advances in Conceptual Modeling, Springer International Publishing, Cham, 2020,
pp. 138–147. doi:10.1007/978-3-030-65847-2_13.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>M. D.</given-names>
            <surname>Wilkinson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Dumontier</surname>
          </string-name>
          ,
          <string-name>
            <given-names>I. J.</given-names>
            <surname>Aalbersberg</surname>
          </string-name>
          , G. Appleton,
          <string-name>
            <given-names>M.</given-names>
            <surname>Axton</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Baak</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Blomberg</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.-W.</given-names>
            <surname>Boiten</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L. B. da Silva</given-names>
            <surname>Santos</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P. E.</given-names>
            <surname>Bourne</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Bouwman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. J.</given-names>
            <surname>Brookes</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Clark</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Crosas</surname>
          </string-name>
          ,
          <string-name>
            <given-names>I.</given-names>
            <surname>Dillo</surname>
          </string-name>
          ,
          <string-name>
            <given-names>O.</given-names>
            <surname>Dumon</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Edmunds</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C. T.</given-names>
            <surname>Evelo</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Finkers</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>GonzalezBeltran</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. J. G.</given-names>
            <surname>Gray</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Groth</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Goble</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J. S.</given-names>
            <surname>Grethe</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Heringa</surname>
          </string-name>
          , P. A. C. '
          <string-name>
            <surname>t Hoen</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          <string-name>
            <surname>Hooft</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          <string-name>
            <surname>Kuhn</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          <string-name>
            <surname>Kok</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Kok</surname>
            ,
            <given-names>S. J.</given-names>
          </string-name>
          <string-name>
            <surname>Lusher</surname>
            ,
            <given-names>M. E.</given-names>
          </string-name>
          <string-name>
            <surname>Martone</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Mons</surname>
            ,
            <given-names>A. L.</given-names>
          </string-name>
          <string-name>
            <surname>Packer</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          <string-name>
            <surname>Persson</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Rocca-Serra</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>Roos</surname>
            , R. van Schaik,
            <given-names>S.-A.</given-names>
          </string-name>
          <string-name>
            <surname>Sansone</surname>
            , E. Schultes,
            <given-names>T.</given-names>
          </string-name>
          <string-name>
            <surname>Sengstag</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          <string-name>
            <surname>Slater</surname>
            , G. Strawn,
            <given-names>M. A.</given-names>
          </string-name>
          <string-name>
            <surname>Swertz</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>Thompson</surname>
            ,
            <given-names>J. van der</given-names>
          </string-name>
          <string-name>
            <surname>Lei</surname>
            , E. van Mulligen,
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Velterop</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Waagmeester</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Wittenburg</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          <string-name>
            <surname>Wolstencroft</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Zhao</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          <string-name>
            <surname>Mons</surname>
          </string-name>
          ,
          <article-title>The FAIR guiding M. A</article-title>
          .
          <string-name>
            <surname>Musen</surname>
          </string-name>
          ,
          <string-name>
            <surname>K.-H. Cheung</surname>
            ,
            <given-names>S. H.</given-names>
          </string-name>
          <string-name>
            <surname>Kleinstein</surname>
          </string-name>
          , CEDAR OnDemand:
          <article-title>a browser extension to generate ontology-based scientific metadata</article-title>
          ,
          <source>BMC Bioinformatics 19</source>
          (
          <year>2018</year>
          )
          <article-title>268</article-title>
          . URL: https://doi.org/10.1186/s12859-018-2247-6. doi:
          <volume>10</volume>
          .1186/s12859-018-2247-6.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [32]
          <string-name>
            <given-names>H.</given-names>
            <surname>Pampel</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Vierkant</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Scholze</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Bertelmann</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Kindling</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Klump</surname>
          </string-name>
          , H.
          <article-title>-</article-title>
          <string-name>
            <surname>J. Goebelbecker</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Gundlach</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Schirmbacher</surname>
          </string-name>
          , U. Dierolf,
          <article-title>Making research data repositories visible: The re3data</article-title>
          .
          <article-title>org registry</article-title>
          ,
          <source>PLOS ONE 8</source>
          (
          <year>2013</year>
          )
          <fpage>1</fpage>
          -
          <lpage>10</lpage>
          . URL: https://doi.org/10.1371/journal.pone. 0078080. doi:
          <volume>10</volume>
          .1371/journal.pone.
          <volume>0078080</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [33] European Organization For Nuclear Research, OpenAIRE, Zenodo,
          <year>2013</year>
          . URL: https:// www.zenodo.org/. doi:
          <volume>10</volume>
          .25495/7GXK-
          <fpage>RD71</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [34]
          <string-name>
            <given-names>M.</given-names>
            <surname>Hahnel</surname>
          </string-name>
          ,
          <year>2022</year>
          , figshare, URL: figshare.com.
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [35]
          <string-name>
            <given-names>J.</given-names>
            <surname>Waeber</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Ledl</surname>
          </string-name>
          ,
          <article-title>A semantic web skos vocabulary service for open knowledge organization systems</article-title>
          , in: E.
          <string-name>
            <surname>Garoufallou</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          <string-name>
            <surname>Sartori</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          <string-name>
            <surname>Siatri</surname>
          </string-name>
          , M. Zervas (Eds.),
          <source>Metadata and Semantic Research</source>
          , Springer International Publishing, Cham,
          <year>2019</year>
          , pp.
          <fpage>3</fpage>
          -
          <lpage>12</lpage>
          . doi:
          <volume>10</volume>
          .1007/978-3-
          <fpage>030</fpage>
          -14401-
          <issue>2</issue>
          _
          <fpage>1</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [36]
          <string-name>
            <given-names>J.</given-names>
            <surname>Ison</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Rapacki</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Ménager</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Kalaš</surname>
          </string-name>
          , E. Rydza,
          <string-name>
            <given-names>P.</given-names>
            <surname>Chmura</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Anthon</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Beard</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Berka</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Bolser</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Booth</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Bretaudeau</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Brezovsky</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Casadio</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            <surname>Cesareni</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Coppens</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Cornell</surname>
          </string-name>
          , G. Cuccuru,
          <string-name>
            <given-names>K.</given-names>
            <surname>Davidsen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G. D.</given-names>
            <surname>Vedova</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Dogan</surname>
          </string-name>
          ,
          <string-name>
            <given-names>O.</given-names>
            <surname>Doppelt-Azeroual</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Emery</surname>
          </string-name>
          , E. Gasteiger,
          <string-name>
            <given-names>T.</given-names>
            <surname>Gatter</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Goldberg</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Grosjean</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Grüning</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Helmer-Citterich</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Ienasescu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>V.</given-names>
            <surname>Ioannidis</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M. C.</given-names>
            <surname>Jespersen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Jimenez</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Juty</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Juvan</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Koch</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Laibe</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.-W.</given-names>
            <surname>Li</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Licata</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Mareuil</surname>
          </string-name>
          ,
          <string-name>
            <surname>I. Mičetić</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R. M.</given-names>
            <surname>Friborg</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Moretti</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Morris</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Möller</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Nenadic</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Peterson</surname>
          </string-name>
          , G. Profiti,
          <string-name>
            <given-names>P.</given-names>
            <surname>Rice</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Romano</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Roncaglia</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Saidi</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Schafferhans</surname>
          </string-name>
          ,
          <string-name>
            <given-names>V.</given-names>
            <surname>Schwämmle</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Smith</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M. M.</given-names>
            <surname>Sperotto</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Stockinger</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R. S.</given-names>
            <surname>Vařeková</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S. C.</given-names>
            <surname>Tosatto</surname>
          </string-name>
          , V. de la Torre,
          <string-name>
            <given-names>P.</given-names>
            <surname>Uva</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Via</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            <surname>Yachdav</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Zambelli</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            <surname>Vriend</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Rost</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Parkinson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Løngreen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Brunak</surname>
          </string-name>
          ,
          <article-title>Tools and data services registry: a community efort to document bioinformatics resources</article-title>
          ,
          <source>Nucleic Acids Research</source>
          <volume>44</volume>
          (
          <year>2015</year>
          )
          <fpage>D38</fpage>
          -
          <lpage>D47</lpage>
          . URL: https://doi.org/10.1093/nar/gkv1116. doi:
          <volume>10</volume>
          .1093/nar/gkv1116.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [37]
          <string-name>
            <given-names>W.</given-names>
            <surname>Hugo</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Y.</given-names>
            <surname>Le Franc</surname>
          </string-name>
          , G. Coen,
          <string-name>
            <given-names>J.</given-names>
            <surname>Parland-von Essen</surname>
          </string-name>
          , L. Bonino,
          <year>D2</year>
          .5 FAIR
          <string-name>
            <given-names>Semantics</given-names>
            <surname>Recommendations Second Iteration</surname>
          </string-name>
          ,
          <source>Project Deliverable D2</source>
          .5,
          <issue>FAIRsFAIR</issue>
          ,
          <year>2020</year>
          . doi:
          <volume>10</volume>
          . 5281/zenodo.4314320.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [38]
          <string-name>
            <given-names>British</given-names>
            <surname>Oceanographic Data Centre</surname>
          </string-name>
          ,
          <year>2022</year>
          ,
          <article-title>The NERC Vocabulary Server</article-title>
          , URL: https: //vocab.nerc.ac.uk/.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [39]
          <string-name>
            <given-names>R. F.</given-names>
            <surname>d. Silva</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Pottier</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Coleman</surname>
          </string-name>
          , E. Deelman,
          <string-name>
            <given-names>H.</given-names>
            <surname>Casanova</surname>
          </string-name>
          , Workflowhub:
          <article-title>Community framework for enabling scientific workflow research and development</article-title>
          ,
          <source>in: 2020 IEEE/ACM Workflows in Support of Large-Scale Science (WORKS)</source>
          ,
          <year>2020</year>
          , pp.
          <fpage>49</fpage>
          -
          <lpage>56</lpage>
          . doi:
          <volume>10</volume>
          .1109/ WORKS51914.
          <year>2020</year>
          .
          <volume>00012</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [40] github,
          <source>GitHub</source>
          ,
          <year>2022</year>
          . URL: github.com.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [41]
          <string-name>
            <surname>OpenAIRE</surname>
          </string-name>
          ,
          <year>2022</year>
          , Argos, URL: argos.openaire.eu.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [42]
          <string-name>
            <given-names>M.</given-names>
            <surname>Aristarán</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Tigas</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J. B.</given-names>
            <surname>Merrill</surname>
          </string-name>
          ,
          <year>2022</year>
          , Tabula, URL: ManuelAristarán, MikeTigasandJeremyB.Merrill.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [43]
          <string-name>
            <given-names>J.</given-names>
            <surname>Graybeal</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Vasiljevic</surname>
          </string-name>
          ,
          <year>2022</year>
          , excel2rdf-template, URL: https://github.com/ fair
          <article-title>-data-collective/excel2rdf-template.</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [44] University of Tübingen,
          <year>2022</year>
          , Cmdi to dublin core transformer, URL: https://weblicht.sfs. uni-tuebingen.de/converter/Cmdi2DC/.
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [45]
          <string-name>
            <given-names>Creative</given-names>
            <surname>Commons</surname>
          </string-name>
          ,
          <year>2022</year>
          , License chooser, URL: https://creativecommons.org/choose/.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>