Version 23 (modified by Fran Boon, 14 years ago) ( diff )

tagging field to show which contexts this Person is used in

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


  • 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):

Central functions (PR only):

  • Access to specialized module functions directly from the search results
  • Global statistics and assessment

This then feeds these specialized modules:


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).

Data Model

...under construction

Functionality needed

GetCapabilities and GetContexts (cross-module resource transfer) be discussed:

GetCapabilities should be possible in the PR to query the availability of context functions in the current instance, i.e. which context modules are available (MPR, DVR, VM, DVI, VTT...) and which particular resources they provide for a single record. Resources can then be accessed via the context module using UUIDs _or_ context-related labels, e.g.

  • if GetCapabilities(MPR) contains "ReportMissing", then expose "ReportMissing with person_UUID"

GetContexts should be there in the PR to query which extra data ("context records") exist for a particular person or group, e.g.

  • for each resource_X in GetContexts(person_UUID) expose "view/edit resource_X"


Generic CRUD of personal data records 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?


Q: Including system users? (BluePrintAuthenticationAccess)

  • currently we automatically add new registrations as people as well.

BluePrints TranslatedPages

Note: See TracWiki for help on using the wiki.