Yes, this is definitely an improvement. It is indicator values which can be aggregated or not. Not results.
Agree with Herman – these seem like good fixes.
Is adding @iso-date to baseline done with a view to potentially removing @year in the next integer upgrade? If so, would it be possible to also add something to the guidelines discouraging the use of baseline/@year?
I don’t think adding the attribute to the indicator solves it. Aggregation should be defined with respect to dimensions, not to facts.
- Can I aggregate the numbers across periods?
- Can I aggregate the numbers across activities?
- Can I aggregate the numbers across organisations?
- Can I aggregate the numbers across countries or locations?
There also should be documentation about what we mean with @aggregation-status="true". Aggregation is possible across all dimension for the indicator within a single publisher? (So not across organisations.)
You can say:
<result aggregation-status="true">(result A)<indicator 1></result>
<result aggregation-status="false">(result A)<indicator 2></result>
So basically it is already possible to separate indicators that can be aggregated from those that cannot. I agree this is not elegant, but more a matter of documentation and guidance at this point.
I’m also not sure about adding a single date: that seems to make sense when the baseline is more a “point in time” rather than a “year in time” or “some point in a year”.
It depends on the indicator as well: for output indicators, it seems more appropriate to add a period to the baseline?
If we want to achieve consistency between baseline and periods, we should go all the way.
Perhaps an easier way is to add a @baseline boolean flag to <period> to indicate it represents a baseline? It would only be expected to have an <actual>. With period-start and period-end the same, it offers the equivalent of the iso-date.
And to propose some syntactic sugar-type solutions: we could introduce shorthand notations in version 2.03 or 3.01:
<baseline year="2012" value="10">
<comment>
<narrative>Baseline comment text</narrative>
</comment>
</baseline>
as equivalent to:
<period baseline="true">
<period-start iso-date="2012-01-01" />
<period-end iso-date="2012-12-31" />
<actual value="10">
<comment>
<narrative>Baseline comment text</narrative>
</comment>
</actual>
</period>
and likewise:
<baseline iso-date="2012-06-02" value="10"/>
as
<period baseline="true">
<period-start iso-date="2012-06-02" />
<period-end iso-date="2012-06-02" />
<actual value="10"/>
</period>Agree with the suggestion from @rolfkleef to add a boolean attribute to <period> rather than extending the baseline element through replication of the majority of period (this isn’t very DRY).
As such, a proposal in place of (2) in the post by @mikesmith would be:
- Add an optional boolean
iati-activities/iati-activity/result/indicator/period/@baseline - Deprecate use of
iati-activities/iati-activity/result/indicator/baselineplus its attributes and sub-element (remove element at integer) - Add Rules:
- If
iati-activities/iati-activity/result/indicator/period/@baselineis present for a given indicator,iati-activities/iati-activity/result/indicator/baselinemust not be present for that indicator (remove rule at integer) - If
iati-activities/iati-activity/result/indicator/period/@baselineistrueor1for a given indicator,iati-activities/iati-activity/result/indicator/period/actualmust be present
- If
This topic has been included for consideration in the formal 2.03 proposal depending on further clarification relating to how baselines are handled
I think this thread is falling between discussion on M&E best practice and logical elegance.
When the results element was designed the assumption was explicitly made that each indicator (or disaggregations within the indicator) can only have one baseline value which is established at the outset of the activity. For this reason the baseline element was deliberately kept outside of the period element (which allows for targets and actuals to be reported on a period-by-period basis).
Can M&E experts comment on this?
Hi @bill_anderson, thanks for this, yes there will only ever be one set of baseline data (set, meaning that actual “baseline” element in IATI would be repeated once for each disaggregation, but all referring to the same baseline set) for an indicator (note sometimes people refer to mid-lines and end-lines but think of these more as reviews, sometimes where new indicators are introduced and old retired). Sometimes you take a baseline over a period of time (number of water shortages during last year’s drought) and we were thinking this would be recorded in the comment, but I can see how the period functionality could be useful here (unless anyone can see drawbacks?).
In terms of following DRY principles and logical elegance, you could extend the aforementioned iati-activities/iati-activity/result/indicator/period/@baseline to use a codelist (maybe called Indicator Value Type) that can be one of baseline, target and actual - then you only need one set of locations, dimensions, comments in the schema for all three constructs (baseline, target and actual) thereby creating opportunity to simplify the current Results elements at integer update. It would be helpful to make guidelines to indicate that there should only ever be one set of baselines. Happy with either approaches as both achieve the same M&E requirement.
I agree with the idea of using a code to distinguish between baseline, target and actual. A baseline is just a measurement that has been chosen as a reference point for other measurements, it is not inherently different from other types - I don’t think it should be treated any differently. This has practical benefits in that it simplifies the schema considerably without loss of any capability.
My understanding of where we have got to is …
The ideal solution is:
- We deprecate the
<baseline>,<target>and<actual>elements - We add a new complex element (called
<measurement>??) which inherits the existingtarget/actualcontent. - We add an attribute (called
measurement\@measurementtype??) which has values baseline, target, actual
But …
The baseline element is currently used by 117 publishers in over 150,000 activities so we are in integer terrain. Given that the next integer is most likely a few years away there are a couple of options that could be possibly be considered
- We could implement the changes now if we could provided data users with a utility that converted data in deprecated elements into the new format.
- We could implement an extension for the new format now that could be used in addition to the existing elements. (The integer upgrade would then merely move the extension into the main schema.)
A temporary @baseline attribute (implemented now in anticipation of the bigger integer change) would require users to look in two places for baseline data so I’m not convinced that it is a viable option.
Thoughts?
I would support the extension. It would not be enough to provide a conversion utility because existing publishers would need to change their software at very short notice to write to the new structure or to run the utility. If they have a few years’ notice they should be able to factor the integer upgrade changes into their road maps.
@bill_anderson I completely agree with you. This is not viable. The extension proposal would be detrimental for ease of data-use and data-quality.
I think that is exactly what it is.
I really think the results area needs more insights from experience - thus time - to facilitate a proper redesign. Looking at the organisations currently using the baseline element, the majority seem to publish in accordance with the Dutch publication guidelines, hence experiences will still be ‘fresh’.
I think IATI would benefit from a proper Results Working group, which was announced at the TAG, but doesn’t seem to have materialized yet. I’d be more than happy to participate.
I think we are heading towards a position where any change to existing elements is untenable.
Which leaves us with the original proposal: to make the <baseline> sub-elements consistent with <target> and <actual>.
Can we reach consensus on that?
1 Like
Hi @bill_anderson, you beat me to it! Yes there’s still the original suggestion (potentially using a start and end data, unless anyone see’s drawbacks), which, as mentioned would also satisfy M&E folks, but as @hayfield points out is not DRY. I don’t think that logical elegance (DRY) is a reason not to make up for a shortfall in the standard that M&E folks have identified and asked to change (especially given its about consistency of the standard).
1 Like
I agree with @bill_anderson to make the <baseline> sub-elements consistent with <target> and <actual>.
We will also need further discussion leading up to a potential <results> redesign for a future integer update.
@pelleaardema you mentioned a TAG Results Working Group. Would someone like to volunteer to co-ordinate that? That group will need time to come up with a set of proposals that can meet consensus across a range of M&E people.
1 Like
Sounds like the most feasible solution to me.
1 Like
@bill_anderson Sounds like the most feasible solution to me
@JohnAdams I know that names were collected during the TAG. @SJohns and @rbesseling may have those? I would be happy to contribute.
Agree, maybe not perfect but more consistent than it is right now.
1 Like
Yes there’s still the original suggestion (potentially using a start and end data, unless anyone see’s drawbacks)
I agree – in order to be consistent, the original proposal would need to be amended to include <period-start> and <period-end> (or similar) data. Also, “Add iso-date attribute” (2c) should be removed.
This proposal has been been included in the 2.03 upgrade. It can be viewed in the following two Discuss posts: