Built-in metadata vocabularies

Four built-ins describe a document to something outside your docs site. A platform schema says what your generator will parse. A taxonomy schema says what kind of page this is. These four say how the page presents itself to a social card renderer, a catalogue, or another publisher’s build.

Id	Speaks to	Requires
ogp:article:1.0	Social and link-preview renderers	og:title, og:type, og:url, og:image
dcmi:elements:1.1	Catalogues, repositories, library systems	nothing
microsoft:learn:1.0	The Microsoft Learn publishing build	title, description, author, ms.author, ms.date
x:cards:1.0	X, when someone shares the link	twitter:card

Each has a page of its own, with its full field table, an example page, and the finding a common mistake produces.

• ogp:article:1.0 checks what no build tool checks. A missing og:image deploys cleanly and renders as a grey box wherever the page is shared.
• dcmi:elements:1.1 checks the shape of the fifteen Dublin Core elements, and the W3CDTF form of date.
• microsoft:learn:1.0 requires the five attributes a Learn publishing build refuses to go without.
• x:cards:1.0 requires twitter:card, the one card tag with no Open Graph fallback.

All four allow additional properties. ogp:article:1.0 and x:cards:1.0 share a channel, the <meta> tags of an HTML page, and normally run together:

manni meta validate site/ -s ogp:article:1.0 -s x:cards:1.0

Vocabularies leave some values open

Three of the four decline to enumerate a field whose values look like a closed set. og:type allows namespaced and vendor types. DCMI recommends a type vocabulary without requiring one. Microsoft keeps the authoritative ms.topic list internal. An enum assembled from examples would fail correct documents, so each is checked for shape only. To narrow one for your own docs set, write a schema that $refs the built-in and adds an enum. See Author a schema.