Appearance
Significant properties are the characteristics of a digital object that must survive over time for it to stay authentic and usable to its designated community. Defining them means deciding, for a given object type, exactly what counts as "the same file" after a migration — the text, the layout, the colours, the formulas, the behaviour — and writing those down as acceptance criteria. Get this right and migration becomes a checkable process; get it wrong and you either lose meaning silently or try to preserve everything and can afford nothing.
What exactly is a significant property?
It is the answer to: "If this changed, would the object lose its value or authenticity?" For a scanned medieval charter, the legible text and the visible damage and ink colour are significant; the exact TIFF compression flag is not. For a spreadsheet, the cell values and the formulas that produced them are significant; the font is usually not. The property is significant if your designated community would consider the object compromised without it. That community link is why significance is a judgement, not a fixed list.
Which categories should I check?
Work through five categories so nothing is overlooked:
| Category | Question to ask | Example for a scanned page |
|---|---|---|
| Content | What information must remain? | The legible text, marginalia |
| Structure | How is it organised? | Page order, sections |
| Appearance | What must look the same? | Colour fidelity, layout, ink tone |
| Behaviour | What must it do? | (None for a static scan) |
| Context | What gives it meaning? | Provenance, original arrangement |
Behaviour is the category most people forget — and it is exactly what matters for software, databases and interactive works.
How do I write significant properties down?
Make them concrete and testable. Vague statements ("preserve the look") cannot be checked. Compare:
text
Object type: word-processed report (.docx)
Designated community: policy historians
Significant properties:
- Content : full text, including footnotes and tables (MUST)
- Structure: heading hierarchy and reading order (MUST)
- Appearance: page layout approximate, not pixel-exact (SHOULD)
- Behaviour: none (tracked changes NOT preserved)
- Context: author, date, originating department in metadata (MUST)Now a migration to PDF/A has clear pass/fail criteria, and the decision to drop tracked changes is explicit and defensible.
Who decides, and how?
Significance is a curatorial decision made with people, not in isolation. Consult the designated community about what they actually use, and the creator where possible about what they intended. Then balance that against feasibility and cost — some properties are simply too expensive to preserve with current tools. Record the rationale. When an auditor or a future curator asks why tracked changes were dropped, the documented decision is your defence.
The danger of preserving everything
The most common mistake is declaring every property significant. It feels safe, but it makes preservation unaffordable and migration impossible — no format conversion preserves everything, so an all-significant spec means you can never migrate and must rely solely on emulation. Discipline means choosing the few properties that carry the object's meaning and authenticity, and consciously letting the rest go. A short, prioritised list (MUST / SHOULD / MAY) beats an exhaustive one.
Putting it into the workflow
Define significant properties at appraisal, before you choose a preservation strategy, because they determine that strategy. If appearance and behaviour are both must-keeps and no format captures them, you are pushed toward emulation. If content and structure dominate, migration to an open format works. Store the properties in your preservation metadata alongside the object, so future curators inherit the reasoning, not just the files.
Key Takeaways
- Significant properties are the characteristics an object must keep to stay authentic to its community.
- They define testable acceptance criteria for migration — pass or fail, not guesswork.
- Check five categories: content, structure, appearance, behaviour, context.
- Behaviour is the most-forgotten category and matters most for software and databases.
- Write properties concretely with MUST / SHOULD / MAY priorities, not vague intentions.
- Decide with the designated community and creator, then document the rationale.
- Avoid declaring everything significant — it makes migration impossible and preservation unaffordable.
Frequently Asked Questions
What are significant properties in digital preservation?
Significant properties are the characteristics of a digital object that must be preserved for it to remain authentic and usable to its designated community, such as text content, layout, colour fidelity or interactive behaviour.
Why do significant properties matter for migration?
They define your acceptance criteria: when you migrate a file to a new format, you check that the significant properties survived, so any loss is a deliberate, documented decision rather than an accident.
Are significant properties the same for every object?
No. They depend on the object type and on what your designated community needs; a scanned letter, a spreadsheet and an interactive artwork each have very different significant properties.
Who decides what is significant?
Significance is a curatorial judgement made with input from the designated community and the object's creator where possible, balanced against the cost and feasibility of preservation.
What categories of significant properties exist?
Common categories are content, structure, appearance, behaviour and context; thinking through each in turn helps you avoid overlooking a property that matters.
Can I have too many significant properties?
Yes. Declaring everything significant makes preservation unaffordable and migration impossible; the skill is choosing the few properties that genuinely carry the object's meaning and authenticity.