Gedcom зсередини
Авторська спроба опису формату GEDCOM
Даний опис зібрано мною з кількох моїх нотаток (оглядів) у темі про формат GEDCOM на форумі GENEO
Посилання на цю тему : http://forum.genoua.name/viewtopic.php?id=8865
Якщо Вам є що додати до мого опису, пишіть у вказану тему, обговоримо та включимо
Теми оглядів:
Опис
формату 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
Поточна версія специфікації
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 дозволить використання міжнародних кодувань.
Приклад зберігання: східно-азіатські імена з оригінальною командою
символів, без яких вони могли б бути неясними та мало корисними для
генеалогічних та історичних досліджень). Але ця версія не отримала
широкого використання і поширення, і врешті "померла".
<tag>data</tag>).
Старі програми, які читали звичайні рядкові файли GEDCOM, взагалі не
розуміли цей код.
Як наслідок
того, що XML-версія не отримала практичного поширення, 2 жовтня 2019
року, з'явилася версія GEDCOM 5.5.5. Фактично, це ревізія
версії 5.5.1, яка була на той момент стандартом "де-факто".
Версія GEDCOM 5.5.5 (2019 рік) — це не глобальне оновлення з
новими функціями, а скоріше «ремонтна» версія, створена для очищення та
спрощення старого стандарту 5.5.1 (який був основним з 1999 року).
Основні відмінності від версії 5.5.1:
Підсумок: GEDCOM 5.5.5 — це сучасніша, чистіша версія без зайвого «сміття» минулого, яка краще працює з різними мовами завдяки обов'язковому Unicode.
Які версії Gedcom підтримують основні сучасні генеалогічні програми?
Абсолютно всі підтримують версію 5.5.1 (5.5.5) і тільки деякі, станом на
2025 рік підтримують версію GEDCOM 7.0 або анонсували плани про
таку підтримку.
Чому версія GEDCOM 5.5.1 досі популярна?
Це найбільш стабільна версія, яку «розуміють» всі генеалогічні
інструменти та програми за останні 20 років. Перехід на GEDCOM 7.0
є технічно складним, оскільки ця версія має суттєві архітектурні зміни,
які не завжди сумісні зі старими базами даних.
Що ж таке версія GEDCOM 7.0? Після невдалої спроби перевести
GEDCOM на XML в GEDCOM 6.0, врешті в 2020-2021 році з'явилася
версія GEDCOM 7.0, яка взяла за основу "очищену" GEDCOM
5.5.5 і стала розвиватися саме в напрямку звичайного текстового
файлу, до якого всі звикли, але більш формалізованого.
Що ж такого "революційного" з'явилося у 7.0, порівняно з 5.5.5?
Ось головні стандартні новинки 7.0:
1. Тег SPOU (Spouse — Подружжя)
Раніше в записі особи (INDI) не було прямого
посилання на дружину/чоловіка — лише через сімейний запис (FAM). Тепер у
7.0 можна вказати партнера безпосередньо в картці людини.
2. Тег EXID (External ID)
Це величезний крок вперед. Тепер можна офіційно
посилатися на ID людини в інших базах:
Посилання на запис у Find
A Grave
Раніше для цього кожен розробник вигадував свої теги
(_FSID тощо).
3. Тег UID (Unique ID)
Стандартний 128-бітний ідентифікатор для козаної
особи. Це дозволяє програмам розуміти, що «Іван Петренко» у вашому файлі
і «Іван Петренко» у файлі вашого родича — це одна й та сама людина,
навіть якщо ви змінили йому дату народження.
4. Тег ASSOCIATION (ASSO) — розширено
У 7.0 значно покращили опис неродинних зв'язків.
Тепер можна стандартно вказати:
5. Підтримка декількох мов (LANG)
Тепер для будь-якої події або примітки можна вказати
мову. Це дозволяє створювати мультимовні дерева: наприклад, опис події
українською та англійською в одному файлі.
6. Спеціальні теги для медіа
З'явилися теги для керування тим, як відображати
фото:
7. Фрази (PHRASE)
Це «рятівне коло» для всього, що не влізло в
стандарт. Якщо дата чи подія не вкладається в жорсткі рамки, ви додаєте
PHRASE, де пишете пояснення звичайною мовою, і програма зобов'язана це
прочитати.
Головна відмінність GEDCOM від GEDZIP
полягає в тому, що GEDCOM 5.5.1 та GEDCOM 7.0 — це
лише текстовий файл із даними, тоді як GEDZIP (має розширення
.gdz) — це спеціальний архів, який об'єднує цей файл із вашими
медіафайлами (фото, документи, аудіо) в один пакет.
Ось ключові відмінності від сталої версії 5.5.1:
Комплектність:
Формат файлу:
Версійна залежність:
Безпека:
Специфікація GEDZIP дозволяє застосовувати шифрування
вмісту архіву, що корисно для захисту приватних даних при пересиланні
електронною поштою.
Важливо:
Хоча GEDZIP набагато зручніший для обміну, його
підтримують ще не всі програми.
Специфікації:
Специфікація формату GEDCOM 5.5
(англ.) http://homepages.rootsweb.com/~pmcbride
… 5gctoc.htm
Специфікація GEDCOM XML 6.0
(англ.) http://xml.coverpages.org/Gedcom-XMLv60.pdf
Специфікація GEDCOM 7.0
(англ): https://gedcom.io/specifications/FamilySearchGEDCOMv7.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.
Але спочатку ще раз про формат рядка
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 - теж важлива та цікава тема
Здавалося б, дата є дата, звичайне поле і що тут може бути особливого. Але в генеалогії ми найчастіше маємо справу з неточними, приблизними, неповними датами. І все це різноманіття треба якось позначити.
Почнемо з найпростішого виду дати- точної дати .
Дата
позначається тегом 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 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
Отже, один із найголовніших видів запису в 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.