wiki:BluePrintPersonRegistry

Version 25 (modified by Dominic König, 15 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).

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

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

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

BluePrintVITA

Functionality needed

GetCapabilities and GetContexts (cross-module resource transfer)

...to 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"

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:

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.