GEDCOM зсередини

Gedcom зсередини

Авторська спроба опису формату GEDCOM

Даний опис зібрано мною з кількох моїх нотаток (оглядів) у темі про формат GEDCOM на форумі GENEO

Посилання на цю тему : http://forum.genoua.name/viewtopic.php?id=8865

Якщо Вам є що додати до мого опису, пишіть у вказану тему, обговоримо та включимо

Теми оглядів:

GEDCOM (від англ. Genealogical Data Communications) - специфікація для обміну генеалогічними даними між різними генеалогічними програмами. GEDCOM був розроблений Церквою Ісуса Христа Святих Останніх Днів для допомоги у генеалогічних дослідженнях. Більшість сучасних генеалогічних комп'ютерних програм підтримує імпорт/експорт даних у форматі GEDCOM .

GEDCOM використовує lineage-linked модель даних. В основі цієї моделі ядром є сім'я чи особистість .

Нижче наведено приклад файлу GEDCOM. Перший стовпець означає рівень вкладеності.

Приклад (sample.ged):

0 HEAD
1 SOUR Reunion
2 VERS V8.0
2 CORP Leister Productions
1 DEST Reunion
1 DATE 11 FEB 2006
1 FILE test
1 GEDC
2 VERS 5.5
1 CHAR MACINTOSH
0 @I1@ INDI
1 NAME Bob /Cox/
1 SEX M
1 FAMS @F1@
1 CHAN
2 DATE 11 FEB 2006
0 @I2@ INDI
1 NAME Joann /Para/
1 SEX F
1 FAMS @F1@
1 CHAN
2 DATE 11 FEB 2006
0 @I3@ INDI
1 NAME Bobby Jo /Cox/
1 SEX M
1 FAMC @F1@
1 CHAN
2 DATE 11 FEB 2006
0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 MARR
1 CHIL @I3@
0 TRLR

Заголовок (HEAD) включає вихідну програму та версію (Reunion, V8.0), версію GEDCOM (5.5) та кодування символів (MACINTOSH).

Особисті записи (INDI) визначають персон Bob Cox (ID 1 - @ I1 @), Joann Para (ID 2) і Bobby Jo Cox (ID 3).

Запис сім'ї (FAM) посилається на чоловіка (HUSB), дружину (WIFE) та дитину (CHIL) за їх ID-номерами.

Версії:
Поточна версія специфікації GEDCOM 5.5 була випущена 12 січня 1996 року. Наступний проект GEDCOM 5.5.1 специфікації був випущений в 1999 році, представляючи дев'ять нових тегів, у тому числі WWW, EMAIL і FACT, і як кодування символів було затверджено UTF-8. Цей проект не був офіційно затверджений, але його положення були прийняті в багатьох програмах генеалогії.

6 грудня 2002 року бета-версію GEDCOM 6.0 випустили для розробників, щоб вони вивчили її та почали впроваджувати у своїх програмах. GEDCOM 6.0 мав бути першою версією, в якій для зберігання даних використовується формат XML, і є зміна кращим кодуванням від ANSEL Юнікод (UNICODE). (Єдине використання Unicode дозволить використання міжнародних кодувань. Приклад зберігання: східно-азіатські імена з оригінальною командою символів, без яких вони могли б бути неясними та мало корисними для генеалогічних та історичних досліджень.)

Специфікації:
Специфікація формату GEDCOM 5.5 (англ.) http://homepages.rootsweb.com/~pmcbride … 5gctoc.htm

Попередня специфікація GEDCOM XML 6.0 (англ.) http://xml.coverpages.org/Gedcom-XMLv60.pdf

Огляди:
Огляд GEDCOM та його використання (англ.) на Енциклопедії генеалогії http://www.eogen.com/GEDCOM
Cyndi's List - GEDCOM (англ.) http://www.cyndislist.com/gedcom.htm

Докладніше: https://ua.wikipedia.org/wiki/GEDCOM

Загальний огляд формату GEDCOM та мої особисті враження про нього

Зайвий раз переконуюсь, що за що б не взялися мормони, вони роблять це якісно.

Як виявилося, формат GEDCOM – теж їхніх рук справа.

Спочатку мені, як людині, знайомій з принципами побудови реляційних баз даних, цей формат здався надлишковим. Із запису персони ("особистості") є посилання на сім'ї (власні сім'ї та сім'я батьків). А з сімей, у свою чергу, є посилання на персони. Начебто б навіщо? Адже це й так можна вирахувати?
Але коли починаєш працювати з таким форматом даних, то виявляється, що це дуже зручно, тому що запросто пірнаєш з будь-якої персони ( INDI ):
- на предків ( FAMC - сім'я батьків), де HASB та WIFE - батько та мати
- на нащадків ( FAMS - сім'я або сім'ї, якщо шлюбів кілька), де ті ж HASB або WIFE - чоловік або дружина, а CHIL - діти
І в свою чергу з будь-якої сім'ї ( FAM ) є посилання на всіх її членів, а також супутні дані по цій сім'ї - дата та місце шлюбу, примітки до шлюбу та посилання на документи. Коротше, з легкістю тиняєшся по персонах, як у себе вдома. ))

