Date   

Re: #bep0002 Proposal open for discussion #bep0002

Massimo Pizzol
 

YES

 

From: <main@bonsai.groups.io> on behalf of "Chris Mutel via Groups.Io" <cmutel@...>
Reply-To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Saturday, 22 February 2020 at 09.48
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] #bep0002 Proposal open for discussion

 

YES

 

On Fri, 21 Feb 2020 at 17:39, romain via Groups.Io <r_s@...> wrote:

 

YES

 

 

 

--

############################

Chris Mutel

Technology Assessment Group, LEA

Paul Scherrer Institut

OHSA D22

5232 Villigen PSI

Switzerland

Telefon: +41 56 310 5787

############################

 

 

 


Re: #bep0002 Proposal open for discussion #bep0002

 

YES

On Fri, 21 Feb 2020 at 17:39, romain via Groups.Io <r_s=me.com@groups.io> wrote:

YES
--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################


Re: Call-in details for today's call (BONSAI <> TRASE)

 

Here are the slides from yesterday.

On Fri, 21 Feb 2020 at 17:11, Matteo Lissandrini (AAU) <matteo@...> wrote:

Thanks,

are there available also slides (if some slides have been presented that means ) ?

---
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=gmail.com@groups.io>
Sent: 21 February 2020 16:13:46
To: main@bonsai.groups.io; Michael Lathuillière; Javier Godar; rosa.indenbaum@...
Subject: Re: [bonsai] Call-in details for today's call (BONSAI <> TRASE)

My notes from today's discussion, please respond with any points I missed!

- Trase data is available already, should be examined by bonsai team

- Trase tools should be open access (commitment exists)
- Using python
- Big, distributed team
- Need to clean up and standardize before publishing
- Working on making available via Github

- Trase is willing to make more data available, but want to know what
is actually useful
- Action item for bonsai!

- Possible area of collaboration: Algorithms and models on how to get
to solve (optimization) supply chain problems with imperfect
information

- Blockchain for tracing supply chain impacts?
- Little support from trase administration
- Could be helpful in time series data of changes in trade patterns
- A key question is the "Stickiness" of supply chains (how respond
to outside shocks) (important to know what the relevant temporal scale
is)

Should invite trase team to hackathon!

On Fri, 21 Feb 2020 at 13:36, Christopher Mutel <@cmutel> wrote:

Time: Feb 21, 2020 03:00 PM Copenhagen

Join Zoom Meeting
https://zoom.us/j/942489554

Meeting ID: 942 489 554

Agenda:

TRASE presentation (Michael Lathuillière): 30 mins
BONSAI presentation (Chris Mutel): 10 mins
Discussion: 20 mins

--
############################
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
############################





--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################


Re: #bep0002 Proposal open for discussion #bep0002

romain
 

YES


Re: #bep0002 Proposal open for discussion #bep0002

Miguel Fernández Astudillo
 

yes

(Miguel F. Astudillo)



On Fri, 21 Feb 2020 at 17:10, Bo Weidema <bo.weidema@...> wrote:

YES

Den 2020/02/21 kl. 16.52 skrev romain via Groups.Io:
Dear community members,

