As of the 1st of February 2015 this wiki has been deprecated.
This archive is now a read only site.
There is also a copy of the history that has been converted into a git repository at: https://github.com/IATI/IATI-Wiki-Archive.
Please do not rely on any of the information found here.

roadmap

Create IATI public good architecture blueprints

Making IATI work effectively for a wide range of potential users involves more than just a data standard. A 'Public Good Infrastructure' plan will identify common re-usable components and tools that could benefit many users of IATI. It will suggest ways in which a 'service oriented architecture' approach, and the development of secondary standards, can support the creation of a vibrant eco-system of user-focussed tools that use IATI data to meet real needs.

Layers and elements of IATI

IATI can be divided into four layers:

  • The Data Layer - this forms the core of IATI, and is made up of the IATI Standard and IATI Registry. The core IATI platforms do not host data, and is not a database, but instead provides a common means of exchanging data, and registry of meta-data on datasets available from third-parties.
  • The Access Layer - many use cases of IATI involve accessing data that might be spread across many raw data files. An access layer provides a simple means of getting hold of raw data, regardless of the particular files it is contained in. It contains secondary standards, adopted by the community, for serialising IATI data as CSV, JSON or Linked Data.
  • The Service Layer - many processes involved in creating or using IATI data will involve common tasks, such as normalising currencies, mapping between code-lists, or querying to fetch specific data by geography or project value (for example). The service layer contains common modular services that act as building blocks for end-users of IATI.
  • The User Interface Layer - this contains user-friendly tools for creating or accessing IATI data.

The data layer is already an accepted part of the core IATI initiative, funded and maintained through the technical secretariat.

The need for IATI core to provide a basic access layer is increasingly recognised, but no decision on whether IATI should manage the maintenance of basic tools for accessing data across files, or of secondary standards for serialising the data, is yet made [July 2012].

The service layer has largely developed ad-hoc and is incomplete, with many gaps at present.

Early notes

The IATI public good infrastructure may involve:

  • Tools to aggregate and process IATI data
  • A data store
  • APIs onto that data
  • Convenience services for working with the data
  • Basic visualisation services
  • E-mail alerts

These are all services which it makes sense to either

  • a] provide once centrally;
  • b] which have the properties of being diminishable public goods;
  • c] provide as interchangeable layers of an infrastructure;

As a number of different projects develop that work with IATI data, articulating a shared blueprint for how tools should work together will be beneficial.

What might be in an IATI Toolkit

From http://lopad.org/4vf3Bjwnho.

  • API - data as a service (e.g. Chris' Exist work)
    • Project access
    • Spending access
    • Geographical search
    • Aggregated data
  • database and API 'in a box'
  • data harvesting (from the registry)
  • conversion tools - serialisation
  • currency conversion tool
  • data cleaning tools & routines
  • notification functions
  • code list verficiation
  • mashing datasets
  • documentation for end-users
  • Geographic Information Systems based tools
Create IATI public good architecture blueprints Task
Assigned to:Tim Davies
Due date:2012/06/22

QR Code
QR Code Create IATI public good architecture blueprints (generated for current page)