Не дивуюсь чому не дуже прижився GEDCOM 6 версії (той, що у "модному" нині форматі XML). Попередній формат (версії 5.5.1) виявився неймовірно простим і вдалим.

Але, насправді, і в цьому форматі не все так добре, як хотілося б.
І насамперед через те, що в GEDCOM не передбачено окремих полів імені та по батькові. Точніше це все (ім'я та по батькові) пишеться в одне поле (тег " GIVN "). Хоча при цьому у стандарті передбачені всякі префікси та суфікси імен та прізвищ, для нас марні.
Є неоднозначність і у полі з тегом " SURN ". Так, це прізвище, але яке? Деякі програми це поле просто ігнорують і всі пишуть у "повне ім'я" ( NAME ). Деякі пишуть туди прізвище під час народження. У цьому одні - як жінок і чоловіків, інші (наприклад ДЖ) лише жінок. А чоловіче прізвище йде в NAME , обрамляючись косими дужками (слешами).

Проте цей стандарт залишається єдиним загальноприйнятим, що найкраще підтверджує, що він вийшов дуже вдалим при всіх його недоліках.

Типи записів у GEDCOM :

Отже, про структуру загалом написано у першому повідомленні цієї теми, яка майже є описом формату з Вікіпедії.
Дещо докладніше напишу ще тут про типи записів у GEDCOM.

Але спочатку ще раз про формат рядка

level + delim + [optional_xref_ID] + tag + [optional_line_value] + terminator,
де
level - число, що позначає рівень (допускається 0,1,2,3)
delim - пробіл
[optional_xref_ID] - ідентифікатор запису, якщо рядок "0"- го рівня. Це значення має бути унікальним, тобто, іншими словами, кожен запис повинен мати унікальний номер
tag - тег, що позначає суть даних. Зазвичай це скорочення з 3-4 букв у верхньому регістрі. Кожен тег (всі вони визначені) розписаний у документації з GEDCOM і не може бути довільним.
[optional_line_value] - Значення (необов'язкове) - Довільний текст
terminator - перевод рядка на нову строку

Як писав вище, буває кілька типів записів.
Кожен запис починається з рядка з нульовим рівнем (перший символ "0").
Записи бувають наступних типів:
HEAD_RECORD - заголовок, як правило містить будь-яку службову інформацію, наприклад, кодування файлу, з якої програми і якої версії вивантажено файл, дата вивантаження і т.д. буд. У принципі, в офіційній документації хедер не називається "записом", а називається "заголовком". Але по суті та формою це один із видів записів.
FAM_RECORD - сім'ї
INDIVIDUAL_RECORD - персони
MULTIMEDIA_RECORD - мультимедіа-контент
NOTE_RECORD - нотатки
REPOSITORY_RECORD - власники джерел
SOURCE_RECORD - джерела
SUBMITTER_RECORD - власник файлу (автор)

Тут доречно зазначети, що формат GEDCOM дуже надмірний. У ньому передбачено безліч можливостей, більшість яких залишилися практично не затребуваними. Це добре видно і за типами записів.
Практично в GED-файлах, які мені траплялися, використовуються 2 типи записів (не рахуючи хедер) - це сім'ї (FAM) та персони (INDI).
Інші типи записів зустрічалися рідко і насправді не були джерелами значної інформації.
Тому і зараз і надалі ми надходитимемо згідно з "принципом Паретто" (який мені завжди дуже подобався) - використовувати 20% можливостей формату для покриття 80% потреб.
Наприклад, у моєму GEDCOM-файлі (який я експортував з Древа життя) використовується 2 типи записів та близько 2-х десятків тегів.
Від них (а також від інших корисних тегів, які я зустрічав у чужих файлах), ми і відштовхуватимемося.

Ще хочу сказати про порядок слідування записів у файлі Gedcom.
В офіційній документації записи сімей (FAM) вказані раніше записи персон (INDI), однак у всіх файлах, які я зустрічав спочатку йшли персони, а потім сім'ї.
Найімовірніше в документації типи записів побудовані в алфавітному порядку (так і є). Але чи можуть записи бути в іншому порядку, я інформації не зустрічав.

Структура записів типу Персона (INDI) та теги, які можна використовувати.

Як і будь-який інший тип запису, запис про персону починається з рядка нульового рівня, в якому міститься тип рядка ( INDI ) та унікальний номер.
Унікальний номер у GEDCOM-файлах завжди обрамляється символами @ (у простолюді - "равлик") і складається з літери та цифри, наприклад нульовий рядок запису з ідентифікатором "3" виглядає так:

0 @I3@ INDI

Як нумеруються записи осіб (як і записи інших типів).
Найчастіше нумерація записів у файлі йде по порядку, хоча мені зустрічалися і винятки. Порядок проходження самих осіб довільний.
Тут і далі я рідше звертатимуся до документації та описуватиму формат не стільки так, як описано в стандарті, а так, як він використовується насправді. Просто автор кожної програми, виконуючи експорт даних у GEDCOM , може трактувати їх по-своєму. Іноді, я так підозрюю, бо не хоче "заморочуватися", іноді сам формат зберігання його даних не дозволяє це зробити по-іншому, а іноді й у стандарті чітко не прописані всі ньюанси.
Тому дивитимемося "як є", а не "як має бути".

У будь-якому випадку, у будь-якому записі INDI від різних програм завжди є дані з тегом NAME . Без імені – нікуди, навіть якщо воно невідоме

Ось приклад мінімально можливого запису персони:

0 @I2618@ INDI

1 NAME Vladlen /LIPOVENKO/

1 SEX M

Це означає, що персону звали Vladlen, прізвище LIPOVENKO, чоловік.
Навіть якщо стать персони невідома, тег SEX (стать) є завжди. Принаймні я не зустрічав іншого.
При персони невідомої статі буде зазначено просто U (вірогідно від Unknown)

1 SEX U

Що таке "1" перед Sex, це означає, що це тег першого рівня. Двійка ("2") означає, що тег другого рівня, і це деталізація інформації першого рівня.

Розглянемо це з прикладу тега BIRT - народження.
Найчастіше цей тег теж є, хоча буває, якщо дата народження персони невідома, то його опускають.
Ось приклад даних про народження:

1 BIRT

2 DATE 5 SEP 2012

Як бачимо, сама дата народження - дані другого рівня, тобто це означає, що це деталізація інформації першого рівня (у разі - народження).

Якщо розглянути інформацію про смерть ( DEAT ), вона матиме схожу структуру, наприклад:

1 DEAT

2 DATE 23 JUN 1848

2 NOTE Umer v Ozerâne, Radomysl', Kiev, Ukraina

3 CONT Žitel' Severinovki Vasil'kovskogo uezda

Тут – смерть – інформація першого рівня, дата смерті – другого, NOTE – примітка, опис, замітка – інформація теж другого рівня, але відноситься до смерті, а CONT – інформація третього рівня, з чого робимо висновок, що це деталізація інформації другого рівня, у даному разі - описи до смерті.

Тут я навів приклад, коли дані наведені у латиниці. Але це зовсім необов'язково.
Вони запросто бувають у будь-якому кодуванні (у тому числі в кирилиці) або навіть в юнікоді ( UTF-8 ).
Інформація про кодування міститься в заголовку файлу.

Які ще є корисні теги у записах типу INDI (персони)?

Одні з найважливіших - це інформація про зв'язки персони, а саме батьків та дітей.
А якщо бути точнішим – то про сім'ї персони.
Є 2 основних типи сім'ї для особи.
Ця сім'я його батьків (де вона була дитиною) - позначаються тегом FAMC
І сім'я (або сім'ї), де він сам був батьком - позначаються тегом FAMS .

Самі записи типу "Сім'я" ми розглянемо пізніше, зараз тільки розберемо, як посилаються персони на свої сім'ї.

Краще відразу наведу приклад персони зі зв'язками, заразом і розглянемо ще кілька нових тегів:

0 @I682@ INDI

1 _UID qTgGBh0yfz

1 NAME Пилип Григор'єв /ЯЦЕНКО/

2 GIVN Пилип Григор'єв

1 SEX M

1 BIRT

2 DATE 1845

2 PLAC Україна, Київська область, Юзефівка

1 FAMC @F393@

1 DEAT

2 DATE 17 SEP 1914

2 PLAC Україна, Київська область, Рокитне

2 CAUS від старості

2 NOTE 435об-436 68 (ош) 1914 09.17/09.18 Юзефівка кр Філіп Гри

3 CONC горіїв ЯЦЕНКО 69 від старості о. І. Дурдуковськ

3 CONC ий з дияконом Фаддеєм Донцем на парафію. цвинтар. Ф.127 Оп.10

3 CONC 79 Д.555 Ч.3 Л.420про-441 Олег 10.2011

1 FAMS @F138@

1 FAMS @F480@

1 FAMS @F712@

1 NOTE 1843-1847 народження в Рокитному немає

2 CONT 1842(1897-55) /

2 CONT PC1850(16)-4

2 CONT 1858-12

2 CONT ІР1866-20

2 CONT Шлюбу немає, перевірити на прізвище Роскокошенко(Роскокоха)

Як бачимо з цього запису, сім'я в якому народився Пилип Григорієв ЯЦЕНКО:

FAMC @F393@

А сімей, у яких він був батьком (з різними дружинами) – три. Ось вони всі:

1 FAMS @F138@

1 FAMS @F480@

1 FAMS @F712@

Ми бачимо нові теги
PLAC - місце, це тег, як правило, другого рівня і означає місце, де сталася подія. Тобто запис:

1 BIRT

2 DATE 1845

2 PLAC Україна, Київська область (Київська губернія), Юзефівка

Означає, що народження було 1845 року в Юзефівці.

А смерть-17.09.1914 - в Рокитному, причина - від старості (тег CAUS )

1 DEAT

2 DATE 17 SEP 1914

2 PLAC Україна, Київська область, Рокитне

2 CAUS від старості

Ми бачимо ще теги CONT і CONC - це продовження інформації, яка почалася в тезі вищого рівня, але не помістилася в рядок або примусове перенесення.
Різниця між цими двома тегами – CONT (від continue) – інформація починається з нового рядка, а CONC (concatenation) – триває попередній рядок (розрив може потрапити на середину слова).

Ще зупинюся на незрозумілому на вигляд тезі

1 _UID qTgGBh0yfz

Як правило, з підкреслення починаються поля користувача. Це можуть бути як поля, які сам визначив користувач (якщо програма дозволяє) або поля програми, які не передбачені стандартом GEDCOM.
В даному випадку – це внутрішній ідентифікатор записів із Древа життя.
Я зустрічав, коли внутрішній ідентифікатор програми є ідентифікатором записів у GEDCOM. Це можливо у випадках, коли такий ідентифікатор числовий (GEDCOM іншого не дозволяє). У такому випадку, як правило, нумерація записів не є послідовною.

Ну і останні теги, які сьогодні розглянемо, це GIVN та SURN

1 NAME Пилип Григор'єв /ЯЦЕНКО/

2 GIVN Пилип Григор'єв

В даному випадку – GIVN це ім'я персони. Причому, оскільки в стандарті GEDCOM не передбачені окремо теги для імені та по батькові (один з головних недоліків формату), ім'я та по батькові розташовані в одному тезі.
З прізвищем ( SURN ) ще складніше.
Наприклад, "Дерево життя" цей тег використовує для позначення прізвища при народженні (дівочому), а для чоловіків цей тег відсутній. Інші програми пишуть туди прізвище незалежно від статі. Причому це може бути як дівоче прізвище, так і прізвище, отримане після одруження.
Ось приклад із ДЖ для жінок:

1 NAME Ганна Францівна /РЕМБЕЦЬКА (МЕДИНСЬКА)/

2 GIVN Ганна Францівна

2 SURN МЕДИНСЬКА

У цьому прикладі прізвище після заміжжя (РЕМБЕЦЬКА) ми бачимо тільки в тезі NAME , тому що в SURN - її дівоче прізвище. Загалом, як бачимо, у цьому питанні "можливі варіанти", що не може тішити.

А деякі програми (наприклад Ahnenblatt ) взагалі обходяться тегом NAME і не використовують ні GIVN ні SURN.

Наприклад, я раніше дуже любив писати варіанти прізвищ, які можуть зустрічатися в однієї персони в різних документах, через слеш, наприклад:

КОНОНЕНКО/ЗІНЧЕНКО
ТКАЧ/МОСКАЛИК/ЛИЧАНЕНКО/ТАРАСЕНКО

Зараз я такого намагаюся уникати, оскільки різні програми можуть витлумачити зайві слеші неправильно.

Ось чому буває важливо знати особливості формату обміну даними – GEDCOM .

В імені (тегах другого рівня) є ще різні суфікси ( NSFX ), префікси ( NPFX ), але так як у слов'ян вони не використовуються, то я їх не розглядатиму.

Про дати в GEDCOM

Спосіб надання дат у форматі GEDCOM - теж важлива та цікава тема

Здавалося б, дата є дата, звичайне поле і що тут може бути особливого. Але в генеалогії ми найчастіше маємо справу з неточними, приблизними, неповними датами. І все це різноманіття треба якось позначити.

Почнемо з найпростішого виду дати- точної дати .

Дата позначається тегом DATE .
Наприклад:

2 DATE 11 FEB 1915

Тут все просто: число, місяць (абревіатура), рік. Хоча є нюанси – за документацією число дати – одна чи дві цифри, тобто до десятого числа має бути одна цифра, після – дві. Але за фактом я зустрічав і такий запис: 02 FEB 1999 Те саме
і з роком 0785 = 785

Якщо не вказано інше, це григоріанська дата нашої ери.

Позначення місяців не викликає труднощів:
JAN = January
FEB = February
MAR = March
APR = April
MAY = May
JUN = June
JUL = July
AUG = August
SEP = September
OCT = October
NOV = November
DEC = December

Якщо дата в відмінному від григоріанського календаря, то додається так званий "Date Escape" і тоді запис, наприклад, виглядає таким чином:

2 DATE @#DJULIAN@ 4 NOV 1828

Як бачимо, позначення є і для григоріанського календаря, але воно не обов'язкове, оскільки григоріанський календар у нас йде за замовчуванням.

Хоч до революції у нас був і юліанський календар, я в ДЖ майже ніколи не ставлю його ознаки (ставив тільки на початку своїх досліджень). Більше того, останнім часом і не рекомендую цього робити іншим. По-перше, це і так зрозуміло, по-друге, дати в смутний до-і пост-революційний час, як показує практика, писали й так приблизно, а по-третє це просто нагромаджує вид запису. Проте треба враховувати, що так роблять не всі, і знати, що існують інші види календаря, потрібно.

Тепер про неточні дати .

Вони бувають декількох видів і записуються так:
ABT <DATE>
CAL <DATE>
EST <DATE>

де абревіатура перед датою характеризує "приблизність" дати або як вона отримана (від слів ABT = About, CAL = Calculated, EST = Estimated)

У Древі життя це перекладено як "Близько", "Розраховано", "Приблизно" або знаком "~" у короткому вигляді.
Грань між цими приблизними датами є суто символічною, тому можна вважати їх одним типом запису дати.
Раз ми заговорили про приблизні дати, то логічно, що в них може бути день, місяць і рік.

Це допускається і у "точному" вигляді запису дати.
Відмінність у тому, що якщо ми пишемо:
DATE 1858,
то мається на увазі, що рік ми знаємо точно, а день і місяць події невідомі
запис же:
DATE ABT 1858
позначає, що рік зазначений приблизно і насправді він може бути іншим.

Допускається, що може бути відсутня будь-яка із складових дати, наприклад:
DATE OCT 1858
DATE 25 ОСT
і навіть
DATE OCT

Але позбавлений сенсу такий запис:
DATE CAL OCT (обчислено - у жовтні невідомо якого дня і року) і в документації вона заборонена, хоча в окремих файлах я її зустрічав, а ми домовилися орієнтуватися не лише на документацію, а й на практику.

Поїхали далі.

Дати - діапазони :

DATE BEF 1858
DATE AFT 15 OCT 1858
DATE BET OCT 1858 AND 1863

Відповідно "До" (від before), "Після" (від after), "Між" (від between)

Хороший вид запису для генеалогії, особливо мені подобається BET , оскільки дозволяє час від часу звужувати діапазони з появою нових відомостей, що зрештою полегшує з певною точністю обчислювати дату події.
Як і інші види записів, може бути повним і неповним, тобто, наприклад:
DATE
BET 1853 AND 1855

Але знову ж таки, є обмеження, продиктовані здоровим глуздом:
записи "DATE AFT 15 APR" (після 15 квітня) або "BET OCT AND 1863" (між жовтнем та 1863 роком) позбавлені сенсу, не треба пояснювати чому.

Ну і про еквіваленти запису дат - два слова. Очевидно, що наступні записи будуть ідентичні за змістом:

1852 = BET 1 JAN 1852 AND 31 DEC 1852
1852 = BET 1 JAN 1852 AND DEC 1852
1852 = BET JAN 1852 AND 31 DEC 1852
1852 = BET JAN 1852 AND DEC 1852
JAN 1920 = BET 1 JAN 1920 AND 31 JAN 1920

Є ще один тип запису дат, який я не зустрічав у документації, але бачив у GEDCOM файлах. Зокрема в GEDCOM від Древа життя :

2 DATE 1853 OR 1855
2 DATE 24 OCT 1770 OR 22 JAN 1771

Тобто, в першому випадку "або 1853 або 1855"
У другому випадку "або 24 жовтня 1770 або 22 січня 1771"

Здавалося б трохи абсурдно, але на практиці таке часто буває, наприклад:
- коли зустрічаються два ідентичні записи про смерть однієї й тієї ж людини
- коли знаходиш записи про події повних тезок і не знаєш яка з них твого пращура
- коли є кілька дітей з однаковими іменами і в події шлюбу не знаєш старший чи молодший одружується
- коли дату по одному джерелу обчислено одну, а по іншому - іншу і яке джерело ближче до істини - невідомо

Хоча в останньому випадку я все-таки віддаю перевагу використанню запису BET (між), тому що насправді істина може виявитися посередині

Ще один вид запису дат, який використовується переважно (а швидше за все - тільки) для подій, це запис типу "Період"

Це коли подія відбувається не певного дня, а протягом деякого часу.
Це може бути служба в армії, навчання в семінарії, ходка на зону, в решті решт :)
Записуються таким чином:

