10. Sitzung, 20.10.2025, 11:00-13:00 Uhr

Protokoll des NFDI4Objects Community Clusters “Denkmal-, Maßnahmen-, Schutzflächen / Protected Heritage Sites”

vom 20.10.2025, 11:00-13:00 Uhr

Chairs: Ulrich Himmelmann (GDKE), Christian Bollacher (LAD)

Teilnehmende: 17

Agenda

1. Begrüßung und Tagesordnung

2. Termine und Ankündigungen

3. Rückblick zum Bring-your-own-data-Event am NFDI4Objects Community Meeting 2025

4. Datierungsmodellierung

5. Diskussion

6. Abschluss

1. Begrüßung und Tagesordnung

Die Chairs begrüßen die Anwesenden, eröffnen die Sitzung und stellen die Tagesordnung vor.
Uli Himmelmann ist terminlich verhindert, dafür moderiert Andreas Puhl.

2. Termine und Ankündigungen

Das nächste Treffen des CCs findet am Dienstag, 11.11.2025, von 11-13 Uhr statt.

3. Rückblick zum Bring-your-own-data-Event am NFDI4Objects Community Meeting 2025

Das Bring-your-own-data-Event am letzten Tag des Community Meetings von NFDI4Objects in Bochum am 02.10. war ein voller Erfolg. Gut zwei Stunden diskutierte eine kleine Runde Teilnehmender sehr lebhaft über die Anwendung des Kulturerbeobjekte-Datenmodells. Dabei wurde getestet, wie gut sich Daten der verschiedenen Denkmalämter in dem Datenmodell abbilden lassen. Das Ergebnis: Im Grunde passt das Kulturerbeobjekte-Datenmodell schon sehr gut. Wenige Angaben müssen noch in den Daten ergänzt werden, z.B. die datenhaltende Institution oder das datenhaltende System. Diese Daten werden logischerweise bislang nicht in den Dankenbanken der Denkmalämter benötigt.

Die Abbildung der Datierungsangaben funktionierte nach dem bislang überlegten Modell gut. Eine Schwierigkeit, auf die die Arbeitsgruppe stieß, sind Sammelobjekte bzw. Ensembles, die mehrere Objekte (mit unterschiedlicher Typ- und/oder Datierungsansprache) zusammenfassen. Hier muss die datenhaltende Institution überlegen, ob diese Ensembles in ihre einzelnen Bestandteile aufgeteilt werden können bzw. sollen, die dann als einzelne Kulturerbeobjekte abgebildet werden, oder ob jedes Ensemble durch ein Kulturerbeobjekt dargestellt wird. Bei einer Aufteilung, die die Beibehaltung genauer Datierungen und Typansprachen ermöglichen würde, kann über das Feld “Verweis” ein Bezug zum Gesamtenseble oder zu anderen Objekten aus dem Ensemble hergestellt werden.

In Zukunft soll es nach Abschluss der Diskussion um die einzelnen Datenmodelle weitere bring-your-own-data-Events geben. Diese werden vermutlich online stattfinden, um die Beteiligung einer größeren Runde zu ermöglichen.

4. Datierungsmodellierung

In der vergangenen CC-Sitzung wurde ein Datierungsmodell vorgestellt, das aus vier z.T. mehrteiligen Komponenten besteht. Um dieses Modell zu vereinfachen, wurde eine reduzierte Version entworfen.

Grundsätzlich gibt es bei den vorhandenen Daten drei Regelfälle für Zeitangaben:

1. Zwei (oder eine) absolute Angaben (z.B. 1184-1215)

2. Eine (oder mehrere) relative Angabe (z.B. frühe Urnenfelderzeit)

3. Mischform aus beidem

In der Nutzendenperspektive gibt es zwei Regelfälle:

I. "Filtere alle Siedlungen aus der Zeit zwischen Jahr X und Jahr Y“ -> setzt eine absolute Datierung voraus

II. „Filtere alle Siedlungen aus der Periode Z“ -> setzt eine relative Datierung voraus

=> beide Angaben, sowohl relativ als auch absolut, sollten also gegeben sein.

Als Lösung soll eine Mittelinstanz als Zeitstrahl entwickelt werden, auf den sich alle datengebenden Institutionen mappen können. Durch das Mapping kann eine digitale Übersetzung der absoluten Zahlen in hauseigene, relative Zeitbegriffe und umgekehrt erfolgen. Somit alle Institutionen ihr eigenes Datierungssystem (inklusive Epochenansprachen) behalten. Ein Mapping der eigenen Ansprachen auf die Mittelinstanz gewährleistet eine über-institutionelle Vergleichbarkeit.

