Fehlerhafte Datumsprüfung
Grüß Gott,
natürlich ist es ein Benutzerfehler, aber dieser Fehler sollte vom Programm erkannt und gemeldet werden, damit er nicht übersehen wird.
Eine Taufe kann nicht vor der Geburt erfolgen. Das sollte das Programm erkennen und melden.
Weitere Fragen:
- Über die "Standardisierten Orte" habe ich bereits mehrfach meine Meinung geäußert. "Moderne" Verwaltungshierarchie links, "historische Verwaltungshierarchie" rechts? "Bohemia" gibt es das als offiziellen Begriff?
- "Kleinkindtaufe" (im Gegensatz zur Erwachsenentaufe?) ohne Angabe der Religion ist für den Ahnenforscher hinderlich, da er mehrere Kirchenbücher durchsuchen muss. Warum fehlt in FS grundsätzlich die Angabe der Religion?
Herzliche Grüße Hans-Jürgen (Scheibl)
p.s.: Das lateinische B-o-h e m i a wird automatisch in diesem Text in "Böhmen" umgewandelt. Mal sehen, mit was ich den Übersetzer überlisten kann. Gesperrt geht nicht, mit - geht nicht, ich schreibe einmal rückwärts aimehoB.
Jetzt wird es mühsam: "überlisten" wird zu "überhören", da wird wohl 'listen' als englisches Wort interpretiert und zu "hören" umgewandelt. Ich experimentiere weiter: B.ohemia,
Jetzt verschwindet auch noch das Bild, also noch einmal eingeben?
Antworten
-
I agree that a data problem for baptism before birth (or burial before death!) would be good, and I'm surprised that these don't already exist.
(I tested it on the beta site: the program happily accepts baptism a year before birth, and burial six months before death. The only research help on the profile is the complaint that there are no sources attached.)
Regarding place labeling, the genealogical standard is to use a placename appropriate to the time of the event, so Bohemia/Böhmen for an 18th century birth, not Czechia/Tschechien/Česko. However, many (most?) of the indexes out there -- not just on FamilySearch -- use modern placenames and jurisdictions, as did much of the IGI and Pedigree Resource File, and all of those place labels frequently get/got transferred into Family Tree without change. It's up to you whether to change these when you encounter them; I generally only do so on direct relatives. On side branches, I figure that as long as the computer sticks the pin in the right spot on the map, it's not really my problem how exactly that pin is labeled.
Family Tree does have a place to enter religious affiliation under Other Information. It's rather illogically labeled as an event, I guess because it can have a date attached.
However, I'm not sure I understand what relationship this has to adult versus child baptism: adult baptism as a separate sacrament simply didn't exist in most of Europe during most of the genealogical timeframe. The whole reason christening is there in the Vitals box is that genealogists have always used that as a proxy for birth, because historically, it was what was recorded, and it occurred close enough to birth as to make a good substitute. (Similarly for burial versus death.) This near-equivalence is independent of denomination: if you assume that all baptisms recorded in Europe before the 20th century were for an infant or young child, you'll be correct well over 99% of the time. (The fact that FS cannot be convinced of this fact is a separate question entirely.)
0 -
Regarding your postscript: I think you must be using Chrome's automatic translator, or some other browser plug-in for translation, because the Community does not offer such a tool, and your post is entirely in German.
0 -
Grüß Gott, Julia,
vielen Dank für die schnelle Antwort. Ich sende die Antwort jetzt wieder über den Firefox, der hoffentlich keine "Übersetzungen" durchführt.
Für eine weiterführende Diskussion empfehle ich einen Blick auf meine anderen Beiträge
https://community.familysearch.org/de/discussion/comment/516379
https://community.familysearch.org/de/discussion/comment/516367
https://community.familysearch.org/de/discussion/comment/516350
Mit herzlichen Grüßen Hans-Jürgen (Scheibl)
p.s.: Tatsächlich habe ich gerade ein neues Problem. Durch den Wechsel des Browsers wurde der Beitrag "Fehlerhafte Datumsprüfung" auf der englischen Plattform einsortiert. Sowohl auf der englischen als auch auf der deutschen Seite werden insgesamt inzwischen 24 Diskussionen geführt
Wenn ich nun diese Diskussionen öffne, dann erscheinen aber nur meine alten Beiträge aus den Urzeiten der Community (2021 und früher).
Starte (oder wechsle) ich nun mit Deutsch, dann erscheinen die vermissten Beiträge
FS zählt die Beiträge gemeinsam, führt sie aber nicht zusammen. Das ist für mich ein echtes Problem.
0 -
Grüß Gott, Julia,
nach dem letzten, mehr technischen Kommentar noch eine eigene Anmerkung/Beobachtungen zu den Ereignissen Geburt und Tod.
In den damaligen Religionen (Böhmen als Kronland der habsburgischen Monarchie mit der Einheitsreligion römisch-katholisch) musste man umgehend getauft sein, um auf einem Friedhof (geweihte Erde) begraben zu werden. Interessanterweise hatten beide christlichen Kirchen dazu einheitliche Friedhöfe. Lediglich die Juden hatten eigene Friedhöfe. Daher ist es für mich immer wieder verwunderlich zu sehen, wie viele verschiedene Kirchen und separate Friedhöfe bei amerikanischen Städten (oder auf dem flachen Land) zu finden sind.
Somit wurden die Kinder am Geburtstag, spätestens am Folgetag getauft. Da der Priester im Notfall nicht immer sofort erreichbar war, durften die Hebammen auch eine 'Nottaufe' vornehmen.
Im Todesfall finden wir auch heute noch in den islamischen Bereichen die Beerdigung innerhalb von zwei Tagen. Dies ist und war aus hygienischen Gründen vor der Erfindung der Kühlung notwendig. Dazu kam noch der Umstand, dass alle Verwandten im nahen Umfeld lebten, so dass das Begräbnis innerhalb dieser kurzen Zeit zu organisieren war.
Zurück zum eigentlichen Thema:
Neben den eher kleinen Programmfehlern (Überprüfung der Ereignisreihenfolge) möchte ich auf meine Ausführungen zu den "Standardisierten Orten" verweisen. Ich halte den FS-Ansatz für eine Fehlentwicklung. Man kann doch nicht dem normelen Anwender ohne das entsprechende geschichtliche Hintergrundwissen die Einordnung eines Lebensereignisses überlassen. So hat beispielsweise mein Urgroßvater vier verschiedene Nationalitäten in seinem Leben gehabt. Das muss automatisch geschehen:
Ort (mit Koordinaten) + Ereignisdatum => historische Verwaltungshierarchie
Der Eingeber sucht in FS den richtigen Ereignisort. Die Ereignisdaten ergeben sich aus der Lebenslinie. Die Verwaltungshierarchie wird dynamisch berechnet.
Probleme ergeben sich aus den unscharfen Orten und deren Einordnung: "Geboren in Böhmen". Königreich Böhmen, Kronland Böhmen?? Ein Ort ist physisch halbwegs bestimmbar. Daraus ergibt sich die Folgestufe: "Herrschaft" oder "Hauptmannschaft" oder "Kreis" oder ... . "Böhmen" ist dagegen ein abstrakter Sammelbegriff.
Herzliche Grüße Hans-Jürgen (Scheibl)
0 -
The incomplete listing of your discussions is just another manifestation of the "My Discussions" ("Meine Themen") list's quirky, segregationalist setup: it only ever shows threads from the same specific subsection you're currently in. It doesn't show anything posted to a Group, and it only shows things with the same language tag as you're currently on. I don't remember when the different sections were added for the major languages, but judging by the dates you're seeing, it must've been around 2021. Everything posted before that date is classified as "default" (which is equivalent to "English"), while everything after that is classified according to where you were (...familysearch.org/de/... or ...familysearch.org/en/...) when you posted.
You can get a complete listing of the threads you've started, regardless of which subsection they're in, by going to your profile page and clicking "Discussions" ("Diskussionen") there. (To get to your profile page, either find a post you've made, click your name, and choose "View Profile", or click your profile image at the top right of any Community page and then click your name.)
---
I get the heebie-jeebies from the mere mention of "automatic" in conjunction with "FamilySearch places". You can perhaps see why in this thread: https://community.familysearch.org/en/discussion/137684/how-do-i-point-out-an-error-in-a-result-of-a-search-for-genealogies#latest.
The choice of place jurisdiction must be left to individual users. Yes, they'll sometimes get it wrong, even if the database is correct (which it mostly isn't, currently), but as long as they get the correct point on the map, their error will not have much effect at all. An incorrect jurisdiction on a birthplace (or christening, if the birthplace is empty) will result in a different color on a fan chart colored by birthplace, but that's just about the only situation where it makes any difference whatsoever. It doesn't matter whether a residence is standardized as "Felsőlövő, Vas, Hungary" or "Oberschützen, Oberwart, Burgenland, Austria"; the timeline will stick the pin in the same place regardless. (Well, OK, technically in this case it'll put the pin about 250 feet further north if you pick the Hungarian label.)
1 -
Guten Morgen, Julia,
da ich gerade am gesamten Datenmodell für die "Standardisierten Orte" rüttle, möchte ich noch einmal meinen Vorschlag ausführlich erläutern. Es geht mir nicht darum, einzelne Eingabefehler von Benutzern darzustellen. Auch ist die Festlegung von "zentralen Koordinaten" für einen Ort schwammig, wie die 250 Füße Differenz zwischen den österreichischen und der ungarischen Koordinaten aufzeigen. Wieso eigentlich? Werden nicht Alias-Namen für ein und denselben Ort verwendet? Werden die verschiedenen Schreibweisen der Orte wirklich getrennt gespeichert?
Jetzt wird es technisch. Viele Mitleser können die Schritte mit einer einfachen Access-Datenbank nachvollziehen. Zuerst also die Aufgabenstellung für den Programmierer:
Gehen wir von einem einfachen Modell mit zwei Tabellen aus und realisieren unseren Ansatz:
- Ein Verwaltungsobjekt kann mehreren anderen Verwaltungsobjekten untergeordnet sein.
- Ein Verwaltungsobjekt kann mehreren anderen Verwaltungsobjekten übergeordnet sein.
In der Tabelle 'tblOrtVerwaltung' sind möglichst viele Daten zu einem Ort zusammengestellt. Der Verweis 'ov_og_aNr' zeigt auf eine nicht dargestellte Tabelle aller Orte aus der (schon vorhandenen) Ahnen-Datenbank. So wird die Verwaltungshierarchie einfach an die bestehende Ahnen-Datenbank angedockt.
Ein Verwaltungsobjekt hat ein Existenzintervall 'ov_zVon' und 'ov_zBis".
Nun müssen wir die Verwaltungsobjekte mit einem m:m-Beziehungstyp 'tblOrtVerwaltungVerwaltung' in eine Hierarchie bringen. Die Zugehörigkeit wird durch Unter- bzw. Überordnung und dem Zeitraum der Zuordnung 'ovv_zVon' bis 'ovv_zBis' erfasst. Die Nachschlagtabelle 'tblOrtVerwaltungTyp' enthält Begriffe wie 'Königreich, Staat, Kreis, Gemeinde' usw.
Nun machen wir ein schönes Formular zum Eingeben daraus. Hier beginnt die Aufgabenstellung aller freiwilligen Helfer für die "Standardisierten Orte", die pro Verwaltungsobjekt nur einmal durchgeführt werden muss.
Wenn wir keinen Fehler eingebaut haben, so können wir durch alleinige Vorgabe des Ortes und des Datums die jeweilige Verwaltungshierarchie ablesen. Das macht der Benutzer durch Angabe des Lebensereignisses:
und 100 Jahre später
Durch Minimierung der Existenzintervalle ergibt sich dann ein Gültigkeitsintervall für genau diese Hierarchie von 01.01.1871 bis 08.11.1918.
Aber ich finde noch eine Lücke ab dem Ende der Gültigkeit
Jetzt brauche ich die wahren Historiker, die mir helfen müssen. Was war am 09.11.1918?
Nun baut der Programmierer das wieder in die Benutzeroberfläche ein. Der Benutzer kann jederzeit die Verwaltungshierarchien für die verschiedenen Lebensereignisse (hier Geburt) abrufen.
Herzliche Grüße Hans-Jürgen (Scheibl)
p. s.: Es sind sicher noch Fehler im Programm bzw. in den Daten. So habe ich erst kürzlich die Einteilung des HRR in mehrere Reichskreise bei meinen Testdaten ergänzt. Dazu musste ich aber nicht mehrere hundert Orte (!!) korrigieren. Vielmehr reicht es in der vorgeschlagenen Technik den Reichskreis zwischen 'Vorderösterreich' und 'HRR' einzuschieben. Die Hierarchie wird sofort automatisch für alle Orte in der Grafschaft Hohenberg richtig berechnet.
0 -
The reason the map pin locations aren't identical for the different jurisdictions is that they came from different sources. The Places database contains data imported from all sorts of different lists and maps. I believe the Burgenland data came from an Austrian government source, while the historical Vas county data is based primarily on Dvorzsák's gazetteer.
A few years ago, the two sets of placenames etc. were not connected at all; someone has done a lot of work to clean up the Burgenland data. The same has not yet happened in most of Slovakia. For example, Nagyrét, Zólyom, Hungary is a stand-alone entry in the database, unconnected by anything other than the map pin location and an alternate name to Veľká Lúka, Zvolen, Slovakia.
Historical Hungary had 63 counties. The remnant country has less than a third of that: 19 counties. That's a very, very large number of places that have at least two different name-and-jurisdictions that need to be linked up in the database -- and that's just one former country, which even at its largest was smaller than the state of California.
A process like your proposal depends on the database being fully complete and accurate for every single place. The Places database represents over a decade of work already and is nowhere near ready for any such characterization.
Another aspect that I'm not sure you've considered is how users would specify a place. I'm not sure there exists a placename that there has only ever been one of on the entire globe, so just typing in the village's name (in some language or other, hopefully not too badly misspelled) is almost never going to be enough: the user will need to choose a jurisdiction. (England in particular is notorious for having multiple places with the same name, sometimes even in the same county.) If the user is choosing the jurisdiction anyway, then I see no point in investing all that effort in having the computer choose one, too.
0 -
Grüß Gott, Julia,
leider geht die Diskussion in die falsche Richtung. Ich lese nur noch Ausreden. Sie lenken vom eigentlichen Thema ab. FS versucht doch gerade die "Standardisierten Orte" zu reorganisieren. Neuerdings werden diese Orte mit einem Existenzintervall versehen (beispielsweise 1993 - heute). Immer noch soll also der Eingeber nicht nur den richtigen Ort sondern auch das richtige Zeitintervall suchen und finden. Wenn er schon den Ort nicht findet, dann wird er erst recht nicht das richtige Zeitintervall für sein Ereignis finden, also nimmt er irgendeines, meist das aktuelle und nicht das historisch richtige.
Es gehört nach meiner Meinung nicht zu den Aufgaben des Ahnenforschers dieses Intervall zu bestimmen. Vielmehr muss er
- den (einigermaßen) richtigen Ort finden
- das Ereignisdatum bestimmen
mehr nicht. Den Rest muss FS (zumindest in der Zukunft) liefern.
Besonders in Böhmen gibt es viele gleichnamige Orte, die näher bestimmt werden müssen, wenn man seine Vorfahren richtig einordnen möchte. Diese Arbeit kann man dem Forscher nicht abnehmen. Aber den Rest schon. Jeder ausgewanderte Böhme hat in den USA seinen Ort neu angelegt. Dort hängt man dann einfach das Staatenkürzel an.
In Böhmen gab es geteilte Orte, in denen ein Teil der Häuser einem Grundherren (einer Herrschaft) gehörten, während ein anderer Teil des Ortes einer zweiten Herrschaft gehörten. Typisch dafür sind die Hinweise in den Kirchenbüchern zur Herrschaft "Plaß, Cerni, Manetin, Miltschowes, ..." usw. Ja, die einzelnen Personen waren Leibeigene der Herrschaften. Die Rechte am Grund, den Untertanen usw. wurden verkauft, gingen wegen Kriegen usw. an andere Herrschaften über, wurden verpfändet, neu als Lehen vergeben, enteignet usw. usw. Wichtig ist nur, diese Herrschaften waren hierarchisch gegliedert. Interessant zu lesen:
https://de.wikipedia.org/wiki/Robot_(Frondienst_im_K%C3%B6nigreich_B%C3%B6hmen)
Betrachtet man nun einen Ort (genauer ein Haus, oder noch genauer eine Familie), so wechseln über die Jahrhunderte, Jahrzehnte ja über die Jahre deren rechtliche Stellung. Nach der jetzigen Technik der "Standardisierten Orte" müssen für jeden Ort eine Vielzahl einzelner Verwaltungshierarchien angelegt werden. Bei jeder Reform, jedem Verkauf, ja jeder Verleihung (Pfand) usw. muss ein neuer Eintrag erzeugt werden.
Das ist keine Lösung. Nein, die bereits in der Realität vorhandene Hierarchie muss in der Datenbank abgebildet werde.
In einem ersten Schritt könnten Sie Ihr Problem der "250 Füße" durch eine Festlegung der Wohnplätze und dem dazugehörigen (automatisch generierbaren) Voronoi-Diagramm über die gesamte Erde (oder für den Anfang auch nur Ungarn) angehen. Für alle Ortsangaben außerhalb der so festgelegten Wohnplätze (aus fremden Quellen, aus der FS Vergangenheit) wird das jeweilige Voronoi-Polygon bestimmt und die Ortsangabe auf den vorgegebenen Wohnplatz (Voronoi-Zentrum) korrigiert (zusammen gezogen). Damit haben wir einen stabilen Stamm an Orten. (Die Suche nach den richtigen Namen, den Schreibweisen usw. ist ein weiteres Nebenproblem, das erst mit einem stabilen Ortsstamm gelöst werden kann.) Fertige Programmvorschläge finden Sie in
https://de.wikipedia.org/wiki/Voronoi-Diagramm
Fehlt ein Ort, so wird dieser ergänzt und das Voronoi-Diagramm verfeinert. In unserem Diagramm gibt es keine Lücken, jedes Koordinatenpaar gehört zu einem zentralen Wohnplatz (Knoten). Da fällt mir noch die alte Gebrauchsanweisung für die Standardisierten Orte ein, die so ungefähr lautet: "Suchen Sie den nächstgelegenen größeren Ort". Eigentlich darf kein Benutzer so mir nichts dir nichts einen neuen Ort anlegen. Das ist eine zentrale Aufgabe.
Ich versuche einmal - wenn ich etwas Zeit finde - diese Verwaltungshistorie für meinen Beispielort "Dautmergen" zusammenzustellen. Dann erwarte ich mehrere Dutzend Zeitintervalle für Dautmergen von der ersten Erwähnung bis zur heutigen Zeit. Leider ist mein erster Prototyp noch etwas bockig und liefert Fehlermeldungen.
Derzeit habe ich noch nicht das Problem gelöst, ob der Übergang einer höheren Hierarchieebene (z. B. Königreich -> Republik) auch alle darunter liegenden Ebenen automatisch beendet und/oder neu startet. Ist also ein Kreis im Königreich auch ein solcher in der Republik, selbst wenn er seine Form behält. Bei den Wohnplätzen ist das klar, das sind Immobilien. Sie können zwar untergehen oder neu entstehen, bewegen sich aber nicht. Alle andern Objekte sind abstrakte Erfindungen unserer Bürokratie, die sich verändern.
Algorithmisch interessant ist das fast gleiche Verfahren verglichen mit dem Fortune-Algorithmus für das Generieren der Voronoi-Diagramme, um die Verwaltungshierarchie über einen Zeitraum zu bestimmen. Hierzu zeichnen wir die Existenzintervalle unserer Verwaltungsobjekte als Balken in ein waagerechtes Balkendiagramm (genauer Gantt-Diagramm) über der Zeitachse ein. Dann lassen wir von links eine Sweep-Line (Cursor) nach rechts wandern. Immer wenn wir auf einen Anfangs oder Endpunkt eines Existenzintervalls treffen, ändert sich die Verwaltungshierarchie unseres Wohnplatzes. Diese Verwaltungshierarchie wird zu einem weiteren Auswahlelement in der Liste der "Standardisierten Orte". Theoretisch sollte es dabei keine Lücken geben.
Herzliche Grüße Hans-Jürgen (Scheibl)
p. s. : Ich habe noch die Frage nach der Eindeutigkeit von Orten nicht ausreichend beantwortet:
- Name und alle Aliasnamen sind keine Invarianten.
- Vom Benutzer frei gewählte Koordinaten sind zu ungenau (schon die letzte Ziffer macht sie unterschiedliche)
Ein Ort wird von FS als Voronoi-Zentrum eindeutig festgelegt und vom Benutzer aus der vorgegebenen Liste ausgewählt. Dabei werden allgemeine Orte wie "Böhmen", "Tschechien", "Region Pilsen", usw. als Platzhalter vorgesehen, wobei diese ebenfalls ein Existenzintervall besitzen sollten.
0 -
A Voronoi diagram of the entire globe: that'd be like a cadastral map in a mathematical form, right?
(Example of a cadastral map: https://maps.arcanum.com/hu/map/cadastral/?layers=3%2C4&bbox=1790466.4555046216%2C5993857.0250880895%2C1819493.4169959172%2C6004042.25910709)
---
Timespans have been a part of the Places database from the very beginning, but they're not intended to ever be granular (accurate) down to the single year. I believe the rule of thumb is five years: anything that existed for less than that should simply be absorbed into whatever existed before or after.
I don't have any Bohemian ancestors, so I'm not familiar with its administrative structures: how relevant is the landowner's identity to the task of identifying a location? Can you localize an event without that information?
It's one of the beauties of FS's dual-entry system that you can identify a place down to the building, if you want to, but you don't need to. For example, my grandfather was born on an outlying farm kinda in the middle of nowhere, but it belonged administratively to the town of Dunaszerdahely, so that's what I standardized it to. This did involve a bit of research (i.e., I had to look it up in a gazetteer), but that's just as integral a part of genealogy as finding birth and death records.
Another beauty of FS's system is that it allows this flexibility and ability to capture exact details regardless of the current state of the database. It doesn't matter whether the database entity labeled "Dunaszerdahely" is linked to the one labeled "Dunajska Streda", and it makes no difference whether any of the relevant jurisdictions have time periods entered. Heck, even when Sopron ("the most faithful city", because it voted to stay Hungarian) was inexplicably in the database with its German name, I could work around the problem and still display it as Sopron everywhere that it mattered. (That one has since been fixed, but I've discovered that Pozsony now has the same problem. I asked in my suggested improvement whether someone on the Places team enjoys concocting trilingual labels, and suggested the neutral [Latin] Posonium for that purpose.)
0 -
Grüß Gott, Julia,
wie schon gesagt, gleitet die Diskussion langsam in eine Form über, in der wir uns gegenseitig gescheite Weisheiten um die Ohren schlagen und diese mit Einzelbeispielen unterfüttern.
Die Parkettierungsalgorithmen - hier das Voronoi-Diagramm - sollen nur dazu dienen, das FS das "250-Fuß"-Problem lösen kann. Wichtig ist, dass am Ende in FS feste Wohnplätze definiert werden, aus denen der Normalbenutzer den passenden herausfindet. Wie er diesen Platz findet, ist eine andere algorithmische Aufgabe, die sich mit der Ähnlichkeitssuche in den Sprachen beschäftigt, als ältestes Beispiel sei der Soundex-Algorithmus erwähnt. Schon bei diesem erkennt man, dass er sprachabhängig ist, also phonetisch angepasst werden muss. Aber das ist nicht unser Thema.
Ahnenforschung arbeitet mit unscharfen Informationen. Bei der Datumseingabe sind Zusätze wie vor, nach, etwa, ... (in FS dann auch noch in der jeweiligen Landessprache) erlaubt, statt eine sprachneutrale Symbolik wie <, ?, ~, ... zu verwenden. Aber auch das ist nicht unser Thema.
Ja, ich arbeite grundsätzlich mit "vollständigen" Datumsangaben: Die Jahresmitte 01.07.2023? (mit ?) ist für mich genauso richtig oder falsch wie 2023 allein. Ein solches (erweitertes) Datum hat aber den Vorteil, dass es fertige, vielfach geprüfte Algorithmen zur Datumsberechnung gibt. Eine ähnliche Technik finden Sie bei den Datenbanken. Da eine Ganzzahl keine Möglichkeit bietet, das "Nichts = NULL" darzustellen, wird dieser Datentyp beispielsweise in C++ inzwischen zu eine "Datenbank-Ganzzahl" erweitert. Aber das ist nicht unser (oder sagen wir lieber MEIN) Thema.
Mein Thema: Wie gelingt es FS, den normalen Ahnenforscher von der Geschichtsforschung zu entlasten. Genauer ihm sogar dabei wertvolle weitere Informationen bereit zu stellen?
Treffe ich auf einen mir bisher unbekannten Vorfahren (möglichst nur der Vorname der Ehefrau), dann beginnt mein Arbeitsplan.
Wo kann ich suchen? FS liefert erst einmal keine Informationen zur Religion, aber mein Grundwissen sagt mir, dass es damals pro Landesfürst eine Einheitsreligion gab. Also ist das Kirchenbuch einigermaßen festgelegt.
Wo ist der Ort, genauer der kirchenbuchführende Ort zu den einsamen Geöften/Weilern/Einsiedeleien? Kann ich irgendeinen Namen entziffern? Welche Orte liegen in der Umgebung? Wie weit konnten Ehepaare auseinander gelebt haben?
Wann könnte der unbekannte Vorfahr geboren sein? Mit welchem Generationenabstand rechne ich? Hat sich der reiche Bauer eine junge Frau "leisten" können?
Fazit: Ich suche einen Ort und ein Datum. Das muss erst einmal reichen. FS sollte mir dazu die historische Umgebung liefern: Verwaltungshierarchie, Gerichtshierarchie, Kirchenhierarchie, ... ggf. weitere weltpolitische Ereignisse um dieses Datum herum. Diese Informationen sind weitgehend stabil und müssen nur einmal erfasst werden.
Wie gelangt der Maurer (Handwerker) 'Karl Scheibl' um 1800 herum nach rund 600 km ohne große Probleme (Steuerschulden, Wehrdienst) aus dem schwäbischen Dautmergen in das böhmische Flöhau (siehe Screenshot in meinem letzter Kommentar)?
Richtig: Beide Orte waren zur damaligen Zeit "österreichisch", was mir FS zeigen könnte. Als Handwerker geht man zur damaligen Zeit "auf die Walz" (und bleibt leicht bei einem hübschen Mädchen in der Ferne hängen). Wenn dann noch während dieser Zeit die Heimat durch Napoleon zum "Königreich Württemberg" wird und der neue König alle Bürger, die sich nicht zurückmelden, enteignet, dann bleibt man einfach in Böhmen. So kann man seine Familiengeschichte weiter fortspinnen.
Das ist mein Thema:
Es muss für den FS-Eingeber genügen, den Ort und den Zeitpunkt hinreichend genau zu bestimmen, um den historischen Kontext von FS zurück zu erhalten.
Das ist nicht mein Thema:
Ich halte es für eine abwegige Idee, wenn ich auf der Anmeldeseite aufgefordert werde:
Immerhin kann jetzt ein Filter gesetzt werden:
Aber wirkt das wirklich? Soll ich jetzt in einem fremden Stammbaum hineinfummeln?
Vielleicht liegt es ja an "Böhmen", das in den weiteren Beispielen nach England bzw. in die Niederlande verlegt wird. Ich war einfach zu schnell, oder mein Rechner war zu langsam. Im zweiten Versuch erhalte ich wenigstens eine Liste der erlaubten Länder. (Immerhin schön übersichtlich mit großen Abständen) Aber ich soll nicht ständig meckern:
Ich finde Kiribati usw. aber wo ist Tschechien (wie schreibt man das auf Englisch?)? Böhmen fehlt ganz. Aber das seit 1992 nicht mehr existierende 'Czechoslovakia' ist in der Liste zu finden:
Getreu dem "Jonny Walker" Spruch mache ich weiter mit "KEEP GOING". Aber nach gefühlt 100 Beispielen erscheinen immer nur slowakische Orte.
Ich gebe es auf, wer hat sich so etwas ausgedacht?
Hans-Jürgen (Scheibl)
0 -
That "volunteer opportunity" is a tiny little part of FamilySearch. (Is it still labeled "new"? It's been around for years.) Given FS's rather abysmal track record with automated processes, I am more than happy to have this one require human input, but I think it needs better instructions: many (most?) people don't fully understand what's going on with it.
Due to circumstances or processes that I'm not completely clear on, there are many place conclusions in the Family Tree for which the computer does not currently have a places database association, because the entered text does not match any of the labels in it closely enough, or because there are multiple database entries that it could match.
The volunteer is tasked with simply helping the computer choose the most appropriate database entry to go with the entered text.
People are generally only familiar with the geography of small parts of the world, and they would naturally rather not work in unfamiliar areas, so the project offers to filter by (mostly-modern) country. However, this filter skirts around a rather major chicken-and-egg problem: if the whole problem is that the computer doesn't know the location, how is it supposed to filter by that location? Hence the rather broad categorizations available: that's as far as the process makes the computer guess.
As I said, whatever the faults of the human process, I vastly prefer it to an automated alternative.
0 -
Grüß Gott, Julia,
simple question:
Welche Funktion haben Sie in FS?
- Zugriff auf eine Beta-Version?
- Kenntnis der internen Datenstrukturen (uralte Speicherung der Zeitintervalle)
- Glücklich/unglücklich über einige (fehlerhafte) Funktionen
Ich sehe FS nur als black-box-Tester und erkenne mögliche Fehler und rege Verbesserungen an. Mehr kann ich nicht. Vorsichtshalber beweise ich noch, dass meine Vorschläge funktionieren.
Weiterhin versuche ich alle meine Anmerkungen zu dokumentieren. FS verändert sich ständig (siehe PDF-Fächerdiagramme gegen dynamische, anklickbare Fächerdiagramme, neuerdings Zeitintervalle bei den Standardisierten Orten).
Abgesehen von den diversen kleinen Fehlern (fehlende Datumsüberprüfung in der Zeitlinie einer Person, die Sie sogar persönlich überrascht haben, fehlende Religionseingabe, ungenügende Darstellung von Namensvarianten, unklare Trennung von Namensbestandteilen (Vorname, Rufname, Geburtsname, mehrere Familiennamen, Aliasnamen, genannt, jeder Benutzer stellt seinen eigenen Mix zusammen), sehe ich zwei schwerwiegende konstruktionelle Probleme in FS.
- Mehrfacheltern mit und auch ohne Adoptionsverweis
- Standardisierte Orte
zu 1: FS erlaubt Mehrfacheltern (Familienbildung) durch implizite und auch explizite Adoption. Wobei diese nicht durch entsprechende Dokumente belegt sein müssen. Vielmehr handelt es sich hier um "religiöse Adoption", beispielsweise durch Siegelung. Großeltern können nicht ihre unehelich geborenen Enkel adoptieren.
zu 2: Dies habe ich ausführlich dargelegt und eine gangbare Lösung vorgeschlagen. Konfuzius sagt: "Jeder lange Weg beginnt mit dem ersten Schritt". Diesen bin ich gegangen.
Der lange Weg sollte nicht schon am Anfang durch Totschlagargumente blockiert werden. Meine Philosophie lautet:
Löse das Ganze und kümmere dich erst dann um die Sonderfälle, nicht umgekehrt. Also erst einen Prototyp erstellen (das ist geschehen) und dann über die Problemfälle wie unscharfe Ortsangaben, unsichere Datumsangaben diskutieren und Lösungen finden.
Mit freundlichen Grüßen Hans-Jürgen (Scheibl)
p. s.: FS hat das Diagramm im letzten Post verschluckt, das passiert also nicht nur mir. 😉
Und die erste 'simple question' beantworten!
0 -
I'm just a fellow user of FS, perhaps of longer duration than most, but with no special access to anything currently. (I'm not LDS, so in some areas, I have less access than others.)
Everyone can use the beta site (beta.familysearch.org); I just suggest doing it in a different browser, to keep the logins straight. It's useful for testing "what would happen if?" questions that you don't want to litter the actual Family Tree with.
I'm perhaps a bit more familiar with the Places tool/database than others, because several years ago I was a volunteer with some editing priviledges. (There were updates/changes made while I was away for a time, and my access had gone away when I got back. I haven't pursued it, because I'm quite busy enough without that task.) That was circa 2016-18 or thereabouts, and the database definitely already had time periods. Determining them was part of the task.
Other bits and pieces:
As I said somewhere above, FS does allow for input of a person's religion.
Likewise, FS allows a nearly-unlimited number of alternate names for a profile, so there's absolutely no need to combine them all in one set of fields. All names are used equally by the searching and hinting algorithms, i.e., it doesn't matter which name is in Vitals and which ones are in Other Information, because they're all treated exactly the same way.
I'm not sure what you mean by "ungenügende Darstellung von Namensvarianten, unklare Trennung von Namensbestandteilen": do you want more name fields or fewer? I vastly prefer FS's flexible two-field setup (in which either one can be left blank at need) to other websites' complicated Anglo-centric structures (yes, I'm looking at you, WikiTree). I just wish FS's fields were labeled non-positionally.
(I sometimes feel like I'm standing on my head, looking at that name-input screen while working on a family with an unmarked patronymic surname.)
And regarding the Community "eating" images: nowadays, you just need to be a little bit patient, and most of them will show up. (Last year, we were advising each other to only try one image per post, because any more than that, they'd all get permanently eaten, but that fault -- knock on wood! -- seems to have been fixed.)
0 -
Grüß Gott, Julia,
nur eine schnelle Antwort auf "unklare Trennung von Namensbestandteilen".
Da FS nur zwei Felder für die Namenseingabe besitzt und diese auch nicht in der externen Darstellung trennt, kann ich beliebig viele Namen in 'Last Names' und 'First Names' packen, ohne dies im Ergebnis zu erkennen. In Bayern ist es beispielsweise üblich, den Namen in umgekehrter Reihenfolge zu nennen, aber dann ein , einzufügen, also
Scheibl, Hans-Jürgen
Hans-Jürgen Scheibl
Da FS keinerlei Vorschriften macht, packen nun einige Benutzer alle Namen hintereinander in die Felder, also sämtliche alte Ehenamen. In den Frühzeiten der Namensbildung (1500-1600) kommen dann noch die Hofnamen (Aliasnamen) und die Namen der Ehefrauen hinzu, die sich dann teilweise auf die Kinder vererben usw., aber nicht immer. Daher entstehen lustige Mischungen bei den Kindsnamen. Gut, man kann die Korrektur aufrufen, um zumindest die grobe Aufteilung der Namen anzuschauen.
--------------
Noch ein Wort zur Anwerbung der Freiwilligen zur Namenskorrektur.
Was würde ich erwarten?
- Die Länderliste wird auf den neuesten Stand gebracht, wenigsten Czesko sollte vorhanden sein
- Der Designer schiebt die Länderliste ein wenig zusammen, die Suche geht einfach schneller.
- Das Filter wird überprüft.
Ich verändere fast nie die Eingaben eines anderen Forschers. Und wenn, dann nur mit Angabe einer Primärquelle. Ich habe schon Ortsangaben gesehen, die ,,, (also mehrere Kommata) lauteten. Es gibt kein einheitliche Verwaltungshierarchie in allen Ländern.
Bei einigen Gründen stehen mir die Haare zu Berge. 'GEDCOM' ist doch keine Quelle, 'MyHeritage' usw. sind abgeschriebene Daten usw.
Es war nett, mit Ihnen zu fachsimpeln, Ihr Hans-Jürgen (Scheibl)
p. s.: Keine Stunde später stolpere ich über den nächsten Fall:
13 Kinder mit zwei verschiedenen Frauen und eine Anmerkung, dass es noch zu wenige Kinder sind:
https://www.familysearch.org/tree/person/details/GMZ9-L4L
Was wird diese Prüfung bei neueren Paaren sagen, die nicht spätesten alle drei Jahre ein Kind bekommen.
0 -
It's funny: you're at least the second person I know of who somehow manages to work in FamilySearch's collaborative tree without actually editing other people's contributions. I would not be able to manage that. (Names with -ovÁ would just bug me on too many levels, for example.)
The good news for you is that the placename volunteer opportunity allows you to contribute exactly as you'd like: your inputs there do not change the other contributor's inputs at all.
(I have been known to dismiss the "possible missing child" hints with a plaintive "isn't thirteen enough?!"...)
0 -
Grüß Gott, Julia,
irgendwie fühle ich mich immer wieder nur halb verstanden. Alle meine Beiträge drehen sich nicht um Einzelfehler sondern um Entwurfsfehler der Datenbankmodellierer bzw. der Datenbankprogrammierer.
Wenn ich in meiner Datenbank Namen mit '-ovÁ' finde, dann korrigiere ich diese nicht einzeln manuell. Vielmehr überlege ich mir, wie ich sämtliche Fehler dieser Art, also tschechische Großbuchstaben mitten im Namen, vermeiden bzw. nachträglich korrigieren kann.
Die Ursache ist einfach erklärt, die Eingeberin Frau Abbott schreibt die Forschungsergebniss von Herrn Šedivý aus MyHeritage ab, nein sie macht das offensichtlich mit Copy & Paste. Dabei werden leider die kleinen á, ... zu Großbuchstaben.
Nun hat Herr Šedivý ca. 120.000 !! Personeneinträge in MyHeritage. Meine Korrekturen und die der anderer Forscher sind also mehr oder weniger nur ein Tropfen auf den heißen Stein. Also habe ich Frau Abbott eine einfache Technik vorgeschlagen, wenigstens die zukünftigen Eingaben fehlerfrei zu übertragen. Nehmen wir dazu ein besonders schönes Beispiel (Wo ist der Ehename, der Witwennam, wo der Geburtsname?) und übertragen den Namen nach Word. Jetzt nur noch <Umsch><F3> (neudeutsch <Shift><F3>) gedrückt und schon erscheint der Name in allen Varianten
Das ist für die schon eingegebenen Namen (wahrscheinlich mehrere 10.000) natürlich eine Lebensaufgabe, also muss ein erfahrener Programmierer her und die Korrekturen programmieren, denn der Algorithmus ist in Word (Windows API) offensichtlich schon vorhanden.
Technischer Hinweis: Die ASCII-Zeichen lassen sich durch die Manipulation eines einzelnen Bits in der Schreibweise wandeln. Das geht bei den diakritischen Unicode-Zeichen leider nicht ohne eine Umwandlungstabelle. In Word gibt es diese offensichtlich.
Fazit: Ich bin so überheblich und sehe meine Aufgabe in FS nicht darin, einzelne Fehler bei den Namen oder den Standardisierten Orten zu korrigieren. Vielmehr schlage ich weiterhin grundsätzliche Lösungswege zur Verbesserung vor.
Diese Lösungen bedeuten oft eine Einschränkung der Benutzerfreiheiten getreu meinem Motto:
Eine Datenbank hat das Recht sich zu verteidigen, gegen unbeabsichtigte oder sogar vorsätzliche Angriffe auf ihre Integrität.
Wieder ein Beispiel: Datumsausgabe (nicht die Eingabe) Hier lerne ich endlich einmal alle Monatsnamen in vielen, vielen Sprache kennen. Auch sind die Abkürzungen und die Reihenfolge der Bestandteile selbst in einem geschlossenen Sprachraum dazu oft besonders interessant. Dabei gibt es eine ISO-Norm. Die gilt aber nur für das Rahmenprogramm
"Man kann doch die Benutzer nicht einschränken". Bei der Eingabe wohl nicht, aber muss ich als Leser der Daten auch noch ein Wörterbuch parat halten?
Und schon frage ich mich: Welchen Einfluss hat die Angabe "Language Template" außer auf die Datumsanzeige? Wer nutzt die eigentlich? Ist die historische oder die Eingeber-Sprache hier einzugeben? Vielleicht hilft sie ja bei der Suche nach Doppeleinträgen.
Wie gesagt, war es nett, mit Ihnen zweckfrei, aber ergebnislos zu plaudern. Es erleichtert mein Herz, hat aber keine wirkliche Wirkung auf FS, oder?
Nein, das ist natürlich falsch. Wenigstens ich habe gelernt, dass es eine Beta-Spielwiese für die Experimente mit FS gibt. Wo finde ich noch mehr dieser Praxistipps?
Hans-Jürgen (Scheibl)
0
