Culture, Places and the Public Graph: CIDOC-CRM, GeoSPARQL and Wikidata
Museums solved a modelling problem that enterprises are still failing at: how to record contested, partial, evolving knowledge about the same object from multiple sources without pretending to certainty. A curator cannot write that a vase was made in 480 BC as a simple attribute, because that date is somebody’s attribution, published in a particular paper, disputed by a rival. Heritage informatics responded by making events and attributions first-class entities rather than fields. The result, CIDOC CRM, is one of the most intellectually serious domain ontologies in existence, and it sits alongside two other public-graph pillars every practitioner should know: GeoSPARQL for places and Wikidata for everything else.
CIDOC CRM: event-centric modelling as standard
The CIDOC Conceptual Reference Model is the ISO-standard ontology for cultural heritage information integration. The content of ISO 21127:2023 corresponds to community version 7.1.3 of the model, an update produced through collaboration between the ISO technical committee for information and documentation, TC 46/SC 4, and the CIDOC CRM Special Interest Group working on behalf of ICOM’s International Committee for Documentation. The SIG is a volunteer community of international experts and has stewarded the model through more than two decades of development.
Structurally, CRM is a compact set of classes, conventionally numbered with an E prefix, and properties numbered with a P prefix. Persons, human-made objects, places, time-spans, events, activities and appellations are the backbone. The design commitment that makes it powerful is that almost nothing is asserted directly between an object and a value. A production event links the object to its maker, its place and its time-span. An acquisition event links it to owners. An identifier assignment links it to a museum number, and an attribution is itself an activity carried out by somebody at some time. Provenance, disagreement and change of ownership therefore have somewhere to live, which is exactly what a plain attribute model cannot offer.
Access is straightforward for practitioners: the RDF encodings, class and property definitions and the extension family, including archaeological, scientific observation and library-oriented extensions, are published openly at cidoc-crm.org, while the ISO text itself is a paid document. The deployment example most often cited is ResearchSpace, funded by the Andrew W. Mellon Foundation and developed with the British Museum, where museum catalogue data was mapped to CRM and published as an RDF graph with a research environment on top, running on an RDF store with semantic search and visualisation. National archives have followed the same route, with published work on migrating Portuguese archival description from ISAD(G) to a CRM-based linked data model.
What breaks · the attribution recorded as an attribute
A collections migration flattens the catalogue for speed: each object gets a creation date, a maker and a place as plain properties. The vase acquires dateCreated 480 BC, and the record looks clean.
The 480 BC was Beazley’s attribution, published in a specific paper, and a 2019 reassessment argues for 460 BC on stylistic grounds. In the flattened model there is exactly one slot, so the migration must either overwrite one scholar with another, silently, or invent parallel fields that no query understands. Both destroy the thing the discipline exists to preserve: who claimed what, when, on what evidence. Worse, the model cannot express that the two dates are competing claims about one production event rather than two production events, so any aggregation over the collection double-counts or arbitrarily picks. The event-centric answer is the whole point of the standard: the production is an event, each dating is an attribution activity carried out by an actor at a time with a source, and disagreement becomes data instead of a merge conflict. This is the register’s provenance discipline, where derived facts are separable from told facts, arriving from a discipline that got there thirty years earlier.
GeoSPARQL: places you can query
GeoSPARQL is the Open Geospatial Consortium standard that gives RDF a spatial vocabulary and SPARQL a spatial query capability. Version 1.1 was published in 2024 as OGC 22-047, roughly a decade after the original, and it contains no breaking changes to 1.0. The model is deliberately small: features are things with spatial extent, geometries are their representations, and geometry literals are serialised in well-known text or GML, with GeoJSON support added in 1.1. On top sit the topological relation vocabularies, the Simple Features, Egenhofer and RCC8 families, which give you predicates for contains, intersects, touches, overlaps and their relatives, plus query functions for distance, buffering and area. Version 1.1 also added a SHACL validator for GeoSPARQL data and a machine-readable vocabulary of the standard’s rules and functions, which tells you something about where the wider ecosystem is heading: shapes as the delivery mechanism for conformance. The specification is public at the OGC GeoSPARQL site.
The reason this matters outside geography is that place is the most common join key in public data, and it is the one most often botched. Two datasets that both mention Camden mean different polygons, at different dates, under different administrative regimes. GeoSPARQL lets you keep the geometry and the identity separate and query the relationship rather than assume it. National mapping agencies have proved the pattern: Ordnance Survey published open data products including the administrative geography of Great Britain, Code-Point Open and its gazetteer as linked data with SPARQL endpoints, and Geoscience Australia works with the Australian Bureau of Statistics and the environment department on a Location Index linking population, environmental and geographic information through linked data.
Wikidata and DBpedia: the public graph
Wikidata is the largest general-purpose public knowledge graph, containing over 122 million items in early 2026, all licensed CC0 with no attribution requirement at all. Its data model is more sophisticated than most people notice. An item carries statements, each statement is a property and value pair, and each statement can carry qualifiers, for example a point in time or a valid-in period, and references, pointing at the source that supports it. That is statement-level provenance and temporal qualification built into the base model, which is precisely what most enterprise graphs bolt on badly later. Access is through the public SPARQL query service, dumps, and the entity data endpoints at wikidata.org.
Two developments have changed how practitioners use it. The Wikidata Embedding Project, launched on 1 October 2025 by Wikimedia Deutschland with Jina.AI and DataStax, vectorised roughly 120 million items for semantic search and shipped Model Context Protocol tools for entity and property search, relationship retrieval and SPARQL execution. The largest public knowledge graph is now natively accessible to agents, which is the practical version of the argument that MCP is becoming the new SPARQL endpoint. DBpedia remains the complementary resource, extracting structured data from Wikipedia article content under a share-alike licence, and is often better for text-derived abstracts and multilingual article links while Wikidata is better for curated statements and identifiers.
Reuse discipline matters here. Wikidata is not authoritative and does not claim to be; it is a collaboratively edited aggregation whose quality varies by domain and whose references range from national registers to nothing at all. Filter by reference quality for any claim that carries risk. Contributing back is genuinely worthwhile if your organisation owns identifiers: adding an external identifier property that maps your registry to Wikidata items turns your namespace into part of the public join fabric, which is a distribution strategy as much as a data one.
| Resource | What it is and does | Maintainer | Licence and access | Real deployment |
| CIDOC CRM | Event-centric ontology for cultural heritage integration; production, acquisition, attribution and identifier assignment as modelled events | CIDOC CRM Special Interest Group for ICOM CIDOC, with ISO TC 46/SC 4 | RDF encodings openly published; ISO 21127:2023 text paid; version 7.1.3 corresponds to the ISO edition | ResearchSpace with the British Museum; national archive linked data migrations |
| GeoSPARQL 1.1 | Spatial vocabulary and SPARQL functions for RDF: features, geometries, topological relations, distance and buffer, plus a SHACL validator | Open Geospatial Consortium standards working group | Open standard, OGC 22-047, published 2024; public GitHub repository | Ordnance Survey linked data products with SPARQL endpoints; Geoscience Australia Location Index |
| Wikidata | General-purpose knowledge graph with statement-level qualifiers and references; over 122 million items | Wikimedia Foundation and volunteer community, with Wikimedia Deutschland engineering | CC0, no attribution required; public SPARQL service, dumps and MCP tools | Wikidata Embedding Project from 1 October 2025 vectorised around 120 million items for semantic and agent access |
| DBpedia | Structured data extracted from Wikipedia content, with multilingual links and abstracts | DBpedia Association and community | Open share-alike licensing; SPARQL endpoints and dumps | Long-standing entity linking and text enrichment resource in NLP pipelines |
Check yourself
You match a person in your registry to a Wikidata item with high confidence. What should your data record?
- Keep your own identifier and add a mapping to the Wikidata item, with predicate, confidence and date.
- Replace your identifier with the Wikidata Q-number, since it is the public join key.
- Assert owl:sameAs between your record and the Wikidata item so reasoners merge them.
- Copy the Wikidata statements into your record so the data is local and fast.
Show the answer, and why each wrong option is wrong
A is correct. Your record keeps its identity and gains an external assertion. When the public graph changes, and items are merged, split and redirected routinely, you degrade to a stale mapping rather than a corrupted identity.
B hands your identity to a collaboratively edited resource: a later merge upstream silently redefines what your record is about, and you cannot audit the change because you no longer hold the identifier. C is the strongest possible claim, made on the strength of a match, and it merges every property in both directions forever, which is the same cannon the crosswalk lesson warned about firing across registries with different identity criteria. D confuses caching with modelling: you inherit the public graph’s errors as your own assertions with no reference back, and you lose the very provenance that made the public statements evaluable.
Entity linking against public graphs, properly
The pattern that works is four steps and one rule. Generate candidates by searching labels and aliases, not by exact string match, because public graphs carry alternate names for a reason. Disambiguate with type and context constraints: restrict to the expected class, then score against contextual signals such as date range, place or associated entities. Verify against a second identifier where possible, since most Wikidata items for organisations, people and places carry external identifier properties pointing at national registers, library authority files or geographic gazetteers, and agreement between two independent identifiers is far stronger evidence than a string match. Record the outcome as a mapping with an explicit predicate, a confidence value and a date, in the SSSOM style covered in the crosswalk lesson.
The rule: never overwrite your own identifier with a public one. Your record keeps its identity and gains an assertion that it closely or exactly matches an external item. That way, when the public graph changes, and it will, because items get merged, split and redirected, your data degrades to a stale mapping rather than a corrupted identity. Heritage learned this decades ago, which is why CIDOC CRM models identifier assignment as an event carried out by an actor. The same modelling instinct is what separates a public graph integration that survives five years from one that quietly rots.
