Date   

Matteo Lissandrini (AAU)
 

Hi all,

I think  this is really a well made guide.
We should probably collect useful introductory materials about RDF, LCIA, and other topics interesecting the BONSAI project.

“An easy-to-read guide for those looking to learn about semantic modelling or refresh their memory on the subject.
Intended for a wide audience, the book covers topics from basic RDF, to integrating ontologies, to building a model and, finally, to performing SPARQL queries.”

https://zenodo.org/record/3898519#.XvhCavfRbKI


Best,
Matteo

Paid position for 1 year at the BONSAI group at Aalborg University

Bo Weidema
 

Hi all Bonsamurais,

We have the opportunity to host a paid research assistant for 1 year at the BONSAI group at Aalborg University (the ODA project). We would like to people from the BONSAI community to express their interest informally to me (bweidema@...) before we put up the formal announcement later this summer. 

Bo Weidema

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

Andreas Ciroth
 

Dear all,

 

very good discussion! To the USP especially, in my view it is at present (not using the technically correct terms here probably I am afraid)

  • Bringing together different data sources for life cycle approaches with the idea to do this in practice and
  • Be dogmatic about dealing only with free data

 

For me, and I have said this earlier, the second bullet limits the scope unnecessarily; the first we address to quite some extent at GreenDelta now (and have contributed to GLAD, created Nexus, the IO model builder, and are involved in the interesting US EPA activities now). There are other initiatives, but often a disappointment as the focus is more on presentations, and the procedures really slow (like, again, GLAD, where the current page is very similar to our Nexus site from 5 years ago, only that GLAD does not directly provide access to the listed datasets).

 

There are now unfortunately really few people who understand the technical side of LCA data, and therefore capacity building is good but also it is good to join forces. A limitation to free data makes / made bonsai attractive for providers of closed-source for purchase software tools (who can then use free data in their tools and continue to sell the tools) but misses in my view the full picture. In my view, the whole “supply chain” of data for LCA studies covers data and tools integrating the data, and should be provided to users in an affordable way.

 

All the best and I am looking forward to the exchange,

Andreas

 

Von: main@bonsai.groups.io <main@bonsai.groups.io> Im Auftrag von Massimo Pizzol
Gesendet: Mittwoch, 24. Juni 2020 11:34
An: main@bonsai.groups.io
Betreff: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

I second this comment too. Focus on integration, good documentation, create a critical mass and then facilitating contributions.

 

I would add that for me the challenging aspects in previous hackathons was:

  • to keep an overview of the project. Both vision at high level but also practically what e.g. all the github repositories were about and how they were connected
  • understanding the “why” and “how” of many things (e.g. why is this repository here and what is going on there? Why docker container how does it work? Why balanceable property and what is the use of it?)
  • Navigating knowledge and jargon gaps. We come from different domains and I think we should have a special attention in keeping in language understandable and accessible to all. We might be not all familiar with some technical terms but we are certainly able to understand them, if we take the time to explain to each other. As the good science communication rule: “never underestimate your audience’s intelligence, always underestimate your audience’s vocabulary”.

 

Perhaps this is mostly related to the “documentation” aspect and should be addressed as part of documentation.

 

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, 23 June 2020 at 17.40
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

My comment is the following:

 

The real value proposition that none of the existing resources seems to have is the possibility to *integrate* multiple data sources.

*Integrate* is complementary but very different from *aggregate*.

 

Resources like :

are not dissimilar to

 

are aggregators of data. You can find a dataset, but then you are on your own in determining if the dataset contains the data you need, has the correct format, is coherent with your model, adapt it to your workflow, etc.

 

What I see on GLAD (but I only read the homepage) seems more towards the *integration*, which is good, we should keep a close eye on that.

 

I think the BONSAI with the Ontology and Mapping resources is a step ahead in the *integration* direction.

 

I think the next step is documentation,  from LCA domain experts interested in integrating data (BONSAI)  for LCA domain expert interested in sharing data (all the providers).

As we have a lot of tooling and work done and we just need to show people how to contribute.

With more contribution we obtain more use-cases, we bullet-proof the workflow, and we improve.

 

Yes, documentation is boring, and most of us don't feel are achieving anything if we are not writing code, calculating numbers, or running experiments.

Yet, I see this as the crucial part for "lift-off", otherwise our space shuttle will always stay in the hangar redesigning the engine for N-th time but never turning it on.

 

 

Best,

Matteo

 

 

 

 

 

 

---

Matteo Lissandrini

 

Department of Computer Science

Aalborg University

 

 

 

 

 

 

 

________________________________________

From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of Benjamin W. Portner via groups.io <benjamin.portner@...>

Sent: 23 June 2020 16:58:26

Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

My thoughts:

 

