IATI Technical Advisory Group
1 / 10

Agree technical requirements Discuss draft proposals and issues - PowerPoint PPT Presentation

  • Uploaded on

IATI Technical Advisory Group Technical Proposals Simon Parrish IATI Technical Advisory Group, DIPR March 2010. Objectives. Agree technical requirements Discuss draft proposals and issues Hear new ideas and possible solutions for meeting the requirements

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Agree technical requirements Discuss draft proposals and issues' - arvid

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

IATI Technical Advisory Group Technical ProposalsSimon ParrishIATI Technical Advisory Group, DIPR March 2010


Agree technical requirements

Discuss draft proposals and issues

Hear new ideas and possible solutions for meeting the requirements

Agree headline proposals for: licensing, data formats, architecture

Identify additional issues that need to be considered

(where possible) Consider issues identified

Agree concrete follow up


Technical Requirements

The design is based on ‘specialist users’ being the direct consumers and users of IATI data (should IATI do more?)

  • Openly licensed — any third party must be allowed to use any published IATI data under consistent open terms, without requiring explicit permission from the donor who provided the data.

  • Machine-readable — it must be possible for computer programs to extract useful information from IATI data without manual intervention.

  • Easily accessible — users must be able to obtain IATI information automatically and anonymously. IATI should use well-known and well-supported open networking formats and protocols.

  • Decentralised — IATI must be capable of continuing to function without a centralised administrator or computer system (no single point of failure)


Technical Requirements

Comparable — while not all donors will supply all data specified by IATI, whenever two donors do supply the same data, it must be possible for users to compare those data in a meaningful way.

Flexible — data formats and publishing schedules must allow donors the flexibility to omit information that is not relevant or available at different points in the information's life cycle.

Extensible — it must be possible for donors to supply additional information not covered by IATI.

Vendor- and platform-independent — IATI information publishing must not depend on software from a specific vendor, or on a specific hardware or software computing platform.

Multilingual — for human-readable text, IATI must support all major world languages, and it must support multiple versions of the same text in different languages.


Licensing of Data

Headline proposal

The adoption of one standard open licensing model

  • As few constraints as possible for using data (inc. commercial)

  • License policy should be easy to understand by users

  • Data and docs require different licenses


  • Which license model should we adopt?

    • Public domain?

    • attribution?

    • share-alike?


Data Formats

Headline proposal

IATI develops a standard XML format and developing a new schema

(discussion: The role and opportunity for RDF / linked data / semantic web)


  • What other standards should we look into (IDML, SDMX etc.)

  • Should IATI develop translation tools for different formats?

  • URL based unique identifiers

  • How do we create unique ids?


Technical Architecture

Headline proposal

data providers should publish machine-readable aid- data files in a std format on public websites


Files vs. API

Should we beyond raw data to provide user interface to the data?)


  • How data should be segmented – by activity? country? data provider?

    • 3 criteria: non-duplication, persistence, granularity

  • How data should be updated and versioned?

    • Whole vs. Incremental updates

    • How important is keeping historical data


Technical Architecture – The Registry

Headline proposal

an IATI website will create a registry of links to these aid-data files


  • How important is it that the registry isn’t a single point of failure

  • How should the registry be updated?

    • Push (data providers inform the registry directly) or pull (more sustainable decentralised option of data providers also publishing index and summary files to enable the registry )

  • Notification mechanism. – implemented in registry and/or donor websites

  • What is the role of the registry? Other roles?

    • ID generator, data entry, data translating, hold taxonomies

    • Provide registry software for every provider


Geographic coding

Headline proposal

We have suggested some options for addressing geographic classifications in three ways: 1) international standard ISO codes 2) geodesy codes 3) text.



What it the role of IATI?