Technical Metadata

Technical metadata is the category of metadata that documents the digital characteristics of a resource needed to render, verify, and process it correctly over time: file format and version, the hardware and software environment used to create or read it, technical characteristics (size, encoding, resolution, compression), and a record of any technical processing or transformation events (format migration, compression, checksum regeneration) applied since creation. It answers 'what does a machine need to know to open, verify, and correctly interpret this file,' as distinct from what a resource is about (descriptive metadata) or who may use it and under what terms (administrative metadata, in the narrower rights/provenance/access-control sense). Some frameworks, including NISO's influential three-way split, treat technical metadata as a subtype nested under the broader administrative metadata category; others, including the METS schema's own internal structure, give it a distinct named subsection (techMD) alongside rights and provenance subsections rather than folding it into a single undifferentiated administrative bucket. Both framings agree on the underlying content -- format, environment, and fixity information -- they differ only in where they draw the taxonomy line.

ByCASRAI Editorial Board

· Last updated 18 Jul 2026

Worked examples

Is an instance

A repository's preservation record for a deposited dataset stores the exact file format and version (e.g. 'CSV, UTF-8 encoded' or 'TIFF 6.0'), the software used to generate it (e.g. 'R version 4.3.1'), the file's SHA-256 checksum at ingest, and a log entry noting a later format-migration event from an obsolete spreadsheet format to CSV -- all technical metadata, none of it descriptive (title, author) or rights-related (license, embargo).

Is an instance

