[wdmmg-discuss] Fwd: Where Does My Money Go Epiphany

Fri Jan 22 21:47:33 UTC 2010

2010/1/22 Richard Pope <richard at memespring.co.uk>:
> Hello,
>
> Rufus asked me to forward this, so I am :)

And to keep everyone in the loop, here was my response :)

---------- Forwarded message ----------
From: Rufus Pollock <rufus.pollock at okfn.org>
Date: 2010/1/15
Subject: Re: Where Does My Money Go Epiphany

Dear Richard (and everyone else!),

Sorry for slight delay in reply -- very hectic yesterday. These are
really interesting ideas. Comments inlined below.

By the way we have set up a dedicated wdmmg-discuss list here:
<http://lists.okfn.org/mailman/listinfo/wdmmg-discuss> May I forward
this email to that list? You may also want to join :)

Jonathan also posted up an update on WDMMG activities yesterday
evening: <http://blog.okfn.org/2010/01/14/planning-sessions-for-where-does-my-money-go/>

2010/1/13 Richard Pope <richard at memespring.co.uk>:
> Hi Rufus,

[...]

> It seems like the model for mapping money flows, certainly the common
> cases anyway, is fairly simple:

My first stab at this (the link to which I send to Julian b4
christmas) was here:

<http://lists.okfn.org/pipermail/okfn-help/2009-October/000361.html>

We've started aggregating thoughts about the Store here on the wiki:

<http://wiki.okfn.org/p/Where_Does_My_Money_Go/Store>

In there is a summary of the "domain model" for double-entry book-keeping.

> - Parties have a name, address, type etc

Inspired by accounting terminology we called these "Accounts"

> - Money moves between Parties (any individual or org involved) in the
> form of Transactions

Same name :)

> - Transactions have a Date, Amount, Aim (contract/programe) and Type
>
> (capitalisation denotes objects)

One big extra thing we probably want here is:
 * Good "Source" info - i.e. links back to where the information came from
 * The ability to create what I'm currently calling "data/transaction layers"

I should explain this second item a bit more as it is important.
Basically an important feature of any accounting system (and any
analysis of income or expenditure) is that we don't count things twice
and that we account everything (i.e. the accounts reconcile). The
issue for us is that we are going to be getting data from a diverse
bunch of places and it is very likely that the same money is being
listed in two different places. However within given sets of data we
may know that it is "reconciled" -- for example we know this with the
PESA data because the govt are guaranteeing it.

This is an important fact to record about a particular set of
transactions in the system and there we could list these as a
"data/transaction layer". (You might think we could reduce the data
layer to sources by just associating everything we get from PESA with
the Source PESA. However, we may be creating our own "reconciled"
transaction layers with data from a diverse set of sources ...)

> It seems that the data we have is patches of patchiness (farm
> subsidies/MP expenses/government programmes/aid payments), we are
> never going to get everything we want and even the stuff that does
> exist is not going to be *everything* that exists.

Absolutely: we want a system that can flexibly handle both very patchy
and very complete/coherent data.

> The epiphany is that this is a very similar set of circumstances that
> the Open Street Map people found themselves in. So rather than going
> after existing sources in chunks, should we instead be building
> something along the lines of the Open Street Map platform and building
> someothing for storing am amassing anything we can get our hands on?
> It would work something like this:

I quite agree. In the discussion I had with Julian before Christmas we
had quite a lot of discussion of sourcing very low level data.

> - A data structure that represent the basic types listed above
> (intentionally ignoring the edge cases that people cite to block
> things)
> - A tool fo uploading data to this format with citations as to the
> source of data
> - Moderation tools for checking the validity of data and resolving
> contradictions and merging duplicates
> - A fuzzy way of marking Transactions for reliability

This sounds really sensible and close to what I'd been imagining (and
when great minds think alike ;) ...). In terms of actually concrete
steps I'd imagine starting with getting the core domain model sorted
out and leave the "crowd-sourcing" utilities (versioning, moderation,
reliability metrics) to the next stage -- =they are probably quite
hard to do well!

> Does this make any sense? Or am I missing the point? Either way i do

I think this makes a lot of sense.

> think it would be worth emailing Steve Coast from OSm and asking if he
> thinks there are overlaps in the approach.

Definitely could be worth doing. I think the overlap here is going to
be at the conceptual and not the "code" level but may definitely be
worth talking to the architects of the OSM backend.

Rufus
--
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/