IATI Consultations Archive

Live discussions and consultations can be found at discuss.iatistandard.org.

Version 2.02 - Formal Proposal

Avatar
IATI Tech Team
Follow

Version 2.02 - Formal Proposal - Overview

 

This is an overview of the proposal leading towards the adoption of IATI's latest decimal upgrade between now and December.  In this iteration we map out the scope of the upgrade and provide a logical proposal for each item under consideration. In the next few weeks formal definitions, the XML schema and a 2.02 development version of the documentation website will be prepared in advance of the approval and adoption of the new version of the standard on 23rd November.

Steering Committee agreed rules covering the conduct of decimal upgrades were agreed in October 2011 and can be found in the Annex 1 here.  

 

CONTENTS

 

 

GENERAL NOTES

 

RESULT INDICATORS AND DISAGGREGATION

Following substantial discussion before and at the last TAG meeting we present proposals to standardise machine-readable indicator codes and to allow for the disaggregation of results by, inter alia, gender, location and age.

 

New attributes: indicator/reference [MODIFIED 20-Nov-2015 due to an error with the original proposal]

  • Addition of three new attributes to the activity standard: vocabulary, code and indicator-uri

  • Example

    • Existing

<indicator measure="1" ascending="1">

    ...

</indicator>

  • Proposed

<indicator measure="1" ascending="1">

    ...

    <reference vocabulary="99" code="B1" indicator-uri="http://example.com/indicators.html" />

</indicator>

  • Add definitions:
    reference: 'A standardised means of identifying the indicator from a code in a recognised vocabulary. Multiple vocabularies may be specified, but each vocabulary may be specified only once for each indicator.'
    reference@vocabulary: ‘A code for a recognised vocabulary of indicators. The value for this field should appear in the IndicatorVocabulary codelist’
    reference@code: ‘A code for an indicator defined in the specified vocabulary specified.’
    reference@indicator-uri: ‘If the vocabulary is 99 (reporting organisation), the URI where this internal vocabulary is defined’

  • For discussion go to http://support.iatistandard.org/entries/79784435-Results-Require-unambiguous-indicator-reference


New codelist: Indicator Vocabulary

 

New element: result/indicator/target/location [ADDED 16-Nov-2015 as it was erroneously omitted from the original proposal]

  • Add new element to the activity standard: location

  • Example

    • Proposed:
      <target value="110">

       <location ref="AF-KAN" />

       <location ref="KH-ABC" />

      </target>

 


New element: result/indicator/target/dimension [ADDED 16-Nov-2015 as it was erroneously omitted from the original proposal]

  • Add new element to the activity standard: dimension

  • Example

    • Proposed
      <target value="110">
       <dimension name="sex" value="female" />
       <dimension name="age value="adult" />
      </target>

  • Add definition
    Dimension: ‘A category used for disaggregating the result by gender, age, etc’
    Name: ‘Freetext description of a category being disaggregation’
    Value: ‘Description of the value being disaggregated.’

New element: result/indicator/actual/location

  • Add new element to the activity standard: location

  • Example

    • Proposed:
      <actual value="110">

 <location ref="AF-KAN" />

 <location ref="KH-ABC" />

</actual>

 


New element: result/indicator/actual/dimension

  • Add new element to the activity standard: dimension

  • Example

    • Proposed
      <actual value="110">

 <dimension name="sex" value="female" />

 <dimension name="age value="adult" />

</actual>



 

HUMANITARIAN

Adapt and embed the existing UNOCHA FTS extension for more generic and extensible humanitarian reporting, Add a humanitarian flag so that individual activities can be identified as being wholly or partially related to humanitarian activity.  Add vocabularies to the existing sector element to allow for the reporting of humanitarian clusters.  Allow the existing policy-marker element to be used for humanitarian vocabularies.  Add a new ‘humanitarian-event’ element for the classification of emergencies, appeals and other events or actions.

 

New attribute: iati-activity/@humanitarian

  • Add new attribute to the iati-activity element: humanitarian

  • Example

    • Current usage
      <iati-activity xml:lang="en" default-currency="USD" last-updated-datetime="2014-09-10T07:15:37Z" linked-data-uri="http://data.example.org/123456789" hierarchy="1">
      ...
      </iati-standard>

    • Proposed usage
      <iati-activity xml:lang="en" default-currency="USD" last-updated-datetime="2014-09-10T07:15:37Z" humanitarian="1" linked-data-uri="http://data.example.org/123456789" hierarchy="1">
      ...
      </iati-standard>

  • Add definition:
    ‘A process flag to indicate that this activity relates entirely or partially to humanitarian aid’

  • For discussion go to http://support.iatistandard.org/entries/106937796-Humanitarian-Flag

 

