PeopleFinder Interchange Format
From Katrina Help Info
PeopleFinder Interchange Format, called 'PFIF' for short, is a standardized data model for storing and sharing information about missing and displaced people. It can be implemented in XML (http://en.wikipedia.org/wiki/XML) or in a relational database.
The PFIF standard helps in the organization of data about people affected by disasters such as Hurricane Katrina.
| Table of contents |
Learning About PFIF
Only webmasters and database administrators need to grapple with PFIF.
- To volunteer or search (http://www.katrinalist.net/) the database, no knowledge of PFIF is expected.
- If you are running a site that collects information on Katrina survivors, or you want to help with the "scraping" effort, you should understand PFIF.
- Visit PeopleFinderTech for information on implementing PFIF.
- The PFIF home page (http://zesty.ca/pfif/) shows great details, examples and a FAQ.
Versons and Evolution of PFIF
The PFIF is a de facto standard (http://en.wikipedia.org/wiki/Defacto) that can and should evolve in due time. Version 1.1 is in use in September 2005.
Project leaders called for a PFIF version freeze until other pressing needs are resolved.
Background
PFIF is intended to help with database storage, information sharing and data transmission among various sites. A standard allows for the easy movement of data between sites, shelters and others and greatly eases data management for this project.
Tip: The DISCUSSION link at the top of this page contains additional insights.
NotesForTheNextVersion
KatrinaDataProject has a good spec focused on privacy: http://katrinadataproject.com
From Ping:
1. home_zip (integer) should be home_postal_code (string) for international addresses.
2. Person.source_date should be an xs:dateTime in the XML schema.
3. Promote linked_person_record_id to an official field
4. Consider adding a person.home_phone field.
5. Add a person.home_country field for international use.
PFIF is a data model that can be embedded in XML, a relational database, or in Excel if necessary. What is important are the names and meanings of the fields.
Here some design notes from John Galloway: Our spec is:
--Designed for data dumping. We believe having 50 sites with info is counterproductive to the effort. The people in shelters have limited bandwidth, limited computers, and limited time on the computers. They do not have time to search 50 different sites... This is why we save their search and run it for them as new data comes in. A best-case scenario would be for every small-cap registry site to close down, dump their data to a central loc, and link to the data entry form for this central location. An interoperable data spec simply fosters creating multiple search engines for data, which hampers evacuee access to it. Even if you can get all the data in one place, there is still the chance they won't find your central database search.
--Simple. A secretary in the office of a church serving as a shelter for 20 families could type up a list in xls and email it to us. I would not ask her to do this with XML, and I'm certainly not going to ask her to create an RSS feed.
--Good for matching.
We've included various fields which, from our experience, are very useful in
matching (My compnay designed the loyalty network that runs Citibank
Thankyou rewards, matching customer actions on demographic/contact data such
as this from over 100 different file feeds in 30+ formats.). These were
released with our original spec on Friday. We have been developing the data
to collect and systems to use to make accurate, confident matches for years.
Basically, the founding KDP team does this for a living.
--Gathering data from missing person's reports We've also included fields useful in identifying people, and people are happy to give the information. It is not personally identifiable, so there is no privacy concern to posting up age, hair color, eye color, etc AND it helps searchers increase match confidence. Over 80% of people entering data into our website are providing this data.
There is also the EvacueeandSiteInformationDataDictionary
