Annotated PFIF 1.2 Example

This page provides an annotated description of an example PFIF document.

In this example, we are looking at two person records exported from the database. The first is an original record, the second is a clone record.

The first record was posted directly to by Bill Mandil on 2005-09-03 at 09:21:12 UTC, looking for a missing person named Katherine Doe. Jane Peters spoke to her on the phone and posted a note about it at 20:52:25 UTC. Jane posted the note on a different site,, where the record was copied. Jane also happens to know that there is a duplicate record for Katherine Doe at the site, and entered this indication when posting her note. The note was exported on a feed where picked it up, and attached it to the original record (thus, this is a clone note attached to an original record).

The second record was originally posted to by Mary Jacobs on 2005-09-03 at 22:07:59 UTC, looking for a missing person named John Doe. Attached to the record is a note from Mary Jacobs asking for people to contact her if they know anything about John. The record and note were both scraped from by a program named RCScraper, and the PFIF output from RCScraper was loaded into the database at 23:00:00 UTC.

<?xml version="1.0" encoding="utf-8"?>

This tag appears at the top of an XML document. The encoding should be UTF-8.

<pfif:pfif xmlns:pfif="">

This is the start tag for the pfif:pfif element that surounds the entire PFIF document. The xmlns:pfif attribute associates the pfif: prefix with the PFIF 1.2 namespace, which is a URL pointing at the PFIF 1.2 specification.


A PFIF document consists of a pfif:pfif element containing a series of pfif:person elements. This example contains two person records. This record, the first of the two, is a record that was entered directly into a database at (not copied from anywhere else). We call this an original record in the database.


Each record must have a unique ID in its person_record_id field. The ID should begin with the domain name of the record's home repository and a slash. Since this record was created for the first time at and not copied from anywhere else, is the home repository for the record. The slash is followed by an ID that was chosen by, such as the primary key of the record in the database.


This is the date that this copy of the record was stored in the database. Since this is an original record, this is the same as the date it was originally created, that is, the entry_date is equal to the source_date. Notice that all the dates are in YYYY-MM-DD format and all the times are 24-hour times, HH:MM:SS. The date and time are joined by a capital "T" and a "Z" is added to the end to indicate that the time is in UTC (also known as Greenwich Mean Time). All dates and times in PFIF must be given in UTC.

    <pfif:author_name>Bill Mandil</pfif:author_name>
    <pfif:author_phone>(555) 258-6902</pfif:author_phone>

These three elements identify the person who entered the original record.


These three elements identify the original record. They show that the record was created at on September 3, 2005 at 09:21:12 GMT, and give a URL for viewing the record at its home repository,


This is the name of the missing or found person. Any non-ASCII characters should be encoded as UTF-8.


These fields describe the physical characteristics of the person. Note that the pfif:date_of_birth field can specify an approximate date (February 1971 in this example), and the pfif:age field can specify an age range.

    <pfif:home_street>Cotton Lane</pfif:home_street>

This describes the home location of the missing or found person — the place where they resided before the disaster. This information is here to help identify which person we are talking about, not necessarily to locate where they are now; that's why only the street name is given, not the house number.


This field provides a URL to an identifying photo of the person. It is best to use a permanent URL for the photo, for example, at an established photo hosting service.

    Dark hair, in her late thirties.
    Also goes by the names "Kate" or "Katie". Generic Savings Bank

This field contains any other information that did not fit in PFIF fields. In this example, we assume that has a company field, and when we bring it in we prefix it with to indicate who defined the field. The description: tag is for text describing the person. The line breaks are important: each field should start on a new line, with the value either on the same line or indented on the following lines.


This person record has an associated note record, which goes in a pfif:note element contained within the pfif:person element.


This is a unique ID for the note, prefixed with the domain name of its home repository, like the person_record_id. Notice that this note has a different home repository than the person. This means the person record was entered at, then copied to, where someone posted a note on it.


This is the ID of the person again. When the pfif:note element is nested inside the pfif:person element, this is redundant and can be omitted. But notes can also be transferred separately in their own file, and for such notes the pfif:person_record_id field is necessary.


This field indicates that there is a record at, with ID icrc/83.4, which is also for the same person as this one.


This is the date that the note was stored at

      <pfif:author_name>Jane Peters</pfif:author_name>
      <pfif:author_phone>(555) 493-2342</pfif:author_phone>

These three fields identify the person who posted the original note.


This is the date of the original note. Since the note is in its home repository, the date of storage (entry_date) matches the date of creation (source_date).


This field indicates the status of the person, according to the author of the note. Jane spoke to Katie, so this field is present to indicate that Jane knows that Katie is alive.


This field is true to indicate that the missing person has been seen or contacted.

      <pfif:phone_of_found_person>(555) 904-9095</pfif:phone_of_found_person>

These fields provide contact information for the person who has been found.

      <pfif:last_known_location>on a cot somewhere, AstroDome, Houston TX</pfif:last_known_location>

This field describes where the person was last known to have been, and should include as much detail as possible.

I spoke to Katie on the phone today at around noon EST.
She is tired and worried but otherwise okay.

This is the text of the message posted by Jane.


That's the end of the first person record.


Here's the second person record.


This ID begins with to indicate that this record was originally created at Since this record, stored at, is a copy of a record created somewhere else, we call it a clone record.


This is the date that this copy of the record was stored in its current location,

    <pfif:author_name>Mary Jacobs</pfif:author_name>
    <pfif:author_phone>(555) 736-1148</pfif:author_phone>

These three fields identify the author of the original record at

    <pfif:source_name>ICRC FamilyLinks</pfif:source_name>

These three fields identify the original record at Since this is a clone record, the source_date and entry_date are different. The source_date is the date of the original posting at So this tells us that the record was originally posted at at 22:07:59, then later copied into the database at 23:00:00. The source_url field provides a URL to the original post at

    <pfif:home_neighborhood>Herringbone Parish</pfif:home_neighborhood>
    <pfif:home_city>New Orleans</pfif:home_city>

These fields give the missing person's name, details, and address, as before. Note in this case only the year of birth is specified, along with an exact age.

automated-pfif-author: RCScraper 0.4, 1976-02-26

The ICRC database happens to have a birthdate field, which is not part of PFIF, so the birthdate goes here in the other field. Since the birthdate field is defined by ICRC, the field name is The automated-pfif-author field should be added by any program that automatically converts from another format to PFIF; in this example, this record was scraped from the ICRC site by a program called RCScraper.


The note came from ICRC as well, so its ID also begins with


The note was imported into at the same time as the person record.

      <pfif:author_name>Mary Jacobs</pfif:author_name>
      <pfif:author_phone>(555) 736-1148</pfif:author_phone>

This is the original author of the note on


This is the date the note was originally posted at In this example, the note was scraped from the same record, so it is recorded as having the same original posting time.

      <pfif:last_known_location>at home in New Orleans</pfif:last_known_location>

The last_known_location can be filled in even if the person has not been found yet.

If you have any information on John, please contact me.

This is Mary's note that will appear on John's record.


This is the end of the second person record.


And this is the end of the PFIF document.