Differences

This shows you the differences between two versions of the page.

dev:sahana_gsoc10_ideas [2010/03/10 18:12]
greg
dev:sahana_gsoc10_ideas [2010/05/10 19:02] (current)
glenn
Line 202: Line 202:
If the above work is completed, additional research/work could go into providing a Sahana Module 'App Store'. The app store would host modules and integrate with the module manager such that searching for new modules, installing new modules, and upgrading existing modules could be performed. If the above work is completed, additional research/work could go into providing a Sahana Module 'App Store'. The app store would host modules and integrate with the module manager such that searching for new modules, installing new modules, and upgrading existing modules could be performed.
 +
 +For more see [[dev:Agasti_Module_Manager | the page for this project]]
 +
 +====Integration with Usahidhi ====
 +by Chamindra de Silva
 +
 +Ushadihi and Sahana have been working together in disaster response in particular during Haiti. Ushadihi is a great crowd sourcing tool that can obtain and plot geolocated SMS from the field during a disaster. But the SMS can be for various things, from a request for aid, to a report from a relief worker to an identification of a hazard. The SMS can be from victims, relief workers or donors and some work needs to be done to classify the requests. Sahana can provide a lot of value by introducing a process of collective classification and validation of requests and subsequently piping them in the appropriate form for processing in the relevant sub-application. Build an library that process the GeoRSS feeds from Usahidhi and has a mechanism of both auto-tagging and manual tagging, such that the requests then get piped as inputs to be processed in the respective Sahana module (Request Management, Volunteer Management, Organization Registry). In your proposal please provide the interface that would deliver this functionality.
 +
 +==== Referential Integrity ====
 +by Glenn Pearson
 +
 +Referential integrity within a database is the defining of foreign key relationships between database tables.  This simplifies enforcement of data validity on input or update, and allows better management through, for example, cascade deletes.  Not all databases support foreign key relationships.  Traditionally, Sahana has relied on business rules expressed in PHP, which has the advantage of portability across databases.  But coverage of such rules can be spotty.
 +
 +It would be helpful to create an experimental instance of Sahana with (for example) MySQL, where foreign keys are defined, and any parts of now-redundant business rules are conditionally disabled.
 +
 +==== A New Protocol for Missing Person/Disaster Victim Records ====
 +by Glenn Pearson
 +
 +In response to the Haitian earthquake, Sahana PHP has been developing capabilities to import and export missing person records in PFIF 1.1/1.2 formats, e.g., for interchange with Google and other aggregators and sources.
 +
 +But this is not the only potential format.  The US Department of Homeland Security/Federal Emergency Management Agency (FEMA) is currently creating a primarily-US XML standard for patient tracking (Phase I) and eventually disaster-related people tracking (Phase II).  FEMA's effort is attempting to address significant US data-exchange problems, within an US legal and medical framework.  The Phase I work, "Tracking of Emergency Patients" (TEP), uses an "EDXL wrapper" for distribution routing; it will be submitted shortly to OASIS as an "EDXL payload" standard.  (Our US National Library of Medicine customization of Sahana has made some use of a predecessor EDXL format.)
 +
 +The Phase II work, originally called "Tracking of Emergency Victims" (TEV), and now "Tracking of Emergency Clients" (TEC), will be of particular interest to Sahana.  It will build on TEP, but will presumably be different in some regards.  Since it will not be well defined during summer 2010, work in that time frame would focus on feedback to the standards bodies.
 +
 +For more, the starting point is [[http://www.fema.gov/about/programs/disastermanagement/standards/edxl-tep.shtm | FEMA's EDXL-TEP Site]]
 +
 +Pertinent documents (both overview and technical) are [[http://www.evotecinc.com/TEP/ | here ]] and its "TEP Project Documents" subdirectory.
 +
 +Desirable results -
 +
 +  *  At a technical level, a Sahana module that imported/exported/stored TEP records and mapped them to existing Sahana classes/tables would be helpful.
 +
 +  *  At a policy level, suggestions for what TEC should look like to support Sahana and non-US deployments (with potentially different legal/medical frameworks) better would be valuable.  Or proposals for alternatives to TEC and PFIF for these uses.
 +
 +
 +==== Passive Synchronization of Global Unique IDs Over a RESTful Interface  ====
 +
 +If every module has a well-defined, RESTful API, any of them can be distributed.
 +
 +As an example, the "Camp" or "Food Request Module" can function as a Consumer-Aggregator-Syndicator service that uses a common RESTful API.  Each can expose common response methods, internal aggregation methods, and communicate with other modules via a common syndication method that uses a controlled vocabulary.  This controlled vocabulary can be defined independent of any particular module and exist, for example, as an XML namespace.
 +
 +The Sahana Foundation has been discussing synchronization of data across multiple instances. If someone were willing to define a vocabulary, a RESTful API, and methodology for exposing Consumer-Aggregator-Syndicator services it will benefit the community towards this end.
 +
 +With that goal in mind, we would like to mentor a bright and motivated student who groks web service oriented architecture. In particular we seek a student who can implement passive synchronization of global, unique IDs over a restful interface.
 +
 +The implementation should:
 +  *Be resilient to connection failure.
 +  *Be able to perform at 4K records (number of 4K records per sec on X-type-pipe) (What's the scale that's reasonable?)
 +  *Does not need to be a text based API. Binary acceptable.
 +  *Function in multiple pipes, such as:
 +    * Cellular
 +    * dialup
 +    * WiFi
 +    * Cable
 +    * DSL
 +    * T1
 +    * T3
 +    * 10 Gigabit Ethernet
 +
 +
 +==== Talking Papers, OCR and a world without data entry  ====
 +by Chamindra de Silva:
 +
 +Rather than elaborate here, I would like to point to the excellent blog post by Robert Kirckpatrick that captures this idea http://humanitariantech.com/2009/11/16/talking-papers-a-world-without-data-entry/ and more here http://www.humanitarian.info/2009/11/24/talking-about-paper/
 +==== ORM for Sahana Phase II ====
 +by Chamindra de Silva
 +
 +Sahana requires a good ORM. Incorporate the doctrine ORM into the Sahana framework.
 +==== Interoperability with InSTEDD RIFF ====
 +by Mark Prutsalis
 +
 +Build two-way interoperability between Sahana's biosurveillance module and InSTEDD RIFF; other general bi-directional integration between InSTEDD GeoChat and Sahana.
 +
 +==== Auto-Assignment of Resources ====
 +by Charles Wisniewski and Darlene McCullough
 +
 +__Introduction__
 +
 +Upon the creation or activation of a shelter system, the essential administrative task of adequately provisioning these centers becomes pressing.  It can be a daunting and time consuming task when there is little time at hand.  The timely distribution of volunteers and materials during an already stressful situation can make all the difference in saving a life and preventing further catastrophe.
 +
 +As part of the logistics module, a dispatch sub-function could be created to automatically distribute and allocate resources; both human and material.
 +
 +__Proposed Wireframe__
 +
 +This is a first pass at a potential wireframe, intended to provide structure and facilitation brainstorming; by no means intended to limit what can be created out of this proposal.
 +  * At the starting screen you can select what you want to provision.  The options include volunteers, materials, or both.
 +  * To ensure scalability for larger activations:
 +    * Shelters can be activated by group or individually
 +    * Resources can be provisioned either as groups or individually.
 +  * Shelters can be customized to provide special needs:
 +    * Resources can be categorized to be allocated to these customized shelters
 +    * //Example//: A deaf client is sent to a shelter with staff that is fluent in sign language.
 +    * //Example//: Insulin donated from a medical provider is auto-assigned to a shelter specializing in elderly clients with diabetes.
 +  * For deploying resources, the originating location of volunteers and other resources influences the distribution algorithm.
 +    * //Example//: Some emergency zones span hundreds of miles and the address or "home" location of a volunteer is considered when deploying them to a shelter.
 +  * Quality of resources is considered during allocation:
 +    * //Example//: The insulin is expired and not distributed.
 +    * //Example//: A volunteer is a Certified First Responder and is sent to an emergency medical shelter instead of someone who is only trained in basic first aid.
 +  * The ability to consume information from a third party logistic information providers.
 +    * //Example//: Traffic reports and their affect on resource allocation routes.
 +    * //Example//: GIS data in KML (Google maps/earth) format.
 +  * At the end of the assignment process a report should be generated on-screen indicating where resources have been allocated and the remaining resource pool to be allocated at a later time.

Navigation
  • Navigate