- BONSAI and other projects (Electricity LCI<https://github.com/USEPA/ElectricityLCI>, US EEIO<https://github.com/USEPA/USEEIO> LCIA base data<https://github.com/USEPA/Federal-LCA-Commons-Elementary-Flow-List>, LCIA data formats<https://github.com/USEPA/LCIAformatter>, CDLCI project<https://www.pre-sustainability.com/news/harness-the-power-of-the-lca-community>, GLAD<https://www.unenvironment.org/explore-topics/resource-efficiency/what-we-do/life-cycle-initiative/global-lca-data-access-network>, IEDC<http://www.database.industrialecology.uni-freiburg.de>,...): I agree that it is hard to keep up with the numerous projects out there. We should definitely avoid reinventing the wheel. The question is: How? Adopting existing data, formats, etc. is good. But how can we do that if we don't know about them? Do we need some sort of "radar" for new projects and a "screening system" to filter out the portions of those projects, which are interesting for us?

 

- Community engagement: I agree. I don't know if the existing BONSAI technology can help. Would be awesome if it could! If not, we need to find better ways to engage the community. Pré's LCAList is a good place to find advice but it is a poor place for collaboration. GitHub is a great place for collaboration but I don't think many people from the LCAList are there. I wonder if there is a way to bridge the gap between both communities.

 

- BONSAI's 2nd work track: I was originally in favor of this idea but I lost momentum because I felt like support within BONSAI was weak. Furthermore, I feel like the release of GLAD made this the work track obsolete (although I might be wrong). I think there should be a new discussion about this.

 

- Hackathon: I really regret that there is no in-person hackathon this year. For a newbie like me this would have presented a great opportunity to get to know everyone. Furthermore, I was planning to use it as an opportunity to get acquainted with the work previously done in BONSAI. I agree that an online hackathon is a poor substitute. But I think that an online hackathon is better than no hackathon :)

 

That's it from me. Looking forward to hearing the results from the GA.

Ben

 

 

 

 

 

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

arturdonaldson@...
 
Edited

Hi all,

This my first post in the BONSAI community, but have been subscribed to the list for a while and would like to be able to participate more. Coming from a programming/physical sciences background I feel the LCA community could do with greater open-source collaboration which is what makes BONSAI stand out. I want to add to Brandon's point about engagement.

In order to keep the project growing given the current situation with coronavirus (and perhaps also going beyond that) one idea to try is a hackathon spread over a longer period of time and as a series of events, to make it more accessible for those with parental/carer duties and allow establishment of teams. I have seen this emerge since March with other volunteer-run groups outside of LCA in place of traditional hackathons, and like all of us have have experienced both both good and not so good transitions online. Some have run coding challenges, workshops and talks spread out over several days with a central communication platform such as Slack/Rocket/MatterMost Chat. For interactive workshops and larger talks, platforms like Zoom or https://konf.co/ (for video conferences) are used to bring everyone together.

Nice examples include the OpenCOVID19 initiative hackathon which was organized by a relatively small organization set up last year, but managed to attract over 1000 projects. Even though LCA may not be so widely known about as COVID-19, it would still be possible to create an online space for incubating ideas through events of this style. It would take a core team working fairly intensely to organize such an event, find organizations to support, and to advertise it, but BONSAI is not coming from no-where and it is worth a shot.

All the best,
Artur

--
Research Analyst, LCAWorks
Previously at the Centre for Environmental Policy, Imperial College London

London, UK
GitHub: tur-ium

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

Massimo Pizzol
 

I second this comment too. Focus on integration, good documentation, create a critical mass and then facilitating contributions.

 

I would add that for me the challenging aspects in previous hackathons was:

  • to keep an overview of the project. Both vision at high level but also practically what e.g. all the github repositories were about and how they were connected
  • understanding the “why” and “how” of many things (e.g. why is this repository here and what is going on there? Why docker container how does it work? Why balanceable property and what is the use of it?)
  • Navigating knowledge and jargon gaps. We come from different domains and I think we should have a special attention in keeping in language understandable and accessible to all. We might be not all familiar with some technical terms but we are certainly able to understand them, if we take the time to explain to each other. As the good science communication rule: “never underestimate your audience’s intelligence, always underestimate your audience’s vocabulary”.

 

Perhaps this is mostly related to the “documentation” aspect and should be addressed as part of documentation.

 

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, 23 June 2020 at 17.40
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

My comment is the following:

 

The real value proposition that none of the existing resources seems to have is the possibility to *integrate* multiple data sources.

*Integrate* is complementary but very different from *aggregate*.

 

Resources like :

are not dissimilar to

 

are aggregators of data. You can find a dataset, but then you are on your own in determining if the dataset contains the data you need, has the correct format, is coherent with your model, adapt it to your workflow, etc.

 

What I see on GLAD (but I only read the homepage) seems more towards the *integration*, which is good, we should keep a close eye on that.

 

I think the BONSAI with the Ontology and Mapping resources is a step ahead in the *integration* direction.

 

I think the next step is documentation,  from LCA domain experts interested in integrating data (BONSAI)  for LCA domain expert interested in sharing data (all the providers).

As we have a lot of tooling and work done and we just need to show people how to contribute.

With more contribution we obtain more use-cases, we bullet-proof the workflow, and we improve.

 

Yes, documentation is boring, and most of us don't feel are achieving anything if we are not writing code, calculating numbers, or running experiments.

Yet, I see this as the crucial part for "lift-off", otherwise our space shuttle will always stay in the hangar redesigning the engine for N-th time but never turning it on.

 

 

Best,

Matteo

 

 

 

 

 

 

---

Matteo Lissandrini

 

Department of Computer Science

Aalborg University

 

 

 

 

 

 

 

________________________________________

From: main@bonsai.groups.io <main@bonsai.groups.io> on behalf of Benjamin W. Portner via groups.io <benjamin.portner@...>

Sent: 23 June 2020 16:58:26

Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

My thoughts:

 

