FAIR Assessment Tool by TKFDM

The first step in (re)using data is to find them. Metadata and data should be easy to find for both humans and computers. Machine-readable metadata are essential for automatic discovery of datasets and services, so this is an essential component of the FAIRification process.

• F1. (Meta)data are assigned a globally unique and persistent identifier
• F2. Data are described with rich metadata (defined by R1 below)
• F3. Metadata clearly and explicitly include the identifier of the data they describe
• F4. (Meta)data are registered or indexed in a searchable resource

Once the user finds the required data, she/he/they need to know how they can be accessed, possibly including authentication and authorisation.

• A1. (Meta)data are retrievable by their identifier using a standardised communications protocol
• A1.1 The protocol is open, free, and universally implementable
• A1.2 The protocol allows for an authentication and authorisation procedure, where necessary
• A2. Metadata are accessible, even when the data are no longer available

The data usually need to be integrated with other data. In addition, the data need to interoperate with applications or workflows for analysis, storage, and processing.

• I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.
• I2. (Meta)data use vocabularies that follow FAIR principles
• I3. (Meta)data include qualified references to other (meta)data

The ultimate goal of FAIR is to optimise the reuse of data. To achieve this, metadata and data should be well-described so that they can be replicated and/or combined in different settings.

• R1. (Meta)data are richly described with a plurality of accurate and relevant attributes
• R1.1. (Meta)data are released with a clear and accessible data usage license
• R1.2. (Meta)data are associated with detailed provenance
• R1.3. (Meta)data meet domain-relevant community standards

Identifiers play a crucial role in identifying, locating, retrieving, linking, and citing datasets. While a web address (URL) can indicate where a resource is found online, URLs often change over time, resulting in broken links and irretrievable data.

The solution? Persistent Identifiers (PIDs). Unlike regular URLs, PIDs remain stable and unique over time. They work across multiple platforms because they are managed by independent, dedicated registries. The most widely used PID for datasets is the Digital Object Identifier (DOI), which is also common in academic publishing and event documentation.

Want to learn more about PIDs? Visit the PID Network for further information.

A (persistent) identifier shouldn't just exist – it should also be included in the metadata of the dataset. This applies to various possible locations, such as:

• the dataset’s entry or landing page in the repository
• the documentation (e.g. a README file), and
• at least one of the repository’s export formats (e.g. XML, JSON, JSON-LD, BibTeX, etc.) or embedded directly in the HTML source code of the landing page.

To achieve the highest score, the identifier should be present in all of these places. If it appears in only one or two, or if not all of these metadata types are available, select the second option. If the identifier is missing entirely in the available metadata – or if no identifier exists at all – choose the third option.

Comprehensive metadata records include descriptive information that supports the discovery, access, and reuse of the dataset.

A widely used standard for metadata attributes is defined by DataCite, which specifies 20 properties: 6 are mandatory, 6 are recommended, and 8 are optional. These metadata elements can typically be found on the dataset's landing page – or more completely – in the JSON, XML, or other export formats provided by the repository.

To answer this question, check the box for the filled out metadata fields and count them. The selected fields will also be transferred to the downloadable report.

Total: 0

In the context of (meta)data quality, the platform on which data is published can play a crucial role. In a data journal, research datasets or data papers are published only after undergoing a peer review process, ensuring that they make sense not only structurally – via metadata – but also from a scientific perspective. In contrast, a research data repository allows for the provision of detailed metadata for dataset entries, but typically does not evaluate the actual content of the data. When a dataset is published as a supplement to a journal article, it is often not described separately and simply inherits the metadata of the article itself. A basic website that merely links to a dataset often lacks standardized metadata altogether, such as those defined in F3 by the DataCite attributes.

A rich metadata description alone does not guarantee that a dataset will be findable on the internet. To be discoverable, the dataset must be registered or indexed in a searchable resource. This can be achieved by the platform, for example, by registering a DOI via DataCite or by embedding JSON-LD metadata directly in the HTML code of the dataset’s landing page.

To check whether a dataset is findable on the web, try using a general search engine like Ecosia, DuckDuckGo, Google, Bing – or use specialized dataset search engines such as OpenAIRE Search or Google Dataset Search. In less ideal cases, the dataset may not be registered externally, but still indexed within the hosting platform, making it at least searchable internally. In the worst-case scenario, the dataset is only accessible via a direct URL, which means it is not discoverable through any search engine at all.

