|Version 21 (modified by 14 years ago) ( diff ),|
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).
- 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 draft for "Personal Data for Disaster Management" (suggested for implementation in the data model):
(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).
Generic CRUD is a matter of course, specialities below:
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
Q: How to handle the entity relationships with the extra data needed?
- 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'.
- 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.