Note — this repo is being renamed from datacite4.6-jsonld to datacite-metadata-toolkit to better reflect its scope (now covers DataCite 4.6 + 4.7, JSON Schema profiles, XML conversion, and crosswalk mappings — not just JSON-LD).

This repository provides machine-readable linked-data resources and tooling for the DataCite Metadata Schema (currently versions 4.6 and 4.7): RDF class and property definitions, controlled vocabulary terms as resolvable IRIs, JSON Schema validation profiles, an XML-to-JSON conversion script, and SKOS / JSKOS / SSSOM crosswalk mappings to external vocabularies (Schema.org, DCTERMS, DCAT-AP, Wikidata).

It is the source of truth for the DataCite linked-data namespace. For the TIB/W3ID publication route, this repository generates a reviewable production-namespace/ bundle that can be synced to TIBHannover/datacite-metadata-toolkit. The TIB toolkit fork then supplies the flat publication repository, TIBHannover/datacite, which is the GitHub Pages backend for the W3ID namespace. Do not edit the publication repo directly — all generated namespace changes start here or in TIBHannover/datacite-metadata-toolkit.

The key folders are:

The staging namespace is rooted at https://schema.stage.datacite.org/linked-data/. Every file in rdf-vocabulary-staging/ and validation-and-conversion/schemas/schema-profiles/ declares an $id (JSON Schema) or @id (JSON-LD) whose URL path mirrors its location on disk, so a file's canonical IRI is predictable from its folder:

The GitHub Pages deploy publishes this layout so the IRIs resolve to both human-readable HTML pages and machine-readable JSON-LD. generate-production-namespace.sh creates the public namespace bundle for the planned TIB publication setup:

In that setup, RDF identifiers use w3id, while GitHub Pages serves the concrete files. For example, the canonical term IRI https://w3id.org/tib/datacite/vocab/resourceTypeGeneral/Dataset resolves through w3id to the file served at https://tibhannover.github.io/datacite/vocab/resourceTypeGeneral/Dataset.jsonld.

Two relatedItem sub-properties reuse the controlled vocabularies of other DataCite properties — per spec, not as parallel vocabularies. The JSON-LD context (rdf-vocabulary-staging/context/fullcontext.jsonld) reflects this by pointing both @vocab bases at the canonical scheme directories:

