in order to model correctly the data in Exiobase (and not only there)
we have investigated our current model of representing flows and quantity of flows.
Following is a (toy) example:
The Exiobase supply table represents a flow of `1000Euros` of `Cars` as `output` of activity `A1`
Yet, some other extension table will tell us that the flow above "at the same time" corresponds to some `200Kg` of Steel that is still `output` of activity `A1` (although in some processed form)
Hence, 100Euros and 200Kg are different way to "measure" the very same flow.
The current name of this is "balanceable property".
In the first case we are representing the "currency" balanceable property of the flow of cars,
in the second the "dry mass of Steel" balanceable property .
We do not want to miss the link between these two instances and they are effectively properties of the same flow.
Hence the following model (in the attached picture).
The triple statements (in natural language) following this new model will be:
Flow1 output of A1
A1 has activity type "Car production"
Flow1 has object "Car"
Flow1 has balanceable property P1
P1 has type "currency"
P1 has numeric value "1000"
P1 has unit "Euros"
Flow1 has balanceable property P2
P2 has type "dry mass of Steel"
P2 has numeric value "200"
P2 has unit "Kg"
Please let us know if you have comments and/or questions.
@Bo, please correct me if I'm wrong
@Chris, shoot your questions, I know you have them :)
A suggestion: if you understand what we are trying to do, at this stage refrain from discussing the actual name "balanceable property" (it might or might not be ugly)
and first see if there are problems with the modeling itself, naming comes as second step.
Department of Computer Science
The Aalborg BONSAI contingent and visitors are running a mini-hack-a-thon Jan. 20 & 21 to make progress on finalizing the Exiobase import into the BONSAI ontology. During this time, we have prepared
Trade data and model
Trade data will be imported from the use table. In the initial import, we just take the data as it is - aggregation and cleaning steps will happen afterwards.
Every trade data point will have a unique activity, with the type "Export," and with a single edge to a flow. This is in contrast with so-called normal activities, which can have many input and output edges to flows. As a reminder, activities are resolved in
time and space, but flow objects are not, and flows are not explicitly (though you can infer their temporal and spatial context by their linked activity/ies).
Environmental and other extensions
Exiobase has a number of extensions. Some are easy, but others pose modelling or data architecture challenges.
The easy ones: Emissions, resource use, land use, crop residues
Each "thing," such as CO2, is a single new flow object. We store this using the standard flow object / flow / activity approach, and the activity is the activity that produces or consumes the flow.
There is a small exception for emissions, which are also provided in a separate worksheet listing avoided emissions due to the use of manure. This is essentially information used already by the manure treatment activity to calculate its net emissions - a flavor
of consequential LCA, if you will. For our purposes, this information is not needing and won't be used.
There is also a question for what Exiobase calls "emissions of activities from unregistered waste." Currently, we plan to skip this, but are investigating whether these values are ever significant (compared to "normal" emissions from the activities).
The hard one: waste / materials
Exiobase has 19 materials (measured in mass), such as wood, textiles, glass, and steel. These can give data on waste production, but also on the material composition of packaging and products. There are multiple worksheets, and they need to be handled separately.
Supply and use of waste
This is the simple case. Each waste material is a flow object (regardless of production or consumption), linked as any other industrial import or export.
Take the case of production of canned vegetables. Exiobase will give the mass of the produced vegetables, but the mass of the can is given separately in the packaging worksheets, both as a production (linked to the producing activity), and as a consumption
(for the consuming activity, such as final demand). When the packaging material is disposed of by the consuming activity, its mass is already included in the total waste figures.
We will give the production or consumption of packaging material as a separate flow & flow object, and provide documentation and examples on how to correctly query for and use the activities that have these linked multiple products.
Supply and use of materials in heterogenous products by activities
In Exiobase, automobile manufacturing is denoted in euros. It is useful to know about the material composition of these cars, however, and Exiobase gives these material compositions (e.g. kg steel per euro) in the above strange title.
This case is tricky, as it is not a case of flow & flow object, but is rather a property of the already existing automobile flow. This is the first time we have to use the ontology section "balancable
property" with real data, and it has exposed some elements that we could improve. The relevant people are looking into this.
Supply of materials accumulated at the end of the period, and supply of waste from materials accumulated previously in the society
Exiobase (and, you know, the world) has the concept of stocks: buildings, warehouses, your aunt's toy closet. In a given year, products can enter into stocks, or be removed from stocks. Exiobase gives these stock additions in two perspectives: the product perspective,
with normal Exiobase products (in the supply table), and the material composition perspective. The sums of both perspectives should be identical. The above categories list the composition of things either entering the stock pool and staying there are the Exiobase
representative year, or things that were added to stock beforehand and turned into waste during the Exiobase representative year.
I have written this up to the best of my understanding, but certainly there are some technical errors or places where clarification will be needed. We will be documenting this work, and the BONSAI ontology in general, with easier manuals and examples before
the next hackathon.