Data standard for budgets – Fiscal Data Package

Data standard for budgets – Fiscal Data Package

New to data standards? Please read these introductions.

About Fiscal Data Package

“Fiscal Data Package is an open specification for quantitative fiscal data, especially data generated during the planning and execution of budgets. It supports both data on expenditures and revenues, and also supports publishing both highly aggregated and highly granular data, for example individual transactions.”

The official introduction sums up the specification quite comprehensively. To give a few examples, it can be used to represent a national budget, the spending of a civil society organization, as well personal expenditures in a wallet management application.

Who uses Fiscal Data Package? Where to find compatible data?

The power of the standard comes from the power of all the stakeholders using it. So, who uses Fiscal Data Package?

Open Spending Next created by Open Knowledge International is an open catalogue of fiscal datasets to which anyone can contribute data and visualize them online. For now, it is the only website using Fiscal Data Package and it is still in the alpha stage of development, it will eventually serve people around the world. A previous version of Open Spending, which remains the main product, has gathered 1,105 datasets from 76 countries.

As part of the TransparenCEE project, we plan to use this specification to open the budgets of six self-governing Georgian municipalities – stay tuned for the data.

As for the other specifications, the International Aid Transparency Initiative (IATI), whose mission is to make “information about aid spending easier to access, use and understand,” has published a data standard that also supports budgetsand transactions.

How to open up the data?

The Fiscal Data Package approach to data standardization is different than that of most standards. Rather than implying a rigid data structure, it allows the use of any tabular data (eventually converted to csv format) and documents it by adding semantics (meaning) to the data columns.

For example, with a tabular data file like the one below:

+——–+——+————+————+
| Amount | Year | Department |    Type    |
+——–+——+————+————+
| 1500   | 2014 | Education  |   Revenue  |
+——–+——+————+————+
| ….
+—–

Data Package specifies types of data in the columns (Amount is floating point number, Year is date, Department and Spend Type are strings), and their meaning (ie. Year is fiscal year, Amount is in US dollars, Department is a procurerand Type is so called budget direction).

In the end, the whole Fiscal Data Package in the example consists of two files – data.csv and datapackage.json. That’s the minimal form for each data package.

In terms of practical opening, there are several resources to utilize. The standard specification will inform developers working on data export or conversion from other sources. Being quite technical in nature, it isn’t the easiest point to start with, even for developers. Happily, Open Spending Next offers a tool called Packager that guides the user through documenting his/her dataset as a Data Package. I recommend using Packager as a starting point and then enhancing the generated datapackage.json using the formal specification.

P.S. Keep in mind that this specification is built on top of Tabular Data Package, which is built on top of Data Package, so as a developer you will need to dive into all three of them to have the full specification.

How to contribute to the standard?

Fiscal Data Package is being developed as a part of the Frictionless Data initiative (former Data Protocols) by Open Knowledge International. It directly supports the Open Spending Next platform, which is still its only implementation  in a running product.

Nevertheless, Fiscal Data Package is an open specification. It is licensed under Creative Commons and the development is led in the open on Github by Open Knowledge International in collaboration with the World Bank and GIFT (Global Initiative on Fiscal Transparency).

Suggestions and questions about the standard should be reported as Github issues. The contributing guide presents the formal process for discussing and incorporating any contributions.

Acknowledgements

I would like to thank Dan Fowler from Open Knowledge International for his feedback on the article’s draft.