This is a thread for discussing OpenSpending Data Package structure which is the subject of OSEP 4 - OpenSpending Data Package
The current rough proposal looks like:
{
name: …
# other budget data package / OS metadata [tbc]
title: …
license: “ODC-PDDL-1.0”
currency: … (?)
maintainer:
openspending: {
mapping: {
amount: "spending" # this is interpreted as fieldname on first resource. if multiple resources then should be array of strings: [ "resource-name/field-name", ... ]
id: "id"
# recommend but optional …
payer:
payerId:
payee:
payeeId:
}
},
resources: [
{
name:
title:
schema: [
{
name:”id”,
primaryKey: true,
title: # must be present (?)
description: # warn if not present - would really like it there
type:
}
...
]
}
...
}
Considerations and design principles:
- OpenSpending data packages should allow for both denormed and normalized data. Normalized data means where the expenditure information is separated from e.g. the entities spending or received money (with a FK relation between the spend “table” and the “entity” table). Denormed is where that is all in one table.
- A given OpenSpending data package should only contain spend data “once”. I.e. we should not include both “actuals” and “planned” versions of the same expenditure in one data package: instead separate these into two data packages
- Why? We need to enumerate some simplifying principles in OpenSpending and there are two here. One principle is that aggregating expenditure in a given data package should make sense. If we have the same expenditure in different versions then aggregating leads to double counting. Second principle is that data from a single data package should map to a single “fact” or “measure” table in an idealized OLAP destination table. Again if we have different versions of the same expenditure we should really map them to two tables.
- Comparing different versions of expenditure is a common and extremely important functionality. In the case of budgeted (planned) and actuals (or different versions of a planned budget) it is comparing the same budget line between planned and actual. We also want to compare between countries: for example spending on defence in one country vs another (or spending on the same cofog codes). This is a really important feature and one that OpenSpending will support. Exactly how OS will do that does not need discussion here, but what we can emphasize is that being able to perform these kinds of comparisons does not require data being in the same data package: comparison will be possible across data packages. This is important as it means there is no conflict with the principles enumerated in the previous bullet point (if we did need data we wanted to compare to be in the same data package we would have a conflict with the no duplication principle).
Other Links
- OpenSpending Mapping Model Example in Spreadsheet
- Diagram OS Mapping Source to Idealized Model
- Diagram Use Case of Open Spending Data: How to structure a data package?
Mapping Source Data to OS Internal Model