- BONSAI and other projects (Electricity LCI<https://github.com/USEPA/ElectricityLCI>, US EEIO<https://github.com/USEPA/USEEIO> LCIA base data<https://github.com/USEPA/Federal-LCA-Commons-Elementary-Flow-List>, LCIA data formats<https://github.com/USEPA/LCIAformatter>, CDLCI project<https://www.pre-sustainability.com/news/harness-the-power-of-the-lca-community>, GLAD<https://www.unenvironment.org/explore-topics/resource-efficiency/what-we-do/life-cycle-initiative/global-lca-data-access-network>, IEDC<http://www.database.industrialecology.uni-freiburg.de>,...): I agree that it is hard to keep up with the numerous projects out there. We should definitely avoid reinventing the wheel. The question is: How? Adopting existing data, formats, etc. is good. But how can we do that if we don't know about them? Do we need some sort of "radar" for new projects and a "screening system" to filter out the portions of those projects, which are interesting for us?

 

- Community engagement: I agree. I don't know if the existing BONSAI technology can help. Would be awesome if it could! If not, we need to find better ways to engage the community. Pré's LCAList is a good place to find advice but it is a poor place for collaboration. GitHub is a great place for collaboration but I don't think many people from the LCAList are there. I wonder if there is a way to bridge the gap between both communities.

 

- BONSAI's 2nd work track: I was originally in favor of this idea but I lost momentum because I felt like support within BONSAI was weak. Furthermore, I feel like the release of GLAD made this the work track obsolete (although I might be wrong). I think there should be a new discussion about this.

 

- Hackathon: I really regret that there is no in-person hackathon this year. For a newbie like me this would have presented a great opportunity to get to know everyone. Furthermore, I was planning to use it as an opportunity to get acquainted with the work previously done in BONSAI. I agree that an online hackathon is a poor substitute. But I think that an online hackathon is better than no hackathon :)

 

That's it from me. Looking forward to hearing the results from the GA.

Ben

 

 

 

 

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

Agneta
 

Hi Benjamin and Miguel

We already have two datasets one from IO (supply and use tables) and another from MFA linked to the BONSAI ontology. We are in the process of documenting it. I do think some additional sources of process based LCA data can be useful if annotated and linked to the semantic web using the BONSAI ontology.
However, I think its a great idea to show how this could be used together to perform an LCA. 

