Cultural heritage has comprehensive standards for describing what things are. What has been harder to come by is how to effectively use them to let the data achieve their best potential, including finding them, accessing them and (re)using them, especially within automatic queries and analysis. What has been missing so far is the layer underneath: the one that lets software check a real file, understand it, and pass it on. This is how the HERITALISE project built that layer by leveraging the OGC building blocks approach, i.e. the definition, storage and documentation of small modular pieces of specifications, facilitating validation, standard-compliance and scalability (see below). The results are published as bblocks-heritage, a public register of 27 reusable building blocks. The AI-assisted method behind it transfers to any domain.
How to read this post. The main text is written for people who build or specify data systems. The indented “In plain words” boxes say the same thing without the technical vocabulary, for heritage professionals who care about the outcome rather than the mechanics. Either track works on its own.
Start with a room in Venaria
The Reggia di Venaria, near Turin, is one of the pilot sites in the HERITALISE project, and the first to bring a detailed set of documentation requirements. Take a single room in it: the Galleria Grande, Filippo Juvarra’s great gallery. A documentation team needs to record the gallery, the building it sits in, the site that building belongs to, the condition of its surfaces, the laser scans and photogrammetry that captured it, and who did all of that, when, and with which instrument.
Ask which standards to use, and the field gives a good, well-established answer. Describe the objects, places, actors, and events with CIDOC-CRM, the ISO conceptual reference model the community has converged on, and which underpins current European work such as the Heritage Digital Twin Ontology behind the European Collaborative Cloud for Cultural Heritage. Record who did what, from what, and with which instrument, using PROV-O. Put things in space with GeoJSON. Use SOSA/SSN for sensor readings, DCAT for dataset metadata, EDM if the records should eventually reach Europeana.
That is only half the picture, because the gallery is also a building standing in a landscape. The moment the documentation includes the 3D and survey side, a second family of standards applies: IFC for the BIM model of the building itself, CityGML and LandInfra for the urban and landscape context around it, INSPIRE for anything that has to line up with European geospatial data. Heritage documentation sits precisely on the seam between the semantic world and the geospatial and BIM world, and that seam is where most of the practical difficulty lives.
Each of those standards is the right answer to the question it was built for. What none of them gives you, by design, is the next thing down: an actual data model for your use case. Somebody still has to decide what a record of this gallery contains, what a condition assessment looks like as a set of fields, how a room relates to the building around it and to the scan that captured it, and then tie every one of those decisions to the standard term it stands for, in a form software can act on. A conceptual reference model tells you how to think about heritage information. Deliberately, it does not do that modeling for you, and it cannot tell software that the link to the parent site is missing.
So, every project does the modeling itself, and every project does it differently. That is how you end up with datasets that all correctly claim to follow the same standards and still cannot be used together. Doing that modeling once, in the open, and publishing it in a form software can act on, is the work this post is about.
In plain words. Everyone in heritage broadly agrees on how to think about the information. There are mature, internationally agreed models for objects, places, people, events, buildings, and 3D data. What none of them hands you is the practical part: what, exactly, goes in a record about this room, in a form a computer can use. Each project works that out for itself, which is why two teams can both follow the same standards faithfully and still be unable to read each other’s files. We did that work once, for heritage, and published it for anyone to use.
What a building block is
An OGC building block is a small, self-contained specification, or a reusable part of one. Each block is a data model for one kind of thing, and it bundles, in a single package under a stable name like ogc.heritage.building:
- a schema: the exact fields a valid record has, in a form software checks automatically;
- a semantic mapping: for each field, the standard term it stands for, whether that is CIDOC-CRM’s “forms part of” behind a parentSite field or PROV-O’s “was generated by” behind the scan that produced a model, which is what lets a plain data file be turned into a knowledge graph;
- validation rules for that graph, catching the errors a field-by-field check cannot see;
- documentation in ordinary language;
- worked examples, tested automatically every time the block changes;
- where useful, ready-made conversions to other specifications.
A register is a published, maintained collection of such blocks. OGC Blocks is the framework for building them, and public registers already exist for many general-purpose domains.
Blocks compose, and this is the mechanism everything else rests on. The obvious form is profiling: take another block wholesale, then constrain or extend it, without redefining it or forking it. The less obvious form matters more. A block is not restricted to a single parent. It can inherit from several at once, compose parts of others, narrow what it inherits, and offer a choice between alternative parents, all in one definition. Profiles get built by combining those techniques, not by specializing down a single line of descent.
That is what keeps a data model the right size. Broad standards are written for wide applicability, so adopting one directly tends to leave you overspecified and underspecified at once: carrying terms and options that have nothing to do with your data, while still unable to express the one distinction your use case turns on. And frequently no single standard reaches far enough by itself, whatever you do to it. Combining lets you drop what does not apply, add the surgical detail, and borrow from a second or third specification where the first stops. Data written against one of our blocks stays valid against every block it builds on, all the way up. The next section shows what that looks like on a real room.
Together that covers the three things the pilots actually needed:
- Describe. Everyone involved, from the conservator entering records to the developer building tools on top of them, works from one precise definition of the data.
- Validate. The schema catches structural errors; the graph rules catch the meaningful ones, such as a missing relationship or an object typed as the wrong kind of thing.
- Transform. On two levels. A block’s semantic mappings (its own, plus everything inherited from the blocks it builds on) turn a plain record from a partner’s system into a queryable, linkable graph, ready for Europeana-style aggregation. And blocks can publish crosswalks: ready-to-run conversions to other blocks and specifications, shipped with the block so nobody downstream reimplements them.
In plain words. A building block is a small specification for one kind of information: what a record about a building, a room, or a survey must contain, what each part of it means, and how to tell a correct record from a broken one. It lives at a web address that does not change, so software can act on every part of it rather than a person having to read it and interpret. Blocks build on each other, and on more than one at a time: a historic building is a heritage object with a few additions, and a record of a 3D scan can satisfy the heritage standard, the provenance standard and the mapping standard at once, instead of forcing you to choose.
The answer for the Galleria Grande
With that in hand, “how do we structure this?” has a concrete answer:
place (CIDOC-CRM E53 Place, profiles the standard geospatial feature block)
└── heritage-site (CIDOC-CRM E27 Site) → the Reggia di Venaria
└── building (CIDOC-CRM E22 Human-Made Object, IFC alignment)
└── architectural-space (CIDOC-CRM E22, IFC IfcSpace) → the Galleria Grande
Each level adds only what is new at that level and inherits the rest. building adds a link to its parent site and inherits everything else, down to the url field mapped to DCAT’s access URL, from the heritage-object block above it. The IFC alignments carried by building and architectural-space are what let a record on this chain travel between the heritage catalog and the BIM model of the same room without a bespoke translation each time.
Now add the laser scan of one bay of that gallery, and combining several standards starts to earn its keep. A scan is three things at once: something with a provenance history, something located in space, and something with a heritage meaning. No single standard covers all three, so digital-representation-feature combines them. It inherits PROV-O’s entity for the provenance. For the location it offers a choice between a GeoJSON (JSON-FG) feature and a topo-feature, depending on whether the record carries its own geometry or points at somebody else’s. Its CIDOC-CRM anchoring rides in the semantic layer. Then it adds its own properties on top and narrows the inherited identifier to require a real URI. One record, three specifications satisfied at once, none of them forked, and the record still a valid instance of each.
That choice about geometry is the interesting part. The scan of the bay covers exactly the bay it surveyed, so rather than repeat that polygon inside the survey record, the record points at the architectural space’s own geometry by reference. The two cannot drift apart later, because there is only one copy. These are explicit, machine-readable links between data models, not a compatibility claim in a document.
The same chain describes Villa Portelli, a 19th-century residence in Malta and the project’s other pilot site: the same four levels, a different building in a different country, no new schema required. One definition, two pilots, two worked examples. That reuse across unrelated sites is the practical payoff of anchoring blocks to CIDOC-CRM classes rather than to whatever vocabulary each site happens to use locally.
In plain words. Four nested specifications: a place, a heritage site, a building on it, a room inside the building. Describe the room and you automatically get everything already agreed about the building, the site, and the place it stands in. The same four fit a Baroque royal palace in Italy and a 19th-century house in Malta, which is exactly what you want: two teams documenting very different things, in a way a third party can still read. And because each record is also a proper geospatial object, a survey of one room can simply point at that room’s outline rather than carry a second copy of it that someone will later have to keep in step.
The audit that came before any authoring
The first real decision was about what not to write. Published, maintained registers already exist for most of the generic layers:
| Need | Reused from | Used for |
| Provenance | The PROV register | Production history, restoration events, derivation chains |
| Concept schemes | The SKOS register | Narratives, controlled vocabularies |
| Dataset and geospatial metadata | The GeoDCAT / OGC API Records register | Dataset-level metadata; an RDF-friendly substitute for ISO 19115 |
| Sensor observations | The SensorThings register (SOSA/SSN) | Observations and measurements at heritage sites |
What nobody publishes is the layer where heritage is genuinely specific: CIDOC-CRM and EDM applied to physical heritage objects, places, actors, events, and their digital representations, sitting alongside the geospatial and BIM standards rather than ignoring them. That gap is the register’s actual contribution. Everything authored in bblocks-heritage anchors to a CIDOC-CRM, CRMdig, CRMsci, or EDM class and composes the imports above instead of duplicating them. digital-representation is built by composing the imported provenance block, not by reinventing provenance fields.
This “what exists, versus what is genuinely missing” audit is worth doing carefully and writing down. It is the difference between a register that adds coverage and one that adds noise to an already crowded standards landscape.
The audit even short-circuited an entire use case. One HERITALISE use case is about observations and measurements at heritage sites: sensor readings, plain and simple. When its requirements went through the same cross-register search, every one of them landed on the existing SOSA/SensorThings blocks, and the correct number of new blocks to author turned out to be zero. A method that can confidently tell you “you need nothing new here” is doing exactly its job. The expensive failure mode in this space is the register that reinvents sensor observations with heritage vocabulary sprinkled on top.
In plain words. Before writing anything, we checked what already existed. Provenance, vocabularies, dataset catalogs, and sensor readings are solved problems with published, maintained answers, so we reused them instead of producing yet another heritage-flavored variant. For one of the project’s use cases the honest conclusion was that nothing new was needed at all. Knowing when not to invent something is as valuable as inventing it.
Four moves, repeated per pilot
The method itself is short enough to state completely:
- Capture requirements in a consistent tabular format. Each pilot’s needs arrived as a table, one row per data need. That alone made them enumerable and trackable, even though the content inside each cell was still mostly free-form prose written by domain experts rather than by schema authors.
- Map to standards first, write schemas second. Before a single schema existed, every requirement got a documented mapping to whatever actually covers it: a CIDOC-CRM property, a PROV relation, a sensor observation class, an IFC concept. That mapping is prose with rationale, independent of any block identifier, and it remains the authoritative record of why each block looks the way it does. Requirements already covered by an existing block or an imported register needed only an example, not a new schema. Several of Venaria’s garden-related requirements resolved that way.
- Author one block at a time, through a fixed checklist. Check whether the thing already exists and can simply be reused; write the schema; map every field to its CIDOC-CRM, PROV, EDM or IFC term; write the graph validation rules; write a plain-language description; and write at least two examples grounded in real pilot data, one Venaria-flavored and one Malta-flavored where possible. Two examples per block is not decoration. Examples grounded in pilot data are the concrete evidence that a block actually covers the requirement it claims to.
- Validate before moving on. Every example is checked automatically, three ways: against the schema, through the conversion into a graph, and against the graph rules once converted. A block is not done until all of those pass. We deliberately did not bulk-generate a batch of blocks and validate at the end. Several non-obvious issues only ever surfaced at validation time, and catching them one block at a time was far cheaper than untangling them across many at once.
That last rule earned its keep early. An earlier standards analysis we inherited included hand-written validation rules produced by a different AI assistant and never actually run. We treated it as a starting reference, not as ground truth, and carried nothing forward without putting it through the real checks. “AI-generated” and “AI-generated and verified” are not the same thing.
In plain words. Write down what you need, one line at a time. Work out which existing standard covers each line before designing anything. Then build one piece at a time, and prove each piece works on real examples from a real site before starting the next. Nothing is accepted because it looks plausible, including anything an AI produced.
The part where the AI earns its place
We used Claude Code for the authoring itself: reading the requirements, writing the schemas and semantic mappings, running the validation, iterating against the failures. The reason it worked as well, and as hands-off, as it did is that the assistant did not start from zero. It could draw on a substantial set of resources, tools, and services whose entire purpose is to support an AI assistant doing this kind of job. Much of that existed before HERITALISE. Building this register improved it and filled in gaps that only surface once a method is taken through a real domain end to end, which makes it as much an output of this story as the register is.
Skills, not guesses. An Agent Skill is a packaged set of instructions and reference material that an AI assistant loads when it encounters a task of a given kind: in effect, the written-down expertise of somebody who has done the job before, in a form the assistant can pick up on demand. We build and maintain OGC LLM Skills, a public repository of them for OGC Blocks work. One skill covers authoring blocks; another covers the downstream side, validating data against published blocks and converting it into a graph. Alongside them, a search service lets the assistant look through every published register, by keyword and by meaning, before anything new gets written. That is what turned judgments like “don’t reinvent provenance” and “the observations use case needs nothing new at all” into fast, confident checks rather than manual spec hunts.
A working memory that outlives the session. A living plan file tracked scope, status, authoring order, the dependencies between blocks, and, most valuably, a running log of small hard-won lessons discovered at validation time. Individually those lessons are trivia. Collectively they are the difference between the twenty-fifth block sailing through validation and every block re-tripping the same wire the first one found. Each was learned by running the real checks and reading the real error, then written down where the next session would find it. The skills and the plan file are what let that knowledge accumulate across the whole register instead of evaporating every time a session ended.
In plain words. The AI assistant was not asked to improvise. It was given written-down expertise about this exact kind of work, a search service so it could check what already exists before proposing anything, and a notebook it kept updating so that a lesson learned on Monday was still known on Friday. That combination is why the work is reliable enough to publish, and all of it is public, so the next project does not start from zero either.
What is in the register today
Everything published and validated, under the ogc.heritage. prefix. heritage-object, place and actor carry the core entities. heritage-site, building and architectural-space are the chain this post has been following. survey-dataset and condition-assessment cover the work done to a site, oral-history and historical-statement the things said about it, and the feature envelopes make any of them a first-class geospatial object. The rest, from monitoring-threshold to route, are in the register.
Every block is anchored in the standards it draws on, most often CIDOC-CRM, CRMdig, CRMsci, PROV-O or EDM, and many of them in several at once. Every block has a validated schema, a semantic mapping, graph validation rules where it introduces constraints of its own, and at least two examples, most of them grounded directly in Venaria or Malta pilot data. Browse them all at ogcincubator.github.io/bblocks-heritage.
This is not a heritage-only recipe
If your problem reads like “I have a use case and some data, and I need to model it, validate it, map it to something (especially semantics), and possibly transform it,” the same path applies whatever the domain:
- A worked example at full scale: bblocks-heritage (source), profile chains, validation rules, examples and all.
- The skills, ready to install: OGC LLM Skills (source) publishes the authoring and consuming skills, ready for you or your assistant to install. Works with claude.ai, Claude Code, and the Claude API.
- The framework: the OGC Blocks documentation explains the approach and how to start a register of your own.
The method in one line: audit what already exists before modeling anything, map requirements to standards before mapping them to schemas, model and validate one piece at a time against real data, and write down every non-obvious lesson so it only costs you once. It is an iterative loop, not a specification handed down in one pass. An AI assistant with the right domain skills makes that loop fast, which is what makes iterating at this granularity affordable at all. It does not replace the loop.
For HERITALISE, that loop turned prose requirements from real heritage sites into a public data model: 27 blocks, every one anchored to standards the community already trusts, carrying its own validation and its own semantics, and built to meet the geospatial and BIM side rather than to ignore it. The resources, tools, and services that made it possible (the skills, the search service, the method itself) are published, tested on a real domain, and waiting for the next one.
