Standardisierung

Wiesenmichel

Warum beginnt FamilySearch mit den Standardisierten Orten und hat noch nicht einmal die Datumsangaben standardisiert?

Zur Präsentation eines numerischen Datums gibt es die ISO-Norm 8601. Warum erlaubt FS die freie Gestaltung der Datumsangabe? Die muss nicht einmal richtig sein.

Gibt es wirklich ernsthafte Ahnenforscher, die ein ISO-standardisiertes Datum nicht lesen können?

Intern muss FS das Datum doch in einem einheitlichen Format abspeichern.

Auch die "standardisierten Orte" können beliebig umgestaltet und falsch geschrieben werden, oder gar ganz falsch zugeordnet werden. Ein gerade einmal wieder gefundenes Beispiel:

Welche Prüfungen erfolgen hier?

Alle Ortsnamen verstoßen gegen die 1. Normalform für Relationale Datenbanken: Die Namen enthalten Trennzeichen (Kommata), die mehrere Informationen über die Verwaltungshierarchie in einen String zusammenpacken.

Die Geo-Koordinaten gehören in zwei getrennte Felder. Der Gültigkeitsbereich gehört in zwei getrennte Datumsfelder usw.

mfg Wiesenmichel

Wiesenmichel

Why is FamilySearch starting with the Standardized Places and hasn't even standardized the dates?

09MAY89

9MAY89

09 MAY 1889

9 MAY 1889

9 May 1889

9 may 1889

9 Sep 1889

09 September 1889

9. September 1889

09 Mai 1889

9 Mai 1889

9 květen 1889

9 Smět 1889

9 Winnemond 1889

9 Мая 1889

and even more and more

There is ISO standard 8601 for the presentation of a numerical date. Why does FS allow you to freely design the date? It doesn't even have to correspond to the internal date.

Are there really serious genealogists who can't read an ISO standardized date?

Internally, FS has to save the date in a uniform format, propably the Windows-format (100 ns Ticks) .

-------------------------

The "standardized locations" can also be rearranged as desired and spelled incorrectly, or even assigned completely incorrectly. An example that has just been found again:

Which tests are carried out here?

All place-names violate the 1st normal form for relational databases: The names contain separators (commas) that combine information about the administrative hierarchy into one string.

The geo-coordinates should saved in two separate fields. The range of date-validity belongs in two separate date fields (Begin-End), etc.

mfg Wiesenmichel

Julia Szent-Györgyi

(As far as I know, FS does not use a relational database.)

Both dates and places are standardized, but both have FS's ultra-flexible dual-field setup: the display value does not need to match the standardized value.

Yes, this gives a greater chance for user error, but that is a tradeoff that FS is willing to accept. (And so am I.)

The Places database is incomplete and full of errors, but it nevertheless can serve its purpose. (Fixing it is an ongoing long-term project.) Again, the dual-field setup allows greater scope for user error, but it also allows for greater precision.

(As an example of "wrong but still works": I'd like to get rid of the second "Dunaszerdahely" in that standard. Yes, that's the correct district, but nobody ever used districts; they're not needed to uniquely designate a place.)

I think part of the problem is that a lot of the place standards are a mishmash of ecclesiastic and administrative jurisdictions, so it's difficult for the average user to determine which choices in the drop-down are "not even close" and which ones are "good enough". In my somewhat limited experience with places in Germany, this is especially true there. Meyer's Gazetteer unfortunately just compounds this problem, as it lists every possible jurisdiction, from ecclesiastic to judicial to military, and it can be difficult to figure out which entry in FS's database corresponds to the place you're looking at in Meyer.

Wiesenmichel

Danke für den Kommentar.

Hier wird das Problem aber größer, da die Standardisierung nicht den Originalnamen 'Hessen' sondern seine englische Übersetzung 'Hesse' als richtig ansieht und diesen dann noch auf alle Wortkombinationen ausdehnt.