Metadata describes content so people and systems can identify it, find it, understand its context and manage its use. Begin with a few questions the team must answer. Each field should support a task, have an owner and follow an agreed rule.
Choose fields from real questions
For a publishing team, useful questions include: which page is the current version, who can confirm its facts, which language is it in, and what are we allowed to reuse? A field earns its place when the answer supports discovery, delivery or maintenance.
DCMI Metadata Terms provides established meanings for properties such as identifier, title, subject, language, modified and rights. Use those meanings when mapping your fields. Operational fields such as review owner or workflow state may be local extensions. Document that distinction so other systems can interpret the export correctly.
The PRISM specification package describes publishing metadata, including rights and content exchange. This linked package is a W3C Member Submission, not a W3C Recommendation. A small team can begin with a documented local profile and map to a publishing standard when a real exchange partner requires it. Avoid claiming conformance merely because some field names look similar.
Write a compact data dictionary
| Field | Rule | Purpose |
|---|---|---|
| content_id | Required; unique and stable, such as HELP-001. | Connect versions and translations without relying on a title. |
| title | Required; meaningful human-readable text. | Identify the item in search and lists. |
| content_type | Required; article, procedure or form. | Choose an appropriate workflow and presentation. |
| subject | Required; approved topic code. | Group related content consistently. |
| language | Required; agreed language tag, such as en or fr. | Identify the language of this version. |
| modified | Required; YYYY-MM-DD for substantive modification. | Support freshness checks and exchange. |
| rights | Required; a verified rights statement or reference. | Explain the documented basis for use. |
| review_owner | Required locally; a team role with a current contact. | Route questions and scheduled reviews. |
| review_due | Required locally; YYYY-MM-DD. | Make the next maintenance action visible. |
Define “required” for each stage. A draft may have unresolved rights; publication should wait for the required verification. A date field should state whether it describes creation, modification, publication or review. These events can happen on different days.
Compare two complete records
Download the data dictionary CSV, the two sample records and instructions. The samples are a learning aid, not production-ready records.
Control terms without freezing the vocabulary
Assign a stable code to each approved subject and keep its display label separate. “Visits” can change to “Service visits” without changing the code VISITS. Record synonyms that help editors find the right term. Have one vocabulary owner approve additions, merges and retirements.
Free-text keywords can complement controlled subjects, but they should not replace fields that drive permissions, reporting or routing. If automated tagging proposes a subject, record it as a suggestion until the required review is complete. Evaluate suggestions on real examples, including ambiguous and minority topics.
For multilingual publishing, a shared concept code can have different translated labels. The language of the content and the language of its metadata labels are separate concerns. Use the localization workflow to keep both understandable.
Validate before importing or publishing
- Check that every required field is present and that identifiers are unique.
- Validate dates, language tags, allowed content types and subject codes.
- Check that related identifiers resolve and that a relationship points to the intended item.
- Inspect rights and ownership values for unresolved placeholders.
- Export a small sample, import it into the receiving system and compare field meanings as well as values.
A syntactically valid date can still describe the wrong event. A successful import can still drop multiple subjects or change an identifier's leading zeros. Record mappings, separators, blank-value rules and transformations explicitly. Review representative records with the people who use them.
Keep the schema version and change history. When changing a field, explain how existing records will be migrated and how older exports should be interpreted. This makes metadata a maintained part of the publishing system.