BEP002 (https://github.com/BONSAMURAIS/enhancements/blob/master/beps/0002-bonsai-project-community-governance-structure.md) is now open to votes.
The voting period will last one month (Friday the 20th of March).
Simply reply to this discussion thread by "YES" or "NO".
--


Re: Call-in details for today's call (BONSAI <> TRASE)

Matteo Lissandrini (AAU)
 

Thanks,

are there available also slides (if some slides have been presented that means ) ?

---
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=gmail.com@groups.io>
Sent: 21 February 2020 16:13:46
To: main@bonsai.groups.io; Michael Lathuillière; Javier Godar; rosa.indenbaum@...
Subject: Re: [bonsai] Call-in details for today's call (BONSAI <> TRASE)

My notes from today's discussion, please respond with any points I missed!

- Trase data is available already, should be examined by bonsai team

- Trase tools should be open access (commitment exists)
- Using python
- Big, distributed team
- Need to clean up and standardize before publishing
- Working on making available via Github

- Trase is willing to make more data available, but want to know what
is actually useful
- Action item for bonsai!

- Possible area of collaboration: Algorithms and models on how to get
to solve (optimization) supply chain problems with imperfect
information

- Blockchain for tracing supply chain impacts?
- Little support from trase administration
- Could be helpful in time series data of changes in trade patterns
- A key question is the "Stickiness" of supply chains (how respond
to outside shocks) (important to know what the relevant temporal scale
is)

Should invite trase team to hackathon!

On Fri, 21 Feb 2020 at 13:36, Christopher Mutel <@cmutel> wrote:

Time: Feb 21, 2020 03:00 PM Copenhagen

Join Zoom Meeting
https://zoom.us/j/942489554

Meeting ID: 942 489 554

Agenda:

TRASE presentation (Michael Lathuillière): 30 mins
BONSAI presentation (Chris Mutel): 10 mins
Discussion: 20 mins

--
############################
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
############################


Re: #bep0002 Proposal open for discussion #bep0002

Bo Weidema
 

YES

Den 2020/02/21 kl. 16.52 skrev romain via Groups.Io:

Dear community members,

BEP002 (https://github.com/BONSAMURAIS/enhancements/blob/master/beps/0002-bonsai-project-community-governance-structure.md) is now open to votes.
The voting period will last one month (Friday the 20th of March).
Simply reply to this discussion thread by "YES" or "NO".
--


Re: #bep0002 Proposal open for discussion #bep0002

Michele De Rosa
 

To be clear: 

YES = APPROVED

NO = REJECTED

I vote YES!

 

 


Re: #bep0002 Proposal open for discussion #bep0002

romain
 

Dear community members,

BEP002 (https://github.com/BONSAMURAIS/enhancements/blob/master/beps/0002-bonsai-project-community-governance-structure.md) is now open to votes.
The voting period will last one month (Friday the 20th of March).
Simply reply to this discussion thread by "YES" or "NO".


Re: Call-in details for today's call (BONSAI <> TRASE)

 

My notes from today's discussion, please respond with any points I missed!

- Trase data is available already, should be examined by bonsai team

- Trase tools should be open access (commitment exists)
- Using python
- Big, distributed team
- Need to clean up and standardize before publishing
- Working on making available via Github

- Trase is willing to make more data available, but want to know what
is actually useful
- Action item for bonsai!

- Possible area of collaboration: Algorithms and models on how to get
to solve (optimization) supply chain problems with imperfect
information

- Blockchain for tracing supply chain impacts?
- Little support from trase administration
- Could be helpful in time series data of changes in trade patterns
- A key question is the "Stickiness" of supply chains (how respond
to outside shocks) (important to know what the relevant temporal scale
is)

Should invite trase team to hackathon!

On Fri, 21 Feb 2020 at 13:36, Christopher Mutel <@cmutel> wrote:

Time: Feb 21, 2020 03:00 PM Copenhagen

Join Zoom Meeting
https://zoom.us/j/942489554

Meeting ID: 942 489 554

Agenda:

TRASE presentation (Michael Lathuillière): 30 mins
BONSAI presentation (Chris Mutel): 10 mins
Discussion: 20 mins

--
############################
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
############################


Opening a second work track for BONSAI #dataliberation

 

I would like to propose we open a second work track for BONSAI: data liberation. The goal is to allow for more work to be done on interesting research questions and practical challenges in a distributed and democratic fashion.
 
The problem
 
We currently have ambitions about all-encompassing database using an ontology and tool chain, both currently under development. This plan has a lot of ideas that are, in my opinion, fundamentally correct, including the use of different kinds of data to develop inventories, storing information in its original form and transparently documenting any transformations, and including actors as fundamental bits of data along with flows and activities. However, the relatively slow progress, specific tool chain, and lack of widespread expertise at the intersection of tools and concepts make it difficult and frustrating for most BONSAI participants to make real contributions - and essentially impossible for outsiders! You can see this clearly in the commit stream to the BONSAI repositories.
 
At the same time, there are stupid barriers in doing industrial ecology and LCA work where BONSAI could make a substantial contribution in the very short term, like common standards for nomenclature, improving data formats, conversion tools, small parametric models for activities, science-based algorithms for merging and reconciling data, and tools for extracting data from published LCA studies.
 
Finally, BONSAI seems to exist as a separate pillar or project, working to some degree with others (e.g. the presentations seen or to come from US EPA, HESTIA, TRASE), but still it's own "team." Probably this is inevitable, to some degree, but such separation means some duplication of effort, as well as effort on many sides to translate across data formats or ontologies. There is enough tribalism in the world already, and, again in my opinion, we are too willing to let the perfect be the enemy of the good enough.
 
A different vision
 
  • BONSAI is the entire LCA/industrial ecology community (or maybe vice-versa). BONSAI reflects a number of different subject domains and methodological approaches, and doesn't try to fit everything into it's own shoebox.
  • Use open stuff already being worked on by others! No more wheels needed. BONSAI is not an individual tree, but an aspen community (but without the cloning part :).
  • Prioritize efforts during and outside of hackathons based on broad input from the community. Incrementalism instead of revolution.
  • Widely used, understood, and damn simple tech choices. See work of Stefan Pauliuk [0] for inspiration.
  • No religious debates on tiny details. Need proof of importance before starting widespread discussion, and big choices can only be made through the BEP process [1], not by a few people in a room somewhere.
 
Next steps
 
Let's talk about it - this is only my perspective, and this proposal (and indeed, BONSAI as a whole) doesn't work without many people participating. Discussion as usual on the mailing list (to keep an open record) under the hashtag #dataliberation.
 
Personally, given my limited time and energy, I will no longer be developing the BONSAI semantic web database work track.
 
[0] http://www.database.industrialecology.uni-freiburg.de/
[1] https://github.com/BONSAMURAIS/enhancements/blob/master/beps/0002-bonsai-project-community-governance-structure.md


Re: Call-in details for today's call (BONSAI <> TRASE)

Matteo Lissandrini (AAU)
 

Hi,
this was not in my calendar for some reason, did I miss something?
When was this organized?

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=gmail.com@groups.io>
Sent: 21 February 2020 13:36:11
To: main@bonsai.groups.io; Michael Lathuillière; Javier Godar; rosa.indenbaum@...
Subject: [bonsai] Call-in details for today's call (BONSAI <> TRASE)

Time: Feb 21, 2020 03:00 PM Copenhagen

Join Zoom Meeting
https://zoom.us/j/942489554

Meeting ID: 942 489 554

Agenda:

TRASE presentation (Michael Lathuillière): 30 mins
BONSAI presentation (Chris Mutel): 10 mins
Discussion: 20 mins

--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################


Call-in details for today's call (BONSAI <> TRASE)

 

Time: Feb 21, 2020 03:00 PM Copenhagen

Join Zoom Meeting
https://zoom.us/j/942489554

Meeting ID: 942 489 554

Agenda:

TRASE presentation (Michael Lathuillière): 30 mins
BONSAI presentation (Chris Mutel): 10 mins
Discussion: 20 mins

--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################


Building collaboration with US EPA #communication

Agneta
 

Dear All

We had a meeting with Wes Ingwersen and David Meyer (US EPA) for collaboration possibilities with BONSAI. Here are some of the opportunities we discussed:

1) Convert USEE supply and use data to RDF using Bonsai ontology
2) Link this to Exiobase as an example on how the resolution of Exiobase could be improved with country specific data (supply and use tables)
3) Similary we could test the inclusion of data from external datasets different from traditional LCI data (Eg. data on chemical exposure ) as an example of  interoperability 
 David has relevant experience with testing interoperability of data from based on different ontologies. If interested you can read his paper (see attachment). 