A digitized image file's technical metadata records pixel dimensions, colour depth, compression scheme, and the scanning hardware and software used to capture it -- information a future user or migration tool needs to correctly render or convert the file, independent of what the image depicts (that's descriptive metadata) or who may reuse it (that's rights metadata).

Looks similar, but isn't

Not an instance

A dataset's title, creator names, and subject keywords are descriptive metadata, not technical metadata -- they answer what the resource is about and how to find it, not how it is technically encoded or what software can open it.

Not an instance

A license statement (e.g. CC BY 4.0) or an embargo end-date is rights/access-control metadata, not technical metadata, even though it is commonly captured in the same repository deposit record alongside genuinely technical fields like file format and checksum.

Technical metadata documents the digital characteristics a resource has and the technical environment it depends on: file format and version, the hardware and software used to create or read it, and a record of any technical processing applied to it since creation. Where descriptive metadata answers “what is this, and how do I find it?” and rights/provenance metadata answers “who may use this, and under what conditions?”, technical metadata answers a narrower, more mechanical question: “what does a system need to know to open, verify, and correctly interpret this specific file?”

The four components of technical metadata

In practice, technical metadata for a research data object typically covers:

File format and version — the exact format identifier and version (CSV, TIFF 6.0, PDF/A-2b, NetCDF-4), which determines what software can open the file at all and whether it is at risk of format obsolescence.
Fixity and integrity information — a checksum (a cryptographic hash such as MD5, SHA-1, or SHA-256 computed over the file’s contents) recorded at deposit and re-verified periodically to detect any unintended or unauthorized change to the bytes. MD5 is adequate for catching accidental corruption; SHA-1/SHA-256 are used where the checksum needs to resist deliberate, engineered tampering. Checking fixity at three points in a file’s lifecycle — on ingest, periodically at rest, and on retrieval — is standard digital-preservation practice, reflected in frameworks like the National Digital Stewardship Alliance’s Levels of Digital Preservation and file-packaging formats such as BagIt (IETF RFC 8493), which bundles a manifest of checksums alongside the files it describes.
Hardware and software environment — the operating system, application, application version, or physical equipment used to create or capture the resource (e.g. the instrument model that produced a sensor dataset, or the software version used to generate a statistical output), and any dependencies a future user would need to reopen or re-run it.
Technical processing history — a log of technical events applied to the object over time: format migration, compression or decompression, re-encoding, or checksum regeneration after a verified migration. This overlaps with, but is narrower than, full provenance metadata: technical processing history records what was done to the bytes, not who authorized the change or why in a policy sense.

How this relates to administrative metadata

CASRAI’s administrative metadata entry describes NISO’s standard three-way metadata split (descriptive, administrative, structural) and notes that this framing treats technical and preservation metadata as subtypes nested under the broader administrative category. That is a legitimate and common way to draw the taxonomy line, and it is not in tension with treating technical metadata as its own detailed entry here — the same way a broader term can have a narrower, more operationally detailed child concept. Other standards draw the line differently: the METS schema’s administrative metadata section (amdSec) is itself subdivided into four named parts — technical (techMD), rights (rightsMD), source/provenance (sourceMD), and digital-provenance (digiprovMD) metadata — giving technical metadata its own distinct, separately structured subsection rather than a single undifferentiated administrative bucket. Both framings agree on the underlying content; they differ only in how many named boxes it gets sorted into.

The PREMIS (Preservation Metadata: Implementation Strategies) data dictionary, maintained by the Library of Congress, is the standard most specifically built around this technical/fixity layer: it defines a structured way to record an object’s format and technical characteristics, its environment (software and hardware dependencies), and fixity events (the algorithm used, the timestamp, and the resulting checksum value) as part of an object’s preservation metadata.

How this relates to metadata format

Technical metadata (a content category — what technical facts are recorded about a resource) should not be confused with metadata format (a syntax layer — how any metadata, technical or otherwise, gets physically encoded as XML, JSON, or another serialization). A repository can express identical technical metadata — the same file format, checksum, and environment facts — as XML in a METS techMD section or as JSON in a REST API response; the content is the same, only the wire format differs.

Why it matters for research data management

Technical metadata is what makes long-term reuse and preservation actually possible in practice, not just in principle. A dataset with excellent descriptive metadata (title, author, keywords) but no recorded file format, checksum, or software dependency information is difficult to trust or reopen years later: a repository cannot verify the file has not silently corrupted, and a future user may not know what software or version is needed to read it. This is why digital-preservation certification frameworks such as CoreTrustSeal require documented processes for storage and data integrity (its R14 requirement), and why the data curator or repository manager responsible for a deposit typically captures technical metadata at ingest rather than relying on the depositing researcher to supply it.

References

PREMIS Editorial Committee, PREMIS Data Dictionary for Preservation Metadata (Library of Congress, loc.gov/premis).
Digital Preservation Coalition, “Fixity and Checksums,” DPC Digital Preservation Handbook (dpconline.org/handbook).
National Digital Stewardship Alliance, Levels of Digital Preservation (ndsa.org/publications/levels-of-digital-preservation).
IETF RFC 8493, The BagIt File Packaging Format.

Use in your systems

JATS XML <role> element

xml

<role vocab="credit"
      vocab-identifier="https://casrai.org/dictionary/"
      vocab-term="Technical Metadata"
      vocab-term-identifier="https://casrai.org/dictionary/term/technical-metadata" />

Schema.org DefinedTerm (JSON-LD)

json

{
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  "@id": "https://casrai.org/dictionary/term/technical-metadata",
  "name": "Technical Metadata",
  "identifier": "https://casrai.org/dictionary/term/technical-metadata",
  "description": "Technical metadata is the category of metadata that documents the digital characteristics of a resource needed to render, verify, and process it correctly over time: file format and version, the hardware and software environment used to create or read it, technical characteristics (size, encoding, resolution, compression), and a record of any technical processing or transformation events (format migration, compression, checksum regeneration) applied since creation. It answers 'what does a machine need to know to open, verify, and correctly interpret this file,' as distinct from what a resource is about (descriptive metadata) or who may use it and under what terms (administrative metadata, in the narrower rights/provenance/access-control sense). Some frameworks, including NISO's influential three-way split, treat technical metadata as a subtype nested under the broader administrative metadata category; others, including the METS schema's own internal structure, give it a distinct named subsection (techMD) alongside rights and provenance subsections rather than folding it into a single undifferentiated administrative bucket. Both framings agree on the underlying content -- format, environment, and fixity information -- they differ only in where they draw the taxonomy line.",
  "inDefinedTermSet": "https://casrai.org/dictionary/domain/data-infrastructure#set",
  "url": "https://casrai.org/dictionary/term/technical-metadata",
  "sameAs": [],
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "publisher": {
    "@id": "https://casrai.org/#organization"
  },
  "dateModified": "2026-07-18T06:30:53",
  "inLanguage": "en"
}