What is Administrative Metadata?
Administrative metadata is the information needed to manage a digital asset, or that relates to its creation, as distinct from descriptive metadata that helps people find and understand it. It typically covers technical properties, rights and permissions, and preservation data such as checksums and provenance.
How Administrative Metadata works
NISO’s Understanding Metadata primer treats administrative metadata as an umbrella over three types: technical metadata needed to decode and render files, preservation metadata supporting their long-term management, and rights metadata describing the intellectual property rights attached to content. It stands beside descriptive metadata, used for finding and understanding a resource, and structural metadata, which relates the parts of a resource to one another. Schemas slice the umbrella differently. A METS document’s amdSec holds four kinds, technical (techMD), intellectual property rights (rightsMD), source (sourceMD), and digital provenance (digiprovMD), each embedded in the document or referenced externally. PREMIS, the preservation data dictionary, models Objects, Events, Agents, and Rights statements. Technical values are often embedded in a file by the software that created it, and NISO notes that embedded metadata must still be extracted into an external system before it can be indexed.
Key facts
- 1Is technical metadata part of administrative metadata? It depends on the scheme, so name the scheme when you write requirements. NISO places technical, preservation, and rights metadata under the administrative umbrella, and METS records technical, rights, source, and digital provenance metadata in its administrative section. PREMIS instead lists administrative, technical, and structural as separate categories that preservation metadata spans. Structural metadata sits outside the administrative group in both NISO and METS.
- 2Does a matching checksum prove a file is intact and authentic? It shows only that the file has not changed since the stored digest was computed. PREMIS describes a fixity check as comparing a message digest calculated earlier with one calculated later, and states that this does not address the object’s integrity or authenticity, for which it points to format validation and documented provenance. Store the algorithm with the value; PREMIS records both.
- 3What does a provenance record need? In PREMIS an Event has a mandatory identifier, a mandatory type, such as ingestion, migration, or validation, and a mandatory date and time. Linking the responsible Agent, which can be a person, an organization, or software, is optional but recommended, and one Event can link several Agents, each with an optional role such as implementer or executing program. A derivative is tied to its source by a derivation relationship that names the source object and the Event that produced it; PREMIS says that Event must be recorded for derivative relationships. Which actions to record is left to the implementation. So is recording events from before ingest, such as derivation from an earlier object or a change of custody; PREMIS counts these as events too, so a repository that keeps them records them as Events.
- 4Can a missing rights value be read as permission? No; treat it as unknown. PREMIS keeps the cases apart: its copyright status examples are separate values for copyrighted, public domain, and unknown, and for the end date of a license or of a granted permission it prescribes
OPENfor an open-ended term and omission when the date is unknown or differs between the objects one statement covers. An omitted end date therefore never means open-ended, so record a term with no end explicitly. In your own schema, giving unknown an explicit value as well keeps an empty field from being read either way.
When Administrative Metadata matters
Use these fields to enforce access rules, audit asset history, and act on time-bounded permissions such as license terms or embargoes. Automated decisions are only as reliable as the recorded values, so treat a missing or stale value as a reason to stop and check, not as approval.
How Transloadit helps with Administrative Metadata
Transloadit produces or carries several administrative values during processing. Metadata extraction reports technical properties such as MIME type, dimensions, and codecs for each file, along with embedded rights fields such as copyright when the file contains them. The /file/hash Robot computes a digest and exports it as file.meta.hash, and the /meta/write Robot writes fields such as a copyright notice into image, video, and audio files.
These values are reported in the Assembly Status as part of each file’s metadata, and a Step’s result parameter controls whether its results are listed there; store them in your own catalog or repository if they must serve as a lasting record. The file hashing Robot hashes the whole file by default. Its partial setting hashes only the first bytes, the last bytes, or both, for fast fingerprinting, which does not cover every byte of the file.
Sources
- NISO: Understanding Metadata primer (Riley, 2017), Types of Metadata
- Library of Congress: METS Overview and Tutorial (administrative metadata section)
- PREMIS Data Dictionary for Preservation Metadata, version 3.0 (semantic units 1.5.2 fixity, 1.13 relationship, 2.1–2.6 Event, 4.1 rightsStatement; special topic “Fixity, integrity, authenticity”)