Great idea for a hackathon!
Agneta
-- 
Agneta Ghose, PhD 
Post doc, The Danish Centre for Environmental Assessment  
Aalborg University
Rendsburggade 14
Aalborg 9000
Denmark 
( +45 93 56 2051


Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

I would really appreciate an extremely simple example of linking two or three fictitious datasets expressed according to the bonsai ontology to produce an LCA score. Something that would fit on a notebook. (Miguel)
That would be tremendously helpful for me. To be honest, when discovering new software packages I usually look at the examples, not the documentation. But maybe that's just me!

I could imagine a periodic meet-up event, e.g. weekly on slack or similar...
Interesting idea! Count me in!

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

Miguel Fernández Astudillo
 

Hi

I will try to elaborate more later but being essentially a volunteer-based organization, I think we also need to pay some attention to the volunteers. In my opinion many are overwhelmed by the complexity and do not see how it is supposed to work.

In that sense better documentation, with more examples should help (e.g. how to add metadata, how to create URI …). There are tasks that are quite simple (like linking exiobase to an existing classification). I would really appreciate an extremely simple example of linking two or three fictitious datasets expressed according to the bonsai ontology to produce an LCA score. Something that would fit on a notebook.

I am a bit out of touch, but it would be interesting to see what potential collaborators would want form BONSAI and why we can’t help them yet (assuming we can’t).


best, Miguel



On Tue, 23 Jun 2020 at 17:56, Bo Weidema <bo.weidema@...> wrote:
I echo Matteo's comment :-)

Bo

Den 2020/06/23 kl. 17.40 skrev Matteo Lissandrini (AAU):
> My comment is the following:
>
> The real value proposition that none of the existing resources seems to have is the possibility to *integrate* multiple data sources.
> *Integrate* is complementary but very different from *aggregate*.
>
> Resources like :
> https://www.globallcadataaccess.org/
> are not dissimilar to
> https://datasetsearch.research.google.com/
>
> are aggregators of data. You can find a dataset, but then you are on your own in determining if the dataset contains the data you need, has the correct format, is coherent with your model, adapt it to your workflow, etc.
>
> What I see on GLAD (but I only read the homepage) seems more towards the *integration*, which is good, we should keep a close eye on that.
>
> I think the BONSAI with the Ontology and Mapping resources is a step ahead in the *integration* direction.
>
> I think the next step is documentation,  from LCA domain experts interested in integrating data (BONSAI)  for LCA domain expert interested in sharing data (all the providers).
> As we have a lot of tooling and work done and we just need to show people how to contribute.
> With more contribution we obtain more use-cases, we bullet-proof the workflow, and we improve.
>
> Yes, documentation is boring, and most of us don't feel are achieving anything if we are not writing code, calculating numbers, or running experiments.
> Yet, I see this as the crucial part for "lift-off", otherwise our space shuttle will always stay in the hangar redesigning the engine for N-th time but never turning it on.
>
>
> Best,
> 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 Benjamin W. Portner via groups.io <benjamin.portner=bauhaus-luftfahrt.net@groups.io>
> Sent: 23 June 2020 16:58:26
> To: main@bonsai.groups.io
> Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication
>
> My thoughts:
>
> - BONSAI and other projects (Electricity LCI<https://github.com/USEPA/ElectricityLCI>, US EEIO<https://github.com/USEPA/USEEIO> LCIA base data<https://github.com/USEPA/Federal-LCA-Commons-Elementary-Flow-List>, LCIA data formats<https://github.com/USEPA/LCIAformatter>, CDLCI project<https://www.pre-sustainability.com/news/harness-the-power-of-the-lca-community>, GLAD<https://www.unenvironment.org/explore-topics/resource-efficiency/what-we-do/life-cycle-initiative/global-lca-data-access-network>, IEDC<http://www.database.industrialecology.uni-freiburg.de>,...): I agree that it is hard to keep up with the numerous projects out there. We should definitely avoid reinventing the wheel. The question is: How? Adopting existing data, formats, etc. is good. But how can we do that if we don't know about them? Do we need some sort of "radar" for new projects and a "screening system" to filter out the portions of those projects, which are interesting for us?
>
> - Community engagement: I agree. I don't know if the existing BONSAI technology can help. Would be awesome if it could! If not, we need to find better ways to engage the community. Pré's LCAList is a good place to find advice but it is a poor place for collaboration. GitHub is a great place for collaboration but I don't think many people from the LCAList are there. I wonder if there is a way to bridge the gap between both communities.
>
> - BONSAI's 2nd work track: I was originally in favor of this idea but I lost momentum because I felt like support within BONSAI was weak. Furthermore, I feel like the release of GLAD made this the work track obsolete (although I might be wrong). I think there should be a new discussion about this.
>
> - Hackathon: I really regret that there is no in-person hackathon this year. For a newbie like me this would have presented a great opportunity to get to know everyone. Furthermore, I was planning to use it as an opportunity to get acquainted with the work previously done in BONSAI. I agree that an online hackathon is a poor substitute. But I think that an online hackathon is better than no hackathon :)
>
> That's it from me. Looking forward to hearing the results from the GA.
> Ben
>
>
>
>




Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

Brandon Kuczenski
 

Hi all,
I agree that the USEPA work under Wes has been really impressive and broad. Compared to BONSAI though, it is both very well capitalized and very constrained institutionally. They are (I think) limited to incremental changes that are not especially transformative. I think they are right alongside BONSAI in terms of trying to figure out how to meld their work with others into a new paradigm. I think this is going to be a process of slow accretion, where the key contributions will provide cross-links between different projects.

Based largely on my experience in the 2019 hackathon, I see BONSAI as a sort of "incubator" or synthesis lab. Taking problems that can be observed and solving them in extensible ways. The ReCiPe 2016 implementation- that is really impressive and a great example (and this is the first I'd heard of it). LCIA has to be redundantly implemented by all the softwares- and even Ecoinvent has to do it- because there doesn't exist a consistent, stable third party version. Now there does.

One thing you could do that would cross-link would be to provide a static export in the EPA's (quite simple) LCIAFormat (https://github.com/USEPA/LCIAformatter/blob/master/format%20specs/LCIAmethod.md). Not sure if it does this already, or if there is a generic export from brightway into a static format. Chris, Didn't you also come up with a serialization format in your regional LCIA roadmap, using data packages? I am all about serializations, especially of shared open resources in simple, transparent formats.

I also agree with Matteo's comment about "integration" as opposed to aggregation being a valuable thing to pursue. Based on the slide that you posted, I don't really see how CDLCI is contributing to that- it seems like they are just modernizing their own integrated pipeline and trying to get their partners' offerings to pipe through it, rather than to cooperate or equally interoperate with it. But I'm just biased against PRe as "old guard."

As for engagement- that is not limited to LCA- I have noticed that it afflicts all of industrial ecology. Look at the R community and especially the "tidyverse" (e.g. for a community that has really embraced novel communication forms to build a truly online collaborative network. UCSB is near the epicenter of that movement (e.g. https://eco-data-science.github.io/ ) and I still feel sharply to the outside of it. But then I don't use R. People need tutorials and hand-holding and blog posts and such that will help them:
 * make websites
 * publish their code
 * document + test their code
 * write tweets / respond to tweets
etc. I personally need help with this. I found cmutels' python-skeleton to be really helpful in getting my very first package published on PyPI (https://pypi.org/project/synonym-dict/). BONSAI projects (and brightway-derived projects like the activity browser) are the only place where I've seen true open-source collaborative development in LCA and that is potentially a big deal. But it does take a lot of effort and a culture of constant engagement to maintain it. 

Some people, e.g. the "energy twitter" community, are good at this. I am not. I have found that I have a tremendously high activation energy and fear of rejection / inadequacy / impostor syndrome that prevents me from putting stuff out at all. Rather than a "hackathon" I could imagine a periodic meet-up event, e.g. weekly on slack or similar, where we all get our jekyll sites up, write tweets / blogs and then re-tweet each other, until it becomes more of a habit. Writing documentation could also be done this way. Writing clearly-stated problems, competency questions, demonstration projects, are all valuable additions.

Just some thoughts. Keep up the good work.

-Brandon



On Tue, Jun 23, 2020 at 8:56 AM Bo Weidema <bo.weidema@...> wrote:
I echo Matteo's comment :-)

Bo

Den 2020/06/23 kl. 17.40 skrev Matteo Lissandrini (AAU):
> My comment is the following:
>
> The real value proposition that none of the existing resources seems to have is the possibility to *integrate* multiple data sources.
> *Integrate* is complementary but very different from *aggregate*.
>
> Resources like :
> https://www.globallcadataaccess.org/
> are not dissimilar to
> https://datasetsearch.research.google.com/
>
> are aggregators of data. You can find a dataset, but then you are on your own in determining if the dataset contains the data you need, has the correct format, is coherent with your model, adapt it to your workflow, etc.
>
> What I see on GLAD (but I only read the homepage) seems more towards the *integration*, which is good, we should keep a close eye on that.
>
> I think the BONSAI with the Ontology and Mapping resources is a step ahead in the *integration* direction.
>
> I think the next step is documentation,  from LCA domain experts interested in integrating data (BONSAI)  for LCA domain expert interested in sharing data (all the providers).
> As we have a lot of tooling and work done and we just need to show people how to contribute.
> With more contribution we obtain more use-cases, we bullet-proof the workflow, and we improve.
>
> Yes, documentation is boring, and most of us don't feel are achieving anything if we are not writing code, calculating numbers, or running experiments.
> Yet, I see this as the crucial part for "lift-off", otherwise our space shuttle will always stay in the hangar redesigning the engine for N-th time but never turning it on.
>
>
> Best,
> 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 Benjamin W. Portner via groups.io <benjamin.portner=bauhaus-luftfahrt.net@groups.io>
> Sent: 23 June 2020 16:58:26
> To: main@bonsai.groups.io
> Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication
>
> My thoughts:
>
> - BONSAI and other projects (Electricity LCI<https://github.com/USEPA/ElectricityLCI>, US EEIO<https://github.com/USEPA/USEEIO> LCIA base data<https://github.com/USEPA/Federal-LCA-Commons-Elementary-Flow-List>, LCIA data formats<https://github.com/USEPA/LCIAformatter>, CDLCI project<https://www.pre-sustainability.com/news/harness-the-power-of-the-lca-community>, GLAD<https://www.unenvironment.org/explore-topics/resource-efficiency/what-we-do/life-cycle-initiative/global-lca-data-access-network>, IEDC<http://www.database.industrialecology.uni-freiburg.de>,...): I agree that it is hard to keep up with the numerous projects out there. We should definitely avoid reinventing the wheel. The question is: How? Adopting existing data, formats, etc. is good. But how can we do that if we don't know about them? Do we need some sort of "radar" for new projects and a "screening system" to filter out the portions of those projects, which are interesting for us?
>
> - Community engagement: I agree. I don't know if the existing BONSAI technology can help. Would be awesome if it could! If not, we need to find better ways to engage the community. Pré's LCAList is a good place to find advice but it is a poor place for collaboration. GitHub is a great place for collaboration but I don't think many people from the LCAList are there. I wonder if there is a way to bridge the gap between both communities.
>
> - BONSAI's 2nd work track: I was originally in favor of this idea but I lost momentum because I felt like support within BONSAI was weak. Furthermore, I feel like the release of GLAD made this the work track obsolete (although I might be wrong). I think there should be a new discussion about this.
>
> - Hackathon: I really regret that there is no in-person hackathon this year. For a newbie like me this would have presented a great opportunity to get to know everyone. Furthermore, I was planning to use it as an opportunity to get acquainted with the work previously done in BONSAI. I agree that an online hackathon is a poor substitute. But I think that an online hackathon is better than no hackathon :)
>
> That's it from me. Looking forward to hearing the results from the GA.
> Ben
>
>
>
>






--
Brandon Kuczenski, Ph.D.
Associate Researcher

University of California at Santa Barbara
Institute for Social, Behavioral, and Economic Research
Santa Barbara, CA 93106-5131

email: bkuczenski@...

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

Bo Weidema
 

I echo Matteo's comment :-)

Bo

Den 2020/06/23 kl. 17.40 skrev Matteo Lissandrini (AAU):

My comment is the following:

The real value proposition that none of the existing resources seems to have is the possibility to *integrate* multiple data sources.
*Integrate* is complementary but very different from *aggregate*.

Resources like :
https://www.globallcadataaccess.org/
are not dissimilar to
https://datasetsearch.research.google.com/

are aggregators of data. You can find a dataset, but then you are on your own in determining if the dataset contains the data you need, has the correct format, is coherent with your model, adapt it to your workflow, etc.

What I see on GLAD (but I only read the homepage) seems more towards the *integration*, which is good, we should keep a close eye on that.

I think the BONSAI with the Ontology and Mapping resources is a step ahead in the *integration* direction.

I think the next step is documentation, from LCA domain experts interested in integrating data (BONSAI) for LCA domain expert interested in sharing data (all the providers).
As we have a lot of tooling and work done and we just need to show people how to contribute.
With more contribution we obtain more use-cases, we bullet-proof the workflow, and we improve.

Yes, documentation is boring, and most of us don't feel are achieving anything if we are not writing code, calculating numbers, or running experiments.
Yet, I see this as the crucial part for "lift-off", otherwise our space shuttle will always stay in the hangar redesigning the engine for N-th time but never turning it on.


Best,
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 Benjamin W. Portner via groups.io <benjamin.portner=bauhaus-luftfahrt.net@groups.io>
Sent: 23 June 2020 16:58:26
To: main@bonsai.groups.io
Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

My thoughts:

- BONSAI and other projects (Electricity LCI<https://github.com/USEPA/ElectricityLCI>, US EEIO<https://github.com/USEPA/USEEIO> LCIA base data<https://github.com/USEPA/Federal-LCA-Commons-Elementary-Flow-List>, LCIA data formats<https://github.com/USEPA/LCIAformatter>, CDLCI project<https://www.pre-sustainability.com/news/harness-the-power-of-the-lca-community>, GLAD<https://www.unenvironment.org/explore-topics/resource-efficiency/what-we-do/life-cycle-initiative/global-lca-data-access-network>, IEDC<http://www.database.industrialecology.uni-freiburg.de>,...): I agree that it is hard to keep up with the numerous projects out there. We should definitely avoid reinventing the wheel. The question is: How? Adopting existing data, formats, etc. is good. But how can we do that if we don't know about them? Do we need some sort of "radar" for new projects and a "screening system" to filter out the portions of those projects, which are interesting for us?

- Community engagement: I agree. I don't know if the existing BONSAI technology can help. Would be awesome if it could! If not, we need to find better ways to engage the community. Pré's LCAList is a good place to find advice but it is a poor place for collaboration. GitHub is a great place for collaboration but I don't think many people from the LCAList are there. I wonder if there is a way to bridge the gap between both communities.

- BONSAI's 2nd work track: I was originally in favor of this idea but I lost momentum because I felt like support within BONSAI was weak. Furthermore, I feel like the release of GLAD made this the work track obsolete (although I might be wrong). I think there should be a new discussion about this.

- Hackathon: I really regret that there is no in-person hackathon this year. For a newbie like me this would have presented a great opportunity to get to know everyone. Furthermore, I was planning to use it as an opportunity to get acquainted with the work previously done in BONSAI. I agree that an online hackathon is a poor substitute. But I think that an online hackathon is better than no hackathon :)

That's it from me. Looking forward to hearing the results from the GA.
Ben


Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

Matteo Lissandrini (AAU)
 

My comment is the following:

The real value proposition that none of the existing resources seems to have is the possibility to *integrate* multiple data sources.
*Integrate* is complementary but very different from *aggregate*.

Resources like :
https://www.globallcadataaccess.org/
are not dissimilar to
https://datasetsearch.research.google.com/

are aggregators of data. You can find a dataset, but then you are on your own in determining if the dataset contains the data you need, has the correct format, is coherent with your model, adapt it to your workflow, etc.

What I see on GLAD (but I only read the homepage) seems more towards the *integration*, which is good, we should keep a close eye on that.

I think the BONSAI with the Ontology and Mapping resources is a step ahead in the *integration* direction.

I think the next step is documentation, from LCA domain experts interested in integrating data (BONSAI) for LCA domain expert interested in sharing data (all the providers).
As we have a lot of tooling and work done and we just need to show people how to contribute.
With more contribution we obtain more use-cases, we bullet-proof the workflow, and we improve.

Yes, documentation is boring, and most of us don't feel are achieving anything if we are not writing code, calculating numbers, or running experiments.
Yet, I see this as the crucial part for "lift-off", otherwise our space shuttle will always stay in the hangar redesigning the engine for N-th time but never turning it on.


Best,
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 Benjamin W. Portner via groups.io <benjamin.portner=bauhaus-luftfahrt.net@groups.io>
Sent: 23 June 2020 16:58:26
To: main@bonsai.groups.io
Subject: Re: [bonsai] Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

My thoughts:

- BONSAI and other projects (Electricity LCI<https://github.com/USEPA/ElectricityLCI>, US EEIO<https://github.com/USEPA/USEEIO> LCIA base data<https://github.com/USEPA/Federal-LCA-Commons-Elementary-Flow-List>, LCIA data formats<https://github.com/USEPA/LCIAformatter>, CDLCI project<https://www.pre-sustainability.com/news/harness-the-power-of-the-lca-community>, GLAD<https://www.unenvironment.org/explore-topics/resource-efficiency/what-we-do/life-cycle-initiative/global-lca-data-access-network>, IEDC<http://www.database.industrialecology.uni-freiburg.de>,...): I agree that it is hard to keep up with the numerous projects out there. We should definitely avoid reinventing the wheel. The question is: How? Adopting existing data, formats, etc. is good. But how can we do that if we don't know about them? Do we need some sort of "radar" for new projects and a "screening system" to filter out the portions of those projects, which are interesting for us?

- Community engagement: I agree. I don't know if the existing BONSAI technology can help. Would be awesome if it could! If not, we need to find better ways to engage the community. Pré's LCAList is a good place to find advice but it is a poor place for collaboration. GitHub is a great place for collaboration but I don't think many people from the LCAList are there. I wonder if there is a way to bridge the gap between both communities.

- BONSAI's 2nd work track: I was originally in favor of this idea but I lost momentum because I felt like support within BONSAI was weak. Furthermore, I feel like the release of GLAD made this the work track obsolete (although I might be wrong). I think there should be a new discussion about this.

- Hackathon: I really regret that there is no in-person hackathon this year. For a newbie like me this would have presented a great opportunity to get to know everyone. Furthermore, I was planning to use it as an opportunity to get acquainted with the work previously done in BONSAI. I agree that an online hackathon is a poor substitute. But I think that an online hackathon is better than no hackathon :)

That's it from me. Looking forward to hearing the results from the GA.
Ben

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

My thoughts:

- BONSAI and other projects (Electricity LCI, US EEIO LCIA base data, LCIA data formats, CDLCI project, GLAD, IEDC,...): I agree that it is hard to keep up with the numerous projects out there. We should definitely avoid reinventing the wheel. The question is: How? Adopting existing data, formats, etc. is good. But how can we do that if we don't know about them? Do we need some sort of "radar" for new projects and a "screening system" to filter out the portions of those projects, which are interesting for us?

- Community engagement: I agree. I don't know if the existing BONSAI technology can help. Would be awesome if it could! If not, we need to find better ways to engage the community. Pré's LCAList is a good place to find advice but it is a poor place for collaboration. GitHub is a great place for collaboration but I don't think many people from the LCAList are there. I wonder if there is a way to bridge the gap between both communities.

- BONSAI's 2nd work track: I was originally in favor of this idea but I lost momentum because I felt like support within BONSAI was weak. Furthermore, I feel like the release of GLAD made this the work track obsolete (although I might be wrong). I think there should be a new discussion about this.

- Hackathon: I really regret that there is no in-person hackathon this year. For a newbie like me this would have presented a great opportunity to get to know everyone. Furthermore, I was planning to use it as an opportunity to get acquainted with the work previously done in BONSAI. I agree that an online hackathon is a poor substitute. But I think that an online hackathon is better than no hackathon :)

That's it from me. Looking forward to hearing the results from the GA.
Ben

Re: Change branch name in GitHub #communication #project

 

+1 to waiting for consensus and tooling to make this trivial on existing repos.

I will make a proposal to switch to main as the default branch name to the GA, and post an update when a decision is made.

Re: Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

Here are my personal thoughts:

  • There is a lot of work being done in the USA by various federal agencies, coordinated by the US EPA and supported by GreenDelta. This includes reproducible inventory building (Electricity LCI, US EEIO), LCIA base data, and LCIA data formats and correspondence lists. It's difficult for me to keep up with all that is happening! In my opinion, BONSAI should support and benefit from all this activity - one clear way of doing this is to adopt data and data formats, instead of reinventing wheels.
  • PRé is (one of) the core initiators of the CDLCI project, which is trying to solve basically the same problem that BONSAI is (though through a different path). They are strong supporters of BONSAI, sponsored our 2019 hackathon, and have expressed strong interest in leveraging BONSAI in the future. They also see CDLCI as part of a data network, not as a stand alone project (see the attached slide). How can we benefit from this partner in an effective way, while preserving the BONSAI vision?
  • Similarly, UNEP is willing to sponsor and participate in a hackathon, as long as their work directly benefits GLAD.
  • There are a number of small problems where a little bit of work, combined with broad engagement from the community, could make everyone's life a lot easier. For example, at PSI we recently implemented ReCiPe 2016, which was incredibly painful, both in standardizing and correcting the names the ReCiPe team used, and in comparing our implementation with others. You can read the closed issues to see some colorful language. Is this an area where BONSAI ideas and already present technology could be applied?
I have no idea if it makes sense to try and hold an online hackathon - I see both sides here quite well. I am happy to follow the judgment of the community.

-Chris

Request for comment before BONSAI 2020 General Assembly #dataliberation #communication

 

Dear BONSAI community-

The 2020 general assembly will be held on Thursday, and is open to all paid members of BONSAI. Remember, active members qualify for a reduced enrollment rate of 50 - it isn't too late to sign up! Contact me personally for more info.

Before the GA, I would love to get some input from the broader community on where BONSAI is, what you think is realistic, and where you think BONSAI can be most effective. We had big plans for a funded hackathon before Corona shut everything down, and the energy of an in-person hackathon is difficult to reproduce online. Consequently, there hasn't been much forward movement on the BONSAI project as a whole (though if you follow the BONSAI churn email list you can see work continues: https://bonsai.groups.io/g/churn). Feel free to respond to this email with your thoughts, concerns, and ideas!

Yours,
Chris

Re: Change branch name in GitHub #communication #project

tomas Navarrete
 

1)
I saw that tweet from the current CEO Of Microsoft owned GitHub, and even CDNET seems to know from "internal sources" at github that it was not just a tweet. 
https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
2)
The rename is for every clone and fork out there, for every developper that has collaborated, and for all the CI / CD services (Travis, Jenkins) and targets (PyPi, Conda) ... they are downstream. For example, certain build and publish (python packages let's say) actions are only taken on specific branches. Some of them, like "features" or "develop" are never "built" or published to a repository. This is usually configured in the CI / CD files _inside_ the repositories. So It's also a matter of modifying the actual contents of the repositories, not only the name.
3) 
I agree, it will take 5 minutes to the person creating the repository, until github comes up with a new default branch name.

a) The actual instructions you point to are to change what is known as the default branch. This could as well be "release". Not directly related to a new default branch name. _But_ indeed, this shows that you can right now use github with a new default branch name.
b)  and c) look to me like the perfect recipe to complicate a world that was already not very easy. Let's face it, git has been known to be more complicated than mercurial for example. The fact that you can do so many cool things with git like "pre-commit" hooks, templates, worktrees and so on, comes at the price of complexity of the tool. So if I can stay with a regular "git init" in _any_ remote headless server I can work with, (or a git clone) instead of having to create a new template plus remember the new default branch name of the particular organization (inside github for example) I will do it that way.


