Supporting assets and liabilities (needed for OpenEconomy.org.au)


#1

Hi all. I’m here as part of a revamp of openeconomy.org.au in which I propose to replace the existing backend with OpenSpending (the next generation). OpenEconomy is slightly different from other OS-style projects in that it’s not really a transparency project driven by budgetary organisations, but a “tool for winning arguments” that lets you compare different organisations (and parts of their finances) against each other.

It’s also somewhat unique in that it covers the spread of revenues/expenses/assets/liabilities, and has a certain visualisation style that lets you visually characterise an organisation (eg, high debt but high revenues, or balanced revenues/expenses etc).

Anyway, in order to use OS as the backend, obviously OS would have to support assets and liabilities in the data model. Rufus and Paul have given their cautious support to this idea but want more details, and sample data.

I’ve uploaded all the sample data here: https://github.com/stevage/openeconomydata/tree/master/hjson

My general plan of attack from here would be:

  1. Work out how to represent assets/liabilities in OpenSpending Data Package
  2. Convert existing data to that format
  3. Build datavis and site around that format (well, a colleague will be doing this)
  4. Temporarily store that data in Github if OS Next isn’t ready
  5. When OS data store and API is ready, switch over to using that, moving the data there and hooking into its API
  6. Explore how the worlds of OE and OS can mesh more deeply - ie, can our new vis be useful to other communities, and can the existing data be useful for comparisons etc within OE.

But right now, let’s talk about 1.

  • Has this been discussed before?
  • Are there any big blockers to doing it?
  • What would need to change in the data model?
  • Does anyone else want this?
  • Any objections?

etc.


#2

Hi @stevage

It looks like this has been raised before. I dug up this, and perhaps @trickvi can shed some light on this.

At a conceptual level:

“assets” and “liabilities” should be able to be represented as new types just like “expenditure” and “revenues”, as far as OpenSpending Data Package goes. Currently, expenditure and revenue are declared on the “direction” property (http://labs.openspending.org/osep/osep-04.html#top-level-descriptor). Perhaps that should be renamed back to “type” as per Budget Data Package, and add two new types: “assets” and “liabilities”.

The rest of the package could be exactly the same as far as I see now. The difference would be when/how asset/liability data is loaded into some database for aggregate queries, with particular treatment over temporal dimensions?

So, I don’t see any significant blockers - it is clearly a new type of data, and therefore needs to be treated as such in derived databases/data representations.

Very keen for some further input on this from @rufuspollock @trickvi and @pudo, along with anyone else who has some insight on the issue.


Open Spending Data Structure: Ideas and Suggestions
#3

First off, Steve: I really enjoyed your presentation on the call the other day, OpenEconomy is really exciting!

On the question of how to support balance sheet style info, I can’t really comment on OSDP very deeply. I agree with the analogy to revenue/expenditure that @pwalsh is making. I’m surprised to see, however, that OSDP models that as a dataset level metadata field, when in many budgets it seems to be a line item distinction (ie. each entry specifies whether it is an expenditure or a revenue item). That would seem the easiest way to model assets and liabilities as well, as has been done with the IBRD balance sheet here:

https://finances.worldbank.org/Accounting-and-Control/IBRD-Balance-Sheet-FY2013/cryz-p8hk

Depending on what API is then made available, this can be used to slice and drilldown the data accordingly.

The larger question raised by this, for me, is still to come up with a nice place to collect and structure the taxonomy of dimension types with regards to fiscal datasets like these. Right now this is partially in BDP, in OSDP and tacit - it would be great just to have a code list somewhere.


#4

@pudo I get you. I see “type” as a per line thing too. I also realised this issue this a while back in relation to BDP here. OSDP, by inheriting this from BDP, currently expects “type” conformity in a set. We should discuss that here though, and leave this thread to specific discussion of assets and liabilities :). [LINK]