Стандарт GEDCOM

GEDCOM 5.5.1

Вольный перевод

от prashchur.ru

Вступление

GEDCOM был разработан отделом семейной истории Церкви Иисуса Христа Святых последних дней (LDS Church), чтобы обеспечить гибкий, единообразный формат для обмена компьютеризированными генеалогическими данными. GEDCOM - это аббревиатура от Genealogical Data Communication (передачи генеалогических данных). Его цель - способствовать обмену генеалогической информацией и разработке широкого спектра совместимых программных продуктов для оказания помощи генеалогам, историкам и другим исследователям.

Цель и содержание стандарта GEDCOM

Стандарт GEDCOM - это технический документ, написанный для разработчиков программного обеспечения и технически искушенные пользователи. В нем рассматриваются следующие темы:

Грамматика представления данных GEDCOM
Грамматика, связанная с родословной
Теги GEDCOM, связанные с родословной

Этот документ описывает GEDCOM на двух разных уровнях. В первой главе описывается нижний уровень, известный как формат данных GEDCOM. Это язык представления данных для описания любого вида структурированной информации в последовательном виде. В нем описывается синтаксис и идентификация структурированной информации в целом, но не рассматривается семантическое содержание.

Во второй главе описывается более высокий уровень, известный как GEDCOM form, т. е. как с помощью формата данных GEDCOM описать уже тематические данные. В нашем случае это генеалогические данные. И так как тема(форма) у нас только одна, далее мы не будет разделять эти понятия, а говорить о формате GEDCOM в целом. Формат был разработан для создания на базе него генеалогического программного обеспечения, с возможностью обмена генеалогическими данными.

Цели для версии 5.x

Более ранние версии стандарта GEDCOM были выпущены в октябре 1987 (3.0) и августе 1989

(4.0). Версии 1 и 2 были проектами для общественного обсуждения и не были установлены в качестве стандарта.

Данный документ посвящен версии 5.х и включает в себя описание базовой версии 5.5 и ее расширение 5.5.1, Версия 5.5, в свою очередь, базируется на версии 3.0 и подразумевается, что все программное обеспечение, разработанное по данному стандарту, должно обеспечивать обратную совместимость с версией 3.0 и позволять загружать файл предыдущих версий стандарта.

Глава 1

Грамматика представления данных

Вступление

В этой главе описывается основной язык представления данных GEDCOM.

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

Концепция

GEDCOM представляет из себя базу данных в виде последовательного потока связанных записей. А запись, в свою очередь, представляет последовательность иерархически расположенных тегированных строк переменной длины. Строка всегда содержит номер иерархического уровня, тег и необязательное значение. Строка также может содержать идентификатор перекрестной ссылки или указатель. Строка GEDCOM всегда завершается символом возвратом каретки, перевода строки или любой их комбинацией.

Тег в строке GEDCOM, взятый в его иерархическом контексте, идентифицирует информацию, содержащуюся в строке, в том же смысле, в каком имя поля идентифицирует поле в записи базы данных. Это означает, что данные являются самоопределяющимися. Теги позволяют полю встречаться в записи любое количество раз или не встречаться вообще. Они также позволяют использовать отличающиеся или новые поля, которые будут включены в данные GEDCOM, не внося несовместимости, поскольку принимающая система будет игнорировать данные, которые она не понимает, и обрабатывать только те данные, которые она понимает.

Иерархические отношения обозначаются номером уровня. Подчиненные строки имеют более высокий номер уровня. Иерархия позволяет строке иметь подстроки, которые, в свою очередь, могут иметь свои собственные подстроки и так далее. Строка и ее подстроки образуют контекст или вложение, то есть совокупность информации относящийся непосредственно к одному и тому же. Это иерархическое расположение соответствует естественной иерархии, встречающейся в большинстве структурированных данных.

Серия из одной или нескольких строк представляет собой запись. Начало новой записи обозначается строкой, номер уровня которой равен 0 (нулю).

В дополнение к иерархическим связям, GEDCOM определяет взаимосвязи между записями, которые позволяют записи быть логически связанной с другими записями, не вводя избыточности. Эти отношения представлены двумя дополнительными, но необязательными частями строки: указателем перекрестной ссылки и идентификатором перекрестной ссылки. Указатель перекрестной ссылки "указывает на" связанную запись, которая идентифицируется с помощью требуемого, соответствующего уникальному идентификатору перекрестной ссылки. Идентификатор перекрестной ссылки аналогичен первичному ключу в терминологии реляционных баз данных.

Грамматика

В этой главе определяется грамматика для формата GEDCOM. Грамматика - это набор правил, которые определяют последовательности символов, допустимые для создания строки GEDCOM. Последовательности символов описываются в терминах различных комбинаций элементов (переменных и/или констант). Элементы могут быть описаны в терминах набора других элементов, некоторые из которых выбраны из набора альтернативных элементов. Каждый элемент в определении разделен знаком плюс (+), означающим, что оба элемента требуются. Когда есть выбор из различных элементов, которые можно использовать, набор альтернатив перечисляется между открывающими и закрывающими квадратными скобками ([]), причем каждый выбор разделен вертикальной чертой ([альтернатива_1 | альтернатива_2]). Когда отображается только одна альтернатива, то выбор необязателен, то есть он такой же, как [alternative_1 | <NULL>]. Пользователь может прочитать грамматические компоненты выбранного элемента, подставляя любые подэлементы до тех пор, пока все подэлементы не будут разрешены.

Передача GEDCOM состоит из последовательности логических записей, каждая из которых состоит из последовательность строк gedcom_lines, все они содержатся в последовательном файле или потоке символов. Следующие правила относятся к gedcom_line:

Грамматические правила

Длинные значения могут быть разбиты на более короткие строки GEDCOM с помощью подчиненного тега CONC или CONT. Тег CONC предполагает, что сопутствующее подчиненное значение объединено с предыдущим значением строки без сохранения возврата каретки перед ограничителем строки. Если объединенная строка прерывается пробелом, то пробел должен быть перенесен на следующую строку. CONT предполагает, что значение подчиненной строки объединено с предыдущей строкой после вставки возврата каретки.
Начало новой логической записи обозначается строкой, номер уровня которой равен 0 (нулю).
Номера уровней должны быть в диапазоне от 0 до 99 и не должны содержать начальных нулей, например, первый уровень должен быть 1, а не 01.
Номер каждого нового уровня должен быть больше на 1 (единицу) уровня предыдущей строки.
Все строки GEDCOM имеют либо значение, либо указатель, если только строка не содержит подчиненных строк GEDCOM. Строки где есть только номер уровня и тег не должны использоваться для определения данных.
Размеры логических записей GEDCOM должны быть ограничены таким образом, чтобы они помещались в буфер памяти размером менее 32 Кб. Файлы GEDCOM с размерами записей, превышающими 32 Кб, могут быть недоступны для загрузки в некоторых программах. Использование указателей на записи, особенно записи примечаний(NOTE), должно гарантировать, что этого ограничения будет выполняться.
Любые ограничения по длине задаются в символах, а не в байтах. Когда используются многобайтовые кодировки(unicode), длина байтового буфера должна быть скорректирована соответствующим образом.
Идентификатор перекрестной ссылки должен содержать максимум 22 символа, включая заключающие в себя знаки "at" (@), и он должен быть уникальным в рамках одного файла GEDCOM.
Указатели на записи подразумевают, что запись, на которую указывают, действительно присутствует в файле и к ней можно обратиться.
Длина ТЕГА GEDCOM должна составлять максимум 31 символ, причем первые 15 символов являются уникальными.
Общая длина строки GEDCOM, включая номер уровня, номер перекрестной ссылки, тег, значение, разделители и ограничитель, не должна превышать 255 (многобайтовых) символов.
Начальный пробел (табуляции, пробелы и дополнительные разделители строк), предшествующий строке GEDCOM, должен быть проигнорированным системой считывания. Системы, генерирующие GEDCOM, не должны размещать никаких пробелов перед строкой GEDCOM.

Грамматический синтаксис

Строка gedcom_line имеет следующий синтаксис:

gedcom_line:=

level + delim + [xref_ID] + tag + [line_value] + terminator

Где элементы в квадратных скобках являются необязательными и их может не быть. По-русски это выглядит так:

уровень + разделитель + [идентификатор записи] + тег + [значение] + окончание строки

Например:

1 NAME Иван /Иванов/

Компоненты, используемые в приведенном выше шаблоне, определены ниже в алфавитном порядке. Некоторые компоненты определены в терминах других примитивных шаблонов. Пробелы, используемые в приведенных ниже шаблонах, предназначены только для их разделения и не являются частью результирующего шаблона. Символьные константы задаются в шестнадцатеричном формате, например (0x20) соответствует шестнадцатеричному значению ASCII символа пробела. Символьные константы, которые разделены тире (-), представляют любой символ в пределах этого диапазона от первой константы до второй константы включительно.

alpha:= [(0x41)-(0x5A) | (0x61)-(0x7A) | (0x5F)]

где:

(0x41)-(0x5A) = от A до Z

(0x61)-(0x7A) = от a до z

(0x5F)=(_) подчеркивание

alphanum:= [alpha | digit]

any_char := [alpha | digit | otherchar | (0x23) | (0x20) | (0x40)+(0x40)]

где:

(0x23) = #

(0x20) = пробел

(0x40)+(0x40) = @@

delim:= [(0x20)]

где:

(0x20) = пробел

digit:= [(0x30)-(0x39)]

где:

(0x30)-(0x39) = одна из цифр: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

escape:= [(0x40) + (0x23) + escape_text + (0x40) + non_at]

где:

(0x40) = @

(0x23) = #

escape_text:= [any_char | escape_text + any_char]

level:= [digit | digit + digit ]

(Не используйте начальные нули, например: 02)

line_item:= [any_char | escape | line_item + any_char | line_item + escape]

line_value:= [pointer | line_item]

non_at:= [alpha | digit | otherchar | (0x23) | (0x20 )]

где:

(0x20) = пробел

(0x23) = #

null:= ничего

optional_line_value:= delim + line_value

optional_xref_ID:= xref_ID + delim

где:

(0x21)-(0x22) = ! "

(0x24)-(0x2F) = $ % & ' ( ) * +, - . /

(0x3A)-(0x3F) = : ; < = > ?

(0x5B)-(0x5E) = [ \ ] ^