New attribute: transaction/@humanitarian [ADDED 15-Oct-2015 based on advice][MODIFIED 27-Nov-2015, with improved definition]

  • Add new attribute to the transaction element: humanitarian

  • Example

    • Current usage
      <transaction ref="1234">
      ...
      </transaction>

    • Proposed usage
      <transaction ref="1234" humanitarian="1">
      ...
      </transaction>

  • Add definition:
    'A process flag to indicate that this transaction relates entirely or partially to humanitarian aid. If the entire activity relates to humanitarian aid this should be reported using iati-activity/@humanitarian, rather than for each transaction.'

  • For discussion go to http://support.iatistandard.org/entries/106937796-Humanitarian-Flag

 

Schema amendment: policy-marker/@significance

  • Amend occurrence rules and definition of the significance attribute in the activity standard.

  • Existing

    • Occur: 1..1

    • Definition: An OECD DAC CRS code indicating the significance of the policy marker for this activity. This codelist should be used for all vocabularies. Markers MUST NOT be reported unless a value for significance is present.

  • Proposed

    • Occur: 0..1

    • Definition: An OECD DAC CRS code indicating the significance of the policy marker for this activity. This attribute MUST be used for all OECD DAC CRS vocabularies.

  • For discussion go to: http://support.iatistandard.org/entries/105777943-Humanitarian-Policy-Markers

 

New element: iati-activity/humanitarian-scope [MODIFIED 15-Oct-2015 based on advice]

  • Add new element to the activity standard: humanitarian-scope

  • Example

    • Proposed usage
      <humanitarian-scope type="1" vocabulary="99" vocabulary-uri="http://example.com/vocab.html" code="5">
         <narrative xml:lang="en">Nepal Earthquake (April 2015)</narrative>
      </humanitarian-scope>

  • Add definitions:
    humanitarian-scope: ‘Classification of emergencies, appeals and other humanitarian events and actions’
    humanitarian-scope/@type: ’A code for the type of event or action being classified’
    humanitarian-scope/@vocabulary: ‘A code for a recognised vocabulary of terms classifying the event or action’
    humanitarian-scope/@vocabulary-uri: ‘A u.r.i. for the vocabulary specified which provides access to the list of codes and descriptions’
    humanitarian-scope/@code: ‘A code for the event or action from the vocabulary specified’
    humanitarian-scope/narrative: ‘The description of the code specified’
    humanitarian-scope/narrative/@xml:lang: ‘ISO 639-1 code specifying the language of text in this element. If a default language is specified in the iati-activity element it does not have to be repeated here.’

  • For discussion go to: http://support.iatistandard.org/entries/105778163-Humanitarian-Emergencies-and-Appeals



New codelist: Humanitarian Scope Type [MODIFIED 15-Oct-2015 based on advice]

 

New codelist: Humanitarian Scope Vocabulary [MODIFIED 15-Oct-2015 based on advice]

  • A new non-embedded codelist will be added: ‘HumanitatianScopeVocabulary’. Further consultation is required on values which may include:

    • Code: 1-1
      Name: UN OCHA FTS

    • Code: 1-2
      Name: Glide

    • Code: 2-1
      Name: Humanitarian Plan

    • Code: 2-2
      Name: Start Network

    • Code: 2-3
      Name: Disasters Emergency Committee

    • Code: 99
      Name: Reporting organisation

  • For discussion go to: http://support.iatistandard.org/entries/105778163-Humanitarian-Emergencies-and-Appeals




IMPROVEMENTS TO CRS COMPATIBILITY

To ensure that IATI is fully compatible with the OECD DAC Creditor Reporting System two gaps are being filled. Non-flow items which are reported to CRS++ have been added to the Organisation standard. And the DAC channel of delivery code, for which the code list consists of a mixture of organisation types and names, is added as an additional element to avoid any ambiguity for publishers wishing to derive their CRS output from IATI data.

 


New element : dac-add/non-flow-items [MODIFIED 16-Nov-2015, based on consultation comments]

  • This proposal has been removed, in light of consultation comments. This is because the publication of statistical fields such as GNI will require further thought in order to be consistent with IATIs endeavour to publish raw information.

  • For discussion go to http://support.iatistandard.org/entries/71003738-Non-flow-data

 