DATE FROM 1877
DATE TO 14 MAY 1977
DATE FROM 3 JUL 1985 TO 18 MAY 1987

Різниця в цих записах у тому, що в перших двох випадках початкова або кінцева дати не визначені (не відомі чи не мають сенсу), а в останній є дата початку та дата закінчення.
Для прикладу першого запису це може бути вихід на пенсію, тобто дата виходу відома, а дати закінчення як такої немає.
Приклад другого запису - перебування в дитбудинку, якщо дитину туди віддали відразу після народження
Ну а третій запис найочевидніший, має початок і закінчення, прикладом для нього взято дати моєї служби в армії :)

От начебто б і все. Хоча ні.

Дата до нашої ери .
Для тих, хто докопав свій родовід до Адама та Єви, мормони передбачили і цей тип запису.
У цьому випадку до року ми додаємо " BC " (before the birth of Christ), наприклад:

2 DATE 4000 BC

І останнє, якщо нічого не забув, тип дати, це довільний текст .
Коли я вперше побачив такий запис у ged-файлі від програми Ahnenblatt , то я вирішив, що розробники вирішили просто не морочитися і для дати надали просте текстове поле. Я побачив такий запис:

2 DATE (після 01.01.1860)

Потім ще:

2 DATE (бл. 1848 (1854))

