(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.
Mike I don't think this is a good idea for a number of reasons
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
Apologies Mike. I've clearly not read your suggestion properly. Will review again.
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.
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
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:
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 :-)
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?
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...)
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.
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).
This proposal has been moved to the 'Modifications, Additions, Improvements' forum, as a candidate for inclusion within the next upgrade process.