"One thing to bind them all!"
Contents |
Team working on Global Pulse Recipe Manager at New York are:
Chenai and Evangelia are looking at existing data sources and application inputs/outputs, working out how to characterise these so we can input, search and match between them. Jen Ziemke is helping them as an SME at the moment.
Sara and Graham are paired up as a coding team
Daphne and James are paired up as a coding team
Project name is Oliver (as in the chef).
Where to find things:
Languages etc:
How to join in with the coding environment:
Stories
The coders are concentrating on the registry of databases and feeds at the moment. This is because the core of the recipe manager is the ability to search and compare database descriptions.
a data source is "something you can extract info from", and probably has:
We decided that 'application' had too many connotations, so we used 'module' instead. A module is something that converts data into something else (where 'something else' could be data, a feed, or a gui).
Also using Bvira reference architecture.
The non-coders are working out what the questions we need to ask about data stores should be, then taking these questions and asking them of the other rhok project teams. We are working from the perspective of a developer interested in developing "adaptors", i.e. software, that allow data stores and apps to" talk" to each other through the data that they generate. The idea is that within Global Pulse users would be able to build data flows that string together different data and analytical tools, depending on their needs and aims. Over time users would be able to share insights about these composite chains, which we call recipes, creating demand for more apps and adaptors and motivating data suppliers to facilitate access to their data.
One thing that we came to realise pretty quickly is the enormous amount of work that has been done to facilitate the exchange of socio-economic data (e.g. see [[1]]. Programmers would need to be aware of these standards, as well as those in place for other scientific communities (meteorologists, GIS specialists, medical professionals, etc).
CRMAT Sudan Team
The project collects four types of data:
For each type of data, information is collected on who, what, where and when. Information on the "who" and "what" categories change depending on the type of data. For incidents, for instance, information is collected on who the perpetrators and the victims are. For activities, the "who" can be national, international organisations and NGOs.
The app is written in C#. It currently runs only on Windows. The source code for the application is open. CRMAT does not have an API. It currently exports data in CSV and XML formats.
Data sharing: this is something that needs to be followed up with Helena. Conflict data are extremely sensitive and we are expecting that they will have safeguards in place.
Users for the app: In this instance: the Sudanese government, international agencies and NGOs operating in the region.
At the moment the app works in standalone/offline mode and does not consume data from other services.
OpenStreetMap This is a very well-documented project with lots of information online. The developer's page [[2]] provides good overview of OSM's building blocks.