For BONSAI, when we talk practical terms this means less than 35 repositories, so I suppose the 5 minutes for every potential bonsai contributor can be safely spent. Hey, maybe once github finds the right way to push this down, they'll even allow groups or organization for an automatic way to do it for all their projects (after all, a git -m is relatively fast on the server side). However, don't forget that this means every clone out there of our repos might need an update. 

In my personal daily experience  I deal with gitlab.com / github.com / bitbucket.com / local gitlab instances daily, and, clearly this will be not just 5 minutes once (like this week for example). It's going to be 5 minutes daily for a few weeks.

I suggest we wait until
+ github.com proposes:
  - a way to do it from the web interface that matches a github wide policy
  - a huge communication campaign that warns all github users (professional / free-lance / occasional / consultant developers,  community managers, savy tech users, scientific programmers, you-name-it) of the *name* of the new default branch
+ a consensus [on a sensitive new default name] emerges:
  - from the BONSAI community (General Assembly, we're looking at you)
  - also from the wider git users community in the world

.. and optionally it would be interesting to hear from this "2 hit-wonder" guy named Linus Torvalds, on how he is going to deal with it. Not that we should follow his own practices, because the python community ones seem a bit less tyrannic. 

To sum up, I'm not against it. All I say is that we can decide now to GO or NO-GO on a BONSAI wide level for the change of the current default branch of all our github repositories (because they are all hosted there, but they are all just "git" repositories), but before executing this, let's see how the wider world community handles the case.

cheers,



Re: Change branch name in GitHub #communication #project

Matteo Lissandrini (AAU)
 

Hi Tomas,

I think I can reassure you on practical issues:

1) so Github is already working on this: https://twitter.com/natfriedman/status/1271253144442253312?ref_src=twsrc%5Etfw

