Test a discovered data GUID for the ability to implement authentication and authorization in its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. It also searches the metadata for the Dublin Core 'accessRights' property, which may point to a document describing the data access process. Recognition of other identifiers will be added upon request by the community.

API Definition

Test that the identifier of the data is an unambiguous element of the metadata. Tested options are schema:distribution, http://www.w3.org/ns/ldp#contains, iao:IAO_0000136, IAO:0000136,ldp:contains,foaf:primaryTopic,schema:distribution,schema:contentUrl,schema,mainEntity,schema:codeRepository,schema:distribution,schema:contentUrl, dcat:distribution, dcat:dataset,dcat:downloadURL,dcat:accessURL,sio:SIO_000332, sio:is-about, obo:IAO_0000136

API Definition

Test if the data uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a 'knowledge representation language'; in this evaluation, a knowledge representation language is interpreted as one in which terms are semantically-grounded in ontologies. Any form of ontologically-grounded linked data will pass this test.

API Definition

Test if the data uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a 'knowledge representation language'; in this evaluation, a knowledge representation language is interpreted as one in which terms are semantically-grounded in ontologies. Any form of structured data will pass this test

API Definition

Data may be retrieved by an open and free protocol. Tests data GUID for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community.

API Definition

Tests whether a machine is able to find 'grounded' metadata. i.e. metadata terms that are in a resolvable namespace, where resolution leads to a definition of the meaning of the term. Examples include JSON-LD, embedded schema, or any form of RDF. This test currently excludes XML, even when terms are namespaced. Future versions of this test may be more flexible.

API Definition

Tests metadata GUID for the ability to implement authentication and authorization in its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community.

API Definition

Metric to test if the metadata contains the unique identifier to the metadata itself. This is done using a variety of 'scraping' tools, including DOI metadata resolution, the use of the 'extruct' Python tool, and others. The test is executed by searching for the predicates 'http[s]://purl.org/dc/terms/identifier','http[s]://schema.org/identifier.

API Definition

