[OpenSpending] Follow-up to transaction standard call

Tue Oct 23 08:10:09 UTC 2012

Hey all,

I don't think there is any disagreement that both contractual and
transaction-level information are valuable and need to be published.

It's important to see that this dicusssion about a transactional
spending standard does not stand isolated, but it needs to connect to
the debate about standards for the release of contractual data (see
http://www.open-contracting.org/). The question of what has priority -
transactions or contracts - can probably only be answered in
connection with another question: What for? We all have different
goals in using this data, often based on the differences between the
countries in which we operate.

The best thing we can accomplish is to generate a language that finds
a fair compromise between reflecting the eccentricities of many
governments, while not getting lost in the details of each. If what we
design ends up being the perfect sum of all ways in which people
record transactional data it will be completely worthless, because it
will be unusable. So we need to break it down and simplify in a few
places.

That said, I'm very keen to see more samples of the data that
governments are releasing. We can use this to have further evidence of
what they can (and need to) publish.

In the end, I hope that what we come up with will be something useful.
Useful for government so they have concrete guidance on how to publish
data. Useful for techies like me, who can build tooling. Useful for
analysts who want to reconstruct flows of funds within government.
(Still, we should not mix up the analysis with the standard, it
enables analysis but should not require it.)

Cheers,

 - Friedrich

On Mon, Oct 22, 2012 at 4:36 PM, James McKinney <james at opennorth.ca> wrote:
> Thanks for the clarifications! I just have a few more anecdotes to share.
>
>
>>> Cost overruns are easy to see even at a high-level. Governments regularly spend more than they budget. There's certainly interest in determining where those cost overruns are at a lower-level, but I don't see the need to go to the lowest level. Same for non-performance.
>>
>> I am assuming that the lowest level is easier to obtain than a more processed form. Maybe that's not true?
>
> Reporting differs between institutions. In Canada, for example, one institution may report its planned and actual spending per program activity. Others may not provide that much detail. In many jurisdictions, reporting is standardized, and if the standard requires a certain level of precision, then that processed form would certainly be easier to obtain.
>
>
>>>> I can see that contract-level data would also add lots of new useful information about the purpose of the transactions. I don't think either of transaction-level data and contract-level data really replaces the other.
>>>>
>>>> Bulk of data is not in itself an insurmountable problem. We have computers and dedicated people. Given ledger-level transaction data the task of reducing it is manageable, provided the books balance. However, if you get a dumbed-down version of the data that has been processed and reduced and summarised so that it no longer balances, then you don't really have anything at all.
>>>
>>> Insurmountability is a very low bar :) I would not underestimate the time it takes to properly model an accounting system, so that it's possible to ask of it the sorts of questions that are interesting.
>>>
>>> Anyway, I'm not against transparency at the transaction level. I'm just curious to figure out if the common use cases and requirements can be satisfied without going that far, because I think going for the transaction level will be a lot harder, both in terms of getting the data and in terms of using it.
>>
>> Well then, maybe it's a question of finding the appropriate ambition! Quick fix or long-term solution? Easy for me to say when I am not the one doing the work, I suppose.
>
> I think it's possible to incrementally build a long-term solution. Today's "quick fix" could inform, or be a part of, tomorrow's longer-term solution.
>
>
> _______________________________________________
> openspending mailing list
> openspending at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openspending