Dear all- I would like to invite Wes Ingwersen to present the work that the US EPA is doing on open data infrastructure and associated efforts to the BONSAI group. We have had a "hang out" on Friday

Hello at All, My Name is Matthias Dollfuss (27), I’m from Austria studying Eco-Design (Ecological Product-Development) at the University of Applied Science in Wieselburg. Before studying

Hi, please see my answer below. SM: Yes, transports, insurance, etc. linked to imports are just accounted separately as normal inputs, but non necessarily in the national data.

>>>The trade data appear as imports in the Exiobase use table. Note that this is different from the way it appears in national supply-use tables. I am the only one who got lost? The trade data

Den 2019-11-08 kl. 10.59 skrev Chris Mutel: International trade activities, i.e. activities that move use of an export to become an import supply, do need to be FlowObject specific. Each such trade

Hi Chris, trade data is only in the USE tables. The SUPPLY tables just show the production of activities and the location of the outputs is the same of the activities which produce them.

Thanks Bo, this is clear and (at least in my opinion) completely consistent with all group decisions. Maybe I just missed it - entirely possible! - but the issue discussions did not seem to have this

Hi all, I am not in the position of taking sides. I just want to provide one clarification here. Both options (keep the data as is in Exiobase, or re-aggregate) are compatible with the ontology. I

Dear Chris, The issue is not about interpreting or deleting data, but simply to make the import of it consistent with our ontology. The Exiobase SUT data includes two kinds of data 1)

Please see https://github.com/BONSAMURAIS/EXIOBASE-conversion-software/issues/5, and add your input (or reply to this email). -- ############################ Chris Mutel Technology Assessment Group,

Sorry, I don't want to be a pain in the ass, but I think we are going a bit down the raod of Stalin's ideological purity here... In an ideal world, we would have separate sources of trade data, and

>> Will this require to write from scratch the Exiobase RDF converter? do I understand correctly or is this about some other data? > But we need to update this software anyway to a) make it a proper >

Hi Chris, for how the data is now in the publicly available excel file, we can ignore for the SUPPLY, but we cannot "just ignore" the location for the USE table, we need to recompute the

Indeed, this was not clear. Sorry. I was referring to https://frictionlessdata.io/specs/data-package/ and https://frictionlessdata.io/specs/tabular-data-resource/

OK, but we can just... ignore... this location? Each national S or U table by definition only has one location anyway. In any case, I don't think there needs to be a discussion here, as our ontology

Hi Chris The disaggregation to country level data is mainly to avoid the assumptions made using the trade matrix (info on markets for different flow objects). Current SUT tables include this

Hi Chris, unfortunately half of what you say is alien to me, but I have the impression that this is about the numeric data that the RDF converter is handling. Will this require to write from scratch

Sorry for chiming in late here. +1 to the idea of only using the publicly available data, it seems to me a very unnecessary and dangerous step to start using private (and unlicensed!) data at the

True, I did the correspondence to the label not the code. Currently it looks like this: https://github.com/BONSAMURAIS/rdf/blob/master/activitytype/exiobase3_3_17/exiobase3_3_17.ttl

Thanks Miguel, I will work on the activity one for now then. In the current one I see tare only strings, isn't there a "code" for these ? Like for activities we have the Exiobase code