Appearance
Apply CIDOC CRM when your questions are fundamentally about events, processes and relationships across heterogeneous cultural collections, and when you need to integrate data from several institutions on shared semantics. Avoid it when you only need flat item discovery, lack ontology expertise, or face a tight deadline. CIDOC CRM is powerful precisely because it is event-centric, and that same property is what makes it expensive to model. The decision is about fit, not prestige.
What problem does CIDOC CRM actually solve?
Most catalogues describe an object with flat attributes: title, date, creator, place. CIDOC CRM instead models the events that produced those facts. A "creation date" becomes a production event (E12 Production) that happened at a time-span, was carried out by an actor, and brought the object into being. This indirection is the whole point: it lets you record how facts came to be, integrate conflicting accounts, and answer questions about process that flat metadata simply cannot.
turtle
@prefix crm: <http://www.cidoc-crm.org/cidoc-crm/> .
<item/MS-0421> a crm:E22_Human-Made_Object ;
crm:P108i_was_produced_by <event/prod-MS-0421> .
<event/prod-MS-0421> a crm:E12_Production ;
crm:P14_carried_out_by <person/p-0093> ;
crm:P4_has_time-span <ts/1685> .Five flat attributes have become a small graph. That is the trade-off in one example.
When is CIDOC CRM clearly the right tool?
Reach for it when you can answer yes to most of these:
- Your research questions are about provenance, object biographies or processes, not just discovery.
- You must integrate data from multiple institutions with different local schemas.
- You need to represent conflicting or uncertain assertions with their sources.
- You have access to ontology expertise and time to model carefully.
- The dataset will be maintained over years, justifying the upfront cost.
Provenance research, museum collection integration and digital prosopography are textbook fits.
When should you walk away from it?
Be honest about these counter-signals:
| Signal | Better choice |
|---|---|
| Flat item discovery is the goal | Dublin Core + schema.org |
| Small team, no ontology expertise | SKOS + simple RDF |
| Tight deadline, MVP needed | Lightweight profile, defer CRM |
| Mostly subject indexing | SKOS thesaurus |
| One homogeneous collection | Domain-specific schema |
There is no shame in not using CIDOC CRM. Misapplied, it turns a two-week project into a six-month modelling exercise that nobody on the team can maintain.
How heavy is the cost, really?
The cost is modelling time and triple inflation. A single object that needed five triples in Dublin Core may need twenty or more in full CIDOC CRM once you model production, acquisition, current location and dimensions as events. That affects storage, query complexity, and crucially the learning curve for everyone who touches the data. Budget weeks, plan for ongoing review, and expect to train staff.
Do you have to swallow the whole ontology?
No, and you should not. CIDOC CRM has hundreds of classes and properties. Mature projects define an application profile that constrains it to the handful of classes their data needs, often a dozen E classes and twenty P properties. Tools like the 3M mapping tool, X3ML, or Sparnatural help author and constrain these mappings. Document the profile so every contributor models consistently.
Can you blend CIDOC CRM with simpler vocabularies?
Yes, and most production systems do. A pragmatic layering:
- CIDOC CRM for events, relationships and provenance.
- Dublin Core or schema.org for lightweight discovery metadata.
- SKOS for the controlled vocabularies your CRM events reference.
This gives search engines flat fields to index while preserving the rich event model for researchers. You get both audiences without forcing either to deal with the wrong layer.
A decision rule you can apply today
Write down your top three research questions. If they contain verbs of process, "was produced by", "was acquired from", "moved to", CIDOC CRM earns its keep. If they are mostly "find me objects about X from period Y", lighter vocabularies will reach a usable result faster and cheaper.
Key Takeaways
- CIDOC CRM is event-centric: it models how facts came to be, not just the facts.
- Choose it for provenance, object biographies and cross-institution integration.
- Avoid it for flat discovery, small teams without expertise, or tight deadlines.
- The real cost is modelling time and triple inflation, often four times the triples of flat metadata.
- Constrain the full ontology with an application profile instead of using every class.
- Layer it with Dublin Core, schema.org and SKOS to serve both researchers and search engines.
Frequently Asked Questions
What is CIDOC CRM in one sentence?
CIDOC CRM (ISO 21127) is an event-centric ontology for cultural heritage that models how people, objects, places and times connect through events such as production, acquisition and movement, rather than through flat attributes.
When is CIDOC CRM the right choice?
When your research questions are about events, processes and relationships across heterogeneous collections, for example provenance chains or object biographies, and you need to integrate data from multiple institutions.
When should I avoid CIDOC CRM?
When you mainly need flat resource discovery, have a small team without ontology expertise, or face a tight deadline. Dublin Core plus SKOS will serve item-level catalogues far more cheaply.
What is the real cost of adopting it?
Modelling time and expertise. Every simple attribute becomes a multi-node event path, so triple counts and the learning curve rise sharply. Budget weeks of modelling and ongoing review, not days.
Do I have to use raw E and P codes?
You can, but most teams build an application profile that constrains the full ontology to the classes and properties their project needs, which keeps modelling tractable and consistent.
Can I combine CIDOC CRM with Dublin Core?
Yes. A common pattern is CIDOC CRM for the event and relationship layer and Dublin Core or schema.org for lightweight discovery metadata on the same resources.