This criterion evaluates whether the accessibility statement clearly communicates how the resource can be accessed. The statement should be written in a way that avoids vague or ambiguous language and ensures that users can easily understand what steps (if any) are needed to access the data or service. If there is no accessibility statement but the data can be freely downloaded select answer "1) Yes, Open Access".

Importantly, the FAIR principles do not require data to be openly accessible. Embargoed, restricted, or controlled access is fully acceptable (especially in cases involving sensitive or personal data) as long as the access conditions are clearly described. Nevertheless, the guiding ideal remains: as open as possible, as closed as necessary.

The download options describe how users can technically retrieve the data once access has been granted. Typical download mechanisms include a direct download via a web interface (e.g. HTML link to a file or dataset) or machine-accessible methods such as an API. The more flexible and standardized the download options are, the better the resource supports automated reuse and integration into workflows.

Common API types include RESTful APIs, which allow programmatic access to specific data endpoints, and OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting), often used in repositories to expose metadata and sometimes full data. To be considered a valid download option, the repository must explicitly indicate in its documentation that such an API exists and provide sufficient instructions on how to use it (e.g. base URLs, endpoints, authentication requirements). Providing both a user-friendly (HTML) and a machine-readable (API) access path is considered best practice, though having at least one method clearly documented and functional is usually sufficient to meet basic FAIR standards.

The long-term accessibility of metadata is a core element of the FAIR principles. Even if the underlying data can no longer be made available (due to legal, ethical, technical, or organizational reasons) the metadata should remain accessible to preserve the scientific record, enable citation, and support discoverability of past research outputs.

To fulfill this criterion, the repository should explicitly state whether metadata will be retained and remain publicly accessible even if the data files are deleted, embargoed, or otherwise removed. Ideally, the repository also provides information on its preservation and contingency strategies – e.g. how long metadata is guaranteed to be stored, and whether metadata (and/or data) is transferred to an archival service or another trusted repository in case of deprecation or closure of the hosting platform.

The metadata should be provided in a structured, machine-readable format that follows common standards. Standardized metadata formats enable interoperability across systems, facilitate automated data processing, and support long-term usability of the data.

Typical formats include XML, JSON or JSON-LD, which are widely used for structured data exchange, as well as YAML, which is often used for configuration or lightweight metadata, and BibTeX (.bib) for bibliographic references. These formats exist to ensure that metadata can be easily parsed, validated, and reused by both humans and machines. The use of such formats is a key step toward making data interoperable across platforms, tools, and domains.

Standardized metadata values ensure consistency, machine-readability, and semantic clarity across datasets and systems. By using community-recognized identifiers, formats, and vocabularies, metadata becomes more interoperable and easier to link with other research outputs. Key elements that benefit from standardization include:

• Person identifiers such as ORCID, ResearcherID, ScopusID, ISNI, VIAF, or GND
• Institutional identifiers such as ROR, ISNI, RINGGOLD, GRID, or Wikidata
• Dates formatted according to the ISO 8601 standard (e.g. 2023-11-05)
• Keywords drawn from controlled vocabularies like GND, MeSH, GEMET, Iconclass, or EuroSciVoc (see BARTOC for a registry of vocabularies)
• Relations between resources, expressed using qualified descriptors such as is part of, is documented by, is version of, etc.

Applying such standards strengthens metadata quality and enhances integration with other data sources. It is, however, sufficient to apply these standards where feasible. For instance, a ROR ID may not be available if an institution is not listed in the ROR registry, or keywords might not come from a controlled vocabulary if they describe emerging or highly specific topics not yet covered by existing thesauri.

Linked metadata refers to the practice of connecting metadata elements to authoritative external resources, related data, or formal definitions. Such linking enhances the semantic richness and interoperability of metadata, allowing both humans and machines to better interpret the context and meaning of each element.

For example, personal identifiers like ORCID or GND should not only be present but also resolvable. This means they are provided as clickable links that lead to the corresponding profile or entry. The same applies to institutional identifiers such as ROR or ISNI, which should point to a reliable description of the affiliated organization.

