Important: Look at Person Finder problem definition on the new RHok site: http://www.rhok.org/problems/upload-tool-person-finder
Person Finder is a searchable public database of missing persons. It was created by Google volunteers in response to the Haiti earthquake in January 2010. It was used again for the Chile earthquake, the Yushu earthquake, and the Pakistan floods, and now runs at http://person-finder.appspot.com/. Person Finder is an open source Python application running on App Engine. See the project page at http://code.google.com/p/googlepersonfinder for details on its design and instructions for getting the code and contributing to development. Person Finder implements the PFIF data model (see http://zesty.ca/pfif), including import and export in PFIF, as well as PFIF Atom feeds.
There are many improvements to Person Finder that RHOK participants could contribute. Not all of these tasks require Python or App Engine knowledge; please see the notes for each one.
app/view.py (post method)
When someone posts a note on a person record, it would be nice to send e-mail to the creator of the record and others who have posted on the record. Users should be able to choose whether they want to receive e-mail.
This is also being worked on from a guy in Russia
app/templates/view.html
It would be cool to use the Google translation tools to let users get translations of the notes on a person record, ideally right in the context of the person page.
app/static/forms.js<code>, <code>app/templates/create.html<code>, <code>app/templates/view.html
The current app validates input fields only after submission. The UI would be better if form validation could happen right in the browser.
app/templates/view.html
Person Finder already produces an Atom feed of notes about each person; task is just a UI enhancement to add the button, link, and/or meta tags to let users easily subscribe to this feed of notes when looking at a person's record.
app/static/style.css, app/templates/*.html
Test the Person Finder UI on a mobile browser and figure out the necessary CSS changes to make it work well on small screens.
Allow to search on any field of Person Finder index. UC Irvine has a prototype, we'll work on integrating this index into the PersonFInder code base.
app/indexing.py, app/model.py
Allow searches to match names that are spelled approximately correct, or transliterations of names. (For a volunteer with some expertise in linguistics.) Some work has been done during rhok1.0 to compare names: They came up with algorithm for accent-insensitive, position-insensitive and case-insensitive name matching for duplicate detection. Code was not integrated in PF yet, maybe added prior Dec 4th
app/model.py, app/pfif.py, app/templates/create.html, app/templates/view.html
Person Finder currently has a first name field and a last name field. But some countries and cultures don't use first and last names, and often people have more than two names. Person Finder needs a "full name" field as well, where the user can enter the person's entire name (or all names). This field would be indexed and searchable like the other name fields. Perhaps the UI would allow the user to toggle between entering full or entering first+last; or the full name would be automatically populated with first + ' ' + last if the full name field is empty.
app/api.py, app/results.py
Currently PersonFInder supports only data upload and download (http://code.google.com/p/googlepersonfinder/wiki/DataAPI)
It would be great to add a Search API which allow to search among PersonFinder records and will return a PFIF feed with all matching records.
During RHOK 1.0, a Twitter scraper was developed to detect if someone is looking for a missing person. In this case, we would check if this missing person is in Person Finder and will reply with a tweet containing a link to the Person Finder results. This work can be continued during RHOK 2.0 as follows:
What Chicago is doing: allow people to tweet "@personfinder john doe" and receive a tweet back "we found x results + link to Person Finder results page".
See the notes from RHOK 1.0: PersonFinder_and_social_networks
Code: https://github.com/feordin/twitter-to-pfif
Synchronization of multiple person finders/missing persons registries Expand contribute-consume pipeline Expand functionality and richness/usefulness of data
A large hurricane results in large-scale destruction and flooding over a wide area. Some people have evacuated, some are trapped, some have found shelters, some are scattered, and some have become fatalities. Families, co-workers and neighbors cannot find or contact each other.
Create a Person finder technology that includes a database schema to synchronize multiple databases. Solution should support:
Imagine your sister/brother/mom/dad were missing in the aftermath of an earthquake; what would you want to know?
Apply the technology to lost/displaced pets and animals
We build over Google Person Finder this software, also search in Twitter, the code:
http://bitbucket.org/dxc/buscador-de-personas
README: http://bitbucket.org/dxc/buscador-de-personas/changeset/b0143c09fb65#chg-README
Visit the Person Finder Sydney team page for the ideas and code of the Sydney team working on the project
We are working on:
* duplicate detection: detected which record in personfinder refer to the same person. * I am OK app to send data to person finder * Add a Virtual Keyboard to our UI with Google Virtual Keyboard API[5] * Updating twitter-pfif to automatically send a reply to a tweet with link to person finder if tweet is about a missing person
More details are available on our page Person Finder DC team
Saturday 8:20pm: Notes from discussion with Santiago
Santiago has the idea of using twitter and facebook to detect when people post updates about "I am looking for John Smith" or "I know that John Smith is ok". In this case, we can reply to the post with a message "We found 5 results corresponding to John Smith in PersonFinder. Check on PersonFinder if you can find news about John Smith" OR "5 other people are looking for John Smith in PersonFinder, please, add you updates to PersonFinder"
So idea is NOT to automatically update PersonFinder based on twitter or facebook updates. The idea is to detect people that are tweeting about a missing person and to tell them to update person finder.
DC team loves this idea.
We want to syncup with Sydney to have their though in the idea.
The LPF project is particularly concerned with family reunification during disasters in the Washington, D.C. area, in conjunction with a 3-hospital consortium near the National Institutes of Health campus. More details about how the project was first tested during an October, 2009 can be found here. However, this project also responded extensively to the Haitian earthquake (with this site), providing an alternative view to Google's data and other resources.
LPF is based around a customization and extension of the Sahana Eden disaster management system. For RHOK 1.0, we would like to propose micro-projects in the NLM "friend of Sahana" wireless/mobile space, rather than the Eden core. Specifically:
TriagePic is a C#/.Net/WinForm app (built on VS 2005 or later) that runs on a Windows laptop at a primary triage station at the hospital's perimeter, associating photos of each arriving victim with a casualty patient ID and their routing to a color-coded treatment zone. Desirable features to be added (which could be done by independent RHOK teams) are:
• data transport to/from LPF/Eden by web services instead of or in addition to email;
• use of a webcam to take photos (this could be loosely coupled as a separate app);
• to be able to see photos in our app's outbox.
Zipped source code and docs are provided in the folder RHOK 1.0 - TriagePic
Potential platforms include:
• Android 2.2
• Win Phone 7
• Blackberry
• HP/Palm WebOS
ReUnite is a simple form app, available from the Apple iTunes Store, for reporting lost and found people to the LPF website and doing simple searches. ReUnite uses the same data transports as TriagePic to LPF/Eden, namely, structured-email with some initial web service support.
A ReUnite RHOK team, to succeed, must have 1 or more experienced developers in a particular mobile target platform (i.e., don't count on NLMers). These results would be native re-implementations, so existing iPhone source code would be unhelpful. NLM will instead provide GUI details/videos and input/output specs. It is not expected that the results will be polished enough at the end of RHOK 1.0 to submit to the corresponding mobile App Store.
Details about how ReUnite's appears to the user, screenshots, artwork, and email services specs are in the folder RHOK 1.0 - ReUnite Clones. (For web services specs, see the TriagePic ReadMe.)
There will be a bit more detail about both of these at the event.