They are keen on joining us on the next hackathon! :) 

Best regards
Agneta


Data group on Transport Energy

Bo Weidema
 

Hi,

Some interesting parallel work going on on transport energy: https://transportenergy.org/

Best regards

Bo


Re: Import of Exiobase data #exiobase

Massimo Pizzol
 

Thanks. I must say I didn’t know that this exiobase “extension table” existed, specifying the mass composition of a monetary output.

I think what you propose below is fine then, or at least I don’t see any limitation at first sight. Indeed both the dry mass content, steel content, wood content, etc.,  and the monetary value, price, weight, etc. are all characteristics or “properties” of the same flow.

 

Massimo

 

 

From: <main@bonsai.groups.io> on behalf of "Bo Weidema via Groups.Io" <bo.weidema@...>
Reply-To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Tuesday, 21 January 2020 at 19.31
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Import of Exiobase data #exiobase

 

Dear Massimo,

Good with critical questions.

Although Matteo's example is correct, maybe the example would have been easier to understand if using as the second flow "dry mass" as such, rather than "dry mass of steel", the point being that the same flow, namely that of cars has many "balanceable properties" that can each be measured and expressed separately. The flow of car can be expressed by its value (in currency) or its dry mass (in mass units), but also in terms of its material composition, separately reporting its content of steel (in mass units), wood (in mass units), etc. all adding up to the total mass. Each of these baleanceable properties can be balanced across the activity, hence the name, in terms of "what goes in must come out".

