= Common Person Registry =

The Common Person Registry is a new conception in !SahanaPy - it provides a framework and a comfortable user interface to store and manipulate personal data which are common to all modules (the Ontology below specifies which data this could be).

The Person Registry is:
  * the central registry for common personal data
  * the central search engine for personal data records
  * main entry point and central hub for personal data related actions

Justification:
  * People may appear in different contexts at the same time: displaced person <-> volunteer <-> missing person
  * For optimal assistance there is often a need to search and track individuals across multiple or all contexts
  * Data may also need to be shared across different contexts (e.g., missing person and dead body)
  * Central storage and manipulation of personal data at least improves data integrity, and ''can'' enhance security

Framework functions (available in all person-related modules, even PR):
  * Create/Read/Update/Delete for common personal data records
  * Manipulation of groups/roles
  * Global search for personal records

Central functions (PR only):
  * Access to specialized module functions directly from the search results
  * Global statistics and assessment

This then feeds these specialized modules:

 * Disaster Victim Identification: http://wiki.sahana.lk/doku.php?id=dev:dvimodule
 * Disaster Victim Registry: http://wiki.sahana.lk/doku.php?id=doc:dvr:english
 * Missing Person Registry: http://wiki.sahana.lk/doku.php?id=doc:mpr:english
 * Volunteer Management: http://www.cs.trincoll.edu/hfoss/wiki/User_Guide_for_the_VM_Module
 * Victim Tracking/Tracing (real-time tracking/tracing of individuals and groups)

== Ontology ==

Ontology draft for "Personal Data for Disaster Management" (suggested for implementation in the data model):

  * [http://ontology.nursix.org/sahana-person.owl "OWL Source"]
  * [http://ontology.nursix.org/sahana-person.png "Class Tree Diagram"]

''(still under development, see the OWL source for version information)''

This ontology defines four axes for the construction of "Personal Data" relations:

  * '''Appearance''' - forms of appearance (of persons)
  * '''Distinction''' - classes for operational distinction (assigned features)
  * '''Evidence''' - classes of data sources
  * '''Finding''' - classes of findings (observed or derived features)

Every data set implements at least one class (aspect) from each axis (at least implicitly, e.g. in case of the appearance aspect).

== Data Model ==

[[wiki:BluePrintVITA]]

== Functionality needed ==

=== CRUD ===

Generic CRUD of personal data records is a matter of course, specialities below:

=== Labels ===

During rescue/recovery operations mostly tags are used to identify affected persons. Different types of tags are in use: barcode tags are common, but even RFID tags could be used (which contain more details on the person).

The Person Registry should support (at least) barcode labels:

 * read labels from tags or documents (realized by the client system)
 * retrieve/display the corresponding record from the database
 * display links to process this record in other person-data-related modules
 * display/print out barcode labels for existing records (e.g. to forms, documents, stickers)
 * generate/manage new unique labels (and print them out), even pre-printed stock tags

=== Import/Export Formats ===
Should be able to support:
 * vCard
 * PFIF

== Discussion ==

Q: How to handle the entity relationships with the extra data needed?

Options:
 * Polymorphic Associations: http://www.fleegix.org/articles/2008-01-03-rails-polymorphic-associations-and-migrations
  * Single Many-to-Many Reference Table which includes a 'type' reference for which sub-table it refers to.
 * A Many-to-Many table for each 'type'.
 * A tagging field within the main PR to show which contexts this Person is used in: Staff, Victim, Missing, etc
 * Single-Table Inheritance: http://groups.google.com/group/web2py/browse_thread/thread/d9715e7b751c1e56
  * A single table containing all information, with unnecessary information ignored.

Q: Including system users? (BluePrintAuthenticationAccess)
 * currently we automatically add new registrations as people as well.

----

BluePrints
[[TranslatedPages]]