Wird in discort nicht mein kompletter Mailtext angezeigt?
Ich hatte Deine Variante 8 mit in meiner Mail.
Die hast Du „als Vorgriff auf GEDCOM-7“ bezeichnet. Da die Kennzeichen
in GEDCOM 5.5.1 in der Art nicht definiert sind, sind sie (in einer
GEDCOM 5.5.1 Datei) in der Art unzulässig.
Gruß, Stefan Mettenbrink.
Das hat (soweit ich das erkenne) keiner bestritten.
Allerdings wurde in der GEDCOM-L die Variante mit EVEN empfohlen.
Nach der Beschreibung von Heinz ist der Bürgerort eher ein Ereignis
(Zuweisung eines Bürgerortes) mit Datum als ein Fakt (mit Datum).
Wenn ich mir jedoch den Beruf ansehe, ist das auch als Attribut
definiert. Da kann ich ja auch genau angeben, von wann bis wann (oder ab
wann) der Beruf ausgeübt wird.
Wir drehen uns im Kreis.
Laut GEDCOM/PLAC-Tag – GenWiki gibt
es eine klare Empfehlung. Die sollten wir so nutzen.
Gruß, Stefan Mettenbrink.
Mir ist die Semantik nicht klar…
Häufig steht ein Ereignis auf Level-1: NAME, BIRT, OCCU, …
Noch nie habe ich gesehen, dass es ein Level tiefer steht:
1 FACT
2 NAME, BIRT, OCCU, … (das sind immer und implizit Ereignise und/oder Fakten)
Intuitiv bzw. logisch wäre also:
1 BURG
Die vorgeschlagenen Varianten 1 und 2 und die von Peter (ohne Nummern)
passen irgendwie nicht zur Systematik…
Gruss, Markus
Hallo Markus,
bei EVEN oder FACT handelt es sich um generische Ereignisse oder Fakten, welche durch die TYPE-Angabe näher spezifiziert werden. Zu den beiden Kennzeichen und deren Grammatik siehe GEDCOM-Standard 5.5.1 und 7.0.
Viele Grüße
Peter (Schulz)
Hallo in die muntere Diskussionsrunde,
hier wurde jetzt die Diskussion wiederholt, die wir in der GEDCOM-L unter den Programmautoren geführt hatten. Wir haben mit dem Ziel, dass die Lösung möglichst von allen Programmen verstanden wird (auch von denen, die nicht in der GEDCOM-L Gruppe vertreten sind) gearbeitet. Wegen dieses Ziels und der Möglichkeit, die Aussage zum Bürgerort mit vorhandenen Strukturen des GEDCOM 5.5.1 Standards darzustellen, haben wir alle Varianten verworfen, die Nutzerdefinierte Kennzeichen verwenden. Also alles, was mit einem Unterstrich beginnt und somit wie _BÜRGERORT oder so aussieht. Verboten nach Standard sind alle Lösungen, die ohne Unterstrich im Kennzeichen beginnen und ein Kennzeichen verwenden, welches nicht im Standard definiert ist. Da Bürgerort auch im GEDCOM 7.0 Standard keinen Eingang als eigenes Kennzeichen gefunden hat, scheiden somit auch alle Lösungen wie BURG auch unter GEDCOM 7.0 wie unter GEDCOM 5.5.1 aus.
Wie hier bereits mehrfach beschrieben, hat sich die GEDCOM-L Gruppe entschieden, den Bürgerort mit EVEN zu beschreiben: https://wiki.genealogy.net/GEDCOM/PLAC-Tag#P8_B.C3.BCrgerort
Hierbei können alle für das Ereignis EVEN erlaubte Unterstrukturen zur weiteren Spezifizierung verwendet werden. Insbesondere kann man mit DATE auch Angaben einbauen, ab wann und ggfs. bis wann der Bürgerort gilt.
Das von Peter bereits aufgeführte Beispiel wird also so exportiert (mit EVEN, nicht mit FACT):
1 EVEN
2 TYPE Bürgerort
2 PLAC Untereggen, SG
2 DATE FROM 1 MAY 1950 TO 31 DEC 1980
1 EVEN
2 TYPE Bürgerort
2 PLAC Winterthur, ZH
2 DATE FROM 1 JAN 1981
Das ist sowohl für GEDCOM 5.5.1 als GEDCOM 7.0 eine dem Sinn und Zweck des GEDCOM Standards entsprechende Lösung, sie wird - wie hier in der Diskussion bereits auch ausgeführt - von den meisten Programmen verstanden und sollte daher unbedingt zur Umsetzung kommen.
Jede andere Lösung birgt eine erhöhte Gefahr in sich, dass andere Programme es einfach nicht verstehen. Und mit dieser vereinheitlichten Lösung haben Programme intern die Möglichkeit, ein eigenes Datenfeld für Bürgerort einzubauen und dieses aus dieser Lösung heraus zu füllen und mit dieser Lösung zu exportieren und doch gleichzeitig kompatibel zu den Programmen zu bleiben, die für den Bürgerort keine explizite Lösung in der Nutzeroberfläche haben.
Ich sehe auch aus dieser nochmaligen Diskussion in dieser Liste heraus keinen Grund, warum die Entscheidung der Programmautoren in der GEDCOM-L zum Bürgerort verändert werden sollte. Sie ist auch für den neuen GEDCOM Standard 7.0 zutreffend.
Mit freundlichen Grüßen
Albert (Emmerich)
Admin der GEDCOM-L Gruppe
Vielen Dank für die verschiedenen Sichten auf die Dinge und die Erläuterungen.
Nur sachlich-inhaltlich und nicht gedcom-technisch:
Vererbung des Bürgerortes vom Vater durch Geburt
Das ist der eine Weg zum Erhalt eines Bürgerrechtes - das Ereignis wäre wohl die Geburt, der Erhalt des Bürgerrechtes ist einfach so - also eher ein FAKT
Erwerb des Bürgerrechtes in einer Wohnsitz-Gemeinde
Das ist der zweite Weg zum Erhalt eines Bürgerrechtes - und wohl klar ein Ereignis; allenfalls begleitet vom Ereignis, dass das Bürgerrecht von der Geburt beendet wird.
Damit keine Mischformen entstehen, macht die Abbildung in einer einzigen Art Sinn, das Bürgerrecht ab Geburt im Normalfall ohne Datum oder höchstens mit einem bis-Datum - alle anderen Vorgänge mit von-Datum. Und die Abbildung mehrerer Bürgerrechte (= Bürgerorte) ist auch kein Problem.
Dass je nach Herkunfts-Anwendung geprüft werden muss, was in einer Gedcom-Datei weitergegeben wird, ist ja dann auch nichts Neues.
Danke nochmals für das allseitige Engagement am Thema und einen guten Sonntag!
Heinz
Hallo Heinz,
bei der Dokumentation des Bürgerortes in einer Genealogie geht es in erster Linie um den Ort, an dem die Lebensdaten einer Person im Familienregister erfasst und archiviert wurden. Die Angabe bezieht sich also nicht auf einen „Zeitpunkt“ (= Ereignis), sondern auf einen „Zeitraum“ (= Tatsache).
Der GEDCOM-Standard schreibt dazu:
„Als allgemeine Regel sind Ereignisse (Events) Dinge, die zu einem bestimmten Zeitpunkt passiert sind. Die „zwischen Datum und Datum“-Form sollte (BET Datum AND Datum) benutzt werden, um anzuzeigen, dass etwas irgendwann in dem Zeitraum passiert ist. Die „von Datum bis Datum“-Form (FROM Datum TO Datum) sollte möglichst vermieden werden. Wenn etwas über einen gewissen Zeitraum hinweg passiert ist, so ist es wahrscheinlich kein Ereignis, sondern eher ein Attribut oder Fakt.“
So gesehen handelt es sich in den beiden von Dir skizzierten Fällen um Fakten.
Aber sehen wir es pragmatisch:
Wer die Wahrscheinlichkeit erhöhen will, dass der Bürgerort beim Datenaustausch mit Programmen, die den GEDCOM-Standard nicht vollständig unterstützen, korrekt übertragen wird, sollte das EVEN-Kennzeichen verwenden. Vor diesem Hintergrund wurde auch vor 10 Jahren die GEDCOM-L Empfehlung ausgesprochen, einen Fakt mit dem generischen EVEN darzustellen, da FACT nicht von allen Programmen unterstützt wurde.
Wer aber den Bürgerort semantisch korrekt in seiner Genealogie verwenden möchte, verwendet dafür das FACT-Kennzeichen. Dies ist natürlich auch mit der Angabe einer Zeitspanne möglich. Die grammatikalische (Teil-)Struktur von FACT und EVEN ist ohnehin gleich. Der Unterschied zwischen der Verwendung von EVEN und FACT besteht darin, dass manche Programme Ereignisse und Fakten zu einer Person in unterschiedlichen Registern darstellen. Bei der Verwendung von EVEN erscheint dann der Bürgerort unter den Ereignissen, wo er meiner Meinung nach nicht hingehört.
Viele Grüße
Peter (Schulz)
Vielen Dank Peter
Vollkommen klar - und bereits beim Hochladen ins TNG vom Geneal-Forum musste ich EVEN-Kennzeichen verwenden, weil FACT nicht unterstützt wird! Gut, dass dort die Darstellung nicht in verschiedenen Registern erfolgt.
Grüsse
Heinz (Riedener)
Hallo Heinz,
ja, da hast Du recht. TNG gehört zu den Programmen, welche mit der Umsetzung des GEDCOM-Standards so ihre Schwierigkeiten haben. 
FACT wird nicht unterstützt und bei EVEN musst Du sicherstellen, dass die TYPE-Angabe unmittelbar der EVEN-Angabe folgt. Ansonsten werden Daten ohne Hinweis verworfen.
Peter (Schulz)
Im webtrees-Forum wurde noch ein interessanter Vorschlag für die Nutzung des Bürgerortes in GEDCOM gemacht:
In GEDCOM (5.5.1 und 7.0) gibt es das Kennzeichen NATI (NATIONAL_OR_TRIBAL_ORIGIN), welches für Nationalität steht. Laut Beschreibung ist es zu verwenden, um die nationale Herkunft einer Person, oder ihre Volks-, Haus-, Gesinnungs-, Abstammungs- oder Stammesherkunft zu beschreiben.
Mit einer TYPE-Angabe kann das Kennzeichen näher spezifiziert werden.
1 NATI
2 TYPE Bürgerort
2 PLAC Untereggen, SG
2 DATE FROM 1 MAY 1950 TO 31 DEC 1980
1 NATI
2 TYPE Bürgerort
2 PLAC Winterthur, ZH
2 DATE FROM 1 JAN 1981
Viele Grüße
Peter (Schulz)
Das nutzerspezifische Tag _BUERGERORT wird laut GEDCOM/ Nutzerdef-Tag – GenWiki von den folgenden Programmen unterstützt: Ahnenforscher2000, Stammbaumdrucker, Familienbuch, Ahnenblatt. Allerdings würde ich die Verwendung in Hinblick auf einen Umstieg zu GEDCOM 7.0 auf keinen Fall mehr empfehlen. Eine Standardkonforme Lösung mit EVEN/FACT wird das Leben leichter machen.
Ob EVEN mit einem exakten Datum (erstmalige oder spätere Zuordnung eines Bürgerortes) oder FACT (mit einem Zeitraum „ab“ oder „von - bis“) ist eine Grauzone. Die von Albert bevorzugte Lösung mit EVEN und Zeitraumsangaben finde ich als semantisch nicht korrekt, aber das ist sicherlich die Lösung, die am kompatibelsten mit unterschiedlichen Programmen ist.
Die Variante mit 1 NATI gefiel mir auch gut, aber es gibt wohl nicht viele Programme, die das unterstützen.
Die Ausgangsfrage bezog sich ja auf webtrees als Programm. Mit webtrees funktionieren alle hier vorgestellten Lösungen, die irgendwie GEDCOM-konform sind (also _BUERGERORT, EVEN, FACT, NATI), so dass man hier völlig frei ist. Die Variante, die man importiert, kann man in webtrees bearbeiten. Und beim Export wird sie auch wieder so exportiert wie sie war (es erfolgt also kein Eingriff in die gewählte GEDCOM-Struktur).
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::
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