Metadata is structured information about a piece of content: what it is, what it is about, who made it, how its parts fit together and how it should be managed. For a publisher, it is the difference between an archive that can be searched, syndicated and reused, and a store of files that only long-serving staff can navigate.

The most widely used breakdown comes from libraries and archives. NISO's primer Understanding Metadata (Jenn Riley, 2017) separates descriptive metadata, which helps people find and understand a resource, from administrative metadata, which helps an organisation manage it, and from structural metadata, which records how the parts relate. It adds markup languages as a fourth category, where metadata is woven into the content itself.

This guide explains each type with publishing examples, the standards that book, journal, news and education publishers exchange, and the most common problems and fixes.

Key takeaways

  • Descriptive metadata helps people find and understand content, administrative metadata (technical, preservation and rights) helps you manage it, and structural metadata records how the parts fit together.
  • Each sector has a shared exchange standard (ONIX for books, JATS for journals, NewsML-G2 and IPTC Photo Metadata for news, LRMI for learning resources), while Dublin Core and Schema.org work across all of them.
  • Good metadata supports discovery, exchange with partners, archive reuse, analytics, and AI systems that filter and retrieve by topic, date or type.
  • Most metadata problems are consistency problems, fixed with controlled vocabularies, written rules and automated checks.

The main types of metadata

Descriptive metadata

NISO describes descriptive metadata as information about the content of a resource that helps someone find or understand it. Its example properties are title, author, subject, genre and publication date. In a publishing archive this is what most people mean by "metadata": headlines, bylines, sections, topic tags, places and people mentioned, series and edition, reading level or curriculum stage.

Administrative metadata: technical, preservation and rights

Administrative metadata is NISO's umbrella term for the information needed to manage a resource or that relates to its creation. It has three parts:

  • Technical metadata describes digital files so that software can decode and render them: file type, file size, creation date and time, compression scheme.
  • Preservation metadata supports the long-term management, migration or emulation of files. NISO's examples are a checksum (a digital fingerprint that shows whether a file has changed) and a record of preservation events, such as format migrations.
  • Rights metadata records the rights information attached to content. NISO's example properties include copyright status and rights holder.

In many archives this is the thinnest layer, because it was often not captured when print pages were scanned or when files moved between systems.

Structural metadata

Structural metadata describes how the parts of a resource relate to one another. NISO's examples include pages in sequence, a table of contents pointing to each section, and links between different resolutions of the same image. For a newspaper, it records which articles sit on which page of which edition. Without it, a digitised book becomes loose page images and an article can lose its sidebar or caption.

Markup languages

NISO treats markup languages as a final category, because they mix metadata and content in one file, marking features such as paragraphs, headings, names and dates inside the text. Journal article XML carries this kind of metadata, and it is what lets software tell a figure caption from body text.

Type Question it answers Publishing examples Main uses
Descriptive What is this, and what is it about? Title, byline, subject tags, genre, publication date, series Discovery, display, exchange
Technical How do I open and render it? Format, file size, resolution, creation date, compression Interoperability, file management
Preservation Is it intact, and what has happened to it? Checksum, migration and integrity-check events Long-term preservation
Rights What rights information is attached? Copyright status, rights holder, credit line Interoperability, file management
Structural How do the parts fit together? Page order, chapters, article-to-page links, image versions Navigation, reassembly
Markup What is each part of the text? Headings, paragraphs, names, dates, figure captions Navigation, reuse of components

The standards publishers and newsrooms use

Metadata is only useful if the people and software receiving it understand it, which is why each sector has shared standards. The practical question is which one your partners, retailers or clients already expect.

Standard Maintained by Sector What it describes Typical form
Dublin Core Dublin Core Metadata Initiative (DCMI) All 15 general elements for any resource XML, RDF, web pages
ONIX for Books EDItEUR Book trade Product information for print and digital books XML
IPTC Photo Metadata IPTC News, photography Captions, creators, rights, locations, how an image was made Embedded in image files
NewsML-G2 IPTC News agencies and publishers News items, packages, planning, vocabularies XML
JATS NISO (Z39.96) Journals Full-text journal articles and their metadata XML
Schema.org Schema.org community The web Web pages and the things they describe Markup in web pages
LRMI DCMI LRMI Working Group Education Learning resources and their educational alignment Schema.org terms, RDF

Dublin Core

