Liebe Mitdenker,
Herzlichen Dank für die vielen interessanten Gedanken und Meinungen und für das m.E. hohe Niveau der gemeinsamen Diskussion über eine Schweizer Besonderheit 
Heimatort hat für die Schweizer eine grosse Bedeutung. Er steht in jedem Pass und Personalausweis und ist für den Bürger identitätsstiftend - und zwar nicht nur individuell, sondern generationsübergreifend und zurtiefst genealogisch. Bis 2017 war der Bürgerort auch für die Sozialhilfe zuständig und ein Platz im Altersheim war gesichert.
Wohnort hingegen ist in der Schweiz entscheidend für politisches Mitwirken.
Mir fällt es nicht leicht, „GEDCOM“ zu verstehen. Irgendwie wirkt die Struktur auf mich semantisch unklar, so als wäre sie über die Jahrzehnte einfach „gewachsen“, ohne dass dahinter ein schlüssiger Plan steht, und jetzt hat man so Elemente wie „EVEN“ und „FACT“, für die es keine eindeutige Definition gibt (mit Beispielen für „gehört dazu“ und „gehört nicht dazu“, aus denen man dann Regeln verbindlich ableiten kann). Und ich gewinne den Eindruck, dass jeder Entwickler die Struktur so verwendet, wie es ihm „richtig“ erscheint, aber dass darüber kein Einvernehmen ist, und in Folge dann dazu führt, dass man entsprechend keine Schnittstellen definieren kann. Und ich habe den Eindruck, dass die Weiterentwicklung von GEDCOM eher träge verläuft. Gleichzeitig entwickeln sich aber die Programmiersprachen weiter und können längst mit komplexen Zusammenhängen umgehen, wenn sie denn datenseitig definierter wären.
Was ich auch nicht verstehe::
- wieso gibt es so viele Schlüssel ohne Wert
- wieso gibt es keine Sub-Schlüssel nach dem Schema „ABCD.EFGH“
Zurück zur Frage von „Bürgerort“ und dem Verlauf der Diskussion:
_Unterstrich-Schlüssel können neuartige Inhalte - und neuartige Strukturen - beschreiben.
Aber sie sollen mittelfristig abgelöst werden durch universell gültige Schlüssel.
Neue universelle Schüssel in der Form „ABCD“ müssen in die alte Struktur passen.
Was beispielsweise für „EVEN“ und „FACT“ bisher nicht so recht klappt.
Wenn man aber „Bürgerort“ universell definiert als
1 EVEN
2 TYPE Bürgerort
dann ist das eine Festlegung (wenn auch semantisch nicht wirklich logisch).
Damit kann man arbeiten.
Logischer finde ich:
1 NATI
2 TYPE Bürgerort
3 LOC <bürgerort>
denn in der Schweiz ist ein ein Schweizer: „NATI=Schweiz“ (oder in GEDCOM: „1 NATI Schweiz“)
Und „NATI.Bürgerort=<bürgerort>“ (oder IN GEDCOM: „2 Bürgerort <bürgerort>“)
Strategisch würde ich immer zuerst die Datendefinition machen und die Schnittstelle definieren.
Und in einem zweiten Schritt die Programme kompatibel machen.
Wenn ich richtig verstanden habe, gehört Webtrees zu den Programmen, die neue Datendefinitionen problemslos integrieren können.
Meine Präferenz wäre:
NATI=Schweiz
NATI.DATE=<startdatum>-<enddatum>
NATI.Bürgerort=<bürgerort-1>
NATI.Bürgerort.DATE=<startdatum>-<enddatum>
NATI.Bürgerort=<bürgerort-2>
NATI.Bürgerort.DATE=<startdatum>-<enddatum>
oder in GEDCOM:
1 NATI Schweiz
2 DATE FROM <startdatum> TO <enddatum>
2 Bürgerort <bürgerort-1>
3 DATE FROM <startdatum> TO <enddatum>
2 Bürgerort <bürgerort-2>
3 DATE FROM <startdatum> TO <enddatum>
Technisch ist es meinen GEDCOM-Dateien egal, welche Stringfolge ich verwende.
Schön wäre, für Bürgerort eine universell gültige Definition zu haben
Gruss, Markus