Keywords taken from standardized vocabularies may also link to explanations or hierarchical structures. This helps users understand their meaning and relationships. While not all keywords need to be linked, doing so for at least a representative subset is considered good practice. Additionally, references to related resources – such as other datasets, publications, or a documentation – should ideally be expressed as qualified, clickable links. These links should resolve to the original source or record of the related item.

Establishing such connections not only supports better navigation and reuse. It also contributes to realizing the vision of the semantic web, where data is meaningfully connected across systems.

Comprehensive documentation is essential for understanding, interpreting, and reusing a dataset. This question focuses on where and in what form such documentation is provided. Ideally, descriptive information – especially about provenance, structure, and context (see second question in Reusable) – is embedded directly within the repository or the dataset itself.

Within the repository, metadata fields can be filled out during deposition or be accompanied by a file such as a README or another structured description format. This is the preferred form, as the documentation is preserved together with the dataset. Alternatively, the dataset may be described in a publication, project website, or another external resource. While this can provide rich context, the separation may hinder long-term access and make automated interpretation more difficult.

A license defines the conditions under which a particular object can be used, modified, and shared. The absence of a license does not imply that the object is free to use but requires obtaining explicit permission from the copyright holder for the intended use. By issuing a license, you eliminate this uncertainty, clearly communicate the terms of use, and reduce the need for individual permissions.

Whenever possible, choose a well-known, standardized, and machine-readable license to minimize misunderstandings. Be sure to include the license name, identifier, and a link to its full text in your work.

Different licenses are suited to different use cases and types of objects. To encourage the reuse of your work, select a license that is as open as possible while being as restrictive as necessary. Commonly used open standard licenses for research data and software include:

• Creative Commons for data, e.g. CC0-1.0 and CC-BY-4.0
• Open Data Commons for data and especially databases, e.g. PDDL and ODC-By
• Various open-source software licenses, such as: MIT, BSD-3-Clause, Apache-2.0, LGPL-3.0-only and GPL-3.0-only

Licenses can typically be found in the metadata of a repository entry, in a dedicated LICENSE file, or within a README file. To verify whether a license is standardized and machine-readable, you can refer to SPDX. For a quick overview of a license's terms and conditions consult TLDRLegal. However, it is essential to read the full license text carefully before applying it to your works, which exceed the threshold of originality. For example, pure measurement data from scientific instruments do not and are best published under CC0. For details see forschungsdaten.info (de|en).

Provenance information documents the origins, history, and evolution of data throughout its life cycle. Key elements include:

• Research Context: The underlying research question and related projects, publications, or datasets.
• Contributions: Contact information and roles of contributors.
• Data Organization: Naming conventions and organizational structures.
• Methodology: Requirements, methods, and software used for data generation, transformation, analysis, visualization, and reuse.

Rich provenance information fosters collaboration builds trust through accountability, and enhances data quality by promoting reproducibility, transparency, and compliance. Provenance information is typically found in the README file and in the structured metadata on a repository’s web interface or in its export files (e.g. XML, JSON, ...).

To achieve the highest score in this question, pay special attention to the detailed description of data origin, evolution, and handling.

Whenever possible, use open, standardized file formats that are platform-agnostic, non-proprietary, and ideally machine-readable. Open formats enhance the accessibility, interoperability, and longevity of your data, facilitating its reuse across disciplines. Learn more about open formats, for example, at the European Data Portal.

However, proprietary file formats are often involved in the research data life cycle, such as those generated by scientific instruments or specialized software. While these formats may be unavoidable, aim to export your data to open formats at reasonable intervals. When publishing data, include both the open and proprietary formats, especially if the latter are common in your field. Provide additional information about proprietary formats, explaining which instruments produce and which software is needed to handle them.

Avoid using non-research-specific, proprietary file formats when equivalent open formats exist. For example, use Markdown and CSV for text and tabular data, or the OpenDocument format for office applications. Consult Wikipedia's list of open file formats to find suitable options for various data types.

Provide a recommended citation style for your data to facilitate proper acknowledgment of your work and encourage data sharing. Common citation styles include APA, Harvard or IEEE. Recommended citation styles are typically found in the metadata, the README file or a dedicated CITATION file, such as a CFF file.

If you can import the citation metadata directly into a reference manager (i.e. Citavi or Zotero) choose the first option.