(0x60) = `

(0x7B)-(0x7E) = { | } ~

(0x80)-(0xFE) = символы ANSEL (все что больше кода 127)

Любой 8-битный ASCII символ, кроме управляющих символов (0x00–0x1F), alphanum, пробела ( ), цифр, решетки (#), собачки (@), подчеркивания (_) и сивола DEL (0x7F).

pointer:= [(0x40) + alphanum + pointer_string + (0x40)]

где:

(0x40) = @

pointer_char:= [non_at]

pointer_string:= [null | pointer_char | pointer_string + pointer_char]

tag:= [alphanum | tag + alphanum]

terminator:= [carriage_return | line_feed | carriage_return + line_feed | line_feed + carriage_return]

xref_ID:= [pointer]

Описание грамматических компонентов

alpha:=

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

any_char:=

Любой 8-битный символ ASCII, за исключением управляющих символов, найденных в диапазоне 0x00–0x1F и 0x7F.

delim:=

Разделитель (delimiter), представляющий собой одиночный пробел, завершает как номер уровня переменной длины, так и тег переменной длины. Обратите внимание, что в значении также могут присутствовать символы пробела.

escape:=

Escape - это последовательность символов в грамматике, используемая для указания специальной обработки, например для переключение наборов символов или для указания включения формы данных, отличной от GEDCOM, в структуру GEDCOM. Форма escape-последовательности такова:

@+#+escape_text+@+non_at.

Принимающая сторона(приложение) должна отбрасывать любой символ пробела, который следует за завершающим знаком escape-последовательности (@). Если символ, следующий за закрывающим символом escape-последовательности (@), не является символом пробела, то его следует сохранить как часть текста, следующего за escape. Приложения, пишущие escape-последовательности, всегда должны выводить символ пробела после escape-последовательности.

Конкретный формат escape-последовательности определен для конкретной определяемой форме GEDCOM, т. е. для конкретного случая, когда GEDCOM используют для описания чего-то другого(другой формы).

escape_text:=

escape_text определен таким образом, чтобы соответствовать требованиям конкретной форме GEDCOM.

level:=

Номер уровня работает так, что строка с большим уровенем содержит уточняющую информацию о строке меньшего уровня, образуя таким образом иерархию, где меньший номер всегда находится выше, большего номера уровня. Т.е. строка на любом уровне L относится(подчиняется) и уточняет ближайшую(предыдущую) строку на уровне L-1. Уровень L может увеличиться максимум на 1. Номера уровней не должны содержать начальных нулей, например, первый уровень должен быть равен (1), а не (01).

Считается, что вложенные подчиненные строки на уровне L находятся в контексте вышестоящей строки на уровне L-1. Интерпретация tag(тега) должна быть в контексте tags(тегов) вышестоящей строк(и), которой она подчиняется. Возьмем, к примеру, следующую запись о датах рождения и смерти персоны:

0 INDI

1 BIRT

2 DATE 12 MAY 1920

1 DEAT

2 DATE 1960

В этом примере выражение DATE 12 MAY 1920 интерпретируется в пределах INDI (персона), в контекст BIRT (рождение), представляющий дату рождения персоны. Вторая DATE находится так же в INDI, уже в контексте DEAT (смерть персоны). Смысл DATE зависит от контекста.

Примечание: Приведенный выше пример сделан с отступами в соответствии с номерами уровней, чтобы сделать его более наглядным. В фактических данных GEDCOM номера уровней выстроены вертикально(без отступов), что означает, что они являются первыми символами строки GEDCOM, т. е. приложения должны писать в файл без начальных отступов.

Некоторые приложения выводят данные GEDCOM с отступом для лучшей читаемости, помещая пробел или символы табуляции перед номером уровня следующей строки, чтобы наглядно показать иерархию. Кроме того, некоторые люди предложили разрешить дополнительные пустые строки для видимого разделения физических записей. Файлы GEDCOM, созданные с использованием этих принципов, не должны использоваться при передаче данных GEDCOM в другие приложения.

line_value:=

Значение описывает объект в пределах области возможных значений, разрешенных в контексте тега. Комбинация tag и line_value в иерархическом контексте gedcom_lines обеспечивает понимание вложенных значений.

В значениях, которые содержат неразборчивые части, должны быть произведена замена этой неразборчивой части на многоточие (...).

Значения, как правило, не кодируются в двоичном формате или в других схемах сокращений для уменьшения размера, и они, как правило, должны быть понятными обычному пользователю без декодирования.

line_value в контексте иерархии тегов gedcom_lines представляет одну часть информации и соответствует одному полю в традиционной терминологии базы данных или файла.

otherchar:=

Любой 8-битный символ ASCII, за исключением управляющих символов (0x00–0x1F), alphanum, пробела ( ), знака числа (#), знака at (@) и символа DEL (0x7F).

pointer:=

Указатель(pointer) заменяет саму запись, на ее идентификатор (xref_ID).

Теоретически принимающая сторона должна быть готова найти по указателю соответствующую запись.

Указатель представляет связь между двумя объектами, которые обычно находятся в разных записях. Объекты внутри логической записи могут быть связаны. Если такая необходимость существует, запись указателя содержит восклицательный знак (!), который отделяет перекрестную ссылку родительской записи

Идентификатор из идентификатора перекрестной ссылки конкретной подструктуры, который находится на некотором подчиненном уровне по отношению к логической записи на нулевом уровне. Идентификатор перекрестной ссылки подструктуры, подчиненной записи нулевого уровня, для ассоциаций между записями всегда состоит из идентификационного номера записи и идентификационного номера подструктуры, такого как @I132!1@. Включение идентификационного номера записи в указатель, который связывает объекты внутри записи, позволит процессорам GEDCOM создавать индекс только в уровень записи, а затем последовательно выполните поиск соответствующего идентификатора перекрестной ссылки подструктуры.

Идентификатор родительской записи предполагается, когда идентификатор перекрестной ссылки начинается с восклицательного знака (!), обозначающего ассоциацию внутри записи.

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

Указатель должен соответствовать уникальному идентификатору записи внутри передачи, если только не присутствует символ двоеточия (:) (который будет использоваться в будущем в качестве сетевой ссылки на постоянную файловую запись). Вместо дублирования объекта используется указатель, хотя логический результат эквивалентен. Расширенный обход дерева записей включает в себя прохождение указателя на связанные записи на некоторую глубину и объединение этих записей (логически) в результирующее расширенное дерево. Указатели могут ссылаться либо на записи, которые еще не появились в передаче (прямая ссылка), либо на записи, которые уже появились ранее в передаче (обратная ссылка). Эта схема обычно требует предварительного прохода для создания справочной таблицы для поддержки произвольного доступа по идентификатору записи(xref_ID) во время последующих проходов.

tag:=

Тег состоит из последовательности alphanum символов и имеет переменную длину. Все пользовательские теги, которые не были определены стандартом GEDCOM, должны начинаться с символа подчеркивания «_» (0x95).

Тег является лексической единицей и служит для описания основного смыслового содержания значения line_value в контексте вложенных тегов, так же влияя на смысл значений вложенных(подчиненных) строк. Все теги стандарта GEDCOM определены в Приложение А. Наличие тега вместе со значением представляет собой утверждение, которое отправитель желает сообщить получателю. Тег без значения не представляет утверждение. Если тег отсутствует, утверждение не выполняется. Информация негативного характера (например, положительное знание о том, что событие не произошло) обрабатывается с помощью семантического определения другого тега и сопровождающего его значения, которые явно подтверждают информацию.

Хотя формально теги имеют длину всего три или четыре символа, при написании программ следует подготовиться к обработке пользовательских тегов большей длины. Теги должны быть уникальными в пределах первых 15 символов.

Допустимые комбинации определенных tag-ов, line_values, xref_ID и pointer ограничиваются форматом GEDCOM.

terminator:=

terminator ограничивает значение переменной длины line_value и сигнализирует об окончании строки gedcom_line.

Допустимыми символами-терминаторами являются:

[возврат каретки | перевод строки | возврат каретки + перевод строки | перевод строки + возврат каретки ]

xref_ID:=

Идентификатор записи xref_ID формируется любой произвольной комбинацией символов из набора pointer_char. Первый символ должен быть буквой или цифрой. Программное обеспечение, которое загружает данные GEDCOM, как правило, не сохраняет исходные xref_ID и поэтому они могут быть сформирован из любой удобной комбинации идентификаторов на стороне системы формирующей GEDCOM. Получатель не придает никакого значения какой-либо части внешнего идентификатора, кроме его уникальной ассоциации с соответствующей записью. Использование символа двоеточия (:) также зарезервировано.

Ниже приведены примеры допустимых, но не связанных строк GEDCOM:

0 @1234@ INDI

. . .

1 AGE 13y

. . .

1 CHIL @1234@

. . .

1 NOTE Это поле для заметок, которое

2 CONT продолжено на следующей строке.

Первая строка содержит номер уровня(level) 0, идентификатор записи(xref_ID) @1234@, тег(tag) INDI, при этом какое-либо значение отсутствует.

Вторая строка содержит номер уровня(level) 1, тег(tag) AGE и значение(line_value) 13y, но не содержит идентификатора записи(xref_ID).

Третья строка содержит номер уровня(level) 1, идентификатора записи(xref_ID) отсутствует, тег(tag) CHIL и значение(line_value) в виде указателя(pointer) на идентификатор записи (xref_ID) @1234@.

Четвертый пример состоит из двух строк с номером уровня(level), тегом(tag) и значением(line_value) в виде текста, там нет ни идентификаторов записи(xref_ID), ни указателей(pointer) на них.

Глава 2

Грамматика, связанная с родословной

Введение

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

Форма GEDCOM, связанная с родословной, определённая в этой главе, основана на общей структуре грамматики представления данных GEDCOM, описанной в главе 1. Генеалогическому программному обеспечению предлагается использовать GEDCOM, для обмена данными.

Организация

Базовое описание грамматики формы GEDCOM, связанной с родословной, представлено в

следующих трёх основных разделах:

«Структуры записей формы, связанной с родословной»
«Подструктуры формы, связанной с родословной»
«Первичные элементы формы, связанной с родословной»

Определение тегов, используемых для определения структур, связанных с родословной, содержится в Приложении А.

Символы, используемые в Главе 2

В Главе 2 используются следующие обозначения:

<<двойная_угловая скобка>>

Указывает, что шаблон подчиненной структуры GEDCOM записи, структуры или подструктуры должен быть подставлен вместо строки, содержащей двойные угловые скобки. Заменяющий шаблон структуры находится ниже определения шаблона самой записи, или в алфавитном порядке в разделе «Подструктуры формы, связанной с родословной».

<одинарная_угловая скобка>

Указывает имя соответствующего значения для этой строки GEDCOM — <Primitive>. Конкретное определение этого значения находится в алфавитном порядке в разделе «Первичные элементы формы, связанной с родословной».

{фигурные скобки}

Указывает минимальное и максимальное количество вхождений, допустимое для данной структуры или строки — {Минимум:Максимум}. Обратите внимание, что минимальные и максимальные пределы вхождений определяются относительно внешней верхней строки. Это означает, что обязательная строка (минимум = 1) не требуется, если отсутствует необязательная внешняя верхняя строка. Аналогично, строка, встречающаяся только один раз (максимум = 1), может встречаться несколько раз, при условии, что каждая из них встречается только один раз под своей многократно встречающейся верхней строкой.

[квадратные скобки]

Указывает на выбор одного или нескольких вариантов — [Выбор].

| вертикальная черта |

Разделяет несколько вариантов, например, [Выбор 1 | Выбор 2].

Номер уровня n

Номер уровня, который принимает номер уровня строки, ссылающейся на имя подструктуры.

+1, +2 ...

Номер уровня +1 на 1 больше номера уровня, принимаемого вышестоящим уровнем n. Номер уровня +2 на 2 больше и так далее.

0xHH

Указывает допустимое шестнадцатеричное значение символа, где HH — это значение, например, 0x20 (десятичное 32) обозначает пробел.

Условия использования связанных с генеалогическим древом форм

! Порядок записи строк GEDCOM в файл GEDCOM определяется контекстом и номером уровня. Если строки имеют одинаковый номер уровня, но разные имена тегов, то порядок не имеет значения. Наличие одинаковых номеров уровней и одинаковых тегов в одном контексте подразумевает существование нескольких мнений или нескольких значений данных. Значимость порядка в этих случаях интерпретируется как предпочтение отправителя. Наиболее предпочтительное значение будет первым, а наименее предпочтительные данные будут перечислены в последующих строках в порядке убывания предпочтения. Например, исследователь, обнаруживший противоречивые данные о событии рождения человека,

должен перечислить наиболее достоверную информацию первой, а наименее достоверные или наименее предпочтительные элементы – последней.

Системы, поддерживающие несколько полей или структур, должны позволять пользователям указывать свое мнение о предпочтениях. Системы, хранящие только структуры с одним значением, должны использовать предпочтительную информацию (первое вхождение в списке) и хранить остальную информацию как исключение, предпочтительно в соответствующем поле NOTE или каким-либо другим способом, чтобы пользователь имел легкий доступ к менее предпочтительным данным при просмотре записи.

! Конфликтующие даты и места событий следует представлять, помещая их в отдельные структуры событий с соответствующими ссылками на источники, а не помещая их в одно и то же вложенное событие.

! Форма GEDCOM, связанная с происхождением, использует тег TYPE для классификации своего главного тега для просмотрщика. Значение, заданное тегом TYPE, не предназначено для информирования компьютерной программы о том, как обрабатывать данные, если только не существует списка стандартизированных или контролируемых вариантов line_value, заданного определением line_value в настоящем стандарте. Разница между неконтролируемым значением line и значением note заключается в том, что системы отображения всегда должны отображать значение type при отображении данных из связанного контекста. Это дает пользователю гибкость в дальнейшем определении информации в совместимом контексте GEDCOM, а читателю — возможность понять события или факты, которые не были классифицированы конкретным тегом. Например:

1 EVEN

2 TYPE Awarded BSA Eagle Rank

2 DATE 1980

! Все контролируемые варианты line_value следует считать нечувствительными к регистру. Это означает, что значения должны быть преобразованы в заглавные или строчные буквы перед сравнением. Термины UPPERCASE и UpperCase считаются равными. ТЕГИ всегда ЗАГЛАВНЫЕ.

! Все строки GEDCOM содержат либо значение, либо указатель, если строка не содержит подчиненных строк GEDCOM. Другими словами, наличие только номера уровня и тега не должно использоваться для подтверждения данных (например, 1 DEAT Y следует использовать для обозначения смерти, которая, как известно, произошла, но дата и место неизвестны, а не 1 DEAT). Форма, связанная с происхождением, не допускает наличия строки GEDCOM, содержащей и значение, и указатель на одной строке.

Структуры записей

LINEAGE_LINKED_GEDCOM:=

Это модель структуры GEDCOM, для отправки данных в другие системы обработки GEDCOM. Необходимы заголовок и завершающая запись, которые могут включать любое количество записей данных. Теги из Приложения A должны использоваться в том же контексте, что и показано в следующей форме. Пользовательские теги (см. <NEW_TAG>) не рекомендуются, но при их использовании должны начинаться с подчеркивания. Теги, которые требуются в контексте, выделены жирным шрифтом. Обратите внимание, что некоторые контексты не являются обязательными, но если они используются, то выделенные жирным шрифтом теги обязательны.

0 <<HEADER>> {1:1}

0 <<SUBMISSION_RECORD>> {0:1}

0 <<RECORD>> {1:M}

0 TRLR {1:1}

HEADER:=

n HEAD {1:1}

+1 SOUR <APPROVED_SYSTEM_ID> {1:1}

+2 VERS <VERSION_NUMBER> {0:1}

+2 NAME <NAME_OF_PRODUCT> {0:1}

+2 CORP <NAME_OF_BUSINESS> {0:1}

+3 <<ADDRESS_STRUCTURE>> {0:1}

+2 DATA <NAME_OF_SOURCE_DATA> {0:1}

+3 DATE <PUBLICATION_DATE> {0:1)

+3 COPR <COPYRIGHT_SOURCE_DATA> {0:1)

+4 [CONT|CONC]<COPYRIGHT_SOURCE_DATA> {0:M}

+1 DEST <RECEIVING_SYSTEM_NAME> {0:1}*

+1 DATE <TRANSMISSION_DATE> {0:1}

+2 TIME <TIME_VALUE> {0:1}

+1 SUBM @<XREF:SUBM>@ {1:1}

+1 SUBN @<XREF:SUBN>@ {0:1}

+1 FILE <FILE_NAME> {0:1}

+1 COPR <COPYRIGHT_GEDCOM_FILE> {0:1}

+1 GEDC {1:1}

+2 VERS <VERSION_NUMBER> {1:1}

+2 FORM <GEDCOM_FORM> {1:1}

+1 CHAR <CHARACTER_SET> {1:1}

+2 VERS <VERSION_NUMBER> {0:1}

+1 LANG <LANGUAGE_OF_TEXT> {0:1}

+1 PLAC {0:1}

+2 FORM <PLACE_HIERARCHY> {1:1}

+1 NOTE <GEDCOM_CONTENT_DESCRIPTION> {0:1}

+2 [CONC|CONT] <GEDCOM_CONTENT_DESCRIPTION> {0:M}

* ПРИМЕЧАНИЕ: При отправке файлов в некоторые зарубежные системы, встречается необходимость указывать тег DEST (место назначения).

Структура заголовка содержит информацию обо всей передаче. Имя исходящей системы SOUR (source) определяет, какая система отправила данные. Имя принимающей системы DEST (destination) определяет предполагаемую принимающую систему.

В будущем будут разработаны дополнительные стандарты GEDCOM, отражающие расширение GEDCOM. Для этого программа чтения должна убедиться, что она может читать значения GEDC.VERS и GEDC.FORM, чтобы обеспечить корректную обработку файлов конкретных версия. Тег CHAR обязателен. Все коды символов больше 0x7F должны быть преобразованы в ANSEL. Так как ANSEL на момент создания стандарта являлся самым распространенным набором символов, его и рекомендовали использовать, но время не стоит на месте и на сегодняшний день, проблем с обработкой кодировки unicode быть не должно.

RECORD:=

[

n <<FAM_RECORD>> {1:1}

n <<INDIVIDUAL_RECORD>> {1:1}

n <<MULTIMEDIA_RECORD>> {1:1}

n <<NOTE_RECORD>> {1:1}

n <<REPOSITORY_RECORD>> {1:1}

n <<SOURCE_RECORD>> {1:1}

n <<SUBMITTER_RECORD>> {1:1}

]

FAM_RECORD:=

n @<XREF:FAM>@ FAM {1:1}

+1 RESN <RESTRICTION_NOTICE> {0:1)

+1 <<FAMILY_EVENT_STRUCTURE>> {0:M}

+1 HUSB @<XREF:INDI>@ {0:1}

+1 WIFE @<XREF:INDI>@ {0:1}

+1 CHIL @<XREF:INDI>@ {0:M}

+1 NCHI <COUNT_OF_CHILDREN> {0:1}

+1 SUBM @<XREF:SUBM>@ {0:M}

+1 <<LDS_SPOUSE_SEALING>> {0:M}

+1 REFN <USER_REFERENCE_NUMBER> {0:M}

+2 TYPE <USER_REFERENCE_TYPE> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<CHANGE_DATE>> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<SOURCE_CITATION>> {0:M}

+1 <<MULTIMEDIA_LINK>> {0:M}

Запись FAM(family) используется для регистрации браков, гражданских браков и семейных союзов, образованных двумя людьми, ставшими родителями ребёнка. В каждой записи FAM_RECORD может быть указано не более одного МУЖА/отца и одной ЖЕНЫ/матери. Например, если мужчина участвовал более чем в одном семейном союзе, то он будет указан более чем в одном FAM_RECORD. Структура семейной записи предполагает, что МУЖ/отец — мужчина, а ЖЕНА/мать — женщина.

Предпочтительный порядок указателей CHIL(children) в структуре FAM(family) — хронологический по рождению.

INDIVIDUAL_RECORD:=

n @XREF:INDI@ INDI {1:1}

+1 RESN <RESTRICTION_NOTICE> {0:1}

+1 <<PERSONAL_NAME_STRUCTURE>> {0:M}

+1 SEX <SEX_VALUE> {0:1} p.61

+1 <<INDIVIDUAL_EVENT_STRUCTURE>> {0:M}

+1 <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> {0:M}

+1 <<LDS_INDIVIDUAL_ORDINANCE>> {0:M}

+1 <<CHILD_TO_FAMILY_LINK>> {0:M}

+1 <<SPOUSE_TO_FAMILY_LINK>> {0:M}

+1 SUBM @<XREF:SUBM>@ {0:M}

+1 <<ASSOCIATION_STRUCTURE>> {0:M}

+1 ALIA @<XREF:INDI>@ {0:M}

+1 ANCI @<XREF:SUBM>@ {0:M}

+1 DESI @<XREF:SUBM>@ {0:M}

+1 RFN <PERMANENT_RECORD_FILE_NUMBER> {0:1}

+1 AFN <ANCESTRAL_FILE_NUMBER> {0:1}

+1 REFN <USER_REFERENCE_NUMBER> {0:M}

+2 TYPE <USER_REFERENCE_TYPE> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<CHANGE_DATE>> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<SOURCE_CITATION>> {0:M}

+1 <<MULTIMEDIA_LINK>> {0:M}

Индивидуальная запись представляет собой сборник известных или обнаруженных фактов о человеке. Иногда эти факты получены из разных источников. Эта форма позволяет документировать источник, где каждый из фактов был обнаружен.

Обычные родословные связи отображаются с помощью указателей от человека к семье через тег FAMC или тег FAMS. Тег FAMC предоставляет указатель на семью, где этот человек является ребёнком. Тег FAMS предоставляет указатель на семью, где этот человек является супругом или родителем. Структура <<CHILD_TO_FAMILY_LINK>> содержит указатель FAMC, который необходим для отображения любой связи между ребёнком и родителем для навигации по родословной. Структура <<CHILD_TO_FAMILY_LINK>> также указывает, представляет ли родословная родословную по рождению, по усыновлению или по запечатыванию. Связь между ребёнком и семьёй, к которой он принадлежал на момент события, также может быть показана указателем FAMC, подчинённым соответствующему событию. Например, указатель FAMC, подчинённый событию усыновления, указывает на связь с семьёй через усыновление. Биологические родители могут быть показаны указателем FAMC, подчинённым событию рождения (необязательно).

Другие связи или отношения представлены тегом ASSO(association). Связь или отношение лица является лицом, на которое указывает ссылка. Связь или отношение указывается значением в строке RELA, подчинённой данному событию. Например:

0 @I1@ INDI

1 NAME Fred/Jones/

1 ASSO @I2@

2 RELA Godfather

MULTIMEDIA_RECORD:=

n @XREF:OBJE@ OBJE {1:1}

+1 FILE <MULTIMEDIA_FILE_REFN> {1:M}

+2 FORM <MULTIMEDIA_FORMAT> {1:1}

+3 TYPE <SOURCE_MEDIA_TYPE> {0:1}

+2 TITL <DESCRIPTIVE_TITLE> {0:1}

+1 REFN <USER_REFERENCE_NUMBER> {0:M}

+2 TYPE <USER_REFERENCE_TYPE> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<SOURCE_CITATION>> {0:M}

+1 <<CHANGE_DATE>> {0:1}

Контекст BLOB-объекта мультимедийной записи был удалён в версии 5.5.1. Ссылка на мультимедийный файл была добавлена в структуру записи. Ссылка на файл встречается один раз, чтобы можно было сгруппировать несколько файлов, каждый из которых относится к одному контексту. Например, если вы хотите связать аудиоклип и фотографию, вы должны сослаться на каждый мультимедийный файл и указать формат с помощью тега FORM, подчинённого каждой ссылке на файл.

NOTE_RECORD:=

n @<XREF:NOTE>@ NOTE <SUBMITTER_TEXT> {1:1}

+1 [CONC|CONT] <SUBMITTER_TEXT> {0:M}

+1 REFN <USER_REFERENCE_NUMBER> {0:M}

+2 TYPE <USER_REFERENCE_TYPE> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<SOURCE_CITATION>> {0:M}

+1 <<CHANGE_DATE>> {0:1}

REPOSITORY_RECORD:=

n @<XREF:REPO>@ REPO {1:1}

+1 NAME <NAME_OF_REPOSITORY> {1:1}

+1 <<ADDRESS_STRUCTURE>> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 REFN <USER_REFERENCE_NUMBER> {0:M}

+2 TYPE <USER_REFERENCE_TYPE> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<CHANGE_DATE>> {0:1}

SOURCE_RECORD:=

n @<XREF:SOUR>@ SOUR {1:1}

+1 DATA {0:1}

+2 EVEN <EVENTS_RECORDED> {0:M}

+3 DATE <DATE_PERIOD> {0:1}

+3 PLAC <SOURCE_JURISDICTION_PLACE> {0:1}

+2 AGNC <RESPONSIBLE_AGENCY> {0:1}

+2 <<NOTE_STRUCTURE>> {0:M}

+1 AUTH <SOURCE_ORIGINATOR> {0:1}

+2 [CONC|CONT] <SOURCE_ORIGINATOR> {0:M}

+1 TITL <SOURCE_DESCRIPTIVE_TITLE> {0:1}

+2 [CONC|CONT] <SOURCE_DESCRIPTIVE_TITLE> {0:M}

+1 ABBR <SOURCE_FILED_BY_ENTRY> {0:1}

+1 PUBL <SOURCE_PUBLICATION_FACTS> {0:1}

+2 [CONC|CONT] <SOURCE_PUBLICATION_FACTS> {0:M}

+1 TEXT <TEXT_FROM_SOURCE> {0:1}

+2 [CONC|CONT] <TEXT_FROM_SOURCE> {0:M}

+1 <<SOURCE_REPOSITORY_CITATION>> {0:M}

+1 REFN <USER_REFERENCE_NUMBER> {0:M}

+2 TYPE <USER_REFERENCE_TYPE> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<CHANGE_DATE>> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<MULTIMEDIA_LINK>>

Записи об источниках используются для предоставления библиографического описания цитируемого источника. (См. структуру <<SOURCE_CITATION>>, которая содержит указатель на эту запись об источниках.)

SUBMISSION_RECORD:=

n @XREF:SUBN@ SUBN {1:1}

+1 SUBM @XREF:SUBM@ {0:1}

+1 FAMF <NAME_OF_FAMILY_FILE> {0:1}

+1 TEMP <TEMPLE_CODE> {0:1}

+1 ANCE <GENERATIONS_OF_ANCESTORS> {0:1}

+1 DESC <GENERATIONS_OF_DESCENDANTS> {0:1}

+1 ORDI <ORDINANCE_PROCESS_FLAG> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<CHANGE_DATE>> {0:1}

Отправляющая система использует запись отправки для передачи инструкций и информации принимающей системе. Данная запись используется некоторыми зарубежными системами для дальнейшей маршрутизации пересылки GEDCOM данных. Каждый передаваемый GEDCOM-файл должен иметь только одну запись отправки. Несколько отправок обрабатываются путем создания отдельных файлов передачи GEDCOM.

SUBMITTER_RECORD:=

n @<XREF:SUBM>@ SUBM {1:1}

+1 NAME <SUBMITTER_NAME> {1:1}

+1 <<ADDRESS_STRUCTURE>> {0:1}*

+1 <<MULTIMEDIA_LINK>> {0:M}

+1 LANG <LANGUAGE_PREFERENCE> {0:3}

+1 RFN <SUBMITTER_REGISTERED_RFN> {0:1}

+1 RIN <AUTOMATED_RECORD_ID> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<CHANGE_DATE>> {0:1}

Запись отправителя идентифицирует лицо или организацию, предоставившую информацию, содержащуюся в передаче GEDCOM. Предполагается, что все записи в передаче отправлены

ОТПРАВИТЕЛЕМ, указанным в заголовке, если только ссылка на SUBM (submitter) внутри конкретной записи не указывает на другую запись SUBMITTER.

* Примечание: для отправки в файл предков необходимо указать имя и адрес отправителя.

Подструктуры

ADDRESS_STRUCTURE:=

n ADDR <ADDRESS_LINE> {1:1}

+1 CONT <ADDRESS_LINE> {0:3}

+1 ADR1 <ADDRESS_LINE1> {0:1}

+1 ADR2 <ADDRESS_LINE2> {0:1}

+1 ADR3 <ADDRESS_LINE3> {0:1}

+1 CITY <ADDRESS_CITY> {0:1}

+1 STAE <ADDRESS_STATE> {0:1}

+1 POST <ADDRESS_POSTAL_CODE> {0:1}

+1 CTRY <ADDRESS_COUNTRY> {0:1}

n PHON <PHONE_NUMBER> {0:3}

n EMAIL <ADDRESS_EMAIL> {0:3}

n FAX <ADDRESS_FAX> {0:3}

n WWW <ADDRESS_WEB_PAGE> {0:3}

Структура адреса должна быть сформирована так, как она будет выглядеть на почтовой этикетке, с использованием строк ADDR и CONT. Строки ADDR и CONT обязательны для любого адреса. Дополнительные подчиненные теги адреса, такие как STAE и CTRY, предназначены для использования системами, которые структурировали свои адреса для индексации и сортировки. В целях обратной совместимости эти строки не следует использовать вместо обязательной структуры строк ADDR и CONT.

ASSOCIATION_STRUCTURE:=

n ASSO @<XREF:INDI>@ {1:1} p.25

+1 RELA <RELATION_IS_DESCRIPTOR> {1:1}

+1 <<SOURCE_CITATION>> {0:M}

+1 <<NOTE_STRUCTURE>>

Указатель ассоциации связывает только INDI записи с INDI записями.

CHANGE_DATE:=

n CHAN {1:1}

+1 DATE <CHANGE_DATE> {1:1} p.44

+2 TIME <TIME_VALUE> {0:1} p.63

+1 <<NOTE_STRUCTURE>>

Дата изменения предназначена только для регистрации последнего изменения записи. Некоторые системы могут требовать более подробного управления процессом изменения, но для целей GEDCOM достаточно указать время последнего изменения записи.

CHILD_TO_FAMILY_LINK:=

n FAMC @<XREF:FAM>@ {1:1}

+1 PEDI <PEDIGREE_LINKAGE_TYPE> {0:1}

+1 STAT <CHILD_LINKAGE_STATUS> {0:1}

+1 <<NOTE_STRUCTURE>> {0:M}

EVENT_DETAIL:=

n TYPE <EVENT_OR_FACT_CLASSIFICATION> {0:1}

n DATE <DATE_VALUE> {0:1}

n <<PLACE_STRUCTURE>> {0:1}

n <<ADDRESS_STRUCTURE>> {0:1}

n AGNC <RESPONSIBLE_AGENCY> {0:1}

n RELI <RELIGIOUS_AFFILIATION> {0:1}

n CAUS <CAUSE_OF_EVENT> {0:1}

n RESN <RESTRICTION_NOTICE> {0:1}

n <<NOTE_STRUCTURE>> {0:M}

n <<SOURCE_CITATION>> {0:M}

n <<MULTIMEDIA_LINK>> {0:M}

FAMILY_EVENT_DETAIL:=

n HUSB {0:1}

+1 AGE <AGE_AT_EVENT> {1:1}

n WIFE {0:1}

+1 AGE <AGE_AT_EVENT> {1:1}

n <<EVENT_DETAIL>> {0:1}

FAMILY_EVENT_STRUCTURE:=

[

n [ ANUL | CENS | DIV | DIVF ] {1:1}

+1 <<FAMILY_EVENT_DETAIL>> {0:1}

n [ ENGA | MARB | MARC ] {1:1}

+1 <<FAMILY_EVENT_DETAIL>> {0:1}

n MARR [Y|<NULL>] {1:1}

+1 <<FAMILY_EVENT_DETAIL>> {0:1}

n [ MARL | MARS ] {1:1}

+1 <<FAMILY_EVENT_DETAIL>> {0:1}

n RESI

+1 <<FAMILY_EVENT_DETAIL>> {0:1}

n EVEN [<EVENT_DESCRIPTOR> | <NULL>] {1:1}

+1 <<FAMILY_EVENT_DETAIL>> {0:1}

]

INDIVIDUAL_ATTRIBUTE_STRUCTURE:=

[

n CAST <CASTE_NAME> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n DSCR <PHYSICAL_DESCRIPTION> {1:1}

+1 [CONC | CONT ] <PHYSICAL_DESCRIPTION> {0:M}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n EDUC <SCHOLASTIC_ACHIEVEMENT> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n IDNO <NATIONAL_ID_NUMBER> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n NATI <NATIONAL_OR_TRIBAL_ORIGIN> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n NCHI <COUNT_OF_CHILDREN> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n NMR <COUNT_OF_MARRIAGES> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n OCCU <OCCUPATION> {1:1} p.57

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n PROP <POSSESSIONS> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n RELI <RELIGIOUS_AFFILIATION> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n RESI /* Проживает в */ {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n SSN <SOCIAL_SECURITY_NUMBER> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n TITL <NOBILITY_TYPE_TITLE> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n FACT <ATTRIBUTE_DESCRIPTOR> {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

]

* Примечание: использование тега IDNO или FACT требует использования подчиненного тега TYPE для определения типа определяемого идентификационного номера или классификации факта. Тег TYPE может использоваться с каждым из перечисленных выше тегов, используемых в этой структуре.

INDIVIDUAL_EVENT_DETAIL:=

n <<EVENT_DETAIL>> {1:1}

n AGE <AGE_AT_EVENT> {0:1}

INDIVIDUAL_EVENT_STRUCTURE:=

[

n [ BIRT | CHR ] [Y|<NULL>] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

+1 FAMC @<XREF:FAM>@ {0:1}

n DEAT [Y|<NULL>] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n [ BURI | CREM ] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n ADOP {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

+1 FAMC @<XREF:FAM>@ {0:1}

+2 ADOP <ADOPTED_BY_WHICH_PARENT> {0:1}

n [ BAPM | BARM | BASM | BLES ] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n [ CHRA | CONF | FCOM | ORDN ] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n [ NATU | EMIG | IMMI ] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n [ CENS | PROB | WILL] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n [ GRAD | RETI ] {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

n EVEN {1:1}

+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}*

]

Как правило, события – это события, которые происходят в определённую дату. Используйте форму даты «BET дата AND дата», чтобы указать, что событие произошло в какой-то момент между двумя датами. Не поддавайтесь искушению использовать форму «FROM дата TO дата» в структуре событий. Если объект вашей записи происходил в течение определённого периода времени, то это, вероятно, не событие, а атрибут или факт.

Тег EVEN в этой структуре предназначен для записи общих событий, которые не показаны в приведенной выше <<INDIVIDUAL_EVENT_STRUCTURE>>. Событие, обозначенное этим общим тегом EVEN, определяется значением подчинённого тега TYPE. Например, лицо, подписавшее договор аренды земли от 2 октября 1837 года и договор аренды оборудования от 4 ноября 1837 года, будет записано в GEDCOM следующим образом:

1 EVEN

2 TYPE Land Lease

2 DATE 2 OCT 1837

1 EVEN

2 TYPE Equipment Lease

2 DATE 4 NOV 1837

Тег TYPE можно использовать для изменения базового понимания его главного события или атрибута. Например:

1 GRAD

2 TYPE College

Наступление события подтверждается наличием либо тега и значения DATE, либо тега и значения PLAC (place) в структуре события. Если ни значение даты, ни значение места неизвестны, то для подтверждения того, что событие произошло, требуется значение Y (yes) в строке тега родительского события. Например, каждая из следующих структур GEDCOM подтверждает, что произошла смерть:

1 DEAT Y

1 DEAT

2 DATE 2 OCT 1937

1 DEAT

2 PLAC Cove, Cache, Utah

Использование этого соглашения, в отличие от простого наличия тега, защищает процессоры GEDCOM, которые удаляют (обрезают) строки, не имеющие ни значения, ни подчиненных строк. Это также позволяет прикреплять примечание или источник к контексту события, не подразумевая, что событие произошло.

Использование значения N (no) с тегом события для вывода о том, что событие не произошло, не является корректной формой GEDCOM. Соглашение для обработки событий, которые никогда не происходили, может быть определено в будущем.

LDS_INDIVIDUAL_ORDINANCE:=

[

n [ BAPL | CONL ] {1:1}

+1 DATE <DATE_LDS_ORD> {0:1}

+1 TEMP <TEMPLE_CODE> {0:1}

+1 PLAC <PLACE_LIVING_ORDINANCE> {0:1}

+1 STAT <LDS_BAPTISM_DATE_STATUS> {0:1}

+2 DATE <CHANGE_DATE> {1:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<SOURCE_CITATION>> {0:M}

n ENDL {1:1}

+1 DATE <DATE_LDS_ORD> {0:1}

+1 TEMP <TEMPLE_CODE> {0:1}

+1 PLAC <PLACE_LIVING_ORDINANCE> {0:1}

+1 STAT <LDS_ENDOWMENT_DATE_STATUS> {0:1}

+2 DATE <CHANGE_DATE> {1:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<SOURCE_CITATION>> {0:M}

n SLGC {1:1}

+1 DATE <DATE_LDS_ORD> {0:1}

+1 TEMP <TEMPLE_CODE> {0:1}

+1 PLAC <PLACE_LIVING_ORDINANCE> {0:1}

+1 FAMC @<XREF:FAM>@ {1:1}

+1 STAT <LDS_CHILD_SEALING_DATE_STATUS> {0:1}

+2 DATE <CHANGE_DATE> {1:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<SOURCE_CITATION>> {0:M}

]

LDS_SPOUSE_SEALING:=

n SLGS {1:1}

+1 DATE <DATE_LDS_ORD> {0:1}

+1 TEMP <TEMPLE_CODE> {0:1}

+1 PLAC <PLACE_LIVING_ORDINANCE> {0:1}

+1 STAT <LDS_SPOUSE_SEALING_DATE_STATUS> {0:1}

+2 DATE <CHANGE_DATE> {1:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 <<SOURCE_CITATION>> {0:M}

MULTIMEDIA_LINK:=

n OBJE @<XREF:OBJE>@ {1:1}

n OBJE

+1 FILE <MULTIMEDIA_FILE_REFN> {1:M}

+2 FORM <MULTIMEDIA_FORMAT> {1:1}

+3 MEDI <SOURCE_MEDIA_TYPE> {0:1}

+1 TITL <DESCRIPTIVE_TITLE> {0:1}

Примечание: некоторые системы могут выводить следующую структуру версии GEDCOM 5.5. Новый контекст, представленный выше, был введен для группировки связанных мультимедийных файлов в определенном контексте.

n OBJE

+1 FILE

+1 FORM <MULTIMEDIA_FORMAT>

+2 MEDI <SOURCE_MEDIA_TYPE>

NOTE_STRUCTURE:=

[

n NOTE @<XREF:NOTE>@ {1:1}

n NOTE [<SUBMITTER_TEXT> | <NULL>] {1:1}

+1 [CONC|CONT] <SUBMITTER_TEXT> {0:M}

]

Примечание: При использовании тега CONC необходимо учитывать особые условия. Он используется для создания строки примечания, которую можно объединить, чтобы программа отображения могла самостоятельно выполнять перенос слов в соответствии с размером окна отображения. Необходимо либо разрывать текст в середине слова, либо, если тег находится в конце слова, добавлять пробел в первую строку следующей строки CONC. В противном случае большинство операционных систем удалят конечный пробел, и он будет потерян при восстановлении примечания.

PERSONAL_NAME_PIECES:=

n NPFX <NAME_PIECE_PREFIX> {0:1}

n GIVN <NAME_PIECE_GIVEN> {0:1}

n NICK <NAME_PIECE_NICKNAME> {0:1}

n SPFX <NAME_PIECE_SURNAME_PREFIX {0:1}

n SURN <NAME_PIECE_SURNAME> {0:1}

n NSFX <NAME_PIECE_SUFFIX> {0:1}

n <<NOTE_STRUCTURE>> {0:M}

n <<SOURCE_CITATION>> {0:M}

PERSONAL_NAME_STRUCTURE:=

n NAME <NAME_PERSONAL> {1:1}

+1 TYPE <NAME_TYPE> {0:1}

+1 <<PERSONAL_NAME_PIECES>> {0:1}

+1 FONE <NAME_PHONETIC_VARIATION> {0:M}

+2 TYPE <PHONETIC_TYPE> {1:1}

+2 <<PERSONAL_NAME_PIECES>> {0:1}

+1 ROMN <NAME_ROMANIZED_VARIATION> {0:M}

+2 TYPE <ROMANIZED_TYPE> {1:1}

+2 <<PERSONAL_NAME_PIECES>> {0:1}

Значение имени формируется так, как оно обычно произносится, с именем и фамилией, разделенными слешами (/). (См. <NAME_PERSONAL>) Исходя из динамической природы или неизвестной структуры соглашений об именовании, сложно предоставить более подробную структуру частей имени для обработки каждого случая. Теги NPFX, GIVN, NICK, SPFX, SURN и NSFX предоставляются опционально для систем, которые не могут эффективно работать с менее структурированной информацией. Для обеспечения совместимости в будущем все системы должны формировать свои имена на основе структуры <NAME_PERSONAL>. Те, кто использует необязательные части имени, должны предполагать, что немногие системы будут их обрабатывать, и большинство не будут предоставлять части имени.

Тип имени <NAME_TYPE> используется для указания конкретной вариации этого имени. Например: Если тип имени подчиняется <NAME_PERSONAL>, это может указывать на то, что это имя взято при иммиграции или что это может быть имя «также известное как».

В будущих версиях GEDCOM (6.0 или более поздних), вероятно, будет применена совершенно другая стратегия для решения этой проблемы, возможно, с использованием сложного парсера и базы данных знаний имён.

PLACE_STRUCTURE:=

n PLAC <PLACE_NAME> {1:1}

+1 FORM <PLACE_HIERARCHY> {0:1}

+1 FONE <PLACE_PHONETIC_VARIATION> {0:M}

+2 TYPE <PHONETIC_TYPE> {1:1}

+1 ROMN <PLACE_ROMANIZED_VARIATION> {0:M}

+2 TYPE <ROMANIZED_TYPE> {1:1}

+1 MAP {0:1}

+2 LATI <PLACE_LATITUDE> {1:1}

+2 LONG <PLACE_LONGITUDE> {1:1}

+1 <<NOTE_STRUCTURE>> {0:M}

SOURCE_CITATION:=

[ /* указатель на исходную запись (предпочтительно)*/

n SOUR @<XREF:SOUR>@ {1:1}

+1 PAGE <WHERE_WITHIN_SOURCE> {0:1}

+1 EVEN <EVENT_TYPE_CITED_FROM> {0:1}

+2 ROLE <ROLE_IN_EVENT> {0:1}

+1 DATA {0:1}

+2 DATE <ENTRY_RECORDING_DATE> {0:1}

+2 TEXT <TEXT_FROM_SOURCE> {0:M}

+3 [CONC|CONT] <TEXT_FROM_SOURCE> {0:M}

+1 <<MULTIMEDIA_LINK>> {0:M}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 QUAY <CERTAINTY_ASSESSMENT> {0:1}

| /* Системы, не использующие исходные записи */

n SOUR <SOURCE_DESCRIPTION> {1:1}

+1 [CONC|CONT] <SOURCE_DESCRIPTION> {0:M}

+1 TEXT <TEXT_FROM_SOURCE> {0:M}

+2 [CONC|CONT] <TEXT_FROM_SOURCE> {0:M}

+1 <<MULTIMEDIA_LINK>> {0:M}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 QUAY <CERTAINTY_ASSESSMENT> {0:1}

]

Данные, представленные в структуре <<SOURCE_CITATION>>, представляют собой информацию об источнике, относящуюся к цитируемым данным. Системы, не использующие (SOURCE_RECORD), должны использовать непредпочтительный второй параметр структуры цитирования SOUR. Когда системы, поддерживающие формат записи источника нулевого уровня, встречают ссылку на источник, которая не содержит указателей на записи источника, то эта система должна создать SOURCE_RECORD и сохранить информацию об описании источника, найденную в неструктурированной ссылке на источник, в области заголовка новой записи источника.

Информация, предназначенная для размещения в структуре цитирования, включает:

! Указатель на SOURCE_RECORD, который содержит более общее описание источника, используемого для цитируемого факта.

! Информация, такая как номер страницы, помогающая пользователю найти цитируемые данные в указанном источнике. Эти данные хранятся в контексте тега «.SOUR.PAGE».

! Фактический текст из источника, использованный при формировании утверждений, например, дата, фактически записанная в источнике, или важные заметки, сделанные регистратором, или соответствующее предложение из письма. Эти данные хранятся в контексте тега «.SOUR.DATA.TEXT».

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

- Дата записи в исходном документе хранится в контексте тега «.SOUR.DATA.DATE».

- Тип события, инициировавшего запись, хранится в контексте тега «SOUR.EVEN». Используемое значение — это код события, взятый из таблицы вариантов, показанной в примитиве EVENT_TYPE_CITED_FROM.

— Роль этого человека в событии хранится в контексте ".SOUR.EVEN.ROLE".

SOURCE_REPOSITORY_CITATION:=

n REPO [ @XREF:REPO@ | <NULL>] {1:1}

+1 <<NOTE_STRUCTURE>> {0:M}

+1 CALN <SOURCE_CALL_NUMBER> {0:M}

+2 MEDI <SOURCE_MEDIA_TYPE> {0:1}

Эта структура используется в записи источника для указания имени и адреса владельца исходного документа. Формальные и неформальные имя и адрес репозитория хранятся в REPOSITORY_RECORD. Неформальные репозитории включают владельцев неопубликованных работ или редких опубликованных источников, а также хранителей личных коллекций. Примером может служить владелец семейной Библии, содержащей неопубликованные семейные генеалогические записи. Более формальные репозитории, такие как Библиотека семейной истории, должны указывать идентификационный номер источника в этом репозитории. Идентификационный номер этого источника должен быть записан с помощью подчиненного тега CALN. Системы, не использующие запись имени и адреса репозитория, должны описывать, где хранится цитируемая информация, в поле <<NOTE_STRUCTURE>> структуры цитирования источника REPO (repository).

SPOUSE_TO_FAMILY_LINK:=

n FAMS @<XREF:FAM>@ {1:1}

+1 <<NOTE_STRUCTURE>> {0:M}

Примитивные элементы

Размеры полей показывают минимальную рекомендуемую длину поля в базе данных, которая ограничена полями фиксированной длины. Размеры полей добавляются к уровню GEDCOM и накладным расходам тегов. Строки GEDCOM ограничены 255 символами. Однако теги CONC (concatenation) или CONT (continuation) могут использоваться для расширения поля сверх этого ограничения. Строка CONT подразумевает, что должна появиться новая строка для сохранения форматирования. CONC подразумевает конкатенацию с предыдущей строкой без новой строки. Это используется для того, чтобы текстовая заметка или описание могло быть обработано (с переносом слов) в текстовом окне без фиксированных возвратов каретки. Теги CONT и CONC используются для расширения указанных текстовых значений.

ADDRESS_CITY:= {Size=1:60}

Название города, используемого в адресе. Выделяется для сортировки или индексации.

ADDRESS_COUNTRY:= {Size=1:60}

Название страны, к которой относится связанный адрес. Выделяется некоторыми системами для сортировки или индексации. В большинстве случаев используется для упрощения автоматической сортировки почты.

ADDRESS_EMAIL:= {Size=5:120}

Электронный адрес, который можно использовать для связи, например, адрес электронной почты.

ADDRESS_FAX:= {Size=5:60}

Номер телефона факса, подходящий для отправки факсимильных данных.

ADDRESS_LINE:= {Size=1:60}

Обычно используется для определения почтового адреса физического лица при использовании в качестве подчиненного тега RESI (resident). При использовании в качестве подчиненного тега события это адрес места, где произошло событие. Строки адреса обычно содержат имя получателя и другую информацию об улице и городе, что позволяет сформировать адрес, отвечающий почтовым требованиям.

ADDRESS_LINE1:= {Size=1:60}

Первая строка адреса, используемая для индексации. Это значение строки, соответствующей строке тега ADDR в структуре адреса.

ADDRESS_LINE2:= {Size=1:60}

Вторая строка адреса, используемая для индексации. Это значение первой строки CONT, подчиненной тегу ADDR в структуре адреса.

ADDRESS_LINE3:= {Size=1:60}

Третья строка адреса, используемая для индексации. Это значение второй строки CONT, подчиненной тегу ADDR в структуре адреса.

ADDRESS_POSTAL_CODE:= {Size=1:10}

Почтовый индекс, используемый различными населенными пунктами при обработке почты. Выделяется для сортировки или индексации.

ADDRESS_STATE:= {Size=1:60}

Название штата, используемое в адресе. Выделено для сортировки или индексации.

ADDRESS_WEB_PAGE:= {Size=5:120}

Адрес страницы в Интернете.

ADOPTED_BY_WHICH_PARENT:= {Size=1:4}

[ HUSB | WIFE | BOTH ]

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

Где:

HUSB = Муж в соответствующей семье усыновил данного человека.

WIFE = ЖЕНА в соответствующей семье усыновила данного человека.

BOTH = И муж, и жена усыновили данного человека.

AGE_AT_EVENT:= {Size=1:12}

[ < | > | <NULL>]

[ YYy MMm DDDd | YYy | MMm | DDDd |

YYy MMm | YYy DDDd | MMm DDDd |

CHILD | INFANT | STILLBORN ]

]

Где:

> = больше указанного возраста

< = меньше указанного возраста

y = метка, указывающая количество лет

m = метка, указывающая количество месяцев

d = метка, указывающая количество дней

YY = количество полных лет

MM = количество месяцев

DDD = количество дней

CHILD = возраст < 8 лет

INFANT = возраст < 1 года

STILLBORN = умер непосредственно перед рождением, во время или около 0 лет

Число, указывающее возраст в годах, месяцах и днях, в котором был родитель на момент соответствующего события. Любые метки должны следовать за соответствующим им номером, например: 4y 8m 10d.

ANCESTRAL_FILE_NUMBER:= {Размер=1:12}

Уникальный постоянный номер записи для индивидуальной записи, содержащейся в файле предков Отдела семейной истории(зарубежная система).

APPROVED_SYSTEM_ID:= {Размер=1:20}

Идентификационное имя системы, полученное в процессе регистрации GEDCOM. Это имя должно быть уникальным среди других продуктов. Пробелы в имени должны быть заменены на 0x5F (подчеркивание _), чтобы получилось одно слово.

ATTRIBUTE_DESCRIPTOR:= {Размер=1:90}

Текст, описывающий конкретную характеристику или атрибут, присвоенный человеку. Значение этого атрибута назначается тегу FACT. Классификация этого конкретного атрибута или факта определяется значением подчиненного тега TYPE, выбранного из структуры EVENT_DETAIL. Например, если вы классифицируете навыки, полученные человеком;

1 FACT Деревообработка

2 TYPE Навыки

ATTRIBUTE_TYPE:= {Размер=1:4}

Атрибут, который мог быть причиной записи имени, адресов, номеров телефонов и семейных списков.

Его применение — помощь в классификации источников информации.

AUTOMATED_RECORD_ID:= {Размер=1:12}

Уникальный идентификационный номер записи, присвоенный исходной системой. Этот номер предназначен для более надежной идентификации записи при согласовании различий в данных между двумя взаимодействующими системами.

CASTE_NAME:= {Size=1:90}

Имя, присвоенное определенной группе, с которой был связан данный человек, например, определенной расовой группе, религиозной группе или группе с наследуемым статусом.

CAUSE_OF_EVENT:= {Size=1:90}

Используется в особых случаях для записи причин, вызвавших событие. Обычно используется после события смерти, чтобы указать причину смерти, например, указанную в свидетельстве о смерти.

CERTAINTY_ASSESSMENT:= {Size=1:1}

[ 0 | 1 | 2 | 3 ]

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

0 = Ненадёжные доказательства или предполагаемые данные

1 = Сомнительная надёжность доказательств (интервью, перепись, устные генеалогии или потенциальная предвзятость, например, автобиография)

2 = Вторичные доказательства, данные, официально зарегистрированные после события

3 = Использованы прямые и первичные доказательства или по преобладанию доказательств

CHANGE_DATE:= {Size=10:11}

<DATE_EXACT>

Дата изменения этих данных.

CHARACTER_SET:= {Size=1:8}

[ ANSEL |UTF-8 | UNICODE | ASCII ]

Кодовое значение, представляющее набор символов, который следует использовать для интерпретации этих данных. В настоящее время предпочтительным набором символов является ANSEL, который включает ASCII как подмножество. UNICODE не поддерживается большинством операционных систем; Таким образом, GEDCOM, созданный с использованием набора символов UNICODE, некоторое время будет ограничен в своей взаимозаменяемости, но в конечном итоге должен обеспечить необходимую международную гибкость.

Примечание: Набор символов IBMPC не допускается. Этот набор символов невозможно интерпретировать правильно, не зная, какую кодовую страницу использовал отправитель.

CHILD_LINKAGE_STATUS:= {Size=1:15}

[challenged | disproven | proven]

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

Где:

challenged = Связь этого ребёнка с этой семьёй вызывает сомнения, но связь не была ни доказана, ни опровергнута.

disproven = Некоторые утверждали, что этот ребёнок принадлежит к этой семье, но эта связь была опровергнута.

proven = Некоторые утверждали, что этот ребёнок не принадлежит к этой семье, но её связь была доказана.

COPYRIGHT_GEDCOM_FILE:= {Size=1:90}

Заявление об авторских правах, необходимое для защиты авторских прав отправителя этого GEDCOM-файла.

COPYRIGHT_SOURCE_DATA:= {Size=1:90}

Заявление об авторских правах, требуемое владельцем данных, из которых была загружена эта информация.

Например, при запросе загрузки GEDCOM-файла из Ancestral File это будет заявление об авторских правах, указывающее на то, что данные получены из источника, защищенного авторским правом.

COUNT_OF_CHILDREN:= {Size=1:3}

Известное количество детей данного лица от всех браков или, если это связано с семейной записью, указанное количество детей, известных как принадлежащие к этой семье, независимо от того, представлены ли связанные с ними дети в соответствующей структуре. Это не обязательно количество детей, указанных в семейной структуре.

COUNT_OF_MARRIAGES:= {Size=1:3}

Количество различных семей, в которых данный человек, как известно, состоял в качестве супруга или родителя, независимо от того, представлены ли соответствующие семьи в файле GEDCOM.

DATE:= {Size=4:35}

[ <DATE_CALENDAR_ESCAPE> | <NULL>]

<DATE_CALENDAR>

DATE_APPROXIMATED:= {Size=4:35}

[

ABT <DATE> |

CAL <DATE> |

EST <DATE>

]

Где:

ABT = Примерно, то есть дата неточная.

CAL = Рассчитано математически, например, на основе даты и возраста события.

EST = Оценено на основе алгоритма, использующего другую дату события.

DATE_CALENDAR:= {Size=4:35}

[ <DATE_GREG> | <DATE_JULN> | <DATE_HEBR> | <DATE_FREN> | <DATE_FUTURE>]

Выбор основан на <DATE_CALENDAR_ESCAPE>, который предшествует значению <DATE_CALENDAR> слева. Если <DATE_CALENDAR_ESCAPE> отсутствует в этом месте, подразумевается @#DGREGORIAN@. В будущих типах календарей слова (например, названия месяцев) из этого списка: FROM, TO, BEF, AFT, BET, AND, ABT, EST, CAL или INT не будут использоваться.

Если в качестве значения DATE указаны только день и месяц, это считается фразовым обозначением даты, а не допустимой формой даты.

Date Escape (кодовое обозначние) Используемый синтаксис

@#DGREGORIAN@ <DATE_GREG>

@#DJULIAN@ <DATE_JULN>

@#DHEBREW@ <DATE_HEBR>

@#DFRENCH R@ <DATE_FREN>

@#DROMAN@ для будущего определения

@#DUNKNOWN@ календарь неизвестен

DATE_CALENDAR_ESCAPE:= {Size=4:15}

[ @#DHEBREW@ | @#DROMAN@ | @#DFRENCH R@ | @#DGREGORIAN@ |

@#DJULIAN@ | @#DUNKNOWN@ ]

Экранирование даты определяют интерпретацию даты, указывая, какой <DATE_CALENDAR> использовать. Календарь по умолчанию — григорианский.

DATE_EXACT:= {Size=10:11}

DATE_FREN:= {Size=4:35}

[ <YEAR>[B.C.] | <MONTH_FREN> <YEAR> | <DAY> <MONTH_FREN> <YEAR> ]

Смотри <MONTH_FREN>

DATE_GREG:= {Size=4:35}

[ <YEAR_GREG>[B.C.] | <MONTH> <YEAR_GREG> |

<DAY> <MONTH> <YEAR_GREG> ]

Смотри <YEAR_GREG>

DATE_HEBR:= {Size=4:35}

[ <YEAR>[B.C.] | <MONTH_HEBR> <YEAR> |

<DAY> <MONTH_HEBR> <YEAR> ]

Смотри <MONTH_HEBR>

DATE_JULN:= {Size=4:35}

[ <YEAR>[B.C.] | <MONTH> <YEAR> | <DAY> <MONTH> <YEAR> ]

DATE_LDS_ORD:= {Size=4:35}

<DATE_VALUE>

Даты таинств LDS(Святые последних дней) используют только григорианское время и чаще всего указываются в формате «день, месяц и год». Лишь в редких случаях дата может быть частичной. Тег и код храма всегда должны сопровождать даты таинств храма. Иногда используется LDS_(ordinance)_DATE_STATUS, чтобы указать, что дата таинства и код храма не требуются, например, при использовании BIC. (См. определения LDS_(ordinance)_DATE_STATUS.)

DATE_PERIOD:= {Size=7:35}

[

FROM <DATE> |

TO <DATE> |

FROM <DATE> TO <DATE>

]

Где:

FROM = Указывает начало события или состояния.

TO = Указывает окончание события или состояния.

Пример:

FROM 1904 to 1915

= Состояние некоторого атрибута существовало с 1904 по 1915 год включительно.

FROM 1904

= Состояние атрибута началось в 1904 году, но дата окончания неизвестна.

TO 1915

= Состояние закончилось в 1915 году, но дата начала неизвестна.

DATE_PHRASE:= {Size=1:35}

<TEXT>

Любое утверждение, предлагаемое в качестве даты, год которого не распознаётся анализатором дат, но которое предоставляет информацию о том, когда произошло событие.

DATE_RANGE:= {Size=8:35}

[

BEF <DATE> |

AFT <DATE> |

BET <DATE> AND <DATE>

]

Где:

AFT = Событие произошло после указанной даты.

BEF = Событие произошло до указанной даты.

BET = Событие произошло в какой-то момент между датой 1 и датой 2.

Например, BET 1904 AND 1915 указывает, что событие (возможно, один день) произошло где-то между 1904 и

1915 годами включительно.

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

Следующие значения эквивалентны и взаимозаменяемы:

Короткая форма Полная форма

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

DATE_VALUE:={Size=1:35}

[

<DATE> |

<DATE_PERIOD> |

<DATE_RANGE>|

<DATE_APPROXIMATED> |

INT <DATE> (<DATE_PHRASE>) |

(<DATE_PHRASE>)

]

DATE_VALUE представляет дату действия, атрибута или события, где:

INT = Интерпретируется на основе информации о связанной дате, указанной в скобках.

Приемлемой альтернативой варианту с датой является использование одного из других вариантов, например,<DATE_APPROXIMATED> в качестве значения строки DATE, а затем включение значения даты в качестве значения NOTE, подчиненного тегу строки DATE.

Значение даты может принимать форму даты: просто дата, приблизительная дата, дата между датой и другой датой и от одной даты до другой даты. Предпочтительным способом отображения неточности даты является, например, отображение MAY 1890, а не ABT 12 MAY 1890. Это связано с тем, что ограничения не установлены для точности таких префиксов, как ABT или EST.

DAY:= {Size=1:2}

День месяца, где dd — числовое значение, находящееся в допустимом диапазоне дней для соответствующего календарного месяца.

DESCRIPTIVE_TITLE:= {Size=1:248}

Название произведения, записи, элемента или объекта.

DIGIT:= {Size=1:1}

Одна цифра (0-9).

ENTRY_RECORDING_DATE:= {Size=1:90}

<DATE_VALUE>

Дата внесения данных о событии в исходный документ.

EVENT_ATTRIBUTE_TYPE:= {Size=1:15}

[ <EVENT_TYPE_INDIVIDUAL> |

<EVENT_TYPE_FAMILY> |

<ATTRIBUTE_TYPE> ]

Код, который классифицирует основное событие или явление, приведшее к созданию исходной записи. Если событие или атрибут не соответствует ни одному из этих кодов тегов, то ожидается указанное пользователем значение, которое, как правило, будет отнесено к категории «Другое».

EVENT_DESCRIPTOR:= {Size=1:90}

Текст, описывающий конкретное событие, относящееся к отдельному лицу или семье. Значение этого события обычно присваивается тегу EVEN. Классификация, отличающая данное событие от других событий тега EVEN, указывается с помощью подчинённого тега TYPE, выбранного из структуры EVENT_DETAIL. Например:

1 EVEN Appointed Zoning Committee Chairperson

2 TYPE Civic Appointments

2 DATE FROM JAN 1952 TO JAN 1956

2 PLAC Cove, Cache, Utah

2 AGNC Cove City Redevelopment

EVENT_OR_FACT_CLASSIFICATION:= {Size=1:90}

Описательное слово или фраза, используемая для дальнейшей классификации родительского события или тега атрибута. Его следует использовать всякий раз, когда используются общие теги EVEN или FACT. Значение этого примитива отвечает за классификацию цитируемого общего события или факта. Например, если определяемый атрибут был одним из навыков человека, например, деревообработкой, тег FACT будет иметь значение «Столярное дело», за которым следует подчиненный тег TYPE со значением «Навыки».

1 FACT Столярное дело

2 TYPE Навыки

Это группирует факт в общий атрибут навыков, и, в частности, эта запись фиксирует тот факт, что данный человек обладал навыком деревообработки. Использование метода классификации подчинённого тега TYPE с любым другим определённым тегом событий обеспечивает дальнейшую классификацию родительского тега, но не меняет его основного значения. Например, тег MARR может быть подчинён тегу TYPE со значением EVENT_DESCRIPTOR «Общее право».

1 MARR

2 TYPE Общее право

Это классифицирует запись как гражданский брак, но событие всё равно является браком. Другие значения дескриптора могут включать, например, «мертворожденный» как квалификатор для BIRT или «племенной обычай» как квалификатор для MARR (marriage).

EVENT_TYPE_CITED_FROM:= {SIZE=1:15}

[ <EVENT_ATTRIBUTE_TYPE> ]

Код, указывающий тип события, послужившего причиной регистрации исходной записи. Например, если запись была создана для регистрации рождения ребёнка, то тип будет BIRT, независимо от утверждений, сделанных на основе этой записи, таких как имя матери или дата её рождения. Это позволит приоритетно выбрать наилучшее представление и определить достоверность, связанную с источником, использованным для подтверждения цитируемого факта.

EVENT_TYPE_FAMILY:= {Size=3:4}

MARB | MARC | MARL | MARS | EVEN ]

Код, используемый для обозначения типа семейного события. Определение совпадает с соответствующим тегом события, указанным в Приложении А.

EVENT_TYPE_INDIVIDUAL:= {Size=3:4}

GRAD | IMMI | NATU | ORDN |

RETI | PROB | WILL | EVEN ]

EVENTS_RECORDED:= {Size=1:90}

[<EVENT_ATTRIBUTE_TYPE> |

<EVENTS_RECORDED>, <EVENT_ATTRIBUTE_TYPE>]

Перечень различных видов событий, зафиксированных в определённом источнике. Каждый перечисленный разделяется запятой. Например, в приходской книге регистрации рождений, смертей и браков это будет BIRT, DEAT, MARR.

FILE_NAME:= {Size=1:90}

Имя файла передачи GEDCOM. Если имя файла включает расширение, оно должно быть указано в формате (имя_файла.расширение).

GEDCOM_CONTENT_DESCRIPTION:={Size=1:248}

Примечание, которое пользователь вводит для описания содержимого файла, связанного с генеалогическим древом, в терминах «предки или потомки», чтобы получатель данных знал, какую генеалогическую информацию содержит переданный файл.

GEDCOM_FORM:= {Size=14:20}

[ LINEAGE-LINKED ]

Форма GEDCOM, используемая для построения этой передачи. Возможно, используются и другие формы, например, "EVENT_LINEAGE_LINKED" от CommSoft, но эти спецификации определяют только форму LINEAGELINKED. Системы будут использовать это значение для определения совместимости GEDCOM с этими спецификациями.

GENERATIONS_OF_ANCESTORS:= {Size=1:4}

Количество поколений предков, включенных в эту передачу. Это значение обычно предоставляется, когда программы FamilySearch создают GEDCOM-файл для пользователя, запрашивающего загрузку данных о предках.

GENERATIONS_OF_DESCENDANTS:= {Size=1:4}

Количество поколений потомков, включённых в эту передачу. Это значение обычно предоставляется, когда программы FamilySearch создают GEDCOM-файл для пользователя, запрашивающего загрузку потомков.

LANGUAGE_ID:= {Size=1:15}

Таблица действительных идентификационных кодов языка, которые используют латиницу.

Другие языки поддерживаются только в UNICODE.

Vietnamese | Yiddish ]

LANGUAGE_OF_TEXT:= {Size=1:15}

[ <LANGUAGE_ID> ]

Человеческий язык, на котором обычно читаются или записываются передаваемые данные. Он используется в основном программами для выбора последовательностей сортировки, специфичных для конкретного языка, и алгоритмов сопоставления фонетических имён.

LANGUAGE_PREFERENCE:= {Size=1:90}

[ <LANGUAGE_ID> ]

Язык, на котором человек предпочитает общаться. Предпочтение к нескольким языкам демонстрируется использованием нескольких вхождений в порядке приоритета.

LDS_BAPTISM_DATE_STATUS:= {Size=5:10}

Код, указывающий статус крещения СПД и дату конфирмации, где:

CHILD = Умер до достижения восьмилетнего возраста, крещение не требуется.

COMPLETED = Завершено, но дата неизвестна.

EXCLUDED = Покровитель исключил это таинство из числа прошедших процедуру в данной заявке.

PRE-1970 = Таинство, вероятно, завершено, другое таинство для этого человека было преобразовано из храмовых записей о работе, выполненной до 1970 года, поэтому это таинство считается завершенным до тех пор, пока все записи не будут преобразованы.

STILLBORN = Мертворожденный, крещение не требуется.

SUBMITTED = Таинство было ранее подано.

UNCLEARED = Данных для запроса на прохождение таинства недостаточно.

LDS_CHILD_SEALING_DATE_STATUS:= {Size=5:10}

[ BIC | COMPLETED | EXCLUDED | DNS | PRE-1970 |

STILLBORN | SUBMITTED | UNC ]

BIC = Рождённый в завете, получивший благословение запечатывания ребёнка с родителем.

EXCLUDED = Покровитель исключил это таинство из числа прошедших проверку в данном запросе.

PRE-1970 = (См. информацию до 1970 г. в разделе LDS_BATTISM_DATE_STATUS)

STILLBORN = Мертворожденный, не требуется.

SUBMITTED = Таинство было ранее пройдено.

UNCLEARED = Данных для прошедшего проверку запроса на таинство было недостаточно.

LDS_ENDOWMENT_DATE_STATUS:= {Size=5:10}

[ CHILD | COMPLETED | EXCLUDED | PRE-1970 |

STILLBORN | SUBMITTED | UUNCLEARED ]

Код, указывающий статус таинства облечения Церкви Иисуса Христа Святых последних дней, где:

CHILD = Умер до достижения восьмилетнего возраста.

COMPLETED = Завершено, но дата неизвестна.

EXCLUDED = Покровитель исключил это таинство из рассмотрения в данной заявке.

INFANT = Умер до достижения возраста одного года, крещение или облечение не требуется.

PRE-1970 = (См. до 1970 г. в разделе LDS_BAPTISM_DATE_STATUS)

STILLBORN = Мертворожденный, таинство не требуется.

SUBMITTED = Таинство было рассмотрено ранее.

UNCLEARED = Данных для рассмотрения запроса на таинство недостаточно.

LDS_SPOUSE_SEALING_DATE_STATUS:= {Size=3:10}

[ CANCELED | COMPLETED | DNS | EXCLUDED |

DNS/CAN | PRE-1970 | SUBMITTED | UNCLEARED ]

CANCELED = Отменено и признано недействительным.

COMPLETED = Завершено, но дата неизвестна.

EXCLUDED = Покровитель исключил это таинство из числа подлежащих утверждению в данной подаче.

DNS = Это таинство не утверждено.

DNS/CAN = Это таинство не утверждено, предыдущее опечатывание отменено.

PRE-1970 = (См. до 1970 года в разделе LDS_BATTISM_DATE_STATUS)

SUBMITTED = Таинство было ранее представлено.

UNCLEARED = Данных для утверждения таинства недостаточно.

MONTH:= {Size=3}

[ JAN | FEB | MAR | APR | MAY | JUN |

JUL | AUG | SEP | OCT | NOV | DEC ]

Где:

JAN = Январь

FEB = Февраль

MAR = Март

APR = Апрель

MAY = Май

JUN = Июнь

JUL = Июль

AUG = Август

SEP = Сентябрь

OCT = Октябрь

NOV = Ноябрь

DEC = Декабрь

MONTH_FREN:= {Size=4}

Где:

VEND = VENDEMIAIRE

BRUM = BRUMAIRE

FRIM = FRIMAIRE

NIVO = NIVOSE

PLUV = PLUVIOSE

VENT = VENTOSE

GERM = GERMINAL

FLOR = FLOREAL

PRAI = PRAIRIAL

MESS = MESSIDOR

THER = THERMIDOR

FRUC = FRUCTIDOR

COMP = JOUR_COMPLEMENTAIRS

MONTH_HEBR:= {Size=3}

[ TSH | CSH | KSL | TVT | SHV | ADR | ADS |

NSN | IYR | SVN | TMZ | AAV | ELL ]

Где:

TSH = Tishri

CSH = Cheshvan

KSL = Kislev

TVT = Tevet

SHV = Shevat

ADR = Adar

ADS = Adar Sheni

NSN = Nisan

IYR = Iyar

SVN = Sivan

TMZ = Tammuz

AAV = Av

ELL = Elul

MULTIMEDIA_FILE_REFERENCE:= {Size=1:30}

Полная локальная или удалённая ссылка на файл вспомогательных данных, которые необходимо связать с контекстом GEDCOM.

Удалённая ссылка должна включать сетевой адрес, по которому можно получить мультимедийные данные.

MULTIMEDIA_FORMAT:= {Size=3:4}

[ bmp | gif | jpg | ole | pcx | tif | wav ]

Указывает формат мультимедийных данных, связанных с конкретным контекстом GEDCOM. Это позволяет процессорам определить, могут ли они обработать объект данных. Любые связанные файлы должны содержать данные, необходимые для обработки данных файла, в указанном формате.

NAME_OF_BUSINESS:= {Size=1:90}

Название предприятия, корпорации или лица, изготовившего или заказавшего продукт.

NAME_OF_FAMILY_FILE:= {Size=1:120}

Имя, под которым фамилии членов семьи, участвующих в таинствах, хранятся в семейном архиве храма.

NAME_OF_PRODUCT:= {Size=1:90}

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

NAME_OF_REPOSITORY:= {Size=1:90}

Официальное название архива, в котором хранится указанный исходный материал.

NAME_OF_SOURCE_DATA:= {Size=1:90}

Название электронного источника данных, использованного для получения данных в этой передаче. Например, данные могли быть получены с компакт-диска под названием «U.S. 1880 CENSUS CD-ROM vol. 13».

NAME_PERSONAL:= {Size=1:120}

[

<NAME_TEXT> |

/<NAME_TEXT>/ |

<NAME_TEXT> /<NAME_TEXT>/ |

/<NAME_TEXT>/ <NAME_TEXT> |

<NAME_TEXT> /<NAME_TEXT>/ <NAME_TEXT>

]

Фамилия человека, если известна, заключается в два слэша (/). Порядок частей имени должен соответствовать порядку, который человек, согласно традициям своей культуры, использовал бы при передаче имени регистратору. В ранних версиях некоторого ПО косая черта в конце имени не использовалась. Если часть имени неразборчива, она обозначается многоточием (...). Имя человека или название места следует писать с заглавной буквы общепринятым образом — заглавной первой буквой каждой части и строчными остальными, если общепринятое употребление не требует иного.

Примеры:

Уильям Ли (только имя или фамилия неизвестна)

/Пэрри/ (только фамилия)

Уильям Ли /Пэрри/

Уильям Ли /Мак Пэрри/ (обе части (Мак и Пэрри) являются частями фамилии)

Уильям /Ли/ Пэрри (фамилия вставлена в строку имени)

Уильям Ли /Па.../

NAME_PHONETIC_VARIATION:= {Size=1:120}

Фонетический вариант имени записывается в той же форме, что и имя, использованное в главном примитиве <NAME_PERSONAL>, но фонетически записывается с использованием метода, указанного главным значением <PHONETIC_TYPE>. Например, если для прочтения имени, написанного кандзи, использовалась хирагана, то значение <PHONETIC_TYPE> будет указывать на «кану».

NAME_PIECE:= {Size=1:90}

Часть имени, относящаяся к интересующей части имени. Фамилия, имя, префикс имени или суффикс имени.

NAME_PIECE_GIVEN:= {Size=1:120}

[ <NAME_PIECE> | <NAME_PIECE_GIVEN>, <NAME_PIECE> ]

Имя или заслуженное имя. Различные имена разделяются запятой.

NAME_PIECE_NICKNAME:= {Size=1:30}

[ <NAME_PIECE> | <NAME_PIECE_NICKNAME>, <NAME_PIECE> ]

Описательное или фамильярное имя, используемое в сочетании с собственным именем.

NAME_PIECE_PREFIX:= {Size=1:30}

[ <NAME_PIECE> | <NAME_PIECE_PREFIX>, <NAME_PIECE> ]

Неиндексируемая часть имени, предшествующая имени и фамилии. Различные префиксные части имени разделяются запятой.

Пример:

Lt. Cmndr. Joseph /Allen/ jr.

В этом примере «Lt. Cmndr.» рассматривается как префиксная часть имени.

NAME_PIECE_SUFFIX:= {Size=1:30}

[ <NAME_PIECE> | <NAME_PIECE_SUFFIX>, <NAME_PIECE> ]

Неиндексируемая часть имени, которая следует за частью имени и фамилии. Разные части имени с суффиксом разделяются запятой.

Пример:
Lt. Cmndr. Joseph /Allen/ jr.

В этом примере jr. рассматривается как суффиксная часть имени.

NAME_PIECE_SURNAME:= {Size=1:120}

[ <NAME_PIECE> | <NAME_PIECE_SURNAME>, <NAME_PIECE> ]

Фамилия. Разные фамилии разделяются запятой.

NAME_PIECE_SURNAME_PREFIX:= {Size=1:30}

[ <NAME_PIECE> | <NAME_PIECE_SURNAME_PREFIX>, <NAME_PIECE> ]

Префикс или артикль фамилии, используемый в семейном имени. Различные артикли фамилии разделяются запятой, например, в имени «de la Cruz» это будет «de, la».

NAME_ROMANIZED_VARIATION:= {Size=1:120}

Латинизированный вариант имени записывается в той же форме, что и имя, используемое в главном контексте <NAME_PERSONAL>. Метод, используемый для романизации имени, указывается значением_строки подчиненного <ROMANIZED_TYPE>. Например, если для чтения имени, написанного кандзи, использовался ромадзи, то подчиненный тег ROMN ROMANIZED_TYPE будет указывать на ромадзи.

NAME_TEXT:= {Size=1:120}

<TEXT> исключая запятые, цифры, специальные символы, не считающиеся диакритическими знаками.

NAME_TYPE:= {Size=5:30}

Указывает тип имени, например имя, выданное или принятое иммигрантом.

aka = также известный как, псевдоним и т. д.

birth = имя, указанное в свидетельстве о рождении.

immigrant = имя, принятое при иммиграции.

maiden = девичья фамилия, фамилия до первого брака.

married = фамилия, использовавшаяся в предыдущем браке.

user_defined = другое текстовое имя, определяющее тип имени.

NATIONAL_ID_NUMBER:= {Size=1:30}

Номер, контролируемый государством, присваиваемый физическому лицу. Общеизвестным национальным номерам следует присвоить собственный тег, например, SSN для номера социального страхования США. Использование тега IDNO требует подчинённого тега TYPE для определения типа сохраняемого номера.

Например:

n IDNO 43-456-1899

+1 TYPE Canadian Health Registration

NATIONAL_OR_TRIBAL_ORIGIN:= {Size=1:120}

Разделение личности по национальному происхождению или другим народным, семейным, родовым, родовым или племенным интересам.

Примеры: ирландцы, шведы, сиу-дакота, апачи-чирикава, навахо, биттер-уотер, восточные чероки и т. д.

NEW_TAG:= {Size=1:15}

Пользовательский тег, содержащийся в текущей передаче GEDCOM. Этот тег должен начинаться с символа подчеркивания (_) и должен интерпретироваться только в контексте отправляющей системы.

NOBILITY_TYPE_TITLE:= {Size=1:120}

Титул, данный или используемый лицом, особенно представителем королевской семьи или другого знатного класса в данной местности.

NULL:= {Size=0:0}

Условное обозначение, указывающее на отсутствие в значении любого 8-битного символа ASCII, включая нулевой символ (0x00), который запрещён.

NUMBER:=

[<DIGIT> | <NUMBER>+<DIGIT>]

OCCUPATION:= {Size=1:90}

Вид деятельности, которую выполняет человек в рамках своей работы, профессии или основной деятельности.

ORDINANCE_PROCESS_FLAG:= {Size=2:3}

[ yes | no ]

Флаг, указывающий, следует ли обрабатывать заявку на прохождение храмовых таинств.

PEDIGREE_LINKAGE_TYPE:= {Size=5:7}

[ adopted | birth | foster | sealing ]

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

Где:

adopted = указывает на приёмных родителей.

birth = указывает на биологических родителей.

foster = указывает на ребёнка, находящегося в приёмной семье или семье опекуна.

sealing = указывает на ребёнка, находившегося в семье, отличной от биологических родителей.

PERMANENT_RECORD_FILE_NUMBER:= {Size=1:90}

<REGISTERED_RESOURCE_IDENTIFIER>:<RECORD_IDENTIFIER>

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

PHONE_NUMBER:= {Size=1:25}

Номер телефона.

PHONETIC_TYPE:= {Size=5:30}

[<user defined> | hangul | kana]

Указывает метод, используемый для преобразования текста в фонетический вариант.

<user define> = Метод записи, используемый для получения фонетического варианта имени.

hangul = Фонетический метод для озвучивания корейских глифов.

kana = Символы хираганы и/или катаканы использовались для озвучивания иероглифа, используемого в японском языке.

PHYSICAL_DESCRIPTION:= {Size=1:248}

Неструктурированный список атрибутов, описывающих физические характеристики человека, места или объекта. Каждый атрибут разделяется запятыми.

Пример:

1 DSCR рыжие волосы, зеленые глаза, третий размер груди

2 DATE 23 JUL 1935

PLACE_HIERARCHY:= {Size=1:120}

Здесь показаны юрисдикционные образования, перечисленные в порядке от низшей к высшей. Юрисдикции разделены запятыми, и любое отсутствующее название юрисдикции все равно учитывается запятой. Когда структура PLAC.FORM включена в заголовок передачи GEDCOM, это подразумевает, что все географические названия следуют этому юрисдикционному формату, и каждая юрисдикция учитывается запятой, независимо от того, известно ли название или нет. Когда PLAC.FORM подчинена событию, она временно переопределяет последствия, накладываемые структурой PLAC.FORM, указанной в HEADER. Такое использование не распространено и, следовательно, не рекомендуется. Его следует использовать только в том случае, если система имеет чрезмерно разветвленную структуру географических названий.

PLACE_LATITUDE:= {Size=5:8}

Значение, указывающее широтную координату места. Координата широты — это направление на север или юг от экватора в градусах и долях градуса, выраженное в градусах и долях градуса, для достижения желаемой точности. Например, 18 градусов, 9 минут и 3,4 секунды на север будут отформатированы как N18.150944. Минуты и секунды преобразуются путем деления значения минут на 60, а значения секунд на 3600 и сложения результатов. Эта сумма становится дробной частью значения градуса.

PLACE_LIVING_ORDINANCE:= {Size=1:120}

<PLACE_NAME>

Местоположение места, где было совершено таинство крещения при жизни LDS. Как правило, в этом поле указывается место крещения при жизни LDS.

PLACE_LONGITUDE:= {Size=5:8}

Значение, указывающее долготную координату названия места. Координата долготы: градусы и доли градуса к востоку или западу от нулевого или базового меридиана. Например: 168 градусов, 9 минут и 3,4 секунды на восток будут представлены в формате E168.150944.

PLACE_NAME:= {Size=1:120}

[

<PLACE_TEXT> |

<PLACE_TEXT>, <PLACE_NAME>

]

Название юрисдикции места, где произошло событие. Юрисдикции разделяются запятыми, например, «Коув, Кэш, Юта, США». Если фактические названия юрисдикций этих мест были определены, их можно отобразить с помощью структуры PLAC.FORM либо в заголовке, либо в структуре события. (См. <PLACE_HIERARCHY>)

PLACE_PHONETIC_VARIATION:= {Size=1:120}

Фонетический вариант названия места записывается в той же форме, что и название места, использованное в главном примитиве <PLACE_NAME>, но фонетически записывается способом, указанным главным значением <PHONETIC_TYPE>. Например, если для прочтения названия, написанного кандзи, использовалась хирагана, то значение <PHONETIC_TYPE> будет указывать на кану. (См. <PHONETIC_TYPE>)

PLACE_ROMANIZED_VARIATION:= {Size=1:120}

Латинизированный вариант названия места записывается в той же форме, что и название места, используемое в вышестоящем контексте <PLACE_NAME>. Способ романизации названия указывается значением строки подчиненного <ROMANIZED_TYPE>. Например, если ромадзи использовался для прочтения названия места, написанного кандзи, то <ROMANIZED_TYPE>, подчиненный тегу ROMN, будет указывать на «ромадзи». (См. <ROMANIZED_TYPE>)

PLACE_TEXT:= {Size=1:120}

<TEXT> без учета запятых.

POSSESSIONS:= {Size=1:248}

Перечень имущества (недвижимости или иной собственности), принадлежащего данному лицу.

PUBLICATION_DATE:= {Size=10:11}

<DATE_EXACT>

Дата публикации или создания данного источника.

RECEIVING_SYSTEM_NAME:= {Size=1:20}

Имя системы, которая, как ожидается, будет обрабатывать данные, совместимые с GEDCOM. Зарегистрированное RECEIVING_SYSTEM_NAME для всех документов GEDCOM, отправляемых в Family History Department, должно быть одним из следующих имён:

! "ANSTFILE" при отправке в Ancestral File.

! "TempleReady" при отправке на получение разрешения на храмовое таинство.

RECORD_IDENTIFIER:= {Size=1:18}

Идентификационный номер, присваиваемый каждой записи в конкретной базе данных. База данных, к которой относится RECORD_IDENTIFIER, обозначается REGISTERED_RESOURCE_NUMBER, который предшествует двоеточию (:). Если перед RECORD_IDENTIFIER нет двоеточия, это ссылка на запись в текущей передаче GEDCOM.

REGISTERED_RESOURCE_IDENTIFIER:= {Size=1:25}

Это идентификатор, присвоенный базе данных ресурсов, доступной через сеть. Это необходимо для будущих версий GEDCOM.

RELATION_IS_DESCRIPTOR:= {Size=1:25}

Слово или фраза, указывающая на связь объекта 1 с объектом 2. Например, следующее можно прочитать как «правнук Джо Джейкоба является отправителем, на что указывает @XREF:SUBM@»:

0 INDI

1 NAME Joe /Jacob/

1 ASSO @<XREF:SUBM>@

2 RELA great grandson

RELIGIOUS_AFFILIATION:= {Size=1:90}

Название религии, с которой был связан этот человек, событие или запись.

RESPONSIBLE_AGENCY:= {Size=1:120}

Организация, учреждение, корпорация, лицо или другой субъект, несущий ответственность за соответствующий контекст. Например, работодатель человека соответствующей профессии, церковь, проводившая обряды или мероприятия, или организация, ответственная за создание и/или архивирование записей.

RESTRICTION_NOTICE:= {Size=6:7}

[confidential | locked | privacy ]

Уведомление об ограничении использования Ancestral File. Файлы GEDCOM для загрузки Ancestral File могут содержать эти данные.

Где:

confidential = Эти данные были помечены пользователем как конфиденциальные. В некоторых системах данные, помеченные как конфиденциальные, будут обрабатываться по-другому, например, может быть опция, которая запрещает отображение конфиденциальных данных в печатных отчетах или предотвращает экспорт этой информации.

locked = Некоторые записи в Ancestral File были удовлетворительно подтверждены доказательствами, но из-за конфликтов источников или неверных традиций предпринимаются неоднократные попытки изменить эту запись. По договоренности Хранитель Ancestral File может заблокировать запись, чтобы ее нельзя было изменить без согласия лица, назначенного распорядителем такой записи. Назначенным распорядителем является либо лицо, указанное для записи, либо служба Family History Support, если лицо, указанное для записи, не указано.

privacy = Указывает, что информация, касающаяся этой записи, отсутствует в связи с правами или одобренным запросом на конфиденциальность. Например, данные из запрошенных загрузок Ancestral File могут содержать информацию о лицах, помеченных как «конфиденциальные», если предполагается, что они живы, то есть родились в течение последних 110 лет и дата смерти отсутствует. В некоторых случаях семейные записи также могут быть помечены тегом RESN, указывающим на конфиденциальность, если предполагается, что лицо, выступающее в роли HUSB (МУЖА) или WIFE (ЖЕНЫ), живо.

ROLE_DESCRIPTOR:= {Size=1:25}

Слово или фраза, определяющая роль человека в описываемом событии. Это должно быть то же самое слово или фраза, и на том же языке, которые регистратор использовал для определения роли в фактической записи.

ROLE_IN_EVENT:= {Size=1:15}

Указывает, какую роль этот человек играл в событии, цитируемом в данном контексте. Например, если вы ссылаетесь на запись о рождении ребёнка в качестве источника имени матери, значение этого поля — «MOTH». Если вы описываете жениха в браке, роль — «HUSB». Если роль отличается от одной из шести ролей отношений, перечисленных выше, заключите имя роли в круглые скобки.

ROMANIZED_TYPE:= {Size=5:30}

[<user defined> | pinyin | romaji | wadegiles]

Указывает метод, используемый для преобразования текста в романизированный вариант.

SCHOLASTIC_ACHIEVEMENT:= {Size=1:248}

Описание учебного или образовательного достижения или занятия.

SEX_VALUE:= {Size=1:7}

Код, указывающий пол человека:

M = Мужской

F = Женский

U = Не определено по имеющимся данным.

SOCIAL_SECURITY_NUMBER:= {Size=9:11}

Номер, присваиваемый человеку в Соединенных Штатах в целях его идентификации.

SOURCE_CALL_NUMBER:= {Size=1:120}

Идентификационный номер или справочное описание, используемое для регистрации и извлечения объектов из фондов репозитория.

SOURCE_DESCRIPTION:= {Size=1:248}

Текстовый блок свободной формы, используемый для описания источника, из которого была получена информация. Этот текстовый блок используется системами, которые не могут использовать указатель на запись источника. Он должен содержать описательное название, информацию о создателе работы, месте и времени её создания, а также о месте хранения исходных данных. Разработчик должен поощрять пользователей использовать подходящий стиль для формирования этой библиографической ссылки в свободной формы. Разработчикам рекомендуется поддерживать метод SOURCE_RECORD для представления описаний библиографических ссылок.

SOURCE_DESCRIPTIVE_TITLE:= {Size=1:248}

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

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

Неопубликованное произведение, например:

! Письмо может включать дату, отправителя и получателя.

! Сделка между покупателем и продавцом может содержать их имена и дату сделки.

! Семейная Библия, содержащая генеалогическую информацию, может иметь прошлых и настоящих владельцев, а также физическое описание книги.

! В личном интервью будут указаны информатор и интервьюер.

SOURCE_FILED_BY_ENTRY:= {Size= 1:60}

В этой записи указывается краткое название, используемое для сортировки, хранения и извлечения исходных записей.

SOURCE_JURISDICTION_PLACE:= {Size=1:120}

<PLACE_NAME>

Название низшей юрисдикции, охватывающей все населённые пункты низшего уровня, упомянутые в данном источнике. Например, «Онейда, Айдахо» будет использоваться в качестве места исходной юрисдикции для событий, происходящих в различных городах округа Онейда. «Айдахо» будет местом исходной юрисдикции, если зарегистрированные события произошли в других округах, а также в округе Онейда.

SOURCE_MEDIA_TYPE:= {Size=1:15}

Код, выбранный из одной из классификаций медиа, приведенных выше, который указывает тип материала, в котором хранится указанный источник.

SOURCE_ORIGINATOR:= {Size=1:248}

Лицо, агентство или организация, создавшие запись. Для опубликованного произведения это может быть автор, составитель, переписчик, референт или редактор. Для неопубликованного источника это может быть физическое лицо, государственное агентство, церковная организация или частная организация и т. д.

SOURCE_PUBLICATION_FACTS:= {Size=1:248}

Когда и где была создана запись. Для опубликованных произведений это включает такую информацию, как город публикации, название издателя и год публикации.

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

SUBMITTER_NAME:= {Size=1:60}

Имя отправителя, отформатированное для отображения и формирования адреса.

SUBMITTER_REGISTERED_RFN:= {Size=1:30}

Регистрационный номер заявителя, предоставляющего данные Ancestral File. Этот номер используется в последующих заявках или запросах заявителя для целей идентификации.

SUBMITTER_TEXT:= {Size=1:248}

Комментарии отправителя.

TEMPLE_CODE:= {Size=4:5}

Сокращенное название храма, в котором совершались храмовые таинства LDS. (См. Приложение B)

TEXT:= {Size=1:248}

Строка, состоящая из любых допустимых символов из наборов символов используемых GEDCOM.

TEXT_FROM_SOURCE:= {Size=1:248}

<TEXT>

Дословная копия любого описания, содержащегося в источнике. Это указывает на заметки или текст, которые фактически содержатся в исходном документе, а не на мнение автора об источнике. С точки зрения доказательств, это должно быть «то, что сказал хранитель исходных записей», а не интерпретация исследователя. Слово ТЕКСТ в данном случае означает текст, который появился в исходной записи, включая метки.

TIME_VALUE:= {Size=1:12}

[ hh:mm:ss.fs ]

Время определенного события, обычно хронометрируемого компьютером, где:

hh = часы в 24-часовом формате

mm = минуты

ss = секунды (необязательно)

fs = десятичная доля секунды (необязательно)

TRANSMISSION_DATE:= {Size=10:11}

<DATE_EXACT>

Дата создания данной передачи.

USER_REFERENCE_NUMBER:= {Size=1:20}

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

USER_REFERENCE_TYPE:= {Size=1:40}

Пользовательское определение USER_REFERENCE_NUMBER.

VERSION_NUMBER:= {Size=1:15}

Идентификатор, представляющий номер версии, присвоенный соответствующему продукту. Он определяется и изменяется создателями продукта.

WHERE_WITHIN_SOURCE:= {Size=1:248}

Конкретное место, на которое ссылается информация. Для опубликованного произведения это может быть том многотомного издания и номер(а) страницы(страниц). Для периодического издания это могут быть том, выпуск и номера страниц. Для газеты это могут быть номер колонки и номер страницы. Для неопубликованного источника или микрофильмированных произведений это может быть номер плёнки или листа, номер страницы, номер кадра и т. д. В переписном листе может быть указан район переписи, номер страницы, номер строки, номер дома и номер семьи. Данные в этом поле должны быть представлены в виде пары «метка-значение», например, «Метка1: значение», «Метка2: значение», где каждая пара разделяется запятой. Например, «Плёнка:1234567, Кадр: 344, Строка: 28».

XREF:= {Size=1:22}

Либо указатель, либо уникальный идентификатор перекрёстной ссылки. Если этот элемент находится перед тегом в строке GEDCOM, то это идентификатор перекрёстной ссылки. Если он находится после тега в строке GEDCOM, то это указатель. Метод разграничения указателя или идентификатора перекрёстной ссылки заключается в заключении указателя или идентификатора перекрёстной ссылки в символы @, например, @I123@. XREF не может начинаться со знака номера (#). Это сделано для того, чтобы избежать путаницы с префиксом управляющей последовательности (@#). Использование двоеточия (:) в XREF зарезервировано для создания будущих сетевых перекрёстных ссылок, а использование восклицательного знака (!) зарезервировано для указателей внутри записи. Уникальность идентификатора перекрёстной ссылки требуется в файле передачи.

XREF:FAM:= {Size=1:22}

Указатель на fam_record или идентификатор перекрестной ссылки на него.

XREF:INDI:= {Size=1:22}

Указатель или идентификатор перекрестной ссылки на INDI запись.

XREF:NOTE:= {Size=1:22}

Указатель на запись заметки или идентификатор перекрёстной ссылки на неё.

XREF:OBJE:= {Size=1:22}

Указатель на мультимедийный объект или идентификатор перекрёстной ссылки на него.

XREF:REPO:= {Size=1:22}

Указатель на запись репозитория или идентификатор перекрёстной ссылки на неё.

XREF:SOUR:= {Size=1:22}

Указатель на запись SOUR или идентификатор перекрёстной ссылки на неё.

XREF:SUBM:= {Size=1:22}

Указатель на запись SUBM или идентификатор перекрёстной ссылки на неё.

XREF:SUBN:= {Size=1:22}

Указатель на запись SUBN или идентификатор перекрёстной ссылки на неё.

YEAR:= {Размер=3:4}

Числовое представление календарного года, в котором произошло событие.

YEAR_GREG:= {Size=3:7}

[ <NUMBER> | <NUMBER>/<DIGIT><DIGIT> ]

Слэш «/» <DIGIT><DIGIT> — модификатор года, который показывает возможные варианты даты до 1752 года, вызванные изменением начала года с MAR на JAN в английском календаре 1752 года, например, 15 APR 1699/00. A (B.C.), добавленная к <YEAR>, указывает на дату до Рождества Христова.

Совместимость с другими версиями GEDCOM

Совместимость с GEDCOM оценивается по каждому тегу и зависит от того, насколько схожи модели данных для двух различных взаимодействующих продуктов, а также от того, насколько последовательно они понимают и соблюдают стандарт GEDCOM. Некоторые несоответствия в использовании конкретных тегов также прослеживались в разных версиях самого стандарта из-за недальновидности или непреднамеренных ошибок. В рамках этих ограничений совместимые с GEDCOM продукты могут обмениваться данными на основе GEDCOM 2.0, 3.0, 4.0 и 5.x. Конечно, более новые версии GEDCOM значительно расширяют модель данных, для которой новые контексты тегов не будут поддерживаться старыми продуктами. Некоторые продукты внесли собственные изменения в свою форму GEDCOM. Это, вероятно, приведет к уникальным проблемам совместимости.

Ниже перечислены области, в которых могут возникнуть несовместимости:

! Структура источника:

Структура SOUR не поддерживалась GEDCOM в версиях до 5.x. Однако некоторые продукты, выпущенные до GEDCOM 5.x, разработали структуру SOUR для цитирования источников. Эти структуры различались от продукта к продукту, что влияло на интерпретацию ссылок на источники. Продукты, основанные на 5.x GEDCOM, выпущенные до GEDCOM 5.4, могли использовать более подробную структуру источника, предложенную в предыдущих версиях 5.x. Более старые системы, уже обрабатывающие источники, нуждаются в доработке. Проектным продуктам GEDCOM 5.x рекомендуется как можно скорее обновить свои программы до стандарта GEDCOM 5.5.

! Указатель FAMC:

Структура INDI.FAMC была значительно изменена со времени GEDCOM 4.0. В предыдущих версиях GEDCOM 5.x структура FAMC могла содержать подчиненные события усыновления и/или запечатывания LDS в родительские события. См. вопросы совместимости, касающиеся запечатывания LDS с исходным событием, рассмотренные в разделе «Даты таинств LDS» в следующем абзаце.

Возможно, имелось в виду запечатывание детей в рамках учения мормонов. Согласно этому учению, запечатывание — ритуал, который проводят в храмах Церкви Иисуса Христа Святых последних дней (LDS Church). Его цель — укрепить семейные отношения, чтобы они могли существовать на протяжении вечности.

! Даты постановлений LDS:

Структура запечатывания ребёнка к родителю в LDS была изменена в предыдущих версиях проекта GEDCOM 5.x со структуры FAM.CHIL.SLGC на структуру INDI.FAMC.SLGC. Это было сделано для того, чтобы обеспечить доступ к информации о запечатывании ребёнка без необходимости следовать указателю на семейную запись. Personal Ancestral File 2.31 записывает дату запечатывания в структуру FAM.CHIL.SLGC, но считывает эту информацию из любого формата. В новой основной версии Personal Ancestral File будет использоваться более новый подход.

GEDCOM 5.4 помещает событие запечатывания ребёнка к родителю на тот же уровень, что и все остальные события, подчинённые тегу INDI. Если система отслеживает, к какой семье принадлежит человек, то указатель FAMC дополнительно вставляется под тегом события SLGC, указывающим на запечатывание в семье.

Для поддержки импорта из предыдущих версий GEDCOM, системы, обрабатывающие события таинств LDS, должны искать информацию о запечатывании детей либо в структурах INDI.SLGC (см. LDS_INDIVIDUAL_ORDINANCE, INDI.FAMC.SLGC, либо в структурах FAM.CHIL.SLGC. Экспорт Ancestral File не отделял код храма от даты таинства. Даты таинств, загруженные из Ancestral File, могут содержать дату таинства, за которой следует двузначный код храма, а не отдельную строку кода храма.

Системы GEDCOM 4.x использовали определенные ключевые слова в качестве части дат таинств. GEDCOM 5.x отделял эти коды от дат и указывал, что они должны быть значениями подчиненного тега STAT. Предыдущие реализации GEDCOM 5.x могли реализовывать эту функцию с помощью тега TYPE вместо тега STAT. (См. <LDS_(ordinance)_DATE_STATUS>)

! События усыновления:

В GEDCOM 5.x событие ADOP (adoption) было перенесено из структуры FAM.CHIL в структуру INDI.FAMC.ADOP, оно также присутствует в структуре INDI.ADOP. В GEDCOM 5.4 событие ADOP отображается только как отдельное событие, которое может содержать указатель FAMC на усыновившую семью. Этому указателю подчиняется другой тег ADOP, который указывает, был ли HUSB (МУЖ) или WIFE (ЖЕНА) в указанной семье усыновителем (см. примитив <ADOPTED_BY_WHICH_PARENTS>). Навигация по родословной обеспечивается только структурой <<CHILD_TO_FAMILY_LINK>>.

! Коды в дате события:

Некоторые приложения, такие как Personal Ancestral File, передают ключевые слова как часть дат определённых событий. Некоторые из этих ключевых слов — INFANT, CHILD, MERTHILD и т.д. Они связаны с приблизительным возрастом на момент события.

В этой версии GEDCOM эта информация была удалена из значения даты и задана ключевым словом <AGE_AT_EVENT>, которое указывает описательное значение возраста на момент события. (См. <AGE_AT_EVENT>) Например:

1 DEAT

2 DATE 13 MAY 1984

2 AGE STILLBORN

Это означает, что этот человек умер в возрасте приблизительно 0 дней.

1 DEAT

2 DATE 13 MAY 1984

2 AGE INFANT

Это означает, что этот человек умер в возрасте менее 1 года.

! Несколько имён:

GEDCOM 5.x требует перечисления разных имён в разных структурах NAME, где предпочтительный экземпляр идёт первым, а за ним следуют менее предпочтительные имена. Однако Personal Ancestral File и другие продукты, обрабатывающие только одно имя, могут использовать только последний экземпляр имени из передачи GEDCOM. Это приводит к отбрасыванию предпочтительного имени при наличии более одного имени. То же самое часто происходит с другими тегами с несколькими экземплярами, когда принимающая система ожидала только один экземпляр.

! Псевдонимы:

Одна или две системы использовали тег ALIA (alias) для представления нескольких имён. Эта форма не поддерживается в стандарте GEDCOM версии 5.5.

! Структура события:

Структура адреса, как часть структуры места, предоставляла больше детализации, чем требовалось для структуры PLAC. Поэтому она была удалена из-под структуры места и добавлена в структуру <<EVENT_DETAIL>> на том же уровне, что и PLAC. Тег SITE также был удалён из структуры PLAC, поскольку место события фактически является частью адреса, например, Primary Children's Hospital, 100N Medical Drive, Salt Lake City, Utah.

! Дополнительные атрибуты или факты:

Иногда другие атрибуты или факты используются для описания действий человека, его физических данных, работы, образования, места жительства и т. д. Они обычно не рассматриваются как события. Однако их часто описывают как события, поскольку они наблюдались в определённое время и/или в определённом месте. GEDCOM 5.x перечисляет эти атрибуты в разделе <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> и позволяет записывать их так же, как и события. Определение атрибута допускает значение на той же строке, что и тег атрибута. Кроме того, он позволяет передавать подчиненный период даты, место и/или адрес и т.д., как и события. Предыдущие версии, которые обрабатывали только тег и значение, можно прочитать как обычно, обработав детали подчиненного атрибута как исключение.

Изменения в версии 5.5 в результате обзора версии 5.4 (черновик)

! Добавлены теги для хранения подробных адресных фрагментов в структуре адреса.

! Добавлены префиксы имени, обозначающие прозвище и фамилию, в структуру личного имени. Удалено соглашение об указании прозвища в двойных кавычках. Это соглашение было введено в GEDCOM 5.4 (черновик).

! Добавлена ссылка на подчиненный источник в структуру примечаний.

! Добавлены правила кодирования для включения встроенных мультимедийных объектов. (Удалено в версии 5.51)

! Добавлен тег RIN в структуры записей. Тег RIN — это идентификатор записи, назначенный записи исходным программным обеспечением. Его предназначение — обеспечить автоматизированный доступ к этой записи при получении возвратных транзакций или других процессах сверки.

! Значение тега GEDCOM без значения в строке зависит от его подчиненного контекста для любых утверждений, предполагаемых исследователем. Например, в структуре события подчиненные значения DATE и/или PLAC подразумевают, что событие произошло. Однако подчиненные контексты NOTE или SOUR сами по себе не подразумевают, что событие произошло. Чтобы исследователь мог указать, что событие произошло, не зная дату или место, необходимо добавить значение «Y» (yes) к строке тега события. Использование этого соглашения защищает процессоры GEDCOM, которые могут удалять (обрезать) строки без значения, а также не иметь подчиненных строк. Значение N (no) не должно использоваться в строке тега события для утверждения, что событие никогда не происходило. Для этого требуется определение другого тега.

! Возвращена управляющая последовательность календаря для поддержки альтернативных календарей.

! Определение значения даты было уточнено и теперь включает множество потенциальных способов, которыми пользователь может задать неточную дату в поле текста свободной формы. Системы, которые помогают пользователям вводить дату, не должны приводить к такому точному указанию неточной даты. Например, если программа должна была определить дату свадьбы на основе алгоритма, включающего дату рождения первого ребёнка пары, то вместо «EST ABT 1881» следовало бы использовать «EST 1881».

! Были добавлены следующие теги:

ADR1, ADR2, CITY, NICK, POST, SPFX

Изменения, внесенные или измененные в черновике версии 5.4

Некоторые изменения, внесенные в черновик GEDCOM версии 5.4, несовместимы с более ранними черновиками форм 5.x. Некоторые концепции были удалены с целью их реализации в будущем выпуске GEDCOM. Следующие функции являются либо новыми, либо отличающимися:

! Использование SCHEMA было исключено. Хотя концепция схемы является допустимой и необходимой для развития GEDCOM, она слишком сложна и преждевременна для успешного внедрения в текущие продукты. Слишком ранняя реализация может привести к тому, что разработчики потратят много ресурсов на программирование того, что очень быстро устареет. Языки определения объектов, вероятно, будут способствовать удовлетворению этих потребностей.

! Контекст EVENT_RECORD был удален. Этот контекст предназначался для поддержки концепции записи данных в форме GEDCOM, которая оказалась сложнее, чем предполагалось изначально. Понимание разницы между ролью исходной записи и ролью так называемой записи-свидетельства требует дальнейшего изучения.

! Нестандартные теги (см. <NEW_TAG>) могут использоваться в передаче GEDCOM, при условии, что первый символ — это подчеркивание (например, _NUTAG). Нестандартные теги следует использовать только в тех случаях, когда структурированная информация не может быть представлена в существующем контексте. Использование поля «Примечание» — более универсальный способ передачи генеалогических данных, которые не вписываются в стандартную структуру GEDCOM.

! Структура SOURCE_RECORD была упрощена до пяти основных разделов: данные или классификация, автор, название, факты публикации и репозиторий. Раздел данных или классификации содержит информацию о данных, представленных этим источником, и используется для анализа коллекции источников, использованных исследователем. Разделы «автор», «название», «факты публикации» и «репозиторий» представляют собой текстовые блоки свободной формы, которые информируют последующих исследователей о том, как получить доступ к исходным данным, использованным первоначальным исследователем.

! Добавлена структура <<SOURCE_CITATION>>, подчиненная цитируемому факту. Как правило, лучше всего, если ссылка на источник содержит только информацию, относящуюся к цитируемому факту, а затем указывает на более общее описание источника, определенное в SOURCE_RECORD. Это уменьшает избыточность, дает возможность контролировать размер записи GEDCOM и более точно представляет нормализованную модель данных.

! Системы, описывающие источники с помощью полей AUTH, TITL, PUBL и REPOS, могут и должны всегда передавать эту информацию в GEDCOM, используя запись SOUR, на которую указывает <<SOURCE_CITATION>>. Системы, допускающие только свободные примечания к источнику, должны поощрять формирование информации об источнике таким образом, чтобы она включала текст, содержащий информацию о следующих категориях:

! TITL: Описательное название источника

! AUTH: Автор работы

! PUBL: Когда и где она была создана

! REPO: Где его можно получить или просмотреть?

По возможности укажите теги для этих категорий в тексте, чтобы принимающая система могла

анализировать их в соответствии с рекомендуемой структурой источника/цитирования.

! Некоторые атрибуты INDI, такие как EDUC (образование), OCCU (профессия), RESI (проживание) или TITL (титул), должны быть описаны с использованием даты и места. Поэтому структура описания этих атрибутов была отформатирована так же, как и для описания событий. То есть эти атрибуты дополнительно определяются с использованием даты, места и других атрибутов, используемых для описания событий. (См. <<EVENT_DETAIL>>, и <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>)

! Структура таинства LDS была расширена и теперь включает место проведения таинства. Строка с тегом TYPE была изменена на строку с тегом STAT. Это позволяет удалять из строки даты такие утверждения, как BIC, отменено, младенец и т.д., и добавлять их сюда под тегом STAT. (См.<LDS_(ordinance)_DATE_STATUS>), где (ordinance) представляет собой любое из следующих: BAPTISM (КРЕЩЕНИЕ), ENDOWMENT (ОБРУЧЕНИЕ), CHILD_SEALING (ЗАПЕЧАТЛЕНИЕ_РЕБЕНКА) или SPOUSE_SEALING (ЗАПЕЧАТЛЕНИЕ_СУПРУГА).

! В предыдущих версиях GEDCOM 5.x структура указателя FAMC перегружалась подчинёнными событиями, которые связывали отдельные события и связанную с ними семью. Например, событие усыновления показывалось подчинённым указателю FAMC, чтобы указать, какая семья является приёмной. Событие запечатывания ребёнка с родителем (SLGC) также отображалось таким же образом. GEDCOM 5.4 распознаёт, что это события и должны находиться на том же уровне, что и другие отдельные события. Чтобы показать связанную семью, подчинённый указатель FAMC помещается подчинённым соответствующему событию. (См.<<INDIVIDUAL_EVENT_STRUCTURE>> и LDS_INDIVIDUAL_ORDINANCE )

! К формату даты был добавлен модификатор даты (int), указывающий на то, что соответствующая фраза даты была интерпретирована, и интерпретация следует за префиксом int в поле даты. Фраза даты также включается в значение даты, заключенное в скобки. (См. <DATE_APPROXIMATED>)

! Определение примитива <AGE_AT_EVENT> теперь включает ключевые слова METRBORN, INFANT и CHILD. Эти слова следует интерпретировать как приблизительный возраст на момент события. (См.<AGE_AT_EVENT>)

! Контекст семейного события в записи FAM теперь позволяет отображать возраст как мужа, так и жены на момент события. (См. FAM_RECORD)

! Структура <<PERSONAL_NAME_STRUCTURE>> теперь позволяет специально идентифицировать части имени как подчиненные части строки имени. Большинство продуктов не используют подчиненные части имени. Псевдоним теперь можно включить в строку имени, заключив его в двойные кавычки (изменено в версии 5.5.) Примечание: Системы, использующие подчиненные части имени, должны по-прежнему предоставлять структуру имени, сформированную таким же образом, как указано для <NAME_PERSONAL>.

! В GEDCOM была добавлена запись отправки, позволяющая отправляющей системе передавать информацию, которая позволит принимающей системе более эффективно обрабатывать данные GEDCOM. Формат, разработанный в настоящее время для записи отправки, был создан специально для системы TempleReady™ и для файлов GEDCOM, загружаемых из Ancestral File™. (См. SUBMISSION_RECORD)

! Тег RESN (RESTRICTION) и примитив <RESTRICTION_NOTICE> были добавлены в контекст INDIVIDUAL_RECORD. (Также добавлены в семейную запись в 5.5.1.) Это позволяет пометить некоторые записи в Ancestral File как конфиденциальные (указывая на то, что некоторая личная информация не включена), а некоторые записи — как заблокированные (указывая, что Ancestral File не будет вносить изменения в запись без разрешения назначенного ответственного за запись).

! Следующие теги больше не используются в форме, связанной с родословной:

ARVL, BROT, BUYR, CEME, CNTC, CPLR, DEFM, DPRT, EDTR, FIDE, FILM, GODP, HDOH,

HEIR, HFAT, HMOT, INFT, INDX, INTV, ISA, ISSU, ITEM, LABL, LCCN, LGTE, MBR,

NAMS, NAMR, OFFI, ORIG, OWNR, PERI, PORT, PWIF, PUBR, RECO, SELR, SEQU, SERS,

SIBL, SIGN, SIST, SITE, TXPY, XLTR, WFAT, WITN, WMOT, AUDIO, IMAGE, PHOTO,

SCHEMA, VIDEO

! Добавлены следующие теги:

BLOB, CTRY, CREM, FCOM, GIVN, NPFX, NSFX, OBJE, PEDI, RELA, RESI, RESN, SUBN,

SURN, STAT

Изменения, внесённые в черновую версию 5.3

В версии 5.3 в стандарт GEDCOM были внесены следующие изменения:

! Была определена структура адреса.

! В структуру события был добавлен новый тег для семейного положения (MSTA) на момент события. (Это было удалено в версии 5.4.)

! Был добавлен механизм создания пользовательских тегов. Они были определены в определении SCHEMA в заголовочной записи версии 5.3. (SCHEMA была удалена в версии 5.4.)

! Стандарт Unicode (ISO 10646) был введён в качестве дополнительного набора символов. (Это было сокращено до потенциального набора символов в версии 5.4. См. Главу 3)

! Была введена структура <<MULTIMEDIA_LINK>> для обеспечения связывания и встраивания оцифрованных фото-, видео- и аудиофайлов. (Это было изменено в версии 5.4). (См.

MULTIMEDIA_LINK и MULTIMEDIA_RECORD)

! Тег NAME структуры источника, означающий название источника в <<SOURCE_CITATION>>, был изменён обратно на тег TITL и используется для отображения названия книги, статьи или описательного названия источников без названия.

! Тег <<SOURCE_CITATION>> был изменён. Использование тегов CPLR, XLTR и INFT в подструктурах источника прекращено.

! Тег FORM {FORMAT} был добавлен в качестве подчинённого тегам PLAC и GEDC в записи HEADER, а также подчинённого тегу PLAC в <<PLACE_STRUCTURE>>. Строка PLAC.FORM в заголовке указывает, что все названия населённых пунктов указаны в последовательной иерархической последовательности, заданной значением FORM. Например: 2 FORM Город, Округ, Штат. В GEDCOM 5.2 для этой цели использовался тег TYPE, подчинённый тегу PLAC вместо тега FORM. Это положение применимо к продуктам с чрезмерно структурированным значением места.

Упаковка файла передачи GEDCOM

Передача GEDCOM обычно создаётся на совместимой с DOS или Macintosh® дискете.

Тут нужно учитывать, что GEDCOM версии 5.5, был выпущена в начале 1996 года, а версия 5.5.1 в 1999 году.

Расширение имени файла в DOS — (.GED). В именах файлов Macintosh расширения не используются.

Если файл GEDCOM слишком большой для размещения на одной дискете, файл разделяется после каждой целой строки (последний символ — это терминатор), и расширение имени файла DOS становится (G##), где (##) — это (00) для второго диска, (01) для третьего и так далее. Для имён файлов Macintosh добавьте две цифры к последующим именам файлов в скобках. (См. пример ниже.) Это позволяет принимающему программному обеспечению гарантировать, что диски считываются в правильной последовательности.

Учитывая, что пользовательская часть имени файла — SMITH, то полные имена файлов для передачи на трёх дисках будут следующими:

Disk DOS Filename Macintosh Filename

1 SMITH.GED SMITH

2 SMITH.G00 SMITH(00)

3 SMITH.G01 SMITH(01)

Обязательная запись GEDCOM HEAD присутствует только на первом диске, а обязательная запись TRLR (концевик) присутствует только на последнем диске и должна сопровождаться терминатором.

Пользовательские теги

Мы не рекомендуем использовать пользовательские теги GEDCOM. Приложения, требующие использования нестандартных тегов, должны определять их с помощью начального подчеркивания, чтобы они не конфликтовали с будущими стандартными тегами GEDCOM. Системы, считывающие пользовательские теги, должны учитывать, что они имеют значение только относительно системы, содержащейся в контексте HEAD.SOUR.

Формат управляющей последовательности

Очень немногие системы, совместимые с GEDCOM, связанной с родословной, используют функцию управляющей последовательности, предусмотренную в грамматике GEDCOM.

Пример передачи GEDCOM

Пример ниже представляет собой пример передачи генеалогической информации о трёх людях, являющихся членами одной семьи — отце, матери и ребёнке. В этом примере «Джо/Уильямс/» — это значение, указанное тегом NAME под тегом INDI для записи (@3@). Другие значения в других строках, такие как дата и место рождения, предоставляют дополнительную информацию о Джо Уильямсе. Значение (@4@), указанное тегом FAMC, является указателем на запись FAM_RECORD (@4@), потомком которой является Джо Уильямс. В этот пример передачи также включены три других типа записей: исходная запись, запись отправителя и запись репозитория. На эти записи ссылаются другие записи в передаче. Это показывает, как значения указателей можно использовать при создании GEDCOM.

Пример: (Отступы добавлены только для удобства чтения.)

0 HEAD

1 SOUR PAF

2 VERS 2.1

1 DEST ANSTFILE

1 SUBM @5@

1 SUBN @8@

1 GEDC

2 VERS 5.4

2 FORM Lineage-Linked

1 CHAR ANSEL

0 @1@ INDI

1 NAME Robert Eugene/Williams/

1 SEX M

1 BIRT

2 DATE 02 OCT 1822

2 PLAC Weston, Madison, Connecticut

2 SOUR @6@

3 PAGE Sec. 2, p. 45

3 EVEN BIRT

4 ROLE CHIL

1 DEAT

2 DATE 14 APR 1905

2 PLAC Stamford, Fairfield, CT

1 BURI

2 PLAC Spring Hill Cem., Stamford, CT

1 RESI

2 ADDR 73 North Ashley

3 CONT Spencer, Utah UT84991

2 DATE from 1900 to 1905

1 FAMS @4@

1 FAMS @9@

0 @2@ INDI

1 NAME Mary Ann/Wilson/

1 SEX F

1 BIRT

2 DATE BEF 1828

2 PLAC Connecticut

1 FAMS @4@

0 @3@ INDI

1 NAME Joe/Williams/

1 SEX M

1 BIRT

2 DATE 11 JUN 1861

2 PLAC Idaho Falls, Bonneville, Idaho

2 FAMC @4@ /* примечание: это не является обязательным, но разрешен в версии 5.5 */

1 FAMC @4@

1 FAMC @9@

2 PEDI Adopted

1 ADOP

2 FAMC @9@

2 DATE 16 MAR 1864

1 SLGC

2 FAMC @9@

2 DATE 2 OCT 1987

2 TEMP SLAKE

0 @4@ FAM

1 MARR

2 DATE DEC 1859

2 PLAC Rapid City, South Dakota

1 SLGS

2 DATE 14 JUN 1975

2 TEMP SLAKE

1 HUSB @1@

1 WIFE @2@

1 CHIL @3@

0 @5@ SUBM

1 NAME Reldon /Poulson/

1 ADDR 1900 43rd Street West

2 CONT Billings, MT 68051

1 PHON (406) 555-1232

0 @6@ SOUR

1 DATA

2 EVEN BIRT, DEAT, MARR

3 DATE FROM Jan 1820 TO DEC 1825

3 PLAC Madison, Connecticut

2 AGNC Madison County Court, State of Connecticut

1 TITL Madison County Birth, Death, and Marriage Records

1 ABBR VITAL RECORDS

1 REPO @7@

2 CALN 13B-1234.01

3 MEDI Microfilm

0 @7@ REPO

1 NAME Family History Library

1 ADDR 35 N West Temple Street

2 CONT Salt Lake City, Utah

2 CONT UT 84150

0 @8@ SUBN

1 SUBM @5@

1 FAMF Reg Poulson Family

1 TEMP SLAKE

0 @9@ FAM

1 HUSB @1@

1 CHIL @3@

0 TRLR

Ниже приведён пример SOURCE_CITATION, подчинённого цитируемому событию о рождении, который не содержит указателя на SOURCE_RECORD. (Это не рекомендуется.)

0 INDI

1 NAME Fred /Jones/

1 BIRT

2 DATE 14 MAY 1812

2 PLAC Tonbridge, Kent, England

2 SOUR Waters, Henry F., Genealogical Gleanings in England: Abstracts of W

3 CONC ills Relating to Early American Families. 2 vols., reprint 1901, 190

3 CONC 7. Baltimore: Genealogical Publishing Co., 1981.

3 CONT Stored in Family History Library book 942 D2wh; films 481,057-58 Vol 2, pa

3 CONC ge 388.

Глава 3

Использование наборов символов в GEDCOM

Введение

GEDCOM должен поддерживать различные наборы символов для облегчения обмена генеалогическими данными на разных языках. Чтобы минимизировать количество различных стандартов, мы решили, что каждая система перейдет на ANSEL, а затем на UNICODE.

В настоящее время ANSEL используется для представления латинских символов.

Стандарт GEDCOM не рассматривает методы реализации многоязычной обработки, такие как раскладка клавиатуры, последовательности сортировки или представление символов и графики (стили шрифтов, пропорциональные интервалы и т. д.) на ЭЛТ-дисплеях или принтерах. Однако стандарт Unicode определяет символы форматирования, которые будут указывать направление представления текста, и другие коды символов форматирования текста.

Системы, использующие кодовые страницы для поддержки диакритических символов, такие как кодовая страница Windows ANSI 1252, должны преобразовывать все символы с кодом выше 0x7F в их представление ANSEL для этой кодовой страницы.

Большинство разработанных на сегодняшний день генеалогических систем используют ASCII, ANSEL или оба формата. ANSEL поддерживает множество языков на основе латиницы, как описано ниже.

8-битный ANSEL

8-битный ANSEL (Американский национальный стандарт расширенного набора кодированных символов латинского алфавита для библиографического использования, авторское право Z39.47-1985) в настоящее время является предпочтительным набором символов для GEDCOM. Однако вскоре он будет заменен на UNICODE и UTF-8, поскольку поддержка этих последних форматов символов станет полностью поддерживаться компьютерной индустрией.

Набор символов ANSEL позволяет сохранить целостность большинства языков на основе латиницы, предоставляя метод использования стандартного набора символов ASCII и дополняя его как модификаторами символов без пробелов (диакритическими знаками), так и некоторыми полезными спецсимволами для пробелов.

Примечание: Без пробелов диакритический знак печатается без смещения позиции печати устройства. Изменяемый символ затем печатается в той же позиции, что приводит к объединенному изображению как самого символа, так и диакритического знака(ов).

Для хранения ANSEL необходимо сохранить непробельные графические символы, предшествующие символу ASCII, который должен модифицироваться диакритическим знаком. Стандарт ANSEL определяет расширенную 8-битную конфигурацию (более 128) для представления пробельных и непробельных графических символов, составляющих большинство языков на основе латиницы. ANSEL — это надмножество ASCII. Стандартные символы ASCII, включая управляющие символов, сохраняются.

ANSEL известен под двумя другими названиями:

! ANSI Z39.47-1985

! набор символов Американской библиотечной ассоциации, используемый в библиотечных системах по всему миру, включая формат MARC (машиночитаемый каталог).

Коды, используемые для набора символов ANSEL, описаны в Приложении C. Полное определение можно приобрести в:

American National Standards Institute

1430 Broadway

New York, N.Y. 10018

Коды наборов символов от 0x0 до 0x7F одинаковы для 8-битного ANSEL и 8-битного ASCII (версия для США — ANSI 8-Bit). Коды наборов символов от 0x80 до 0xFF уникальны для набора символов ANSEL.

ASCII (версия для США)

Если языку не требуются диакритические знаки или другие специальные символы, и вы не передаёте двоичные данные, вам будет удобно использовать ASCII (8-битная версия для США), если ваш компьютер уже поддерживает её. Это стандарт Американского национального института стандартов (ANSI). Большинство основных печатных символов ANSEL и ASCII (версия для США — ANSI 8-бит) идентичны.

UNICODE

Стандарт Unicode — это кодировка символов, предназначенная для кодирования текста для хранения в компьютерных файлах. Он разрабатывается в тесном сотрудничестве со стандартом ISO 10646. Конструкция стандарта Unicode основана на простоте и согласованности распространённого сегодня набора кодов символов, расширенного набора кодов ASCII, но выходит далеко за рамки ограниченной возможности ASCII кодировать только латинский алфавит: кодировка Unicode обеспечивает возможность кодирования практически всех символов, используемых в письменных языках мира. Для размещения многих тысяч символов, используемых в международном тексте, стандарт Unicode использует 16-битный кодовый набор вместо 8-битного расширенного ASCII. Это расширение предоставляет коды примерно для 65 000 символов. Текстовое представление 16-битных чисел Unicode – U+0041, что соответствует букве A с десятичными 65. Стандарт Unicode включает символы латинского алфавита (английский), кириллицы (русский), греческого, иврита и арабского алфавитов. Также включены другие алфавиты, используемые в странах Европы, Африки, Индийского субконтинента и Азии, такие как японская кана, корейский хангыль и китайский бопомофо. (См. «Стандарт Unicode версии 2.0», опубликованный Addison-Wesley Publishing, для получения информации о стандартах кодировки символов.)

Если для передачи GEDCOM используется среда Unicode, запись заголовка также будет в Unicode, что потребует от принимающих систем определить, относится ли передача к Unicode или ASCII, прежде чем они смогут интерпретировать заголовок GEDCOM.

UTF-8

UTF-8 — это формат преобразования, позволяющий преобразовывать символы Unicode в 8-битную форму. Схема преобразования позволяет представлять существующие символы ASCII в диапазоне от 0x0 до 0x7F с помощью обычного 8-битного кода. Символы из набора символов Unicode в диапазоне от U+0080 до U+07FF могут быть представлены двумя 8-битными кодами, а символы из диапазона от U+0800 до U+FFFF — тремя 8-битными кодами. Этот метод используется многими системами, обрабатывающими преимущественно латинские символы, для экономии значительного объема памяти. Метод преобразования UTF-8 обеспечивает эффективное преобразование в текст Unicode и обратно. По сути, эта 8-битная форма использует старшие биты для определения способа декодирования каждой из 8-битных форм обратно в представление Unicode.

Как изменить набор символов

Набор символов для всей передачи указывается в строке набора символов записи заголовка. В примере ниже показана спецификация в заголовочной записи:

0 HEAD

1 SOUR PAF

2 VERS 2.1

1 DEST ANSTFILE

1 CHAR ANSEL

Изменение набора символов остается в силе до тех пор, пока в конце передачи не будет обнаружена запись TRLR.

Набор символов UNICODE или 8-битная форма UTF-8 должны использоваться для поддержки нескольких языков, как только операционные системы начнут обеспечивать адекватную поддержку хранения и отображения.

Для получения дополнительной информации о наборах символов см.:

!Расширенный набор кодированных символов латинского алфавита для библиографического использования. Американские национальные стандарты (ANSEL), Z39.47, 1985. Это устаревшая версия, но она является версией, установленной в качестве стандарта GEDCOM ANSEL.

!"Стандарт Unicode", версия 2.0, опубликовано Addison-Wesley Publishing.

Глава 4

Регистрация продукта GEDCOM

Регистрация продуктов GEDCOM

Разработчики продуктов, совместимых с GEDCOM, должны зарегистрировать свой продукт у координатора GEDCOM Family History Department (отдела семейной истории).

Регистрация означает, что:

Зарегистрированный продукт GEDCOM указан в публикациях Отдела семейной истории как совместимый с GEDCOM 5.5.
Пример выходного файла продукта проверен в соответствии с установленным стандартом, и отмечены исключения.
Разработчик будет уведомлен о будущих проблемах с GEDCOM.
Заявки в файлы ресурсов Отдела семейной истории принимаются от пользователей зарегистрированных продуктов.

Чтобы зарегистрировать продукт GEDCOM, разработчик должен отправить координатору GEDCOM следующую информацию:

Файл, содержащий небольшой пример выходных данных GEDCOM продукта для оценки. Все поля, которые обрабатывает продукт, должны быть включены в эти данные для проверки совместимости с продуктами других разработчиков.
Предлагаемое уникальное имя SOUR, идентифицирующее продукт, а не компанию. Этот идентификатор должен быть включен в запись заголовка GEDCOM в качестве значения тега SOUR. Это имя может содержать до 40 символов, может содержать как заглавные, так и строчные буквы и не может содержать пробелов. Используйте либо подчеркивание (_) для соединения нескольких слов, либо комбинацию заглавных и строчных букв (например, FamilyRecords или Family_Records, а не Family Records). Отдел семейной истории обеспечит уникальность в пределах первых 10 символов этого имени.
Необязательно, но настоятельно рекомендуется, копия продукта GEDCOM с инструкциями по установке и текстовый файл, содержащий соответствующую техническую документацию о реализации GEDCOM в продукте.

Продукт будет защищен и использоваться только для проверки выходных данных GEDCOM и для оказания некоторой поддержки пользователям, отправляющим заявки на ваш продукт.

Информацию о регистрации продукта отправляйте по адресу:

E-mail: gedcom@gedcom.org

Почтовый адрес:

Family History Department

GEDCOM Coordinator— 3T

50 East North Temple Street

Salt Lake City, UT 84150

Телефоны (США): 801-240-4534, 801-240-3442

Приложение A

Определение тегов GEDCOM

Введение

Приложение A представляет собой глоссарий тегов, используемых в форме GEDCOM, связанной с родословной. Эти теги используются в иерархической структуре для описания отдельных лиц с точки зрения их семей, имён, дат, мест, событий, ролей, источников, родственных связей. Также включена управляющая информация и другие виды данных, предназначенные для компьютерной обработки. (Пример тегов, используемых в форме GEDCOM) Для обеспечения единообразной идентификации всей передаваемой информации в форме GEDCOM, стандартизированные теги не могут быть помещены в какой-либо другой контекст, кроме указанного в Главе 2. Контекст формы можно расширять, но только используя определяемые пользователем теги, которые должны начинаться с символа подчеркивания. Это не нарушает стандарт GEDCOM, если не нарушается контекст грамматики формы GEDCOM. Использование подчёркивания в имени пользовательского тега указывает на использование нестандартной конструкции. Это уведомляет систему чтения о несоответствии и позволит избежать будущих конфликтов с тегами, которые могут быть стандартизированы в последующих выпусках GEDCOM.

Определения тегов GEDCOM

В этом разделе приведены определения стандартизированных тегов GEDCOM и их формальные имена указаны внутри {фигурных скобок}. Формальные имена не используются вместо тега. Полное понимание должно исходить из контекста, в котором используется тег.

ABBR {ABBREVIATION}:=

Краткое название титула, описания или имени.

ADDR {ADDRESS}:=

Современное местонахождение, обычно необходимое для почтовых целей, физического лица, отправителя информации, хранилища, предприятия, школы или компании.

ADR1 {ADDRESS1}:=

Первая строка адреса.

ADR2 {ADDRESS2}:=

Вторая строка адреса.

ADOP {ADOPTION}:=

Относится к созданию юридически оформленных отношений между ребенком и родителем, которые не существуют биологически. Например усыновление.

AFN {AFN}:=

Уникальный постоянный номер файла записи для индивидуальной записи, хранящейся в системе Ancestral File.

AGE {AGE}:=

Возраст лица на момент события или возраст, указанный в документе.

AGNC {AGENCY}:=

Учреждение или лицо, имеющие полномочия и/или обязанность управлять или руководить.

ALIA {ALIAS}:=

Указатель для связи между различными описаниями записей о лице, которое может быть одним и тем же лицом.

ANCE {ANCESTORS}:=

Относится к предкам лица.

ANCI {ANCES_INTEREST}:=

Указывает на заинтересованность в дополнительных исследованиях предков данного лица. (См. также DESI)

ANUL {ANNULMENT}:=

Признание брака недействительным с самого начала (никогда не существовавшего).

ASSO {ASSOCIATES}:=

Указатель для связи между друзьями, соседями, родственниками или соратниками лица.

AUTH {AUTHOR}:=

Имя лица, создавшего или составившего информацию.

BAPL {BAPTISM-LDS}:=

Крещение, совершаемое в возрасте восьми лет или старше властью священства Церкви LDS. (См.также BAPM, далее)

BAPM {BAPTISM}:=

Крещение (не LDS), совершаемое в младенчестве или позже. (См. также BAPL, выше, и CHR)

BARM {BAR_MITZVAH}:=

Церемониальное событие, проводимое еврейским мальчиком по достижении 13 лет.

BASM {BAS_MITZVAH}:=

Церемониальное событие, проводимое еврейской девочкой по достижении 13 лет, также известное как «бат-мицва».

BIRT {BIRTH}:=

Событие вступления в жизнь.

BLES {BLESSING}:=

Религиозное событие дарования божественной заботы или заступничества. Иногда проводится в связи с церемонией имянаречения.

BURI {BURIAL}:=

Событие надлежащего захоронения останков умершего человека.

CALN {CALL_NUMBER}:=

Номер, используемый хранилищем для идентификации конкретных предметов в своих коллекциях.

CAST {CASTE}:=

Название ранга или статуса человека в обществе, которое иногда основано на расовых или религиозных различиях, а также на различиях в имуществе, унаследованном положении, профессии, роде занятий и т. д.

CAUS {CAUSE}:=

Описание причины соответствующего события или факта, например, причины смерти.

CENS {CENSUS}:=

Событие периодического подсчёта населения в определённом населённом пункте, например, национальная или государственная перепись.

CHAN {CHANGE}:=

Обозначает изменение, исправление или модификацию. Обычно используется вместе с DATE для указания даты изменения информации.

CHAR {CHARACTER}:=

Указатель набора символов, используемого при записи этой информации.

CHIL {CHILD}:=

Родной, усыновлённый или запечатанный (LDS) ребёнок отца и матери.

CHR {CHRISTENING}:=

Религиозное событие (не LDS) крещения и/или наречения имени ребёнка.

CHRA {ADULT_CHRISTENING}:=

Религиозное событие (не LDS) крещения и/или наречения имени взрослого человека.

CITY {CITY}:=

Юрисдикционная единица низшего уровня. Обычно муниципальная единица.

CONC {CONCATENATION}:=

Указатель принадлежности дополнительных данных к вышестоящему значению. Информация из значения CONC должна быть присоединена к значению вышестоящей предыдущей строки без пробела и без символа возврата каретки и/или символа новой строки. Значения, разделяемые тегом CONC, всегда должны быть разделены не пробелом. Если значение разделено пробелом, при конкатенации пробел будет потерян. Это связано с тем, что пробелы рассматриваются как разделители GEDCOM. Многие значения GEDCOM обрезаются от конечных пробелов, а некоторые системы ищут первый непробел, начинающийся после тега, чтобы определить начало значения.

CONF {CONFIRMATION}:=

Религиозное событие (не LDS) – дарование дара Святого Духа и, среди протестантов, полноправного членства в церкви.

CONL {CONFIRMATION_LDS}:=

Религиозное событие, в результате которого человек получает членство в Церкви LDS.

CONT {CONTINUED}:=

Указатель принадлежности дополнительных данных к вышестоящему значению. Информация из значения CONT должна быть соединена со значением вышестоящей предшествующей строки символом возврата каретки и/или символом новой строки. Начальные пробелы могут иметь важное значение для форматирования результирующего текста. При импорте значений из строк CONT читатель должен предполагать наличие только одного символа-разделителя после тега CONT. Остальные начальные пробелы следует считать частью значения.

COPR {COPYRIGHT}:=

Заявление, сопровождающее данные, для защиты их от незаконного копирования и распространения.

CORP {CORPORATE}:=

Название учреждения, агентства, корпорации или компании.

CREM {CREMATION}:=

Утилизация останков человека путём сжигания.

CTRY {COUNTRY}:=

Название или код страны.

DATA {DATA}:=

Относится к хранимой автоматизированной информации.

DATE {DATE}:=

Время события в календарном формате.

DEAT {DEATH}:=

Событие, завершающее смертную жизнь.

DESC {DESCENDANTS}:=

Относится к потомкам человека.

DESI {DESCENDANT_INT}:=

Указывает на интерес к исследованиям по выявлению дополнительных потомков этого человека. (См. также ANCI)

DEST {DESTINATION}:=

Система, получающая данные.

DIV {DIVORCE}:=

Событие расторжения брака в гражданском порядке.

DIVF {DIVORCE_FILED}:=

Событие подачи заявления на развод супругом/супругой.

DSCR {PHY_DESCRIPTION}:=

Физические характеристики человека, места или вещи.

EDUC {EDUCATION}:=

Указатель уровня полученного образования.

EMAI {EMAIL}:=

Адрес электронной почты.

EMIG {EMIGRATION}:=

Событие, связанное с выездом из родной страны с намерением переехать в другое место.

ENDL {ENDOWMENT}:=

Религиозное событие, при котором таинство облечения человека совершается должностным лицом священства в храме LDS.

ENGA {ENGAGEMENT}:=

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

EVEN {EVENT}:=

Относится к значимому событию, связанному с отдельным лицом, группой или организацией. Структура EVEN обычно уточняется или классифицируется с помощью подчинённого тега TYPE.

FACT {FACT}:=

Относится к значимому атрибуту или факту, касающемуся отдельного лица, группы или организации. Структура FACT обычно уточняется или классифицируется посредством использования подчинённого тега TYPE.

FAM {FAMILY}:=

Определяет юридические, основанные на общем праве или иные основанные на обычае отношения между мужчиной и женщиной и их детьми, если таковые имеются, или семью, созданную в результате рождения ребёнка у его биологических отца и матери.

FAMC {FAMILY_CHILD}:=

Определяет семью, в которой человек указан как ребёнок.

FAMF {FAMILY_FILE}:=

Относится к семейному файлу или является его названием. Имена, хранящиеся в файле и назначенные семье для выполнения храмовых таинств.

FAMS {FAMILY_SPOUSE}:=

Определяет семью, в которой человек указан как супруг(а).

FAX {FACIMILIE}:=

Электронная передача данных.

FCOM {FIRST_COMMUNION}:=

Религиозный обряд, первый акт участия в Вечере Господней в рамках церковного богослужения.

FILE {FILE}:=

Место хранения информации, упорядоченное и организованное для сохранения и использования в качестве справочника.

FORM {FORMAT}:=

Название, присвоенное единому формату, в котором может быть передана информация.

FONE {PHONETIC}:=

Фонетический вариант основной текстовой строки

GEDC {GEDCOM}:=

Информация об использовании GEDCOM в передаче.

GIVN {GIVEN_NAME}:=

Присвоенное или полученное имя, используемое для официальной идентификации человека.

GRAD {GRADUATION}:=

Событие вручения дипломов об образовании или степеней отдельным лицам.

HEAD {HEADER}:=

Идентифицирует информацию, относящуюся ко всей передаче GEDCOM.

HUSB {HUSBAND}:=

Человек, исполняющий обязанности женатого мужчины или отца.

IDNO {IDENT_NUMBER}:=

Номер, присвоенный для идентификации человека в какой-либо значимой внешней системе.

IMMI {IMMIGRATION}:=

Событие въезда в новое место жительства.

INDI {INDIVIDUAL}:=

Человек.

LANG {LANGUAGE}:=

Название языка, используемого при общении или передаче информации.

LATI {LATITUDE}:=

Значение, указывающее координатное положение на линии, плоскости или в пространстве.

LONG {LONGITUDE}:=

Значение, указывающее координатное положение на линии, плоскости или в пространстве.

MAP {MAP}:=

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

MARB {MARRIAGE_BANN}:=

Событие официального публичного уведомления о намерении двух людей вступить в брак.

MARC {MARR_CONTRACT}:=

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

MARL {MARR_LICENSE}:=

Событие получения законного разрешения на брак.

MARR {MARRIAGE}:=

Юридическое, основанное на общем праве или обычае событие создания семьи мужчиной и женщиной как мужем и женой.

MARS {MARR_SETTLEMENT}:=

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

MEDI {MEDIA}:=

Определяет информацию о носителе или имеющую отношение к носителю, на котором хранится информация.

NAME {NAME}:=

Слово или сочетание слов, используемое для идентификации человека, титула или другого объекта. Для людей, известных под несколькими именами, следует использовать более одной строки NAME.

NATI {NATIONALITY}:=

Национальное происхождение человека.

NATU {NATURALIZATION}:=

Событие получения гражданства.

NCHI {CHILDREN_COUNT}:=

Количество детей, которых данное лицо, как известно, является родителем (всех браков), если оно подчинено человеку, или которые принадлежат к данной семье, если оно подчинено FAM_RECORD.

NICK {NICKNAME}:=

Описательное или фамильярное имя, которое используется вместо или в дополнение к собственному имени.

NMR {MARRIAGE_COUNT}:=

Сколько раз данное лицо участвовало в жизни семьи в качестве супруга или родителя.

NOTE {NOTE}:=

Дополнительная информация, предоставленная отправителем для понимания прилагаемых данных.

NPFX {NAME_PREFIX}:=

Текст, который отображается в строке имени перед именем и фамилией.

Например, (Лейтенант-коммандер) Джозеф /Аллен/ мл.

В этом примере «Лейтенант-коммандер» считается префиксной частью имени.

NSFX {NAME_SUFFIX}:=

Текст, который отображается в строке имени после имени и фамилии или после них.

Например, «Лейтенант-коммандер» Джозеф /Аллен/ мл.

В этом примере «Младший» считается суффиксной частью имени.

OBJE {OBJECT}:=

Относится к группе атрибутов, используемых при описании чего-либо. Обычно относится к данным, необходимым для представления мультимедийного объекта, такого как аудиозапись, фотография человека или изображение документа.

OCCU {OCCUPATION}:=

Вид работы или профессии человека.

ORDI {ORDINANCE}:=

Относится к религиозному таинству в целом.

ORDN {ORDINATION}:=

Религиозное событие, связанное с получением полномочий на осуществление религиозных дел.

PAGE {PAGE}:=

Номер или описание, указывающее, где в указанном источнике можно найти информацию.

PEDI {PEDIGREE}:=

Информация, относящаяся к генеалогической схеме родословной человека.

PHON {PHONE}:=

Уникальный номер, присвоенный для доступа к определенному телефону.

PLAC {PLACE}:=

Юрисдикционное название для обозначения места или местоположения события.

POST {POSTAL_CODE}:=

Код, используемый почтовой службой для обозначения территории с целью упрощения обработки почты. Индекс.

PROB {PROBATE}:=

Событие судебного определения действительности завещания. Может указывать на несколько связанных судебных действий в течение нескольких дат.

PROP {PROPERTY}:=

Относится к имуществу, такому как недвижимость или другая собственность, представляющая интерес.

PUBL {PUBLICATION}:=

Указывает, когда и/или где произведение было опубликовано или создано.

QUAY {QUALITY_OF_DATA}:=

Оценка достоверности доказательств, подтверждающая вывод, сделанный на основе доказательств.

REFN {REFERENCE}:=

Описание или номер, используемые для идентификации элемента при архивировании, хранении или других справочных целях.

RELA {RELATIONSHIP}:=

Значение связи между указанными контекстами.

RELI {RELIGION}:=

Религиозная конфессия, к которой принадлежит человек или к которой относится запись.

REPO {REPOSITORY}:=

Учреждение или лицо, в коллекции(ях) которых находится указанный элемент.

RESI {RESIDENCE}:=

Адрес или место жительства, где проживала семья или отдельное лицо.

RESN {RESTRICTION}:=

Индикатор обработки, указывающий на то, что доступ к информации запрещён или иным образом ограничен.

RETI {RETIIREMENT}:=

Событие прекращения трудовых отношений с работодателем после истечения установленного срока.

RFN {REC_FILE_NUMBER}:=

Постоянный номер, присваиваемый записи, который однозначно идентифицирует её в известном файле.

RIN {REC_ID_NUMBER}:=

Номер, присвоенный записи исходной автоматизированной системой, который может использоваться принимающей системой для сообщения результатов, относящихся к этой записи.

ROLE {ROLE}:=

Название роли, исполняемой лицом в связи с событием.

ROMN {ROMANIZED}:=

Романизированный вариант главной текстовой строки.

SEX {SEX}:=

Указывает пол лица — мужской или женский.

SLGC {SEALING_CHILD}:=

Религиозное событие, связанное с запечатыванием ребёнка с его или её родителями в храмовой церемонии LDS.

SLGS {SEALING_SPOUSE}:=

Религиозное событие, связанное с запечатыванием брака мужа и жены в храмовой церемонии LDS.

SOUR {SOURCE}:=

Исходный материал, из которого была получена информация.

SPFX {SURN_PREFIX}:=

Фрагмент имени, используемый в качестве неиндексируемой части фамилии.

SSN {SOC_SEC_NUMBER}:=

Номер, присвоенный Управлением социального обеспечения США. Используется для налоговой идентификации.

STAE {STATE}:=

Географическое деление более крупной юрисдикционной территории, например, штата в составе Соединенных Штатов Америки.

STAT {STATUS}:=

Оценка состояния или состояния чего-либо.

SUBM {SUBMITTER}:=

Физическое лицо или организация, которые вносят генеалогические данные в файл или передают их кому-либо другому.

SUBN {SUBMISSION}:=

Относится к набору данных, переданных для обработки.

SURN {SURNAME}:=

Фамилия, передаваемая или используемая членами семьи.

TEMP {TEMPLE}:=

Название или код, представляющий название храма Церкви LDS.

TEXT {TEXT}:=

Точная формулировка, найденная в исходном документе.

TIME {TIME}:=

Значение времени в 24-часовом формате, включая часы, минуты и, возможно, секунды, разделённые двоеточием (:). Доли секунд отображаются в десятичном формате.

TITL {TITLE}:=

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

TRLR {TRAILER}:=

На уровне 0 указывает на окончание передачи GEDCOM.

TYPE {TYPE}:=

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

VERS {VERSION}:=

Указывает, какая версия продукта, элемента или публикации используется или упоминается.

WIFE {WIFE}:=

Физическое лицо, выступающее в роли матери и/или замужней женщины.

WILL {WILL}:=

Юридический документ, рассматриваемый как событие, посредством которого человек распоряжается своим имуществом, вступающее в силу после смерти. Датой события является дата подписания завещания при жизни человека. (См. также PROB)

WWW {WEB}:=

Домашняя страница в Интернете.