І наостанок:

2 DATE (старша за Казимира)

Виявилося, що таке припускає стандарт GEDCOM і це "дати-фрази" , в якому сама дата представляє звичайний текст. Цей текст береться в круглі дужки, щоб при аналізі ми розуміли, що він не стандартизований і може містити абсолютно будь-яку інформацію (кожною мовою).

Ось таке непросте уявлення дати в такому звичайному на вигляд тегу DATE

Записи типу "Сім'я" (FAM)

Отже, один із найголовніших видів запису в GEDCOM - Сім'ї: FAM

При всій значущості і важливості даного типу запису (а ці типи запису є в будь-якому файлі GEDCOM ), насправді структура цього запису напрочуд проста.

Не дарма кажуть: Все геніальне – просто.

Запис FAM призначений для зберігання зареєстрованих шлюбів, шлюбів, цивільних, церковних шлюбів, а також будь-якого об'єднання 2 людей, що викликало народження дитини.
Тобто, не тільки класичного розуміння "сім'я"

У записах цього типу не може бути більше одного чоловіка ( HUSB ) та однієї дружини ( WIFE ).
Якщо, наприклад, людина була кілька разів одружена (одружена), то вона буде присутня в декількох записах FAM , а не кілька разів в одному записі "Сім'я".

Структура запису FAM передбачає, що HUSB – це батько, чоловік та WIFE – мати, жінка, дружина.
Переважно, порядок покажчиків нижчестоящих елементів у структурі FAM (дітей CHIL) у хронологічному порядку народження. Хоча відразу обмовлюся, я досить часто зустрічав порушення цієї рекомендації.

