Wo kommen die unterschiedlichen Daten der 'Standardisierten Orte' her?
Grüß Gott,
wenn ich eine Suche nach Namen starte (Beispiel: Schilling aus Eschwege), dann erhalte ich unter Anderen einen Treffer mit der aktuellen Ortsangabe:
Niederdünzebach, Eschwege, Werra-Meißner-Kreis, Hessen, Deutschland
Einmal abgesehen davon, dass diese Verwaltungshierarchie anno 1788 nicht gültig war (was den FS-Eingabeempfehlungen widerspricht, den jeweiligen Kontext anzugeben), wundert es mich, dass beim Aufruf dieses Treffers, dann bei allen Ortsangaben
Niederduenzebach,Eschwege,Hesse,Germany
erscheint, also nicht die Form wie bei der Suche. Wie kommt das zustande?
Richtig an dieser Stelle wäre übrigens in Abhängigkeit zum Datum der standardisierte Ort
Niederdünzebach (D) (51.177991,10.094938) am: 17.10.1788
Niederdünzebach
Bischhausen Amt (1654-1807)
Hessen-Kassel (1263-1802)
Heiliges Römisches Reich deutscher Nation (1512-1806)
Antworten
-
Guten Tag, die unterschiedlichen Angaben bei den "Standardisierten Orten" sind im Moment leider noch ein wenig unübersichtlich. Wir arbeiten daran, es besser zu machen. Das Projekt ist gestartet, wird aber einige Zeit in Anspruch nehmen, bis es beendet ist.
1 -
Grüß Gott, Frau Koggelmann,
jein. Ich habe das Gefühl, dass der FS-Ansatz grundlegend falsch ist. Es werden standardisierte Orte (SO) angelegt, die jeder Eingeber beliebig abändern kann. Dieser wählt dann einen der jetzt vorhandenen SO aus, um das dicke Ausrufezeichen weg zu bekommen, auch wenn dieser SO total falsch ist, und schreibt eine beliebige Erfindung zum Ort als Anzeigetext hin.
Es sieht manchmal so aus, dass insbesondere die Transkribierer gern alle hessischen Orte in eine preußische Provinz (Hessen-Nassau) legen, auch wenn diese erst ab 1868 existiert. All die Tausenden von Ortsangaben davor sind daher grundlegend falsch angelegt worden. Sollen diese Fehler dann später irgendwann einmal mühsam oder gar nicht korrigiert werden? Von wem?
Ähnliches gilt übrigens auch für die Datumsangaben, die man mehr oder weniger frei gestalten kann. Warum?
Der bessere Weg bestände darin, dem Eingeber aufgrund des Datums für jeden Ort nur eine gesicherte Verwaltungshierachie vorzuschlagen, die er nicht ändern kann, auch wenn 'Hessen' im Englischen einfach nur 'Hesse' heißt und der Vorschlag den historisch richtigen Namen 'Hessen' benutzt. Damit wären auch so lustige Variante wie 'Hesse-Kassel' oder 'Hesse-Nassau' vom Tisch.
So würden sich auch meist unterschiedliche Angaben für den Ort zum Geburts-, Heirats- und Sterbedatum ergeben. Der Benutzer gibt einen Ort und ein Datum ein und erhält die automatisch erstellte Hierarchie. Ich versuche es an einem Beispiel. Geburt 01.07.1800
siehe Bild 1
ergibt (Ort, ggf. Straße/Haus, Koordinaten) mit anschließender Hierarchie (noch ist die Person ein Hesse)
Eschwege (D), An der Wasenmeisterei 15 (51.184729,10.062360) am: 01.07.1800
Eschwege (974-heute)
Eschwege Amt (1567-1807)
Hessen-Kassel (1263-1802)
Heiliges Römisches Reich deutscher Nation (1512-1806)
Die Person stirbt am 01.07.1869 mit einer neuen Hierarchie (jetzt ist sie ein Preuße)
Eschwege (D), An der Wasenmeisterei 15 (51.184729,10.062360) am: 01.07.1869
Eschwege (974-heute)
Eschwege Lk (1851-1973)
Kassel Rb (1868-1944)
Hessen-Nassau (1868-1944)
Preußen Königreich (1701-1918)
Norddeutscher Bund (1867-1870)
0 -
Grüß Gott, Frau Kollmann,
leider kann ich meinen langen Kommentar von gestern hier nicht mehr finden. Er ist möglicherweise untergegangen oder (doch nicht etwa) gelöscht worden.
Ich will meine Behauptung "die jetzige Form der Standardisierten Orte (SO) ist eine Fehlentwicklung" noch etwas verstärken "SO sind eine automatisierte, systematische Fehlerquelle, Schade um die eingesetzte Arbeit" und untermauern.
Schauen wir dazu einige Beispiele an:
Typisch sind die unterschiedlichen Datumsangaben. Nach wenigen Tagen vergisst der normale Eingeber (so wie ich auch) seine eigenen Regeln zur Datums- und Ortsangabe. Gebe ich die aktuelle Verwaltungshierarchie oder die historisch richtige Verwaltungshierarchie an? Gebe ich das Datum deutsch oder englisch, in Kurz- oder Langform ein?
Dass Oberdünzebach anno 1692 zur preußischen Provinz "Hessen-Nassau" gehören soll, ist natürlich falsch.
Aber auch andere Eingeber machen das. Hier hat dazu die Tastatur kein 'ü', aber auch kein 'ß' wie auch die anderen Umlaute. Das gilt natürlich auch für die Spezialzeichen anderer europäischer Sprachen.
Die falschen tschechischen Kleinbuchstaben scheinen in diesem Fall aus MyHeritage falsch übernommen zu werden.
Die Liste der Merkwürdigkeiten lässt sich (fast) beliebig verlängern:
So heiratet ein Mann/eine Frau hin und wieder denselben Partner, ohne dass FS eine Warnung ausgibt:
https://www.familysearch.org/tree/person/details/K64D-CSM
Kehren wir zum eigentlichen Thema den SO zurück. Der normale Eingeber kennt sich bei der Bearbeitung von Nebenlinien nicht immer mit den Sonderfällen in der jeweiligen Gegend aus. Er wird daher immer, wenn die Warnung kommt, dass es sich nicht um einen SO handelt, den einfachsten Weg suchen und irgendeinen Ort aus der mühsam erstellten Liste der SO auswählen. Dabei fehlen in dieser Liste die Angaben zur Gültigkeit: In welchem Zeitintervall ist Dünzebach ein Ort unter preußischer Herrschaft?" Er wählt somit meist die falsche Hierarchie aus. Die sichere Seite ist die heutige Hierarchie. Aber auch hier findet man Unterscheidungen wie "Gemeinde", "Wohnplatz", "Siedlung" zu ein und demselben Ort.
Dazu kommt, dass es im zerstückelten Deutschland für jeden Ort eine Vielzahl von unterschiedlichen Zeitintervallen gibt. Schon wenige km Luftlinie zwischen zwei Orten kann eine total abweichende Hierarchie ergeben. In Böhmen soll es Orte geben, bei denen einzelne Häuser in Ortschaften zu unterschiedlichen 'Herrschaften' gehörten. Also die Hierarchie nicht einmal für einen Ort zu einem Zeitpunkt einheitlich war.
Bevor es noch langweiliger wird, höre ich einfach auf und warte auf die Antwort
mit herzlichen Grüßen vom Waltschrat
0 -
0
-
Verschwinden meine Kommentare?
0 -
Jetzt noch ein Demo-Bild dazu. Vielleicht liegt es ja daran?
0 -
Dürfen Kommentare kein Bild enthalten?
0 -
Also noch ein Versuch mit einer Kopie. Dabei sind aber alle Bilder nach hinten gerutscht. Der Kommentar von gestern scheint aber wirklich untergegangen zu sein.
Grüß Gott, Frau Kollmann,
leider kann ich meinen langen Kommentar von gestern hier nicht mehr finden. Er ist möglicherweise untergegangen oder (doch nicht etwa) gelöscht worden.
Ich will meine Behauptung "die jetzige Form der Standardisierten Orte (SO) ist eine Fehlentwicklung" noch etwas verstärken "SO sind eine automatisierte, systematische Fehlerquelle, Schade um die eingesetzte Arbeit" und untermauern.
Schauen wir dazu einige Beispiele an:
Typisch sind die unterschiedlichen Datumsangaben. Nach wenigen Tagen vergisst der normale Eingeber (so wie ich auch) seine eigenen Regeln zur Datums- und Ortsangabe. Gebe ich die aktuelle Verwaltungshierarchie oder die historisch richtige Verwaltungshierarchie an? Gebe ich das Datum deutsch oder englisch, in Kurz- oder Langform ein?
Dass Oberdünzebach anno 1692 zur preußischen Provinz "Hessen-Nassau" gehören soll, ist natürlich falsch.
Aber auch andere Eingeber machen das. Hier hat dazu die Tastatur kein 'ü', aber auch kein 'ß' wie auch die anderen Umlaute. Das gilt natürlich auch für die Spezialzeichen anderer europäischer Sprachen.
Die falschen tschechischen Kleinbuchstaben scheinen in diesem Fall aus MyHeritage falsch übernommen zu werden.
Die Liste der Merkwürdigkeiten lässt sich (fast) beliebig verlängern:
So heiratet ein Mann/eine Frau hin und wieder denselben Partner, ohne dass FS eine Warnung ausgibt:
https://www.familysearch.org/tree/person/details/K64D-CSM
Kehren wir zum eigentlichen Thema den SO zurück. Der normale Eingeber kennt sich bei der Bearbeitung von Nebenlinien nicht immer mit den Sonderfällen in der jeweiligen Gegend aus. Er wird daher immer, wenn die Warnung kommt, dass es sich nicht um einen SO handelt, den einfachsten Weg suchen und irgendeinen Ort aus der mühsam erstellten Liste der SO auswählen. Dabei fehlen in dieser Liste die Angaben zur Gültigkeit: In welchem Zeitintervall ist Dünzebach ein Ort unter preußischer Herrschaft?" Er wählt somit meist die falsche Hierarchie aus. Die sichere Seite ist die heutige Hierarchie. Aber auch hier findet man Unterscheidungen wie "Gemeinde", "Wohnplatz", "Siedlung" zu ein und demselben Ort.
Dazu kommt, dass es im zerstückelten Deutschland für jeden Ort eine Vielzahl von unterschiedlichen Zeitintervallen gibt. Schon wenige km Luftlinie zwischen zwei Orten kann eine total abweichende Hierarchie ergeben. In Böhmen soll es Orte geben, bei denen einzelne Häuser in Ortschaften zu unterschiedlichen 'Herrschaften' gehörten. Also die Hierarchie nicht einmal für einen Ort zu einem Zeitpunkt einheitlich war.
Bevor es noch langweiliger wird, höre ich einfach auf und warte auf die Antwort
mit herzlichen Grüßen vom Wiesenmichel
0 -
Grüß Gott, Frau Kollmann,
hier haben wir den Fall, dass ein Eingeber die Ortsangabe nach seinem Gusto abändert
https://www.familysearch.org/tree/person/details/M162-DJ4
In Eschwege gibt es zwei Kirchen, je eine in der Alt- und eine in der Neustadt. Hier will der Eingeber die Quelle im Ortsnamen verstecken. Erneut frage ich mich, was dann Standardorte bewirken sollen, wenn man diese willkürlich abändern kann. Einen Ort 'EschwegeNeustadt' gibt es nicht.
Beim wortgleichen Heiratsort hat er jedoch vergessen, einen Standardort auszuwählen. Daher eine Fehlermeldung
0 -
Grüß Gott, Frau Kollmann,
hier fehlt im Programm eine Prüfung
https://www.familysearch.org/tree/person/details/LH5K-77P
Eine Person kann nicht am gleichen Tag zwei unterschiedliche Personen heiraten, auch wenn diese wahrscheinlich Doppelgänger sind und als solche nicht erkannt werden.
Zumindest eine Fehlermeldung sollte erscheinen.
0 -
Grüß Gott, Frau Kollmann,
ja, ich nerve, aber ich habe schon wieder eine Frage:
https://www.familysearch.org/tree/person/details/LH5K-7CF
Können tatsächlich zwei Personen
cagerth477976 und emaul3415665
gleichzeitig an einem Datensatz Änderungen vornehmen. Sind das wirklich "echte" Personen, denn beide produzieren dieselben ständig falschen Ortsbezeichnungen?
Wenn man sich die Treffer bei der Suche nach 'Neusuess' (Neusüß) anschaut, beispielsweise
https://www.familysearch.org/tree/person/details/MHRN-B1P
dann treten bis zu drei Doppeleinträge des Namens 'Neusuess' unter diesen Änderungsnamen am gleichen Tag auf. Kann man sich wirklich auf Einträge aus dem Jahre 2012 in FamilySearch verlassen?
0 -
Im Frühling 2012 wurden Daten aus dem Vorläuferprogramm newFamilySearch (nFS) in den Familienstammbaum übernommen. Das Vorläuferprogramm von etwa 2006 wurde im Februar 2014 abgeschaltet. Also sind Einträge vom Frühling 2012 in Wirklichkeit fast immer älter und daher ist es auch möglich, dass zwei völlig verschiedene Heiraten am gleichen Tag vom Vorläuferprogramm in den Familienstammbaum übertragen wurden.
Einreicher mit einem Kontaktnamen mit vielen Ziffern am Ende haben diese Einreichungen schon vor Jahrzehnten vorgenommen - evtl. leben diese Einreicher heute nicht mehr.
Bezüglich der von zentraler Stelle durchzuführenden Erneuerung der vielen unrichtigen standardisierten Ortsvorschläge muss ich um viel Geduld bitten - dieses Projekt, an dem ich auch mitarbeite, wird noch einige Jahre benötigen, bis zufriedenstellende Vorschläge erscheinen.
Mit freundlichen Grüßen
FamilySearch Support
Hans-Jürgen Kuhlo
0 -
Grüß Gott, Hans-Jürgen,
wie schon die anderen Kommentare von mir darlegen, habe ich das Gefühl, dass in FS sehr viel unnötige Arbeit in ein eher schwaches Datenmodell gesteckt wird, das ich natürlich nicht kenne. Ich selbst arbeite in meiner lokalen Datenbank mit einem ganz einfachen Modell (hier ohne die notwendigen Nachschautabellen dargestellt)
Die Tabelle 'tblOrtVerwaltung' enthält die verwaltungstechnischen (theoretischen) Objekte. Daneben gibt es noch die physischen Objekte in einer dreistufigen Hierarchie Ort - Straße - Haus, die ich hier aus Platzgründen außen vor lasse. Aber eine Person wird nicht in einem Ort sondern in einem Haus/Hütte/Kate/Schuppen... geboren. Gerade die böhmischen Forscher hängen dann die Hausnummer an den Ortsnamen an, so dass es hunderte von ähnlichen Orten gibt. Die Tabelle 'tblOrtVerwaltungVerwaltung' verknüpft die Objekte untereinander. Alle Daten sind mit einer booleschen Variable versehen, die angibt, ob das Datum geschätzt oder gesichert ist. Es handelt sich jeweils um "echte" Datumsangaben, also nicht um unscharfe Angaben mit 'vor, nach, um, ca.' und was noch denkbar ist.
Nach der Eingabe der notwendigen übergeordneten Verwaltungsobjekte und deren Verknüpfung sollte nun jeder FS-Eingeber aufgrund der exakten Eingabe des Ortes und eines Prüfdatums automatisch den richtigen Standardisierten Ort erhalten. Einfach gesagt, er gibt diesen nicht in FS ein oder sucht ihn in einer langen Liste aus. Vielmehr wird die Verwaltungshierarchie automatisch aus der Ortsangabe dem Ereignisdatum (Geburt, Heirat, Tod, ...) berechnet. Nehmen wir mein Forschungsgebiet an: Ort = Dautmergen, Geburtsdatum = 01.07.1820. Das führt zum Ergebnis:
Hier ist die Spur eingeschaltet, so dass er den Suchvorgang mitverfolgen kann. Am Ende steht die Verwaltungshierarchie zusammen mit einem Gültigkeitsintervall für diese Hierarchie. Diese Hierarchie kann für den Todestag (nach 80 Jahren) gerade in dieser Gegend völlig anders aussehen:
Da muss der Ahnenforscher nicht lange suchen, welcher 'Standardisierte Ort' gilt denn nun für dieses oder jenes Datum?
Um nun zu prüfen, ob die Verwaltungshierarchie für alle denkbaren Ereignisdaten gilt, benutzt der Orts-Verwalter (wie beispielsweise Du) einen Pfadprüfer
Aha, das 'Oberamt Hohenberg' ist noch nicht richtig eingehängt (verlinkt). Beim 'Rheinbund' fehlt noch die Information, dass es sich um ein Spitzenobjekt, das kein Überobjekt besitzt, handelt usw.
Die Liste zeigt aber die vielen Pfade für einen Ort. Werden diese nun für alle Gültigkeitsintervalle in FS einzeln erfasst? Das sollte nicht wirklich sein. Das Gültigkeitsintervall steht in den erfolgreichen Zeilen am Ende in Klammern.
Muss sich der Ahnenforscher wirklich für jedes Lebensereignis durch 20 oder 30 Einträge hindurch quälen? Nein, das sollte automatisch erfolgen.
In der untersten Stufe muss ich dazu folgende Daten für den Ort Dautmergen eingeben (Darstellung ist nicht schön, aber hoffentlich verständlich)
Nr Name Ueber.Nr Name Spitze? Beginn Ende der Unterstellung
12 Dautmergen 35 Hohenberg Grafschaft Falsch 01.01.1304 31.12.1381
12 Dautmergen 33 Hohenberg Österreich Falsch 01.01.1382 31.12.1789
12 Dautmergen 34 Hohenberg OA Falsch 01.01.1790 31.12.1802
12 Dautmergen 16 Rottweil Oa Falsch 01.01.1812 31.12.1933
12 Dautmergen 14 Spaichingen OA Falsch 01.01.1806 31.12.1811
12 Dautmergen 31 Rottweil Kr Falsch 01.01.1934 30.09.1938
12 Dautmergen 15 Balingen Kr Falsch 01.10.1938 31.12.1972
12 Dautmergen 13 Zollernalbkreis Falsch 01.01.1973
Analog muss ich nun für jede Stufe die Überobjekte ergänzen und alle Spitzenobjekte mit 'Wahr' markieren. Hier sieht man eine Nebenbedingung beim Übergang von 31 nach 15. Der Wechsel vom Kreis Rottweil in den Kreis Balingen muss zeitlich lückenlos erfolgen (und natürlich geprüft werden).
Für alle Nachbarorte des Gebietes muss ich nur die unterste Ebene verdoppeln, alles andere ergibt sich automatisch. Ich bin noch am Überlegen, ob es Sinn macht, virtuelle Einheitsorte anzulegen, auf die die Basisorte eines Gebietes verweisen, dann spare ich auch noch das Verdoppeln ein. Leider erleiden selbst benachbarte Orte oft nicht das gleiche (geschichtliche) Schicksal.
Damit ist natürlich noch nicht das Eingabeproblem für einen Benutzer gelöst, der seinen Wunschort nicht findet. Ein in der Hilfe zu FS zu findende Vorschlag, den nächsten größeren Ort zu suchen, ist für das zerrissene Deutschland um diese Zeit nicht wirklich zielführend. Aber wir sollten vom Forscher verlangen, dass er den Namen und die Koordinaten in einem der vielen Kartenprogramme sucht.
Ein Endbenutzer kann dazu keinen ungeprüften Standardort eingeben. Dieser wird gemeldet und in das System im vorgestellten Stil eingepflegt. Anschließend ergeben sich alle Stanardisierten Orte automatisch für diesen physischen Ort.
Das sollte es erst einmal von meiner Seite sein. Gern erwarte ich eine Antwort auf meine Ideen. Sicherheitshalber habe ich sehr ausführlich dargelegt, dass die Ideen in der Praxis funktionieren.
Mit besten Grüßen vom
Wiesenmichel
0 -
Hallo Wiesenmichel,
vielen Dank für Ihre umfangreichen Ausführungen. Obwohl ich mich auch mit Datenbanken befasst hatte und vor etwa 20 Jahren mit Microsoft Access eine relationale Datenbank mit mehreren Tabellen für unsere Kirchengemeinde aufgebaut hatte, habe ich doch Schwierigkeiten, Ihre Tabellen ganz zu verstehen.
Zum zentralen Teil Ihrer Ausführungen:
Muss sich der Ahnenforscher wirklich für jedes Lebensereignis durch 20 oder 30 Einträge hindurch quälen? Nein, das sollte automatisch erfolgen.
Wenn ich das richtig verstanden habe, soll anhand eines zuerst eingegeben Datums und dann des Ortsnamens "automatisch" (nach einer entsprechenden Suche in der Datenbank) die richtige Verwaltungshierarchie erscheinen, die dann im Sinne des Standards angeklickt und damit in das Feld dafür hineingeschrieben wird. Das ist sicher ein großer Fortschritt, wenn es funktioniert. Bei Orten wie Hiddenhausen (im Kreis Herford in Nordrhein-Westfalen) oder dem von Ihnen angegebenen Dautmergen in Baden-Württemberg könnte das funktionieren, da es diese Orte nur einmal gibt. Aber leider gibt es viele Orte mehrfach (z.B. Wetter an der Ruhr und Wetter in Hessen, am schlimmsten könnten Orte wie Neustadt sein). Um hier den richtigen Ort auszuwählen, ist leider eine Eingabe von mehr Bezeichnungen notwendig, womit man dann schon etwas in die ungeliebte Verwaltungshierarchie hineinkommt.
Hier gibt es einen radikalen Vorschlag von einem "Kollegen", nur geographische Koordinaten zu verwenden. Das hat sicher viele Vorteile, da die Verwaltungshierarchie komplett umgangen bzw. nicht mehr benötigt würde. Allerdings sehe ich hier viele Widerstände, da bisher alle mir bekannten Genealogieprogramme (sowohl Partnerprogramme wie Ancestry und myheritage als auch Drittanbieterpprogramme wie AncestralQuest, Legacy Family Tree bis hin zu weiteren Programmen wie z.B. gesw2018) mit Verwaltungshierarchien arbeiten. "Kollege" deshalb, da wir ehrenamtlich für FamilySearch arbeiten, also keine Weisungs- oder Entscheidungsbefugnis haben.
Trotzdem haben Ihre Ausführungen in meinen Augen durchaus den Charakter für einen Verbesserungsvorschlag, der, wenn es eine passende Lösung für die vielen mehrfach vorkommenden Orte geben sollte, vielleicht in einigen Jahren in Angriff genommen werden könnte. Zur Zeit werden die von Ihnen als unterste Ebene beschriebenen Verwaltungshierarchie-Einträge konsolidiert und allein dafür sind wohl mehrere Jahre erforderlich. Dabei versuchen wir, relativ kurze Zeiträume (z.B. die Zeit von Napoleon) möglichst nicht mit aufzunehmen, damit eben nicht 8 (wie bei Dautmergen), sondern nur etwa 3-5 Einträge für einen Ort vorhanden sein werden (Zielwert).
Mit freundlichen Grüßen
FamilySearch Support
Hans-Jürgen Kuhlo
1 -
Grüß Gott, Hans-Jürgen,
schön, dass ich jetzt einen zumindest geduldigen Ansprechpartner habe, denn Geduld und ein wenig Hintergrundwissen braucht er.
Wichtig: Es handelt sich um einen Prototypen, der laufend weiter entwickelt wird, also wirklich noch nicht fertig ist. Ziel ist jedoch immer, mit minimalem Aufwand (für die Eingeber) ein maximales Ergebnis (für den Anwender) zu erreichen. Immer aus der jeweiligen Sicht.
Ich gehe von folgendem Modell für den Anwender aus und stelle mir dazu folgendes Szenario vor:
Der Anwender hat einen ungesicherten Vorfahren (ein Name und eine Ortsangabe). Dann möchte er diesen selbst, dessen Partner und dessen Eltern, oder umgekehrt dessen Kinder finden. Dazu braucht er weiterführende Primärdokumente. Er muss also den Ort und das dazu gehörige Archiv, genauer das buchführende (dokumenterzeugende) Amt zum Ort finden. Erst in zweiter Linie interessiert er sich für den geschichtlichen Kontext, der sich aus Ort und Ereignisdatum ergibt. Diesen Kontext muss er möglichst nicht selbst bestimmen, dies muss ihm FS liefern, ggf. muss er FS dazu (einmalig) unterstützen. Er gibt die Verwaltungshierarchie nie und nimmer selbst ein.
Umgekehrt muss er jedoch den Ort (Name plus den in FS vorbereiteten Koordinaten) genau bestimmen. Es ist richtig, dass es viele Mehrfachnamen gibt (angefangen von Großstädten wie Frankfurt bis hin zu Weilern wie Holzhausen). Aber die Suche nach dem Ort sollten wir ihm nicht ersparen.
Er legt nun seinen Ahn mit (einigen) Eckdaten und einem oder sogar mehreren Orten über die Lebenszeit an, mehr nicht. FS liefert ihm dann auf Wunsch die Verwaltungshierarchie zu Geburt, Heirat oder Tod aufgrund des jeweiligen Ortes und Datums.
Erst einmal zur Erklärung der Datenbank. Sie besteht nur aus zwei Tabellen
tblOrtVerwaltung
Sie enthält die Verwaltungsobjekte mit einer Existenzdauer und möglichen Ergänzungen, z. B. dem Typ wie "Staatenbund, Königreich, usw.". Eine dazu passende Nachschautabelle habe ich weggelassen. Diese Details müssen wir später besprechen. Welche Ueberordnungen sind erlaubt? (Reichsstädte, kreisfreie Städte,...)
tblOrtVerwaltung_1
ist dieselbe Tabelle, die der Abfragegenerator für die Doppelbeziehung (SQL-Generator) ergänzt. Also einfach weg denken.
tblOrtVerwaltungVerwaltung
verbindet je zwei Objekte aus tblOrtVerwaltung miteinander in der Rolle 'Unterobjekt' und 'Überobjekt' für ein bestimmtes Zeitintervall: Wann ist Hessen der Bundesrepublik beigetreten? Wann war der Kanton Eschwege in Teil des Departementes und damit des Königreichs Westphalen?
Die Idee dahinter ist nicht, die Geschichte zu "begradigen", um kurze Phasen einfach auszublenden (damit der Anwender nicht frustriert wird), vielmehr geht es um möglichst hohe geschichtliche Genauigkeit, von der der Anwender eigentlich nicht bemerken sollte.
Lassen Sie mich das mit der Mathematik vergleichen: Die Infinitesimalrechnung geht davon aus, dass durch Vergrößerung eine Kurve zu einer Gerade wird. Die Chaos-Theorie zeigt nun aber gerade den gegenteiligen Effekt, je näher man herangeht, desto chaotischer wird das System.
Wie könnte nun das Verfahren für die Eingeber aussehen? Oder, wie mache ich es gerade? Was kann ich daran noch verbessern? Was fehlt, was ist falsch?
Am besten fange ich auf der obersten Ebene an und lege die Spitzenobjekte an (hier natürlich aus meinen Testdaten heraus schon mit Unterobjekten versehen:
Das muss ich nur einmal für einige wenige Objekte machen. Es folgen nun die Unterobjekte usw. Ggf. muss ich auch fehlende Objekte nachträglich ergänzen.
Im Grunde kann ich schon mit dem ersten fertigen Pfad loslegen, der mich interessiert, aber natürlich noch nicht vollständig ist. Aber für die Experimente reicht es.
Mein Beispieldorf 'Niederdünzebach' hat keine Unterobjekte, jedoch eine eher bescheidene Anzahl von Überobjekten. Wo finde ich diese? Mühsam und Glücksache. Hessen ist ein Glücksfall. Es liefert Verwaltungshierarchien frei Haus
Ich kontrolliere noch einmal, ob ich alle dort genannten Überobjekte eingegeben habe und beginne diese von der rechten auf die linke Seite zu schubsen. Jetzt fehlt nur der passende Zeitbereich, der höchstens der Durchschnitt der beiden Existenzintervalle ist. Er wird entsprechend weiterer Unterlagen korrigiert und bestätigt.
Die Liste der 'Möglichen Überobjekte' wird auf die Dauer sehr groß. Also muss diese in der Zukunft möglichst intelligent beschränkt werden.
Das ist eigentlich schon alles 😂
Nun müssen wir das noch in die Anwendung einbauen. Nein, einige Kontrollen sind wichtig:
- Die Zuordnungsintervalle sollten keine Zeitlücke enthalten.
- Die Zuordnungen sollten einen vollständigen Pfad zu den Spitzenobjekten ergeben.
Das sieht schon einmal ganz gut aus, aber da ist der Rheinbund noch nicht als Spitzenobjekt markiert. Auch beim Amt stimmt noch etwas nicht. Das muss noch korrigiert werden, aber dann geht es endlich los
Eigentlich nicht viel für den ganzen Aufwand. Ereignisort oder -datum markieren und starten. Jetzt gibt es da aber noch den Geburtsort 'Aue'. Wenn er dieselbe Verwaltungshierarchie hat, dann sollten wir einfach die Zuordnungen von Niederdünzebach mit einem Klick auf diesen Ort verdoppeln können, oder? Ein neues Programm muss her.
Wie gesagt, der Prototyp ist noch lange nicht fertig. Fragen über Fragen:
- Was mache ich mit unsicheren Datumsangaben?
- Was mache ich mit chaotischen Zeiten (Revolutionen, Kriegen)?
- Wie ist das jetzt mit dem Donbas?
In diesem Sinne
Euer Wiesenmichel
0 -
Grüß Gott, Hans-Jürgen,
hast Du Dich inzwischen mit meinem Vorgehen auseinandersetzen können?
Ich selbst habe nun meinen letzten Baustein in das Prüfprogramm eingebaut, nämlich die Prüfung auf Lücken bzw. Überschneidungen der abgehenden Kanten zu den Überobjekten:
Ausgehend von der Ersterwähnung eines Ortes bis zum heutigen Zeitpunkt sollte es keine Lücken oder Überscheidungen geben. Am Beispiel sieht man, dass noch eine Lücke zwischen 1806 und 1811 von 1097 Tagen besteht, die nun der Geschichts-Spezialist untersuchen und ggf. füllen muss.
Mit den Restriktionen
- Exaktes Existenzintervall
- Exakte Zuordnung
kann nun die Verwaltungshierarchie für einen Ort von der Ersterwähnung bis heute automatisch erstellt werden. Dazu muss ich TopDown die Verwaltungsobjekte einmal erstellen und kann dann alle physischen Siedlungseinheiten anhängen.
Jetzt können noch die wirklichen Probleme der unscharfen Datumsangaben angegangen werden. Hierzu wird ein Datumsobjekt (im Sinne der OOP) angesetzt, das neben dem Einheitsdatum noch Informationen zu
- Bestätigung
- Kalendertyp (es gibt verschiedene Kalender)
Jetzt kann ich noch überlegen, ob es für die FS-Anwendungen noch notwendig ist, für jeden Ort eine Kalenderhistorie anzulegen. So wurde beispielsweise der Gregorianische Kalender nicht überall zum gleichen Datum übernommen. Daher feiern die Baseler ihren Fasching immer "verspätet", oder das Neujahr der orthodoxen Kirche.
Aber das wird erst dann interessant, wenn es wirklich nötig ist. Daher muss ich jetzt nur noch die Daten für meine Orte eingeben.
Grüße vom Wiesenmichel
0 -
Grüß Gott,
unerwarteter Weise herrscht bei diesem Thema lautes dröhnendes Schweigen. Eigentlich habe ich erwartet, dass die vielen Eingeber von 'Standardisierten Orten' mir erklären, warum die aktuelle Lösung in FS keine Fehlgeburt ist und warum ihre Arbeit nicht umsonst ist.
Leider falle ich eigentlich ständig über haarsträubende Fehleingaben:
Offensichtlich gibt es Preußen und seine Provinz Hessen-Nassau seit Anbeginn der Erde bis ins Jahr 1972!!
Immerhin wird jetzt vermehrt ein (leider meist falsches) Gültigkeitsintervall eingegeben. Muss das wirklich so sein? Die Existenz von Preußen und die Einverleibung von Nordhessen durch Preußen (Zuordnung) muss doch wirklich nur einmal festgestellt werden.
Tatsächlich gibt es schon auf der untersten Verwaltungsebene eine Vielzahl von Unterstellungen
Aber es geht nicht wirklich um diese Daten, auf denen weitere Hierarchieebenen aufsetzen, sondern um das Verfahren, das ich beschrieben habe. Hier sehen wir neun Überobjekte. In der nächsten Ebene kommen viele weitere hinzu. So erlebt der Kreis Witzenhausen zwischen 1851 und 1971 zwei Weltkriege mit Besatzungsmacht und Bildung eines Bundesstaates usw. Jetzt muss der Ortspfleger zig Hierarchien mit Gültigkeitsintervallen eingeben und der Ahnenforscher aus diesem Wust das richtige Intervall heraussuchen. Und dann müssen Ereignisdaten korrigiert werden, wer denke denn da noch an die Überprüfung der "Standardisierten Orte"?
Der Ahnenforscher muss lediglich den richtigen Ort in FS finden. Zusammen mit dem Ereignisdatum erhält er automatisch die richtige Verwaltungshierarchie, wobei in seinem Leben sehr unterschiedliche Ergebnisse herauskommen können (zwischen 1807 und 1813 war er Franzose).
Herzliche Grüße vom Wiesenmichel
0 -
Grüß Gott,
Ist das inzwischen ein toter Briefkasten?
Herzliche Grüße vom Wiesenmichel
0 -
Lieber Wiesenmichel, nein, kein Toter Briefkasten.
Aber überfordern Sie nicht möglicherweise die Datenbank-Kenntnisse der hier Angesprochenen? Auch meine, dabei möcht ich doch nur einen vernünftigen Ort eingeben, oder einen falsch platzierten in vorhandenen Einträgen korrigieren.
Angefangen habe ich hier vor 1,5 Jahren als Laie bei dem Angebot der FS an Ehrenamtliche bei der Standardisierung der Orte mitzuwirken. Und auch die von Ihnen an anderer Stelle (Ortsbezeichnungen) scherzhaft kommentierten Funktion "Ortsnamen verbessern" genutzt. Bis ich aufgab, zu viele gleichförmige Aufgaben ohne Reflektion, was ich da mache. Manches wäre besser mit einem Tool zu bewerkstelligen gewesen. Interessehalber habe ich außer Deutschland und Preußen auch die Insel Guam im Pazifik untersucht. Auch dort gab es Aufgaben. Viele englische Menschen der Zeit um 1800 waren dort verewigt. Und auch viele Schweden, die angeblich ihren Lebensabend im Ort Utan, Guam verbrachten un dort beerdigt waren. Bis ich den Text dazu las:
"Utan stadig uppehall", was bedeutet "ohne ständigen Aufenthalt, wohnsitzlos", von der FS-Künstlichen Intelligenz als Ort interpretiert. Und andere Ungereimtheiten. Guam wird seit einiger Zeit nicht mehr als Änderungsbereich angeboten, wohl zu viel Unsinn drin.
Wenn ich eine Person unterscheidbar von anderen halten will, brauche ich den Namen, den Geburtsort und eine Zeitangabe. Ich brauche nicht die politischen oder kommunalen Verhältnisse dazu. Die Standardisierung sollte dazu dienen, dass Personen aus gleichen Familien zusammengeführt werden können. Leider werden bei vielen persönlichen Einträgen (aus der Indexierung) weder ein Geburtsdatum oder Ort, noch vernünftige Namen mitgeliefert, sondern Abkürzungen, die erstbesten Orte oder solche Ungetüme wie "Heiliges Römisches Reich Deutscher Nation", das hilft nicht viel.
Hiermit will ich vorerst schließen
Grüße von Holger Kraft
0 -
Grüß Gott, Herr Kraft,
nach nunmehr fast 8 Monaten musste ich doch noch einmal alle Texte durchlesen, da ich inzwischen das Thema als "hoffnungslos" zur Seite gelegt habe. Dabei ist das jeweilige Umfeld zu einem Ereignis für einen Genealogen sehr wichtig. "Warum sind Engländer und Schweden nach Guam ausgewandert? War es das schöne Wetter oder eine Hungersnot?" und "Warum sind sie dort 'wohnsitzlos' herumgeirrt?"
Wir müssen in dieser grundlegenden Diskussion drei Ebenen unterscheiden:
- Programmierer
- Eingeber
- Anwender
Alle konkreten Beispiele dienen der Untermauerung, sollten aber nicht als Killer-Argumente benutzt werden.
Anwender
Im Mittelpunkt muss bei jeder Anwendung der Anwender stehen. Dieser lokalisiert in der FS-Ortsliste den vermuteten Ort. Dazu kontrolliert er zum Namen die standardisierten Koordinaten, die er wahrscheinlich nicht direkt treffen wird. Die "KI" könnte bei einer Anwender-Eingabe der Koordinaten einen Trefferkreis um die Standardkoordinaten definieren, die zum gewünschten Ort führt.
Der Anwender gibt weiterhin verschiedene Ereignisdaten (Plural von Datum) ein. Mehr nicht. Die "KI" von FS liefert ihm dann automatisch die politische Umgebung zu jedem Datum und bei Bedarf zum heutigen Datum.
Eingeber
Der Eingeber nimmt sich einen Ort vor und gibt das Existenzintervall des Ortes und das Zugehörigkeitsintervall zur nächst höheren Verwaltungsebene ein.
Natürlich macht er das aufgrund von geschichtlichen Quellen anders herum, also zuerst die höheren Verwaltungsebenen (ebenfalls mit den Intervallen), da diese logischerweise erst vorhanden sein müssen, bevor die untergeordneten Ebenen zugeordnet werden können.
D. h., der Eingeber gibt nur einmal in seinem Leben "Heiliges Römisches Reich Deutscher Nation" usw. ein. Er erhält bei seiner Eingabe eines Verwaltungsobjektes durch die "FS-KI" (übrigens keine KI sondern einfache Logik) aufgrund der Zeitintervallangaben Vorschläge zu den Überobjekten (z. B. zu den Staaten). Ggf. erscheinen Fehlermeldungen, wenn die Zuordnung unlogisch ist.
Programmierer
Der Programmierer versteckt die Datenbank gegenüber den Anwendern/Eingebern durch eine (selbsterklärende) Oberfläche.
Fazit
Auch hier muss man die Vorgehensweise wieder umdrehen. Zuerst ist der Programmierer gefragt, der eine entsprechende Datenhaltung samt Oberfläche erzeugen muss. Dann erst ist der Eingeber am Zuge. Der Anwender muss dann nur noch den richtigen Ort zu jedem Ereignis finden. Die Ereignisdaten gibt er so und so ein.
Wenn dieses Grundgerüst funktioniert, können wir uns um die "Sonderfälle" kümmern, also die "Wohnsitzlosen". Bei genauerer Betrachtung werden aber immer aus den Aufzeichnungen einen Ereignisort finden. Die Frage ist dann natürlich, ob "nach Selbstmord an der Werra angetrieben" ein SO (standardisierter Ort) werden soll.
Leider diskutiere ich hier nur mit den (nach meiner Meinung) "bedauernswerten" Eingebern, die viel Zeit für eine nach meiner Auffassung falschen Arbeitsweise opfern, um die fehlerhaften Eingaben der Anwender nachträglich zu korrigieren. Das muss so nicht sein.
Hiermit will ich vorerst schließen.
Gruß vom Wiesenmichel, der langsam aber sicher zum Wald- oder Holzmichel mutiert.
p. s.: Was ist KI?
"Wenn es der Programmierer selbst nicht weiß, wie das Ergebnis zustande kommt" und natürlich erst recht nicht der Anwender. Tatsächlich ist dies der Fall beim "maschinellen Lernen" mit Hilfe neuronaler Netze. Das macht aber FS möglicherweise bei der Personensuche. Sprachen wie "Prolog" bieten dagegen eine 'Beweismaschine' an, die auf Wunsch erklärt, wie ein Programm ausgehend von der Eingabe zu einem Ergebnis gekommen ist.
0 -
Guten Morgen, Herr Wiesenmichel,
Sie versuchen dankenswerter Weise mir das System der Datenbank gestützten Findung von korrekten Ortsbezeichnungen zu erklären. Und rennen damit bei mir offene Türen ein. Ich dachte auch schon an einen Zeit bezogenen Katalog von Ortsnamen, der pflichtgemäß zu verwenden ist. Die Software dazu kenne ich nicht. Allerdings sollte die Variationsmöglichkeit auf rein geographische Daten beschränkt sein, aber auch nicht zu detailreich. Politische Veränderungen haben mit dem Ereignis von Geburt, Heirat und Tod nur sekundär zu tun. Ebenso Kommunale Veränderungen wie z.B. Eingemeindung oder Umbenennung (Chemnitz / Karl-Marx-Stadt). Eindeutigkeit, Kontinuität und bitte so einfach, wie möglich. Es ist nicht nötig die einzelnen Pfarrhäuser im Katalog zu halten. Oder längst vergangene Straßennamen mit Hausnummer. Wem das wichtig ist kann es als einzelnen Kommentar zugeben.
Ich denke an die Handhabung durch Indexierer oder "bedauernswerte" Eingebende wie mich.
Zu Guam: Der Ablauf geht wohl so: Aus den erstellten Lebensdokumenten eines Engländers/Schweden entsteht ein Personen-Eintrag. Geburt, Heirat, mit Zeitpunkten, alles schön in England oder auch in Schweden. Dann der Eintrag "Aufenthaltsort" oder "Burial". In England gibt es Ortsbezeichnungen, die denen in Guam ähneln, schon sind diese vorrangig eingetragen und die Person ist nach 20.000 km Seefahrt unfreiwillig auf der Insel gelandet. Und ich spreche hier von hunderten solcher Fälle.
In Schweden wird Wohnsitzlosen die (Schwedisch geschriebene) "Utan stadig uppehall" Meldung zugeteilt. Es ist nichts im Orte-Katalog für solche Fälle vorgesehen. Ergebnis siehe oben.
Bei aller Hoffnung das Problem der falschen Eingaben durch Software lösen zu können, bleibt nur der Appell an den gesunden Menschenverstand. Dem ist mit vernünftigen, leicht zu handhabenden Eingabehilfen beizustehen. Sie zu benutzen muss eine Erleichterung der schweren Aufgaben sein, die Anwender sollten sie gerne benutzen.
Grüße von Holger Kraft
0 -
Grüß Gott, Herr Kraft,
warum einfach, wenn es auch kompliziert geht?
Ich halte meine Vorschläge für narrensicher, zukunftsorientiert, (programmtechnisch) minimalistisch und stabil. In der jetzigen Form wird es immer und immer notwendig sein, die "ohne den gesunden Menschenverstand" erfolgten Eingaben zu korrigieren (wie auch die nicht genormten Datumsangaben). Das ist - egal wie hart es klingt - "ewige Fummelei". Diese verlorene Zeit kann man für die Pflege weiterer Orte einsetzen. Soll ich wirklich in den Stammbäumen fremder Personen ohne die entsprechenden Kenntnisse eingreifen. Bisher sind auf jeden Fall alle meine Versuche in dieser Richtung gescheitert (es gibt noch unklarere Beispiele). Aufruf: https://www.familysearch.org/tree/improve-place-names/
Immerhin lernt man die Welt (hier wahrscheinlich Irland) und in den weiteren Beispielen besonders die Bundesstaaten der USA kennen.
Was kann denn noch einfacher sein, wenn ein Anwender nur den richtigen Ort (was oft genug schon schwierig ist) und den richtigen Zeitpunkt eines Ereignisses eingeben muss, um automatisch das geschichtliche Umfeld zu erfahren? Dazu muss er nicht selbst die Geschichtsbücher wälzen. Die Community hat mit ihrer Schwarmintelligenz (<> KI) alles im Laufe der Zeit vorbereitet.
Die Granularität der Orte bis auf Hausebene herunter zu brechen, ist eigentlich ein ganz anderes Thema. Hier interessiert den Forscher die Geschichte seines Geburtshauses oder das seiner Vorfahren. Wer hat nebenan gewohnt? Wer hat im Ort gewohnt? Welches Schicksal hat das Haus erlebt? Wer wohnt heute dort?
"Politische Veränderungen haben mit dem Ereignis von Geburt, Heirat und Tod nur sekundär zu tun."
Auch hier gehen unsere Meinungen weit auseinander. So habe ich kürzlich ein Fotoalbum ausgewertet, bei dem ein Mann einmal in der tschechischen Uniform seinen Grundwehrdienst abgeleistet hat, um kurze Zeit später in einer deutschen Uniform zu sehen ist (Anschluss des Sudetenlandes). Wie viele Nationalitäten hat er im Laufe seines Lebens gehabt?
FS propagiert selbst bei der Erfassung der Orte, auf den historischen Kontext zu achten. Warum sind Personen ausgewandert? Verarmung, Hungersnot, Straflager, Walz als Handwerker usw. usw.?
Ohne ein Gültigkeitsintervall ist jede historische Orts-Umfeld-Angabe sinnlos, aber diese wird kein Endanwender so einfach liefern können.
Leider ist unsere Diskussion nicht sehr zielgerichtet und ehrlich gesagt "hoffnungslos".
Herzliche Grüße vom Wiesenmichel
0
