Core Database

This page describes the principles for the core database.

---

Core database

The core database can be described as an RDF triplestore, containing data (numbers, units and uncertainty) on the flow of flow-objects between activities. Activities, flow-objects and flows can have properties.

This implies that each datapoint is defined in terms of its flow-property, its flow-object and its activity. Furthermore, the data on each flow can depend on the time and location, and for flows occurring in the future, also on the macro-economic scenario (to distinguish between data belonging to different future scenarios).

Summarising, there are six necessary dimensions or identifiers for each datapoint (beyond versioning) are Activity, Flow-object, Flow-property, Time, Location, and Macro-economic scenario.

Furthermore, metadata/attributes can be assigned to each identifier/dimension and each datapoint (e.g. author and provenance, and text descriptions, or standardised metadata as defined e.g. in the ecospold format).

Each temporal (annual) instance of the core data (flow-properties, flow-objects and activities) of BONSAI can be understood as a Supply Use Table (SUT): a matrix of flows of flow-objects into and out of activities. Traditionally, the flow-objects in a SUT are limited to products and the flow property limited to monetary value, but in BONSAI the objects may also be environmental, i.e. without economic value, and the flow-properties may be physical (in units of mass (dry, wet, water, or elemental), energy, or person-time). A SUT represents data for individual activities before any linking or other data manipulation. This represents the raw starting point for product system algorithms that fill data gaps and link the data for individual activities into product systems, as represented by a Direct Requirements Table.

Multiple, competing observations for each datapoint are be allowed for the raw data, distinguished by their provenance. The different steps in the production (from raw data --> SUT --> Direct Requirements Table --> Leontief inverse --> Product footprints) will be stored in separate databases. Separate versions of each step may also be stored as separate databases, reflecting, e.g., alternative algorithms for data reconciliation and gap-filling for the creation of SUTs, alternative algorithms for producing Direct Requirements Tables, and alternative resulting product footprints. For such multiple database instances, one must be agreed as default by the BONSAI community. Relevant parts of the RDF databases may be converted to other database formats when speed of search and calculation makes this desirable.

The task of establishing the core database is described on the wiki page Data Storage. Based on the core database described here an ontology and RDF framework was developed.

The Task corresponding to making the core database ready for integrating data of different origins is described on the wiki page Data Integration.