Does a content standard necessarily choose a file format?

In the narrower definition used here, no. Encoding and service details are separate concerns.

Does a complete record have to be accurate?

No. Presence checks do not verify whether the values are true or correctly interpreted.

Can a project require only selected items from a broader vocabulary?

It can define an appropriate local profile, while documenting the applicable rules and mappings.

AI Glossary / Data engineering and architecture / Advanced

Metadata content standard

Definition

A metadata content standard specifies which descriptive information is to be provided about data or other resources. In the OECD glossary's definition, it concerns the metadata items rather than prescribing their physical format, delivery services or encoding syntax. It answers the question of what information should be described. Separate implementation rules may be needed to determine how systems store, validate and exchange that information.

What it means

Two teams can agree that a dataset needs a title, an explanation of its subject and information about its source while storing those descriptions in different technical forms. Agreement about the descriptive content helps them interpret one another's records. It does not automatically make their files interchangeable. In an original AI learning catalog, a column labeled date is not sufficient if one team means publication date and another means last review date. The standard or accompanying profile must make the intended meaning clear enough to support the task for which the metadata is used.

How it works

A team selects a relevant content framework, identifies the items needed for its purpose and defines how local records will express them. Dublin Core's authoritative metadata vocabulary illustrates defined terms such as title, creator and description, with usage across different implementation contexts. A project may add a local application profile specifying required items and other rules. In the original catalog example, those local requirements must be labeled as project decisions rather than attributed to every implementation of the broader vocabulary. Content checks and technical format checks should then be evaluated separately.

Three practical examples

A dataset catalog agrees on descriptive items so analysts can interpret resources supplied by different teams.
An AI learning website defines what resource descriptions must contain before they are presented to visitors.
A migration project maps metadata between a spreadsheet and another system while checking that each item's meaning survives the transfer.

Think of it this way

Imagine agreeing on the information a parcel label must communicate: its destination, sender and handling instructions. That agreement does not, by itself, choose the printer, label size or electronic message used to transmit the details. The analogy separates content from its carrier. A neat label with the wrong destination still fails its purpose, just as a technically valid metadata file can contain misleading descriptions.

Worked example

Consider an original fictional catalog profile that requires four items for each resource: identifier, title, description and review date. These are local requirements chosen for the exercise, not a claim about a universal standard. Resource R1 has all four items. R2 has an identifier, title and description but no review date. R3 has an identifier, title and review date but no description. There are 3 × 4 = 12 required item occurrences and ten are populated, giving 10/12, approximately 83.3%, field completeness. Only R1 has every required item, so record completeness is 1/3, approximately 33.3%. Both measurements are valid descriptions of different checks. Now suppose R1's review-date value actually records publication rather than review. Its four fields remain populated, but it fails the intended semantic requirement. Moving the same values from a spreadsheet into JSON does not resolve that mismatch. The example distinguishes populated fields, complete records and correct interpretation.

Illustrative case study

In a fictional AI resource portal, contributors submit descriptions in different file formats. The team initially focuses on making every submission load successfully. Reviewers then discover that identical field labels conceal different meanings and that some resources lack essential descriptions. They establish a documented local profile, map each submission's fields to its defined items and report both completeness measures from the worked example. They ask contributors to verify ambiguous dates rather than having an assistant invent them. The scenario illustrates improving descriptive consistency while retaining a separate technical import process. It does not claim that adopting a vocabulary alone certifies the truth of every metadata value.

Common misconceptions and mistakes

A metadata content standard is not simply a spreadsheet layout or a choice between XML and JSON. Those concern representation and implementation. Another mistake is assuming every field in a broad vocabulary must be mandatory for every project. Local requirements need explicit documentation. Identical labels can also conceal different concepts, while different labels may refer to the same defined concept. Finally, completeness is not the same as accuracy: a fully populated record can contain incorrect dates, vague descriptions or unsupported source claims. Automated checks should report what they actually establish.

Business use

For an AI catalog, decide what visitors and internal tools need to know about each resource. Define the descriptive items, explain their meaning and identify the evidence used to populate them. Keep local mandatory-field rules visible and versioned so contributors can follow them consistently. When exchanging records, check the mapping of meanings as well as whether the file opens correctly. In the fictional portal, report missing descriptions separately from ambiguous dates because the remedies differ. This helps metadata support discovery and interpretation without overstating what a successful import or completeness score proves.

Check your understanding

How many required item occurrences are in the toy catalog?

Answer: Twelve.

How many are populated?

Answer: Ten.

Why is record completeness only approximately 33.3%?

Answer: Only one of three records contains all four required items.

Does R1's populated publication date satisfy a review-date requirement?

Answer: No.

Why does changing to JSON not fix that problem?

Answer: The carrier changes, but the wrongly interpreted content remains.

Related terms

Learn next

Define a small local metadata profile for a fictional learning resource. State each item's meaning and whether it is required. Represent one record in two different formats, then check that the meaning remains unchanged. Include one fully populated but semantically incorrect record to demonstrate why completeness alone is insufficient.

Metadata

Sources

OECD, Glossary of Statistical Terms, 2008, Metadata content standard: https://www.oecd.org/content/dam/oecd/en/publications/reports/2008/09/oecd-glossary-of-statistical-terms_g1gh9ad7/9789264055087-en.pdf Dublin Core Metadata Initiative, DCMI Metadata Terms: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ The four-item profile, completeness arithmetic, parcel-label analogy and AI portal scenario are original educational illustrations. The local required fields are not presented as universal Dublin Core requirements.

Previous: Metadata Next: Metadata controller