Crosswalk reference

Which CodeMeta concept each supported format maps onto, how strictly the two are expected to agree, and where the mapping came from.

See consistency.md for the model behind these tables, and adapters.md for how to add a format.

This is developer reference. If you are here because a consistency check failed, diagnostics and the FAQ are the faster route.

Comparison rules

Rule	Violated when
equal	The two sides are not equivalent in either direction.
subset	The source holds a value the anchor does not. The reverse is fine: codemeta.json is allowed to be richer.
overlap	The two sides have nothing in common at all.
informational	Never. Differences are reported without judgement.

Mapping provenance

Origin	Meaning
codemeta-upstream	Taken from the CodeMeta project’s own crosswalk tables.
mixed	Based on an upstream crosswalk and extended here.
rs-metadata	Defined here, because no adequate upstream mapping exists.

Provenance travels with every consistency finding in the JSON report, so a reader can always tell which kind of mapping produced it.

bio.tools metadata

• Mapping id: biotools

• Format version: 3.3.0

• Provenance: upstream crosswalk, extended by rs-metadata

• Upstream table: codemeta/codemeta

• Retrieved: 2026-09-02

Record-level correspondences follow CodeMeta’s bio.tools crosswalk. That table still names the pre-3.3 labels.language and labels.license paths; biotoolsSchema 3.3 flattened both to language and license, so the current paths are used here. Repository links, issue trackers, EDAM operations, tool types, downloads, documentation and credit roles are unambiguous extensions defined by rs-metadata. Comparison policy is also rs-metadata’s.

CodeMeta concept	Source field	Comparison	Rule	Severity
applicationCategory	toolType	text	must overlap	warning
citation	publication[].doi	doi	source ⊆ anchor	info
codeRepository	link[type=Repository].url	uri	must overlap	warning
contributor	`credit[typeRole=Contributor	Developer	Documentor]`	people
description	description	text	reported only	info
developmentStatus	maturity	best-effort	reported only	info
downloadUrl	download[].url	uri	reported only	info
issueTracker	link[type=Issue tracker].url	uri	source ⊆ anchor	warning
keywords	topic[].term	text	must overlap	warning
license	license	spdx	must be equal	error
maintainer	`credit[typeRole=Maintainer	Primary contact]`	people	source ⊆ anchor
name	name	name	must be equal	error
operatingSystem	operatingSystem	text	must overlap	warning
programmingLanguage	language	language	must overlap	warning
provider	credit[typeRole=Provider]	people	source ⊆ anchor	info
schema:featureList	`function[].operation[].uri	term`	text	must overlap
softwareHelp	documentation[].url	uri	source ⊆ anchor	info
url	homepage	uri	must be equal	warning
version	version	version	must overlap	warning

Notes

• description — bio.tools limits descriptions to 1,000 characters, so the registry text may be a shortened version of the CodeMeta abstract.

• developmentStatus — bio.tools uses Emerging, Mature and Legacy, while CodeMeta records a repostatus.org term. The vocabularies do not map one to one.

• keywords — The upstream crosswalk relates CodeMeta keywords to EDAM topic labels. Only a completely disjoint set is treated as drift.

• schema:featureList — bio.tools operations and the LUMC feature list both use EDAM Operation identifiers. A label is used when an operation has no URI.

• version — A bio.tools record may list several versions. The current CodeMeta release must appear in that list, but older versions are allowed.

Rust package manifest

• Mapping id: cargo

• Format version: unversioned

• Provenance: upstream crosswalk, extended by rs-metadata

• Upstream table: codemeta/codemeta

• Retrieved: 2026-08-20

Field correspondences follow the CodeMeta project’s own Cargo crosswalk. The comparison policy is rs-metadata’s, as is the handling of fields inherited from a workspace (version.workspace = true), which state no value in this file and are skipped rather than compared.

