Wikipedia:WikiProjekt Österreichische Denkmallisten/Migration auf neue BDA-Datenbank

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Das BDA hat ihre in die Jahre gekommene DB (DMDB - Denkmaldatenbank) auf eine neue Basis (HERIS - Heritage Information System) gestellt und die Daten aus dem Altsystem auf das neue System migriert. Die nächste Publikation (geplant für etwa Februar 2021) wird bereits auf Basis des neuen Systems erfolgen. Diese Seite dient

  • der Beschreibung der für uns wichtigen Änderungen
  • als Infoschnittstelle und Feedbackkanal zum BDA
  • der Planung der Migration auf unserer Seite
  • der Planung der notwendigen Umstellungen in unseren Prozessen

Änderungen und Ergänzungen und Fortschreibungen bitte direkt in diesem Dokument, Fragen und Diskussionen umseitig. lg --Herzi Pinki (Diskussion) 15:52, 6. Okt. 2020 (CEST)[Beantworten]

  • 6. Oktober 2020: Kickoff Treffen beim BDA (Herzi Pinki, BDA)
  • Dezember 2020: Probepublikation Steiermark

ID[Quelltext bearbeiten]

  • Die uns bekannte ObjektID (DMDB-id) wird durch eine davon unabhängige neue HERIS-ID ersetzt. Diese ist ebenfalls numerisch.

Objektstruktur[Quelltext bearbeiten]

  • Das BDA geht den Schritt von einer Modellierung nach KGs zu einer Objektmodellierung (ganze Brücke als ein Objekt, Stichwort Objekttreue). Dies betrifft Eisenbahnen, Brücken, Wasserleitungen, Stadtmauern etc. Die (Um-)Modellierung als ein Objekt erfolgt nach und nach manuell und es ist davon auszugehen, dass beide Modellierungen parallel noch eine Zeitlang weiter bestehen werden. Die Änderungen in allen Bereichen werden erst langsam kommen. Für die kommende Listenpublikation wird das nur einen sehr schwachen Effekt haben, obwohl die Listen offensichtlich anders aussehen werden.
  • Ein Objekt kann eine Anlage, ein Ensemble oder ein Baudenkmal sein. Anlagen können aus mehreren Baudenkmälern bestehen, Ensembles aus mehreren Anlagen und / oder Baudenkmälern. Ensembles werden nicht veröffentlicht, wie Anlagen veröffentlicht werden, wird beim BDA noch diskutiert. Jedenfalls werden die einzelnen Baudenkmäler publiziert.
    • Schon bisher war eine Brücke als Anlage modelliert, mit den zwei KG-seitigen Teilen. Allerdings wurde die Anlage (die gesamte Brücke) bisher nicht publiziert.
    • Die bestehenden Anlagen hatten eigene IDs, die unabhängig von den ObjektIDs vergeben wurden, daher kann dieselbe ID (alt) bei einer Anlage und bei einem Baudenkmal vorkommen. Da wir bisher keine Anlagen haben, macht das bisher auch keine Probleme. In Zukunft wird die HERIS-ID eindeutig über alle drei Typen von Objekten sein.
  • Durch die Modellierung als ein Objekt kann dieses jetzt mehrere Adressen haben und mehreren Gemeinden und KGs zugeordnet werden. In der Datenbank gibt es für jede KG einen Satz zum Objekt mit (Gemeinde, KG, Grundstücksnummernliste in der KG).
    • Diese Modellierung sagt nichts über die Publikation aus. Aus Publikationssicht besteht das Requirement (gegenüber den Gemeinden und BMs), jedes Objekt in allen relevanten Gemeinden zu publizieren. Wie das konkret aussieht, ist noch offen.
    • Gemeinden und KGs sind keine Texte mehr, sondern kommen direkt vom BEV. In der Publikation beinhalten sie die Gemeindekennzahl bzw. die Katastralgemeindenummer. Wie das im Detail in der endgültigen Publikation aussehen wird, ist offen. Aktuell etwa Birkfeld (61757).
    • Adressen werden aktuell als Straße Nr., PLZ Gemeinde publiziert. (alt: nur Straße Nr.)

Datenblätter[Quelltext bearbeiten]

