-
Notifications
You must be signed in to change notification settings - Fork 20
IATI Import mapping
There are several fields which are mandatory in order to publish your project in RSR, using IATI import:
- IATI identifier;
- Title;
- Subtitle (special description type, or otherwise copied from
title
); - Status (not 'Suspended');
- (Planned or actual) Start date;
- Photo (
document-link
with an image file); - At least one funding, implementing or accountable participating organisation;
- Project plan summary (a
description
); - Goals overview (a
description
with type 2); - A location with latitude and longitude;
- A budget item.
This node contains information about the data set and is not directly mapped to elements within the RSR data structure. In order to import an IATI file into RSR, the version
attribute is required and needs to be a valid IATI version. All IATI versions up to 2.02 are supported in RSR.
If the IATI file contains Akvo specific fields, please indicate the Akvo namespace as an attribute in this node: xmlns:akvo="http://akvo.org/iati-activities"
.
This node contains activity level information that is mapped to the project level within RSR.
All IATI attributes in this node are supported in RSR. It is possible to specify one Akvo specific attribute in this node: akvo:publish
. Set the value of this attribute to 'True' if the project should be published, and to 'False' otherwise. If not specified, we will assume that the project needs to be published.
This node contains the IATI identifier that will be used to look up the corresponding project in RSR. If a project with this identifier does not yet exist in RSR, a new project will be created. Otherwise, the existing project will be updated.
Within RSR the reporting organisation relates to the organisation that owns the content of the project. It is required that the reporting organisation is an existing organisation in RSR which is allowed to import projects.
The reporting organisation will solely be matched based on the IATI organisation identifier as specified in the ref
attribute of this node.
Title fields within RSR are restricted to 200 characters. If the title specified has more than 200 characters, we will cut off the text and use the first 200 characters as the title. The full title will still be stored in a custom title field, but not displayed as such on the project page.
The description section is where we have the most customisation to the IATI standard from RSR. We have added an additional codelist for adding more different types of descriptions.
We have many description fields within RSR that provide a granular opportunity to explain the activities being undertaken. These sections help to provide a consistent public narrative for activities of an organisation and all publishers within RSR.
It is possible to indicate the subtitle in multiple ways:
- When using the Akvo namespace, use the
akvo:type="4"
attribute. - Without the Akvo namespace, it is possible to indicate the subtitle by prepending
Subtitle:
orProject name:
before the text in the node. - If none of these is used, we use the
<title>
node for the subtitle.
The subtitle text is limited to 200 characters. If the subtitle text has more than 200 characters, we store the full text in a custom subtitle field which is not displayed on the project page.
It is possible to indicate the project plan summary in multiple ways:
- When using the Akvo namespace, use the
akvo:type="5"
attribute. - Without the Akvo namespace, it is possible to indicate the project plan summary by prepending
Project summary:
before the text in the node. - If none of these is used, we use the first
<description>
node without atype
attribute or withtype="1"
as an attribute.
The project plan summary is limited to 2000 characters. If the project plan summary has more than 2000 characters, we store the full text in a custom project plan summary field which is not displayed on the project page.
It is possible to indicate the goals overview in multiple ways:
- When using the Akvo namespace, use the
akvo:type="8"
attribute. - Without the Akvo namespace, it is possible to indicate the project plan summary by using the
type="2"
attribute. - If none of these is used, we extract the titles for each of the
<result>
nodes and put these in a list.
The goals overview is not limited to any character limit.
It is possible to indicate the background in multiple ways:
- When using the Akvo namespace, use the
akvo:type="6"
attribute. - Without the Akvo namespace, it is possible to indicate the background by prepending
Background:
before the text in the node. - If none of these is used, we use the second
<description>
node without atype
attribute or withtype="1"
as an attribute.
The background is not limited to any character limit.
It is possible to indicate the baseline situation in multiple ways:
- When using the Akvo namespace, use the
akvo:type="9"
attribute. - Without the Akvo namespace, it is possible to indicate the baseline situation by prepending
Baseline situation:
before the text in the node. - If none of these is used, we use the third
<description>
node without atype
attribute or withtype="1"
as an attribute.
The baseline situation is not limited to any character limit.
It is possible to indicate the target group in multiple ways:
- When using the Akvo namespace, use the
akvo:type="3"
attribute. - Without the Akvo namespace, it is possible to indicate the target group by using the
type="3"
attribute.
The target group is not limited to any character limit.
It is possible to indicate the project plan in multiple ways:
- When using the Akvo namespace, use the
akvo:type="7"
attribute. - Without the Akvo namespace, it is possible to indicate the project plan by prepending
Project plan:
before the text in the node. - If none of these is used, we use the fourth
<description>
node without atype
attribute or withtype="1"
as an attribute.
The project plan is not limited to any character limit.
It is possible to indicate the sustainability in multiple ways:
- When using the Akvo namespace, use the
akvo:type="10"
attribute. - Without the Akvo namespace, it is possible to indicate the sustainability by prepending
Sustainability:
before the text in the node. - If none of these is used, we use the fifth
<description>
node without atype
attribute or withtype="1"
as an attribute.
The sustainability is not limited to any character limit.
It is possible to indicate any number of custom text fields in RSR, by using the akvo:type="99"
attribute. The use of the Akvo namespace is required in this case. There are several additional attributes that can be specified:
-
akvo:label
: The label of the custom field, as displayed in the RSR Project editor -
akvo:section
: The section of the custom field in the RSR Project editor -
akvo:max-characters
: The maximum number of characters for the custom field -
akvo:help-text
: The help text for the custom field in the RSR Project editor -
akvo:mandatory
: 'True' or 'False' to indicate the field should be mandatory in the RSR Project editor -
akvo:order
: The order (per section) in which the custom fields will be displayed in the RSR Project editor
This node records any partner organisations working on the activity. Based on the ref
attribute, we will match the specified organisation to an organisation in RSR. If we are unable to match to an existing organisation in RSR based on this IATI organisation identifier, we will try to match the organisation based on the name specified in the text of the node.
If we could not match the organisation to any existing organisations in RSR, a new organisation will be created based on the specified IATI organisation identifier and organisation name.
If the partner is providing funding for the project, then the total amount provided can also be included within this node with the akvo:funding-amount
attribute. We aim to work with publishers to replace this field over time with the more granular information available within the transaction node.
In case the akvo:funding-amount
attribute is not specified, we will calculate the funding amount by dividing the total budget amount by the number of funding partners. E.g. a project with a total budget of €100,000 and 2 funding partners will result in a funding amount of €50,000 for each funding partner.
The structure for the project status in RSR is directly adopted from the IATI structure of the activity status.
We have adopted the 4 types of activity date from IATI in RSR: start and end, actual and planned. Do note that the planned end date must always occur after the planned start date, and similar for the actual dates.
The structure for contact information is directly adopted from the IATI structure. Therefore it is possible to store the contact type, organisation, department, person name, job title, telephone, email, website, and mailing address.
The scope determines the geographical spread of the activities being undertaken. This also has been ported directly into RSR from IATI.
This node identifies the countries that the project aims to benefit. This structure comes directly from the IATI standard.
This node identifies the regions that the project aims to benefit. This structure comes directly from the IATI standard.
The location node includes all the specific geographic information provided. The structure being provided by IATI gives options for entry of a variety of different types of locations - from areas or towns to individual buildings or features.
Within RSR there is an additional country field for each location. It is possible to specify this country in an <administrative>
node with the country
attribute. Since this field is deprecated in newer versions of IATI, we have alternatively also implemented a feature to extract the country from the <recipient-country>
node and link it to the location. However, this only works when there is one <recipient-country>
node.
RSR has fully adopted the OECD DAC sector codelists and will be using a combination of the 3 and 5 digit codes for projects in RSR.
Country budget items were not existing in RSR previously, so we have added these using the native IATI data structure.
Policy markers have been added to RSR directly from IATI. We are looking at potentially expanding the existing codelist with additional markers defined by government level partners as used within their frameworks. This will be explicitly mentioned when it is implemented.
This node has been implemented directly from the IATI standard as it was not previously existing in RSR.
This node has been implemented directly from the IATI standard as it was not previously existing in RSR.
This node has been implemented directly from the IATI standard as it was not previously existing in RSR.
This node has been implemented directly from the IATI standard as it was not previously existing in RSR.
This node has been implemented directly from the IATI standard as it was not previously existing in RSR.
The budget node fits very nicely with the existing RSR structure. Additionally we have an extra budget type codelist within RSR that we will be using to further refine the identification of budgets entered. This can be specified with the akvo:type
and akvo:label
attributes.
In case the budget type or label is not specified, we assign the 'Total' budget label in case there is only one budget, or the 'Other' budget label in case there are multiple budget items. In the latter case, we will label the budgets based on the year of its' start date. E.g. when there are two budget items, one starting in 2014 and one in 2015, the budget items will be automatically labeled '2014' and '2015'.
This node has been implemented directly form the IATI standard as it was not previously existing in RSR.
This node has been implemented directly form the IATI standard as it was not previously existing in RSR.
Transactions were not represented within the RSR data set, so we have implemented the IATI standard data set natively. We aim to increase the utilisation of this node within the data being published within RSR as we encourage more specific transaction information over general funding information at transaction level.
In addition, we try to match the organisations mentioned in the <provider-org>
and <receiver-org>
nodes to existing organisations within RSR. If this is not possible, we will create a new organisation.
This node within IATI is used to link to additional documents for supporting evidence. Within RSR, this node is implemented directly from the IATI standard. However, we also use this node in two special cases.
The image of a project is an important aspect of RSR. In order to retrieve the image, we will look for the first <document-link>
that has an image (with the 'gif', 'jpg', 'jpeg', 'png', or 'tiff' extension) specified in the url
attribute.
The caption of the image will be retrieved from the <title>
node, and in addition it is possible to specify a akvo:photo-credit
attribute in the <document-link>
node.
Any <document-link>
nodes with the format
attribute set to 'application/http' will be imported into RSR as links. Similar to the <activity-website>
node, which has been deprecated in newer versions of IATI.
The related activity is aimed to be the primary resource of linking activities together when published via RSR. In order to indicate a hierarchy or a programme within RSR, related projects are used.
Especially for projects making use of the monitoring and evaluation functionalities, this is useful. By stating that a project has a child project, the results of the child project will be aggregated into the its' parent project.
This node has been implemented directly form the IATI standard as it was not previously existing in RSR.
RSR has implemented the IATI results framework, containing results, indicators and indicator periods. Therefore, any results specified can be directly imported into RSR.
Although not visualised on RSR itself, it is possible to store legacy data. This node has been implemented directly from IATI.
Although not visualised on RSR itself, it is possible to store CRS++ data. This node has been implemented directly from IATI.
Although not visualised on RSR itself, it is possible to store FSS data. This node has been implemented directly from IATI.
Some data can be ignored when importing into RSR. This is done by setting the attribute akvo:import
to a "falsey" value on the element that is to be ignored. All elements of that type and all data in child elements will be ignored when importing even if only one or a few of the elements are set to akvo:import="false"
, but it's best to set the attribute on all elements for clarity. Any data of the kind represented by the ignored elements already present in an RSR Project, if one already exists for the activity, is left unchanged.
"Falsey" values are false, 0, no and f.
Ignoring on import is currently supported for the following elements: budget, contact-info, humanitarian-scope, legacy-data, location, participating-org, planned-disbursement, policy-marker, recipient-country, recipient-region, related-activity, result, sector
and transaction
.
To leave out all information on locations a snippet of the XML could look like this:
...
<recipient-country code="AF" percentage="25" />
<recipient-country code="AG" percentage="25" />
<recipient-region code="489" vocabulary="1" percentage="25" />
<recipient-region code="289" vocabulary="1" percentage="25" />
<recipient-region code="A1" vocabulary="99" vocabulary-uri="http://example.com/vocab.html" percentage="100" />
<location ref="AF-KAN" akvo:import="false">
<location-reach code="1" />
<location-id vocabulary="G1" code="1453782" />
<name>
<narrative>Location name</narrative>
</name>
<description>
<narrative>Location description</narrative>
</description>
<activity-description>
<narrative>A description that qualifies the activity taking place at the location.</narrative>
</activity-description>
<administrative vocabulary="G1" level="1" code="1453782" />
<point srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<pos>31.616944 65.716944</pos>
</point>
<exactness code="1"/>
<location-class code="2"/>
<feature-designation code="ADMF"/>
</location>
<location ref="KH-PNH" akvo:import="false">
<location-reach code="1" />
<location-id vocabulary="G1" code="1821306" />
<name>
<narrative>Location #2 name</narrative>
</name>
<description>
<narrative>Location #2 description</narrative>
</description>
<activity-description>
<narrative>A description that qualifies the activity taking place at location #2</narrative>
</activity-description>
<administrative vocabulary="G1" level="1" code="1453782" />
<coordinates latitude="31.616944" longitude="65.716944" />
<exactness code="1"/>
<location-class code="2"/>
<feature-designation code="ADMF"/>
</location>
<sector vocabulary="2" code="111" percentage="50" />
<sector vocabulary="2" code="112" percentage="50" />
...