New element: crs-add/channel-code [MODIFIED 27-Nov-2015, with improved definition]

  • Add new element to the activity standard: channel-code

  • Example

    • Current usage

<crs-add>
  ...
</crs-add>

  • Proposed usage

<crs-add>
  ...
  <channel-code>21039</channel-code>
</crs-add>

  • Add definition: 
    ‘The CRS channel code for this activity. This should only be used for reporting to CRS. The code list contains both organisation types and names of organisations. For non-CRS purposes these should be reported using the participating-org element.’

  • For further discussion go to http://support.iatistandard.org/entries/83678719-DAC-Channel-of-Delivery

 

New codelist: CRS Channel Code

 

BUDGET ISSUES

 

Two issues relating to the reporting of forward-looking budgets are included. Firstly a status attribute is added to all budget elements to allow publish to be unambiguous about whether the reported budget is indicative or a firm commitment. Secondly budgets for recipient regions are added alongside recipient countries.

 


New attribute: total-budget/@status

 

New attribute: recipient-org-budget/@status

 

New attribute: recipient-country-budget/@status

 

New attribute: budget/@status



New element: recipient-region-budget [MODIFIED 16-Nov-2015 based on feedback from consultation calls][MODIFIED 27-Nov-2015, with improved definition]

  • Add new element to the organisation standard: recipient-region-budget

  • Example 1

    • Proposed:

<recipient-region-budget status="1">
  <recipient-region vocabulary="99" vocabulary-uri="http://example.com/vocab.html" code="A1" />
  <period-start iso-date="2014-01-01" />
  <period-end iso-date="2014-12-31" />
  <value currency="USD" value-date="2014-01-01">25000000</value>
  <budget-line ref="1234">
    <value currency="USD" value-date="2014-01-01">2000000</value>
    <narrative xml:lang="en">Budget Line</narrative>
  </budget-line>
</recipient-region-budget>

  • Add definitions

    • [Definitions to be broadly in line with those for the recipient-country-budget element together with its child elements and attributes]. Notable exceptions:

      • recipient-region: The recipient-region-budget element allows for the reporting of forward looking budgets where the organisation maintains region-wide, rather than or in addition to country-specific budgets. The recommendation is that, where and when possible, the organisation’s total annual planned budget for each of the next three financial years is reported for each recipient region. This must NOT include an aggregation of budgets reported in the recipient-country-budget element. It is strongly recommended that publishers report to existing defined regions wherever possible.

      • recipient-region/@vocabulary: An IATI code for the vocabulary from which the region code is drawn. If it is not present 1 - ‘OECD DAC’ is assumed. The value in recipient-region/@vocabulary should appear within the RegionVocabulary codelist.

      • recipient-region/@vocabulary-uri: ‘If the vocabulary is 99 (reporting organisation)’, the URI where this internal vocabulary is defined’

      • recipient-region/@code: Either an OECD DAC, UN region code or (if code ‘99’ Reporting organisation is selected for recipient-region/@vocabulary) a code from your internal vocabulary. The codelist is determined by vocabulary attribute. The value in recipient-region/@code should appear within the Region codelist, if the vocabulary code 1 (OECD DAC) is used.

    • See the proposed v2.02 summary table spreadsheet for full proposed changes.

  • Add guidance:

    • [Guidance to be broadly in line with those for the recipient-country-budget element together with its child elements and attributes]. Notable exceptions:

      • recipient-region, recipient-region/@vocabulary & recipient-region/@code: Guidance to be based on the recipient-region element

  • For discussion on the element go to http://support.iatistandard.org/entries/79323113-Org-Standard-recipient-region-budget

  • For discussion on the addition of a status attribute go to http://support.iatistandard.org/entries/21150501-Budgets-and-tentativeness

 

New codelist: Budget Status [ADDED 15-Oct-2015 as it was erroneously omitted from the original proposal]



TRANSACTION TYPE - Incoming Commitments

At the request of the Netherlands, and supported by the UK, (the two governments leading the way on traceability of funds down the delivery chain) it is proposed that a new transaction type is added to remove ambiguity between incoming and outgoing commitments.

 


Codelist addition: Transaction Type



New attribute: Transaction/provider-org/@type

  • Addition of a new attribute to the activity standard: type

  • Example

    • Current usage:
      <provider-org provider-activity-id="BB-BBB-123456789-1234AA" ref="BB-BBB-123456789">
         <narrative xml:lang="en">Agency B</narrative>
      </provider-org>

    • Proposed usage:
      <provider-org provider-activity-id="BB-BBB-123456789-1234AA" ref="BB-BBB-123456789" type="10">
         <narrative xml:lang="en">Agency B</narrative>
      </provider-org>

  • Add definition:
    ‘The type of organisation providing the funds. See IATI codelist OrganisationType codelist for values.
    This value should be of type xsd:string.’

  • For discussion: http://support.iatistandard.org/entries/81683876-provider-receiver-og-adding-type



