[ChrisR]
Bewusst hier aufgrund mangelnder Datenbank- und Status der Definition-
Kenntnisse weiter ins Fettnäpfchen zu treten, versuche ich einige der
aufgeworfenen Punkte besser zu definieren, um zu verstehen ob wirklich
Du trittst nicht ins Fettnäpfchen (IMHO), aber du wirfst bewusst oder
unbewusst verschiedene Schichten bunt durcheinander, nämlich
Programm-Funktionalität mit Austausch-Funktionalität. Ich bin auch nur
Anwender, bilde mir aber ein, ein kleines bisserl Ahnung (zumindest
Halbwissen) von Programmieren, Datenbanken und GEDCOM zu haben. Deshalb
schreibe ich das hier aus meiner subjektiven Sicht, der vielleicht nicht
jeder zustimmt. Von Anwender an Anwender.
Vorsicht: Es wird lang. Und vielleicht auch recht technisch.
Der Titel des Threads ist „Gedcom - alternative Dateiformate“. Irgendwo
ziemlich am Anfang steht die Aussage „Software-Katastrophe GEDCOM“.
GEDCOM ist KEINE Software. GEDCOM ist ein Transport- oder
Austausch-Format. Als Alternativen fallen mir dazu nur 2 weitere Formate
ein: XML, JSON
Dass von einigen Programmierern XML oder JSON bevorzugt wird, mag
vielleicht daran liegen, dass einige Programmiersprachen nativen Support
für XML oder JSON bieten, während die Programmierer für GEDCOM erst
einen eigenen Parser schreiben müssen, wenn’s noch kein anderer getan hat.
Da es nach Thread-Titel eigentlich um den Austausch gehen soll, versuche
ich mal die Programm-Funktionalität von der Austausch-Funktionalität in
deinen Punkten zu trennen. (In der Programmierung gibt es das
MVC-Konzept (Model-View-Controller), das die verschiedenen Schichten
voneinander unabhängig hält. Auch für Genealogie-Software und den
Datenaustausch sollte man das anwenden können.)
Vorsicht: vielleicht zerhagelt Discourse wieder meine Formatierungen 
Unterstriche scheint Discourse als Umschalter zu Kursiv zu verstehen.
- Orte: mit Erwähnung Orts-Verwaltung meinte ich dass Software ohne
eine solche nicht mal 5.5.1 komplett abdecken können, also setze ich
dieses (für mich) Grundfeature voraus. GPS-Felder: sind nicht
nativ und flexibel (bleiben starr). Ich kann mir nicht vorstellen,
dass Logiken Sprach- und zeitliche Versionen, Custom Hierarchien /
Pfarren usw. in 5.5.1 oder L-Definition austauschbar erhalten
bleiben oder wäre das schon möglich? Diese Funktion als reines
Feature wäre für mich nämlich nur interessant zu nutzen, wenn nicht
nur von einer Software unterstützt. Ähnlich auch in nun folgenden
Punkten.
Orts-Verwaltung:
ist Programm-Funktionalität. Was ein Programm hier anbietet, ist
abhängig davon, für was es gedacht ist, und davon was der Programmautor
seinen Anwendern an Komfort bietet. Hier gibt es alles von einem
einfachen Eingabefeld bis zu einer umfangreichen Ortsdatenbank.
Transport-Funktionalität: da gibt das Standard-Kennzeichen PLAC,
außerdem die GEDCOM-L-Erweiterung „_LOC“. Damit kann man bereits
Orts-Hierarchien abbilden. Und Ortsstrukturen sind gerade beim
GEDCOM-Steering-Kommittee in Überarbeitung.
- Quellenverwaltung: bei Medienanhang meine ich besonders flexiblere
Standarddefinition von Speicherorten (lokal absolut/relativ, online
https/webdav) usw. und explizite Unterstützung von modernen Formaten
(auch in der Darstellung) wie WebP, MD (Markdown) und gute PDF-
Unterstützung. Ist klar, dass das letztendlich ein Feature der
Software ist, aber die Definition der wichtigsten Formate im
Standard, würde dies vielleicht etwas harmonisieren. Ebenso
interessant vordefinierte Möglichkeiten die Daten (GEDCOM und die
verknüpften Medien) als komprimierte Datei (ZIP) zusammen zu speichern.
Quellen-Verwaltung:
ist Programm-Funktionalität. Manche bieten nur ein einfaches
Eingabe-Feld, in das man alles reinquetschen muss, was man braucht um
eine Quelle wiederzufinden. Und dann muss man vielleicht kryptisch
abkürzen, weil das Feld nicht lang genug ist. Für den Transkript-Text
ist kein Platz. Andere ermöglichen die Eingabe von Quellzitaten und
Dokument-Anhänge. Einige zeigen die Dokumente auch an, bei anderen muss
man das Dokument separat öffenen. Welche Art Dokumente man anhängen kann
bzw. wie sie angezeigt werden, bestimmt das Programm (der
Programm-Autor). Markdown (z.B. in Quell-Zitaten) ist auch nur eine
Anzeige-Form = Programm-Funktionalität.
Was du unter „gute PDF-Unterstützung“ verstehst, ist mir nicht klar.
Aber egal ob es um Dokument-Anhang, -Anzeige, oder -Erstellung geht, das
ist alles Programm-Funktionaliät.
Transport-Funktionalität: GEDCOM bietet für Quellen SOUR mit diversen
Unterkennzeichen wie PAGE, AUTh, … . Medien können einem SOUR
zugeordnet werden.
Für Medien hat GEDCOM die gängigsten Formate (jpg, pdf, mp3, mp4, …)
in Petto. webp ist neuer und nicht im Standard gelistet, es sollte aber
trotzdem kein Problem sein, das zu transportieren.
Mit GEDCOM 7 gibt es auch die zip-Möglichkeit.
- Bezifferungsfelder: hier meinte ich dass REFN+INDI (immer) den
Probanden (oder das Start-Paar) referenziert und somit
unterschiedliche Bezifferungs-Sets für diverse Probanden einfacher
parallel gehalten werden können und diese Logik auch bei Austausch
behalten werden kann. Ich behelfe mir derzeit mit unbefreidigenden
Mehrfacheinträgen in REFN oder auch CAST (Feld für Kaste); SSN
(Social Security Number) “mißbrauche” ich derzeit (noch) nicht. Eine
automatische Füllung der Bezifferung ins Feld ausgehend von
Startperson ist sicherlich ein Feature, würde dann dazu passen. Eine
dynamische Bezifferung bei Ausgaben (Tafeln, Listen) reicht mir
nicht, besonders wenn man z.B. zwei Probanden vergleicht/untersucht.
Bezifferungs-Felder:
ist Programm-Funktionalität: Kekule/SOSA etc. sind Probanden-abhängig.
Da sollte das Programm in der Lage sein, den Probanden zu wechseln und
die Bezifferungen anzuzeigen. Auch ob das Programm ein Bezifferungsfeld
anbietet, damit der Forscher dort eine „Familien-Signatur nach eigenem
System“ eintragen kann, bestimmt der Programm-Autor.
Transport-Funktionalität:
Bezifferungen wie Kekule/SOSA haben IMHO(!) nichts im im
Austausch-Format zu suchen. Warum sollte ich diese statisch für mich,
meine Kinder, Eltern, Großeltern, Patenkinder, Großonkel und wen auch
immer transportieren und die Export-Datei aufblähen? Für eigene
Signaturen, wer’s braucht, steht REFN zur Verfügung.
- Referenzierung von Personen bei Ereignissen und vielleicht auch
Referenzierungen:
ist Programm-Funktionalität: ob ich einen Paten oder Trauzeugen nur
textlich eintragen kann, oder ob ich eine Person aus dem Datenbestand
zuweisen kann, bestimmt der Programm-Autor. Ob man auch allgemein
Beziehungen wie Nachbar/Arbeitskollege/Vereinskamerad zuweisen kann, ist
abhängig vom Programm (Funktionalität).
Transport-Funktionalität:
In GEDCOM 5.5.1 geht das mit _ASSO (GEDCOM-L?), in V7 gibt es ASSO.
dazu *DNA-Genealogie Felder*: Felder für at, Y, mt - Matches
(Referenzierung Personen), Felder für Y, mt - Haplogruppen
Falls nicht explizit im Standard definiert sollte es die *Definition
eines Schemas für Erweiterungen* geben (kein Datenverlust bei
unbekannten Tags), die dann von unterschiedlicher Software
austauschkonform unterstützt werden könnte.
DNA-Genealogie:
Programm-Funtkionalität: DNA-Genealogie ist relativ „jung“. Da müssen
Programmautoren erstmal schauen, wie sie was im Programm unterstützen
wollen/können.
Transport-Funktionalität:
explizite Kennzeichen gibt es nicht, siehe „jung“. Ließe sich aber mit
Sicherheit über Unterstrich-Kennzeichen transportieren.
- XML Nachteile kann ich zu wenig praktisch einschätzen, aber
Vermeidung von Ambiguitäten in der Syntax (z.B. Zeilenumbrüche,
UTF-8 Zwang) könnten besser funktionieren. Ich denke das wurde
Grundsätzlich könnte man alles, was es im GEDCOM gibt, auch über xml
oder json abbilden. Aber dazu muss man sich auch erstmal auf eine
gemeinsame Nomenklatur und Grammatik einigen. Und warum sollte das
besser gehen als beim GEDCOM-Format?
GEDCOM (5.5.1) hat sicher einige Mankos. Aber es ist ein verdammich
mächtiges Austauschformat. Die oben genannte „Software-Katastrophe“
besteht meines Erachtens darin, dass die Programm-Autoren in der
Vergangenheit den GEDCOM-Standard falsch und lediglich nach ihrem Gusto
interpretiert und implementiert haben. Und darin, dass Funktionalität-
und Transport-Schicht nicht getrennt wurden. Und daraus folgt leider,
dass es an den Anwendern hängen bleibt, ihre GEDCOM-Exporte so
aufzubereiten, dass sie ihre Daten von A nach B bekommen.
Aber es wird ja am GEDCOM-Standard gearbeitet, auch wenn es gefühlt nur
in Trippelschritten vorangeht.
(Ich sollte vielleicht nicht vergessen zu erwähnen, dass der ein oder
andere Programmautor hier durchaus recht progressiv ist. Und ich will
auch nicht alle Programme über einen Kamm scheren. 
)
Ich hoffe über den Jahreswechsel kann ich ein wenig den Stand der Dinge
bei Import/Export bzw. Kompatibilität bei einiger aktueller Software testen.
Ich hoffe, ich konnte dir ein paar Anregungen für die
Betrachtung/Beschäftigung über den Jahreswechsel geben. 
Viele Grüße
Martina (Klein)