CodeMeta concept	Source field	Comparison	Rule	Severity
applicationCategory	package.categories	text	must overlap	info
author	package.authors	people	source ⊆ anchor	warning
codeRepository	package.repository	uri	must be equal	error
description	package.description	text	reported only	info
keywords	package.keywords	text	must overlap	warning
license	package.license	spdx	must be equal	error
name	package.name	name	must be equal	warning
programmingLanguage	package	language	must overlap	warning
softwareHelp	package.documentation	uri	source ⊆ anchor	warning
softwareRequirements	dependencies	dependency-set	reported only	info
url	package.homepage	uri	must be equal	warning
version	package.version	version	must be equal	error

Notes

• applicationCategory — crates.io categories are a controlled vocabulary of application areas, which is what applicationCategory describes. The two vocabularies do not correspond term for term, so a difference is shown rather than judged.

• description — Cargo’s description is the one-line summary crates.io shows, which is shorter than CodeMeta’s abstract by design. Shown, never judged.

• license — Cargo requires an SPDX expression here, so this is the one companion whose license field is already in the form CodeMeta wants.

• name — Compared with separators removed: a crate published as my-tool and a record calling it MyTool are the same software.

• programmingLanguage — A Cargo.toml is prima facie evidence that the crate is written in Rust; this catches a codemeta.json that forgot to say so.

• softwareRequirements — Never an error. codemeta.json is not obliged to enumerate every crate a build pulls in. Only genuinely incompatible pins are reported.

Citation File Format

• Mapping id: cff-1.2.0

• Format version: 1.2.0

• Provenance: CodeMeta upstream crosswalk

• Upstream table: https://github.com/codemeta/codemeta/blob/master/crosswalks/Citation File Format 1.2.0.csv

• Retrieved: 2026-08-14

Field correspondences are taken from the CodeMeta project’s own CFF 1.2.0 crosswalk table. The comparison rules and severities are rs-metadata’s, since a crosswalk states which concepts correspond but not how strictly two files are expected to agree about them.

CodeMeta concept	Source field	Comparison	Rule	Severity
author	authors	people	must be equal	error
citation	preferred-citation.doi	doi	source ⊆ anchor	info
codeRepository	repository-code	uri	must be equal	error
datePublished	date-released	date	must be equal	error
description	abstract	text	must be equal	warning
downloadUrl	repository-artifact	uri	must be equal	warning
identifier	doi, identifiers	identifier	source ⊆ anchor	error
keywords	keywords	text	must overlap	warning
license	license	spdx	must be equal	error
maintainer	contact	people	source ⊆ anchor	info
name	title	text	must be equal	error
referencePublication	preferred-citation	doi	source ⊆ anchor	warning
sameAs	identifiers[type=url]	best-effort	source ⊆ anchor	info
softwareRequirements	references	—	not comparable	—
url	url	uri	must be equal	warning
version	version	version	must be equal	error

Notes

• author — Compared semantically: ORCIDs first, then family name with initials accepted as abbreviations of given names. Order is not significant to the comparison, though CFF and CodeMeta both treat author order as meaningful for citation.

• citation — The work CFF says to cite instead of the software itself. Recorded alongside referencePublication, which is the same DOI under the concept the profile speaks to.

• description — Reported as a warning rather than an error. Prose is routinely reworded in one file and not the other, and that is a documentation lapse rather than contradictory metadata.

• identifier — Every identifier claimed in CITATION.cff must also appear in codemeta.json, which is the canonical record. The reverse is not required: codemeta.json may list identifiers CFF has no field for.

• keywords — Keyword lists legitimately differ in detail, so only a completely disjoint pair is reported. That pattern nearly always means one file was filled in for a different project.

• name — The software title is one of the three fields that must agree between the two files.

• sameAs — Another address for this same work. Informational: CFF permits several and CodeMeta expects one canonical URL, so a difference is not a fault.

• softwareRequirements — CFF references is a bibliography of arbitrary works, not a dependency list. The upstream crosswalk relates it to softwareRequirements, but the mapping loses so much that any comparison would be meaningless.

• version — A version skew between the two files means one of them describes a different release than the other, which breaks citation.

Dockerfile (OCI image labels)

• Mapping id: dockerfile-oci