Dublin Core grew out of a 1995 meeting in Dublin, Ohio, and settled on 15 elements: contributor, coverage, creator, date, description, format, identifier, language, publisher, relation, rights, source, subject, title and type. It is standardised as ISO 15836 and ANSI/NISO Z39.85. DCMI later expanded it with refinements known as DCTERMS. Because it is simple, Dublin Core works best as a common denominator that richer schemes are mapped onto.

ONIX for Books

EDItEUR describes ONIX for Books as the international standard for representing and communicating book industry product information electronically. It is XML-based, carries the metadata needed to describe and promote new and backlist titles, and supports targeted updates when availability changes. Release 3.1, published in March 2023, is where EDItEUR tells new implementers to focus. ONIX 2.1 lost EDItEUR support at the end of 2014 and was formally deprecated in 2023. Coded values come from separately issued code lists (controlled vocabularies).

IPTC Photo Metadata and NewsML-G2

The IPTC Photo Metadata Standard defines the fields used to describe news and stock images. The current specification, 2025.1, covers IPTC Core 1.5 and IPTC Extension 1.9, and recommends writing values into the file in both the older IIM format and XMP. Familiar fields include Description, Creator, Copyright Notice, Keywords and Digital Source Type. Version 2025.1 added AI System Used, AI System Version Used, AI Prompt Information and AI Prompt Writer Name, so the use of generative tools can be recorded with the image.

NewsML-G2 is IPTC's XML format for exchanging text, photos, audio, video, event and sports data as single items or structured packages. It relies heavily on controlled vocabularies, with IPTC Media Topics as its subject taxonomy (see our guide to IPTC Media Topics). Version 2.36, approved on 21 October 2026, adds properties for describing how AI was used to create or enhance content.

JATS for journals

JATS, the Journal Article Tag Suite, is published as NISO Z39.96-2024 (JATS 1.4) and continues the NLM Archiving and Interchange DTD work begun in 2002. It comes in three tag sets: Archiving and Interchange (the most permissive), Journal Publishing and Article Authoring (the most prescriptive). JATS holds both descriptive metadata, in the article's front matter, and markup for the full text, which makes journal archives unusually well structured.

Schema.org

Schema.org was launched by the major search engines in 2011 as a vocabulary for marking up web pages so software can understand what they describe. Creative works such as articles and books are among its most used types. For publishers it is the bridge to the open web: the title, author, date and subject in your content system can be published as Schema.org markup on the page.

LRMI for learning resources

LRMI is a set of classes, properties and concept schemes for describing educational resources. Developed by the LRMI project from 2011 and maintained by DCMI since 2014, it builds on Schema.org, whose LearningResource type has properties such as educationalLevel, learningResourceType, teaches, assesses and educationalAlignment (an alignment to an established educational framework, such as a national curriculum). A minimal record:

{
  "@context": "https://schema.org",
  "@type": "LearningResource",
  "name": "Comparing and ordering fractions",
  "learningResourceType": "worksheet",
  "educationalLevel": "Fourth class",
  "teaches": "Compare and order fractions with the same denominator",
  "inLanguage": "en-IE"
}

Embedded and external metadata

NISO notes that virtually every file format has a metadata area, mostly for technical information, and that formats such as JPEG, WAV and PDF can also hold descriptive metadata. Embedded metadata travels with the file, which keeps it understandable in new contexts, but it must be extracted into an external system before it can be searched.

IPTC has published tests of how social media sites handle photo metadata, and says the removal of rights information as images are transferred is of particular concern. The practical rule: keep the authoritative record in your content or asset management system, write the essential fields (caption, creator, credit, copyright notice) back into files on export, and test what survives the platforms you publish to.

What good metadata makes possible

  • Discovery. Search, browsing and filters depend on structured fields. Finding every review of one author from the 1990s needs genre, subject and date recorded consistently.
  • Exchange. NISO cites the book supply chain, where titles and authors flow through ONIX into retailer catalogues, as metadata created once and reused downstream.
  • Preservation. Checksums show whether files are intact after transfer or migration.
  • Analytics. With topic, format and audience labels, performance can be analysed by type of story or resource rather than one URL at a time.
  • AI. Retrieval systems and datasets need clean text, clear structure and filters such as date, topic, content type and language. Our guide to AI-ready data explains why metadata often separates a usable dataset from a raw dump.

Common metadata problems and how to fix them

