FAIR Champion

This assessor is a Python implementation of selected FAIR Core Tests used by FAIR Champion. It runs on supplied metadata without Ruby or network access.

Supported versions

version="0.5.12" pins the Core Tests rules. It is not the Champion web application's version. Harvester definitions provide the identifier patterns and metadata predicates: the named relationships in RDF. The library prepares these from pinned source files; it does not run the online harvester.

Assess metadata

from fair_offline_assessor import Assessor

result = Assessor("FAIR_CHAMPION", version="0.5.12").assess(
    metadata={
        "@context": "https://schema.org",
        "@type": "Dataset",
        "identifier": "10.1234/example",
        "license": "https://creativecommons.org/publicdomain/zero/1.0/",
    },
    target_identifier="10.1234/example",
    metadata_url="https://example.org/metadata",
)

for check in result.tests:
    print(check.id, check.outcome)

These arguments describe different things. A dataset DOI can be the target while its metadata document is hosted at a separate URL.

Metadata

Supply JSON-LD as a dictionary, an array of dictionaries or JSON text. Leave metadata_format unset or use json-ld. Other formats are not supported by this Champion version.

Champion checks the RDF relationships expressed by the JSON-LD. It accepts any node type and does not apply F-UJI's dataset-selection rules. A bare JSON key such as license needs a context defining its meaning before graph checks can use it. The bundled Schema.org context is version 30.0. Supply other contexts using local_contexts; a context explains terms but does not prove that their URLs resolve.

Without subject, the metadata must contain at most one nonempty graph. With subject, Champion uses the whole graph containing that node's outgoing statements, including other nodes in that graph. Named graphs remain separate. A missing subject or a subject appearing in multiple graphs is indeterminate for dependent checks. Valid empty metadata is usable evidence and can fail checks.

What can run offline

The first six rows cover 13 checks. The two conditional checks can decide some cases locally; they are not fully supported offline. All 16 checks remain visible in the response. Actual coverage depends on the supplied evidence.

Rules retain the pinned source's order and query behaviour. For example, licence checks use the first value per supported predicate. Some distribution/DCAT queries leave a variable unbound and therefore yield no data identifier. The Python port preserves that behaviour. Expected decisions were reviewed against source; equivalence was not established by running the Ruby implementation.

Results

The common response contains 16 checks grouped by 13 upstream metric identifiers. It assigns no numerical scores, FAIR percentage or maturity levels.

Metric summaries use this library's rule: an error takes precedence, then an indeterminate result. Otherwise, unanimous pass/fail results keep that outcome; mixed passes and failures become partial. This is not Champion benchmark scoring.

raw contains the Python port's FTR JSON-LD results, using the FAIR Test Registry vocabulary to describe each test, outcome, execution and target. These identify the offline implementation and omit online service endpoints. A check that errors has no raw entry. ftr:completion describes execution completion, not a FAIR score.

Pin the library and its dependencies as well as the assessor version to reproduce decisions. Raw execution UUIDs and timestamps change between runs, so complete responses are not byte-identical.

Input problems

Read diagnostics alongside each check's reason_code and message.

Input problems affect only checks needing that evidence. For example, a bare DOI can still settle preservation when the metadata is invalid. Unexpected execution errors are separate from failed FAIR checks.