IATI Consultations Archive

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

Add xs:duration attribute to certain dates to indicate aggregation spans

Avatar
Mike Smith
Follow

(re-opening idea from: “Add xs:duration attribute to certain dates” with clarifications)


Suggestion to allow periods of time as well as events. Could use additional xs:duration for elements such as transaction/transaction date where it is not necessary to have the date as an event in time (as opposed to transaction/value/@value-date or activity-date/@iso-date which must be events , eg for the former the date is for currency conversion, the latter it is not known a priori eg. the end-actual date) 

Clarifications: without xs:duration how would you reliably determine the length of time that eg. a transaction spans - it could be a monthly aggregation, quarterly, yearly etc. – current IATI documentation suggests one has to read free-text: http://iatistandard.org/201/activity-standard/iati-activities/iati-activity/transaction/transaction-date/ "The narrative content may contain text (e.g. 2011Q1) for accurately recording less specific dates such as month, quarter, or year." I imagine this would affect any visualisation trying to create a “per month” value from IATI data.

Have more questions? Submit a request

12 Comments

Date Votes
  • 0
    Avatar
    Bill Anderson

    Mike I don't think this is a good idea for a number of reasons

    • Currency conversion requires reference to a specific date
    • Duration will make use of data substantially more complex
    • As the standard expects data to be published at least quarterly, a quarter in arrears, annual aggregations (which I agree can cause confusion depending on financial years) are not recommended. 
    • Publishers will normally have a standard approach to aggregation which can be reported in the implementation schedule. There is also general guidance then that the first date of the period is used to report commitments, and the last date for disbursements and expenditures.
  • 0
    Avatar
    Mike Smith

    <!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->

    Thanks for the feedback, however I think you have misunderstood the proposal.  To clarify:
    • Currency conversion requires reference to a specific date
    >> Some elements, such as transaction/transaction-date are not used for currency conversion - I'm NOT suggesting the addition of xs:duration to transaction/value/@value-date or activity-date/@iso-date which must be events (per both our posts).
    • Duration will make use of data substantially more complex
    >> I disagree - at the moment there is no way to programmatically determine what aggregation an organisation is using through just IATI data - e.g. how can you tell when an organisation provides the minimum requirement of quarterly in some areas but monthly in others, or when comparing across organisations?  The current approach of having to lookup each implementation schedule is far more complex and prone to error (not all organisations even document to this level!).
    • As the standard expects data to be published at least quarterly, a quarter in arrears, annual aggregations (which I agree can cause confusion depending on financial years) are not recommended.
    >> What about forward looking annual budgets?  Is it better to give annual figures that are well defined (e.g. using xs:duration or equivalent) vs. no data at all?
    • Publishers will normally have a standard approach to aggregation which can be reported in the implementation schedule. There is also general guidance then that the first date of the period is used to report commitments, and the last date for disbursements and expenditures.
    >> See above
    More than willing to discuss this further, but if xs:duration (a standard part of the XSD Data type definitions) is out of the question, could you point us in the direction to a document that highlights all the emerging conventions on the “standard” IATI approach and how to interpret the data - at the moment these seem (unless I am missing something) to be disbursed across the IATI standards reference pages, could these be gathered in one place? 
  • 0
    Avatar
    Bill Anderson

    Apologies Mike. I've clearly not read your suggestion properly. Will review again.

  • 0
    Avatar
    IATI Tech Team

    This proposal has been discussed amongst the IATI Technical Team following the end of the initial suggestion phase of the v2.02 upgrade.

    The IATI Technical Team encourage further discussion and invite others who support this proposal to post accordingly before 7th October when a final decision on inclusion within v2.02 will be made.

  • 0
    Avatar
    Sarah Johns

    Would it be possible to use this idea of xs:duration to also indicate projects that have no particular end date (planned or actual)? For example the codelist could include: quarterly, annual, monthly, no end date

  • 0
    Avatar
    Mike Smith

    I had a quick look through the documentation and can see that although dates are always dealt with using attributes in IATI, date spans are dealt with inconsistently, some:

    • use attributes to depict if the date is e.g. a start or an end date e.g. activity-date
    • use free-text e.g. transaction-date
    • have separate but related elements that depict if the date is e.g. a start or an end date e.g. period-start and period-end
    • have no support for spans as they must be events e.g. value
    This proposal was about the second scenario where there is no means to reliably, programmatically determine the date span.  I suggested that the xs:duration could be used as it draws on a standard part of the XSD Data type definitions, but on reflection I understand if other mechanisms might be more in keeping with the IATI standard.
    I also agree with Sarah that it is also important to have a means to indicate where there is no envisaged activity end date, particularly if IATI data is to be useful in helping us move us away from projects that stop when some particular funding stops  - at the moment you have to either:
    • put a ridiculous year, such as 3000
    • do not put an end date
    Both are misleading, and the second option makes it appear as if the data is incomplete (and indeed fails some minimum publishing standards and means that activities are dropped or badly handled by some leading visualisations).  However, allowing the use of xs:duration with start-date in this scenario might be mis-leading as it permits two different ways to define an activity end date ( either with start and end attributes or with start and duration attributes) - is this a problem?
    What might be a good way of capturing date spans in these scenarios? 
  • 0
    Avatar
    Rolf Kleef

    In our work with NGOs on security concerns, we suggest they can publish the aggregate disbursements to a recipient at the last day of a quarter (Cordaid started this practice), to conceal details about payment schedules. Right now, that means the transaction date is the last day of a quarter.

    An added duration attribute could express this practice explicitly, to indicate it is an aggregate number. Same with expenses, etc.

    (However, you still can't specify an appropriate date for currency conversion.)

    For the open-ended activities, we advise to add a somewhat realistic end date (e.g. 1 Jan 2020). Interpret "planned" more as "foreseeable", and don't hesitate to adapt. If it's part of your strategic plan, use the end of the time period of your strategic plan.

    xs:duration won't help here :-)

  • 0
    Avatar
    Mike Smith

    Hi Rolf, great to hear the aggregation use case on security grounds, thanks.

     

    Re: currency conversion - this uses an attribute under transaction/value called @value-date - see http://iatistandard.org/201/activity-standard/iati-activities/iati-activity/transaction/value/ .  This proposal is talking about, for example transaction/transaction-date - see http://iatistandard.org/201/activity-standard/iati-activities/iati-activity/transaction/transaction-date/

     

    I agree that xs:duration will not help with open-ended activities.  However I disagree that an end date of 2020 is more realistic, or accurate, than something like 3000. Even with a corresponding free-text explaining that 2020 is the end of the organisations current strategic period this would not stop any data aggregation, visualisations etc. interpreting the value incorrectly.  For NGOs sustainability is a huge area of concern so you can appreciate there is a huge difference (for example in planning) between broadcasting that an activity that is planned to end in 2020 (or even that it is only planned until 2020) vs. an activity that is not planned to end.

     

    Instead, a related attribute that indicates there is no anticipated end date is one option that could be useful here, but we need to make sure that whatever approach is suggested is in keeping with the IATI standard and future direction as a whole - does anyone have any other suggestions? 

  • 0
    Avatar
    Rolf Kleef

    I forgot to add one more remark: I think that if you truly don't have some sort of end date, then perhaps what you represent is not an "activity", and you probably don't have a budget for it either; or target results.

    Perhaps then you need to look for "sub activities" that are time-bound, with a budget, with probably a workplan (e.g. for a year).

    IATI doesn't really work for ongoing operations (should probably be in the organisation file), and I'm not sure how suitable the data would be to facilitate cooperation and coordination.

    I think it's important in using the data to stress that, by its very nature, IATI data is incomplete and subject to change. It's an approximation of what is planned, committed and achieved. The standard focuses on forward-looking, up-to-date data to increase aid effectiveness, and is not intended for full organisational accountability.

     

    Re: value-date - the problem here is that if you use the actual date of the transaction, you're not concealing anything; and for very volatile currencies, using the end date of the quarter may lead to very different amounts (which also could be acceptable given the approximate nature of the data...)

  • 0
    Avatar
    IATI Tech Team

    This proposal has again been discussed amongst the IATI Technical Team.  We appreciate the efforts gone into the discussions, although - at this stage - we feel that introduction of this proposal will add complexity and confusion to data usage.  As such, we do not plan to include this proposal as part of the version 2.02 upgrade of the standard, however we are keen to hear further use cases to inform proposals for future upgrades.

  • 0
    Avatar
    Mike Smith

    Understood that there is still significant think through required here, It would be great to keep this proposal open and gather more use cases, please do not archive the thread so that we do not loose continuity (it stems from the archived proposal "Add xs:duration attribute to certain dates” Oct 2013 for further reading).

    Re: activity vs. sub-activity - agreed.  However, in some cases it makes sense to also include the activity where e.g. budgets, work plans, targets, results etc. are available and helps to improve the clarity of tracing the funds and informs decision makers - the standard half supports this through hierarchical reporting but aspects like the inability to indicate sustained projects, I think is an omission and it would be great to build our understanding if and how this might be included in IATI.
    While I agree that while IATI data is incomplete, subject to change and not for full organisational accountability this should not be used as an excuse to provide potentially mis-leading information.  I suggest that if we truly wish IATI to be used to inform planning (which it is starting to be in numerous places), mis-informing decision makers with incorrect information (by, for example, indicating that funding will stop after 2020 - which is what end-date is often interpreted as) can, in my view, have the potential to do more harm than good.  I would like to see a publishing standard that supports the long term sustainability agenda.
    re: currency conversion date - agreed, its very difficult to remove inaccuracy where currency conversion comes into play - given the fact that aggregations are used one has to pick a representative date (through value-date) and value ( for example rebasing etc. as appropriate). 
  • 0
    Avatar
    IATI Tech Team

    This proposal has been moved to the 'Modifications, Additions, Improvements' forum, as a candidate for inclusion within the next upgrade process.

Article is closed for comments.