New attribute: Transaction/receiver-org/@type

  • Addition of a new attribute to the activity standard: type

  • Example

    • Current usage:
      <receiver-org receiver-activity-id="AA-AAA-123456789-1234" ref="AA-AAA-123456789">
          <narrative xml:lang="en">Agency A</narrative>
      </receiver-org>

    • Proposed usage:
      <receiver-org receiver-activity-id="AA-AAA-123456789-1234" ref="AA-AAA-123456789" type="10">
          <narrative xml:lang="en">Agency A</narrative>
      </receiver-org>

  • Add definition:
    ‘The type of organisation receiving the funds. See IATI codelist OrganisationType codelist for values.’
    This value should be of type xsd:string.

  • For discussion: http://support.iatistandard.org/entries/81683876-provider-receiver-og-adding-type



IMPROVEMENTS IN USE OF VOCABULARIES

 

Wherever vocabularies are in use to drive codelists, and particularly when publishers use their own codelist, it is useful to be able to link to the list in question. It is therefore proposed to add a vocabulary-uri attribute alongside all vocabulary occurrences.



New attribute: recipient-region/@vocabulary-uri

  • Add new attribute: vocabulary-uri

  • Example

    • Current usage
      <recipient-region code="A1" vocabulary="99" percentage="50" />

 



New attribute: transaction/recipient-region@vocabulary-uri

  • Add new attribute: vocabulary-uri

  • Example

    • Current usage
      <recipient-region code="A1" vocabulary="99" />

    • Proposed usage
      <recipient-region code="A1" vocabulary="99" vocabulary-uri="http://example.com/vocab.html" />

 



New attribute: sector/@vocabulary-uri



New attribute: transaction/sector/@vocabulary-uri

  • Add new attribute: vocabulary-uri

  • Example

    • Current usage
      <sector vocabulary="99" code="A1" />

    • Proposed usage
      <sector vocabulary="99" vocabulary-uri="http://example.com/vocab.html" code="A1" />

 

 

New attribute: policy-marker/@vocabulary-uri

  • Add new attribute: vocabulary-uri

  • Example

    • Current usage
      <policy-marker vocabulary="1" code="2" significance="3" />

    • Proposed usage
      <policy-marker vocabulary="1" vocabulary-uri="http://example.com/vocab.html"  code="2" significance="3" />

 



PROVIDER & RECEIVER ORGANISATION CLARITY

 

Amend guidance: participating-org

  • This change will not affect the schema.

  • Append to guidance:
    ‘It is strongly recommended that the name of the organisation is provided (using the narrative child element) in addition to a valid organisation identifier. Where an organisation identifier is not present the name (using the narrative child element) is mandatory.’

  • For further discussion, go to http://support.iatistandard.org/entries/83872305-Clearer-guidance-on-organisation-names

CHANGES TO CODELIST MANAGEMENT POLICY

Codelist management policy

  • Modification to the codelist.xsd to add three attributes status, activation-date and withdrawal-date.

  • Example

    • Current usage

   <codelist-item>

      <code>AUR</code>

      <name>

          <narrative xml:lang="en">(Ancient Roman) Aureus</narrative>

      </name>

   </codelist-item>

  • Proposed usage

   <codelist-item status="active" activation-date="2000-01-01" withdrawal-date="2017-01-01">

       <code>ZMK</code>

           <name>

              <narrative xml:lang="en">Zambian Kwacha</narrative>

          </name>

   </codelist-item>



ORG STANDARD IMPROVEMENTS

New element: total-expenditure

  • Add a new element to the organisation standard: total-expenditure

    • Proposed example
      <total-expenditure>
        <period-start iso-date="2014-01-01" />
        <period-end iso-date="2014-12-31" />
        <value currency="USD" value-date="2014-01-01">250000000</value>
        <expense-line ref="1234">
          <value currency="USD" value-date="2014-01-01">200000000</value>
          <narrative xml:lang="en">Expense Line</narrative>
        </expense-line>
       </total-expenditure>

  • Add definitions:

    • total-expenditure: ‘The total-expenditure element allows for the reporting of the organisation’s international development expenditure. The recommendation is that, where and when possible, the organisation’s total expenditure for each of the past three years is reported. The expense line allows publishers to record further breakdown.’

    • [Further documentation and guidance will be added for each of the child elements & their attributes: period-start, value and expense-line in accordance with the elements & attributes that form part of total-budget.]

    • See the proposed v2.02 summary table spreadsheet for full proposed changes.

  • For discussion, go to: http://support.iatistandard.org/entries/83404469-Add-Total-Expenditure-Element-To-Organisation-File

 