Problem What it looks like Fix
Free-text tags and synonyms Thousands of tags used once; "NHS" and "health service" used for the same idea Adopt a controlled vocabulary with preferred labels and synonyms, then map legacy tags to it
Inconsistent values Dates as 3/4/05, March 2005 or 2005; one author spelled four ways Write content rules (one date format, one form of each name) and normalise in bulk
Missing administrative metadata Scans with no capture date, resolution or checksum Extract technical metadata automatically and generate checksums on ingest
Lost structure PDFs without page order, captions separated from photos Keep source XML or layout files and record page and section relationships
Metadata stripped in transit Captions and credits missing after upload Treat the database record as the master and re-embed key fields on export
Outdated schemes ONIX 2.1 feeds, retired subject codes Migrate, using published mappings between old and new vocabularies
Uneven tagging Some articles carry 25 topics, others none Set rules on how many tags and at what depth, then check samples
No stable identifiers Records matched by title, creating duplicates Give every work and file a persistent identifier

Most are prevented by agreeing values before tagging. If your subject tags have grown into an uncontrolled list, see our guide to building a content taxonomy.

A practical metadata audit in seven steps

  1. List content types and systems. Articles, photos, books, worksheets, audio, and where their metadata lives.
  2. Export a sample. A few hundred records per content type, spread across decades; older material usually has the biggest gaps.
  3. Measure completeness and consistency. For each field, record how often it is filled and how many distinct values it has.
  4. Define a minimum record. For each content type, decide which fields are required, recommended and optional, and who owns each.
  5. Map to partner standards. Write a crosswalk from internal fields to ONIX, JATS, NewsML-G2, Schema.org or Dublin Core.
  6. Fix at source, then in bulk. Change entry forms and rules first so new content arrives clean, then clean the backlog.
  7. Automate enrichment and measure it. Use AI-assisted tagging to fill gaps and check it against a reviewed sample (see our guide to evaluating AI tagging).

How Druid Learning helps

Druid Learning is an AI archival processing platform, based in Dublin and New York, that turns content archives into AI-ready datasets. Its Standardization Tool tags and labels content in real time, so new and archived material carries consistent descriptive metadata. Archive Optimization turns archives in formats including OCR scans, PDF, XML, IDML, INDD, EPUB, WAV, MP3 and MP4 into an indexed, labelled dataset. The platform has processed more than 10 million assets and handles content in 140+ languages. For the Irish educational publisher CJ Fallon, it processed 50,000 resources and mapped them to the curriculum.

Frequently asked questions

What is the difference between metadata and data?

Metadata is data that describes other content: the title, byline, subject tag, file format or checksum attached to an article, book or image. NISO's primer notes that the boundary is fuzzy, because metadata is usually stored and processed like any other data. The practical difference is purpose. Content is what readers consume, while metadata is the structured layer that lets people and software find, understand, manage and exchange that content.

What are the main types of metadata?

The common breakdown, used in NISO's Understanding Metadata primer, is descriptive metadata for finding and understanding a resource; administrative metadata for managing it, which includes technical, preservation and rights metadata; and structural metadata, which records how the parts relate, such as page order or chapters. NISO also lists markup languages, such as journal XML, as a category in which metadata and content are combined in the same file.

Which metadata standard should a publisher use?

Use the standard your partners already exchange. Book publishers send product data to the trade in ONIX for Books, where EDItEUR advises new implementers to use release 3.1. Journal publishers use JATS XML. News organisations use NewsML-G2 and IPTC Photo Metadata, with IPTC Media Topics for subjects. Education publishers can describe resources with Schema.org and LRMI terms. Dublin Core works as a simple common layer for mapping between schemes.

Is embedded metadata enough on its own?

Usually not. Embedded metadata, such as IPTC fields stored inside a JPEG, travels with the file. But it has to be extracted into a database before it can be searched, and it can be lost when files are converted or uploaded. Keep the authoritative record in your content or asset management system, and write the essential fields back into files whenever you export them.

Can AI generate metadata for an archive?

Yes, for many fields. NISO's 2017 primer already described automated speech transcription as relatively mature and pointed to topic modelling and named-entity recognition for text. Current models can suggest subjects, places, people and content types at archive scale. The results still need a controlled vocabulary to choose from, a reviewed sample to measure accuracy against, and human review of uncertain or high-impact labels before they are trusted at scale.

Sources