Візьмемо простий приклад запису FAM:

0 @ F294 @ FAM
1 HUSB @ I432 @
1 WIFE @ I303 @
1 CHIL @ I433 @
1 CHIL @ I434 @
1 CHIL @ I435 @
1 MARR

З першого погляду – нічого не зрозуміло.
Насправді ми бачимо, що в цій сім'ї є:
Батько (HUSB) – це персона з номером 432
Мати (WIFE) – персона з номером 303
Діти (CHILD) – персони з номерами 433, 434, 435

Решту інформації про надані персони (дату та місце народження, стать, ім'я тощо) ми можемо легко дізнатися, звернувшись до запису персони ( INDI ) за відповідним номером.

Як дізнатися чи одружувалися зазначені персони? Елементарно: по наявності події Шлюб (тег MARR )
У наведеному вище прикладі така подія є, хоча вона не містить додаткових даних. Але цього вже достатньо, щоб зрозуміти, що шлюб зареєстрований у релігійній чи державній установі. Якщо такого тега у FAM немає, значить шлюб ніде не зареєстровано і "сім'я" існує тільки з причини існування спільних дітей. Хоча у житті це може бути міцна та дружня сім'я.

Ось приклад із більш заповненою подією шлюб:

0 @ F304 @ FAM
1 HUSB @ I460 @
1 WIFE @ I467 @
1 CHIL @ I601 @
1 CHIL @ I621 @

1 CHIL @ I622 @
1 CHIL @ I623 @
1 MARR 2 DATE BET 1922 AND 192

NOTE Шлюб із Аггеєм Євменевичем був першим. Після весілля стала п

3 CONC роживати чоловіка в Юзефівці.

3 CONT Вінчання, найімовірніше, відбувалося за місцем проживання

3 CONC нареченої, тобто. у с. Насташка.

Тут ми бачимо всі знайомі нам теги та пояснювати їх немає потреби.

Як вже писав вище, чоловік і дружина мають бути представлені не більше, ніж в одному екземплярі.
Але в сім'ї може бути і одна жінка без чоловіка (наприклад, одинока мати), і один чоловік без дружини (наприклад прийомний батько, але там з'являється тег ADOP , про нього трохи нижче). Але в такому разі (коли є або батько або мати) в сім'ї має бути хоча б одна дитина.
У сім'ї може не бути дітей лише у разі, якщо у наявності чоловік і дружина (бездітна сім'я).
Варіанти: один чоловік, одна дружина, одні діти – виключені.

