PFIF（People Finder Interchange Format）詳細解

1 PFIFとは何か

PFIF（People Finder Interchange Format）は、自然災害や人為的災害によって行方不明になったり避難したりした人々に関するデータを共有するための、データモデルとXMLベースの交換フォーマットです。

PFIFは、複数の機関やサービスが独自に収集した行方不明者情報を統合し、重複や分散を防ぐために設計されました。現在の最新バージョンはPFIF 1.4（2012年5月29日リリース）です。

正式名称: People Finder Interchange Format

最新バージョン: PFIF 1.4（2012年5月29日）

仕様策定者: Ka-Ping Yee 他

ライセンス: GNU Free Documentation License 1.2

2 設計思想と7つの原則

PFIFは以下の7つの設計原則に基づいています。

人とデータを結びつける — 同じ人を探す人々の情報を収束させ、最終的に行方不明者と家族を再会させることを目指す。
データの追跡可能性 — 信頼性の不明なソースからのデータでも、起源情報を保持し信頼性を判断できるようにする。
オリジナルリポジトリの権威 — 各レコードは最初に入力されたリポジトリに属し、そのリポジトリのみが内容を変更できる。
分散型の真実 — 中央権威が全データの真実を決定するのではなく、各集約者が独自に信頼するソースを選択する。
レコードの関連付け — 同じ人を指す複数レコードを関連付けることができるが、判断は各集約者が行う。
重複コピーの解決 — 異なる経路でインポートされた同じレコードの複数コピーを解決できる。
UTCでの日時管理 — タイムゾーンをまたぐデータ伝達のため、すべての日時はUTC（RFC 3339形式）で表記する。

3 データモデル：2種類のレコード

PFIFのデータモデルは、person レコードとnote レコードの2種類で構成されます。

3.1 person レコード（人物特定情報）

行方不明者を特定するための静的な情報を格納します。25個のフィールドを持ちます。

カテゴリ	主なフィールド	説明
メタデータ	`person_record_id`	一意識別子（必須）。`ドメイン名/ローカルID`形式。ドメインはオリジナルリポジトリを示す。
	`entry_date`	このコピーが保存されたUTC日時（増分更新用）。
	`expiry_date`	レコード削除予定のUTC日時（プライバシー保護）。
	`source_date`, `source_name`, `source_url`	データの起源情報。
入力者情報	`author_name`	レコード入力者の氏名。
	`author_email`	入力者のメールアドレス。
	`author_phone`	入力者の電話番号。
人物情報	`full_name`	氏名（必須）。
	`given_name`, `family_name`	名・姓。
	`alternate_names`	別名（カンマ区切り）。
	`sex`	性別（`male`, `female`, `other`）。
	`date_of_birth`, `age`	生年月日・年齢。
	`home_*`（住所系）	自宅住所（street, city, state, postal_code, country）。
	`photo_url`	写真のURL。
	`profile_urls`	SNS等のプロフィールURL（カンマ区切り）。

3.2 note レコード（状態・状況情報）

特定の人物の現在の状態や状況に関する情報を格納します。person_record_idで紐づきます。状態が変わった場合はpersonレコードを更新せず、新しいnoteを追加るのが基本です。

フィールド	説明
`note_record_id`	一意識別子（必須）。
`person_record_id`	紐づくpersonレコードのID（必須）。
`author_name` 等	入力者情報。
`status`	状態（`believed_alive`, `believed_missing`, `is_note_author`, `believed_dead`, `information_sought` など）。
`text`	本文（必須）。「無事です」「〇〇避難所にいます」など。
`spam`	スパム判定（`true`/`false`）。
`author_made_contact`	入力者がその人と連絡を取ったか。

4 データのライフサイクル

PFIFでは、レコードがどこで生まれ、どう伝播するかが厳密に定義されています。

現実世界の事実 ├─ 人間がPFIFリポジトリに入力 │ → オリジナルPFIFレコード（2a） └─ 人間が非PFIFリポジトリに入 → オリジナル非PFIFレコード（2b） ↓ PFIFに変換（3） ↓ 他のPFIFリポジトリに読み込み ↓ クローンレコード（4） ← entry_dateが更新 ↓ さらにPFIFとしてエクスポート

重要な概念

オリジナルレコード（Original Record）: そのレコードが最初に作られたリポジトリにあるもの。
クローンレコード（Clone Record）: 他のリポジトリからコピーされたもの。person_record_id のドメイン部分が自ドメインと異なる場合はクローン。

entry_date と source_date の違い

フィールド	意味	変
`source_date`	レコードがオリジナルリポジトリで作成された日時	固定（クローンでも同じ）
`entry_date`	このコピーが現在のリポジトリに保存された日時	リポジトリごとに異なる能性あり

entry_date は増分更新（incremental update）のために使われます。前回受信した最大の entry_date 以降のレコードだけを取得すれば、差分更新が可能です。