MISCELLANEOUS

 

New attribute: participating-org/@activity-id [MODIFIED 27-Nov-2015, with improved definition]

  • Add new attribute: activity-id

  • Example

    • Current usage

    <participating-org ref="BB-BBB-123456789" role="2" type="40">
          <narrative xml:lang="en">Name of Agency B</narrative>
    </participating-org>

  • Proposed usage

<participating-org ref="BB-BBB-123456789" role="2" type="40" activity-id="BB-BBB-123456789-1234">
          <narrative xml:lang="en">Name of Agency B</narrative>
    </participating-org>

 

 


New element: document-link/document-date

  • A new element will be created: document-date

  • Example

    • Current usage
      <document-link format="application/vnd.oasis.opendocument.text" url="http:www.example.org/docs/report_en.odt">
        ...
      </document-link>

    • Proposed usage

<document-link format="application/vnd.oasis.opendocument.text" url="http:www.example.org/docs/report_en.odt">
  ...

  <document-date iso-date="2013-10-05" />
 </document-link>

  • Add definition:
    Element: ‘The date of publication of the document that is being linked to.’
    Attribute @iso-date: ‘This attribute is required. This value should be of type xsd:date.’

  • Add guidance:
    ‘Document date would normally be the production or published date of the relevant document to identify the specific document version’

  • For further discussion go to http://support.iatistandard.org/entries/92707776-Document-Dates

 

New elements: planned-disbursement/provider-org & planned-disbursement/receiver-org

  • Add new elements with planned-disbursement in the activity standard: provider-org and receiver-org

  • Example

    • Existing
      <planned-disbursement type="1">
        …
      </planned-disbursement>

    • Proposed
      <planned-disbursement type="1">
        ...
        <provider-org provider-activity-id="BB-BBB-123456789-1234AA" ref="BB-BBB-123456789" type="10">
          <narrative xml:lang="en">Agency B</narrative>
        </provider-org>
        <receiver-org receiver-activity-id="AA-AAA-123456789-1234" ref="AA-AAA-123456789" type="10">
          <narrative xml:lang="en">Agency A</narrative>
        </receiver-org>
      </planned-disbursement>

  • Add definitions

Definitions to be in line with appears for provider-org and receiver-org as child elements to the transaction element.

 

Guidance amendment: planned-disbursement

 

Schema amendment: planned-disbursement/period-start

 

Schema amendment: planned-disbursement/period-end

 

Guidance addition: planned-disbursement/period-start & planned-disbursement/period-end

  • This change will not affect the schema.

  • Add guidance

    • The period start should define when the actual transfer of funds will take place, if a specific date is known. If the specific payment date is not known, the period in which the transfer is due to take place should be described by using both period-start and period-end dates.

    • The timeframe between period-start and period-end should not normally exceed 3 calendar months

  • For further discussion go to http://support.iatistandard.org/entries/29665337-Add-provider-org-and-receiver-org-to-planned-disbursement-element



ADDITIONAL CODELIST CHANGES

Codelist addition: Region Vocabulary

 

Codelist additions: Sector Vocabulary [MODIFIED 16-Nov-2015 based on advice]

 

Codelist addition: Version [ADDED 9-Nov-2015]

  • Addition of the following code:

    • Code: 2.02

    • URL: http://iatistandard.org/202/

 

Consultation

  • All members of the Steering Committee, all publishers and users of IATI data, and all members of the IATI Technical Advisory Group are invited and encouraged to participate in this consultation.

  • You can do this by commenting on the specific topics that are linked to the detailed proposals laid out in the links above. We are also holding public consultation calls in the weeks beginning 12th October (dates and times here) and 3rd November (dates and times TBC).

  • If you prefer to comment privately you are welcome to email support @ iatistandard.org

  • It is hoped that a transparent, collaborative consensus will develop out of this consultation.

  • The consultation ends on 23rd November. On that date all proposals that have consensual agreement will be included in the 2.02 upgrade
Have more questions? Submit a request

0 Comments

Article is closed for comments.