Die fehlende Ebene zwischen Denkmalschutzstandards und Denkmaldaten

KulturerbeAlter hat coumfassend Standards zur Beschreibung von Dingen. Was schwieriger zu beschaffen war, ist Wie man sie effektiv nutzt, um das volle Potenzial der Daten auszuschöpfen, einschließlich des Auffindens, des Zugriffs und der (Wieder-)Verwendung, insbesondere im Rahmen automatisierter Abfragen und Analysen. Was bisher fehlte, ist Die darunterliegende Schicht: Sie ermöglicht es der Software, eine echte Datei zu prüfen, sie zu verstehen und weiterzuleiten. So hat das HERITALSE-Projekt diese Schicht aufgebaut. durch die Nutzung des OGC-Bausteinansatzes, d. h. der Definition, Speicherung und Dokumentation kleiner modularer Spezifikationsbausteine, wodurch Validierung, Standardkonformität und Skalierbarkeit erleichtert werden (siehe untenDie Ergebnisse werden veröffentlicht as bblocks-heritage, ein öffentliches Register von 27 wiederverwendbaren Bausteinen. Tdie KI-gestützte Methode„d dahinter“ überträgt an jede beliebige Domain. 

So lesen Sie diesen Beitrag: Der Haupttext richtet sich an Personen, die Datensysteme entwickeln oder spezifizieren. Die eingerückten „Einfach erklärt“-Kästen erklären dasselbe ohne Fachjargon und sind für Fachleute im Bereich Denkmalpflege gedacht, denen das Ergebnis wichtiger ist als die technischen Details. Beide Wege sind unabhängig voneinander verständlich.

Beginnen Sie mit einem Zimmer in Venaria.

Die Reggia di Venaria bei Turin ist einer der Pilotstandorte des HERITALISE -Projekts und der erste, der detaillierte Dokumentationsanforderungen mit sich bringt. Nehmen wir einen einzelnen Raum: die Galleria Grande, Filippo Juvarras große Galerie. Ein Dokumentationsteam muss die Galerie, das Gebäude, in dem sie sich befindet, das Grundstück, auf dem das Gebäude steht, den Zustand der Oberflächen, die Laserscans und photogrammetrischen Aufnahmen sowie die jeweiligen Personen, die diese Daten wann und mit welchem ​​Gerät erhoben haben, erfassen.

Fragt man nach den anzuwendenden Standards, liefert das Fachgebiet eine fundierte und etablierte Antwort. Beschreiben Sie Objekte, Orte, Akteure und Ereignisse mit CIDOC-CRM, dem ISO-Referenzmodell, auf das sich die Fachgemeinschaft geeinigt hat und das aktuelle europäische Projekte wie die Heritage Digital Twin Ontology der European Collaborative Cloud for Cultural Heritage untermauert. Dokumentieren Sie mit PROV-O, wer was mit welchem ​​Instrument und aus welchem ​​Material getan hat. Verorten Sie Objekte im Raum mit GeoJSON. Nutzen Sie SOSA/SSN für Sensormesswerte, DCAT für Metadaten von Datensätzen und EDM, falls die Datensätze später in Europeana veröffentlicht werden sollen. 

Das ist nur die halbe Wahrheit, denn die Galerie ist auch ein Gebäude in einer Landschaft. Sobald die Dokumentation die 3D- und Vermessungsaspekte umfasst, kommt eine zweite Normenfamilie zum Einsatz: IFC für das BIM-Modell des Gebäudes selbst, CityGML LandInfra für den städtischen und landschaftlichen Kontext, INSPIRE für alles, was mit europäischen Geodaten kompatibel sein muss. Die Dokumentation des Kulturerbes liegt genau an der Schnittstelle zwischen der semantischen Welt und der Geodaten- und BIM-Welt, und genau dort liegt der Großteil der praktischen Schwierigkeiten. 

Jeder dieser Standards liefert die richtige Antwort auf die Fragestellung, für die er entwickelt wurde. Was keiner von ihnen jedoch – bewusst – bietet, ist der nächste Schritt: ein konkretes Datenmodell für Ihren Anwendungsfall. Jemand muss weiterhin festlegen, was ein Eintrag in dieser Galerie beinhaltet, wie eine Zustandsbewertung als Satz von Feldern aussieht, wie ein Raum mit dem umgebenden Gebäude und dem ihn erfassenden Scan zusammenhängt und all diese Entscheidungen dem jeweiligen Standardbegriff in einer für die Software nutzbaren Form zuordnen. Ein konzeptionelles Referenzmodell zeigt Ihnen, wie Sie über Kulturerbeinformationen nachdenken können. Es übernimmt diese Modellierung bewusst nicht für Sie und kann der Software auch nicht mitteilen, dass die Verbindung zur übergeordneten Website fehlt.

Jedes Projekt erstellt also sein eigenes Modell, und jedes Projekt geht dabei anders vor. So entstehen Datensätze, die zwar alle korrekterweise behaupten, denselben Standards zu entsprechen, aber dennoch nicht zusammen verwendet werden können. In diesem Beitrag geht es darum, die Modellierung einmalig und transparent durchzuführen und sie in einem Format zu veröffentlichen, das von Software verarbeitet werden kann.

Einfach ausgedrückt: In der Denkmalpflege herrscht weitgehend Einigkeit darüber, wie mit Informationen umzugehen ist. Es gibt ausgereifte, international anerkannte Modelle für Objekte, Orte, Personen, Ereignisse, Gebäude und 3D-Daten. Was jedoch keines dieser Modelle vorgibt, ist die praktische Umsetzung: Was genau gehört in eine Dokumentation über diesen Raum, und zwar in einem Format, das ein Computer verarbeiten kann? Jedes Projekt erarbeitet das selbst, weshalb zwei Teams, die dieselben Standards gewissenhaft befolgen, dennoch nicht in der Lage sein können, die Dateien des jeweils anderen Teams zu lesen. Wir haben diese Arbeit einmal für die Denkmalpflege geleistet und sie zur freien Verwendung veröffentlicht.

Was ein Baustein ist

Ein OGC-Baustein ist eine kleine, in sich abgeschlossene Spezifikation oder ein wiederverwendbarer Teil davon. Jeder Baustein ist ein Datenmodell für eine bestimmte Art von Objekt und wird in einem einzigen Paket unter einem stabilen Namen wie ogc.heritage.building zusammengefasst.

• a Schema: die genauen Felder, die ein gültiger Datensatz in einem Formular aufweist, das die Software automatisch überprüft; 

• a semantische Zuordnung: für jedes Feld die Standardbezeichnung, für die es steht, sei es die „ist Teil von“-Bezeichnung von CIDOC-CRM oder eine andere Bezeichnung. übergeordnete Website Feld oder PROV-Os „wurde generiert von“ hinter dem Scan, der ein Modell erzeugt hat, was es ermöglicht, eine einfache Datendatei in einen Wissensgraphen umzuwandeln; 

• Validierungsregeln für dieses Diagramm, um die Fehler zu erkennen, die eine feldweise Überprüfung nicht erkennen kann; 

• Dokumentation in Alltagssprache; 

• Arbeitsbeispielewird bei jeder Änderung des Blocks automatisch getestet; 

• wo es nützlich ist, vorgefertigte Umrüstungen nach anderen Spezifikationen. 

Ein Register ist eine veröffentlichte und gepflegte Sammlung solcher Blöcke. OGC Blocks ist das Framework für deren Erstellung, und für viele allgemeine Domänen existieren bereits öffentliche Register.

Blöcke setzen sich zusammen, und auf diesem Mechanismus basiert alles Weitere. Die offensichtlichste Form ist das Profiling : Man nimmt einen anderen Block als Ganzes und schränkt ihn ein oder erweitert ihn, ohne ihn neu zu definieren oder abzuspalten. Die weniger offensichtliche Form ist jedoch wichtiger. Ein Block ist nicht auf einen einzigen Elternblock beschränkt. Er kann von mehreren gleichzeitig erben, Teile anderer Blöcke kombinieren, seine Erbfolge einschränken und eine Auswahl zwischen alternativen Elternblöcken bieten – alles in einer einzigen Definition. Profile entstehen durch die Kombination dieser Techniken, nicht durch die Spezialisierung entlang einer einzigen Abstammungslinie.

Das sorgt dafür, dass ein Datenmodell die richtige Größe hat. Weitgehende Standards sind für eine breite Anwendbarkeit ausgelegt. Die direkte Übernahme eines Standards führt daher oft zu einer Über- und Unterspezifizierung: Man verwendet Begriffe und Optionen, die nichts mit den eigenen Daten zu tun haben, und kann gleichzeitig die entscheidende Unterscheidung für den Anwendungsfall nicht ausdrücken. Häufig reicht kein einzelner Standard allein aus, egal wie man ihn anpasst. Durch die Kombination verschiedener Standards kann man Nichtzutreffendes entfernen, präzise Details hinzufügen und bei Bedarf auf eine zweite oder dritte Spezifikation zurückgreifen. Daten, die auf Basis eines unserer Bausteine ​​erstellt wurden, bleiben für alle darüberliegenden Bausteine ​​gültig. Im nächsten Abschnitt wird dies anhand eines realen Raums veranschaulicht. 

Damit sind die drei Dinge abgedeckt, die die Piloten tatsächlich benötigten: 

• Beschreiben. Alle Beteiligten, vom Restaurator, der die Aufzeichnungen erfasst, bis zum Entwickler, der darauf aufbauende Tools erstellt, arbeiten mit einer einzigen, präzisen Definition der Daten. 

• Bestätigen. Das Schema erkennt strukturelle Fehler; die Graphregeln erkennen die relevanten Fehler, wie zum Beispiel eine fehlende Beziehung oder ein Objekt, das als falscher Typ typisiert ist. 

• Verwandeln. Auf zwei Ebenen. Die semantischen Abbildungen eines Blocks (seine eigenen sowie alle von den zugrunde liegenden Blöcken geerbten) wandeln einen einfachen Datensatz aus dem System eines Partners in einen abfragefähigen, verknüpfbaren Graphen um, der für die Aggregation im Europeana-Stil geeignet ist. Blöcke können außerdem Crosswalks veröffentlichen: sofort einsatzbereite Konvertierungen zu anderen Blöcken und Spezifikationen, die mit dem Block ausgeliefert werden, sodass sie von niemandem in nachfolgenden Systemen neu implementiert werden müssen. 

Einfach ausgedrückt: Ein Baustein ist eine kleine Spezifikation für eine bestimmte Informationsart: Was ein Datensatz über ein Gebäude, einen Raum oder eine Vermessung enthalten muss, was die einzelnen Bestandteile bedeuten und wie man einen korrekten von einem fehlerhaften Datensatz unterscheidet. Er ist unter einer unveränderlichen Webadresse gespeichert, sodass Software auf jeden einzelnen Bestandteil zugreifen kann, anstatt dass ein Mensch ihn lesen und interpretieren muss. Bausteine ​​bauen aufeinander auf und können auch mehrere gleichzeitig nutzen: Ein historisches Gebäude ist ein Kulturgut mit einigen Ergänzungen, und ein Datensatz eines 3D-Scans kann gleichzeitig die Anforderungen an Denkmalschutz, Provenienznachweis und Kartierung erfüllen, anstatt eine Auswahl zu erzwingen.

Die Antwort für die Galleria Grande

Damit hat die Frage „Wie strukturieren wir das?“ eine konkrete Antwort: 

Ort (CIDOC-CRM E53 Ort, Profile des Standard-Geodaten-Feature-Blocks)
  └── Kulturerbe (CIDOC-CRM E27 Site) → die Reggia di Venaria
        └── Gebäude (CIDOC-CRM E22 Vom Menschen geschaffenes Objekt, IFC-Ausrichtung)
              └── Architekturraum (CIDOC-CRM E22, IFC IfcSpace) → die Galleria Grande 

Jede Ebene fügt nur die Neuerungen dieser Ebene hinzu und übernimmt den Rest. Das Gebäude fügt einen Link zu seiner übergeordneten Website hinzu und übernimmt alle weiteren Daten, bis hin zum URL- Feld, das der Zugriffs-URL von DCAT zugeordnet ist, vom darüberliegenden Denkmalobjektblock . Die von Gebäude und Architekturraum übertragenen IFC-Ausrichtungen ermöglichen es, einen Datensatz dieser Kette zwischen dem Denkmalkatalog und dem BIM-Modell desselben Raums ohne jedes Mal eine individuelle Übersetzung zu übertragen.

Fügt man nun den Laserscan eines Galeriebereichs hinzu, zeigt sich der Nutzen der Kombination mehrerer Standards. Ein Scan vereint drei Aspekte: Herkunftsgeschichte, räumliche Verortung und kulturelle Bedeutung. Da kein einzelner Standard alle drei abdeckt, kombiniert die digitale Repräsentationsfunktion diese. Sie übernimmt die PROV-O-Entität für die Herkunft. Für den Standort bietet sie die Wahl zwischen einem GeoJSON-Feature (JSON-FG) und einem Topo-Feature , je nachdem, ob der Datensatz eigene Geometriedaten enthält oder auf fremde verweist. Die CIDOC-CRM-Verankerung erfolgt auf der semantischen Ebene. Zusätzlich werden eigene Eigenschaften hinzugefügt und der übernommene Identifikator auf eine gültige URI beschränkt. Ein Datensatz, drei Spezifikationen gleichzeitig erfüllt, keine davon verzweigt, und der Datensatz bleibt eine gültige Instanz jeder Spezifikation.

Die Wahl der Geometrie ist der interessante Aspekt. Der Scan der Bucht erfasst exakt die vermessene Bucht. Anstatt dieses Polygon im Vermessungsdatensatz zu wiederholen, verweist der Datensatz referenziell auf die Geometrie des architektonischen Raums. Da nur eine Kopie existiert, können sich die beiden später nicht voneinander entfernen. Es handelt sich hierbei um explizite, maschinenlesbare Verknüpfungen zwischen Datenmodellen, nicht um eine Kompatibilitätsaussage in einem Dokument. 

Dieselbe Kette beschreibt die Villa Portelli, ein Wohnhaus aus dem 19. Jahrhundert in Malta und das zweite Pilotprojekt: dieselben vier Ebenen, ein anderes Gebäude in einem anderen Land, kein neues Schema erforderlich. Eine Definition, zwei Pilotprojekte, zwei Anwendungsbeispiele. Diese Wiederverwendung an unterschiedlichen Standorten ist der praktische Vorteil, Blöcke an CIDOC-CRM-Klassen zu binden, anstatt an das jeweils lokal gebräuchliche Vokabular. 

Einfach ausgedrückt: Vier verschachtelte Spezifikationen: ein Ort, ein Kulturerbe, ein Gebäude darauf und ein Raum innerhalb des Gebäudes. Beschreibt man den Raum, erhält man automatisch alle bereits vereinbarten Informationen über das Gebäude, das Gelände und den Standort. Dieselben vier Spezifikationen eignen sich sowohl für einen barocken Königspalast in Italien als auch für ein Haus aus dem 19. Jahrhundert in Malta – genau das, was man sich wünscht: Zwei Teams dokumentieren ganz unterschiedliche Dinge, und zwar so, dass die Dokumentation auch für Dritte verständlich ist. Da jeder Datensatz gleichzeitig ein eigenständiges Geodatenobjekt darstellt, genügt es bei der Erfassung eines Raumes, einfach auf dessen Umriss zu verweisen, anstatt eine zweite Kopie mitzuführen, die später aktualisiert werden muss.

Die Prüfung, die vor jeglicher Autorenschaft stattfand

Die erste wirkliche Entscheidung betraf die Frage, was nicht geschrieben werden sollte. Für die meisten generischen Schichten existieren bereits veröffentlichte und gepflegte Register:

Was niemand veröffentlicht, ist die Ebene, auf der Kulturerbe wirklich spezifisch ist: CIDOC-CRM und EDM angewendet auf physische Kulturgüter, Orte, Akteure, Ereignisse und deren digitale Repräsentationen, die neben den Geodaten- und BIM-Standards existieren, anstatt diese zu ignorieren. Diese Lücke ist der eigentliche Beitrag des Registers. Alles, was in bblocks-heritage erstellt wird , ist an eine CIDOC-CRM-, CRMdig-, CRMsci- oder EDM-Klasse angebunden und ergänzt die oben genannten Importe, anstatt sie zu duplizieren. Die digitale Repräsentation entsteht durch die Kombination des importierten Provenienzblocks, nicht durch die Neuerfindung von Provenienzfeldern.

Diese Prüfung, die feststellt, was vorhanden ist und was tatsächlich fehlt, sollte sorgfältig durchgeführt und dokumentiert werden. Sie entscheidet darüber, ob ein Register die Abdeckung erweitert oder die ohnehin schon unübersichtliche Normenlandschaft zusätzlich verkompliziert. 

Das Audit führte sogar zur kompletten Abschaffung eines Anwendungsfalls. Ein Anwendungsfall von HERITALISE betrifft Beobachtungen und Messungen an Kulturerbestätten: Sensormesswerte, ganz einfach. Als die Anforderungen die gleiche registerübergreifende Suche durchliefen, landeten sie alle in den bestehenden SOSA/SensorThings-Blöcken, und die korrekte Anzahl neu zu erstellender Blöcke war null. Eine Methode, die zuverlässig sagen kann: „Hier ist nichts Neues nötig“, erfüllt genau ihren Zweck. Der kostspielige Fehler in diesem Bereich ist das Register, das Sensorbeobachtungen mit kulturhistorischem Vokabular neu erfindet. 

Einfach ausgedrückt: Bevor wir etwas entwickelten, prüften wir, was bereits existierte. Herkunft, Vokabulare, Datensatzkataloge und Sensormesswerte sind gelöste Probleme mit veröffentlichten und gepflegten Lösungen. Daher nutzten wir diese, anstatt eine weitere, auf Tradition basierende Variante zu erstellen. Für einen der Anwendungsfälle des Projekts kamen wir ehrlich zu dem Schluss, dass überhaupt nichts Neues nötig war. Zu wissen, wann man etwas nicht erfinden sollte, ist genauso wertvoll wie es zu erfinden.

Vier Manöver, pro Pilot wiederholt

Die Methode selbst ist kurz genug, um sie vollständig zu beschreiben: 

1. Anforderungen in einem einheitlichen Tabellenformat erfassen. Die Anforderungen jedes Piloten wurden als Tabelle übermittelt, wobei jede Zeile einem Datenbedarf entsprach. Allein dadurch waren sie aufzählbar und nachvollziehbar, obwohl der Inhalt der einzelnen Zellen größtenteils noch aus frei formulierten Texten von Fachexperten und nicht von Schema-Autoren bestand.
2. Zuerst die Standards abbilden, dann die Schemas schreiben. Bevor ein einheitliches Schema existierte, wurde jede Anforderung dokumentiert und dem jeweils relevanten Element zugeordnet: einer CIDOC-CRM-Eigenschaft, einer PROV-Relation, einer Sensorbeobachtungsklasse oder einem IFC-Konzept. Diese Zuordnung ist ein nachvollziehbarer Text, unabhängig von Blockkennungen, und bleibt die maßgebliche Dokumentation. warum Jeder Block hat seine eigene Struktur. Anforderungen, die bereits durch einen bestehenden Block oder ein importiertes Register abgedeckt waren, benötigten lediglich ein Beispiel, kein neues Schema. Mehrere gartenbezogene Anforderungen von Venaria wurden auf diese Weise erfüllt.
3. Schreiben Sie Block für Block anhand einer festgelegten Checkliste. Prüfen Sie, ob das Element bereits existiert und einfach wiederverwendet werden kann; erstellen Sie das Schema; ordnen Sie jedes Feld seinem CIDOC-CRM-, PROV-, EDM- oder IFC-Begriff zu; erstellen Sie die Regeln zur Graphvalidierung; verfassen Sie eine Beschreibung in einfacher Sprache; und erstellen Sie mindestens zwei Beispiele, die auf realen Pilotdaten basieren, idealerweise eines mit Venaria- und eines mit Malta-Bezug. Zwei Beispiele pro Block sind keine bloße Dekoration. Beispiele, die auf Pilotdaten basieren, sind der konkrete Beweis dafür, dass ein Block die beanspruchte Anforderung tatsächlich erfüllt.
4. Bitte prüfen Sie die Angaben, bevor Sie fortfahren. Jedes Beispiel wird automatisch auf drei Arten geprüft: anhand des Schemas, durch die Umwandlung in einen Graphen und anhand der Graphregeln nach der Umwandlung. Ein Block wird erst dann als abgeschlossen betrachtet, wenn alle diese Prüfungen erfolgreich bestanden sind. Wir haben bewusst darauf verzichtet, eine große Anzahl von Blöcken zu generieren und diese am Ende zu validieren. Mehrere nicht offensichtliche Probleme traten erst bei der Validierung auf, und deren Behebung Block für Block war deutlich effizienter, als sie gleichzeitig in vielen Blöcken zu lösen.

Diese letzte Regel hat sich früh bewährt. Eine frühere Standardanalyse, die wir übernommen hatten, enthielt handgeschriebene Validierungsregeln, die von einem anderen KI-Assistenten erstellt, aber nie tatsächlich ausgeführt wurden. Wir behandelten sie als Ausgangspunkt, nicht als verbindliche Wahrheit, und übernahmen nichts, ohne es den realen Prüfungen zu unterziehen. „KI-generiert“ und „KI-generiert und verifiziert“ sind nicht dasselbe. 

In einfachen Worten. Schreiben Sie Ihre Anforderungen Zeile für Zeile auf. Ermitteln Sie, welcher bestehende Standard jede Zeile abdeckt, bevor Sie mit der Entwicklung beginnen. Erstellen Sie dann ein Element nach dem anderen und testen Sie jedes Element anhand realer Beispiele von einer realen Website, bevor Sie mit dem nächsten beginnen. Nichts wird akzeptiert, nur weil es plausibel erscheint – auch nichts, was von einer KI generiert wurde.

Der Teil, in dem die KI ihren Platz verdient

Wir nutzten Claude Code für die eigentliche Entwicklung: das Einlesen der Anforderungen, das Schreiben der Schemata und semantischen Zuordnungen, die Validierung und die Fehlerbehebung. Der Grund für die reibungslose und effiziente Funktionsweise liegt darin, dass der Assistent nicht bei Null anfangen musste. Er konnte auf umfangreiche Ressourcen, Tools und Services zurückgreifen, die speziell für die Unterstützung von KI-Assistenten dieser Art entwickelt wurden. Vieles davon existierte bereits vor HERITALISE. Der Aufbau dieses Registers verbesserte es und schloss Lücken, die erst bei der vollständigen Anwendung einer Methode in einem realen Anwendungsgebiet sichtbar werden. Daher ist die Anwendung ebenso ein Ergebnis dieses Projekts wie das Register selbst.

Kompetenz statt Vermutungen. Eine Agentenkompetenz ist ein Paket aus Anweisungen und Referenzmaterial, das ein KI-Assistent lädt, sobald er auf eine bestimmte Aufgabe stößt: im Grunde die schriftlich festgehaltene Expertise eines erfahrenen Experten, die der Assistent bei Bedarf abrufen kann. Wir entwickeln und pflegen OGC LLM Skills , ein öffentliches Repository für OGC Blocks. Eine Kompetenz deckt das Erstellen von Blöcken ab; eine andere die Weiterverarbeitung, die Validierung von Daten anhand veröffentlichter Blöcke und deren Umwandlung in einen Graphen. Ergänzend dazu ermöglicht ein Suchdienst dem Assistenten, alle veröffentlichten Register nach Stichwort und Bedeutung zu durchsuchen, bevor etwas Neues geschrieben wird. Dadurch wurden Aussagen wie „Provenienz nicht neu erfinden“ und „Der Anwendungsfall der Beobachtungen benötigt nichts Neues“ zu schnellen, sicheren Prüfungen anstatt manueller Spezifikationssuche.

Ein Arbeitsgedächtnis, das die Sitzung überdauert. Eine dynamische Planungsdatei erfasst Umfang, Status, Reihenfolge der Bearbeitung, Abhängigkeiten zwischen Blöcken und – besonders wertvoll – ein fortlaufendes Protokoll der während der Validierung gewonnenen, mühsam erlernten Erkenntnisse. Einzeln betrachtet sind diese Erkenntnisse trivial. Zusammengenommen entscheiden sie darüber, ob der 25. Block die Validierung problemlos durchläuft oder ob jeder Block denselben Fehler wiederholt wie der erste. Jede Erkenntnis wurde durch die Durchführung realer Prüfungen und das Lesen des tatsächlichen Fehlers gewonnen und anschließend dort notiert, wo die nächste Sitzung sie finden würde. Die Fähigkeiten und die Planungsdatei ermöglichen es, dass sich dieses Wissen im gesamten Register ansammelt, anstatt mit jedem Sitzungsende zu verfliegen.

Einfach ausgedrückt: Der KI-Assistent sollte nicht improvisieren. Er erhielt schriftliches Fachwissen zu genau dieser Art von Arbeit, eine Suchfunktion, um bereits vorhandene Informationen zu prüfen, bevor er Vorschläge machte, und ein Notizbuch, das er ständig aktualisierte, sodass Erkenntnisse vom Montag auch am Freitag noch relevant waren. Dank dieser Kombination ist die Arbeit zuverlässig genug für eine Veröffentlichung, und da sie vollständig öffentlich zugänglich ist, beginnt auch das nächste Projekt nicht bei null.

Was steht heute im Register?

Alles, was unter der ogc.heritage. Präfix. Kulturerbeobjekt, Ort und Schauspieler tragen die Kernelemente. Kulturerbestätte, Gebäude und Architekturraum sind die Kette, der dieser Beitrag gefolgt ist. Umfragedatensatz und Zustandsbewertung die an einer Baustelle durchgeführten Arbeiten abdecken mündliche Geschichte und historische Aussage Die darüber gemachten Aussagen und die Merkmalsumschläge machen jedes einzelne davon zu einem erstklassigen Geodatenobjekt. Der Rest, von Überwachungsschwelle zu Route, sind im Register eingetragen. 

Jeder Block basiert auf den zugrunde liegenden Standards, meist CIDOC-CRM, CRMdig, CRMsci, PROV-O oder EDM, viele sogar auf mehreren gleichzeitig. Jeder Block verfügt über ein validiertes Schema, eine semantische Zuordnung, Regeln zur Graphvalidierung mit eigenen Einschränkungen und mindestens zwei Beispiele, die größtenteils direkt auf Pilotdaten aus Venaria oder Malta basieren. Alle Beispiele finden Sie unter ogcincubator.github.io/bblocks-heritage.

Dies ist kein Rezept, das nur traditionellen Rezepten vorbehalten ist.

Wenn Ihre Problemstellung etwa so lautet: „Ich habe einen Anwendungsfall und einige Daten, und ich muss diese modellieren, validieren, auf etwas abbilden (insbesondere semantisch) und gegebenenfalls transformieren“, dann gilt unabhängig vom Anwendungsbereich der gleiche Weg: 

• Ein ausgearbeitetes Beispiel in Originalgröße: bblocks-heritage (Quelle), Profilketten, Validierungsregeln, Beispiele und alles Weitere. 

• Die Fähigkeiten, bereit zur Installation: OGC LLM-Kompetenzen (Quelle) stellt die Erstellungs- und Nutzungsfunktionen bereit, die Sie oder Ihr Assistent installieren können. Funktioniert mit claude.ai, Claude Code und der Claude API. 

• Der Rahmen: das OGC Blocks-Dokumentation erklärt die Vorgehensweise und wie man ein eigenes Register anlegt. 

Die Methode in Kürze: Vor der Modellierung wird geprüft, was bereits existiert. Anforderungen werden Standards zugeordnet, bevor sie in Schemata umgesetzt werden. Modellierung und Validierung erfolgen schrittweise anhand realer Daten. Jede nicht offensichtliche Erkenntnis wird dokumentiert, um den Aufwand auf einen einzigen Schritt zu beschränken. Es handelt sich um einen iterativen Prozess, nicht um eine Spezifikation, die in einem Durchgang erstellt wird. Ein KI-Assistent mit den entsprechenden Fachkenntnissen beschleunigt diesen Prozess und ermöglicht so überhaupt erst die Durchführung von Iterationen in dieser Granularität. Er ersetzt den iterativen Prozess jedoch nicht. 

Im Rahmen von HERITALSE wurden die Anforderungen realer Kulturerbestätten in ein öffentliches Datenmodell umgewandelt: 27 Blöcke, die jeweils auf etablierten Standards der Community basieren, über eigene Validierungskriterien und eine eigene Semantik verfügen und speziell für die Anforderungen von Geodaten und BIM entwickelt wurden, anstatt diese zu ignorieren. Die dafür notwendigen Ressourcen, Werkzeuge und Dienstleistungen (die Kompetenzen, der Suchdienst, die Methode selbst) sind veröffentlicht, in einem realen Anwendungsgebiet getestet und bereit für die nächste Herausforderung.