• Format version: unversioned

• Provenance: defined by rs-metadata

• Upstream table: opencontainers/image-spec

• Retrieved: 2026-08-19

The label names are the OCI image specification’s pre-defined annotation keys; the correspondence to CodeMeta is rs-metadata’s own. Keys describing the image build rather than the software — created, revision, ref.name, base.name, base.digest — are not mapped. Labels whose value interpolates a build argument are not read at all, since this file does not determine them.

CodeMeta concept	Source field	Comparison	Rule	Severity
author	org.opencontainers.image.authors	people	source ⊆ anchor	info
codeRepository	org.opencontainers.image.source	uri	must be equal	error
copyrightHolder	org.opencontainers.image.vendor	name	source ⊆ anchor	info
description	org.opencontainers.image.description	—	not comparable	—
license	org.opencontainers.image.licenses	spdx	must be equal	error
name	org.opencontainers.image.title	name	must be equal	warning
softwareHelp	org.opencontainers.image.documentation	uri	source ⊆ anchor	info
url	org.opencontainers.image.url	uri	must be equal	warning
version	org.opencontainers.image.version	version	must be equal	warning

Notes

• author — The specification calls this field “contact details”, so it usually names whoever maintains the image rather than everyone who wrote the software. Subset, and only informational.

• description — The label is a short registry blurb, while CodeMeta’s description is the full abstract. Comparing them would differ on nearly every image.

• license — The specification requires an SPDX expression, so a difference here is a real contradiction rather than a formatting difference.

• version — A warning rather than an error: image labels are commonly set from a CI tag at build time, so a literal value here can legitimately lag the repository between releases.

GitHub repository metadata

• Mapping id: github

• Format version: unversioned

• Provenance: upstream crosswalk, extended by rs-metadata

• Upstream table: codemeta/codemeta

• Retrieved: 2026-08-20

Field correspondences follow the CodeMeta project’s own GitHub crosswalk, which is written against the REST API’s repository object. Three of them are read from a different field than upstream names, each noted below: upstream’s full_name, languages_url and issues_url are respectively an owner-qualified name, an API endpoint and a URL template, none of which hold a value comparable to what codemeta.json carries. The comparison policy is rs-metadata’s.

CodeMeta concept	Source field	Comparison	Rule	Severity
codeRepository	html_url	uri	must be equal	error
dateCreated	created_at	best-effort	must be equal	info
dateModified	updated_at	best-effort	must be equal	info
description	description	text	reported only	info
issueTracker	html_url + "/issues"	uri	must be equal	info
keywords	topics	text	must overlap	warning
license	license.spdx_id	spdx	must be equal	warning
name	name	name	must be equal	warning
programmingLanguage	language	language	must overlap	info
url	homepage	uri	must be equal	warning

Notes

• codeRepository — The one field GitHub is authoritative about. If codemeta.json points somewhere else, it is describing a different repository.

• dateCreated — GitHub timestamps to the second while a metadata file records a day, so these are compared on the calendar day.

• dateModified — updated_at moves whenever the repository changes, so codemeta.json will normally lag it. Shown for context, never judged as an error.

• description — GitHub’s description is the one-line blurb shown under the repository name, while CodeMeta’s is the full abstract. Shown, never judged.

• issueTracker — Upstream maps issues_url, which is the API template .../issues{/number} rather than the page a maintainer would record. The tracker is the repository URL plus /issues, and is read only when the repository has issues enabled.

• keywords — GitHub topics are lowercase and hyphenated by convention, so these are compared case-insensitively like all other keyword sets.

• license — GitHub detects this from the LICENSE file rather than being told it, so a difference can mean either file is wrong. A warning rather than an error for that reason. NOASSERTION, which GitHub reports when its detector recognized nothing, is not compared at all.

• name — Read from name rather than upstream’s full_name, which is owner/repo and so never equals the software’s own name.

• programmingLanguage — Read from language, the language GitHub detected, rather than upstream’s languages_url, which is an endpoint to call rather than a value. GitHub reports only the predominant language, so this is an overlap check and never an error.

Julia project metadata

• Mapping id: julia-project

• Format version: unversioned

• Provenance: upstream crosswalk, extended by rs-metadata

• Upstream table: https://github.com/codemeta/codemeta/blob/master/crosswalks/Julia Project.csv

• Retrieved: 2026-08-20

CodeMeta publishes a Julia Project.toml crosswalk, and the correspondences below follow it. Two deviations are deliberate and noted per field: the upstream table maps version to CodeMeta’s softwareVersion, while this profile uses version throughout, and its identifier correspondence is recorded but not compared. The comparison policy — strategy, rule and severity — has no upstream equivalent and is rs-metadata’s own.

CodeMeta concept	Source field	Comparison	Rule	Severity
author	authors	people	source ⊆ anchor	warning
identifier	uuid	—	not comparable	—
name	name	name	must be equal	warning
programmingLanguage	uuid	language	must overlap	warning
runtimePlatform	compat.julia	text	reported only	info
softwareRequirements	compat	dependency-set	reported only	info
version	version	version	must be equal	error

Notes

• author — Julia accepts both "Name <email>" strings and tables following the Citation File Format’s person schema, so this normalizes the same way CITATION.cff does.

• identifier — Upstream maps Julia’s uuid to CodeMeta’s identifier, and it is a genuine package identifier. But codemeta.json’s identifier is the DOI that identifies the software to registries and archives, so comparing a UUID against a DOI would report a difference on every correct pair of files.

• name — Compared with separators removed, since a package registered as ReadAligner may be written read-aligner elsewhere.

• programmingLanguage — A Project.toml with a uuid is prima facie evidence that the package is written in Julia; this catches a codemeta.json that forgot to say so. Not an upstream correspondence — the crosswalk leaves it blank.

• runtimePlatform — The [compat] entry for julia is the language runtime rather than a dependency, which is what upstream’s runtimePlatform correspondence records.

• softwareRequirements — Read from [compat] rather than [deps], because [deps] carries only UUIDs while [compat] carries the version bounds worth comparing.

npm package metadata

• Mapping id: package-json

• Format version: package.json

• Provenance: CodeMeta upstream crosswalk

• Upstream table: codemeta/codemeta

• Retrieved: 2026-08-14