This means a value like Dataset appearing under relatedItemType resolves to the same SKOS Concept IRI as it would under resourceTypeGeneral (…/vocab/resourceTypeGeneral/Dataset). Consumers distinguish the two usages by the predicate (property:relatedItemType vs property:resourceTypeGeneral), not the object. This eliminates the maintenance hazard of keeping two parallel vocabularies in sync as new values are added (e.g. 4.7's Poster/Presentation automatically apply to both fields).

Three related fields are open lists per spec — values are free text, not constrained to a controlled vocabulary. The context types them as xsd:string:

The DataCite metadata schema evolves over time (4.6, 4.7, …). This section explains how the linked-data vocabulary handles that change, so consumers always know exactly what they are pointing at.

There are three kinds of artifact, and they behave differently:

A separate pointer file, dist/datacite-current.jsonld, is a small machine-readable record that simply names which release is currently the default.

Key consequence — version provenance. Because canonical term IRIs are stable, a machine cannot tell which DataCite schema version a term was used under from the IRI alone. If you dereference …/property/subject, you get its current meaning. If exact provenance matters (was this record built against 4.6 or 4.7?), the consuming system must store that separately — either the schema version string (e.g. 4.6) or the versioned snapshot IRI (e.g. …/dist/datacite-4.6.jsonld).

Several community members have asked for version-specific IRIs for individual terms (so a term carries its release inside its own identifier). We deliberately do not do this:

• Identifier explosion. Versioning every term on every release would create thousands of near-duplicate IRIs, and tools that reason about sameAs / relatedTo would have to reconcile all of them.
• Aligns with DC / DCTERMS. The established practice is to treat each major change as a new ontology version, not as new per-term IRIs.
• Forward-compatible. Frozen distributions don't rule out per-term versioned IRIs later; if a strong need emerges they can be layered on without breaking any existing stable IRI.

These are easy to conflate but are independent:

1. Which version of an external subject vocabulary was used? (e.g. UAT 5.1, AGROVOC) — expressed in the Subject property's schemeUri when that vocabulary offers a versioned IRI. This is about other people's vocabularies, not DataCite's.
2. Which version of the DataCite schema was used? — a separate concern, captured by the versioned distribution / schema-version context described above.

See also Version History for what changed in each release.

rdf-vocabulary-staging/manifest/datacite-4.6.json is a versioned index of every defined class, property, and vocabulary term. Start there to discover what is available.

Individual term files follow a predictable structure:

• Class files (class/Resource.jsonld) — define the IRI, rdf:type, rdfs:label, and rdfs:comment for a DataCite entity.
• Property files (property/identifier.jsonld) — define the IRI and (where applicable) domain/range for a DataCite metadata field.
• Vocab term files (vocab/resourceTypeGeneral/Dataset.jsonld) — define a controlled term with skos:prefLabel, skos:definition, skos:inScheme, and optional skos:closeMatch mappings.

rdf-vocabulary-staging/context/fullcontext.jsonld maps DataCite-style compact JSON keys to their full IRIs. Reference it in your JSON-LD documents:

{
  "@context": "https://schema.stage.datacite.org/linked-data/context/fullcontext.jsonld",
  "@type": "Resource",
  "identifier": "10.1234/example",
  "creator": [{ "creatorName": "Smith, Jane" }]
}

validation-and-conversion/scripts/validate_xml.rb validates an XML file against the DataCite XSD schema. Requires Ruby.

validation-and-conversion/scripts/convert.py parses a DataCite XML file and produces a JSON payload matching the DataCite REST API structure (a data.attributes envelope). Python 3 only — no external packages required.

python3 validation-and-conversion/scripts/convert.py \
    validation-and-conversion/examples/datacite-example-full-v4.xml \
    --output record.json

validation-and-conversion/scripts/validate.js validates an NDJSON file containing JSKOS mappings or concept records using the jskos-validate package.

npm install jskos-validate
node validation-and-conversion/scripts/validate.js mappings/jskos-mappings.json

Generate the public TIB/w3id namespace bundle:

npm run build:production-namespace
# Output is written to production-namespace/

The default command rewrites staging IRIs from https://schema.stage.datacite.org/linked-data/ to the canonical namespace https://w3id.org/tib/datacite/, prepares generated HTML links for the GitHub Pages project path /datacite, and writes a production-specific README into the generated bundle. It also writes CHECKSUMS.sha256 and manifest/bundle-integrity.json so the file count and bundle checksum can be reviewed. The generated bundle is committed in this repository first so it can be reviewed and then synced to TIBHannover/datacite-metadata-toolkit; publication to TIBHannover/datacite happens from that TIB fork.

The production bundle intentionally does not own publication-root files such as .nojekyll, LICENSE, or the root index.html; those belong to TIBHannover/datacite.

To override the defaults:

SOURCE_NAMESPACE="https://schema.stage.datacite.org/linked-data/" \
CANONICAL_NAMESPACE="https://w3id.org/tib/datacite/" \
PAGES_BASE_PATH="/datacite" \
PUBLICATION_BASE_URL="https://tibhannover.github.io/datacite/" \
DST="production-namespace" \
bash rdf-build-scripts/generate-production-namespace.sh

Once deployed, each profile is fetchable at its $id URL — e.g. https://schema.stage.datacite.org/linked-data/schema-profiles/integrated.json — so validators can resolve $refs remotely. You can also validate against a local copy:

npx ajv-cli validate \
    -s validation-and-conversion/schemas/schema-profiles/integrated.json \
    -d your-metadata-record.json

See the Schema Profiles section below for which profile to choose.

The mappings/ folder provides four complementary views of how DataCite terms align with external vocabularies. All four files use the same canonical IRI scheme: subject IRIs resolve to the linked-data namespace (https://w3id.org/tib/datacite/{property,class,vocab/<scheme>}/<name>) and Schema.org targets use the HTTPS form (https://schema.org/<name>). Tools can merge any subset of these files into a single RDF graph without IRI conflicts.

• SKOS_crosswalks.jsonld — SKOS-predicate mappings (skos:exactMatch, skos:closeMatch, etc.) to Schema.org, DCAT, DCTERMS, and Wikidata, embedded directly in the vocabulary JSON-LD. Uses CURIE prefixes datacite-prop:, datacite-class:, datacite-vocab:.
• datacite-schemaorg.sssom.tsv — machine-readable SSSOM mapping set from DataCite 4.6 properties and controlled vocabulary terms to Schema.org only. Suitable for automated alignment pipelines and SSSOM-aware tools.
• datacite-dcterms.sssom.tsv — companion SSSOM mapping set strictly limited to DataCite terms with no adequate Schema.org equivalent (currently four dateType values — Accepted, Submitted, Valid, Withdrawn — and the relationType pair IsReplacedBy / Replaces), mapped to DCTERMS (Dublin Core Terms). Overlap with the Schema.org SSSOM file is excluded by design — see that file for DataCite terms that have both Schema.org and DCTERMS targets.
• jskos-mappings.json — the same mappings in JSKOS format for use with Cocoda and compatible mapping registries.

The integrated profile bundles five concerns into one self-contained file:

• Root attributes schema — structure and validation of data.attributes (creators, titles, publisher, relatedIdentifiers, …), mirroring the REST API. additionalProperties: false for strict client-side validation.
• $defs enumerations — every controlled vocabulary (resourceTypeGeneral, relationType, descriptionType, contributorType, etc.) inlined. Each term has an iriMap entry pointing to its canonical staging IRI (…/linked-data/vocab/<scheme>/<term>), so the same JSON can be validated and exported as RDF without re-mapping.
• profile.@context — a complete JSON-LD context mapping DataCite keys to RDF predicates (creator → schema:creator, identifier → dcterms:identifier, etc.). Embedded so consumers can generate RDF graphs without an external context fetch.
• responseProfile and submitProfile — JSON:API envelope validators for GET responses and POST/PUT submissions, embedded so a single file handles both directions.
• exportProfile — rules for converting validated JSON into RDF/JSON-LD, including language-tag handling and DOI normalization to https://doi.org/<doi>.

rdf-build-scripts/synCheck.py verifies that the controlled-list $defs inside datacite4.6-profile.json stay in sync with the published vocab term files under rdf-vocabulary-staging/vocab/. Run it whenever you add or remove vocabulary terms.

The release pipeline is a three-step process: detect → review → apply. All three steps have both a GitHub Actions workflow (for CI) and a local Node.js command (for development).

• Node.js 20+
• Apache Jena (riot on PATH) — only needed for build-distribution / release-snapshot, which generate .ttl and .rdf files.

What it does: Fetches the official DataCite schema release page, compares it to the local manifest versions, and writes a machine-readable JSON plan plus a Markdown report under reports/.

Via GitHub Actions:

1. Go to Actions → Detect DataCite Release → Run workflow
2. Optionally fill in version (e.g. 4.7) and release_date (e.g. 2026-03-03). Leave both blank to auto-detect the next release.
3. Enable Commit plan files (default: on) to push the plan to the branch automatically.

Locally:

# Auto-detect next release
node rdf-build-scripts/detect-datacite-release.js

# Target a specific version
node rdf-build-scripts/detect-datacite-release.js --version 4.7 --release-date 2026-03-03

Output files:

Open reports/release-import-plan-4.7.json. Each detected change has a "status" field:

Change every "proposed" entry you want to apply to "apply". Entries left as "proposed" or "manual" are skipped.

Typical 4.6 → 4.7 plan looks like:

{
  "targetVersion": "4.7",
  "releaseDate": "2026-03-03",
  "changes": [
    {
      "id": "controlled-list-values-added:resourceTypeGeneral:4.7",
      "module": "controlled-list",
      "kind": "controlled-list-values-added",
      "status": "apply",       // ← set to "apply" to include
      "summary": "Add resourceTypeGeneral terms: Poster, Presentation"
    },
    {
      "id": "controlled-list-values-added:relatedIdentifierType:4.7",
      "module": "controlled-list",
      "status": "apply",
      "summary": "Add relatedIdentifierType terms: RAiD, SWHID"
    },
    {
      "id": "simple-property-added:relationTypeInformation:4.7",
      "module": "simple-property",
      "status": "apply",
      "summary": "Add simple property relationTypeInformation"
    }
  ]
}

What it does: Reads the approved plan, writes new vocab term files into rdf-vocabulary-staging/, updates scheme files and context/fullcontext.jsonld, then builds a full versioned snapshot (manifest + dist bundles + index pages).

Via GitHub Actions:

1. Go to Actions → Apply DataCite Release Plan → Run workflow
2. Set plan_path to reports/release-import-plan-4.7.json
3. Leave module toggles at their defaults unless you want to selectively run only some modules
4. Enable Commit generated files (default: on) to push all outputs back to the branch

Locally:

node rdf-build-scripts/apply-datacite-release-plan.js \
  --plan reports/release-import-plan-4.7.json \
  --set-current

What gets written:

To rebuild the manifest and distribution for an existing version — for example after manually editing vocab files — use the snapshot workflow directly:

Via GitHub Actions: Run Build Versioned Snapshot with version (e.g. 4.6) and an optional release_date.

Locally:

node rdf-build-scripts/release-snapshot.js --version 4.6

This runs: manifest-sync --write --validate → build-distribution → update-current-pointers → generate-index-pages → update-root-index.

All scripts run from the repository root and auto-detect rdf-vocabulary-staging/ as the vocabulary root.

Module IDs (for --modules CSV in apply):

rdf-vocabulary-staging/manifest/datacite-current.json points at the current published version (currently 4.7). Each release leaves a versioned manifest, an apply report under reports/, and a release-matrix delta under rdf-vocabulary-staging/manifest/release-matrix-<prev>-<next>.json.

Applied on top of 4.6 via the Detect → Review → Apply pipeline. Changes:

• resourceTypeGeneral: adds Poster, Presentation
• relatedIdentifierType: adds RAiD, SWHID
• relationType: adds Other
• New property relationTypeInformation (additional information about the selected relationType, applies to both relatedIdentifier and relatedItem)
• descriptionType=SeriesInformation is soft-deprecated — the spec directs new content to encode series metadata via the structured relatedItem property with relationType=IsPublishedIn instead. The SeriesInformation term remains valid for backwards compatibility; see vocab/descriptionType/SeriesInformation.jsonld for the supersession note.

See reports/release-apply-4.7.md and rdf-vocabulary-staging/manifest/release-matrix-4.6-4.7.json for the full apply record.

Adds or updates these controlled values, all represented in the vocabulary files:

4.6 also introduced the subject sub-property classificationCode to support subject schemes such as ANZSRC that lack per-term valueURIs.

JSON-LD — A JSON-based format for linked data. An @context maps compact JSON keys to globally unique IRIs so different systems interpret the same key identically.

SKOS — The W3C Simple Knowledge Organization System. Used here to define controlled vocabulary terms and to map DataCite terms to equivalent terms in Schema.org, DCAT, and other vocabularies.

JSKOS — A JSON-based serialization of SKOS, used for interoperable mapping registries such as Cocoda.

SSSOM — The Simple Standard for Sharing Ontology Mappings. A TSV-based format that records each alignment between two terms with a predicate, justification, and provenance. The .sssom.tsv files in mappings/ can be loaded directly by tools such as sssom-py or imported into ontology alignment pipelines.

JSON Schema profile vs JSON-LD context — The schema profiles (validation-and-conversion/schemas/schema-profiles/) check the structure of a JSON record (required fields, allowed values, data types). The JSON-LD context (rdf-vocabulary-staging/context/fullcontext.jsonld) gives those fields semantic meaning as linked data. Both can be applied to the same JSON document.

Staging vs production namespace — Source vocabulary files use the staging host https://schema.stage.datacite.org/linked-data/. The TIB/W3ID production namespace (https://w3id.org/tib/datacite/) is generated separately via generate-production-namespace.sh into production-namespace/.

• DataCite Metadata Schema 4.6 — https://schema.datacite.org/meta/kernel-4.6/
• DataCite REST API — https://support.datacite.org/docs/api
• DataCite 4.6 Release Notes — https://support.datacite.org/docs/datacite-metadata-schema-46-release-notes
• JSON-LD specification — https://json-ld.org/
• JSON Schema specification — https://json-schema.org/
• SKOS Primer — https://www.w3.org/TR/skos-primer/
• JSKOS format — https://gbv.github.io/jskos/
• SSSOM specification — https://mapping-commons.github.io/sssom/