1 / 10

Agree technical requirements Discuss draft proposals and issues

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

arvid
Download Presentation

Agree technical requirements Discuss draft proposals and issues

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Objectives 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 www.aidtransparency.net

  3. 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) www.aidtransparency.net

  4. 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. www.aidtransparency.net

  5. 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 Issues: • Which license model should we adopt? • Public domain? • attribution? • share-alike? www.aidtransparency.net

  6. 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) Issues: • 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? www.aidtransparency.net

  7. Technical Architecture Headline proposal data providers should publish machine-readable aid- data files in a std format on public websites (discussion: Files vs. API Should we beyond raw data to provide user interface to the data?) Issues: • 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 www.aidtransparency.net

  8. Technical Architecture – The Registry Headline proposal an IATI website will create a registry of links to these aid-data files Issues: • 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 www.aidtransparency.net

  9. 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. Issues: www.aidtransparency.net

  10. What it the role of IATI? www.aidtransparency.net

More Related