|
Bo Weidema
Den 2019-10-30 kl. 16.07 skrev Agneta:
Do we need to have a separate repo that breaks the exiobase SUT from the website ? We could also get these country specific tables directly from Stefano.Why do the EXIOBASE consortium not just publish these on the website, saving us the hazzle of re-constructing the original data? Bo
|
|
|
|
Konstantin Stadler
Hi Bo/2.0 LCA Team
toggle quoted messageShow quoted text
You (trough Stefano) have access to the repository having the country SUT tables. I can add more people to the box account if needed. Best Konstantin
On 30/10/2019 17:35, Bo Weidema wrote:
Den 2019-10-30 kl. 16.07 skrev Agneta:Do we need to have a separate repo that breaks the exiobase SUT from the website ? We could also get these country specific tables directly from Stefano.Why do the EXIOBASE consortium not just publish these on the website, saving us the hazzle of re-constructing the original data?
|
|
|
|
Konstantin Stadler
Hi,
toggle quoted messageShow quoted text
All available EXIOBASE concordances are gathered here https://ntnu.app.box.com/s/ziox4zmkgt3cdsg549brr0qaecskgjsd/folder/47855342420 In the folder "other_ind_prod" you will find NACE and ISIC (keep in mind that EXIOBASE2 and 3 have the same product classification). You can also find the link at https://environmentalfootprints.org/exiobase3/ Best Konstantin
On 30/10/2019 14:06, miguel.astudillo@lca-net.com wrote:
Hi
|
|
|
|
Bo Weidema
I am aware that we have priority access as consortium members. I was hinting to making this publicly available... Bo Den 2019-11-01 kl. 15.28 skrev
Konstantin Stadler:
Hi Bo/2.0 LCA Team --
|
|
|
|
Konstantin Stadler
These folders are as public as the updates of EXIOBASE (for everyone who contacts us) - they are in the public folder. I know that this is not the most elegant solution (not much I can do...).
toggle quoted messageShow quoted text
On 01/11/2019 15:45, Bo Weidema wrote:
I am aware that we have priority access as consortium members. I was hinting to making this publicly available...
|
|
|
|
Bo Weidema
Dear Konstantin, This is good news to me! This implies that anyone who cares can re-publish them under the same license... Best regards Bo Den 2019-11-01 kl. 15.49 skrev
Konstantin Stadler:
These folders are as public as the updates of EXIOBASE (for everyone who contacts us) - they are in the public folder. I know that this is not the most elegant solution (not much I can do...). --
|
|
|
|
Konstantin Stadler
Hi Bo,
toggle quoted messageShow quoted text
That's muddy waters. The version on exiobase.eu has a licence which applies to the data there. This is the outcome of the EU-funded project. The data on box is without licence. We worked on that without funding and share it with colleagues bona fides - either for collaborations on research or b/c they contributed to the db. The bona fides part is that they apply the same rules before sharing the data further. Anyway, the details here are something not in my hand - at the end the consortium (afak including 2.0 LCA) needs to decide. Perhaps have a chat with Richard/Arnold? Best kst
On 1 November 2019 19:09:39 CET, Bo Weidema <bo.weidema@...> wrote:
|
|
|
|
Stefano Merciai
Hi all, I can provide the Exiobase hybrid version of national tables but I wonder whether this is the way to go. I try to explain it better. Exiobase is a multi-regional IO database, therefore on the
website you can only download MR-tables. Of course who contributes
to Exiobase has as intermediate result the national tables stored
somewhere but not on the official Exiobase website. But then, does
Bonsai rely on publicly available data or on 'confidential' data?
In the light of future updates, what is the best way to go? And what if we intend to use other world IO databases such as the
WIOD? We will have the same problem. However, moving from MR-tables to a national table is a quite
simple procedure because we just need to aggregate rows and
columns. This procedure could be easily generalized for future
imports of multi-regional databases. The only issue I see here is
that Exiobase will be stored twice on the Bonsai storage. Best, Stefano
On 01/11/2019 15:45, Bo Weidema wrote:
--
|
|
|
|
Bo Weidema
Dear Stefano, Thanks for your reflections. In the long run, BONSAI should of course not rely on Exiobase or any other processed data, but on as a "raw" data source as possible. For IO tables, this means national Supply Use data, obtained directly from the national statistical agencies etc. Back-calulating these from Exiobase would in all cases just be a temporary solution to get a good start with a relatively complete database. Best regards Bo Den 2019-11-04 kl. 11.16 skrev Stefano
Merciai:
--
|
|
|
|
Miguel Fernández Astudillo
Hi
toggle quoted messageShow quoted text
I did a correspondence between exiobase activities and nace 2 sections (highest level of aggregation). It's in the repo now. https://github.com/BONSAMURAIS/Correspondence-tables/blob/master/raw/exiobas e%20act%20to%20nace2%20section.csv best, Miguel
-----Original Message-----
From: main@bonsai.groups.io <main@bonsai.groups.io> On Behalf Of Konstantin Stadler Sent: 01 November 2019 15:32 To: main@bonsai.groups.io Subject: Re: [bonsai] Categories for Exiobase Activities and Flow Objects to enable Exploration #ontology #toolbox Hi, All available EXIOBASE concordances are gathered here https://ntnu.app.box.com/s/ziox4zmkgt3cdsg549brr0qaecskgjsd/folder/478553424 20 In the folder "other_ind_prod" you will find NACE and ISIC (keep in mind that EXIOBASE2 and 3 have the same product classification). You can also find the link at https://environmentalfootprints.org/exiobase3/ Best Konstantin On 30/10/2019 14:06, miguel.astudillo@lca-net.com wrote: Hi
|
|
|
|
Matteo Lissandrini (AAU)
Thanks Miguel, this is great.
I don't remember, what do we need for the FlowObject instead?
---
Matteo Lissandrini Department of Computer Science Aalborg University http://people.cs.aau.dk/~matteo
From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of miguel.astudillo via Groups.Io <miguel.astudillo@...>
Sent: Tuesday, November 5, 2019 3:02:42 PM To: main@bonsai.groups.io Subject: Re: [bonsai] Categories for Exiobase Activities and Flow Objects to enable Exploration #ontology #toolbox Hi
I did a correspondence between exiobase activities and nace 2 sections (highest level of aggregation). It's in the repo now. https://github.com/BONSAMURAIS/Correspondence-tables/blob/master/raw/exiobas e%20act%20to%20nace2%20section.csv best, Miguel -----Original Message----- From: main@bonsai.groups.io <main@bonsai.groups.io> On Behalf Of Konstantin Stadler Sent: 01 November 2019 15:32 To: main@bonsai.groups.io Subject: Re: [bonsai] Categories for Exiobase Activities and Flow Objects to enable Exploration #ontology #toolbox Hi, All available EXIOBASE concordances are gathered here https://ntnu.app.box.com/s/ziox4zmkgt3cdsg549brr0qaecskgjsd/folder/478553424 20 In the folder "other_ind_prod" you will find NACE and ISIC (keep in mind that EXIOBASE2 and 3 have the same product classification). You can also find the link at https://environmentalfootprints.org/exiobase3/ Best Konstantin On 30/10/2019 14:06, miguel.astudillo@... wrote: > Hi > > This is an open issue > https://github.com/BONSAMURAIS/Correspondence-tables/issues/10 > > The correspondence between exiobase activities and isic "codes" does > not exist. It is not trivial problem because some activities > correspond to different "hierarchival levels". Some are quite broad, > others are more specific. > > For this very broad classification, the easiest would be to use the > highest level of aggregation (isic sections). > > Best, > > Miguel > > Miguel-Astudillo-vcard > > *From:*main@bonsai.groups.io <main@bonsai.groups.io> *On Behalf Of *Bo > Weidema > *Sent:* 30 October 2019 13:25 > *To:* main@bonsai.groups.io > *Subject:* Re: [bonsai] Categories for Exiobase Activities and Flow > Objects to enable Exploration #ontology #toolbox > > He, he, ideally they would be in our correspondence table collection... > > But here: > https://sdmx.org/wp-content/uploads/CL_ACTIVITY_ISIC4_1.0.xls > > Bo > > Den 2019-10-30 kl. 12.10 skrev Matteo Lissandrini (AAU): > > That would be great, > > where do I find them? > > --- > Matteo Lissandrini > > Department of Computer Science > Aalborg University > > http://people.cs.aau.dk/~matteo > > > > > > ---------------------------------------------------------------------- > -- > > *From:* main@bonsai.groups.io <mailto:main@bonsai.groups.io> > <main@bonsai.groups.io> <mailto:main@bonsai.groups.io> on behalf of > Bo Weidema via Groups.Io <bo.weidema@...> > <mailto:bo.weidema@...> > *Sent:* Wednesday, October 30, 2019 11:50:33 AM > *To:* main@bonsai.groups.io <mailto:main@bonsai.groups.io> > *Subject:* Re: [bonsai] Categories for Exiobase Activities and Flow > Objects to enable Exploration #ontology #toolbox > > Hi Matteo, > > Would it not be smartest to use the top categories from one of the > classifications, such as ISIC4? > > Best regards > > Bo > > Den 2019-10-30 kl. 11.23 skrev Matteo Lissandrini (AAU): > > Sorry, now is open to anyone for comment, > > let me know your email for edit acces. > > Thanks, > > Matteo > > --- > Matteo Lissandrini > > Department of Computer Science > Aalborg University > > http://people.cs.aau.dk/~matteo > > > > > > ---------------------------------------------------------------------- > -- > > *From:* main@bonsai.groups.io <mailto:main@bonsai.groups.io> > <main@bonsai.groups.io> <mailto:main@bonsai.groups.io> on behalf > of Agneta via Groups.Io <agneta.20@...> > <mailto:agneta.20@...> > *Sent:* Wednesday, October 30, 2019 10:47:09 AM > *To:* main@bonsai.groups.io <mailto:main@bonsai.groups.io> > *Subject:* Re: [bonsai] Categories for Exiobase Activities and > Flow Objects to enable Exploration #ontology #toolbox > > Could you please provide access to the document? > \Agneta > > -- > > -- > >
|
|
|
|
Miguel Fernández Astudillo
Hi Matteo
I think that would be the different sections of the CPC (central product classification). Classifing by “sections” is quite crude but relatively easy.
I think (well, rather hope) there is a 1-1 correspondence with nace 2 / isic sections.
For example :
CPC section 0 : “agriculture, forestry and fishery products” corresponds to the activity “agriculture, forestry and fishing”
We have not done that correspondence yet.
Miguel
From: main@bonsai.groups.io <main@bonsai.groups.io> On Behalf Of Matteo Lissandrini (AAU)
Sent: 05 November 2019 15:42 To: main@bonsai.groups.io Subject: Re: [bonsai] Categories for Exiobase Activities and Flow Objects to enable Exploration #ontology #toolbox
Thanks Miguel, this is great.
I don't remember, what do we need for the FlowObject instead?
--- From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of miguel.astudillo via Groups.Io <miguel.astudillo@...>
Hi
|
|
|
|
Matteo Lissandrini (AAU)
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 right?
---
Matteo Lissandrini Department of Computer Science Aalborg University http://people.cs.aau.dk/~matteo
From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of miguel.astudillo via Groups.Io <miguel.astudillo@...>
Sent: Tuesday, November 5, 2019 4:02:49 PM To: main@bonsai.groups.io Subject: Re: [bonsai] Categories for Exiobase Activities and Flow Objects to enable Exploration #ontology #toolbox Hi Matteo
I think that would be the different sections of the CPC (central product classification). Classifing by “sections” is quite crude but relatively easy.
I think (well, rather hope) there is a 1-1 correspondence with nace 2 / isic sections.
For example :
CPC section 0 : “agriculture, forestry and fishery products” corresponds to the activity “agriculture, forestry and fishing”
We have not done that correspondence yet.
Miguel
From: main@bonsai.groups.io <main@bonsai.groups.io>
On Behalf Of Matteo Lissandrini (AAU)
Thanks Miguel, this is great.
I don't remember, what do we need for the FlowObject instead?
--- From:
main@bonsai.groups.io <main@bonsai.groups.io> on behalf of miguel.astudillo via Groups.Io <miguel.astudillo@...>
Hi
|
|
|
|
Miguel Fernández Astudillo
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
brdfat:A_ALUM a bont:ActivityType rdfs:label "Aluminium production"
the correspondence between the code and the label is in an excel file in native format as extracted from Exiobase official version.
https://github.com/BONSAMURAIS/arborist/tree/master/arborist/data
for the final correspondence table we’d need the uris for the nace2 division… I think there is not a defined ontology for that and we may need to create our own.
Miguel
From: main@bonsai.groups.io <main@bonsai.groups.io> On Behalf Of Matteo Lissandrini (AAU)
Sent: 05 November 2019 16:22 To: main@bonsai.groups.io Subject: Re: [bonsai] Categories for Exiobase Activities and Flow Objects to enable Exploration #ontology #toolbox
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 right?
--- From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of miguel.astudillo via Groups.Io <miguel.astudillo@...>
Hi Matteo
I think that would be the different sections of the CPC (central product classification). Classifing by “sections” is quite crude but relatively easy.
I think (well, rather hope) there is a 1-1 correspondence with nace 2 / isic sections.
For example :
CPC section 0 : “agriculture, forestry and fishery products” corresponds to the activity “agriculture, forestry and fishing”
We have not done that correspondence yet.
Miguel
From: main@bonsai.groups.io <main@bonsai.groups.io> On Behalf Of Matteo Lissandrini (AAU)
Thanks Miguel, this is great.
I don't remember, what do we need for the FlowObject instead?
--- From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of miguel.astudillo via Groups.Io <miguel.astudillo@...>
Hi
|
|
|
|
Sorry for chiming in late here.
toggle quoted messageShow quoted text
+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 beginning of our journey. I have, after some effort, convert the hybrid IO table to a tidy format, with proper packaging and metadata in the data package format. The data is here: http://files.brightwaylca.org/exiobase-3.3.17-hybrid.tar, the code is here: https://github.com/brightway-lca/mrio_common_metadata/tree/master/mrio_common_metadata/conversion/exiobase_3_hybrid. I would be happy to do this for the SU tables as well. Using the tidy format, and standards packaging, would allow us to have one importer that would work for multiple MRIO/SU databases, which seems to me to be a big win. Agneta, your diagrams are great, but could you explain *why* we would want to separate out the individual country tables? Is this just to get the raw country data before it is processed by the EXIOBASE balancing algorithm? Separating out the country tables from the provided data seems easy but unnecessary. -C
On Mon, 4 Nov 2019 at 16:35, Bo Weidema <bo.weidema@bonsai.uno> wrote:
--
############################ Chris Mutel Technology Assessment Group, LEA Paul Scherrer Institut OHSA D22 5232 Villigen PSI Switzerland http://chris.mutel.org Telefon: +41 56 310 5787 ############################
|
|
|
|
Matteo Lissandrini (AAU)
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 the Exiobase RDF converter? do I understand correctly or is this about some other data?
Thanks, Matteo
---
Matteo Lissandrini Department of Computer Science Aalborg University http://people.cs.aau.dk/~matteo
From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of Chris Mutel via Groups.Io <cmutel@...>
Sent: Wednesday, November 6, 2019 10:33:31 AM To: main@bonsai.groups.io Subject: Re: [bonsai] #rdf #issues #exiobase 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 beginning of our journey. I have, after some effort, convert the hybrid IO table to a tidy format, with proper packaging and metadata in the data package format. The data is here: http://files.brightwaylca.org/exiobase-3.3.17-hybrid.tar, the code is here: https://github.com/brightway-lca/mrio_common_metadata/tree/master/mrio_common_metadata/conversion/exiobase_3_hybrid. I would be happy to do this for the SU tables as well. Using the tidy format, and standards packaging, would allow us to have one importer that would work for multiple MRIO/SU databases, which seems to me to be a big win. Agneta, your diagrams are great, but could you explain *why* we would want to separate out the individual country tables? Is this just to get the raw country data before it is processed by the EXIOBASE balancing algorithm? Separating out the country tables from the provided data seems easy but unnecessary. -C On Mon, 4 Nov 2019 at 16:35, Bo Weidema <bo.weidema@...> wrote: > > Dear Stefano, > > Thanks for your reflections. In the long run, BONSAI should of course not rely on Exiobase or any other processed data, but on as a "raw" data source as possible. For IO tables, this means national Supply Use data, obtained directly from the national statistical agencies etc. Back-calulating these from Exiobase would in all cases just be a temporary solution to get a good start with a relatively complete database. > > Best regards > > Bo > > Den 2019-11-04 kl. 11.16 skrev Stefano Merciai: > > Hi all, > > I can provide the Exiobase hybrid version of national tables but I wonder whether this is the way to go. I try to explain it better. > > Exiobase is a multi-regional IO database, therefore on the website you can only download MR-tables. Of course who contributes to Exiobase has as intermediate result the national tables stored somewhere but not on the official Exiobase website. But then, does Bonsai rely on publicly available data or on 'confidential' data? In the light of future updates, what is the best way to go? > > And what if we intend to use other world IO databases such as the WIOD? We will have the same problem. > > However, moving from MR-tables to a national table is a quite simple procedure because we just need to aggregate rows and columns. This procedure could be easily generalized for future imports of multi-regional databases. The only issue I see here is that Exiobase will be stored twice on the Bonsai storage. > > Best, > > Stefano > > > > > On 01/11/2019 15:45, Bo Weidema wrote: > > I am aware that we have priority access as consortium members. I was hinting to making this publicly available... > > Bo > > Den 2019-11-01 kl. 15.28 skrev Konstantin Stadler: > > Hi Bo/2.0 LCA Team > > You (trough Stefano) have access to the repository having the country SUT tables. I can add more people to the box account if needed. > > Best > Konstantin > > On 30/10/2019 17:35, Bo Weidema wrote: > > Den 2019-10-30 kl. 16.07 skrev Agneta: > > Do we need to have a separate repo that breaks the exiobase SUT from the website ? We could also get these country specific tables directly from Stefano. > > Why do the EXIOBASE consortium not just publish these on the website, saving us the hazzle of re-constructing the original data? > > Bo > > > > > > > -- > > > -- > > -- > -- ############################ Chris Mutel Technology Assessment Group, LEA Paul Scherrer Institut OHSA D22 5232 Villigen PSI Switzerland http://chris.mutel.org Telefon: +41 56 310 5787 ############################
|
|
|
|
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 information, given as location of flow objects. This information is not necessary for the raw SUT data. Assumptions with respect to trade matrix can be added later as I discussed with Stefano. The discussion on this was elaborated by Bo and updated on the read me for the MOJO repository ( https://github.com/BONSAMURAIS/mojo#why-flows-do-not-have-a-location) Best Agneta
On Wed, 6 Nov 2019, 10:34 AM Chris Mutel, <cmutel@...> wrote: Sorry for chiming in late here.
|
|
|
|
On Wed, 6 Nov 2019 at 11:42, Agneta <agneta.20@gmail.com> wrote:
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 information, given as location of flow objects.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 does not allow flow objects to have a location, so we can't input this data in the first place. This information is not necessary for the raw SUT data. Assumptions with respect to trade matrix can be added later as I discussed with Stefano. -- ############################ Chris Mutel Technology Assessment Group, LEA Paul Scherrer Institut OHSA D22 5232 Villigen PSI Switzerland http://chris.mutel.org Telefon: +41 56 310 5787 ############################
|
|
|
|
On Wed, 6 Nov 2019 at 11:30, Matteo Lissandrini (AAU) <matteo@cs.aau.dk> wrote:
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.Indeed, this was not clear. Sorry. I was referring to https://frictionlessdata.io/specs/data-package/ and https://frictionlessdata.io/specs/tabular-data-resource/ and https://en.wikipedia.org/wiki/Tidy_data; see also attached the datapackage.json file for the IO tables. Will this require to write from scratch the Exiobase RDF converter? do I understand correctly or is this about some other data?No, the "intermediate" file is basically the same; https://github.com/BONSAMURAIS/EXIOBASE-conversion-software/blob/master/scripts/excel2csv.py does more or less the same thing, just less completely (not all extensions, doesn't check to make sure EXIOBASE authors were consistent in row and column labels, doesn't correct typos or clean whitespace), and without providing metadata following a specification. But we need to update this software anyway to a) make it a proper installable package, b) follow the URI schema that we are now using, and c) fill in all the "TODO"s in the code.
|
|
|
|
Matteo Lissandrini (AAU)
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 aggregates:
See
https://github.com/BONSAMURAIS/rdf/issues/4
---
Matteo Lissandrini Department of Computer Science Aalborg University http://people.cs.aau.dk/~matteo
From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of Chris Mutel via Groups.Io <cmutel@...>
Sent: Wednesday, November 6, 2019 12:01:39 PM To: main@bonsai.groups.io Subject: Re: [bonsai] #rdf #issues #exiobase On Wed, 6 Nov 2019 at 11:42, Agneta <agneta.20@...> wrote:
> 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 information, given as location of flow objects. 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 does not allow flow objects to have a location, so we can't input this data in the first place. > This information is not necessary for the raw SUT data. Assumptions with respect to trade matrix can be added later as I discussed with Stefano. > The discussion on this was elaborated by Bo and updated on the read me for the MOJO repository ( https://github.com/BONSAMURAIS/mojo#why-flows-do-not-have-a-location) > > Best > Agneta > > On Wed, 6 Nov 2019, 10:34 AM Chris Mutel, <cmutel@...> wrote: >> >> 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 beginning of our journey. >> >> I have, after some effort, convert the hybrid IO table to a tidy >> format, with proper packaging and metadata in the data package format. >> The data is here: >> http://files.brightwaylca.org/exiobase-3.3.17-hybrid.tar, the code is >> here: https://github.com/brightway-lca/mrio_common_metadata/tree/master/mrio_common_metadata/conversion/exiobase_3_hybrid. >> I would be happy to do this for the SU tables as well. >> >> Using the tidy format, and standards packaging, would allow us to have >> one importer that would work for multiple MRIO/SU databases, which >> seems to me to be a big win. >> >> Agneta, your diagrams are great, but could you explain *why* we would >> want to separate out the individual country tables? Is this just to >> get the raw country data before it is processed by the EXIOBASE >> balancing algorithm? Separating out the country tables from the >> provided data seems easy but unnecessary. >> >> -C >> >> On Mon, 4 Nov 2019 at 16:35, Bo Weidema <bo.weidema@...> wrote: >> > >> > Dear Stefano, >> > >> > Thanks for your reflections. In the long run, BONSAI should of course not rely on Exiobase or any other processed data, but on as a "raw" data source as possible. For IO tables, this means national Supply Use data, obtained directly from the national statistical agencies etc. Back-calulating these from Exiobase would in all cases just be a temporary solution to get a good start with a relatively complete database. >> > >> > Best regards >> > >> > Bo >> > >> > Den 2019-11-04 kl. 11.16 skrev Stefano Merciai: >> > >> > Hi all, >> > >> > I can provide the Exiobase hybrid version of national tables but I wonder whether this is the way to go. I try to explain it better. >> > >> > Exiobase is a multi-regional IO database, therefore on the website you can only download MR-tables. Of course who contributes to Exiobase has as intermediate result the national tables stored somewhere but not on the official Exiobase website. But then, does Bonsai rely on publicly available data or on 'confidential' data? In the light of future updates, what is the best way to go? >> > >> > And what if we intend to use other world IO databases such as the WIOD? We will have the same problem. >> > >> > However, moving from MR-tables to a national table is a quite simple procedure because we just need to aggregate rows and columns. This procedure could be easily generalized for future imports of multi-regional databases. The only issue I see here is that Exiobase will be stored twice on the Bonsai storage. >> > >> > Best, >> > >> > Stefano >> > >> > >> > >> > >> > On 01/11/2019 15:45, Bo Weidema wrote: >> > >> > I am aware that we have priority access as consortium members. I was hinting to making this publicly available... >> > >> > Bo >> > >> > Den 2019-11-01 kl. 15.28 skrev Konstantin Stadler: >> > >> > Hi Bo/2.0 LCA Team >> > >> > You (trough Stefano) have access to the repository having the country SUT tables. I can add more people to the box account if needed. >> > >> > Best >> > Konstantin >> > >> > On 30/10/2019 17:35, Bo Weidema wrote: >> > >> > Den 2019-10-30 kl. 16.07 skrev Agneta: >> > >> > Do we need to have a separate repo that breaks the exiobase SUT from the website ? We could also get these country specific tables directly from Stefano. >> > >> > Why do the EXIOBASE consortium not just publish these on the website, saving us the hazzle of re-constructing the original data? >> > >> > Bo >> > >> > >> > >> > >> > >> > >> > -- >> > >> > >> > -- >> > >> > -- >> > >> >> >> >> -- >> ############################ >> Chris Mutel >> Technology Assessment Group, LEA >> Paul Scherrer Institut >> OHSA D22 >> 5232 Villigen PSI >> Switzerland >> http://chris.mutel.org >> Telefon: +41 56 310 5787 >> ############################ >> >> >> > -- ############################ Chris Mutel Technology Assessment Group, LEA Paul Scherrer Institut OHSA D22 5232 Villigen PSI Switzerland http://chris.mutel.org Telefon: +41 56 310 5787 ############################
|
|
|
