Gedcom изнутри Авторская попытка описания формата GEDCOM |
Данное описание собрано мной из нескольких моих заметок (обзоров) в теме о формате GEDCOM на форуме GENEO Ссылка на эту тему: http://forum.genoua.name/viewtopic.php?id=8865 Если Вам есть что добавить к моему описанию, пишите в указанную тему, обсудим и включим Темы обзоров: Описание формата GEDCOM в Википедии Общий обзор формата GEDCOM и мои личные впечатления о нем Структура записей типа Персона (INDI) |
Описание формата GEDCOM в Википедии
GEDCOM (от англ. Genealogical Data Communications) — спецификация для обмена генеалогическими данными между разными генеалогическими программами. GEDCOM был разработан Церковью Иисуса Христа Святых последних дней для помощи в генеалогических исследованиях. Большинство современных генеалогических компьютерных программ поддерживает импорт/экспорт данных в формате GEDCOM .
GEDCOM использует lineage-linked модель данных. В основе этой модели ядром является семья или личность.
Ниже находится пример файла GEDCOM. Первый
столбец обозначает уровень вложенности.
Пример (sample.ged):
Заголовок (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-номерам.
Версии: 6 декабря 2002 года бета-версию GEDCOM 6.0 выпустили для разработчиков, чтобы они изучили её и начали внедрять в своих программах. GEDCOM 6.0 должен был быть первой версией, в которой для хранения данных используется формат XML, и является изменение предпочтительной кодировкой от ANSEL Юникод (UNICODE). (Единообразное использование Unicode позволит использование международных кодировок. Пример хранения: восточно-азиатские имена с оригинальной командой символов, без которых они могли бы быть неясными и мало полезными для генеалогических и исторических исследований.)
Спецификации:
Обзоры:
Подробнее:
|
Лишний раз убеждаюсь, что за что бы не взялись мормоны, они делают это качественно.
Как оказалось, формат GEDCOM - тоже их рук дело.
Поначалу, мне, как человеку, знакомому с принципами
построения реляционных баз данных, этот формат показался избыточным.
Из записи персоны ("личности") есть ссылки на семьи (собственные семьи и
семья родителей). А из семей в свою очередь, есть ссылки на персоны. Вроде
бы зачем? Ведь это и так можно вычислить? Не удивляюсь почему не очень прижился GEDCOM 6 версии (тот, что в "модном" нынче формате XML). Предыдущий формат (версии 5.5.1) оказался неимоверно прост и удачен. Но, на самом деле, и в этом формате
не все так хорошо, как хотелось-бы. Но тем не менее, этот стандарт остается единственным общепринятым, что лучше всего подтверждает, что он получился весьма удачным при всех его недостатках.
Итак, о структуре в целом написано в
первом сообщении этой темы, которая почти целиком есть описанием формата
из Википедии. Но сначала еще раз о формате строки level + delim + [optional_xref_ID] +
tag + [optional_line_value] + terminator, Как уже писал выше, бывает несколько
типов записей. Здесь уместно заметить, что формат
GEDCOM очень избыточен. В нем предусмотрена масса возможностей,
большинство которых осталось практически не востребованными. Это очень
хорошо видно и по типам записей. Еще хочу сказать о порядке
следования записей.
Структура записей типа Персона (INDI) и теги, которые в ней могут использоваться.
Как и любой другой тип записи,
запись о персоне начинается со строки нулевого уровня, в которой
содержится тип строки (INDI) и уникальный номер. 0 @I3@ INDI Как нумеруются записи персон (как
впрочем, и записи других типов). В любом случае, в любой записи INDI от разных программ всегда есть данные с тегом NAME. Без имени - никуда, даже если оно неизвестно Вот пример минимально возможной записи персоны:
0 @I2618@ INDI 1 NAME Vladlen /LIPOVENKO/ 1 SEX M Это значит, что персону звали
Vladlen, фамилия LIPOVENKO, мужчина.
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 - информация третьего уровня, из чего делаем вывод, что это детализация информации второго уровня, в данном случае - описания к смерти. Здесь я привел пример, когда данные
приведены в латинице. Но это вовсе не обязательно. Какие еще есть полезные теги в записях типа INDI (персоны). Одни из самых важных - это информация о
связях персоны, а именно родителях и детях. Сами записи типа "Семья" мы рассмотрим позже, сейчас только разберем как ссылаются персоны на свои семьи. Лучше сразу приведу пример персоны со связями, заодно и рассмотрим еще несколько новых тегов:
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@ Мы видим новые теги
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 - это продолжение информации, которая
началась в теге более высокого уровня, но не поместилась в строку или был
принудительный перенос. Еще остановлюсь на непонятном с виду теге
1 _UID qTgGBh0yfz Как правило, с подчеркивания начинаются
пользовательские поля. Это могут быть как поля, которые сам определил
пользователь (если программа это позволяет) или поля программы, которые не
предусмотрены стандартом GEDCOM.
Ну и последние теги, которые сегодня рассмотрим, это GIVN и SURN 1 NAME Филипп Григорьев /ЯЦЕНКО/ 2 GIVN Филипп Григорьев В данном случае - GIVN это имя персоны. Причем, так как в
стандарте GEDCOM не предусмотрены
отдельно теги для имени и отчества (один из главных недостатков формата),
то имя и отчество расположены в одном теге.
1 NAME Анна Францевна /РЕМБЕЦКАЯ (МЕДЫНСКАЯ)/ 2 GIVN Анна Францевна 2 SURN МЕДЫНСКАЯ В этом примере фамилию после замужества (РЕМБЕЦКАЯ) мы видим только в теге NAME, так как в SURN - ее девичья фамилия. В общем, как видим, в этом вопросе "возможны варианты", что не может радовать. А некоторые программы (например Ahnenblatt) вообще обходятся тегом NAME и не используют ни GIVN ни SURN
КОНОНЕНКО/ЗИНЧЕНКО
Сейчас я такого стараюсь избегать, так как разные программы могут истолковать лишние слеши неправильно. Вот почему бывает важно знать особенности формата обмена данными - GEDCOM. В имени (тегах второго уровня) есть еще разные суффиксы (NSFX), префиксы (NPFX), но так как у славян они не используются, то я их не буду расписывать.
О датах в GEDCOM Способ предоставления дат в формате GEDCOM - тоже важная и интересная тема
Казалось-бы дата есть дата, обычное поле и что тут может быть особенного. Но в генеалогии мы чаще всего имеем дело с неточными, приблизительными, неполными датами. И все это многообразие нужно как-то обозначить.
Начнем с самого простого вида даты - точной даты. Дата обозначается тегом DATE. Здесь все просто: число, месяц
(аббревиатура), год. Хотя есть нюансы - по документации число даты - одна или две цифры, то есть до
десятого числа должна быть одна цифра, после - две. Но по факту я встречал
и такую запись: 02 FEB 1999 Если не указано другое, то это григорианская дата нашей эры.
Обозначение месяцев не вызывает затруднений: Если дата в отличном от григорианского
календаря, то добавляется, так называемый "Date
Escape" и тогда запись, например выглядит таким образом:
2 DATE @#DJULIAN@ 4 NOV 1828
"Date Escape" бывают следующие: @#DHEBREW@
| @#DROMAN@ | @#DFRENCH R@ | @#DGREGORIAN@ |
Как видим, обозначение есть и для григорианского календаря, но оно не обязательно, так как григорианский календарь у нас идет по-умолчанию. Хоть до революции у нас был и юлианский календарь, я в ДЖ почти никогда не ставлю его признак. Во-первых, это и так понятно, во-вторых, даты в смутное до- и пост-революционное время, как показывает практика, писали все равно достаточно приблизительно, а в третьих это просто нагромождает вид записи. Но, тем не менее, нужно учитывать, что так делают не все, и знать, что существуют другие виды календаря, нужно.
Теперь о неточных датах.
где аббревиатура перед датой характеризует
"приблизительность" даты или каким образом она получена (от слов ABT = About, CAL = Calculated, EST = Estimated)
В Древе жизни это переведено как "Около",
"Рассчитано", "Приблизительно" или знаком "~" в кратком виде. Это допускается и в "точном" виде записи
даты. Допускается, что может отсутствовать любая
из составляющих даты, например: Но лишена смысла такая запись:
Поехали дальше.
Даты -
диапазоны: DATE BEF 1858
Соответственно "До" (от before), "После" (от after), "Между" (от between)
Хороший вид записи для генеалогии,
особенно мне нравится BET, так как
позволяет время от времени сужать диапазоны по мере появления новых
сведений, что в конце концов облегчает с определенной точностью вычислять
дату события. Но опять таки, есть ограничения,
продиктованные здравым смыслом:
Ну и эквиваленты записи дат. Очевидно, что следующие записи будут идентичны по смыслу:
Есть еще один тип записи дат, который я не встречал в документации, но видел в GEDCOM-файлах. В частности в GEDCOM от Древа жизни:
То есть, в первом случае "или 1853 год или
1855"
Казалось бы немного абсурдно, но на
практике такое часто бывает, например:
Хотя в последнем случае я все-таки
предпочитаю использовать запись BET (между), так как на самом деле истина
может оказаться посредине
Еще один вид записи дат, который используется
преимущественно (а скорее всего только) для событий, это запись
типа "Период"
Это когда событие происходит не в определенный день,
а на протяжении некоторого времени.
DATE FROM 1877
Разница в этих записях в том, что в первых двух
случаях начальная или конечная даты не определены (не известны или не
имеют смысла), а в последней есть дата начала и дата окончания.
Вот вроде бы и все. Хотя - нет.
Дата до нашей
эры.
И последний,
если ничего не упустил, тип даты, это произвольный текст.
2 DATE (після 01.01.1860)
Потом еще:
2 DATE (бл. 1848 (1854))
И наконец:
2 DATE (старша за Казимира)
Оказалось, что такое допускает стандарт GEDCOM и это "даты-фразы", в котором сама дата представляет обычный текст. Этот текст берется в круглые скобки, чтобы при анализе мы понимали, что он не стандартизован и может содержать абсолютно любую информацию (на любом языке). Вот такое непростое представление даты в таком обычном с виду теге DATE
Записи типа "Семья" (FAM) Итак, один из самых ключевых видов записи в GEDCOM - Семьи: FAM При всей значимости и важности данного
типа записи (а эти типы записи есть в любом файле GEDCOM), на самом деле структура этой записи на
удивление проста.
Не зря говорят: Все гениальное - просто.
Запись FAM предназначена для хранения
зарегистрированных браков, брачных союзов, гражданских, церковных браков,
а также любое объединения 2 людей, которое вызвало рождение
ребенка.
В записях этого типа не может быть более
одного мужа (HUSB) и одной жены (WIFE).
Структура записи FAM предполагает,
что HUSB - это отец, мужчина
и WIFE - мать, женщина.
Возьмем простой пример записи FAM:
0 @F294@ FAM
C первого взгляда - ничего не понятно. Все остальную информацию о предоставленных персонах (дату и место рождения, пол, имя и т.д.) мы можем легко узнать, обратившись к записи персоны (INDI) по соответствующему номеру. Как узнать сочетались ли браком указанные
персоны? Элементарно: по наличию события Брак (тэг MARR)
Вот пример с более заполненным событием брак:
Здесь мы видим все знакомые нам теги и объяснять их нет необходимости. Как уже писал выше, муж и жена должны быть
представлены не более, чем в одном экземпляре.
Ну и
обещанное событие усыновление.
0 @I735@ INDI
Здесь наш интерес представляет такая
структура:
1 ADOP
Которая обозначает событие усыновление, номер семьи, в которой он был усыновлен, и кем усыновлен (BOTH - в данном случае обоими родителями). Есть еще одна, связанная с усыновлением, структура:
Ее необходимость я не совсем понимаю Если мы посмотрим 102 семью, то увидим еще раз ADOP. Это значение мне тоже не понятно. Как рудимент, вроде. А вот еще один пример из этого же GEDCOM-файла:
0 @I228@ INDI
Отличия от первого - это наличие помимо семьи, в которой ребенка усыновили (F559), еще и семьи, в которой ребенок родился (F108). Ну и как видно, усыновлял ребенка только отец:
Семьи
родителей, на которые ссылается запись: 0 @F108@ FAM
Здесь все стандартно. И "семья", приемная:
0 @F559@ FAM
Здесь мы видим то, о чем я говорил: в
семье только один отец - это приемный
отец. Здесь мы не наблюдаем события ADOP Пожалуй и все. Если что еще вспомню, допишу.
Нестандартный стандарт Хоть GEDCOM и является стандартом генеалогических данных, очень многие программы привносят в него свои особенности.Об этом будет следующий обзор |