2) the rename is maybe an issue for existing local branches/forks/clones with active changes, which I would guess are at best a handful.

3) when we create a new repo on github, creating the appropriate branch and delete master is probably a matter of five minutes?


Instructions to change the default branch exist already:

a) On github: https://help.github.com/en/github/administering-a-repository/setting-the-default-branch

b) On local&github: https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx

c) automatically on new repos: https://superuser.com/a/1559582/762700

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 tomas Navarrete via groups.io <tomas.navarrete=list.lu@groups.io>
Sent: 17 June 2020 17:07:20
To: main@bonsai.groups.io
Subject: Re: [bonsai] Change branch name in GitHub #communication #project

Dear All,

I totally understand the reason behind the wish to change names.
Now, beware that:

The default branch name in Git is master.
git-scm.com/book<https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell#ch03-git-branching>

so, every time we create a new repo, or initialize one, we'll need to update this behavior (MAYBE until github does something about it ... which is funny, because they kind of have a dominating position in the "free git hosting" namespace ;) )

For very practical reasons, I would stand against renaming existing repositories and only apply a name change on newly created ones, and loudly anounce this in the README of the repo.
If this (default branch name) is configurable, then we should look to implement a name that is fine with us.

cheers,

Re: Change branch name in GitHub #communication #project