Die Datenblätter scheinen umfangreicher zu sein, insbesondere beschreiben sie jeweils ein Objekt (auch wenn in mehreren KGs) und beinhalten eine Karte (mit Shape im besten Fall). Sie sind aktuell auch wesentlich fetter (im Sinne von Bytes)

Schnittstelle und Feedback zum BDA[Quelltext bearbeiten]

  • Wir bekommen eine Mapping-Tabelle DMDB-id : HERIS-ID (zumindest für die Altobjekte, die eine DMDB-id haben).
  • Wir bekommen in geeigneter Form ein Mapping der alten Anlagen-ids (die wir bisher nicht kennen) auf die neuen HERIS-IDs für diese Anlagen. (Begründung: Irgendwann wenn statt der Teilobjekte die Anlage publiziert wird, brauchen wir eine Zuordnung der alten Beschreibungen und Bilder zu den neuen Anlagen-Objekten.)
  • Wir bekommen die noch fehlenden Objekt-IDs für Altobjekte, um alle Objekte in unseren Listen mit ID versehen zu können. (verantwortlich User:Herzi Pinki)
  • Wir bekommen vorab eine Probepublikation für die Steiermark, um
    • eventuell systematische Fehler frühzeitig zu erkennen
    • um unsere Prozesse zu testen
  • Ich habe darum gebeten, folgende Daten mitzuveröffentlichen (zumindest im CSV): Kategorisierung (Objektklasse), Unterschutzstellungsdatum
  • Eventuell können genauere Angaben zu Teilunterschutzstellungen (TU) veröffentlicht werden, um uns Informationen zu geben, welche Teile eines Objekts relevant zum Fotografieren sind.

Planung Migration WP[Quelltext bearbeiten]

Planung Migration Prozesse[Quelltext bearbeiten]

Vorbedingungen[Quelltext bearbeiten]

Für eine Migration muss der Datenstand auf Wikidata sauber sein. Dies umfasst die folgenden Punkte, wenn jemand was übernehmen oder ergänzen will, nur zu.

Hilfreich[Quelltext bearbeiten]

Generell sollten alle html-Kommentare in den Denkmallisten auf Notwendigkeit, Aktualität und Sinnhaftigkeit geprüft werden und eventuell durch besseres ersetzt werden (Korrekturen, Recherche, Anmerkung). Suche. (464 Treffer - 2021-01-27)

(27.Jänner 2021, Tel mit BDA, Herzi Pinki (Diskussion)):

  • in der neuen Datenbank sind etwa 50 % der Adressen falsch. Bei der Migration wurde versucht, die alten Adressen gegen die Daten des BEV zu verifizieren, und dabei sind massenhaft Fehler passiert, so als Beispiel wurde aus einer Adresse Hauptstraße 22-28 eine neue Adresse Hauptstraße 22 im nächstn Ort wo eine solche Adresse gefunden wurde (kann dann gerne mal 30 km weg sein). Die Adresse ist also kein zuverlässiges Kriterium für was für ein Mapping auch immer.
  • KG und GstNr. sind korrekt migriert, könnten als Basis für ein Mapping verwendet werden.
  • Durch die falschen Adressen wird sich die Publikation der Listen verzögern, im besten Fall bis das Problem gelöst ist (das BDA hat nichts davon, massenhaft falsche Daten zu publizieren)
  • Ich habe nochmals die Notwendigkeit einer Mappingtabelle DBMS-ID -> HERIS-ID angesprochen, auch die Variante, diese einfach aus der DB extrahieren zu lassen (mit SQL-Bordmitteln) und nicht in einen Publikationsprozess einfließen zu lassen. Ist auf Wohlwollen gestoßen und auf die Zusage von Unterstützung an den zuständigen Stellen beim BDA.
  • das publizierte csv ist in der Zwischenzeit wieder auf den Stand von davor geschrumpft. Sinnvolle Zusatzdaten sind wieder verschwunden. Mein BDA-Kontakt wird sich dafür einsetzen, dass ein vollständigeres csv wieder publiziert werden kann, nicht öffentlich, aber z.B. als Schnittstelle zu uns.

(9.2.2021)

zu einzelnen Punkten, wenn mehr Ausführlichkeit notwendig ist.

Eindeutigkeit der HERIS-ID[Quelltext bearbeiten]

