FamilySearch and the 1NF?
The english version follows below.
Achtung! In diesem Beitrag geht es nicht darum, ein schlecht lesbares Wort zu entziffern oder ein totes Ende in einem Ahnenzweig zu überwinden. Vielmehr säge ich hier an den Grundfesten von FamilySearch (FS). Die gute Nachricht ist: Das Problem ist mit viel Mühe reparabel.
Mir ist bewußt, dass ich möglicherweise einen (Deleted) auslöse: "Was will dieser Mensch, es funktioniert doch alles wunderbar". Aber dann müssen Sie einfach nicht weiterlesen.
FS verstößt gegen die Grundregel (1. Normalform) der Relationalen Datenbanktheorie, oder formulieren wir etwas vorsichtiger. FS lässt diesen Verstoß offenen Auges zu, es tut nichts dagegen.
Die Erste Normalform (1NF) in der Datenbankmodellierung verlangt, dass alle Tabellenwerte atomar sind. Das bedeutet: Jedes Datenfeld darf nur einen einzigen logischen Wert enthalten und keine kommagetrennten (oder sonstwie getrennten) Aufzählungen oder sich wiederholenden Gruppen. Zudem muss jede Zeile durch einen Primärschlüssel eindeutig identifizierbar sein.
https://de.wikipedia.org/wiki/Normalisierung_(Datenbank)#Erste_Normalform_(1NF)
https://en.wikipedia.org/wiki/First_normal_form
Der Primärschlüssel wird bereits durch den Mengenbegriff von Cantor verlangt, so dass jedes Element der Menge "wohlunterschieden" ist.
Der "Erfinder" dieses Datenbankmodells, Codd considered 1NF mandatory for relational databases, while the other normal forms were merely guidelines for database design.
Nun wissen wir alle, dass es kein menschgemachtes Merkmal (Nachname) oder keine Merkmalsgruppe (Name + Datum) gibt, die einen Menschen wirklich eindeutig von anderen unterscheidet. Wir führen daher FS-IDs ein, einer interessanten Gruppierung von sieben Zeichen.
Warum interessant?
Weil wir uns im Kurzzeitgedächtnis Dreier- oder Vierergruppen leicht merken können (denken Sie nur daran, wie Sie sich Ihre Telefonnummer merken) .
Erfüllt nun FS die Forderung der 1NF? Nein!
Ständig finden wir dekorierte Namen, die neben dem vermuteten, aktuellen Namen (Sterbenamen) zusätzlich Geburtsnamen, Aliasnamen, Witwennamen, Spitznamen usw. enthalten.
Sind das vielleicht nur Zusammensetzungen für die Anzeige, also keine Verstöße gegen die 1NF?
Nein, FS erlaubt beliebige Vornamen und Nachnamen. Also auch eine Leerstelle, ein Bindestrich, ein Hochkomma sind kein Kriterium, dass es sich um einen Verstoß gegen die 1NF handelt. Schließlich gibt es vielfältige Unterschiede in der Namensgebung verschiedener Nationen.
Achten Sie auf den Hinweis. Leider sterben die Ehefrauen in keinem Kirchenbuch mit ihrem Geburtsnamen sondern mit ihrem Ehenamen. Also brauchen wir beide Namen.
Aber auch bei den Ortsnamen und den Dokumentbezeichnungen finden wir diese Verletzung der 1NF. So ist es häufig üblich die Hausnummern (Konskriptionsnummern) oder ganze Adressen zu hinterlegen.
Bingo, wieder ein Beispiel, bei dem Anzeige und Standard nicht zusammenpassen.
Wie löst man das Problem? (Verbesserungsvorschlag)
FS sollte systematisch die Eingabe der Namensteile trennen und diese auch entsprechend anzeigen. So sehe ich beispielsweise bei 'findagrave' sofort alle diese Teile auf einen Blick (Geburtsname kursiv, Spitzname in ""). Nur die Frage, ob der Mittelbuchstabe mit oder ohne . zu schreiben ist, wird in FS heftig diskutiert.
Und nicht vergessen
Herzliche Grüße vom Hans-Jürgen Scheibl
Hier is the englisch version (by google):
Attention! This post is not about deciphering a hard-to-read word or overcoming a dead end in a family tree branch. Rather, I am taking aim here at the very foundations of FamilySearch (FS). The good news is: With considerable effort, the problem is fixable.
I am aware that I might be triggering a (deleted) —a backlash of comments like: "What is this person on about? Everything works perfectly fine!" But in that case, you simply don't have to read any further.
FS violates a fundamental rule (the First Normal Form) of relational database theory—or, let's phrase it a bit more cautiously: FS knowingly permits this violation; it does nothing to prevent it.
The First Normal Form (1NF) in database modeling requires that all table values be atomic. This means that every data field must contain only a single value—no comma-separated lists (or lists separated in any other way) and no repeating groups. Furthermore, every row must be uniquely identifiable by a primary key.
https://de.wikipedia.org/wiki/Normalisierung_(Datenbank)#Erste_Normalform_(1NF)
https://en.wikipedia.org/wiki/First_normal_form
The primary key is, in fact, already mandated by Cantor's concept of sets, ensuring that every element within a set is "well-distinguished."
The "inventor" of this database model, Codd,
considered 1NF mandatory for relational databases, while the other normal forms were merely guidelines for database design.
Now, we all know that there is no human-assigned attribute—or group of attributes (such as Name + Date of Birth)—that can truly and uniquely distinguish one human being from another. Therefore, we use FS IDs—an interesting grouping of seven characters. Why "interesting"?
Because our short-term memory can easily retain groups of three or four items (just think about how you remember your own phone number).
So, does FS meet this requirement?
No! We frequently encounter "decorated" names—entries that, in addition to the presumed current name (the name used at death), include birth names, aliases, widow's names, nicknames, and so forth.
Are these perhaps merely composite entries intended for display purposes—and therefore not violations of the 1NF (First Normal Form)?
No; FamilySearch permits a wide variety of first and last names. Consequently, the presence of a space, a hyphen, or an apostrophe does not constitute grounds for deeming an entry a violation of the 1NF. After all, there is immense diversity in naming conventions across different nations.
Please take note of the following reminder: Unfortunately, in virtually all church records, wives are recorded at the time of their death under their married name, rather than their birth name. So we need both names.
However, we also observe this violation of the 1NF in place names and document titles. For instance, it is common practice to include house numbers (conscription numbers) or even full addresses within these fields.
Bingo—yet another example where the system's display format and the underlying data standard are at odds with one another.
How can this problem be resolved? (Suggestion for Improvement)
The system should systematically separate the input fields for the various name components and display them accordingly. For example, on 'Find a Grave,' I can immediately see all these distinct components at a single glance (with the birth name in italics and the nickname enclosed in quotation marks). The only point of contention—and one that is still hotly debated within FamilySearch—is whether a middle initial should be written with or without a trailing period.
That should suffice for now, though there is still much more to be said on the subject.
And don't forget to read
Herzliche Grüße vom Hans-Jürgen Scheibl
Answers
-
Only 20 min later:
https://www.familysearch.org/de/tree/person/details/K83F-1YQ
Anna Kozová verwitwete Nová geborene Macháčková
Anna Kozová widowed Nová born Macháčková
Das Haus passt nicht zum Standard Ort.
The house doesn't fit the standard place.
Was soll ich nur nehmen?
What should I choose?
Vielleicht ist es aber eine schottische oder irische Familie aus einem Clan Mac…?
Perhaps, however, it is a Scottish or Irish family belonging to a Clan Mac...?
-1 -
Mod note: a post was edited to remove code violations. Please see the Community Code of Conduct
See section 2, paragraph 3 and paragraph 6.
Mod-Hinweis: Ein Beitrag wurde bearbeitet, um Verstöße gegen die Code-Regeln zu entfernen. Bitte beachten Sie den Community-Verhaltenskodex.
Siehe Abschnitt 2, Absatz 3 und Absatz 6.The discussion forums are intended as a place for users to collaborate, share experiences, and help one another achieve their Family History goals. They are not an appropriate venue for criticizing or disparaging the engineers and developers who work hard to make this a reliable, free, and continually improving resource for the entire community.
If you have corrections, suggestions, or feature requests, the most effective way to ensure they reach the appropriate teams is to submit them through the Suggest an Idea section. That channel is specifically monitored for product feedback, and it allows your ideas to be reviewed by the engineers who can act on them.
Comments posted only in the discussion groups are generally not seen by the engineering teams, so they are unlikely to result in system changes. You may also use the Feedback button, which sends your input directly to the developers.
Thank you for helping keep the forums constructive and focused on supporting one another in our shared Family History work.
0 -
Hat einer von Ihnen wirklich einmal versucht, den von mir eingegebenen Text unter "Vorschläge" einzureichen, dann wird er sehr schnell sehen, dass es nicht geht.
Also schade um die viele Mühe, die ich mir mit dem Zusammensuchen von exakten Bespielen gemacht habe. So vergraulen Sie Vorschläge, die einzig zur Verbesserung von FS dienen.If any of you has actually tried to submit the text I entered under "Suggestions," you will very quickly see that it cannot be done.
So, it is a shame about all the effort I put into gathering exact examples. This is how you drive away suggestions that serve solely to improve FS.Herzliche Grüße vom Hans-Jürgen Scheibl
(Professor für technische Informatik, Berlin; 80 Jahre)
0 -
We appreciate your willingness to share your thoughts; however, it is important to clearly understand and follow Community guidelines.
Ideas posted in the Community are not forwarded to engineering. They are only visible to other users and moderators and cannot be progressed from here. If you want your ideas to be reviewed and considered, you must use the Suggest an Idea or Feedback option. This is the only channel that ensures your input reaches the appropriate teams.
Community responses will continue to direct you to these tools, and posts that do not follow this process are subject to removal after 48 hours.
These guidelines are in place to ensure that feedback is handled appropriately and that the Community remains a respectful and productive space for everyone.
0 -
Although your discussion of 1NF is an interesting theoretical topic, please note that FS Family Tree doesn't use a relational database, so it doesn't really apply. However, even if we set aside the 1NF discussion, you have posed some questions in this thread that I will try to help with.
Regarding the entry of names, you are correct that a person may change their name during their lifetime, and so it is important to allow for the storage of multiple names. As detailed in the help article How do I enter names in Family Tree? the solution is typically to enter the birth name as the primary name and then to enter married names, nicknames, and other alternatives in the Alternate Name fields.
Following the guidance in that article, the primary name for the person you used as an example would be Anna Macháčková. Then you would create an Alternate Name of type Married Name with the name Anna Kozová for her first marriage, and another similar one with the name Anna Nová for her second marriage. Depending on how she was actually known during these marriage (or post-marriage) periods, these married names might be adjusted slightly to be something like Anna Macháčková Kozová (but I don't know those details, since the source documentation is quite limited for this person, and I am not familiar with the Bohemian naming customs of the time). But hopefully that illustrates the general idea. Separating the names into separate entities allows us to specify the meaning of each name, making clear what is the birth name and what are the married names (and each entity can include its own reason statement explaining why that particular name conclusion is correct). That is much better than trying to cram all the names into the primary name entity, where it would be difficult to ascertain the role of each name.
One thing to be aware of as you observe data in Family Tree is that it comes from a collaborative effort by millions of users. The skill level of these users will vary greatly. Some may know their family well, but are not skilled in genealogical practices. Some may have great experience working in their personal family trees, but might be new to the guidelines for working in a collaborative tree like Family Tree. Some may be skilled with languages, while others may have difficulty writing well even in their native language. But everyone has something to contribute, and we all need to patiently work together to improve this one world tree however we can.
With that thought in mind, the examples of Anna Kozová Nová Macháčková and Kateřina Wilmannová b. Karlovcová Krejčířová should really be corrected so that only their birth names are in the primary name, and the various married names are in alternate names of type Married Name. Anyone who understands FamilySearch naming guidelines (and preferably is familiar with those families) could make that change.
In a similar vein, you can see that the unusual capitalization for VÁclav MacHáček comes from a user who is unfamiliar with standards for capitalization, is careless in data entry, or has some unusual opinions about spelling. Whatever the reasons, if you are fortunate to know the proper spelling for that name, you can simply make the correction yourself. In that way you would contribute to improving Family Tree. Billions of such corrections and additions will gradually make Family Tree more accurate over time.
Regarding place names, I won't go into that here. You have already had detailed discussions on that topic with the helpful Gordon Collett in another thread.
1 -
Grüß Gott, @Alan E. Brown
Zuerst einmal eine schnelle Frage:
Wenn Sie kein RDBMS oder ORDBMS Datenmodell benutzen, gibt es möglicherweise eine Beschreibung der Theorie hinter dem FS-Datenmodell.Wo kann ich dieses finden?
Am Anfang ihres Kommentars verweisen Sie auf die Richtlinien zur Namenseingabe. Ich habe diese noch einmal in der deutschen Variante nachgelesen
https://www.familysearch.org/de/help/helpcenter/article/namenseingabe-im-familienstammbaum
Hier kann ich entnehmen, dass mehrere Namen nicht geplant sind.Sollte Ihr Datenmodell die "Multivalued Fields" (z. B. mit Access 2007 eingeführt) verwenden, so gibt es da genügend kritische Meinungen
https://stackoverflow.com/questions/1461582/multivalued-fields-a-good-idea
Diese Felder sind eine Erleichterung für den Programmierer, der die Relation "eine Person : viele Namen während seines Lebens" nun mit wenigen Anweisungen realisieren kann
Aber kommen wir zum Benutzer zurück. Was hilft es ihm, beliebig viele gleichartige Namen zu sehen, ohne ihre Bedeutung zu erkennen
John Fitzgerald Kennedy
Aha, ein zweiter Vorname wie Peter, Hans, ... oder doch nicht
===
First off, a quick question:
If you are not using an RDBMS or ORDBMS data model, is there perhaps a description of the theory underlying the FS data model?
Where can I find this?At the beginning of your comment, you refer to the guidelines for entering names. I have reviewed the German version (automatic link) of these once again:
https://www.familysearch.org/de/help/helpcenter/article/namenseingabe-im-familienstammbaum
From this, I gather that support for multiple names is not planned (marked "den Namen" is Singular, not "die Namen").If your data model happens to utilize "Multivalued Fields" (e.g., as introduced in Access 2007), there are plenty of critical opinions regarding them:
https://stackoverflow.com/questions/1461582/multivalued-fields-a-good-idea
These fields make life easier for the programmer, who can now implement the "one person : many names throughout their lifetime" relationship with just a few lines of code.
But let's turn our attention back to the user. What benefit does it offer them to see an arbitrary number of identical-looking names without being able to discern their significance? What are they supposed to think when the order of names for the husband is exactly the reverse? I will find an example.John Fitzgerald Kennedy
Aha—is that a second given name, like Peter, Hans, etc.? Or is it not?
Hans-Jürgen Scheibl
0 -
You asked:
If you are not using an RDBMS or ORDBMS data model, is there perhaps a description of the theory underlying the FS data model?
Where can I find this?
FamilySearch doesn't publish the theory underlying its data model. I'm sure that's disappointing to you, but such documentation is simply not available. I only mentioned the fact that it uses a non-relational database so that you would not needlessly spend time trying to find elements of the Family Tree data that don't fit in a strict 1NF model.
At the beginning of your comment, you refer to the guidelines for entering names….
From this, I gather that support for multiple names is not planned (marked "den Namen" is Singular, not "die Namen").
Support for multiple names already exists, as I tried to explain earlier. (By the way, it does not use the "Multivalued Fields" approach.)
A name object in FamilySearch consists of these elements:
- Language template
- Title (optional)
- Given names
- Surnames
- Suffix (optional)
Each person has exactly one primary name. This is the name that appears in the Vitals section of the person profile page.
Each person may have zero to many Alternate Names, which appear in the Other Information section. Each alternate name looks exactly like I described above, but with one additional field to specify the type of alternate name (for example, Nickname or Married Name).
But let's turn our attention back to the user. What benefit does it offer them to see an arbitrary number of identical-looking names without being able to discern their significance?
I'm not sure what you mean by "identical-looking names." The examples I gave in my previous comment were quite distinct:
Primary name: Anna Macháčková
Alternate Name (Married Name): Anna Kozová
Alternate Name (Married Name): Anna NováThere are many advantages to this approach:
- Each distinct name has its own given names and surnames in separate fields. This makes it clear what the role of each name part is.
- Each distinct name has its own reason statement (the user's explanation of why this conclusion is correct). It is helpful to keep the explanations separate, so that in one place you can explain why (and when) she was known as Anna Kozová without jumbling that explanation with explanations for her other names. This will help other users to "discern their significance."
- When searching for source documents that pertain to this person, you can easily include or exclude various alternate names to focus on documents from different phases of her life.
- For each alternate name, you can see at a glance if a name was a married name or a nickname, etc.
What are they supposed to think when the order of names for the husband is exactly the reverse? I will find an example.
John Fitzgerald Kennedy
Aha—is that a second given name, like Peter, Hans, etc.? Or is it not?
In most contexts, simply seeing "John Fitzgerald Kennedy" is adequate. But when you really need to distinguish what the particular parts of this name are, you can simply view the details of the name, where you will see that "John Fitzgerald" is in the Given Names field and "Kennedy" is in the "Surnames" field.
0 -
"google-English" below
Grüß Gott, @Alan E. Brown
Danke Alan für die umfangreichen Handhabungsanweisungen. Aber offensichtlich irren sich Tausende von Eingebern, weil die vorgegebene Eingabetechnik nicht selbsterklärend ist. Nun sind meine Beispiele aus Böhmen (aus der weit zurückliegenden) natürlich hinterhältig, weil neben der damals erst beginnenden Namensentwicklung noch die Zweisprachigkeit in diesen Grenzgebieten eine große Rolle spielt. Daher benötige ich für eine böhmische Ehefrau mindestens vier Namen (Ehe- und Geburtsname in tschechisch und deutsch, je nachdem welcher Pfarrer das Kirchenbuch gepflegt hat). Dazu kommen noch die Aliasnamen (Hofnamen) durch Heirat.
Mangels entsprechender Möglichkeiten in FS retten sich nun die meisten Eingeber dadurch, dass sie alle Namen in ein einziges Feld packen.
Die falsche Großschreibung diakritischer Kleinbuchstaben mitten im Namen vieler hundert/tausend Namen ist eine Besonderheit einer Eingeberin, die MyHeritage für FS abschreibt.
Du hast sicher intensiv die Diskussion mit Gordon Collett über den von mir gemeldeten Fehler gelesen. Das Ergebnis der Fehlersuche ist, dass ein "Standard Ort" in FS beliebig hinter einer freien Eingabe verschleiert werden kann. Das brachte mich aber erst einmal auf die Idee, nach der 1 NF in FS zu suchen. Bei der Ortseingabe sehe ich aber derzeit nicht die Möglichkeit, beliebig viele Alternariven einzugeben, oder doch?
Also RDBMS, ORDBMS, MVDBMS ist es nicht. Vielleicht ein Semantic Web oder doch gar kein gängiges Datenmodell. Schade, ich hätte gern etwas Neues dazugelernt.
"John Fitzgerald Kennedy" ist natürlich ein klassisches Beispiel, "Fitzgerald" ist natürlich kein Vorname sondern der Geburtsname seiner Mutter.
Nebenbei habe ich selbst Probleme mit meinem Geburtsnamen "Paul Hans-Jürgen", also "Patenvorname" plus deutschem "Rufnamen" in dieser Reihenfolge. Im ersten Pass wurde der Rufname noch unterstrichen, das gab aber wohl Ärger bei der Grenzkontrolle und kann auch nicht mehr auf modernen Chip-Karten dargestellt werden. Andererseits habe ich in dieser Reihenfolge den "falschen" Mittelnamen (Mittelbuchstaben HJ geht gar nicht) usw. usw.
Eine Anmerkung zu Deiner Anmerkung hätte ich noch:
and I am not familiar with the Bohemian naming customs of the time
Muss sich jetzt jeder Benutzer erst einmal in die jeweilige Kultur einlesen, damit er FS versteht?
So gab es (oder gibt es noch immer) den Effekt, dass die 'Sprachvorlage Ungarn' die Namensreihenfolge umdreht:
https://community.familysearch.org/de/discussion/comment/600191#Comment_600191?utm_source=community-search&utm_medium=organic-search&utm_term=UngarnFazit: Ich bleibe dabei: Die Rückkehr zur 1NF wäre für FS sinnvoll. Die aktuelle Lösung "Standardisiert Ort" ist eine Fehlentwicklung. Eine bessere Lösung (mit ausführlichem, vollständigem RDBMS) habe ich mehrfach vorgeschlagen. Jeder Eingeber sollte in seinem Profil die Möglichkeit haben, seine "Tricks" zu beschreiben, die der Benutzer nicht raten kann.
===
Thanks, Alan, for the comprehensive instructions on usage. However, it is evident that thousands of data entry specialists are mistaken, as the prescribed input method is not self-explanatory. Now, my examples from Bohemia (dating back to the distant past) are, of course, tricky; alongside the evolution of surnames—which was just beginning at the time—the issue of bilingualism in these border regions plays a significant role. Consequently, for a Bohemian wife, I require at least four names (her married and maiden names in both Czech and German, depending on which priest maintained the church register). Added to this are the alias names (farm names) acquired through marriage.
Due to a lack of suitable options in FS, most data entry specialists currently resort to cramming all these names into a single field.
The incorrect capitalization of lowercase letters with diacritical marks—occurring right in the middle of hundreds or thousands of names—is a peculiar quirk of one specific data entry specialist whose work MyHeritage is importing from FS.You surely followed the extensive discussion with Gordon Collett regarding the error I reported. The conclusion of that troubleshooting process was that a "standardized place" in FS can be arbitrarily obscured behind a free-text entry. However, that discovery first gave me the idea to look for evidence of First Normal Form (1NF) within FS. Yet, when entering place names, I currently don't see any option to enter an unlimited number of alternatives—or is there?
So, it’s not an RDBMS, ORDBMS, or MVDBMS. Perhaps it’s a Semantic Web structure—or perhaps not even a standard data model at all. It’s a pity; I would have liked to learn something new.
"John Fitzgerald Kennedy" is, of course, a classic example; "Fitzgerald" is obviously not a given name, but rather his mother's maiden name.
Incidentally, I have issues with my own birth name: "Paul Hans-Jürgen"—that is, my "godparent's name" followed by my German "primary name," in that specific order. In the first passport, the given name was still underlined; however, this apparently caused issues at border control and can no longer be displayed on modern chip-based cards. On the other hand, with this specific name order, I end up with the "wrong" middle name (the middle initials "HJ" are simply not acceptable), and so on.
I have one further comment regarding your remark:
"and I am not familiar with the Bohemian naming customs of the time"
Is every user now expected to first familiarize themselves with the respective culture just to be able to understand FamilySearch? For instance, there was (or perhaps still is) an issue where the "Hungary Language Template" would reverse the name order:
https://community.familysearch.org/de/discussion/comment/600191#Comment_600191?utm_source=community-search&utm_medium=organic-search&utm_term=UngarnConclusion: I stand by my position: Reverting to 1NF (First Normal Form) would be a sensible move for FamilySearch. The current "Standardize Place" solution is a misguided development. I have repeatedly proposed a superior solution (involving a comprehensive, full-featured RDBMS). Every data contributor should have the option within their profile to document the specific "tricks" or conventions they have used—details that a subsequent user would otherwise be unable to guess.
Herzliche Grüße vom Hans-Jürgen Scheibl
-1
