boweidema
commented
4 years ago Using the diagonal of the supply table to pick up the determining product is only relevant for square supply tables. To force the supply table to be square for that purpose does not make sense. For all other data sources, the information on what product is determining will anyway be stored separately, so using a separate list [activity; flow-object] for this seems a reasonable solution. The non-square elements in exiobase are not present in the original data provided by the national statistical offices, but is an artefact introduced when creating Exiobase, so I see no problem in aggregating these data in this particular case. Since the original data are still available, you are not loosing data as such, for anyone that might want to use the original data.
agneta20
kuzeko
We were facing a challenge in detecting the determining product flow as theoretically these could be picked up from diagnol of the Supply tables. However, given that Exiobase is non- square i.e. 200 pdts x 164 activities, it is not that trivial to identify the determining flow directly.
Hence we have the following solution:
We use a separate basic correspondence vector of determining products and the activities that helps us translate the information correctly into RDF
Another method could be to square the Supply and Use tables before converting them to RDF. This was already done in the Mojo repository . Here the product flows are aggregated and the exclusive by-products are placed in a global market. This is useful to build the computational structure (A/Z matrix) but aggregating product flows also leads to loss of information.
Would like feedback