Als Grundlage für diese Mittelinstanz kann der Zeitstrahl des Verbands der Landesarchäologien (https://www.landesarchaeologien.de/fileadmin/mediamanager/004-Kommissionen/Archaeologie-und-Informationssysteme/Thesauri/Zeitstrahl_V01.pdf) dienen, da hier bereits eine Vielzahl an Zeitansprachen gesammelt ist. Der Zeitstrahl muss allerdings noch um eine genauere Ansprache der rezenten Zeitepochen ergänzt werden, um die Bedarfe der Baudenkmalpflege zu integrieren. In einem zweiten Schritt müssen die verwendeten Zeitstufen bzw. Epochen der datengebenden Institutionen mit absoluten Zahlen definiert werden und mit der übergeordneten Mittelinstanz in Beziehung gesetzt werden. Dafür ist eine Veröffentlichung der Datierungen, beispielsweise mittels BARTOC notwendig. Als mögliches Werkzeug für das Mapping wird hierzu aktuell der Dienst DANTE als Vokabular-Repositorium und coli-conc/Cocoda als zugehöriges Mapping-Tool in Erwägung gezogen (beide von der VZG), allerdings muss noch getestet werden, ob sich diese Dienste für unsere Anforderungen eignen.

Die gemappten Datierungen ergeben dann insgesamt einen Thesaurus, der alle Datierungsansprachen abbilden können sollte. Durch die automatisch abgeleiteten Epochenbegriffe oder absoluten Zahlen reicht es, wenn nur eine Datierungsangabe (absolut oder relativ) im datenhaltenden System gegeben ist.

Nicht abbildbar sind Hiatus, hierzu könnte entweder ein Objekt mit Datierungsspanne über den Hiatus hinaus gegeben werden, oder zwei getrennte Objekte.

Für das Datenmodell zum Kulturerbeobjekt bedeutet dies folgendes: Es gibt vier Felder - ein Feld für die absolute Startdatierung, ein Feld für die absolute Enddatierung, ein drittes Feld für den relativen Epochenbegriff, und ein viertes Freitextfeld.

5. Diskussion

• Wo und wie erfolgt die Abbildung des Thesaurus?

Das ist aktuell noch etwas in der Schwebe. Geplant ist quasi ein Netz aus verschränkten Thesauri, dafür braucht man einen Dienst, der die verschiedenen Vokabulare hosten kann. Aktuell haben wir die Datendrehscheine DANTE der VZG ins Auge gefasst, da hier ein Mapping mit dem Tool coli-conc/Cocoda gut machbar wäre. Wir müssen aber noch klären, ob das so funktioniert, und einige Absprachen treffen.

• Müssen sowohl absolute Datierungen (Zahlen) als auch relative Datierungen (Begriffe) von den datenhaltenden Institutionen geliefert werden?

Nein. Es reicht eine von beiden Angaben, die durch das verknüpfte Vokabular auf die jeweils andere Datierungsangabe gemappt werden kann. Es können aber auch beide Angaben geliefert werden wenn vorhanden. Problematisch wird das nur, wenn beides gegeben ist, sich aber widerspricht. Das wird den Thesaurus vor ein Problem stellen. Aber dieser Fehler liegt dann im datenhaltenden System vor.

• Das automatische Mapping funktioniert nicht, wenn zwei Kulturen zeitgleich nebeneinanderleben, z.B. Germanen und Römer. In diesem Fall kann man nicht direkt von der Jahreszahl auf den Begriff gehen.

Das stimmt. Vielleicht lassen sich Kulturbegriffe auf einer untergeordneten Ebene abbilden, oder können in anderer Form in den Datensätzen hinterlegt werden.

• Datierungen, die nach hinten offen sind (z.B. Neuzeit oder Datierung unbekannt) sind ein Problem, wie gibt man das an?

Schwierig, müssen wir überlegen. Man könnte z.B. Datierungen bis in die Zukunft (AD 2100) anlegen.

• Wird die ganze Datierungshierarchie (Feinstufen) mitgetragen, oder nur eine Mittelebene?

Eigentlich soll die Datierung so genau angegeben werden, wie möglich bzw. bei der datenhaltenden Institution gegeben. Die verschiedenen Hierarchiestufen lassen sich außerdem automatisch aus dem Mapping ableiten, wenn eine genauere Ebene angegeben ist.

• Wie geht man mit Hiatus um?

Die Trennung muss nach dem vorgeschlagenen System im Objektdatensatz erfolgen, der Thesaurus kann keinen Hiatus abbilden. Je nachdem, wie es die Datengeber aktuell in ihren System vorhalten, wird aus einem Objekt mit Hiatus mehrere Objekte generiert oder ein Objekt mit Gesamtdatierung (und Hinweis auf Hiatus in Freitextfeld?) erzeugt.

• In der Baudenkmalpflege gibt es vermutlich häufiger den Fall unterschiedlich datierender Bauphasen, wie geht man damit um?

Kommt darauf an, ob die Datensätze einzeln (als Bauphase/Bauelement o.ä.) oder in einem Gesamtobjekt vorkommen. Bei einzelnen Datensätzen könnte man über die Verweise Bezug aufeinander nehmen. Wenn das Gebäude noch besteht, müsste das jüngste Datum heute sein.

• Der VLA-Zeitstrahl ist veraltet und muss nochmal überarbeitet werden. Warum erstellen wir nicht den Zeitstrahl neu?

Die Erstellung des Zeitstrahls war langwierig. Man muss ihn zwar an Stellen noch überarbeiten und v.a. für die Baudenkmalpflege ergänzen, er bietet aber eine gute Grundlage, da die Begriffe schon von allen abgesegnet sind. Die Daten liegen schonmal als CSV vor (https://www.landesarchaeologien.de/fileadmin/mediamanager/004-Kommissionen/Archaeologie-und-Informationssysteme/Thesauri/Vokabular-Datenstrukturen_v1.1.pdf), sodass man den Zeitstrahl leicht digitalisieren und nutzen kann. Grundsätzlich ist aber der Plan, als Mittelinstanz quasi die Epocheneinteilung zu verwenden, auf die sich dann alle Beteiligten mappen können. Der Vorteil des Mappings ist, dass keine weiteren Abstimmungen nötig sind. Alle können sich auf die Mittelinstanz mappen und müssen sich nicht 16+ mal auf die Datierungssysteme der andere Ämter korrellieren. Zuerst müssen aber noch die Epochen genau beschrieben und definiert werden. Außerdem muss für die Mappings eine jeweilige genaue Definition der Zeitstufen in den Ämtern vorliegen und veröffentlicht werden.
Dabei soll nicht die Genauigkeit der Ländersysteme verloren gehen, da das Mapping “nach unten” komplett offen ist. Abgebildet wird später nicht die Zeiteinteilung der Mittelinstanz, die dient lediglich als Grundlage für das Mapping.

• In manchen Landesämtern sind die Daten stärker auf den geografischen Raum und weniger auf die Datierung des Objekts ausgelegt, entsprehend gibt es oft mehrere Datierungsangaben für einen Datensatz (die Mehrphasigkeit wird im selben Objekt hinterlegt). In anderen gibt es zwar nur eine Datierung von-bis, z.T. werden aber kleinere Objekte an größere Objekte über das Freitextfeld angebunden, anstatt dass ein eigener Datensatz angelegt wird. Wie gibt man in diesen Fällen die Datierung an?

Im Grunde muss das die datenhaltende Institution entscheiden. Technisch wird in solchen Fällen vermutlich die Gesamtdatierung als von-bis angegeben. Genauere Informationen kämen in das Freitextfeld. Alternativ (wenn die Objekte getrennt herausgegeben werden können) könnte der Bezug aufeinander über das Verweis-Feld gemacht werden.
Oder man könnte überlegen, bei einer Mehrphasigkeit das Objekt mehrfach mit den einzelnen Datierungsphasen zu exportieren.

• Was genau bildet die Datierung ab? Die Bauzeit? Die Nutzungszeit bzw. das Bestehen? Die Existenz einer Fundstelle?

Eigentlich geht es um die Existenz der Objekte. Gerade in der Baudenkmalpflege ist es aber wichtig, auch Bauzeiträume als Phasen o.ä. angeben zu können. Einige Landesämter fahren hierzu ein ereignisorientiertes Modell, bei dem angegeben wird, um was für eine Datierung es sich handelt (z.B. Bauzeit, Bestandszeit, etc.). Dadurch würde das Datenmodell aber deutlich komplizierter werden. Die Information könnte man sonst im Freitextfeld hinterlegen. Wir sollten herumfragen, wie die Ämter diese Angaben machen, und ob die Freitextfeld-Option funktionieren würde. Trotzdem ist es wichtig, dass gerade ganz unterschiedliche Nutzungs- und Bauphasen angegeben werden können. Auch für Vorgängerbebauung besteht die Frage, wie die Daten in den Ämtern angelegt sind, ob als einzelne Objekte/Datensätze oder gesammelt in einem Datensatz.
Grundsätzlich muss aber auch bei der Existenz geschaut werden, wie die Datierung am besten angegeben wird. Ein eisenzeitlicher Grabhügel kann auch heute noch in der Landschaft sichtbar sein, trotzdem würde niemand als Datierung “Eisenzeit bis heute” angeben. Vielleicht kann in diesem Punkt eine Kombination mit dem (noch nicht zu Ende diskutierten) Feld “obertägige Sichtbarkeit” die Existenz bis heute angegeben werden, ohne die Datierung bis heute laufen zu lassen.
In jedem Fall muss die jeweilige datenhaltende Institution entscheiden, wie sie ihre Objekte zur Verfügung stellt (z.B. als römische Porta Nigra oder bestehend bis heute), das Datenmodell kann und darf die Form nicht voraussetzen.

Abschluss

Grundsätzlich können sich die Teilnehmenden vorstellen, dass ein System bestehend aus zwei absoluten Datierungsfeldern (von/bis) und relativer Datierung funktioniert. Wir übernehmen diese Felder vorerst für das Datenmodell.