Metric to test if the unique identifier of the metadata resource is likely to be persistent. Known schema are registered in FAIRSharing (https://fairsharing.org/standards/?q=&selected_facets=type_exact:identifier%20schema). For URLs that don't follow a schema in FAIRSharing we test known URL persistence schemas (purl, oclc, fdlp, purlz, w3id, ark).

API Definition

Maturity Indicator to test if the linked data metadata contains an explicit pointer to the license. Tests: xhtml, dvia, dcterms, cc, data.gov.au, and Schema license predicates in linked data, and validates the value of those properties.

API Definition

Maturity Indicator to test if the metadata contains an explicit pointer to the license. This 'weak' test will use a case-insensitive regular expression, and scan both key/value style metadata, as well as linked data metadata. Tests: xhtml, dvia, dcterms, cc, data.gov.au, and Schema license predicates in linked data, and validates the value of those properties.

API Definition

Maturity Indicator to test if the metadata uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a 'knowledge representation language'; in this evaluation, anything that can be represented as structured data will be accepted.

API Definition

Maturity Indicator to test if the metadata links outward to third-party resources. It only tests metadata that can be represented as Linked Data.

API Definition

Metric to test if the metadata contains a persistence policy, explicitly identified by a persistencePolicy key (in hashed data) or a http://www.w3.org/2000/10/swap/pim/doc#persistencePolicy predicate in Linked Data. DOIs are assumed to have metadata persistence.

API Definition

Metadata may be retrieved by an open and free protocol. Tests metadata GUID for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community.

API Definition

Maturity Indicator to test if the linked data metadata uses terms that resolve to linked (FAIR) data.

API Definition

Tests whether a machine is able to discover the resource by search, using Microsoft Bing.

API Definition

Tests whether a machine is able to find structured metadata. This could be (for example) RDFa, embedded json, json-ld, or content-negotiated structured metadata such as RDF Turtle.

API Definition

Metric to test if the metadata resource has a unique identifier. This is done by comparing the GUID to the patterns (by regexp) of known GUID schemas such as URLs and DOIs. Known schema are registered in FAIRSharing (https://fairsharing.org/standards/?q=&selected_facets=type_exact:identifier%20schema)

API Definition

This check verifies if the following minimum metadata are present in the ontology metadata: * title: declared using [dc:title](http://purl.org/dc/elements/1.1/title), [dcterms:title](http://purl.org/dc/terms/title) or [schema:name](http://schema.org/name) * description: declared using [dc:abstract](http://purl.org/dc/elements/1.1/abstract), [dcterms:abstract](http://purl.org/dc/terms/abstract), [dc:description](http://purl.org/dc/elements/1.1/description), [dcterms:description](http://purl.org/dc/terms/description), [schema:description](http://schema.org/description), [rdfs:comment](http://www.w3.org/2000/01/rdf-schema#comment), [doap:description](http://usefulinc.com/ns/doap#description), [doap:shortdesc](http://usefulinc.com/ns/doap#shortdesc) or [skos:note](http://www.w3.org/2004/02/skos/core#note) * license: declared using [dcterms:license](http://purl.org/dc/terms/license), [schema:license](http://schema.org/licesne), [doap:license](http://usefulinc.com/ns/doap#license) or [cc:license](http://creativecommons.org/ns#license). * version iri: declared using [owl:versionIRI](http://www.w3.org/2002/07/owl#versionIRI) * creator: declared using [dc:creator](http://purl.org/dc/elements/1.1/creator), [dcterms:creator](http://purl.org/dc/terms/creator), [pav:createdBy](http://purl.org/pav/createdBy), [pav:authoredBy](http://purl.org/pav/authoredBy), [schema:creator](http://schema.org/creator), [prov:wasAttributedTo](http://www.w3.org/ns/prov#wasAttributedTo) or [doap:developer](http://usefulinc.com/ns/doap#developer) * namespace URI: declared using [vann:preferredNamespaceUri](https://purl.org/vocab/vann/) The test will pass if all ontology metadata are present. The test will fail otherwise, indicating the properties that are missing.

API Definition

This test verifies if the ontology has a persistent URL. We do so by checking if the ontology URI follows any of the following URI schemes: * w3id.org * doi.org * purl.org (or purl.something.org) * linked.data.gov.au * dbpedia.org * www.w3.org * perma.cc * data.europa.eu

API Definition

This check verifies if the ontology uses an open protocol (HTTP or HTTPS). The test will pass if the ontology URI starts with http or https. It will fail otherwise.

API Definition

This test verifies whether there is an id for this ontology version, and whether the id is unique (i.e., different from the ontology URI). The test will pass if: 1. The ontology has a versionIRI ([owl:versionIRI](http://www.w3.org/2002/07/owl#versionIRI)) and 2. The versionIRI used is different from the ontology URI. Otherwise the test will fail. The test will also verify whether version information is present (through [owl:versionInfo](http://www.w3.org/2002/07/owl#versionInfo)), but this is optional.

API Definition

This test verifies if the ontology URI that was found within the ontology document is resolvable. Note that the ontology URI found in the ontology may be different from the URI used in the assessment. The test will pass if the vocabulary is resolvable in any of the following RDF serializations: RDF/XML, TTL, N-Triples, JSON-LD. The test will fail if no known RDF serialization is returned, or the serialization returned is not among one of the aforementioned.

API Definition

This test verifies if a license (or rights) are associated with the ontology. The test will pass if a license is declared using any of the following properties: [dcterms:license](http://purl.org/dc/terms/license), [schema:license](https://schema.org/license), [doap:license](http://usefulinc.com/ns/doap#license) or [cc:license](http://creativecommons.org/ns#license). If a license is not found, but rights are declared (using [dc:rights](http://purl.org/dc/elements/1.1/rights), [dcterms:rights](http://purl.org/dc/terms/rights) or [dcterms:accessRights](http://purl.org/dc/terms/accessRights)), the test will pass as well. Otherwise, the test will fail (i.e., no license or rights are declared).

API Definition

This test verifies if the ontology reuses other vocabularies for declaring metadata terms (see tests OM1... OM5). The test will pass if metadata annotations using properties from any of the following vocabularies are used: * [Dublin Core](http://purl.org/dc/elements/1.1/) (dc, dcterms) * [Schema.org](https://schema.org/) (schema) * [Vocabulary for annotating vocabulary descriptions](http://purl.org/vocab/vann/) (vann) * [W3C Provenance standard](http://www.w3.org/ns/prov#) (prov) * [Bibliographic Ontology](http://purl.org/ontology/bibo/) (bibo) * [Provenance, Authoring and Versioning](http://purl.org/pav/) (pav) * [Firend of a friend](http://xmlns.com/foaf/0.1/) (foaf) * [Description of a project](http://usefulinc.com/ns/doap#) (doap) * [Metadata vocabulary for ontology descriptions](https://w3id.org/mod#) (mod) * [Web Ontology Language](http://www.w3.org/2002/07/owl#) (owl) * [Resource description framework schema](http://www.w3.org/2000/01/rdf-schema#) (rdfs) The test will also return the vocabularies that were found. If none are found, the test will fail.

API Definition

This test verifies whether the ontology prefix is available in [prefix.cc]((https://prefix.cc/)) or the [Linked Open Vocabularies (LOV)]((https://lov.linkeddata.es/)) registries. The test will pass if: 1. there is a prefix declared in the assessed ontology, 2. the prefix is found in [LOV](https://lov.linkeddata.es/) or [prefix.cc](https://prefix.cc/) 3. if found in [LOV](https://lov.linkeddata.es/) or [prefix.cc](https://prefix.cc/) , the namespace URI associated with the prefix is the same as the assessed ontology URI (or preferred namespace URI) Otherwise, the test will fail.

API Definition

This test verifies if the ontology can be found in a public registry like the Linked Open Vocabularies (LOV) public registry. The test will pass if the assessed ontology URI is found in the list of vocabularies returned by LOV. Alternatively, if there is a [schema:includedInDataCatalog](https://schema.org/includedInDataCatalog) annotation, the test will pass. The test will fail otherwise.

API Definition

This test verifies if the ontology has a valid RDF serialization (TTL, N3, RDF/XML or JSON-LD are supported). The test will fail if no RDF serialization could be loaded for analysis (e.g., the ontology has typos that prevent its parsing). The test uses the OWLAPI to load ontologies or vocabularies.

API Definition

This check verifies if detailed provenance information is available for the ontology: * issued date: declared using [dcterms:issued](http://purl.org/dc/terms/issued), [dcterms:submitted](http://purl.org/dc/terms/submitted) or [schema:datePublished](https://schema.org/datePublished) * publisher: declared using [dc:publisher](http://purl.org/dc/elements/1.1/publisher), [dcterms:publisher](http://purl.org/dc/terms/publisher) or [schema:publisher](https://schema.org/publisher) The test will pass if both metadata fields are present. The test will fail otherwise, indicating the properties that are missing.

API Definition

This test verifies if the ontology has an HTML documentation. The test will attempt to download an HTML representation using the ontology URI, with content negotiation

API Definition

This test verifies if the following recommended metadata are present in the ontology metadata: * Namespace prefix: declared using [vann:preferredNamespacePrefix](https://purl.org/vocab/vann/) * Version info: declared using [owl:versionInfo](http://www.w3.org/2002/07/owl#versionInfo) or [schema:schemaVersion](http://schema.org/schemaVersion) * Creation date: declared using [dcterms:created](http://purl.org/dc/terms/created), [schema:dateCreated](http://schema.org/dateCreated), [doap:created](http://usefulinc.com/ns/doap#created), [prov:generatedAtTime](http://www.w3.org/ns/prov#generatedAtTime) or [pav:createdOn](http://purl.org/pav/) * Citation: declared using [dcterms:bibliographicCitation](http://purl.org/dc/terms/bibliographicCitation) * Contributor (optional): declared using [dc:contributor](http://purl.org/dc/elements/1.1/contributor), [dcterms:contributor](http://purl.org/dc/terms/contributor), schema:contributor, [doap:documenter](http://usefulinc.com/ns/doap#documenter), [doap:maintainer](http://usefulinc.com/ns/doap#maintainer), [doap:helper](http://usefulinc.com/ns/doap#helper), [doap:translator](http://usefulinc.com/ns/doap#translator) or [pav:contributedBy](http://purl.org/pav/). The test will pass if all the recommended metadata properties are available in the ontology metadata (using any of the vocabularies listed above). The test will also check if contributor is present, but with no penalty (as not all ontologies have a contributor).

API Definition

This test verifies whether HTML and an RDF representation is available for the target vocabulary by doing content negotiation on the ontology URI. The test will pass if the vocabulary is available in HTML and in any of the following RDF serializations: * RDF/XML (application/rdf+xml), * TTL (text/turtle), * N-Triples (text/n3), * JSON-LD (application/ld+json) The test will fail if no HTML is returned, if no known RDF serialization is returned, or the serialization returned is not among one of the aforementioned.

API Definition

This test verifies if the ontology includes the following detailed metadata: * Digital Object Identifier (DOI): declared using [bibo:doi](http://purl.org/ontology/bibo/doi), [schema:identifier](https://schema.org/identifier) (if a doi is provided) or [dcterms:identifier](http://purl.org/dc/terms/identifier) (if a doi is provided) * publisher: declared using [dc:publisher](http://purl.org/dc/elements/1.1/publisher), [dcterms:publisher](http://purl.org/dc/terms/publisher) or [schema:publisher](https://schema.org/publisher) * logo: declared using [foaf:logo](http://xmlns.com/foaf/0.1/logo) or [schema:logo](https://schema.org/logo) * status: declared using [bibo:status](http://purl.org/ontology/bibo/status) or [mod:status](https://w3id.org/mod#status) * source: declared using [dcterms:source](http://purl.org/dc/terms/source) or [prov:hadOriginalSource](http://www.w3.org/ns/prov#hadOriginalSource) * issued date: declared using [dcterms:issued](http://purl.org/dc/terms/issued) * previous version (optional): declared using [dc:replaces](http://purl.org/dc/elements/1.1/replaces), [dcterms:replaces](http://purl.org/dc/terms/replaces), [prov:wasRevisionOf](http://www.w3.org/ns/prov#wasRevisionOf), [owl:priorVersion](http://www.w3.org/2002/07/owl#priorVersion) or [pav:previousVersion](http://purl.org/pav/previousVersion) * backward compatibility (optional): declared using [owl:backwardCompatibleWith](http://www.w3.org/2002/07/owl#backwardCompatibleWith) * modified date (optional): declared using [dcterms:modified](http://purl.org/dc/terms/modified) or [schema:dateModified](https://schema.org/dateModified) The test will pass if all the detailed metadata properties are available in the ontology metadata (using any of the vocabularies listed above). The test will also check if previosu version, backward compatibility and modified date are present, but with no penalty (as not all ontologies have a previous version).

API Definition

This test verifies if the version IRI resolves. The test will pass if there is a version IRI for the ontology/vocabulary (detected using [owl:versionIRI](http://www.w3.org/2002/07/owl#versionIRI) in the ontology metadata) and whether doing a request to said IRI returns a resource. The test will fail if the resource is not found (404 response) or returns an error.

API Definition

This test verifies the extent to which all ontology terms have labels. The test will pass if all classes, properties and data properties have either an [rdfs:label](http://www.w3.org/2000/01/rdf-schema#label) or [skos:prefLabel](http://www.w3.org/2004/02/skos/core#prefLabel). For skos vocabularies, only the skos:Concepts are assessed. Otherwise, the test will fail, indicating the level of completeness found (i.e., percentage of documented terms)

API Definition

This check verifies whether all ontology terms have descriptions. The test will pass if all classes, properties and data properties have at least one [rdfs:comment](http://www.w3.org/2000/01/rdf-schema#comment), [skos:definition](http://www.w3.org/2004/02/skos/core#definition) or [obo:IAO_0000118](http://purl.obolibrary.org/obo/IAO_0000118) annotation. For skos vocabularies, only the skos:Concepts are assessed. The test will fail otherwise, showing the level of completeness obtained (i.e. the percentage of documented terms).

API Definition

This test verifies if the ontology license is resolvable. The test will pass if the license available in the ontology metadata resolves to a resource. The test will fail if no license is declared (OM4.1), if the license is not a URI/URL, or if the response when requesting is 404 or an error.

API Definition

This check verifies if the ontology URI is equal to the ontology ID. The test passes if the ontology URI used to load the ontology document is the same as the ontology id found in the document itself. Otherwise the test will fail.

API Definition

This test verifies if the ontology imports/extends other vocabularies (besides RDF, OWL and RDFS). The test will pass if other vocabularies are imported ([owl:imports](http://www.w3.org/2002/07/owl#imports)), or if classes, properties or data properties outside the ontology URI or namespace URI are used. The test wil fail if no terms are reused.

API Definition

Metadata are accessible even when the ontology is no longer available. Since the metadata is usually included in the ontology, this test verifies if the ontology can be found in the [Linked Open Vocabularies (LOV) public registry](https://lov.linkeddata.es). The test will pass if the assessed ontology/vocabulary URI is found in the LOV list of vocabularies. Alternatively, if there is a [schema:includedInDataCatalog](https://schema.org/includedInDataCatalog) annotation, the test will pass. The test will fail otherwise.

API Definition

This check verifies if an ontology prefix is declared in the ontology metadata. The test will pass if a [vann:preferredNamespacePrefix](http://purl.org/vocab/vann/) is declared. Otherwise, the test will fail.

API Definition

This check verifies if basic provenance metadata is available for the ontology: * creator: declared using [dc:creator](http://purl.org/dc/elements/1.1/creator), [dcterms:creator](http://purl.org/dc/terms/creator), [pav:createdBy](http://purl.org/pav/createdBy), [pav:authoredBy](http://purl.org/pav/authoredBy), [schema:creator](https://schema.org/creator) or [doap:developer](http://usefulinc.com/ns/doap#developer) * creation date: declared using [dcterms:created](http://purl.org/dc/terms/created), [schema:dateCreated](https://schema.org/dateCreated), [doap:created](http://usefulinc.com/ns/doap#created), [prov:generatedAtTime](http://www.w3.org/ns/prov#generatedAtTime) or [pav:createdOn](http://purl.org/pav/createdOn) * contributor (optional): declared using [dc:contributor](http://purl.org/dc/elements/1.1/contributor), [dcterms:contributor](http://purl.org/dc/terms/contributor), [schema:contributor](https://schema.org/contributor), [doap:documenter](http://usefulinc.com/ns/doap#documenter), [doap:maintainer](http://usefulinc.com/ns/doap#maintainer), [doap:helper](http://usefulinc.com/ns/doap#helper), [doap:translator](http://usefulinc.com/ns/doap#translator) or [pav:contributedBy](http://purl.org/pav/contributedBy). * previous version (optional): declared using [dc:replaces](http://purl.org/dc/elements/1.1/replaces), [dcterms:replaces](http://purl.org/dc/terms/replaces), [prov:wasRevisionOf](http://www.w3.org/ns/prov#wasRevisionOf), [owl:priorVersion](http://www.w3.org/2002/07/owl#previousVersion), [pav:previousVersion](http://purl.org/pav/previousVersion) The test will pass if creator and creation date are present. The test will fail otherwise, indicating the properties that are missing.

API Definition

Maturity Indicator to test if the metadata uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a 'knowledge representation language'; in this evaluation, a knowledge representation language is interpreted as one in which terms are semantically-grounded in ontologies. Any form of RDF will pass this test (including RDF that is automatically extracted by third-party parsers such as Apache Tika).

API Definition

This test checks that the identifier associated with a software (if there’s one) follows a common schema such as URN, URL, DOI, etc. This is achieved by looking for identifiers in the README file and checking if they follow one of these schemas: URN, SWHID, DOI and URL.

API Definition

This test checks if an identifier is found in the README or CITATION.cff files. This is done by looking for an identifier in the CITATION.cff and README files in the root of the repository.

API Definition

This test checks if contact and/or support metadata is found in the repository. This is achieved by checking if there is contact or support information in the README file or any other package file ( (e.g., setup.py, setup.cfg, pom.xml, etc.).

API Definition

This test checks if there is a persistent identifier (i.e., Software Heritage ID, Zenodo DOI) associated with the software repository in files like CITATION.cff, codemeta.json and README. This is achieved by looking for an identifier in the files previously mentioned.

API Definition

This test checks whether the provided URL points to a repository hosted on a source code repository such as GitHub or GitLab. It verifies both that the URL contains a known domain (e.g., "github.com" or "gitlab.com") and that it is reachable (i.e., the request returns a valid response).

API Definition

This test checks if the software has any releases in the source code repository. This is achieved by checking if there’s any releases created in the repository.

API Definition

This test checks if documentation is found in the repository. This is achieved by looking for a README file, a ReadTheDocs URL in the README file and wikis (in case of GitHub projects).

API Definition

This test checks if there are continuous integration workflows in the repository. This is done by looking for a .github.workflows directory in Github and .gitlab-ci.yml file in Gitlab.

API Definition

This test checks if dependencies are declared in the repository. This is achieved by checking if there are dependencies listed in the README file or other files like requirements.txt and pom.xml.

API Definition

This test checks whether the repository is active. It first looks for a repostatus badge with the value “Active” in the README file. If the badge is not present, the test verifies whether there have been any commits to the repository in the past, indicating ongoing development.

API Definition

This test checks if the repository license is SPDX compliant. This is done by checking if all licenses found in the repository match any of the licenses supported by SPDX.

API Definition

This test checks if a codemeta.json, CITATION.cff file or package file that includes metadata about a software component exists. This is done by looking for CITATION.cff, codemeta.json and package files (e.g., setup.py, setup.cfg, pom.xml, etc.) in the root of the repository.

API Definition

This test checks if there are contributors found in the repository. This is done by looking for contributors in files like CONTRIBUTOR, codemeta.json and package files.

API Definition

This test checks if authors have an ORCID assigned. This is done by looking for authors in the codemeta.json or AUTHORS files and checking if all of them have an ORCID assigned.

API Definition

This test checks if there are tests present in the repository. This is done by checking if there are files or directories that mention “test” in their names in the root and one level deep in the repository tree.

API Definition

This test checks if the identifier found in the repository resolves back to the source code repository. This is done by checking if the landing page where the identifier resolves to links back to the source code repository using requests.

API Definition

This test checks if the repository has a repo status badge in the README file.

API Definition

This test checks if all release identifiers follow the same scheme. This is achieved by checking if there’s any releases created in the repository and that their URLs follow the same pattern or scheme.

API Definition

This test checks if all version identifiers follow either SemVer or CalVer conventions. This is achieved by checking if there’s any releases created in the repository and that their version numbers (or tags) follow Semantic Versioning (SemVer) or Calendar Versioning (CalVer).

API Definition

This test checks if there is at least one persistent identifier (i.e., Software Heritage ID, Zenodo DOI) in the README file of the source code repository and if said identifier resolves.

API Definition

This test checks if each release has an identifier and version number. This is achieved by checking if there’s any releases created in the repository and that they have a tag and a URL.

API Definition

This test checks if the last release tag version number in the source code repository (if there is one) corresponds to the version number stated in the package file of the repository. This is achieved by checking if the version of the last release created in the repository corresponds to the version stated in the package file in the root of the repository.

API Definition

This test checks if the repository has installation instructions. This is achieved by checking in the README file of the repository if there is information about the installation of the software.

API Definition

This test checks whether the software declares a license. It first looks for a LICENSE (or similarly named) file in the root directory of the repository. If not found, it searches for license information in other common locations such as the README file, metadata files like codemeta.json or CITATION.cff, or configuration files such as setup.py.

API Definition

This test checks if dependencies are in a machine-readable file (not just in README). This is done by checking if dependencies are available in a machine-readable format like requirements.txt or pom.xml in the root of the repository.

API Definition

This test checks if dependencies have version numbers. This is achieved by checking if all dependencies listed in machine-readable files and in the README file have a version number.

API Definition

This test checks if there is a README file in the repository.

API Definition

This test checks if a codemeta.json file exists in the repository. This is done by looking for a codemeta.json file in the root of the repository.

API Definition

This test checks if there are authors found in the repository. This is done by looking for authors in files like AUTHORS, codemeta.json and CITATION.cff.

API Definition

This test checks if a metadata record is found on Zenodo and/or Software Heritage. This is done by searching in the README file for a Zenodo or Software Heritage badge.

API Definition

This test checks if descriptive metadata within the repository includes description, programming language, date created and keywords. This is done by looking for those fields in codemeta.json, README, CITATION.cff or any package metadata file ( (e.g., setup.py, setup.cfg, pom.xml, etc.).

API Definition

This test checks if the repository has title and description of the software available within any metadata file. This is achieved by checking if description and title are in the README file, codemeta.json file or any other package file (e.g., setup.py, setup.cfg, pom.xml, etc.).

API Definition

This test checks if there is a referencePublication or a citation file to a paper. This is done by looking for an article citation in the README file, for a CITATION.cff file or a referencePublication field in the codemeta.json file.

API Definition

This test checks if there is a CITATION.cff file or citations made in the README file. This is done by looking in the root of the repository for a CITATION.cff file and by checking if the README file contains citations in a bibtex format.

API Definition

This test checks if there are actions or workflows that automate tests. This is done by checking if there are workflows that mention “test” in their names in .github.workflows directory for Github and .gitlab-ci.yml file for Gitlab.

API Definition

This test checks if metadata files like codemeta.json, CITATION.cff and package file mention the repository license. This is done by looking if a license field is within said files.

API Definition

The 'FAIR Test - ARK T-A2 - Database has a preservation policy' is a database-level test that requires the presence of a data preservation policy for the database being evaluated. FM ARK A2-Preservation expects a FAIRsharing URL or DOI as its input and evaluates the database described by the FAIRsharing record: the record must have a URL in the data preservation policy field and may optionally also have a non-empty value in the name field. As described by the GFF, there should at least be access to high quality and machine actionable metadata that describes those resources sufficiently to minimally understand their nature and their provenance, even when the relevant data are not available anymore. There are a number of ways to implement this, however this metric deals with preservation of information relating to an identifier by determining if there is a preservation policy in place with the database being evaluated. The test will return as follows: Pass: URL/DOI must point to an existing FAIRsharing database record; the record must have a value in the URL section of the data preservation policy field that resolves (i.e. does not give an error code). Indeterminate: URL/DOI is non-existent, returns an error code of some kind, or is malformed. Fail: if any of the conditions in 'pass' fail; specifically, if the URL/DOI is not a database record, OR if there is an empty URL value for the data preservation policy field.

API Definition

This test checks if there is a version stated for the software in metadata files. This is done by looking for a version number in metadata files like package files, codemeta.json and CITATION.cff.

API Definition

This test checks if authors have their roles stated in a codemeta.json. This is achieved by looking for authors in the codemeta.json file and checking if all of them have a role assigned. This process follows the codemeta v2 and v3 standards.

API Definition

This test checks if the repository has an issue tracker. This is done by checking if the URL for the issues resolves.

API Definition

This test checks if the repository has commits that are linked to open and closed issues. This is done by cross-checking if issue identifiers within the issue list are present in the commit history’s messages (i.e. “closes #123”).

API Definition

This test checks if the repository has a commit history. This is done by looking for commits in the software’s repository.

API Definition

Verifies that a record contains provenance metadata elements. The test examines three elements: distrbtr (distributor/publisher) in the distribution statement (/codeBook/stdyDscr/citation/distStmt/distrbtr) AuthEnty (author/authoring entity) in the responsibility statement (/codeBook/stdyDscr/citation/rspStmt/AuthEnty) grantNo (grant number) in the production statement (/codeBook/stdyDscr/citation/prodStmt/grantNo) of DDI 2.5 metadata.

API Definition

Validates that a record uses DDI Time Method controlled vocabulary. The test examines timeMeth (time method) elements in the data collection method section (/codeBook/stdyDscr/method/dataColl/timeMeth) of DDI 2.5 metadata.

API Definition

Confirms that a record uses DDI Mode of Collection controlled vocabulary. The test examines collMode (collection mode) elements in the data collection method section (/codeBook/stdyDscr/method/dataColl/collMode) of DDI 2.5 metadata.

API Definition

Checks whether a record uses DDI Sampling Procedure controlled vocabulary. The test examines sampProc (sampling procedure) elements in the data collection method section (/codeBook/stdyDscr/method/dataColl/sampProc) of DDI 2.5 metadata.

API Definition

Verifies that a record uses DDI Analysis Unit controlled vocabulary. The test examines anlyUnit (analysis unit) elements in the study description's summary description section (/codeBook/stdyDscr/stdyInfo/sumDscr/anlyUnit) of DDI 2.5 metadata.

API Definition

Checks whether a record uses CESSDA Topic Classification controlled vocabulary. The test examines topcClas (topic classification) elements in the study information subject section (/codeBook/stdyDscr/stdyInfo/subject/topcClas) of DDI 2.5 metadata.

API Definition

Validates that a record contains properly attributed ELSST (European Language Social Science Thesaurus) keywords. The test examines keyword elements in the study information subject section (/codeBook/stdyDscr/stdyInfo/subject/keyword) of DDI 2.5 metadata.

API Definition

Verifies that a record contains approved access rights terminology. The test examines the conditions element within the data access section (/codeBook/stdyDscr/dataAccs/useStmt/conditions) of DDI 2.5 metadata.

API Definition

Confirms that a DDI 2.5 metadata record uses an approved persistent identifier scheme. The test examines IDNo elements with agency attributes in the citation's title statement section (/codeBook/stdyDscr/citation/titlStmt/IDNo) of DDI 2.5 metadata.

API Definition

Test a DOI to determine if funder information is available in the datacite or crossref metadata

API Definition

Test a DOI to determine if license information is available in the datacite or crossref metadata

API Definition

Use Crossref and Datacite APIs to scan a metadata record for author affiliation. Also check landing page for citation_author_institution meta property

API Definition

Test a DOI against OpenAlex to determine if the resource output is open-access

API Definition

I1 – (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation. Evidenced at schema level: the record conforms to the DataCite Metadata Schema or an equivalent published standard (DataCite JSON, Schema.org, DCAT-AP). This principle always passes; it is not assessed through individual field checks.

API Definition

F1 requires that metadata be assigned a globally unique, persistent and resolvable identifier. This metric is particularly concerned with the globally uniqueness aspect of GUPRIs; global uniqueness is required to prevent identifier collision across institutions, systems and domains. Otherwise, an identifier shared by multiple resources will confound efforts to describe that resource, or to use the identifier to retrieve it. In this metric, the definition of global uniqueness follows the FAIRsharing guidance on Globally Unique, Persistent and Resolvable Identifier (GUPRI) schemas. The identifier being evaluated is checked for a match (using regular expressions) to an existing id schema within FAIRsharing. Pass: The id_schema record must have the globally unique field set to 'true'. Indeterminate: URL/DOI is non-existent or malformed. Fail: if the globally unique field is set to 'false'.

API Definition

The ERDERA Project has strict requirements for minimal metadata to onboard their Virtual Platform. These include: Migration away from deprecated EJP purl properties to the w3id equivalents. Presence of the VPDiscoverable prpoperty. Properties: dcat:theme dcat:contactPoint dct:description dcat:keyword dct:language dct:license dct:publisher dct:title dcat:contactPoint dcat:landingPage. It does not test the substructure of the dct:publisher, but it must be a foaf:Agent with a foaf:name.

API Definition

The ERDERA Project has strict requirements for minimal metadata to onboard their Virtual Platform. For Level 2, you must first be Level 1 compliant (see https://w3id.org/fair-metrics/erdera/FM_R1-3_M_VP_L1). In addition, you must declare yourself as a dcat Data Service, and have a landingPage at a minimimum.

API Definition

A2 requires that metadata remain accessible even if the digital object is no longer available. The purpose of this principle is to ensure that information about a resource persists over time, independent of the continued availability of the research object itself. As per FAIR Principle F3, when this metadata remains discoverable, even in the absence of the research object, it will also contain an explicit reference to the identifier of the research object. This test evaluates whether the hosting database or repository declares a formal data preservation policy. The evaluation retrieves the FAIRsharing record for the database and checks for the presence of a value in the “Data Preservation Policy” field, as defined in the FAIRsharing database conditions documentation. The presence of a declared preservation policy in the FAIRsharing record is interpreted as evidence that the database has articulated commitments to long-term metadata availability. If a preservation policy is listed in the FAIRsharing record, the resource passes this test; if not, it fails. This metric measures database-level persistence policies as persistence information is rarely included in record-level metadata.

API Definition

F1 requires that metadata be assigned a globally unique, persistent and resolvable identifier. This metric is particularly concerned with the resolvability aspect of GUPRIs. Resolvability is required so that identifiers are actionable for both humans and machines. In this metric, the definition of resolvability follows the FAIRsharing guidance on Globally Unique, Persistent and Resolvable Identifier (GUPRI) schemas. The identifier being evaluated is checked for a match (using regular expressions) to an existing id schema within FAIRsharing. Pass: The id_schema record must have the resolvability field set to 'true'. Indeterminate: URL/DOI is non-existent or malformed. Fail: if the resolvability field is set to 'false'.

API Definition

The 'FAIR Test - I1 - Metadata - Database-level knowledge representation languages (semantic)' is a database-level test that checks for relationships between the FAIRSharing metadata record and any model/format records with a semantic format. If a FAIRsharing database record is found and is linked to a semantic model/format record then this test will pass. If the record submitted is not a database or is not so linked then the test will fail. An indeterminate value will be returned if no FAIRsharing record metadata is found.

API Definition

The 'FAIR Test - I1 - Metadata - Database-level knowledge representation languages (syntactic)' is a database-level test that checks for relationships between the FAIRSharing metadata record and any model/format records with a syntactic format. If a FAIRsharing database record is found and is linked to a syntactic model/format record then this test will pass. If the record submitted is not a database or is not so linked then the test will fail. An indeterminate value will be returned if no FAIRsharing record metadata is found.

API Definition

FAIR Test - F2 - Metadata - Discovery-Oriented Metadata Fields evaluates whether a metadata record includes a core set of mandatory descriptive elements that are essential for basic discovery. Specifically, it checks the resolved metadata for the presence of the following four fields: title, contributor names, summary/abstract/description, and publication date (defined as the date the record was first made publicly available). To pass, all of these fields must be present and populated within a structured, common format such as schema.org JSON-LD, DataCite XML, or Dublin Core XML. If any of these fields are empty, the evaluation is expected to fail.

API Definition

FAIR Test - F2 - Metadata - Tagging To Aid Discovery evaluates the metadata for the presence of at least one keyword or tag of any kind (free-text or controlled). With regards to Findability (as opposed to e.g., Interoperability), the presence of any type of tag (irrespective of whether that tag is part of a controlled vocabulary) is the key feature for this metric. The metric expects the identifier to point to structured metadata (e.g., schema.org, DataCite, or DC) and verifies that the keyword/subject property is not empty. The metric passes if at least one tag is identified and fails if the keyword attribute is missing or null.

API Definition

FAIR Test - F2 - Metadata - Has Publisher Information evaluates whether the metadata includes explicit information regarding the organisation responsible for publishing the metadata record. It looks for a structured “publisher” field within the record. In the context of an institutional repository, this is typically the institution itself, or an external repository (like Zenodo) if the record is registering an object hosted elsewhere. The test will fail if this value is not present.

API Definition

## What is being measured? This Test evaluates whether the research object provided by the supplied DOI has been formally recognised and cited within the scholarly literature. The assessment uses the DOI to query global citation indexes and aggregation services, such as OpenAlex (searching both full-text data availability sections and reference lists) and OpenCitations. The metric passes if the dataset identifier is found within the citation network of at least one external publication (in the reference section or in text). ## Why should we measure it? Under FAIR Principle R1.2, metadata must be associated with detailed provenance to support its evaluation and reuse. Formal citation in a peer-reviewed publication is a robust indicator of a research object’s provenance.

API Definition

This metric ensures that the research object provided by the supplied URL is associated with a DataCite DOI whose metadata contains a PaNET subject term. This means that the DataCite metadata for the research object’s DOI must define a subject from PaNET using schemeUri or subjectScheme. The supplied URL can be one of: a doi.org domain URL or a DOI target repository domain URL.

API Definition

F1 requires that metadata be assigned a globally unique, persistent and resolvable identifier. This metric is particularly concerned with the persistence aspect of GUPRIs; persistence is required to guarantee long-term continuity of reference. In this metric, the definition of persistence follows the FAIRsharing guidance on Globally Unique, Persistent and Resolvable Identifier (GUPRI) schemas. The identifier being evaluated is checked for a match (using regular expressions) to an existing id schema within FAIRsharing. Pass: The id_schema record must have the persistence field set to 'true'. Indeterminate: URL/DOI is non-existent or malformed. Fail: if the persistence field is set to 'false'.

API Definition

This test is designed to expose the raw output of the FAIR Champion Harvester. It is not designed to be a FAIR test, but rather a debugging tool for developers of the harvester and the FAIR tests that depend on it. The test will return the raw output of the harvester, including any comments generated during the harvesting process. The test will not attempt to interpret the output or assign a score, but will simply return the raw output for inspection by developers.

API Definition

Metadata may be retrieved by an open and free protocol. Tests metadata GUID for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community.

API Definition

Data may be retrieved by an open and free protocol. Tests Data GUID (the identifier of the data that is being described by the metadata record) for its resolution protocol. Currently passes InChI Keys, DOIs, Handles, and URLs. Recognition of other identifiers will be added upon request by the community.

API Definition

If the resolution protocol for the Metadata supports authentication and authorization for access to restricted content.

API Definition

If the resolution protocol for the Data supports authentication and authorization for access to restricted content.

API Definition

Metric to test if the metadata contains a persistence policy, explicitly identified by a persistencePolicy key (in hashed data) or a http://www.w3.org/2000/10/swap/pim/doc#persistencePolicy predicate in Linked Data. DOIs are assumed to have metadata persistence.

API Definition

Metric to test if the unique identifier of the metadata resource is likely to be persistent. Known schema are registered in FAIRSharing (https://fairsharing.org/standards/?q=&selected_facets=type_exact:identifier%20schema). For URLs that don't follow a schema in FAIRSharing we test known URL persistence schemas (purl, oclc, fdlp, purlz, w3id, ark).

API Definition

Metric to test if the metadata resource has a unique identifier. This is done by comparing the GUID to the patterns (by regexp) of known GUID schemas such as URLs and DOIs. Known schema are registered in FAIRSharing (https://fairsharing.org/standards/?q=&selected_facets=type_exact:identifier%20schema)

API Definition

Test that the identifier of the data is an unambiguous element of the metadata. Only Linked Data is considered - other non-grounded metadata is ignored. Tested predicates that likely point to a data record are:

iao:IAO_0000136, IAO:0000136, ldp:contains,foaf:primaryTopic,schema:distribution,schema:contentUrl, schema,mainEntity,schema:codeRepository, dcat:distribution, dcat:dataset,dcat:downloadURL,dcat:accessURL, sio:SIO_000332, sio:is-about, obo:IAO_0000136

API Definition

Test that the identifier of the metadata is an unambiguous element of the metadata. Tested options are ["http://purl.org/dc/elements/1.1/identifier", "https://purl.org/dc/elements/1.1/identifier", "http://purl.org/dc/terms/identifier", "http://schema.org/identifier", "https://purl.org/dc/terms/identifier", "https://schema.org/identifier"]

API Definition

Tests whether a machine is able to discover the resource by search, using Microsoft Bing. The process is to first identify the title of the resource in the metadata, then search for that title in Bing, and then check whether any of the results from Bing include a reference to the resource. This test is designed to check whether the metadata is indexed in a major search engine, which is an important aspect of findability. The test will also check for keywords in the metadata and use those as search terms as well. The properties used to identify titles in linked data are dc:title, dcterms:title, dcterms:alternative, schema:name, schema:headline, schema:alternateName, schemah:name, schemah:headline, schemah:alternateName, rdfs:label, skos:prefLabel, skos:altLabel, foaf:name and bibo:title. The properties used to identify keywords in linked data are any property containing 'keyword' in the name.

API Definition

Test if the Data record referred to by the metadata uses an RDF syntax in which terms are semantically-grounded in ontologies. Any syntax of ontologically-grounded linked data will pass this test.

API Definition

Test if the data uses a formal language broadly applicable for knowledge representation. This particular test takes a broad view of what defines a 'knowledge representation language'; in this evaluation, a knowledge representation language is interpreted any form of structured data (i.e. a purely syntactic test). This test is a 'weak' test because it does not attempt to evaluate the semantics of the data, but only the syntax. The presence of structured data in any form is sufficient to pass this test.

API Definition

Maturity Indicator to test if the metadata links outward to third-party resources. Note that this test only examines metadata that is represented as Linked Data. The test passes if the object of any triple (non-structural triples only) is a URI that points to a host other than the host of the metadata itself. This is a very weak test, but it is designed to encourage data stewards to link their metadata to external resources.

API Definition

Maturity Indicator to test if the metadata contains an explicit pointer to the license. This test will use a case-insensitive regular expression on key/value style metadata, and predicate lookup on linked data metadata. Tests: Tests for the presence of: ["http://www.w3.org/1999/xhtml/vocab#license", "https://www.w3.org/1999/xhtml/vocab#license", "http://purl.org/ontology/dvia#hasLicense", "https://purl.org/ontology/dvia#hasLicense", "http://purl.org/dc/terms/license", "https://purl.org/dc/terms/license", "http://creativecommons.org/ns#license", "https://creativecommons.org/ns#license", "http://reference.data.gov.au/def/ont/dataset#hasLicense", "https://reference.data.gov.au/def/ont/dataset#hasLicense"], and Schema license predicates in linked data. No further validation is done on the value of the license property, but the test will check if the value is a URL or not, and report that in the comments.

API Definition

Maturity Indicator to test if the linked data metadata contains an explicit and correctly structured pointer to the license. Tests for the presence of: ["http://www.w3.org/1999/xhtml/vocab#license", "https://www.w3.org/1999/xhtml/vocab#license", "http://purl.org/ontology/dvia#hasLicense", "https://purl.org/ontology/dvia#hasLicense", "http://purl.org/dc/terms/license", "https://purl.org/dc/terms/license", "http://creativecommons.org/ns#license", "https://creativecommons.org/ns#license", "http://reference.data.gov.au/def/ont/dataset#hasLicense", "https://reference.data.gov.au/def/ont/dataset#hasLicense"] and does some compliance testing on what is expected as the value of those properties. Note that this test only operates on linked data. JSON and XML metadata are not tested by this test, but may be tested by the weaker version of this test.

API Definition

Checks for the presence of grounded metadata by extracting all namespaces used in the document and checking if any of them are resolvable (i.e. can be accessed via HTTP). The method ignores common infrastructure namespaces (e.g. XML, RDF) and focuses on namespaces that are likely to represent the dataset's own metadata.

API Definition

The 'FAIR Test - F1 - Metadata - Resolvable identifiers for database content' is a database-level test that requires the minting of community-relevant, publicly available resolvable identifiers for at least some of the content within the database being evaluated. ft_f1_m_ridark expects a FAIRsharing URL or DOI as its input and evaluates the database described by the FAIRsharing record for the guaranteed resolvability of the identifier schema as defined by the identifier schema record type in FAIRsharing. Resolvability of identifier makes it practically useful, with predictable identifier resolution behavior being key. This feature is key to the Findability of the database being evaluated. The test will return as follows: Pass: URL/DOI must point to an existing FAIRsharing database record; the record must have an 'implements' to an id_schema record; that id_schema record must have the resolvable field set to 'true'. Indeterminate: URL/DOI is non-existent or malformed. Fail: if any of the conditions in 'pass' fail; specifically, if the URL/DOI is not a database record, OR if there is no 'implements' relationship to an id_schema, OR if the resolvable field is set to 'false'.

API Definition

The 'FAIR Test - F1-PID - Metadata - Persistent identifiers for database content' is a database-level test that requires the minting of community-relevant, publicly available persistent identifiers for at least some of the content within the database being evaluated. ft_f1_m_pidark expects a FAIRsharing URL or DOI as its input and evaluates the database described by the FAIRsharing record for the guaranteed persistence of the identifier schema as defined by the identifier schema record type in FAIRsharing. Persistence refers to the requirement that this globally unique identifier is never reused elsewhere and continues to identify the same resource over time. This feature is key to the Findability of the database being evaluated. The test will return as follows: Pass: URL/DOI must point to an existing FAIRsharing database record; the record must have an 'implements' to an id_schema record; that id_schema record must have the persistent field set to 'true'. Indeterminate: URL/DOI is non-existent or malformed. Fail: if any of the conditions in 'pass' fail; specifically, if the URL/DOI is not a database record, OR if there is no 'implements' relationship to an id_schema, OR if the persistent field is set to 'false'.

API Definition

The 'FAIR Test - F1 - Metadata - Globally unique identifiers for database content' is a database-level test that requires the minting of community-relevant, publicly available globally unique identifiers for at least some of the content within the database being evaluated. ft_f1_m_guidark expects a FAIRsharing URL or DOI as its input and evaluates the database described by the FAIRsharing record for the guaranteed global uniqueness of the identifier schema as defined by the identifier schema record type in FAIRsharing. As described by the GFF, global uniqueness guarantees the unambiguous referencing of the described resource; it is insufficient for it to be unique only locally. This feature is key to the Findability of the database being evaluated. The test will return as follows: Pass: URL/DOI must point to an existing FAIRsharing database record; the record must have an 'implements' to an id_schema record; that id_schema record must have the globally unique field set to 'true'. Indeterminate: URL/DOI is non-existent or malformed. Fail: if any of the conditions in 'pass' fail; specifically, if the URL/DOI is not a database record, OR if there is no 'implements' relationship to an id_schema, OR if the globally unique field is set to 'false'.

API Definition

Checks for the presence of grounded metadata by extracting all namespaces used in the document and checking if any of them are resolvable (i.e. can be accessed via HTTP). The method ignores common infrastructure namespaces (e.g. XML, RDF) and focuses on namespaces that are likely to represent the dataset's own metadata.

API Definition

Checks if the document uses a supported namespace by examining the namespace URI of the root element.

API Definition

Checks for the presence of retrievable open protocol identifiers in the document by looking for known elements and attempting to resolve them using known PID resolution services.

API Definition

Checks for the presence of resolvable FAIR vocabulary linkages in the document. The test finds all elements that have a specified attribute, then iterates through those elements to check if they have both a declared vocabulary name and a linked vocabulary URI.

API Definition

Checks for the presence of a formal KR language in the document. The test first checks if the document uses a supported namespace, which is a strong indicator that it is using a formal language.

API Definition

This metric evaluates whether the metadata retrieved from the provided URI contains an identifier that satisfies the FAIRsharing definition of guaranteed persistence, as aligned with the EOSC PID Policy. Note that it assesses the metadata retrieved from the URI rather than the URI itself. During assessment, the provided URI is resolved in accordance with FAIRsharing’s identifier resolution best practices. If the record contains DOI or ARK identifiers it will pass. If any identifier URLs can be determined as persistent via FAIRsharing data the test will also pass. Otherwise, it will fail.

API Definition

This metric evaluates whether the metadata retrieved from the provided URI contains an identifier that satisfies the FAIRsharing definition of guaranteed resolvability, as aligned with the EOSC PID Policy. Note that it assesses the metadata retrieved from the URI rather than the URI itself. During assessment, the provided URI is resolved in accordance with FAIRsharing’s identifier resolution best practices. If the record contains DOI or ARK identifiers it will pass. If any identifier URLs can be determined as resolvable via FAIRsharing data the test will also pass. Otherwise, it will fail.

API Definition

This metric evaluates whether the metadata retrieved from the provided URI contains an identifier that satisfies the FAIRsharing definition of guaranteed global uniqueness, as aligned with the EOSC PID Policy. Note that it assesses the metadata retrieved from the URI rather than the URI itself. During assessment, the provided URI is resolved in accordance with FAIRsharing’s identifier resolution best practices. If the record contains DOI or ARK identifiers it will pass. If any identifier URLs can be determined as globally unique via FAIRsharing data the test will also pass. Otherwise, it will fail.

API Definition

F1 – (Meta)data are assigned a globally unique and persistent identifier. Evidenced by: Identifier (datacite:identifier with a persistent identifier type such as DOI, Handle, ARK, PURL, URL, or URN). A missing or malformed identifier means the dataset cannot be reliably located or cited.

API Definition

FAIR Test - R1.2 - Metadata - ROR ID for funder evaluates whether the metadata includes at least one ROR ID for a funder associated with the research object. The assessment checks for structured funding references within both the landing page metadata and the central records held by DOI registration agencies (such as DataCite or Crossref). Specifically, it verifies that fields such as fundingReferences (DataCite) or funder (Crossref) are populated with at least one funder ROR ID. It checks the record’s landing page for embedded or linked structured data that can be successfully parsed against the declared community schema. If the record contains ROR identifiers it will pass; otherwise, the test will fail

API Definition

FAIR Test - R1.3 - Metadata – use of recognised and structured generic metadata format evaluates whether the dataset metadata is structured according to predefined, widely adopted metadata schemas appropriate to institutional repositories and other generalist contexts, such as schema.org (JSON-LD) or DataCite. It checks the record’s landing page for embedded or linked structured data that can be successfully parsed against the declared community schema. Finding JSON+LD or XML formats will result in a pass; otherwise, the test will fail.

API Definition

FAIR Test - R1.2 - Metadata - Creator ORCIDs evaluates whether the metadata includes at least one qualified reference to ORCID for a contributor with a ‘creator’ role. The presence of ORCIDs linked to individuals, together with the defined ‘creator’ role, constitutes a qualified provenance reference. If the record contains a creator and this creator has an ORCID ID it will pass; otherwise, the test will fail.

API Definition

This metric evaluates whether the protocol used to retrieve metadata referenced by the provided identifier is either HTTP or HTTPS and therefore openly specified, free to implement, and universally implementable.

API Definition

This test evaluates whether the metadata for the digital object includes at least one resolvable language attribute defined by the ISO 639 standard. It evaluates the value held in the language field against the official ISO 639 registry, searching for a valid, standardised code (specifically 639-2 / 639:2023) or a URI pointing to an ISO term.

API Definition

A1.2 requires that the protocol used to retrieve research objects clearly describes any necessary authentication and authorisation procedures. This ensures that access conditions are transparent and that restricted content is accessed in a defined and controlled way. Optionally, if a FAIRsharing record for the hosting database is available, the evaluation first checks the declared data access conditions. If the access condition is “open” then no authentication or authorisation is required for any content within that database, and the evaluation is complete. Otherwise, the test currently fails. [https://tests.ostrails.eu/tests/test_FM_A1_2_M_Auth](https://tests.ostrails.eu/tests/test_FM_A1_2_M_Auth) should also be run.

API Definition

This test evaluates whether the metadata includes at least one qualified reference to linked publications: where a metadata record includes at least one linked publication that explicitly supports the metadata record (rather than just providing context), this constitutes a qualified provenance reference. Where this information is present, at least one declaration is sufficient to pass this metric. The overall level of FAIRness under R1.2 increases as additional provenance dimensions are satisfied; using multiple metrics for R1.2 can help create a detailed picture of reusability. If the record is linked to an object of any of these types: ScholarlyArticle, Thesis, Book, Chapter or CreativeWork; it will pass; otherwise, the test will fail.

API Definition

This metric evaluates whether the metadata retrieved from the provided URI contains an identifier that satisfies the FAIRsharing definition of guaranteed global uniqueness, as aligned with the EOSC PID Policy. Note that it assesses the metadata retrieved from the URI rather than the URI itself. During assessment, the provided URI is resolved in accordance with FAIRsharing’s identifier resolution best practices. If the record contains DOI or ARK identifiers it will pass. If any identifier URLs can be determined as globally unique via FAIRsharing data the test will also pass. Otherwise, it will fail.

API Definition

R1.1 requires that metadata be released with a clear and accessible data usage licence. The purpose of this principle is to ensure that reuse conditions are explicitly stated and legally unambiguous. This test evaluates whether there is at least one licence declared at the database level in the FAIRsharing registry record associated with the identifier under evaluation.

API Definition