What a field definition contains
A schema is a list of field definitions. Each one should answer the same questions:
| Property | Question it answers | Example |
|---|---|---|
| Key | What is the field's stable, machine-readable name? | product_line |
| Label | What do people see, in each language? | Product line / Produktlinje |
| Definition | What exactly does it mean? | The range the product belongs to in the current catalogue |
| Data type | Text, number, date, yes/no, or a term from a list? | Term from a list |
| Allowed values | Which values are valid? | The "Product lines" vocabulary |
| Cardinality | One value or several? | One |
| Obligation | Required, required in some cases, or optional? | Required for product photos |
| Scope | Which kinds of asset use it? | Product photos and datasheets |
| Source | Who or what fills it in? | Product catalogue import |
| Owner | Who decides on changes to it? | Product marketing |
Written down, this table is usually called a data dictionary. Without one, two teams will use the same field for different things within a year.
Metadata schemas and metadata standards
A metadata standard is a schema, or part of one, published for many organisations to share. There are four kinds, and a DAM schema usually draws on several:
- Structure standards define a set of fields. Dublin Core (ISO 15836) is the general one. IPTC photo metadata covers photos, EBUCore and PBCore cover broadcast media, and PREMIS covers digital preservation.
- Value standards define allowed values: ISO 8601 for dates, ISO 3166-1 for country codes, BCP 47 for language tags, and your own controlled vocabularies and taxonomies for everything specific to the business.
- Content standards define how values are written: caption style, how names of people are formatted, which product name is canonical.
- Format standards define how metadata is stored and exchanged: XMP inside files, EXIF for camera data, JSON over an API, CSV for bulk edits.
A company schema is rarely one standard adopted whole. It is the company's own fields, with standard value lists where they exist, and a mapping (a crosswalk) from embedded standards such as IPTC to its own fields so that values in uploaded files are not lost.
A metadata schema example
A B2B manufacturer with product photos, sales decks and videos might define:
- Shared by all assets: asset type, product line, region, language, usage rights, owner.
- Product photos: product (depends on product line), SKU, colour, angle, photographer, shoot date.
- Sales decks: audience, review date, confidentiality.
- Videos: duration (read from the file), subtitle languages, people shown.
The metadata entry lists the design principles behind choices like these. The rest of this entry is about keeping a schema in working order once it exists.
Maintaining a schema
- Stable keys. Integrations, exports and automation rules refer to the key, not the label. Rename labels freely; change keys only with a migration plan.
- Type changes need a data check. Turning a text field into a date or a list breaks every value that does not fit. Count the affected assets first.
- Retire before you delete. Find what depends on a field (filters, rules, saved searches, integrations) before removing it, and decide what happens to its values.
- Review against use. Once a year, compare the schema with search and filter logs. Fields nobody filters on are candidates for removal; terms people type in search without finding a field are candidates for addition.
- One owner per field. Someone must be able to say what the field means and approve new values.
Metadata schemas in Freedam
- Administrators define fields per asset class, so product photos, documents and videos each have their own fields. An asset class can be duplicated to start a new one.
- Each field has a stable key, a label that can be translated into each workspace language, one of eight types (text, long text, number, decimal, yes/no, date, JSON or vocabulary), and settings for required, default value, help text, hiding when empty, multilingual values and sensitive information. See metadata definitions.
- Vocabularies are flat or hierarchical, can be imported from CSV or Excel in several languages, and a vocabulary field can depend on another, so the product field only offers the products of the chosen line.
- Form Studio lays the fields out in sections and columns, and field rules show, hide or require a field depending on the values of others.
- Changing a field's type first counts the assets affected and blocks a conversion that would lose data. A field cannot be deleted while a rule, page or data source still uses it.
- Assets with a required field missing show an Incomplete metadata notice that lists the empty fields. The asset library page gives an overview.
Frequently asked questions
What is the difference between a metadata schema and metadata standards?
A metadata schema is the set of fields one system or organisation uses. A metadata standard is a schema or value list published for shared use, such as Dublin Core, IPTC or ISO 3166. Most schemas combine company-specific fields with standard ones.
What is an example of a metadata schema?
Dublin Core is a published one with 15 fields. A company schema for product photos might hold asset type, product line, product, SKU, colour, region, photographer and usage rights, each with a type and a list of allowed values.
How many fields should a metadata schema have?
As few as cover the searches people actually make. For marketing libraries that is often five to ten shared fields, plus a few per asset type.
Related terms
Look at a working metadata schema
Open assets of different classes in Nordi's library to see the fields each class defines, which ones are required, and how the vocabulary fields narrow each other.
You enter Nordi’s workspace as an administrator.