Loading article…
FamilySearch GEDCOM、または単にGEDCOM（/ ˈdʒɛdkɒm / JED - kom、 Genealogical Data Communicationの頭文字）は、オープンなファイル形式であり、系図データを保存するための事実上の標準仕様です。[ 3 ]これは、系図情報の調査と共有を支援するために、FamilySearchの運営者である末日聖徒イエス・キリスト教会（LDS教会）によって開発されました。 [ 4 ] 一般的な用途としては、さまざまな系図ソフトウェアやウェブサイト間で家系図データをバックアップおよび転送するための標準形式として使用され、それらのほとんどはGEDCOM形式からのインポートとエクスポートをサポートしています。[ 5 ]
GEDCOMは、バージョン7.0以降、UTF-8エンコーディングを使用するプレーンテキストファイルとして定義されています。このファイルには、名前、出来事、関係性など、個人に関する系譜情報が含まれており、メタデータによってこれらのレコードが相互にリンクされます。
2021年にリリースされたGEDCOM 7.0は、 2024年7月時点でのGEDCOM仕様の最新バージョンである。[ 6 ]しかし、その前身である GEDCOM 5.5.1 は、系図データの交換のための業界のフォーマット標準として残っています。1999年にドラフト標準として初めてリリースされた GEDCOM 5.5.1 は、2019 年に 5.5.1 の最終版がリリースされるまでの 20 年間、わずかな更新しか受けていません。その欠点に対処するため、一部の系図プログラムは、 GEDCOM 5.5 EL (Extended Locations) など、他のプログラムでは認識されない GEDCOM への独自の拡張機能を導入しました。[ 7 ] [ 8 ] [ 9 ]リリース以来、7.0 の採用がさらに広まるよう努力がなされてきました。FamilySearchは2022 年第 3 四半期に GEDCOM 7.0 と互換性を持つ予定であり、Ancestry.com は7.0 との互換性を計画していますが、実装日はまだ指定していません。
GEDCOM は、核家族の概念モデルに基づいた系統リンク型データモデルを使用しています。そのため、家族 ( ) レコードタイプは、ファイル内の個人 ( ) 間のリンクの唯一のソースであり、個人の固有 ID番号を参照することで、親 ( および ) と子供 ( ) を割り当てます。[ 10 ]これらの歴史的起源は、7.0 仕様書に記載されています。「このレコードは、もともと男性(夫または父親) と女性(妻または母親) が (子供) を生む家族を表すように構成されていました。」[ 11 ]FAMINDIHUSBWIFECHILFAMHUSBWIFECHIL
GEDCOM ファミリーレコードのリンクは、夫と妻を示す元の命名規則を依然として使用していますが、仕様書には「パートナーの性別、ジェンダー、肩書き、役割は、構造が指すパートナーに基づいて推測されるべきではない」と記載されておりHUSB、WIFE家族構造内のこれらの個人はまとめて「パートナー」、「親」または「配偶者」と呼ばれます。レコードは、FAM「パートナーの性別に関係なく、同棲、里親、養子縁組など」にも使用できます。[ 11 ]
GEDCOM ファイルは、ヘッダーセクション、レコード、およびトレーラーセクションで構成されます。これらのセクション内では、レコードは人物 (INDI レコード)、家族 (FAM レコード)、情報源 (SOUR レコード)、およびメモなどのその他のレコードを表します。GEDCOM ファイルの各行はレベル番号で始まり、すべてのトップ レベル レコード (HEAD、TRLR、SUBN、および各 INDI、FAM、OBJE、NOTE、REPO、SOUR、SUBM) はレベル 0 の行で始まり、その他のレベル番号は正の整数です。
GEDCOM ファイルは手書きで作成することも可能ですが、このフォーマットはソフトウェアで使用することを前提に設計されているため、人間にとって特に使いやすいものではありません。GEDCOM ファイルの構造を検証するために使用できる GEDCOM バリデータ[ 12 ]がPhpGedViewプロジェクトに含まれていますが、これはスタンドアロンのバリデータとして使用することを想定したものではありません。スタンドアロンでの検証には、「Windows GEDCOM Validator」[ 13 ]またはLDS 教会が提供している古いメンテナンスされていない Gedcheck [ 14 ]を使用できます。
2001 年、GEDCOM テストブック プロジェクトは、 Gedcheck プログラムを使用して、4 つの人気のある系図プログラムが GEDCOM 5.5 標準にどの程度準拠しているかを評価しました。[ 15 ]調査結果によると、多くの問題が存在し、「データ損失につながる最も一般的な欠陥は、NOTE タグが出現する可能性のあるすべてのレベルでの読み取りの失敗」であることがわかりました。[ 16 ] 2005 年に、系図ソフトウェア レポート カードが評価されました (元のGEDCOM テストブック プロジェクトに参加した Bill Mumford による) [ 17 ]。これには、Gedcheck プログラムを使用した GEDCOM 5.5 標準のテストが含まれていました。[ 18 ]
GEDCOM 7.0の採用を支援するため、現在ではその規格の検証ツールも存在する。[ 19 ]
以下はGEDCOMファイルのサンプルです。
ヘッダー（HEAD）には、ソースプログラムとバージョン（Personal Ancestral File、5.0）、GEDCOMバージョン（5.5）、文字エンコーディング（ANSEL）、およびファイルの提出者に関する情報へのリンクが含まれます。
個々の記録（INDI）は、ジョン・スミス（ID I1）、エリザベス・スタンスフィールド（ID I2）、およびジェームズ・スミス（ID I3）を定義している。
家族記録（FAM）は、夫（HUSB）、妻（WIFE）、子供（CHIL）をそれぞれのID番号で結びつける。
現在広く使用されている仕様のバージョンは、2019 年 11 月 15 日にリリースされたGEDCOM 5.5.1 finalです。その前身である GEDCOM 5.5.1 draft [ 20 ]は 1999 年に発行され、9 つの新しい属性タグが導入され、UTF-8 が承認された文字エンコーディングとして追加されました。このドラフトは正式には承認されませんでしたが、その規定はFamilySearch.org [ 20 ]を含む多くの系図プログラム[ 21 ] [ 22 ] [ 23 ]によって部分的に採用されました。
系譜リンク付き GEDCOM は、意図的な事実上の共通項です。[ 3 ] GEDCOM 標準のバージョン 5.5 が 1996 年に初めて公開されたにもかかわらず、多くの系譜ソフトウェアベンダーは、そのバージョンの仕様で導入された多言語 Unicode テキスト (ANSEL 文字セットの代わりに) の機能を完全にサポートしていません。Unicode を統一的に使用することで、国際的な文字セットの使用が可能になります。たとえば、東アジアの名前を元の中国語、日本語、韓国語 (CJK)文字で保存できます。そうしないと、曖昧になり、系譜や歴史の研究にはほとんど役に立ちません。[ 24 ] PAF 5.2は、内部文字セットとしてUTF-8 を使用し、UTF-8 GEDCOM を出力できるソフトウェアの例です。 [ 24 ] [ 25 ]
GEDCOM 7.0 では、全体を通して UTF-8 エンコーディングが必須であり、 [ 26 ] GEDCOM 5.5.1 のその他の長年の問題を解決しています。GEDZip と呼ばれる関連付けられた .zip ファイル形式のマルチメディア サポートも含まれています。7.0 が新しい交換標準として採用されるようにする取り組みが進められています。[ 27 ] GEDCOM 7.0 では、特定のファイルに GEDCOM 以外の標準が適用される可能性があることを明示的に識別できます。GEDCOM は常に拡張可能でしたが、7.0 より前は、そのような拡張を識別する標準的な方法はありませんでした。また、GEDCOM 7.0 では、イベントを存在しないものとして明示的にマークできます。これにより、たとえば、特定の個人が結婚したことがないことを文書化できます。[ 28 ] GEDCOM 7.0 は、セマンティック バージョニングを使用した最初のバージョンであり、仕様の最新のマイナー バージョンです。
2024年7月現在次に予定されているマイナーリリースはv7.1で、現在開発中です。[ 29 ]
GEDCOMファイルには、出生、死亡、国勢調査記録、船舶記録、結婚などのイベントに関する情報を含めることができます。イベントとは、特定の日時、特定の場所で発生した出来事を指します（日時と場所が不明な場合でも同様です）。GEDCOMファイルには、身体的特徴、職業、子供の総数などの属性も含めることができます。イベントとは異なり、属性は一般的に特定の日時や場所に関連付けることはできません。
GEDCOM 仕様では、各イベントまたは属性は正確に 1 人の個人または家族に関連付けられる必要があります。[ 60 ] このため、実際の国勢調査エントリには複数の個人に関する情報が含まれていることが多い国勢調査記録などのイベントでは冗長性が発生します。GEDCOM ファイルでは、国勢調査記録の場合、参照される個人ごとに個別の国勢調査「CENS」イベントを追加する必要があります。GrampsやThe Master Genealogistなどの一部の系図プログラムには、複数人のイベントを表すなどに使用されるソース用の複雑なデータベース構造があります。これらのプログラムのいずれかからデータベースを GEDCOM にエクスポートすると、この制限により、これらのデータベース構造を GEDCOM で表現することができず、結果として、関連するすべての引用参照情報を含むイベントまたはソース情報が、使用される場所ごとに複製されることになります。この複製により、ユーザーがソースに関連する情報を維持することが困難になります。
GEDCOM仕様では、結婚情報などの家族に関連するイベントは、家族（FAM）レコードの一部としてGEDCOMに一度だけ保存され、その後、両方の配偶者がその単一の家族レコードにリンクされます。[ 60 ]
GEDCOM仕様は、特にソースの分野において、データのエンコード方法を多数サポートするために意図的に柔軟に作られました。この柔軟性により、多くの曖昧さが生じ、GEDCOMをインポートする一部の系図プログラムがファイルからすべてのデータをインポートしないという副作用が生じています。[ 61 ]
GEDCOM 仕様では、既知のイベントの順序を保持するための明示的なサポートは提供されていません。特に、人物の関係の順序 (FAMS) と、関係内の子の順序 (FAM) は失われる可能性があります。多くの場合、イベントの順序は関連付けられた日付から導き出すことができます。しかし、日付は必ずしもわかっているとは限りません。特に、数世紀前のデータを扱う場合はそうです。たとえば、ある人物が 2 つの関係を持っており、どちらも日付が不明であるが、説明から 2 番目の関係が確かに 2 番目のものであることがわかっている場合などです。これらの FAMS が GEDCOM の INDI レコードに記録される順序は、エクスポート プログラムによって異なります。たとえば、Aldfaer [ 62 ]では、順序はユーザーによるデータの順序 (アルファベット順、時系列順、参照順など) に依存します。提案されている XML GEDCOM 標準[ 55 ]もこの問題には対処していません。
GEDCOMには、あまり一般的に使用されていない機能が多数あります。一部のソフトウェアパッケージは、GEDCOM規格で許可されているすべての機能をサポートしていません。
GEDCOM 規格は、マルチメディア オブジェクト (例えば、個人の写真) の組み込みをサポートしています。[ 63 ] このようなマルチメディア オブジェクトは、GEDCOM ファイル自体 (「埋め込み形式」と呼ばれる) または外部ファイル (GEDCOM ファイルで外部ファイルの名前が指定されている「リンク形式」と呼ばれる) に含めることができます。マルチメディアを GEDCOM ファイルに直接埋め込むと、すべての情報 (マルチメディア データを含む) が 1 つのファイルに含まれるため、データの送信が容易になりますが、結果としてファイルが非常に大きくなる可能性があります。マルチメディアをリンクすると、GEDCOM ファイルのサイズを制御できますが、ファイルを送信する際には、マルチメディア オブジェクトを個別に送信するか、GEDCOM と一緒に 1 つの大きなファイルにアーカイブする必要があります。メディアを直接埋め込むサポートは、ドラフト 5.5.1 規格で削除されました。[ 64 ]
GEDCOM規格では、同じ種類のレコードを複数指定するだけで、複数の意見や矛盾するデータを指定できます。例えば、出生証明書には生年月日が1800年1月10日と記載されているのに、死亡証明書には1800年1月11日と記載されている場合、その人物に関するBIRTレコードが2つ作成されます。1つ目は1800年1月10日を日付とし、出生証明書を情報源とするレコード、2つ目は1800年1月11日を日付とし、死亡証明書を情報源とするレコードです。通常、優先されるレコードが最初に記載されます。
GEDCOMでエンコードされたこの例は次のようになります。
0 @I1@ インド 1 名前 ジョン・ドゥ 1 バース 2 日付 1800年1月10日 2 サワー @S1@ 3 データ 4 テキスト 出生証明書からの転記はここに記載されます 3 注記 この出生記録は出生証明書からのものであるため、推奨されます。 3 埠頭 2 1 バース 2 日付 1800年1月11日 2 サワー @S2@ 3 データ 4 死亡証明書からのテキストの転写はここに記載されます 3 埠頭 2
データの矛盾は、ユーザーエラーが原因である可能性もあります。規格では、内容が一貫している必要があるとは一切規定されていません。例えば、「1819年4月10日」という生年月日が、本人の死後ずっと経ってから誤って「1918年4月10日」と記録されている可能性もあります。このような矛盾を明らかにする唯一の方法は、内容データを厳密に検証することです。
GEDCOM 標準は、いくつかの方法で国際化をサポートしています。まず、標準の新しいバージョンでは、データを Unicode (または最近では UTF-8) で保存できるため、任意の言語のテキストを保存できます。[ 65 ] 次に、1 人の人物に対して複数のイベントを持つことができるのと同様に、GEDCOM では人物に複数の名前を持たせることができるため、[ 66 ]名前を複数の言語で保存できますが、どのインスタンスがどの言語であるかを示す標準的な方法はありません。最後に、バージョン 5.5.1 では、NAME フィールドで名前の音声的バリエーション (FONE) とローマ字表記バリエーション (ROMN) もサポートしています。[ 67 ]
2012年2月に開催されたRootsTech 2012カンファレンスで、FamilySearchはGEDCOM Xと呼ばれる系図標準に関する主要な新プロジェクトの概要を発表し、協力を呼びかけました。[ 68 ]このプロジェクトには、 Apacheオープンソースライセンスの下で開発されたソフトウェアが含まれています。また、資料や記録（物理的なアーティファクトとデジタルアーティファクトの両方）に基づいて家系図を作成するのに役立つデータ形式、オンラインでのデータ共有とリンクのサポート、およびAPIも含まれています。[ 68 ] [ 69 ] [ 70 ]
2012年8月、FamilySearchの従業員でありGEDCOM Xプロジェクトリーダーであるライアン・ヒートンは、GEDCOM Xが新たな業界標準であるという主張を取り下げ、GEDCOM XをFamilySearchの別のオープンソースプロジェクトとして位置づけ直した。[ 71 ]
GEDCOM 7 のリリース後、FamilySearch は GEDCOM X を FamilySearch Family Tree ソフトウェアとの相互運用に役立つものとして位置づけた。[ 72 ]
系図ソフトウェアRoots [ 73 ]シリーズと Ultimate Family Tree の開発元である Commsoft は、イベントを第一級 (ゼロレベル) アイテムとして含む Event-Oriented GEDCOM (別名「Event GEDCOM」、元々は InterGED [ 74 ]と呼ばれていた) [ 75 )と呼ばれるバージョンを定義しました。イベントベースではありますが、証拠ではなく想定された現実に基づいて構築されたモデルです。Event GEDCOM は、想定されるイベントと参加者をある程度分離できるため、より柔軟でした。しかし、Event GEDCOM は意味論的な違いから、他の開発者に広く採用されませんでした。Roots と Ultimate Family Tree が利用できなくなった現在、Event GEDCOM を使用している人はごくわずかです。[ 76 ]
Gramps XMLは、オープンソースの系図プロジェクトGrampsによって作成されたXMLベースのオープンフォーマットであり、 PhpGedViewでも使用されています。
家族史情報標準化機構は、家族史および系図情報の国際標準を開発することを目的として2012年に設立されました。[ 77 ]同機構が提案した標準の1つは、GEDCOM 5.5(.1)と互換性がありながら拡張メカニズムを含むExtended Legacy Format (ELF)でした。同機構は2017年に提案された標準について一般からの意見を求めました。[ 78 ] GEDCOMのリリース7.0で同機構の懸念の多くが解消されたため、提案を取り下げました。[ 28 ]