У сім'ї ще може бути подія SLGS
Це вже суто мормонські події, пояснення якого виконаю за допомогою дослівної цитати з офіційної документації: religious event pertaining to sealing of husband and wife in LDS temple ceremony. Без коментарів.

Та й обіцяна подія усиновлення .
З ним якась свистопляска, яка виникла тому, що у 5-й версії GEDCOM (а потім ще й у 5.4) ця подія змінювала свій формат. У документації цей момент начебто й описаний, але на практиці спостерігається повний розбрід та хитання. Іноді (по-старому) подія усиновлення згадується в сім'ї, тобто сім'я усиновила (а не народила) дитину.
Ймовірно через те, що ситуації бувають різні (дитина від першого шлюбу і усиновлюється тільки одним з батьків), в останній версії GEDCOM подію усиновлення ( ADOP ) перенесли в запис персони ( INDI )
І виглядає вона у загальному випадку так ( Наведу 2 приклади ):

0 @I735@ INDI
1 NAME Павло Кузьмич /ЧЕМЕРІС/
2 GIVN Павло Кузьмич
1 SEX M
1 BIRT
1 ADOP
2 FAMC @F102@
3 ADOP BOTH
1 FAMC @F102@
2 PEDI Adopted
1 DEAT
2 DATE
2 DATE BEF 1941
2 PLAC Україна, Київська область, Велика Бугаївка
2 CAUS від туберкульозу
1 RESI
2 PLAC Україна, Київська область, Велика Бугаївка
1 NOTE Якісь родичі з ним пов'язані Степан та Омелько - по
2 CONC спогадам т.Олі
2 CONT Павла взяли на виховання з дитбудинку