So to your specific questions:

  • Steel is usually not in an extension table. I would expect Carbon Dioxide to be in the extension table. Or do you mean something else?

In the exiobase hybrid, the cars are reported in currency units, while the mass specified per material is reported in teh extensions tables. This is specific to cars, and is of course not the ideal way to do this. Exiobase is not yet a fully multi-property-layer database....

  • Are you saying that 200 kg of Steel is worth 1000 euros? Is this the relationship we need to maintain? Or that we need 200 kg steel to produce 100euros of cars?
  • Seems like cars and steel are the same thing here…

What Matteo's example says is that the flow of a car with 200 kg of steel trades at a value of 1000 Euro. Both pieces of information relates to the same flow and are useful for different purposes.

  • Are we talking about the same sector modelled in two different tables (a monetary one and a physical units one) or about one sector in a hybrid table?

Sector is not in the BONSAI vocabulary. If you mean the same activity and the same flow in different property tables (layers), then yes. The two (and more) balanceable properties can be represented in the same graph, but for balancing you should query only for one specific balanceable property at a time (althoug simultaneous balancing of all balanceable properties is possible).

I hope this helps?

Bo

 

Den 2020/01/21 kl. 17.27 skrev Massimo Pizzol:

Thanks. I have several questions on this mail from Matteo.

 

  • Steel is usually not in an extension table. I would expect Carbon Dioxide to be in the extension table. Or do you mean something else?
  • Are you saying that 200 kg of Steel is worth 1000 euros? Is this the relationship we need to maintain? Or that we need 200 kg steel to produce 100euros of cars?
  • Seems like cars and steel are the same thing here…
  • Are we talking about the same sector modelled in two different tables (a monetary one and a physical units one) or about one sector in a hybrid table?

 

I am afraid this confusion is due to the poor example, so I suggest using a more accurate one.


BR
Massimo

 

From: <main@bonsai.groups.io> on behalf of "Matteo Lissandrini (AAU) via Groups.Io" <matteo@...>
Reply-To:
"main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Tuesday, 21 January 2020 at 17.13
To:
"main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Import of Exiobase data #exiobase

 

Hi all,

 

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.

 

 

Thanks,

Matteo

 

 

 

---
Matteo Lissandrini

Department of Computer Science
Aalborg University

http://people.cs.aau.dk/~matteo

 


Re: Import of Exiobase data #exiobase

Bo Weidema
 

Dear Massimo,

Good with critical questions.

Although Matteo's example is correct, maybe the example would have been easier to understand if using as the second flow "dry mass" as such, rather than "dry mass of steel", the point being that the same flow, namely that of cars has many "balanceable properties" that can each be measured and expressed separately. The flow of car can be expressed by its value (in currency) or its dry mass (in mass units), but also in terms of its material composition, separately reporting its content of steel (in mass units), wood (in mass units), etc. all adding up to the total mass. Each of these baleanceable properties can be balanced across the activity, hence the name, in terms of "what goes in must come out".

So to your specific questions:

  • Steel is usually not in an extension table. I would expect Carbon Dioxide to be in the extension table. Or do you mean something else?

In the exiobase hybrid, the cars are reported in currency units, while the mass specified per material is reported in teh extensions tables. This is specific to cars, and is of course not the ideal way to do this. Exiobase is not yet a fully multi-property-layer database....

  • Are you saying that 200 kg of Steel is worth 1000 euros? Is this the relationship we need to maintain? Or that we need 200 kg steel to produce 100euros of cars?
  • Seems like cars and steel are the same thing here…

What Matteo's example says is that the flow of a car with 200 kg of steel trades at a value of 1000 Euro. Both pieces of information relates to the same flow and are useful for different purposes.

  • Are we talking about the same sector modelled in two different tables (a monetary one and a physical units one) or about one sector in a hybrid table?

Sector is not in the BONSAI vocabulary. If you mean the same activity and the same flow in different property tables (layers), then yes. The two (and more) balanceable properties can be represented in the same graph, but for balancing you should query only for one specific balanceable property at a time (althoug simultaneous balancing of all balanceable properties is possible).