Die HERIS-ID bezeichnet ein Objekt, u.U. Gemeinde- oder KG-übergreifend. Im Gegensatz zur bisherigen ObjektID ist die HERIS-ID nicht mehr global eindeutig, wenn die Objekte weiter so geschnitten werden, wie in unseren Denkmallisten (d.h. nach Gemeinden und KGs). Sie ist nur zusammen mit Zusatzinfo wie Gemeinde oder KG ein Identifikator für eine bestimmte Tabellenzeile.

Ich schlage folgende Änderung beim Aufbau unserer Listen vor:

  • Gemeindeübergreifende Objekte werden weiter in beiden Gemeinden als denkmalgeschützte Objekte angeführt, mit identen Daten in beiden Listen. Der Preis ist Redundanz vs. Auffindbarkeit in der Gemeinde. Ob das durch Mehrfachverwendung einer ausgelagerten Tabellenzeile passiert oder durch c/p, ist von der Logik egal.
  • KG-übergreifende Objekte (derselben Gemeinde) bekommen nur noch einen Eintrag in dieser Gemeinde, mit mehreren KGs. Wir sparen an der Redundanz, auf Kosten der Sortierbarkeit nach KG. Das Objekt wird unter der alphabetisch ersten KG einsortiert und enthält alle KGs und GstNrn. des Objekts.
  • Das erlaubt insgesamt weiterhin die Adressierung per Anker innerhalb einer DL in jeder der beteiligten Gemeinden. Die Adressierung erfolgt aber über unseren internen Schlüssel, das wäre die wikidata-ID. Ohne dem Gemeindezusatz ist diese ID nicht mehr in allen Fällen eindeutig.
  • Wikidata-Einträge zu einem Objekt (aufgeteilt auf mehrere KGs) werden zu einem einzigen Objekt zusammengefaltet.

Brücke über Grenze (Gemeinde, KG)[Quelltext bearbeiten]

Brücke alt besteht aus:

  • Anlagenklammer für die Brücke (mit Anlagen-ID; Objekt wird nicht publiziert)
  • 2 Teilobjekten dies- und jenseits der Grenze (mit den bekannten Objekt-IDs, beide Objekte werden publiziert)

Migration BDA-seitig:

  • Anlagenklammer-ID -> HERIS-ID der Anlage neu
  • Teilobjekte ObjektIDs -> HERIS-IDs neu
  • Verortungsdaten (Gemeinde, KGs, Grundstücksnummern) wandern von den Teilobjekten zur Anlage

Brücke neu besteht aus:

  • Anlage Brücke (mit HERIS-ID, wird publiziert, enthält die KGs, Grundstücksnummern der beiden ehemaligen Teilobjekte)
  • 2 Teilobjekte (mit den migrierten HERIS-IDs; werden nicht mehr publiziert)

Bei der Umstellung und Erstpublikation der Brücke als Objekt statt der beiden Teilobjekte müssen wir den Bezug zwischen der uns unbekannten Anlagenklammer und den ehemaligen Teilobjekten herstellen und geeignet in unseren Listen berücksichtigen. Größenordnung ~200-500 Objekte. Da entweder die Anlage neu oder die Teilobjekte alt publiziert werden (aber nicht beides), brauchen wir zusätzlich noch ein Mapping von den IDs der Anlagenklammer bzw. von den Objekt-IDs der Teilobjekte zur neuen HERIS-ID für die Anlage.

Aktuelle Publikation bei grenzüberschreitenden Objekten (neu)[Quelltext bearbeiten]

Bei einem Objekt über KG-Grenzen (Gemeindegrenzen sind immer auch KG-Grenzen) werden aktuell für jede KG der Gemeindename mit Gemeindekennziffer je einmal in der Spalte Gemeinde und der Name der KG mit Katastralgemeindenummer je einmal in der Spalte KG publiziert. Dies führt u.U. zu Mehrfachnennungen von Gemeinden, aber zu einer gleichen Anzahl von Gemeindenamen in der Spalte Gemeinde und der Anzahl der KGs in der Spalte KG. Liegt ein Objekt in den KGs KG1 und KG2 in der Gemeinde G, so wird folgende publiziert:

  • Gemeinde:= G, G
  • KG:= KG1, KG2
  • Query (aktuelle mapping Tabelle)