tomas Navarrete
 

Dear All,

I totally understand the reason behind the wish to change names.
Now, beware that:

The default branch name in Git is master.
git-scm.com/book

so, every time we create a new repo, or initialize one, we'll need to update this behavior (MAYBE until github does something about it ... which is funny, because they kind of have a dominating position in the "free git hosting" namespace ;) )

For very practical reasons, I would stand against renaming existing repositories and only apply a name change on newly created ones, and loudly anounce this in the README of the repo.
If this (default branch name) is configurable, then we should look to implement a name that is fine with us.

cheers,

Re: Change branch name in GitHub #communication #project

Søren
 

I agree; I think 'main' actually is more precise (master has the connotation of dominance, irrespectively of the imperialist etymology) 

Re: Change branch name in GitHub #communication #project

Matteo Lissandrini (AAU)
 

Thanks for the support Massimo!

To be honest me neither, but alas the fact that *we* don't do that association is quite at the core of the matter.
As you say, it is definitely not about what we mean but about other people being unduly hurt.

Best,
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=plan.aau.dk@groups.io>
Sent: 16 June 2020 09:44:02
To: main@bonsai.groups.io
Subject: Re: [bonsai] Change branch name in GitHub #communication #project

To be completely honest, I had never before this mail associated the word “master-branch” to the master/slave relationship. But I can see some can make this association and find the name inappropriate.