Тут наш інтерес представляє така структура:

1 ADOP
2 FAMC @F102@
3 ADOP BOTH

Яка позначає подію усиновлення, номер сім'ї, де він був усиновлений, і ким усиновлений (BOTH - у даному випадку обома батьками).

Є ще одна, пов'язана з усиновленням, структура:

1 FAMC @F102@
2 PEDI Adopted

Її необхідність я не зовсім розумію

Якщо ми подивимося 102 сім'ю, побачимо ще раз ADOP . Це значення мені також не зрозуміло. Як рудимент начебто.

А ось ще один приклад із цього ж GEDCOM-файлу:

0 @I228@ INDI
1 NAME Алла Георгіївна /ДУХНЕНКО (СМИРНОВА)/
2 GIVN Алла Георгіївна
2 SURN СМИРНОВА
1 SEX F
1 BIRT
2 DATE 31 JUL 1941
1 FAMC @F108@

1 ADOP
2 FAMC @F559@
3 ADOP HUSB
1 FAMC @F559@
2 PEDI Adopted

1 FAMS @F136@

Відмінності від першого - це наявність крім сім'ї, в якій дитину усиновили (F559), ще й сім'ї, в якій дитина народилася (F108). Ну і, мабуть, усиновлював дитину тільки батько:

3 ADOP HUSB

Сім'ї батьків, на які посилається запис:

0 @F108@ FAM
1 HUSB @I468@
1 WIFE @I204@
1 CHIL @I228@
1 MARR

Тут усе стандартно.

І "родина", прийомна:

0 @F559@ FAM
1 HUSB @I96@
1 CHIL @I228@

Тут ми бачимо те, про що я казав: у сім'ї лише один батько – це прийомний батько . Тут ми не спостерігаємо події ADOP
Не виключено, що вона з'являється у повністю прийомній сім'ї, а не окремо створеній, мета якої – показати факт усиновлення. Але це лише припущення.

Мабуть, і все. Якщо ще згадаю, допишу.

Нестандартний стандарт

Нарешті я дописав цей розділ, до якого не доходили у мене руки довгих 8 років

Хоча GEDCOM і є стандартом генеалогічних даних, багато програм привносять до нього свої особливості. Як вже сказано вище, формат дозволяє додавати "користувацькі" поля і багато генеалогічних програм цим користуються при реалізації експорту своїх даних. З високою вірогідністю, коли така програма буде імпортувати файл, яка створила сама ж, то вона "зрозуміє" ці данні і імпортує їх повністю. Але чи зрозуміють інші програми таку "творчість"? З величезною вірогідністю, що ні.

Як зазначалося вище, навіть стандартні поля, такі як прізвище, ім'я можуть писатися у GEDCOM "по-своєму".

По-батькові, яке не передбачено стандартом та розповсюджено у слов'ян, якась програма може додати у ім'я (і більшість роблять саме так). А деякі програми можуть, як це, наприклад реалізовано у GenoPro, дадати свій тег MIDDLE. При чому, хоч це й користувацьке поле (тому що в стандарті його немає), перед ним відсутнє підкреслення, як того вимагає стандарт.

Деякі програми взагалі в інтерфейсі не передбачили по-батькові. А якщо його немає, то і писати в Gedcom вони нічого не будуть. Але з іншого боку, при імпорті з gedcom, де по-батькові є, вони навряд-чи його звідти візьмуть. Бо куди його розмістити?

