Result type codelist is too limited, especially because it contains indicators that may have nothing to do with Output / Outcome / Impact (or not correspond to what different organizations define as such :) )
Suggestion : Add "other" or "undefined" to Result type codelist
Have more questions? Submit a request
-
Mark Brough Propose that the Result Type codelist is expanded to add additional types (that the community may suggest useful during the consultation period), rather than an "undefined" type which may become more difficult to use.
-
David Carpenter We don't actually see that having an 'other' option is unreasonable. We can see that having more meaningful options is better, and we can see that 'other' is not necessarily all that useful!
We think it is an easy option to add it, and we can monitor it's usage, which is why we propose going forward with it.
-
Tom Zeppenfeldt Expanding the code list would definitely help. But there is a bigger issue, being that the concepts of impact, outcome and output aren't characteristics of the data that is stored as indicator values. They are characteristics of the intended use of the data. As such what is "ouptut" to project X is "impact" to project Y. The same applies to concepts as "baseline": An endpoint of an activity can provide a baseline for the next. So, eventually the ultimate solution would be to allow to define a number of "results" , inside of which a number of "datapoints" could be stored that hold references to variable, location, period, modus ( planned,measured,estimated, ...) . We have been experimenting with this in our Ordex project (now working on a linked open data version).
-
Tom Zeppenfeldt Hi Mark,
As promised at the opendevelopmentcamp 2013 in Amsterdam I have elaborated an annotated example of how the content of the <results> element . it is available at
http://www.ophileon.com/odc13/IATIResultsStructure.xml
and a supporting pic at
Article is closed for comments.
4 Comments