Главная

Gedcom изнутри

Авторская попытка описания формата GEDCOM

 

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

Ссылка на эту тему: http://forum.genoua.name/viewtopic.php?id=8865

Если Вам есть что добавить к моему описанию, пишите в указанную тему, обсудим и включим

Темы обзоров:

Описание формата GEDCOM в Википедии

Общий обзор формата GEDCOM и мои личные впечатления о нем

Типы записей в GEDCOM

Структура записей типа Персона (INDI)

О датах в GEDCOM

Записи типа Семья (FAM)

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


Описание формата GEDCOM в Википедии  

 

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://ru.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-х десятков тегов.
От них (а также от других полезных тегов, которые я встречал в чужих файлах), мы и будем отталкиваться.

Еще хочу сказать о порядке следования записей.
В официальной документации записи семей (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 (пол) есть всегда. Во всяком случае, я не встречал другого.
При персоне неизвестного пола будет просто

 

1 SEX U

Что такое "1" перед полом, Это значит, что это тег первого уровня. Двойка ("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
В NAME фамилия заключена в косые скобки (слеши) и это накладывает ограничение на использование данного символа в фамилиях. Например, я раньше очень любил писать варианты фамилий, которые могут встречаться у одной персоны в разных документах, через слеш, например: 

 

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

 

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

Вот почему бывает важно знать особенности формата обмена данными - 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

 

"Date Escape" бывают следующие: @#DHEBREW@ | @#DROMAN@ | @#DFRENCH R@ | @#DGREGORIAN@ |
@#DJULIAN@ | @#DUNKNOWN@

 

Как видим, обозначение есть и для григорианского календаря, но оно не обязательно, так как григорианский календарь у нас идет по-умолчанию.

Хоть до революции у нас был и юлианский календарь, я в ДЖ почти никогда не ставлю его признак. Во-первых, это и так понятно, во-вторых, даты в смутное до- и пост-революционное время, как показывает практика, писали все равно достаточно приблизительно, а в третьих это просто нагромождает вид записи. Но, тем не менее, нужно учитывать, что так делают не все, и знать, что существуют другие виды календаря, нужно.

 

Теперь о неточных датах.


Они бывают нескольких видов и записываются так:
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 BET OCT 1853 AND 15 DEC 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

 

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

 

Вот вроде бы и все. Хотя - нет.

 

Дата до нашей эры.
Для тех, кто докопал свою родословную до Адама и Евы, мормоны предусмотрели и этот тип записи.
В этом случае к году мы добавляем "B.C." (before the birth of Christ), например:


2 DATE 4000 B.C.

 

И последний, если ничего не упустил, тип даты, это произвольный текст.
Когда я в первый раз увидел такую запись в 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

 

C первого взгляда - ничего не понятно.
На самом деле мы видим, что в этой семье есть: 
Отец (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 1923
2 PLAC Киевская губерния, Насташка
2 NOTE Брак с Аггеем Евменевичем был первым. После свадьбы стала п
3 CONC роживать у мужа в д. Юзефовке.
3 CONT Венчание, вероятнее всего, происходило по месту жительства 
3 CONC невесты, т.е. в с. Насташка.

 

Здесь мы видим все знакомые нам теги и объяснять их нет необходимости.

Как уже писал выше, муж и жена должны быть представлены не более, чем в одном экземпляре.
Но в семье может быть и одна женщина без мужа (например, мать-одиночка), и один муж без жены (например приемный отец, но там появляется тэг ADOP, о нем чуть ниже). Но в таком случае в семье должен быть хоть один ребенок.
В семье может не быть детей только в том случае, если в наличии муж и жена (бездетная семья).
Варианты: один муж, одна жена, одни дети - исключены.
  
В семье еще может быть событие SLGS 
Это уже чисто мормонские события, объяснение которого выполню с помощью дословной цитаты из официальной документации: A religious event pertaining to the sealing of a husband and wife in an 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 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
HUSB @I96@
1 CHIL @I228@

 

Здесь мы видим то, о чем я говорил: в семье только один отец - это приемный отец. Здесь мы не наблюдаем события ADOP
Не исключено, что оно появляется в полностью приемной семье, а не отдельно созданной, цель которой - показать факт усыновления. Но это только предположение.

Пожалуй и все. Если что еще вспомню, допишу.

 


 

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

Хоть GEDCOM и является стандартом генеалогических данных, очень многие программы привносят в него свои особенности.

Об этом будет следующий обзор