Field correspondences follow the CodeMeta project’s NodeJS crosswalk. The handling of npm’s shorthand repository forms (user/repo, github:user/repo, git+https://...git) is an rs-metadata addition.

CodeMeta concept	Source field	Comparison	Rule	Severity
author	author, contributors	people	source ⊆ anchor	warning
codeRepository	repository	uri	must be equal	error
contributor	contributors	people	source ⊆ anchor	info
description	description	text	reported only	info
issueTracker	bugs	uri	must be equal	warning
keywords	keywords	text	must overlap	warning
license	license	spdx	must be equal	error
name	name	name	must be equal	warning
operatingSystem	os	text	must overlap	info
processorRequirements	cpu	best-effort	must overlap	info
runtimePlatform	engines	text	reported only	info
softwareRequirements	dependencies, peerDependencies	dependency-set	reported only	info
softwareSuggestions	devDependencies / optionalDependencies	dependency-set	reported only	info
url	homepage	uri	must be equal	warning
version	version	version	must be equal	error

Notes

• author — npm’s single author plus contributors is compared against CodeMeta’s author and maintainer taken together, because the two ecosystems draw the line between the roles differently.

• contributor — npm draws a line between author and contributors that codemeta.json need not draw the same way, so someone listed here satisfies either.

• description — npm descriptions are one-liners shown in search results, so a difference from the CodeMeta abstract is expected and merely reported.

• name — npm names are lowercase and may be scoped (@lumc/mytool); the comparison ignores the scope and separators.

• softwareSuggestions — What the package can use but does not need to run, which is the distinction CodeMeta draws. Never an error.

Python project metadata (PEP 621)

• Mapping id: pyproject-pep621

• Format version: PEP 621

• Provenance: upstream crosswalk, extended by rs-metadata

• Upstream table: https://github.com/codemeta/codemeta/blob/master/crosswalks/Python PKG-INFO.csv

• Retrieved: 2026-08-14

CodeMeta publishes crosswalks for Python PKG-INFO and setuptools, but not for PEP 621 itself. PEP 621’s [project] table is defined by reference to core metadata, so the field correspondences below follow the upstream PKG-INFO crosswalk. The project.urls label conventions, the handling of dynamic, and the PEP 639 license forms are rs-metadata additions with no upstream equivalent.

CodeMeta concept	Source field	Comparison	Rule	Severity
author	project.authors	people	source ⊆ anchor	warning
codeRepository	project.urls.Repository	uri	must be equal	error
description	project.description	—	not comparable	—
developmentStatus	project.classifiers "Development Status"	text	reported only	info
downloadUrl	project.urls.Download	uri	must be equal	info
issueTracker	project.urls.Issues	uri	must be equal	warning
keywords	project.keywords	text	must overlap	warning
license	project.license	spdx	must be equal	error
maintainer	project.maintainers	people	source ⊆ anchor	info
name	project.name	name	must be equal	warning
operatingSystem	project.classifiers "Operating System"	text	reported only	info
programmingLanguage	project.classifiers "Programming Language"	language	must overlap	warning
runtimePlatform	project.requires-python	text	reported only	info
softwareHelp	project.urls.Documentation	uri	source ⊆ anchor	warning
softwareRequirements	project.dependencies	dependency-set	reported only	info
url	project.urls.Homepage	uri	must be equal	warning
version	project.version	version	must be equal	error

Notes

• author — Subset rather than equality: packaging metadata commonly names only the current maintainer, while codemeta.json lists everyone who should be credited. Anyone named in pyproject.toml should still appear in the canonical record.

• description — PEP 621’s description is the one-line summary that corresponds to core metadata’s Summary, whereas CodeMeta’s description is the full abstract. Comparing them would report a difference on nearly every correctly written project.

• developmentStatus — Trove development-status classifiers and the repostatus.org vocabulary used by CodeMeta do not correspond one to one, so differences are shown but never judged.

• license — Handles the PEP 639 SPDX expression string and the older {text = "..."} table. {file = "LICENSE"} names a file rather than a license and is reported as not comparable.

• name — Compared with separators removed, because MyTool in codemeta.json and my-tool on PyPI are the same software named by two conventions.

• programmingLanguage — A pyproject.toml is prima facie evidence that the software is written in Python; this catches a codemeta.json that forgot to say so.

• runtimePlatform — The interpreter the software runs on, which is what npm’s engines and Julia’s compat.julia record for theirs. Recorded as Python >=3.11, matching how those two are written.

• softwareRequirements — Never an error. codemeta.json is not obliged to enumerate every dependency, and a partial list is not a contradiction. Only a package pinned to genuinely incompatible constraints in both files is reported as a conflict.

• version — Skipped entirely when the project declares dynamic = ["version"], since the value in the file is then not the version at all.

R package DESCRIPTION

• Mapping id: r-description

• Format version: R

• Provenance: upstream crosswalk, extended by rs-metadata

• Upstream table: https://github.com/codemeta/codemeta/blob/master/crosswalks/R Package Description.csv

• Retrieved: 2026-08-14

Field correspondences follow the CodeMeta project’s R Package Description crosswalk. Parsing of the Authors@R field, which holds R code rather than data, and the reconciliation of R’s version and license spellings are rs-metadata additions.

CodeMeta concept	Source field	Comparison	Rule	Severity
author	Authors@R [aut], Author	people	source ⊆ anchor	warning
codeRepository	URL	uri	must overlap	warning
contributor	[ctb] in Authors@R	people	source ⊆ anchor	info
datePublished	Date	date	must be equal	warning
description	Description	text	must be equal	warning
issueTracker	BugReports	uri	must be equal	warning
license	License	spdx	must overlap	warning
maintainer	Authors@R [cre], Maintainer	people	source ⊆ anchor	info
name	Package, Title	name	must overlap	warning
programmingLanguage	(implied by DESCRIPTION)	language	must overlap	warning
softwareRequirements	Depends, Imports	dependency-set	reported only	info
softwareSuggestions	Suggests	dependency-set	reported only	info
url	URL	uri	source ⊆ anchor	info
version	Version	version	must be equal	error

Notes

• codeRepository — R’s URL field holds a comma-separated list mixing the repository, the homepage and the documentation site, so only a complete absence of any match is reported.

• license — R license strings such as GPL-3 or MIT + file LICENSE do not map cleanly onto SPDX identifiers, so a partial match is accepted and a complete mismatch is only a warning.

• name — The upstream crosswalk maps CodeMeta name to Title, but codemetar, the tool most R authors use, writes Package there instead. Both are offered and a match against either is accepted, because the disagreement is between conventions rather than within a repository.

• url — CRAN packages routinely list the source repository and the documentation site together in URL without distinguishing them, so both concepts are read from it and both compare as subsets.

• version — R versions use a dash before the final component (1.2-3) where other ecosystems use a dot; the version strategy treats the two as equal.

Zenodo deposition metadata

• Mapping id: zenodo

• Format version: unversioned

• Provenance: upstream crosswalk, extended by rs-metadata

• Upstream table: codemeta/codemeta

• Retrieved: 2026-08-20

Field correspondences follow the CodeMeta project’s own Zenodo crosswalk. The contributor-role breakdown extends it: Zenodo’s roles are DataCite’s and are broader than CodeMeta’s, so a role with no CodeMeta equivalent is left unmapped rather than flattened into contributor. The comparison policy is rs-metadata’s.

CodeMeta concept	Source field	Comparison	Rule	Severity
author	creators	people	must be equal	error
codeRepository	related_identifiers[relation=isSupplementTo]	uri	must be equal	warning
contributor	`contributors[type=DataCurator	ProjectLeader	ProjectManager	ProjectMember
copyrightHolder	contributors[type=RightsHolder]	people	source ⊆ anchor	info
datePublished	publication_date	date	must be equal	warning
description	description	text	reported only	info
downloadUrl	related_identifiers[relation=isIdenticalTo]	uri	source ⊆ anchor	info
editor	contributors[type=Editor]	people	source ⊆ anchor	info
funding	grants	text	reported only	info
identifier	doi	doi	must be equal	error
keywords	keywords	text	must overlap	warning
license	license	spdx	must be equal	error
maintainer	contributors[type=ContactPerson]	people	source ⊆ anchor	info
name	title	name	must be equal	error
producer	contributors[type=Producer]	people	source ⊆ anchor	info
sponsor	contributors[type=Sponsor]	people	source ⊆ anchor	info
version	version	version	must be equal	error

Notes

• author — Equality rather than subset, unlike the packaging formats. Zenodo’s creators become the citation’s author list, so someone credited in codemeta.json but missing here will be missing from the citation.

• codeRepository — Zenodo has no repository field. The convention its crosswalk records is an isSupplementTo relation pointing at the code, which is what this reads.

• contributor — Zenodo uses DataCite’s role vocabulary, which is finer-grained than CodeMeta’s. The roles with no closer CodeMeta property land here.

• datePublished — Zenodo defaults this to the deposition date when it is absent, so a stale value here silently misdates the record.

• description — Zenodo renders this field as HTML, so it commonly carries markup that a plain CodeMeta description does not. Shown, never judged.

• funding — Zenodo writes a grant as a registry-prefixed id (10.13039/501100000780::283595), while CodeMeta’s funding is free text. The two rarely match literally, so differences are shown rather than judged.

• identifier — A reserved DOI in .zenodo.json is the identifier the archived record will carry, so it should be the one codemeta.json advertises.

• license — Zenodo accepts SPDX identifiers case-insensitively, and older records use lowercase Open Definition ids. Both normalize to the same value.

• name — The title Zenodo will publish. A mismatch here means the archived record names the software differently from its own repository.