Crosswalks: CRediT ↔ DataCite, MARC, ORCID, Schema.org

CRediT is a fourteen-role controlled vocabulary for contributor credit on a journal article. It is rarely the only vocabulary a system needs. A repository depositing datasets has to express contribution in DataCite’s contributorType; a library catalogue must use MARC 21 relator codes; an ORCID profile carries work-level contributorship in ORCID’s own API model; a publisher emitting structured data on the open web encodes contribution in Schema.org. The four tables below record how the fourteen CRediT roles cross-walk into each of these systems.

Three of the four mappings are imperfect by design. DataCite’s contributorType is dataset-centric; MARC’s relator codes predate research-output vocabularies; Schema.org’s Role is a generic pattern, not a controlled vocabulary. Only the ORCID mapping is 1:1, because ORCID adopted CRediT verbatim in API v3.0. Each row records the closest match plus a note explaining the compromise.

1. CRediT ↔ DataCite contributorType

DataCite’s Metadata Schema 4.6 defines contributorType as a controlled vocabulary on the <contributor> element (§7). The values are: ContactPerson, DataCollector, DataCurator, DataManager, Distributor, Editor, HostingInstitution, Other, Producer, ProjectLeader, ProjectManager, ProjectMember, RegistrationAgency, RegistrationAuthority, RelatedPerson, Researcher, ResearchGroup, RightsHolder, Sponsor, Supervisor, Translator, WorkPackageLeader. Authorship of the deposited resource itself is carried by <creators> and is therefore not a contributorType value.

Most CRediT roles have no exact DataCite analogue; the table records the closest primary match and, where useful, a fallback. Where DataCite expresses something CRediT cannot (e.g. RightsHolder, WorkPackageLeader), no CRediT row exists for it.

Canonical source: DataCite Metadata Schema 4.6 — Kernel PDF · CASRAI: DataCite federation.

2. CRediT ↔ MARC 21 Relator Codes

The MARC Code List for Relators is maintained by the Library of Congress and contains 270+ three-letter codes. Relators predate research-output vocabularies and the closest matches are often imperfect; the recommended encoding is to record the CRediT term verbatim in MARC field 720 $e (Added Entry — Uncontrolled Name, role) and use the closest MARC code in field 700 $4 (Added Entry — Personal Name, relator). For institutional contributors use 710 instead of 700.

Canonical source: Library of Congress — MARC Code List for Relators. For full-text MARC encoding examples, see also the LoC bibliographic format documentation for fields 700 and 720.

3. CRediT ↔ ORCID work contributorship

ORCID adopted CRediT as the controlled vocabulary for work-level contributor roles when it released API v3.0 (announcement: ORCID — Contributor Roles Taxonomy (CRediT) in ORCID, 2018). The ORCID contributor-role element on the work model takes the canonical NISO URI directly. The mapping is therefore 1:1 by design: each CRediT role has exactly one ORCID role value, which is its casrai.org/credit URI.

When a CRediT-tagged publication is registered with Crossref or DataCite carrying CRediT in the deposit metadata, Crossref auto-pushes the role into the contributor’s ORCID record without further action by the publisher. This is the single largest channel by which CRediT propagates into the persistent-identifier graph.

Canonical source: ORCID — CRediT in ORCID; ORCID XML schema (orcid-model), element work:contributor-attributes/work:contributor-role.

4. CRediT ↔ Schema.org Role

Schema.org has no contributor-role controlled vocabulary; instead it provides the generic Role intermediate type that wraps any property to attach an additional roleName (and optionally startDate / endDate). The pattern recommended by Schema.org for credit-with-role is to express each contributor as a Role instance nested inside the author or contributor property of a CreativeWork (or its subclass ScholarlyArticle).

The recommended values for the Role properties when encoding CRediT are:

• @type — Role
• roleName — the CRediT role name (e.g. Data curation)
• description — the NISO definition for that role, verbatim
• url — the canonical casrai.org/credit URI
• [author | contributor] — a nested Person with name and (where available) identifier as the ORCID iD

Worked example — JSON-LD for a ScholarlyArticle

The example below encodes a paper with two authors. The first is credited with Conceptualization, Methodology, and Writing — original draft; the second with Data curation and Writing — review & editing. Each role is a separate Role instance inside the author array, so the same person appears multiple times — once per role.