I hope this helps?

Bo


Den 2020/01/21 kl. 17.27 skrev Massimo Pizzol:

Thanks. I have several questions on this mail from Matteo.

 

  • Steel is usually not in an extension table. I would expect Carbon Dioxide to be in the extension table. Or do you mean something else?
  • Are you saying that 200 kg of Steel is worth 1000 euros? Is this the relationship we need to maintain? Or that we need 200 kg steel to produce 100euros of cars?
  • Seems like cars and steel are the same thing here…
  • Are we talking about the same sector modelled in two different tables (a monetary one and a physical units one) or about one sector in a hybrid table?

 

I am afraid this confusion is due to the poor example, so I suggest using a more accurate one.


BR
Massimo

 

From: <main@bonsai.groups.io> on behalf of "Matteo Lissandrini (AAU) via Groups.Io" <matteo@...>
Reply-To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Tuesday, 21 January 2020 at 17.13
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Import of Exiobase data #exiobase

 

Hi all,

 

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.

 

 

Thanks,

Matteo

 

 

 

---
Matteo Lissandrini

Department of Computer Science
Aalborg University

http://people.cs.aau.dk/~matteo



Re: Import of Exiobase data #exiobase

Matteo Lissandrini (AAU)
 

Thanks for the good questions Massimo.


@Chris, assuming my example clarifies our discussion, can you just replace names/numbers with what you found in the excel file when looking at cars?

I think this will clarify Massimo's and other people's initial doubts.


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 Massimo Pizzol via Groups.Io <massimo@...>
Sent: 21 January 2020 17:27:38
To: main@bonsai.groups.io
Subject: Re: [bonsai] Import of Exiobase data #exiobase
 

Thanks. I have several questions on this mail from Matteo.

 

  • Steel is usually not in an extension table. I would expect Carbon Dioxide to be in the extension table. Or do you mean something else?
  • Are you saying that 200 kg of Steel is worth 1000 euros? Is this the relationship we need to maintain? Or that we need 200 kg steel to produce 100euros of cars?
  • Seems like cars and steel are the same thing here…
  • Are we talking about the same sector modelled in two different tables (a monetary one and a physical units one) or about one sector in a hybrid table?

 

I am afraid this confusion is due to the poor example, so I suggest using a more accurate one.


BR
Massimo

 

From: <main@bonsai.groups.io> on behalf of "Matteo Lissandrini (AAU) via Groups.Io" <matteo@...>
Reply-To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Tuesday, 21 January 2020 at 17.13
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Import of Exiobase data #exiobase

 

Hi all,

 

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.

 

 

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: 21 January 2020 16:36:26
To: main@bonsai.groups.io
Subject: [bonsai] Import of Exiobase data #exiobase

 

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 the following:

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.

Packaging materials

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.

Next steps

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.


Re: Import of Exiobase data #exiobase

Massimo Pizzol
 

Thanks. I have several questions on this mail from Matteo.

 

  • Steel is usually not in an extension table. I would expect Carbon Dioxide to be in the extension table. Or do you mean something else?
  • Are you saying that 200 kg of Steel is worth 1000 euros? Is this the relationship we need to maintain? Or that we need 200 kg steel to produce 100euros of cars?
  • Seems like cars and steel are the same thing here…
  • Are we talking about the same sector modelled in two different tables (a monetary one and a physical units one) or about one sector in a hybrid table?

 

I am afraid this confusion is due to the poor example, so I suggest using a more accurate one.


BR
Massimo

 

From: <main@bonsai.groups.io> on behalf of "Matteo Lissandrini (AAU) via Groups.Io" <matteo@...>
Reply-To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Tuesday, 21 January 2020 at 17.13
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Import of Exiobase data #exiobase

 

Hi all,

 

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.

 

 

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: 21 January 2020 16:36:26
To: main@bonsai.groups.io
Subject: [bonsai] Import of Exiobase data #exiobase

 

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 the following:

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.

Packaging materials

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.

Next steps

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.


Re: Import of Exiobase data #exiobase

Matteo Lissandrini (AAU)
 

Hi all,


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.



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: 21 January 2020 16:36:26
To: main@bonsai.groups.io
Subject: [bonsai] Import of Exiobase data #exiobase
 
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 the following:

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.

Packaging materials

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.

Next steps

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.