DataCite Crosswalk Guide
How DataCite metadata terms line up with Schema.org, Dublin Core, DCAT and Wikidata, and how to read, use and improve the mapping files. No prior linked-data knowledge needed; every technical word is explained in the glossary.
The big picture
Repositories describe the same research outputs in different vocabularies. DataCite says creator, Schema.org says creator too, Dublin Core says dcterms:creator, and Wikidata uses numbered items. A crosswalk is a dictionary between them. Each entry is a mapping: "DataCite title is close to Dublin Core title".
A useful crosswalk gets three things right.
The four target vocabularies cover different needs: Schema.org for search engines, Dublin Core (DCTERMS) for libraries and repositories, DCAT for data catalogues, and Wikidata for the shared knowledge graph.
Reading a mapping
Every mapping is a triple: three parts that read like a sentence.
datacite-vocab:relationType/IsPartOfskos:closeMatchdcterms:isPartOfThe names are short forms called CURIEs. The prefix before the colon stands for the start of a web address, so dcterms:isPartOf means http://purl.org/dc/terms/isPartOf. Each mapping file lists its prefixes at the top.
One row of a mapping file
The mapping files use SSSOM, a standard spreadsheet format. This is the row above, column by column.
| Column | Value | What it tells you |
|---|---|---|
| subject_id | datacite-vocab:relationType/IsPartOf | The DataCite term |
| predicate_id | skos:closeMatch | How close the meanings are |
| object_id | dcterms:isPartOf | The term in the other vocabulary |
| mapping_justification | semapv:ManualMappingCuration | A person decided this by reading both definitions |
| subject_label, object_label | IsPartOf, isPartOf | Readable names for display |
| object_source_version | 2020-01-20 | Which release of the other vocabulary was checked |
| author_id, reviewer_id | orcid:0000-0003-1378-5495 | Who wrote and who checked the mapping |
| comment | Corresponding relationship with the same direction… | The reasoning, and any conditions |
Link strength
The predicate in the middle of each triple is the most important judgement in a mapping. It comes from SKOS, a W3C standard for vocabularies.
exactMatchInterchangeable everywhere. This crosswalk never uses it (see below).closeMatchNearly the same meaning. creator → schema:creatorbroadMatchTheir term is wider than DataCite's. title → schema:name, because a name can belong to anything.narrowMatchTheir term is narrower. size → schema:contentSize, which only means file size.relatedMatchConnected, but not the same kind of thing. publicationYear → dcterms:issued: a year versus a full date.Why no exactMatch
exactMatch is transitive: if creatorName exactly equals schema:name, and title exactly equals schema:name, software concludes that a person's name and a document's title are the same thing.
What the crosswalk does instead
It uses the weakest link that is still true. creatorName and title both get broadMatch to schema:name, which says each is a kind of name without making them equal to each other.
Link strengths in each mapping file
Bars share one scale, so their lengths compare directly.
Direction matters
DataCite relations are written from the point of view of the record you are describing. Other vocabularies sometimes point the other way. That is an inverse relation, and mapping it naively writes the fact backwards.
Opposite direction
"My dataset IsCitedBy that paper." Schema.org's citation points from the paper to the dataset. A direct mapping would state that the dataset cites the paper, so this pair is handled only by a conversion rule that flips the two ends.
Same direction
Dublin Core has matching pairs such as isPartOf and hasPart. "A IsPartOf B" becomes "A dcterms:isPartOf B", so these are mapped directly.
The automatic checks reject known wrong-direction pairs, such as Reviews → schema:reviews or IsCitedBy → dcterms:references.
Mappings and recipes
Two different statements are easy to confuse.
Correspondence
"These two terms mean similar things." This goes in the SSSOM mapping files.
Conversion rule
"When you translate a record, put this value there, under these conditions." This goes in the conversion/ recipes.
Example: DataCite's publicationYear holds just a year, such as 2024. Dublin Core's issued can hold a full date. The mapping file records that they are related. The recipe adds the instruction a converter needs: never invent a month or a day.
Every term has an outcome
The coverage register records one outcome for each of the 253 DataCite terms, per vocabulary. Nothing is silently left out.
"Recipe only" covers terms such as identifier-scheme values and geographic coordinates, which are carried along inside a converted record rather than matched to a single term. Wikidata is mostly out of scope because its mappings align concepts like "dataset" or "book", not record fields.
The files
Everything lives in the mappings/ folder of the toolkit. Use the file that fits your tool.
| File | What it is | Who it is for |
|---|---|---|
datacite-schemaorg.sssom.tsvdatacite-dcterms.sssom.tsvdatacite-dcat.sssom.tsvdatacite-wikidata.sssom.tsv | The mapping sets, one per vocabulary. These are the source; everything else is generated from them. | Mapping tools and anyone reviewing a mapping |
jskos-mappings.json | All mappings in JSKOS, with labels, vocabularies, author, date and notes. | Cocoda and jskos-server |
SKOS_crosswalks.jsonld | All mappings as linked data, with a label for every term. | Triple stores and RDF tools |
conversion/*.json | Recipes for translating real records. | Developers writing converters |
coverage/*.json | The outcome for every DataCite term. | Anyone checking completeness |
target-sources.json | Which release of each vocabulary was checked, with download addresses and fingerprints. | Anyone checking provenance |
Dublin Core terms that DCAT reuses, such as dcterms:title, appear in both the Dublin Core and DCAT files. In the combined JSKOS and SKOS files each mapping appears once, giving 225 unique mappings from 238 rows.
Permanent addresses
Every DataCite term has a permanent address under https://w3id.org/tib/datacite/. w3id holds no files. It forwards each request to wherever the files are hosted, currently GitHub Pages. If hosting ever moves, only the forwarding rules change and every published address keeps working.
https://w3id.org/tib/datacite/vocab/relationType/IsCitedBy…/vocab/relationType/IsCitedBy.ttl…/vocab/relationType/IsCitedBy.jsonldChoosing a format by what the requester asks for is called content negotiation. JSON-LD is the default; a program can ask for Turtle by sending Accept: text/turtle. Both hold exactly the same information.
The mapping files have permanent addresses too, for example https://w3id.org/tib/datacite/mappings/datacite-schemaorg.sssom.tsv. That address is also each file's official name, its mapping_set_id.
mappings/ addresses are being rolled out. Until then, use the JSON-LD address, or take the files directly from the toolkit repository.Try it yourself:
curl -sL https://w3id.org/tib/datacite/vocab/relationType/IsCitedBy
curl -sL -H "Accept: text/turtle" https://w3id.org/tib/datacite/vocab/relationType/IsCitedByUsing the mappings
In Cocoda
Cocoda is a web tool for browsing and reviewing mappings. Its server, jskos-server, imports jskos-mappings.json directly, because the file is a plain list of mappings and every mapping names its two vocabularies:
npm run import -- mappings https://w3id.org/tib/datacite/mappings/jskos-mappings.jsonVocabularies are identified by their BARTOC registry address, which is how Cocoda recognises them:
| Vocabulary | BARTOC address |
|---|---|
| DataCite Metadata Schema | http://bartoc.org/en/node/21149 |
| Schema.org | http://bartoc.org/en/node/18250 |
| DCMI Metadata Terms (Dublin Core) | http://bartoc.org/en/node/725 |
| DCMI Type Vocabulary | http://bartoc.org/en/node/17909 |
| Data Catalog Vocabulary (DCAT) | http://bartoc.org/en/node/1691 |
| Wikidata | http://bartoc.org/en/node/1940 |
With SSSOM tools
The SSSOM files work with sssom-py and other ontology-alignment tools. To check a file yourself:
pip install sssom==0.4.16 sssom-schema==1.0.0
sssom validate mappings/datacite-schemaorg.sssom.tsvWhen converting records
- Read the row comment and the matching recipe in
conversion/before transforming data. - Treat
relatedMatchas "connected", never as permission to swap one term for the other. - Check the direction of relations. If a pair appears only in a recipe with the operation
inverse, the two ends must be swapped. - Keep the original DataCite value when the target term is broader, so detail is not lost.
How quality is checked
Every change to the mapping files runs automatic checks on GitHub, a setup called CI. The checks fail unless all of the following hold.
- Each SSSOM file passes the official SSSOM validator, including its rules for prefixes and short names.
- Every DataCite term exists in the published DataCite 4.7 vocabulary.
- Every target term exists, and is not deprecated, in the pinned release of its vocabulary.
- Known wrong-direction and wrong-meaning pairs are refused.
- The coverage register gives every DataCite term an outcome, and agrees with the mapping files.
- The JSKOS and SKOS files contain exactly the same mappings as the SSSOM files, and the JSKOS file passes the official JSKOS validator.
- The published copies of the mapping files match the originals.
Changing a mapping
Found a mapping you disagree with? Edit the SSSOM file, never the generated files.
- Change the row in the right
datacite-*.sssom.tsvfile. Explain your reasoning in thecommentcolumn. - If a term gains or loses its only mapping, update its outcome in
coverage/. - Regenerate the JSKOS and SKOS files:
npm run build:mappings - Refresh the published copy in
production-namespace/:npm run build:production-namespace. The checks fail on an out-of-date copy. - Run the checks:
npm run check:mappingsandnpm run test:mappings - Open a pull request on the toolkit repository so the change can be reviewed.
The checks need Python packages listed in rdf-build-scripts/requirements-mappings.txt, and npm install for the JSKOS validator.