It is OK for me to change the branch name to “main” or similar.

Basically it does not cost us any effort, and if this can avoid other people feel bad then…why not.

Massimo

From: <main@bonsai.groups.io> on behalf of "Matteo Lissandrini (AAU) via groups.io" <matteo=cs.aau.dk@groups.io>
Reply-To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Tuesday, 16 June 2020 at 09.32
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: [bonsai] Change branch name in GitHub #communication #project

Hi all,
I would like to propose we change branch names in our github repositories away from `master`.

Here some more pointers about this proposal.

```
Language and words have a power and, unfortunately, some words and terminology we have historically used in technology (and in everyday conversation) are not neutral - they have an inadvertent and inherent ability to hurt some sections of our society.
```
https://dev.to/horus_kol/renaming-your-master-branch-2a37


```
Master-slave is an oppressive metaphor that will and should never become fully detached from history. Aside from being unprofessional and oppressive it stifles participation according to Eglash: “If the master-slave metaphor affected these tough-minded engineers who had the gumption to make it through a technical career back in the days when they may have been the only black persons in their classes, what impact might it have on black students who are debating whether or not to enter science and technology careers at all?”
```
https://tools.ietf.org/id/draft-knodel-terminology-00.html


I believe is in everybody's interest to move to a more inclusive language.

Best,
Matteo