Схожа ситуація з дівочим прізвищем. У стандарті є одне стандартне поле для прізвища (SURN).

Як же бути з дівочим (при народженні), адже це прізвище в генеалогії має велике значення? Наприклад, "Дерево життя" цей тег використовує для позначення прізвища при народженні (дівочому), а для чоловіків цей тег відсутній. Інші програми пишуть в SURN прізвище незалежно від статі. Для чоловіків то не проблема. А для жінок? Причому, для жінок в SURN може бути як дівоче прізвище, так і прізвище, отримане після одруження.

Деякі програми (наприклад теж ДЖ) пишуть поточне прізвище (а саме прізвище після одруження для жінок) у тег NAME

Ось приклад із ДЖ для жінок:

1 NAME Анна Францівна /РЕМБЕЦЬКА (МЕДИНСЬКА)/

2 GIVN Ганна Францівна

2 SURN МЕДИНСЬКА

У цьому прикладі прізвище після одруження (РЕМБЕЦЬКА) ми бачимо тільки в тезі NAME , тому що в SURN - її дівоче прізвище (МЕДИНСЬКА). Загалом, як бачимо, у цьому питанні "можливі варіанти", що не може тішити.

Деякі програми (наприклад Ahnenblatt ) взагалі обходяться тегом NAME і не використовують ні GIVN ні SURN.

Деякі програми можуть, як це, наприклад реалізовано у FamilyTreeBuilder (FTB), а також в GenoPro, дадати прізвище у жінок після одруження у користувацькі поля. І якщо FTB додало нове поле і розробник дотримався стандарту (додав поле з тегом _MARNM, а як я вже описав вище, підкреслення перед іменем вказує на те, що це користувацьке поле), то GenoPro просто додав своє поле LAST2.

Як бачимо, GenoPro, досить вільно додає не стандартні поля на всі випадки життя. З одного боку, ця програма заповнює прогалини і недоліки стандарту, але чи завжди це на користь? Поки ми користуємося тільки однією програмою, ми цього не помічаємо. Але уявимо, що ми вирішили поміняти програму на іншу. І єдиний спосіб перенести до неї дані - це GEDCOM - файл, який мають розуміти всі. Чи врахує якась одна програма не стандартні теги іншої? Я в цьому не впевнений.

В GedomReport я в різний час її розвитку реалізовував більшість особливостей різних загальновідомих програм. Користувачі мені присилали свої GEDCOM-файли, які вони експортовували з різних програм, я їх "розбирав" на складові і адаптував свою програму під їх "примхи". Чи враховано все? Скоріш за все - ні, тому що програми розвиваються і ніхто не дає гарантії, що в якійсь новій версії кожної з них не буде додано якусь нову "екзотику".

Як же себе застрахувати від втрати даних при переносі даних з однієї програми до іншої?

По-перше, глянути GEDCOM від вашої програми на предмет наявності не стандартних тегів (як вже неодноразово говорив, на початку імені такого поля має бути підкреслення). Якщо такі поля виявлено, то гляньте, що за інформацію таке поле містить. Це не стосується GenoPro, яке додає свої поля без підкреслень.

Як варіант, перевірити всі поля чи входять вони в стандарт. Звісно, це ще складніше, але на кону збереження даних.

Що далі робити, якщо ви знайшли не стандартні поля? Бажано, не писати в них важливої інформації. З великою вірогідністю вона може бути втрачена. Жорстко? Певно що так, але я не бачу іншого виходу.

Взагалі, бажано використовувати якесь обмежену кількість основних полів та не користуватися "екзотикою". Чим менше розповсюджено поле, тем більша вірогідність втрати в таких полях даних.

Є надія, що розробник тієї програми, в яку ви будете імпортувати дані, передбачив різноманіття стандартів і імпортує гедком від інших програм без втрати інформації. Така вірогідність є, і вона не мала.

Але чи буде заморочуватись такий розробник, якщо ви звернетеся до нього з проханням реалізувати коректний імпорт з маловідомої програми? Не впевнений.

Тому ще одна порада - користуйтеся відомими програмами, присутність на ринку яких значна.

Ну і наостанок - яку я програму вважаю такою, яка більше за інших нехтує стандартом? Це, безумовно, GenoPro. У всякому разі, найбільше проблем при обробці Gedcom я мав саме від цієї програми.

Єдине, що "рятує" ситуацію - це те, що програма ця відома. А це - дивіться вище.

Ще один "антилідер" - це Ahnenblatt. І вона не розповсюджена в Україні. Не знаю, чи широко розповсюджена вона за кордоном, якщо - так, то є надія, що такий файл "зрозуміють" інші програми, але якщо не розповсюджена, тоді я би не рекомендував її для роботи.

Врешті, вирішувати вам. Я лише виклав свої знання та роздуми на цю тему, як людина, яка все це перещупала руками і знає з середини про ситуацію з таким нестандартним стандартом GEDCOM.