Format support¶
Crosswalk registers formats by stable command-line name. Parsing maps a source document into Hub records; serialization maps Hub records to a target document. Not every format needs both directions.
The registry is deterministic and safe for concurrent readers. Registration fails explicitly when two adapters claim the same name, and automatic format detection fails rather than choosing arbitrarily when more than one adapter matches an input.
| Name | Description | Parse | Serialize |
|---|---|---|---|
archivesspace |
ArchivesSpace JSONModel snapshot/resource data | Yes | No |
arxiv |
arXiv Atom/OAI metadata | Yes | Yes |
bibtex |
BibTeX | Yes | Yes |
crossref |
Crossref deposit XML 5.3.1 | Yes | Yes |
crossref-rest |
Crossref REST API JSON response | Yes | No |
csl |
Citation Style Language JSON | Yes | Yes |
csv |
Generic or spec-driven CSV | Yes | Yes |
datacite |
DataCite XML 4.6 | Yes | Yes |
drupal |
Drupal/Islandora JSON | Yes | Yes |
dublincore |
Dublin Core | Yes | Yes |
islandora-workbench |
Islandora Workbench CSV | Yes | Yes |
marc |
MARC21 binary or MARCXML bibliographic records | Yes | Yes |
mods |
MODS XML 3.8 | Yes | Yes |
omeka-s |
Omeka S JSON-LD acquisition snapshot | Yes | No |
proquest |
ProQuest ETD XML/delivery data | Yes | Yes |
schemaorg |
schema.org JSON-LD | Yes | Yes |
scopus |
Scopus Search API JSON | Yes | No |
wos |
Web of Science Starter API JSON | Yes | No |
zenodo |
Zenodo published-record API JSON | Yes | No |
Run crosswalk convert --help for conversion options and crosswalk fetch
--help for the API-backed acquisition commands.
Crossref REST versus deposit XML¶
The two Crossref names have different wire contracts and responsibilities:
crossref-restparses the JSON response envelope returned by the Crossref REST API. It is an input adapter and has no serializer.crossrefparses and writes Crossref deposit XML version 5.3.1. It is the deposit-format spoke.
Searching Crossref therefore flows through crossref-rest, the Hub,
reconciliation, and then the selected target serializer. Selecting crossref
as that target produces deposit XML; it does not preserve the REST response
envelope. See Architecture.
Dynamic systems¶
Drupal and Omeka S schemas differ by installation. Use a model-bound profile to map their actual configured fields; see Profiles and models. Islandora Workbench additionally requires a sealed directional spec, described in Islandora Workbench.
ArchivesSpace currently uses a versioned JSONModel API adapter without an installation profile. It preserves hierarchy in a Dataset and retains unknown top-level plugin/newer fields in canonical JSON for later use.
MARC21¶
The marc adapter reads MARC21 binary and MARCXML. Serialization writes binary
ISO 2709 by default; pass --pretty to write readable MARCXML instead.
Repeatable Hub values are written as repeated MARC fields or subfields where MARC21 permits them. This includes publishers, publication places and dates, physical descriptions, editions, languages, identifiers, subjects, rights, and supported relations.
MARC maps directly between its tag/subfield record model and the Hub. The current mapping is implemented in the adapter and compiled into Crosswalk; it is not exposed as a site profile or CLI mapping override. A site that needs local MARC tags currently has to extend the adapter. See Which mappings are configurable?.
ProQuest embargo codes¶
For ProQuest ETD data, an explicit delayed-release date takes precedence. When
Crosswalk must derive the date from embargo_code and the acceptance date, the
supported codes are:
| Code | Delay |
|---|---|
0 |
No embargo |
1 |
6 months |
2 |
12 months |
3 |
24 months |
The derived date is represented in the Hub as an available date and maps to
the Workbench embargo-until field. An invalid explicit embargo value falls back
to the code when possible.