5 データの有効期限とプライバシー保護

PFIFには個人情報保護のための有効期限メカニズム（Data Expiry）が組み込まれています。

expiry_date が設定されている場合の動作

expiry_date の1日以内: そのpersonレコードと関連noteレコードの内容を、外部クライアント（ユーザー・API）からアクセス不可にする。
その後: APIでエクスポートする場合、プレースホルダーレコード（IDと日時のみ、内容は空）を返す。
expiry_date の60日以内: バックアップを含め、内容を完全かつ復元不能に削除する。

ユーザーが削除を要求した場合、expiry_date を現在時刻に設定することで、このメカニズムを通じて他のリポジトリにも削除が伝播します。

6 XMLフォーマットの構造

PFIFはXMLで表現されます。以下は最小限のPFIF 1.4ドキュメントの例です。

<?xml version="1.0" encoding="utf-8"?>
<pfif:pfif xmlns:pfif="http://zesty.ca/pfif/1.4">
  <pfif:person>
    <pfif:person_record_id>test.personfinder.google.org/1223</pfif:person_record_id>
    <pfif:source_date>2013-06-20T09:21:12Z</pfif:source_date>
    <pfif:full_name>Hiroshi Ichikawa</pfif:full_name>
  </pfif:person>
  <pfif:note>
    <pfif:note_record_id>test.personfinder.google.org/1223.1</pfif:note_record_id>
    <pfif:person_record_id>test.personfinder.google.org/1223</pfif:person_record_id>
    <pfif:author_name>Mary Jacobs</pfif:author_name>
    <pfif:source_date>2013-06-20T09:21:12Z</pfif:source_date>
    <pfif:status>believed_alive</pfif:status>
    <pfif:text>He is fine.</pfif:text>
  </pfif:note>
</pfif:pfif>

フィード形式

PFIF XMLはそのまま使うほか、AtomフィードやRSSフィードに埋め込んで配信することも可能です。PFIF対応アプリケーションは入力ドキュメントから pfif:person 要素を抽出して他を無視するため、どの形式でも同様に処理できます。

7 Google Person Finderとの連携（Data API）

Google Person Finderは、PFIFを内部データ形式およびAPIの入出力形式として使用しています。

APIキーの種類

Search: 検索クエリによるデータ取得。
Write: レコードの投稿。
Read: データベース全体のレコド取得。

主なAPIエンドポイント

用途	エンドポイント
検索	`https://www.google.org/personfinder/{repo}/api/search?key={key}&q={query}`
個別取得	`.../api/search?key={key}&id={person_record_id}`
書き込み	`.../api/write?key={key}`（PFIF XMLをPOST）
Personフィード	`.../feeds/person?key={key}`
Noteフィード	`.../feeds/note?key={key}`

書き込み時の注意点

person_record_id と note_record_id は domain_name/unique_string の形式である必要があり、ドメイン名はAPIキー申請時に指定したものと一致させる必要があります。
一度に投稿する <pfif:person> 要素は100件までに分割するのが推奨されます。
同じIDのレコードを再度アップロードすると、既存レコードが置き換えられます。

増分ダウンロード

min_entry_date パラメータを使うことで、前回取得以降に追加・更新されたレコードだけを取得できます。これにより、他のデータベースとGoogle Person Finderを同期させることが可能です

8 実装上の重要なガイドライン

同じ人の複数レコードの扱い

同じ人を指す複数のpersonレコードが存在する場合、レコードをその場でマージしてはいけません。すべての元レコードを保持し、別途「これらのレコードは同じ人」を管理するのが推奨されます。これにより、データの信頼性と責任追跡性が維持されます。

PFIFにないフィールドの扱い

人物の不変情報: other フィールドに fieldname: value 形式で格納。外部データの場合は domain/fieldname: value とする。
時間とともに変化する情報: 新しい note レコードとして追加する。

9 まとめ

項目	内容
名称	PFIF（People Finder Interchange Format）
目的	災害時の行方不明者・避難者情報の共有
形式	XMLベース（RELAX NGスキーマで定義）
最新版	PFIF 1.4（2012年5月29日）
中核モデル	`person` レコード + `note` レコード
重要概念	オリジナルリポジトリ、クローンレコード、source_date/entry_date
プライバシー	`expiry_date` による自動削除メカニズム
主要利用例	Google Person FinderのデータAPI・フィード

PFIFは、災害時に分散する行方不明者情報を統合しつつ、データの信頼性とプライバシーを両立させるための、よく設計されたオープン標準フォーマットです。

参考文献・ソース

PFIF 1.4 Specification — 公式仕様書
PFIF FAQ and Implementation Guidelines — FAQと実装ガイド
PFIF 1.4 Examples — 公式サンプル
Google Person Finder Data API Wiki — API仕様