PAF5 hat ja die sch�ne Eigenschaft, da� jeder Person eine eindeutige Nummer
zugeordnet wird, die dann auch beim Gedcom-Export erhalten bleibt.
Mich w�rde mal interessieren, ob auch andere Programm so eine eindeutige Nummer
kennung und dann auch exportieren. Irgendwelche Erfahrungen?
Jesper
Guten Tag,
ich verwende Ahnenwin von Dr. Reitmeier.
Ahnenwin vergibt automatisch Nummern, ich nenne sie mal Systemnummern. Sie
werden aufsteigend angelegt, durch L�schung frei gerwordene Nummern werden
wiederverwendet.
Au�erdem kann man jedem Probranden eine mehrstellige ID zuordnen, beliebigen
Inhalts.
Zum Export verwende ich GEDCOM.
Lese ich sp�ter diese GEDCOM-Datei wieder ein, werden die eindeutigen
Systemnummern und
die (frei vergebbaren) IDs voll wieder hergestellt, also sind sie in GEDCOM
enthalten.
Die Frage ist, ob andere Programme diese Nummern auch �bernehmen!
Ahnengalerie, mit dem zeichne ich die Stammb�ume u.�., �bernimmt weder noch!
Sehr zu meinem Leidwesen!
Das sind meine Erfahrungen.
Herzliche Gr��e aus Rheinhausen am sch�nen Niederrhein
Kurt Willutzki
Beguinenstra�e 34
47228 Duisburg
02065 92171
willutzki.kurt@t-online.de
Als Genealogie-Programm setze ich das neue Ahnenwin 3.0 von Dr. Heribert
Reitmeier ein. Z.Zt. habe ich 2000 Probanden erfasst, Willutzki, Vor- und
Nachfahren, Zugeh�rige.
Forschungsgebiet: Masuren im Dreieck Lyck, L�tzen, Gehlenburg
Suche alles zu Willutzki, Wilutzki, Wylutzki, Willudzki, Wylludzki,
Wyluczki, und �hnlich, also in jeder Schreibweise.
Suche Infos zu den M�hlen in oder bei Gehlenburg/Bialla, Kosuchen, Lauth,
Wilkus M�hle
PAF5 hat ja die sch�ne Eigenschaft, da� jeder Person eine eindeutige
Nummer
zugeordnet wird, die dann auch beim Gedcom-Export erhalten bleibt.
Mich w�rde mal interessieren, ob auch andere Programm so eine eindeutige
Nummer
Hallo Jesper Zedlitz,
zur Mail vom Wed, 15 Aug 2001 15:15:20 +0200:
Mich w�rde mal interessieren, ob auch andere Programm so eine eindeutige Nummer
kennung und dann auch exportieren.
Brother's Keeper numeriert alle Personen fortlaufend; die Nummer wird auch
im .GED File verwendet, z.B. aus BK-Nr. 3917 wird dann 0 @I3917@ INDI.
Gru�
Gerd
Gerd,
>Mich w�rde mal interessieren, ob auch andere Programm so eine eindeutige
Nummer
>kennung und dann auch exportieren.
Brother's Keeper numeriert alle Personen fortlaufend; die Nummer wird auch
im .GED File verwendet, z.B. aus BK-Nr. 3917 wird dann 0 @I3917@ INDI.
Das macht doch jedes Programm so, das GEDCOM exportiert, oder?
Ich denke, was Jesper meinte, sind EINDEUTIGE IDs.
Das neue Feature von PAF 5 erzeugt in der GEDCOM-Datei Eintr�ge der folgenden
Art:
1 _UID 605276E15320D51191A40080AD040613E141
Dabei besteht der Anspruch, das damit eine "weltweit" eindeutige ID generiert
wurde.
Gru�,
Eckhard
Eckhard Henkel schrieb:
Gerd,
> >Mich würde mal interessieren, ob auch andere Programm so eine eindeutige
Nummer
> >kennung und dann auch exportieren.
>
> Brother's Keeper numeriert alle Personen fortlaufend; die Nummer wird auch
> im .GED File verwendet, z.B. aus BK-Nr. 3917 wird dann 0 @I3917@ INDI.Das macht doch jedes Programm so, das GEDCOM exportiert, oder?
Ich denke, was Jesper meinte, sind EINDEUTIGE IDs.
Das neue Feature von PAF 5 erzeugt in der GEDCOM-Datei Einträge der folgenden
Art:1 _UID 605276E15320D51191A40080AD040613E141
Dabei besteht der Anspruch, das damit eine "weltweit" eindeutige ID generiert
wurde.Gruß,
Eckhard
GEDCOM kennt verschiedene Nummern für Personen:
1. Cross-reference IDs.
Das sind die "@I1234@" Nummern. Der GEDCOM Standard sieht hierfür
NICHT vor, daß diese numerisch sein müssen. Daß viele Programme hier
mit @I1@ oder @I0001@ oder ähnlich beginnen und dann fortlaufend
numerieren ist Zufall. Genaugenommen könnte da auch @FREDFEUERSTEIN@
stehen, solange kein anderer Datensatz diese Kennung besitzt. Diese
Nummern dienen innerhalb der Gedcoms der Zuordnung beispielsweise
von Familien zu Personen. Einen Nutzwert für den Anwender haben diese
Nummern nicht - jedenfalls nicht programmübergreifend. Zudem erzeugt
jedes mir bekannte Programm diese Nummern beim speichern neu, so daß
Löschungen die Nummern der folgenden Personen verändern.
2. Der IDNO tag
Personen können ID-Nummern gegeben werden. Diese sind lt. GEDCOM für
offizielle Nummern (beispielsweise Personalausweis etc.) vorgesehen.
Hier ist aber auch Platz für eigene Numerungen. Nicht alle Programme
unterstützen jedoch den IDNO-Tag.
3. Der _UID tag
PAF5 führt diese "Unique Record Identifiers" ein. Diese sind mit
einer extrem hohen Wahrscheinlichkeit weltweit eindeutig für einen
Datensatz. Außer PAF5 unterstützt meines Erachtens nur Ages! ab
V1.20 diesen Tag. Für eine benutzer-definierte Datensatznummer sollte
diese BITTE NICHT benutzt werden, da sie dann mit Sicherheit nicht
weltweit eindeutig ist!
Mit freundlichem Gruß
Jörn Daub
Hallo Eckhard Henkel,
zur Mail vom Wed, 15 Aug 2001 18:49:46 +0200:
1 _UID 605276E15320D51191A40080AD040613E141
'tschuldigung, das hatte ich nicht kapiert.
Gru�
Gerd
Hallo Herr Zedlitz,
in welchem Scope eindeutig ?
weltweit, pro Programm, pro Datenbank , pro Ahnenforscher oder pro GEDCOM-Export-Vorgang ?
DYNAS-TREE führt eine unique numerische dezimale monoton aufsteigende Ident Nr. die nach dem Löschen nicht für neue Personen wiederverwendet wird.
Diese Ident (und die Äquivalente für Familien, Dokumente o.Ä.) wird beim GEDCOM Export in die entsprechenden Tags eingesetzt.
Beim Import wird neu numeriert, weil ja der berühmte "FRED_FEUERSTEIN", wie andernorts bereits sehr richtig erkannt, drinstehen könnte.
Diese Ident's sind pro Datenbank eindeutig.
Eine weitergehende "Uniqueness von Personennummern" ist nur dann möglich, wenn
a) das Format dieses Identifiers allgemein bekannt ist,
b) entweder jeder Person ein solcher Identifier von einer zentralen Vergabestelle zugeteilt bekommt,
c) oder entweder jeder Programmhersteller oder jeder Ahnenforscher ein Kontingent zugeteilt bekommt.
wobei die Fragen offenbleiben,
wie Duplikate erkannt und "gemappt" werden,
wie ggf. zu verfahren ist, wenn jemand mehrere Programme verwendet,
wie die bisherigen Datenbestände umzunumerieren oder zu ergänzen sind.
ob der Nutzen wirklich die Kosten rechtfertigt, die mit einer solchen Vorgehensweise einhergehen.
_UID kann man in DYNAS-TREE als GEDCOM Tag eines User Event/Fact definieren,
IDNO ebenso und auch
REFN und weitere 197, falls notwendig.
Eine Überprüfung auf formale Richtigkeit und Uniqueness findet aber nicht statt.
Gerhard Bauch
Autor von DYNAS-TREE
http://www.dynas-tree.de
P.S.
DYNAS-TREE kann im übrigen (als erstes Genealogieprogramm der Welt ?) eine Datei nach dem
XML/GedML Standard von Michael Kay erstellen.
Näheres auf unserer Homepage.
J�rn,
sch�nen Dank, dass Du die unterschiedlichen ID-Kategorien
"auseinandergepfl�ckt" hast.
Ich will mal mit meinen Worten die Dinge kommentieren - entweder sehe ich die
Dinge in gleicher Sichtweise aber mit anderen Worten oder ich erhoffe mir
konstruktiven Widerspruch.
1. Cross-reference IDs.
Das sind die "@I1234@" Nummern. Der GEDCOM Standard sieht hierf�r
NICHT vor, da� diese numerisch sein m�ssen. Da� viele Programme hier
mit @I1@ oder @I0001@ oder �hnlich beginnen und dann fortlaufend
numerieren ist Zufall. Genaugenommen k�nnte da auch @FREDFEUERSTEIN@
stehen, solange kein anderer Datensatz diese Kennung besitzt. Diese
Nummern dienen innerhalb der Gedcoms der Zuordnung beispielsweise
von Familien zu Personen. Einen Nutzwert f�r den Anwender haben diese
Nummern nicht - jedenfalls nicht programm�bergreifend. Zudem erzeugt
jedes mir bekannte Programm diese Nummern beim speichern neu, so da�
L�schungen die Nummern der folgenden Personen ver�ndern.
Diese Programm-interne Numerierung ist notwendig und wichtig, aber wie Du
sagst: Programm-intern.
Solange man sich innerhalb eines Programms bewegt, sind die Nummern eindeutig.
Sobald man aber die Daten exportiert und weiter gibt, verlieren sie ihren
"Wert" - sie dienen bei einem importierenden Programm der Erstellung der
Verkn�pungen.
Nach dem Import wird das importierende Programm eine eigene Meinung haben, wie
die Datens�tze zu organisieren und zu verkn�pfen sind und wie es diese IDs bei
einem Export definieren wird.
Die "Cross-reference IDs" sorgen f�r die Integrit�t einer GEDCOM-Datei. Nicht
mehr und nicht weniger.
Sie gew�hrleisten keine Programm- oder Installations-�bergreifende Identit�t
eines Datensatzes.
Selbst wenn 2 Anwender dasselbe Programm benutzen und gegenseitig Daten
austauschen, k�nnen sie sich nicht darauf verlassen, dass sie ein-und-dieselbe
Person anhand dieser Nummer identifizieren.
Genau diese Problem scheint mir der Anla� gewesen zu sein, dass die Entwickler
von PAF das Konzept des "_UID"-tags eingef�hrt haben.
2. Der IDNO tag
Personen k�nnen ID-Nummern gegeben werden. Diese sind lt. GEDCOM f�r
offizielle Nummern (beispielsweise Personalausweis etc.) vorgesehen.
Hier ist aber auch Platz f�r eigene Numerungen. Nicht alle Programme
unterst�tzen jedoch den IDNO-Tag.
Dieser "tag" erscheint mir f�r die weitere Diskussion uninteressant zu sein.
Es ist halt ein wenig spezifizierter "tag" (engl. "tag" = deutsch "Etikett,
Namensschild, Marke, Kennzeichen, Schild, ...), der ganz nach Gusto vom
Anwender gepflegt werden kann.
3. Der _UID tag
PAF5 f�hrt diese "Unique Record Identifiers" ein. Diese sind mit
einer extrem hohen Wahrscheinlichkeit weltweit eindeutig f�r einen
Datensatz. Au�er PAF5 unterst�tzt meines Erachtens nur Ages! ab
V1.20 diesen Tag. F�r eine benutzer-definierte Datensatznummer sollte
diese BITTE NICHT benutzt werden, da sie dann mit Sicherheit nicht
weltweit eindeutig ist!
Ich habe mich jetzt nicht durch die GEDCOM-5.5-Spezifikationen gew�hlt.
Nach meinem Verst�ndnis erlaubt GEDCOM propriet�re "tags", wenn deren Name mit
einem Unterstrich beginnt.
Demnach w�re "_UID" eine m�gliche Variante der Spezifikation - mit der Freiheit
des Programms, diesen selbstdefinierten "tag" nach eigenem Geschmack zu
definierien und zu belegen.
Ich lasse mich da gerne eines Besseren belehren.
Nur, wenn dem so sei, wie kann dann Dein "Ages!" in vermeintlich gleichem Sinne
diesen "tag" benutzen?
Ich hoffe, auf einem gedanklichen Irrweg zu sein ...
Gru�,
Eckhard
Hallo Gerd,
>1 _UID 605276E15320D51191A40080AD040613E141
'tschuldigung, das hatte ich nicht kapiert.
Ich mu� mich entschuldigen, das war etwas knapp in's Spiel geworfen worden.
Am besten zitiere ich die Doku von PAF5, Kapitel "Was ist neu?":
*** Zitat Anfang ***
Unverwechselbare Datensatz-Seriennummer.
Das Programm weist jetzt jedem Datensatz in der .paf-Datei eine
unverwechselbare Datensatz-Seriennummer zu.
Wie die Datensatznummer (RIN) hilft die unverwechselbare
Datensatz-Seriennummer, jede Person in der Datenbank erkennen. Anders als die
RIN gibt es jede Datensatz-Seriennummer weltweit jedoch nur einmal. Jede Person
in einer
.paf-Datei unterscheidet sich durch ihre Nummer von jeder anderen Person in
allen anderen .paf-Dateien, die weltweit erstellt werden. Die unverwechselbare
Datensatz-Seriennummer �ndert sich auch nicht, wenn man eine GEDCOM-Datei
exportiert und an andere verschickt. Sie k�nnen also eine GEDCOM-Datei
verschicken, der Betreffende kann sie in Personal Ancestral File importieren,
�nderungen vornehmen, eine neue GEDCOM-Datei erstellen und sie Ihnen
zur�ckschicken.
Mit Hilfe der Funktion Vergleichen/Verschmelzen k�nnen Sie erkennen, welche
Datens�tze Sie urspr�nglich angelegt haben, welche �nderungen vorgenommen
wurden, k�nnen bestimmen, welche Angaben Sie behalten wollen und dann die
Datens�tze verschmelzen. Die unverwechselbare Datensatz-Seriennummer k�nnen Sie
im Fenster Person weder sehen noch bearbeiten."
*** Zitat Ende ***
Die Nummer wird im Programm nicht sichtbar, erst beim GEDCOM-Export sieht man,
dass jeder Personen-Datensatz mit einer solchen Nummer versehen wird.
Das Format ist eine hexadezimale Kodierung von 18 Bytes.
Demnach ergibt sich ein Wertebereich von 0 bis 256 ^ 18 = 2,23 x 10 ^ 43, d.h.
bei dezimaler Darstellung w�re das eine Zahl mit 43 Stellen.
Die Wahrscheinlichkeit, bei "zuf�lliger" Generierung einer Zahl in dieser
Gr��enordnung eine "weltweit eindeutige" Nummer zu erzielen, d�rfte sehr hoch
liegen.
Spannend d�rfte die Frage sein (wie anfangs von Jesper Zedlitz gestellt), ob
andere Programme diese Nummer ("_UID tag") auch unterst�tzen, also bei Import
und Export beibehalten.
Gru�,
Eckhard
in welchem Scope eindeutig ?
weltweit, pro Programm, pro Datenbank , pro Ahnenforscher oder pro
GEDCOM-Export-Vorgang ?
Mir ging es schon um die weltweite Eindeutigkeit, soweit das machbar ist.
Eine weitergehende "Uniqueness von Personennummern" ist nur dann m�glich, wenn
a) das Format dieses Identifiers allgemein bekannt ist,
Daran scheint es momentan zu mangeln, oder hat einer schonmal eine Erkl�rung der
UIDs von PAF5 gefunden? Ich habe jetzt erstmal eine Anfrage an den Support von
PAF5 geschrieben - bin mal gespannt, ob die antworten. W�rde ich dann hier auch
mal weitergeben.
b) entweder jeder Person ein solcher Identifier von einer zentralen
Vergabestelle zugeteilt bekommt,
c) oder entweder jeder Programmhersteller oder jeder Ahnenforscher ein
Kontingent zugeteilt bekommt.
Hier k�nnen die Mormonen hoffentlich erkl�ren, wie sie das machen. Eine andere
M�glichkeit w�re es, sich Nummern von der IANA (Internet address and numbers
authority) geben zu lassen. Theoretisch k�nnte das auch der Verein f�r
Computergenealogie machen, wie haben von der IANA einen eigenen Object-ID-Raum
bekommen.
wobei die Fragen offenbleiben,
wie Duplikate erkannt und "gemappt" werden,
Das ist in der Tat eine interessante Problematik. Die L�sung, die mir jetzt so
spontan einf�llt, ist es vielleicht, da� die Person mehrere UIDs bekommt. Damit
hat man dann jedenfalls eine Zuordnung UID->Person, nicht aber Person->UID. Ist
aber nur eine spontane Idee.
Jesper
Hallo Eckhard Henkel,
zur Mail vom Thu, 16 Aug 2001 08:12:12 +0200:
Am besten zitiere ich die Doku von PAF5, Kapitel "Was ist neu?":
Danke.
Die Wahrscheinlichkeit, bei "zuf�lliger" Generierung einer Zahl in dieser
Gr��enordnung eine "weltweit eindeutige" Nummer zu erzielen, d�rfte sehr hoch
liegen.
Wahrscheinlich ist aber nicht gleich eindeutig - meine n�chste Frage w�re
gewesen, wie die Zahl generiert wird. Eine solche Zufallszahl w�re doch
ziemlich sinnlos? Jede Aussage �ber die �bereinstimmung oder
Nicht-�bereinstimmung der "eindeutigen" Nummern zweier Personendatens�tze
k�nnte falsch sein.
Das ist das Gleiche wie bei nicht korrekten Message-IDs - da k�nnte auch
die falsche Message gecancelt werden... ;-))
Gru�
Gerd
Jörn,
schönen Dank, dass Du die unterschiedlichen ID-Kategorien
"auseinandergepflückt" hast.Ich will mal mit meinen Worten die Dinge kommentieren - entweder sehe ich die
Dinge in gleicher Sichtweise aber mit anderen Worten oder ich erhoffe mir
konstruktiven Widerspruch.> 1. Cross-reference IDs.
>
> Das sind die "@I1234@" Nummern. [... snip]Diese Programm-interne Numerierung ist notwendig und wichtig, aber wie Du
sagst: Programm-intern.Solange man sich innerhalb eines Programms bewegt, sind die Nummern eindeutig.
Sobald man aber die Daten exportiert und weiter gibt, verlieren sie ihren
"Wert" - sie dienen bei einem importierenden Programm der Erstellung der
Verknüpungen.Nach dem Import wird das importierende Programm eine eigene Meinung haben, wie
die Datensätze zu organisieren und zu verknüpfen sind und wie es diese IDs bei
einem Export definieren wird.Die "Cross-reference IDs" sorgen für die Integrität einer GEDCOM-Datei. Nicht
mehr und nicht weniger.Sie gewährleisten keine Programm- oder Installations-übergreifende Identität
eines Datensatzes.Selbst wenn 2 Anwender dasselbe Programm benutzen und gegenseitig Daten
austauschen, können sie sich nicht darauf verlassen, dass sie ein-und-dieselbe
Person anhand dieser Nummer identifizieren.
Absolut korrekt.
Genau diese Problem scheint mir der Anlaß gewesen zu sein, dass die Entwickler
von PAF das Konzept des "_UID"-tags eingeführt haben.
Die Funktion der _UIDs unterscheidet sich von den Cross-reference IDs
insofern, als daß diese nicht Datei-intern eindeutig ist, sondern
weltweit. Man könnte UIDs für Datei-interne aber auch Datei-
übergreifende Querverweise (cross-references) benutzen. Das sieht der
GEDCOM Standard jedoch nicht vor. Daher bleibt es bei der
Unterscheidung zwischen den GEDCOM-Kompatiblen Cross-reference IDs,
und der GEDCOM-Erweiterung _UID.
> 2. Der IDNO tag
> Personen können ID-Nummern gegeben werden. [... snip]
Dieser "tag" erscheint mir für die weitere Diskussion uninteressant zu sein.
Es ist halt ein wenig spezifizierter "tag" (engl. "tag" = deutsch "Etikett,
Namensschild, Marke, Kennzeichen, Schild, ...), der ganz nach Gusto vom
Anwender gepflegt werden kann.
Sofern diese diskussion auf UIDs zielt, ist das richtig. ID-Nummern
können ja frei vergeben werden, und müssen sogar innerhalb einder Datei
nicht notwendiger Weise eindeutig sein.
> 3. Der _UID tag
>
> PAF5 führt diese "Unique Record Identifiers" ein. Diese sind mit
> einer extrem hohen Wahrscheinlichkeit weltweit eindeutig für einen
> Datensatz. Außer PAF5 unterstützt meines Erachtens nur Ages! ab
> V1.20 diesen Tag. Für eine benutzer-definierte Datensatznummer sollte
> diese BITTE NICHT benutzt werden, da sie dann mit Sicherheit nicht
> weltweit eindeutig ist!Ich habe mich jetzt nicht durch die GEDCOM-5.5-Spezifikationen gewühlt.
Nach meinem Verständnis erlaubt GEDCOM proprietäre "tags", wenn deren Name mit
einem Unterstrich beginnt.Demnach wäre "_UID" eine mögliche Variante der Spezifikation - mit der Freiheit
des Programms, diesen selbstdefinierten "tag" nach eigenem Geschmack zu
definierien und zu belegen.Ich lasse mich da gerne eines Besseren belehren.
Das ist korrekt. Alle GEDCOM-Tags, die mit "_" beginnen sind
programmspezifische Erweiterungen. Was natürlich einen anderen
Programmierer nicht davon abhalten muß, diese mit einzulesen, und
auszuwerten.
Fast alle Programme tun dies auch in der einen oder anderen Form.
Beispielsweise werten einige Programme die "_MSTAT"-Tags aus, obwohl
der GEDCOM-Standard dazu nichts aussagt.
Nur, wenn dem so sei, wie kann dann Dein "Ages!" in vermeintlich gleichem Sinne
diesen "tag" benutzen?Ich hoffe, auf einem gedanklichen Irrweg zu sein ...
Gruß,
Eckhard
Ich zitiere jetzt einmal aus Deiner anderen Mail:
*** Zitat Anfang ***
Unverwechselbare Datensatz-Seriennummer.
Das Programm weist jetzt jedem Datensatz in der .paf-Datei eine
unverwechselbare Datensatz-Seriennummer zu.
Wie die Datensatznummer (RIN) hilft die unverwechselbare
Datensatz-Seriennummer, jede Person in der Datenbank erkennen. Anders als die
RIN gibt es jede Datensatz-Seriennummer weltweit jedoch nur einmal. Jede Person
in einer
.paf-Datei unterscheidet sich durch ihre Nummer von jeder anderen Person in
allen anderen .paf-Dateien, die weltweit erstellt werden. Die unverwechselbare
Datensatz-Seriennummer ändert sich auch nicht, wenn man eine GEDCOM-Datei
exportiert und an andere verschickt. Sie können also eine GEDCOM-Datei
verschicken, der Betreffende kann sie in Personal Ancestral File importieren,
Änderungen vornehmen, eine neue GEDCOM-Datei erstellen und sie Ihnen
zurückschicken.
Mit Hilfe der Funktion Vergleichen/Verschmelzen können Sie erkennen, welche
Datensätze Sie ursprünglich angelegt haben, welche Änderungen vorgenommen
wurden, können bestimmen, welche Angaben Sie behalten wollen und dann die
Datensätze verschmelzen. Die unverwechselbare Datensatz-Seriennummer können Sie
im Fenster Person weder sehen noch bearbeiten."*** Zitat Ende ***
Die Nummer wird im Programm nicht sichtbar, erst beim GEDCOM-Export sieht man,
dass jeder Personen-Datensatz mit einer solchen Nummer versehen wird.
Daß die Nummer nicht sichtbar ist, ist PAF-spezifisch. Allerdings
zeigt auch "Ages!" diese nicht am Bildschirm an. Ein Nutzwert durch
dessen Anzeige ist aber auch nicht zu erzielen.
Das Format ist eine hexadezimale Kodierung von 18 Bytes.
Demnach ergibt sich ein Wertebereich von 0 bis 256 ^ 18 = 2,23 x 10 ^ 43, d.h.
bei dezimaler Darstellung wäre das eine Zahl mit 43 Stellen.
Korrekt.
Die Wahrscheinlichkeit, bei "zufälliger" Generierung einer Zahl in dieser
Größenordnung eine "weltweit eindeutige" Nummer zu erzielen, dürfte sehr hoch
liegen.
Die Wahrscheinlichkeit liegt so extrem hoch, daß alle
nicht-Mathematiker einfach davon ausgehen können, daß niemals eine
Nummer doppelt vergeben wird. Die Methoden zur Erzeugung solcher
GUIDs (Globally Unique IDentifiers) sind zudem so ausgearbeitet, daß
dieser statistischen Sicherheit noch eine faktische hinzukommt. Die
Diskussion, wie diese Nummern generiert werden, führt den Anwender
jedoch nicht weiter. Der interessierte Progrmmierer mag sich die
Windows-Dokumentation zu den Funktionen CoCreateGuid() und
UuidCreate() ansehen.
Im Übrigen wird hierfür eine zentrale Vergabestelle genausowenig
gebraucht wie eine eindeutige Nummernzuordnung durch die IANA.
(Genaugenommen wird die IANA doch gebraucht, schließlich fließt
die Hardware-adresse der Ethernetkarte mit in die Berechnung ein,
und dessen Eindeutigkeit wird durch die IANA sichergestellt)
Spannend dürfte die Frage sein (wie anfangs von Jesper Zedlitz gestellt), ob
andere Programme diese Nummer ("_UID tag") auch unterstützen, also bei Import
und Export beibehalten.
Ich kann hierzu nur Aussagen über unser Produkt "Ages!" machen. Es
läßt bestehende _UIDs unverändert, und generiert neue UIDs für neue
Datensätze. Beim Verschmelzen von Personen erzeugt es Datensätze mit
zwei UIDs. Dieses Verfahren ist nach unseren Tests PAF5-kompatibel.
Grüße
Jörn Daub
Hallo Profis,
seit einiger Zeit suche ich nach einer M�glichkeit ein als .rtf Datei
vorliegendes Ortsfamilienbuch so zu formatieren, dass es von einem
Genealogieprogramm eingelesen und dann in GEDCOM umgewandelt wird.
Vielleicht weiss dazu jemand eine L�sung.
Etwas �hnliches ist mir im Ansatz bei PAF 5 mit einem Auszug aus dem IGI
durch herumprobieren gelungen. Weil ich das aber nicht protokolliert habe,
kann ich den Vorgang nicht rekonstruieren.
Falls jemand an der Sache interessiert ist, kann ich den Urprungstext und
die
GEDCOM-Datei in die Liste stellen oder privat zusenden.
Gruss,
Reiner
Reiner Kerp schrieb:
Hallo Profis,
seit einiger Zeit suche ich nach einer Möglichkeit ein als .rtf Datei
vorliegendes Ortsfamilienbuch so zu formatieren, dass es von einem
Genealogieprogramm eingelesen und dann in GEDCOM umgewandelt wird.
Vielleicht weiss dazu jemand eine Lösung.
Das Ganze ist auf keinen Fall einfach. Abhängig von der Art des Buches
kann das mit mehr oder weniger Erfolg gekrönt sein. Grundsätzlich gibt
es eine Reihe von Möglichkeiten hierfür. Für den Nicht-Programmierer
bleibt wahrscheinlich nur folgende:
1. Datei in Word öffnen.
2. Mittels Suchen-Und-Ersetzen bestimmte Formatierungen in
GEDCOM-Tags wandeln
3. Das ganze als "Text" in eine Datei speichern.
4. Ein möglichst toleranten GEDCOM-Importierendes Programm suchen.
Das klingt wild, ist aber möglich. Abhängig vom Inhalt der Liste
können unter Umständen sogar alle Familienverbindungen wieder
hergestellt werden. Dafür benötigen allerdings alle Personen eine
eindeutige Nummer (Womit wir wieder beim Thema wären... 
Etwas Ähnliches ist mir im Ansatz bei PAF 5 mit einem Auszug aus dem IGI
durch herumprobieren gelungen.
Ich weiß nicht, wie das fuktioniert hat, aber einfaches "herumprobieren"
wird das kaum gewesen sein.
Weil ich das aber nicht protokolliert habe,
kann ich den Vorgang nicht rekonstruieren.
Falls jemand an der Sache interessiert ist, kann ich den Urprungstext und
die
GEDCOM-Datei in die Liste stellen oder privat zusenden.
Bitte nicht in die Liste stellen! Es ist wohl nicht sinnvoll, daß
alle die Datei als e-Mail bekommen, wenn nur ein bis zwei sie
brauchen. Zudem weiß ich nicht, ob der Lsitserver überhaupt
Dateianhänge verarbeitet.
Grüße
Jörn Daub