PFIF 1.2 Specification

URL of this specification: http://zesty.ca/pfif/1.2
FAQ, examples, and other information on PFIF: http://zesty.ca/pfif
Editor: Ka-Ping Yee <ping@zesty.ca>

This document is licensed under the GNU Free Documentation License 1.2.

1. Introduction

This specification describes PFIF 1.2 in terms of changes from PFIF 1.1. A future document will contain a complete stand-alone specification of PFIF 1.2.

PFIF 1.2 is identical to PFIF 1.1 apart from the changes given below.

2. Changes to the Data Model

String fields are no longer constrained to capitals only, and may contain non-ASCII characters. All PFIF processors must support UTF-8.

Person records

Person records gain four new fields, all of which are optional:

sex

Physical sex of the person sought or found, specified as one of the three strings female, male, or other. If the sex is unknown, omit this field.

date_of_birth

Exact date of birth (specified as YYYY-MM-DD) or approximate date of birth (specified as YYYY or YYYY-MM) of the person sought or found.

age

Approximate age of the person sought or found, in years since birth, as of the source_date of this record. The value of this field is either a single decimal integer, or an inclusive range given as two decimal integers separated by a hyphen. This field has no defined meaning when source_date is missing.

home_country

The home country of the person sought or found, specified as an uppercase two-letter ISO 3166-1 country code. Upgraded PFIF 1.1 repositories should set this field to US when exporting records whose home_state field refers to a U. S. state, or whose home_zip field contains a U. S. zip code.

The home_state field is explicitly international in PFIF 1.2. It identifies a principal subdivision of the home country using an uppercase ISO 3166-2 code.

The home_zip field is renamed to home_postal_code. Upgraded PFIF 1.1 repositories should export their existing home_zip values in the home_postal_code field.

Note records

Note records gain three new fields, all of which are optional:

status

Status of the person sought or found, specified as one of the following five strings:

information_sought

The author of the note is seeking information on the person in question.

is_note_author

The author of the note is the person in question.

believed_alive

The author of the note has received information that the person in question is alive.

believed_missing

The author of the note has reason to believe that the person in question is still missing.

believed_dead

The author of the note has received information that the person in question is dead.

person_record_id

The person_record_id of the person record to which this note record belongs.

linked_person_record_id

The person_record_id of another person record, which this note is claiming to be a duplicate record for the same person.

When a user marks two person records as duplicates, a note record should be added for both person records, each containing a linked_person_record_id field that points at the other record. These two note records should specify the author_name of the party that is marking duplicates, and should include a message in the text field justifying how they were determined to be duplicates.

3. Changes to the XML Format

The XML namespace for PFIF 1.2 is:

• http://zesty.ca/pfif/1.2

The XML Schema for PFIF 1.2 is located at:

• http://zesty.ca/pfif/1.2/pfif-1.2.xsd

To turn any valid PFIF 1.1 document into a valid PFIF 1.2 document, the following steps are sufficient:

• Replace 1.1 with 1.2 in the XML namespace URL.
• Replace any home_zip tags with home_postal_code tags.
• Add home_country tags for records whose home country is known.

In addition, PFIF 1.2 relaxes some of the requirements of PFIF 1.1.

Notes at the top level

Unlike PFIF 1.1, PFIF 1.2 allows note elements at the top level, outside of person elements. A valid PFIF document consists of a single pfif element containing one or more person or note elements.

When a note element occurs outside of a person element, the note must contain a person_record_id. Otherwise the person_record_id field is optional, and if present, must match the person_record_id field of the enclosing person.

Relaxed field order requirements

Within a person element, the required person_record_id must appear first, and any note elements must appear last. Within a note element, the note_record_id must appear first, followed by the person_record_id if present. Unlike PFIF 1.1, PFIF 1.2 allows the remaining fields to appear in any order.

4. Changes to the Feed Formats

In PFIF 1.2, each entry in an Atom person feed or RSS person feed contains a single pfif:person element. There is no enclosing pfif:pfif element.

In PFIF 1.2, each entry in an Atom note feed or RSS note feed contains a single pfif:note element. There is no enclosing pfif:pfif element or pfif:person element.