Appearance
To write a metadata application profile, document — element by element — exactly which fields your project uses, what each means in your context, whether it is mandatory, how many times it can repeat, and which controlled vocabulary fills it. An application profile is your project's local rulebook: it takes general standards like Dublin Core or MODS and pins down precisely how you apply them. Here is a step-by-step method, a worked table, and the pitfalls to avoid.
What is an application profile and why write one?
A standard tells you what is possible; an application profile tells your team what is required. Dublin Core permits any of fifteen elements, repeatable or not, with no vocabulary rules. That freedom is exactly the problem: without a profile, two cataloguers will record dates, names and subjects differently. The profile removes ambiguity and becomes the single reference you check disputes against.
Step 1 — Define scope and audience
Write down, in a paragraph, what the profile covers and who uses it: "Descriptive metadata for digitised estate maps, 1700–1900, catalogued by two part-time archivists, harvested by Europeana." Scope decisions cascade — they tell you which standards to draw from and how strict to be.
Step 2 — Choose your source standards
Pick the standards your elements come from. You can — and usually should — mix:
- Dublin Core /
dctermsfor the descriptive core. - MODS where you need typed names or hierarchy.
- PREMIS for preservation fields.
- Local terms only where nothing standard fits.
This "mix-and-match" approach is the heart of the Dublin Core application-profile model. Reusing standard elements keeps you interoperable.
Step 3 — Specify each element
This is the substance. For every element record six things: definition, obligation, cardinality, vocabulary, example, and source. A fragment:
| Element | Definition | Obligation | Cardinality | Vocabulary / rule | Example |
|---|---|---|---|---|---|
dcterms:title | Map title as on the object | Mandatory | 1 | Transcribe verbatim | "A Mapp of the Mannor of Henley" |
dcterms:creator | Surveyor or maker | Mandatory | 1..n | LC NAF; "Surname, Forename" | "Hodskinson, Joseph" |
dcterms:spatial | Place depicted | Recommended | 0..n | Getty TGN URI | tgn:7011361 |
dcterms:created | Date drawn | Mandatory | 1 | EDTF | 1782 |
dcterms:rights | Rights statement | Mandatory | 1 | rightsstatements.org URI | Public Domain |
Obligation and cardinality are what a bare schema does not give you — they are why the profile exists.
How do you express obligation and cardinality?
Use a consistent, tiny vocabulary so the table reads unambiguously:
- Obligation: Mandatory / Recommended / Optional.
- Cardinality:
1(exactly one),0..1(optional single),1..n(one or more),0..n(any number).
Decide these by asking, for each element, "would a record be usable without it?" Mandatory means no.
Step 4 — Bind vocabularies and value rules
For every element that should be controlled, name the vocabulary and the exact value form. "Dates in EDTF," "places as Getty TGN URIs," "names from LC NAF as Surname, Forename." Vague rules ("a date") produce inconsistent data; precise rules ("YYYY or EDTF interval") do not.
Step 5 — Make it enforceable
Documentation guides humans; validation enforces rules. Encode the profile so violations are caught automatically. For XML, Schematron expresses obligation neatly:
xml
<sch:rule context="record">
<sch:assert test="dcterms:title">A title is mandatory.</sch:assert>
<sch:assert test="count(dcterms:created) = 1">Exactly one created date is required.</sch:assert>
</sch:rule>For RDF, the equivalent is a SHACL shape with sh:minCount/sh:maxCount. For spreadsheet cataloguing, use column data-validation rules.
What pitfalls should you avoid?
- Re-inventing elements that a standard already defines — breaks interoperability.
- Mandatory-everything, which cataloguers quietly bypass; be honest about what is truly required.
- Naming a vocabulary but no value form, so "Getty TGN" yields both labels and URIs inconsistently.
- Writing it once and never versioning it. Date and version the profile; collections outlive memories.
- No examples. A worked example per element resolves more questions than the definition does.
Key Takeaways
- An application profile is your project's local rulebook on top of general standards.
- Draw elements from multiple standards (Dublin Core, MODS, PREMIS) plus minimal local terms.
- Specify obligation and cardinality for every element — this is what a bare schema lacks.
- Bind a controlled vocabulary and exact value form to each element, with an example.
- Define scope and audience first; they drive every later decision.
- Enforce the profile with Schematron, SHACL or spreadsheet validation, not just prose.
- Version and date the profile; give every element a worked example.
Frequently Asked Questions
What is a metadata application profile?
A metadata application profile is a document that specifies, for one project, exactly which elements from one or more standards you use, what each means locally, whether it is mandatory, how often it repeats, and which vocabularies fill it. It is your local rulebook.
How is an application profile different from a schema?
A schema defines what is technically valid in a standard; an application profile narrows and constrains that standard for your specific use, adding obligation, cardinality and vocabulary rules a generic schema does not enforce.
What columns should an application profile table have?
At minimum: element name, definition, obligation (mandatory/recommended/optional), cardinality (how many times it may repeat), the vocabulary or value rule, and an example. Many add the source standard and a mapping to other schemas.
Do I need an application profile for a small project?
Even a one-page profile pays off. It stops two cataloguers recording dates differently, makes onboarding faster, and is the reference you check disputes against. Scale the detail to the project, but always write something.
Can an application profile mix elements from several standards?
Yes, that is a core purpose. The Dublin Core community formalised this as the mix-and-match approach, where you draw elements from Dublin Core, MODS, PREMIS and local terms into one coherent profile.
How do I enforce an application profile?
Encode its rules in a validation layer: a Schematron ruleset over XML, a SHACL shape over RDF, or column validations in a cataloguing spreadsheet. Documentation guides humans; validation enforces the rules.