De ontbrekende schakel tussen erfgoednormen en erfgoedgegevens

Cultureel erfgoedleeftijd heeft couitgebreid normen voor het beschrijven van wat dingen zijn. Wat moeilijker te vinden is, is Hoe ze effectief te gebruiken om het volledige potentieel van de data te benutten, inclusief het vinden, openen en (her)gebruiken ervan, met name binnen automatische zoekopdrachten en analyses. Wat tot nu toe ontbrak, is... De onderliggende laag: de laag die ervoor zorgt dat software een echt bestand kan controleren, begrijpen en doorgeven. Zo heeft het HERITALISE-project die laag opgebouwd. door gebruik te maken van de OGC-bouwsteenbenadering, dat wil zeggen de definitie, opslag en documentatie van kleine modulaire specificatieonderdelen, waardoor validatie, naleving van standaarden en schaalbaarheid worden vergemakkelijkt (zie hieronderDe resultaten worden gepubliceerd. as bblocks-erfgoedeen openbaar register van 27 herbruikbare bouwstenen. Tde AI-ondersteunde methoded erachter wordt overgedragen naar elk domein. 

Hoe dit bericht te lezen. De hoofdtekst is geschreven voor mensen die datasystemen bouwen of specificeren. De ingesprongen 'In begrijpelijke taal'-kaders zeggen hetzelfde, maar dan zonder het technische jargon, voor erfgoedprofessionals die zich meer richten op het resultaat dan op de technische details. Beide varianten kunnen afzonderlijk worden gelezen.

Begin met een kamer in Venaria.

De Reggia di Venaria, vlakbij Turijn, is een van de pilotlocaties in het HERITALISE -project en de eerste die een gedetailleerde set documentatie-eisen hanteert. Neem bijvoorbeeld één enkele ruimte: de Galleria Grande, de grote galerij van Filippo Juvarra. Een documentatieteam moet de galerij vastleggen, het gebouw waarin deze zich bevindt, de locatie waartoe dat gebouw behoort, de staat van de oppervlakken, de laserscans en fotogrammetrie die gebruikt zijn om de galerij vast te leggen, en wie dit alles heeft gedaan, wanneer en met welk instrument.

Vraag welke standaarden te gebruiken, en het vakgebied geeft een goed, beproefd antwoord. Beschrijf de objecten, plaatsen, actoren en gebeurtenissen met CIDOC-CRM, het conceptuele referentiemodel van ISO waar de gemeenschap het over eens is geworden en dat ten grondslag ligt aan huidig ​​Europees werk, zoals de Heritage Digital Twin Ontology achter de European Collaborative Cloud for Cultural Heritage. Leg vast wie wat heeft gedaan, waarvandaan en met welk instrument, met behulp van PROV-O. Plaats gegevens in de ruimte met GeoJSON. Gebruik SOSA/SSN voor sensoraflezingen, DCAT voor datasetmetadata en EDM als de gegevens uiteindelijk bij Europeana terecht moeten komen. 

Dat is slechts de helft van het verhaal, want de galerie is ook een gebouw dat in een landschap staat. Zodra de documentatie de 3D- en landmeetkundige aspecten omvat, is er een tweede reeks standaarden van toepassing: IFC voor het BIM-model van het gebouw zelf. CityGML en LandInfra voor de stedelijke en landschappelijke context eromheen, INSPIRE voor alles wat moet aansluiten op Europese geospatiale data. Erfgoeddocumentatie bevindt zich precies op het snijvlak tussen de semantische wereld en de geospatiale en BIM-wereld, en dat snijvlak is waar de meeste praktische problemen zich voordoen. 

Elk van die standaarden is het juiste antwoord op de vraag waarvoor het is ontwikkeld. Wat geen van hen je echter, bewust, biedt, is het volgende niveau: een daadwerkelijk datamodel voor jouw specifieke gebruikssituatie. Iemand moet nog steeds bepalen wat een record van deze galerij bevat, hoe een conditiebeoordeling eruitziet als een set velden, hoe een ruimte zich verhoudt tot het gebouw eromheen en tot de scan die de ruimte heeft vastgelegd, en vervolgens elk van die beslissingen koppelen aan de standaardterm die ervoor staat, in een vorm die software kan verwerken. Een conceptueel referentiemodel vertelt je hoe je over erfgoedinformatie moet nadenken. Het modelleert die informatie bewust niet voor je en kan software niet vertellen dat de link naar de bovenliggende site ontbreekt.

Elk project voert de modellering dus zelf uit, en elk project doet dat op een andere manier. Daardoor krijg je datasets die allemaal terecht beweren aan dezelfde standaarden te voldoen, maar die toch niet met elkaar te gebruiken zijn. Het eenmalig en openbaar modelleren en publiceren in een formaat dat door software kan worden verwerkt, is waar dit artikel over gaat.

Simpel gezegd: iedereen in de erfgoedsector is het er grotendeels over eens hoe je met de informatie om moet gaan . Er bestaan ​​volwaardige, internationaal geaccepteerde modellen voor objecten, plaatsen, personen, gebeurtenissen, gebouwen en 3D-data. Wat geen van deze modellen je echter biedt, is het praktische gedeelte: wat komt er precies in een verslag over deze ruimte te staan, in een vorm die een computer kan verwerken? Elk project zoekt dat zelf uit, waardoor twee teams dezelfde standaarden nauwgezet kunnen volgen en elkaars bestanden toch niet kunnen lezen. Wij hebben dat werk ooit gedaan voor de erfgoedsector en het gepubliceerd zodat iedereen het kan gebruiken.

Wat een bouwsteen is

Een OGC-bouwsteen is een kleine, op zichzelf staande specificatie, of een herbruikbaar onderdeel daarvan. Elke bouwsteen is een datamodel voor één type object en bundelt, in één pakket onder een stabiele naam zoals ogc.heritage.building :

• a schema: de exacte velden die een geldig record bevat, in een formulier dat de software automatisch controleert; 

• a semantische toewijzing: voor elk veld, de standaardterm die het vertegenwoordigt, of dat nu CIDOC-CRM's "maakt deel uit van" is, achter een oudersite Het veld of de PROV-O-aanduiding "werd gegenereerd door" achter de scan die een model produceerde, maakt het mogelijk om een ​​eenvoudig gegevensbestand om te zetten in een kennisgrafiek; 

• validatie regels Voor die grafiek is het belangrijk om fouten op te sporen die bij een veld-voor-veld controle niet zichtbaar zijn; 

• documentatie in gewone taal; 

• uitgewerkte voorbeelden, wordt automatisch getest elke keer dat het blok verandert; 

• waar nuttig, kant-en-klare conversies volgens andere specificaties. 

Een register is een gepubliceerde, bijgehouden verzameling van dergelijke blokken. OGC Blocks is het raamwerk voor het bouwen ervan, en er bestaan ​​al openbare registers voor veel algemene domeinen.

Blokken vormen een geheel, en dit is het mechanisme waarop al het andere rust. De meest voor de hand liggende vorm is profileren : neem een ​​ander blok in zijn geheel en beperk of breid het vervolgens uit, zonder het opnieuw te definiëren of te splitsen. De minder voor de hand liggende vorm is echter belangrijker. Een blok is niet beperkt tot één ouder. Het kan van meerdere tegelijk erven, delen van andere blokken samenstellen, de overerving beperken en een keuze bieden tussen alternatieve ouders, allemaal in één definitie. Profielen worden opgebouwd door deze technieken te combineren, niet door te specialiseren in één enkele afstammingslijn.

Dat zorgt ervoor dat een datamodel de juiste omvang behoudt. Brede standaarden zijn ontworpen voor brede toepasbaarheid, dus het direct overnemen van een standaard leidt vaak tot overspecificatie én onderspecificatie tegelijk: termen en opties die niets met uw data te maken hebben, terwijl u tegelijkertijd het ene onderscheid dat uw use case vereist niet kunt uitdrukken. En vaak is geen enkele standaard op zichzelf voldoende, wat u er ook mee doet. Door standaarden te combineren kunt u weglaten wat niet van toepassing is, de precieze details toevoegen en lenen van een tweede of derde specificatie waar de eerste ophoudt. Data die is geschreven op basis van een van onze bouwstenen blijft geldig voor elke bouwsteen waarop deze is gebaseerd, helemaal tot aan de basis. In het volgende gedeelte wordt getoond hoe dat er in een echte ruimte uitziet. 

Dat dekt gezamenlijk de drie dingen die de piloten daadwerkelijk nodig hadden: 

• Beschrijven. Iedereen die erbij betrokken is, van de conservator die de gegevens invoert tot de ontwikkelaar die daar bovenop tools bouwt, werkt vanuit één precieze definitie van de gegevens. 

• Valideren. Het schema detecteert structurele fouten; de grafregels detecteren de betekenisvolle fouten, zoals een ontbrekende relatie of een object dat als het verkeerde type is getypeerd. 

• Transformeren. Op twee niveaus. De semantische mappings van een blok (de eigen mappings, plus alles wat is overgeërfd van de blokken waarop het is gebaseerd) zetten een eenvoudig record uit het systeem van een partner om in een doorzoekbare, koppelbare grafiek, klaar voor aggregatie in de stijl van Europeana. En blokken kunnen conversietabellen publiceren: kant-en-klare conversies naar andere blokken en specificaties, die met het blok worden meegeleverd zodat niemand verderop in het proces deze opnieuw hoeft te implementeren. 

Simpel gezegd: een bouwsteen is een kleine specificatie voor één soort informatie: wat een verslag over een gebouw, een ruimte of een onderzoek moet bevatten, wat elk onderdeel ervan betekent en hoe je een correct verslag van een onjuist verslag kunt onderscheiden. Het staat op een webadres dat niet verandert, zodat software elk onderdeel ervan kan verwerken in plaats van dat een persoon het moet lezen en interpreteren. Bouwstenen bouwen op elkaar voort, en op meerdere tegelijk: een historisch gebouw is een erfgoedobject met een paar toevoegingen, en een verslag van een 3D-scan kan tegelijkertijd voldoen aan de erfgoednorm, de herkomstnorm en de karteringsnorm, in plaats van dat je gedwongen wordt te kiezen.

Het antwoord voor de Galleria Grande

Met die informatie in handen is er een concreet antwoord op de vraag: "Hoe structureren we dit?" 

plaats (CIDOC-CRM E53 Plaats, profielen van het standaard geospatiale objectblok)
  └── erfgoedsite (CIDOC-CRM E27 Site) → de Reggia di Venaria
        └── gebouw (CIDOC-CRM E22 door mensen gemaakt object, IFC-uitlijning)
              └── architecturale ruimte (CIDOC-CRM E22, IFC IfcSpace) → de Galleria Grande 

Elk niveau voegt alleen toe wat nieuw is op dat niveau en erft de rest. Building voegt een link toe naar de bovenliggende site en erft al het andere, tot en met het URL- veld dat is gekoppeld aan de toegangs-URL van DCAT, van het erfgoedobjectblok erboven. De IFC-uitlijningen die Building en Architectural Space bevatten , zorgen ervoor dat een record in deze keten kan worden overgedragen tussen de erfgoedcatalogus en het BIM-model van dezelfde ruimte zonder dat er telkens een aparte vertaling nodig is.

Voeg daar nu de laserscan van één gedeelte van die galerij aan toe, en de combinatie van verschillende standaarden begint zijn nut te bewijzen. Een scan is drie dingen tegelijk: iets met een herkomstgeschiedenis, iets dat zich in de ruimte bevindt, en iets met een erfgoedwaarde. Geen enkele standaard dekt alle drie, dus de digitale representatiefunctie combineert ze. Het erft de entiteit van PROV-O voor de herkomst. Voor de locatie biedt het een keuze tussen een GeoJSON (JSON-FG) feature en een topografische feature , afhankelijk van of het record zijn eigen geometrie bevat of naar die van iemand anders verwijst. De CIDOC-CRM-verankering bevindt zich in de semantische laag. Vervolgens voegt het zijn eigen eigenschappen toe en beperkt het de overgeërfde identifier tot een echte URI. Eén record, drie specificaties tegelijk voldaan, geen van alle afgesplitst, en het record blijft een geldige instantie van elk.

Die keuze met betrekking tot de geometrie is het interessante aspect. De scan van de baai omvat precies de baai die is opgemeten, dus in plaats van die polygoon in het meetverslag te herhalen, verwijst het verslag via een referentie naar de eigen geometrie van de architectonische ruimte. De twee kunnen later niet uit elkaar lopen, omdat er maar één kopie is. Dit zijn expliciete, machinaal leesbare koppelingen tussen datamodellen, geen bewering over compatibiliteit in een document. 

Dezelfde keten beschrijft Villa Portelli, een 19e-eeuwse residentie op Malta en de andere pilotlocatie van het project: dezelfde vier verdiepingen, een ander gebouw in een ander land, geen nieuw schema nodig. Eén definitie, twee pilots, twee uitgewerkte voorbeelden. Dat hergebruik op verschillende locaties is het praktische voordeel van het koppelen van bouwstenen aan CIDOC-CRM-klassen in plaats van aan de lokale terminologie van elke locatie. 

Simpel gezegd: vier geneste specificaties: een locatie, een erfgoedlocatie, een gebouw erop en een kamer in het gebouw. ​​Beschrijf de kamer en je krijgt automatisch alle reeds overeengekomen informatie over het gebouw, de locatie en de plek waar het staat. Dezelfde vier specificaties zijn van toepassing op een barok koninklijk paleis in Italië en een 19e-eeuws huis op Malta, precies wat je wilt: twee teams die heel verschillende dingen documenteren, op een manier die een derde partij toch kan lezen. En omdat elk document ook een echt geospatiaal object is, kan een inventarisatie van één kamer simpelweg de omtrek van die kamer aangeven in plaats van een tweede kopie mee te nemen die later door iemand moet worden bijgehouden.

De audit die voorafging aan het opstellen van documenten.

De eerste echte beslissing ging over wat er níét geschreven moest worden. Voor de meeste generieke lagen bestaan ​​er al gepubliceerde, bijgehouden registers:

Wat niemand publiceert, is de laag waar erfgoed echt specifiek is: CIDOC-CRM en EDM toegepast op fysieke erfgoedobjecten, plaatsen, actoren, gebeurtenissen en hun digitale representaties, naast de geospatiale en BIM-standaarden in plaats van ze te negeren. Die lacune is de werkelijke bijdrage van het register. Alles wat in bblocks-heritage wordt gemaakt , is gekoppeld aan een CIDOC-CRM-, CRMdig-, CRMsci- of EDM-klasse en vormt een aanvulling op de bovenstaande importen in plaats van ze te dupliceren. De digitale representatie wordt opgebouwd door het geïmporteerde herkomstblok te combineren, niet door herkomstvelden opnieuw uit te vinden.

Deze audit van "wat er is, versus wat er werkelijk ontbreekt" verdient het om zorgvuldig uit te voeren en te documenteren. Het is het verschil tussen een register dat de dekking vergroot en een register dat ruis toevoegt aan een toch al overvol normenlandschap. 

De audit heeft zelfs een complete use case om zeep geholpen. Een van de use cases van HERITALISE betreft observaties en metingen op erfgoedlocaties: sensorwaarden, meer niet. Toen de vereisten via dezelfde cross-registerzoekopdracht werden gecontroleerd, bleken ze allemaal te vallen op de bestaande SOSA/SensorThings-blokken, en bleek het aantal nieuwe blokken dat moest worden aangemaakt nul te zijn. Een methode die je vol vertrouwen kan vertellen "hier is niets nieuws nodig" doet precies wat hij moet doen. De kostbare fout in dit geval is het register dat sensorobservaties opnieuw uitvindt met een vleugje erfgoedterminologie. 

Simpel gezegd: voordat we iets schreven, hebben we gekeken wat er al bestond. Herkomstinformatie, vocabulaires, datasetcatalogi en sensorwaarden zijn opgeloste problemen waarvoor al gepubliceerde en onderhouden oplossingen bestaan. Daarom hebben we die hergebruikt in plaats van wéér een variant met een ouderwetse inslag te creëren. Voor een van de use cases van het project was de eerlijke conclusie dat er helemaal niets nieuws nodig was. Weten wanneer je iets niet moet uitvinden is net zo waardevol als het uitvinden ervan.

Vier manoeuvres, herhaald per piloot.

De methode zelf is zo kort dat hij volledig kan worden uitgelegd: 

1. Leg de vereisten vast in een consistente tabelvorm. De behoeften van elke piloot werden als een tabel aangeleverd, met één rij per gegevensbehoefte. Alleen al daardoor waren ze telbaar en traceerbaar, ook al bestond de inhoud van elke cel grotendeels uit vrije tekst, geschreven door domeinexperts in plaats van door schema-auteurs.
2. Breng eerst de kaarten in kaart volgens de standaarden, en schrijf daarna pas de schema's. Voordat er ook maar één schema bestond, kreeg elke vereiste een gedocumenteerde koppeling met datgene wat er daadwerkelijk op van toepassing was: een CIDOC-CRM-eigenschap, een PROV-relatie, een sensorobservatieklasse, een IFC-concept. Die koppeling is in proza ​​beschreven, onafhankelijk van elke blok-identificatie, en blijft de gezaghebbende vastlegging van Waarom Elk blok ziet eruit zoals het eruit ziet. Vereisten die al werden gedekt door een bestaand blok of een geïmporteerd register, vereisten slechts een voorbeeld, geen nieuw schema. Verschillende tuingerelateerde vereisten van Venaria werden op die manier opgelost.
3. Schrijf blok voor blok, aan de hand van een vaste checklist. Controleer of het element al bestaat en eenvoudig hergebruikt kan worden; schrijf het schema; koppel elk veld aan de bijbehorende CIDOC-CRM-, PROV-, EDM- of IFC-term; schrijf de validatieregels voor de grafiek; schrijf een beschrijving in begrijpelijke taal; en schrijf minstens twee voorbeelden gebaseerd op echte pilotgegevens, waar mogelijk één met een Venaria-thema en één met een Malta-thema. Twee voorbeelden per blok zijn geen decoratie. Voorbeelden gebaseerd op pilotgegevens zijn het concrete bewijs dat een blok daadwerkelijk voldoet aan de vereisten die het claimt.
4. Controleer de gegevens voordat u verdergaat. Elk voorbeeld wordt automatisch op drie manieren gecontroleerd: aan de hand van het schema, tijdens de conversie naar een graaf en aan de hand van de graafregels na de conversie. Een blok wordt pas voltooid als al deze controles geslaagd zijn. We hebben er bewust voor gekozen om geen batch blokken in één keer te genereren en deze aan het einde te valideren. Verschillende minder voor de hand liggende problemen kwamen pas tijdens de validatie aan het licht, en het was veel efficiënter om deze blok voor blok op te sporen dan ze in één keer over vele blokken heen te moeten oplossen.

Die laatste regel bewees al snel zijn nut. Een eerdere analyse van de standaarden die we overnamen, bevatte handgeschreven validatieregels die door een andere AI-assistent waren gegenereerd en nooit daadwerkelijk waren uitgevoerd. We beschouwden het als een uitgangspunt, niet als de absolute waarheid, en namen niets over zonder het aan de echte controles te onderwerpen. "Door AI gegenereerd" en "door AI gegenereerd en geverifieerd" zijn niet hetzelfde. 

Simpel gezegd: schrijf op wat je nodig hebt, regel voor regel. Bepaal welke bestaande standaard elke regel dekt voordat je iets ontwerpt. Bouw vervolgens één onderdeel tegelijk en bewijs dat elk onderdeel werkt aan de hand van echte voorbeelden van een echte website voordat je aan het volgende begint. Niets wordt geaccepteerd omdat het aannemelijk lijkt, ook niet iets dat door een AI is geproduceerd.

Het moment waarop de AI zijn waarde bewijst.

We gebruikten Claude Code voor het schrijven zelf: het lezen van de vereisten, het schrijven van de schema's en semantische mappings, het uitvoeren van de validatie en het itereren op basis van de fouten. De reden dat het zo goed en zo geautomatiseerd werkte, is dat de assistent niet vanaf nul begon. Het kon gebruikmaken van een aanzienlijke hoeveelheid resources, tools en services die volledig zijn ontworpen om een ​​AI-assistent te ondersteunen die dit soort werk doet. Veel daarvan bestond al vóór HERITALISE. Het bouwen van dit register verbeterde het en vulde hiaten op die pas aan het licht komen wanneer een methode van begin tot eind in een echt domein wordt toegepast. Daardoor is het register zelf net zozeer een resultaat van dit verhaal als de methode zelf.

Vaardigheden, geen gissingen. Een Agent Skill is een gebundelde set instructies en referentiemateriaal die een AI-assistent laadt wanneer deze een bepaalde taak tegenkomt: in feite de vastgelegde expertise van iemand die de taak eerder heeft uitgevoerd, in een vorm die de assistent direct kan raadplegen. Wij ontwikkelen en onderhouden OGC LLM Skills , een openbare repository voor OGC Blocks-werk. Eén skill behandelt het schrijven van blocks; een andere behandelt de downstream-kant, zoals het valideren van data aan de hand van gepubliceerde blocks en het omzetten ervan in een grafiek. Daarnaast stelt een zoekservice de assistent in staat om elk gepubliceerd register te doorzoeken, op trefwoord en betekenis, voordat er iets nieuws wordt geschreven. Dat is wat oordelen zoals "herschrijf de provenance niet" en "de use case voor observaties heeft helemaal niets nieuws nodig" heeft omgezet in snelle, betrouwbare controles in plaats van handmatige zoektochten naar specificaties.

Een werkgeheugen dat de sessie overleeft. Een levend planbestand dat de reikwijdte, status, auteursvolgorde, de afhankelijkheden tussen blokken en, het allerbelangrijkste, een doorlopend logboek bijhoudt van kleine, moeizaam verworven lessen die tijdens de validatie zijn ontdekt. ​​Individueel zijn die lessen triviaal. Gezamenlijk maken ze het verschil tussen het vijfentwintigste blok dat probleemloos door de validatie komt en elk blok dat dezelfde fout opnieuw tegenkomt als het eerste. Elke les werd geleerd door de daadwerkelijke controles uit te voeren en de daadwerkelijke fout te lezen, en vervolgens op te schrijven waar de volgende sessie die fout zou vinden. De vaardigheden en het planbestand zorgen ervoor dat die kennis zich over het hele register ophoopt in plaats van te verdwijnen telkens wanneer een sessie eindigt.

Simpel gezegd: de AI-assistent werd niet gevraagd om te improviseren. Hij kreeg schriftelijke expertise over precies dit soort werk, een zoekfunctie waarmee hij kon controleren wat er al bestond voordat hij iets voorstelde, en een notitieboek dat hij continu bijwerkte, zodat een les die op maandag was geleerd, op vrijdag nog steeds bekend was. Dankzij die combinatie is het werk betrouwbaar genoeg om te publiceren, en alles is openbaar, zodat het volgende project ook niet helemaal vanaf nul hoeft te beginnen.

Wat staat er vandaag in het register?

Alles wat gepubliceerd en gevalideerd is, valt onder de ogc.heritage. voorvoegsel. erfgoedobject, plaats en acteur De kernentiteiten bevatten. erfgoedlocatie, bouwt en architectonische ruimte Dit is de keten die dit bericht volgt. enquête-dataset en conditiebeoordeling dekt de werkzaamheden die op een locatie zijn uitgevoerd. mondelinge geschiedenis en historische verklaring De dingen die erover gezegd worden, en de kenmerkende eigenschappen, maken van elk van hen een eersteklas geospatiaal object. De rest, van monitoring-drempel naar routestaan ​​in het register. 

Elk blok is verankerd in de standaarden waarop het is gebaseerd, meestal CIDOC-CRM, CRMdig, CRMsci, PROV-O of EDM, en vaak in meerdere standaarden tegelijk. Elk blok heeft een gevalideerd schema, een semantische mapping, validatieregels voor grafieken waar het eigen beperkingen introduceert, en minstens twee voorbeelden, waarvan de meeste direct gebaseerd zijn op Venaria- of Malta-pilotgegevens. Bekijk ze allemaal op ogcincubator.github.io/bblocks-heritage.

Dit is geen recept dat alleen voor traditionele recepten is bedoeld.

Als je probleem luidt: "Ik heb een use case en wat data, en ik moet die modelleren, valideren, ergens aan koppelen (vooral aan semantiek) en eventueel transformeren", dan geldt hetzelfde pad, ongeacht het domein: 

• Een uitgewerkt voorbeeld op ware schaal.: bblocks-erfgoed (bron), profielketens, validatieregels, voorbeelden en alles. 

• De vaardigheden, klaar voor installatie: OGC LLM-vaardigheden (bron) publiceert de vaardigheden voor het maken en gebruiken van code, klaar voor installatie door u of uw assistent. Werkt met claude.ai, Claude Code en de Claude API. 

• Het frame: de OGC Blocks-documentatie legt de aanpak uit en hoe je een eigen register kunt opzetten. 

De methode in één zin: inventariseer wat er al bestaat voordat je iets modelleert, koppel eisen aan standaarden voordat je ze aan schema's koppelt, modelleer en valideer één onderdeel tegelijk aan de hand van echte data, en noteer elke niet-voor de hand liggende les zodat je er maar één keer voor hoeft te betalen. Het is een iteratieve cyclus, geen specificatie die in één keer wordt opgelegd. Een AI-assistent met de juiste domeinkennis maakt die cyclus snel, waardoor iteratie op dit detailniveau überhaupt betaalbaar is. Het vervangt de cyclus niet. 

Voor HERITALISE heeft die cyclus de beschrijvingen van echte erfgoedlocaties omgezet in een openbaar datamodel: 27 blokken, elk gebaseerd op standaarden die de gemeenschap al vertrouwt, met eigen validatie en semantiek, en ontworpen om te voldoen aan de geospatiale en BIM-aspecten in plaats van deze te negeren. De middelen, tools en diensten die dit mogelijk maakten (de expertise, de zoekservice, de methode zelf) zijn gepubliceerd, getest in een reële omgeving en klaar voor het volgende project.