| Version 19 (modified by , 16 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).
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 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 may enhance security, but at least enhances integrity
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):
(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).
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'.
- 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.