{
  "@context": "https://schema.org",
  "@type": "ScholarlyArticle",
  "@id": "https://doi.org/10.1234/example.2026.0001",
  "headline": "An illustrative paper demonstrating CRediT in Schema.org",
  "datePublished": "2026-05-19",
  "author": [
    {
      "@type": "Role",
      "roleName": "Conceptualization",
      "url": "https://casrai.org/credit/roles/conceptualization",
      "description": "Ideas; formulation or evolution of overarching research goals and aims.",
      "author": {
        "@type": "Person",
        "name": "Ada Lovelace",
        "identifier": "https://orcid.org/0000-0002-1825-0097"
      }
    },
    {
      "@type": "Role",
      "roleName": "Methodology",
      "url": "https://casrai.org/credit/roles/methodology",
      "description": "Development or design of methodology; creation of models.",
      "author": {
        "@type": "Person",
        "name": "Ada Lovelace",
        "identifier": "https://orcid.org/0000-0002-1825-0097"
      }
    },
    {
      "@type": "Role",
      "roleName": "Writing — original draft",
      "url": "https://casrai.org/credit/roles/writing-original-draft",
      "description": "Preparation, creation and/or presentation of the published work, specifically writing the initial draft (including substantive translation).",
      "author": {
        "@type": "Person",
        "name": "Ada Lovelace",
        "identifier": "https://orcid.org/0000-0002-1825-0097"
      }
    },
    {
      "@type": "Role",
      "roleName": "Data curation",
      "url": "https://casrai.org/credit/roles/data-curation",
      "description": "Management activities to annotate (produce metadata), scrub data and maintain research data (including software code, where it is necessary for interpreting the data itself) for initial use and later re-use.",
      "author": {
        "@type": "Person",
        "name": "Charles Babbage",
        "identifier": "https://orcid.org/0000-0001-2345-6789"
      }
    },
    {
      "@type": "Role",
      "roleName": "Writing — review & editing",
      "url": "https://casrai.org/credit/roles/writing-review-editing",
      "description": "Preparation, creation and/or presentation of the published work by those from the original research group, specifically critical review, commentary or revision — including pre- or post-publication stages.",
      "author": {
        "@type": "Person",
        "name": "Charles Babbage",
        "identifier": "https://orcid.org/0000-0001-2345-6789"
      }
    }
  ]
}

Canonical sources: schema.org/Role · schema.org/ScholarlyArticle · the Schema.org pattern for nested roles is documented in the Schema.org data model — Roles note.

How to apply these crosswalks

The four tables solve overlapping but distinct problems. A research administrator integrating CRediT into a production system usually faces one or two of them at once, not all four. The decision flow below maps the common cases.

• Depositing a dataset, software release, or instrument with DataCite — use Table 1. Author credit goes in <creators>; non-author contribution goes in <contributors> with the closest contributorType. Carry the CRediT term itself in a separately addressable place: either <contribution> free text (DataCite 4.6 introduced this) or a related resourceTypeGeneral="Text" data paper that does carry CRediT in its Crossref deposit.
• Cataloguing a research output in a MARC-based library system — use Table 2. Record the closest MARC relator in 700/710 $4; record the precise CRediT term verbatim in 720 $e with subfield $4 holding the same relator code as a cross-reference. This preserves the relator-code search index while keeping the CRediT term recoverable for downstream consumers.
• Pushing contributor credit to ORCID records — use Table 3. In practice, this is not done directly: deposit CRediT in the Crossref or DataCite metadata at publication, and Crossref auto-propagates the roles into each contributor’s ORCID record. Direct API writes are appropriate only for back-fills or for outputs that have no Crossref / DataCite deposit.
• Emitting structured data on the open web (JSON-LD on article landing pages, repository pages) — use Table 4. Each Role-with-Person tuple is one Role instance in the author or contributor array; a contributor with three roles appears three times. Set url to the casrai.org/credit URI so consumers can dereference the canonical definition.

Versioning and provenance

The mappings in Tables 1, 2, and 4 are editorial: they reflect the closest available correspondence in vocabularies that were not designed against each other. The mapping in Table 3 is structural: ORCID adopted CRediT verbatim. For any specific implementation that depends on a mapping being correct, refer to the canonical source linked under each table and confirm against the current schema version. The DataCite schema in particular has evolved (4.4 → 4.5 → 4.6); the MARC relator list is appended to roughly annually.

Related pages

• Federation overview
• NISO federation (CRediT stewardship)
• DataCite federation (contributorType)
• ORCID federation (work contributorship)
• Crossref federation (CRediT in deposit metadata)
• 2020 joint stewardship statement