Date   

Re: #ontology Can we come up with a better term than "Flow Object"? #ontology

Bo Weidema
 

The important issue is to distinguish between the observation of a specific flow (e.g. 22 kg input of steel) and the abstract flow-object ("steel"). This distinction was not made clear in e.g. ecospold schema where the exchange = flow and the abstract flow-object is simply called "intermediateExchangeId" or "elementaryExchangeId" referring to a taxonomy of "master data".

I do not think it makes much difference if we call it flow-object or flow-item, so if there is a preference for the latter that would be OK with me. Exchange has the problem that it is easily confused with a market operation (e.g. currency exchange). So I think "flow" is still the best option, as this is either an input or an output.

Bo


Re: #ontology Can we come up with a better term than "Flow Object"? #ontology

Matteo Lissandrini (AAU)
 

Hi all,
like John Snow, I know nothing.

From an outsider perspective the current definition is extremely clear, as it related the Flow and the Object of the Flow (aka Flow Object).

While all other proposal are much more confusing (Flow and Exchange are two dynamic terms)

The only other words I can thing of would be Phenomenon for the Flow and Noumenon for the Flow Object, but I guess bothering  Kant is not a great idea :)

I suggest somebody creates a BEP then :)

Cheers,
Matteo










From: main@bonsai.groups.io [main@bonsai.groups.io] on behalf of Rutger Schurgers via Groups.Io [schurgers@...]
Sent: Wednesday, April 03, 2019 11:57 AM
To: main@bonsai.groups.io
Subject: Re: [bonsai] #ontology Can we come up with a better term than "Flow Object"?

Hi group,

 

Exchange is actually what’s being used in the ecospold2 and ILCD data formats as well. They have flows as well, though they include compartment too. In the SimaPro platform, we don’t include compartments so that matches what we have in Bonsai. To keep things consistent, I’d support using these terms. We don’t use the term exchange in the platform, but I’m considering adopting it as well. The different terms we’re using now cause a lot of confusion and time lost.

 

Regards,

 

Rutger

 

From: main@bonsai.groups.io [mailto:main@bonsai.groups.io] On Behalf Of Agneta
Sent: 03 April 2019 11:37
To: main@bonsai.groups.io
Subject: Re: [bonsai] #ontology Can we come up with a better term than "Flow Object"?

 

So the issue is back!

Well I did raise the point about terms like flow and 'flow object' being confusing and likely that someone new to the ontology might have some difficulty in understanding the differences or even use them interchangeably. I looked up the thesaurus and unfortunately I don't think there is anything that sufficiently translates 'object'/'thing'/'entity'. Some suggested words were- 'element', 'substance, 'item' , 'component'.  

In my humble opinion- I would like to go back to suggestions as defined in previously published LCA ontology (Kuczenski et al. 2016):

Activity- is a “thing that happens”

Flow- is a “thing in the world that exists because of some instance of an Activity."

Exchange- " An exchange is an established relationship between an activity instance and a flow instance." This can be an input/output/ determining.

 

I think this terminology is coherent with the vocabulary used by most industrial ecologist.

There is another term that I find slightly problematic is 'Balanceable properties' . As this class primarily consists of certain specific quantities, I was wondering if we could refer to it as 'quantity types' or 'quantity attributes' ?

I will also put this discussion as an issue in out GitHub repo. 


Re: Vote for BEP-0001 #bep0001 #poll

Matteo Lissandrini (AAU)
 

Hi all,
the BEP seems fine to me.

I have only 2 comments:
- I would have preferred it to be called "BEP000" for vanity reasons :)
- I think each future BEP should include a link to the rules in participating to a BEP discussion


Re: #ontology Can we come up with a better term than "Flow Object"? #ontology

Rutger Schurgers
 

Hi group,

 

Exchange is actually what’s being used in the ecospold2 and ILCD data formats as well. They have flows as well, though they include compartment too. In the SimaPro platform, we don’t include compartments so that matches what we have in Bonsai. To keep things consistent, I’d support using these terms. We don’t use the term exchange in the platform, but I’m considering adopting it as well. The different terms we’re using now cause a lot of confusion and time lost.

 

Regards,

 

Rutger

 

From: main@bonsai.groups.io [mailto:main@bonsai.groups.io] On Behalf Of Agneta
Sent: 03 April 2019 11:37
To: main@bonsai.groups.io
Subject: Re: [bonsai] #ontology Can we come up with a better term than "Flow Object"?

 

So the issue is back!

Well I did raise the point about terms like flow and 'flow object' being confusing and likely that someone new to the ontology might have some difficulty in understanding the differences or even use them interchangeably. I looked up the thesaurus and unfortunately I don't think there is anything that sufficiently translates 'object'/'thing'/'entity'. Some suggested words were- 'element', 'substance, 'item' , 'component'.  

In my humble opinion- I would like to go back to suggestions as defined in previously published LCA ontology (Kuczenski et al. 2016):

Activity- is a “thing that happens”

Flow- is a “thing in the world that exists because of some instance of an Activity."

Exchange- " An exchange is an established relationship between an activity instance and a flow instance." This can be an input/output/ determining.

 

I think this terminology is coherent with the vocabulary used by most industrial ecologist.

There is another term that I find slightly problematic is 'Balanceable properties' . As this class primarily consists of certain specific quantities, I was wondering if we could refer to it as 'quantity types' or 'quantity attributes' ?

I will also put this discussion as an issue in out GitHub repo. 


Re: #ontology Can we come up with a better term than "Flow Object"? #ontology

Agneta
 

So the issue is back!

Well I did raise the point about terms like flow and 'flow object' being confusing and likely that someone new to the ontology might have some difficulty in understanding the differences or even use them interchangeably. I looked up the thesaurus and unfortunately I don't think there is anything that sufficiently translates 'object'/'thing'/'entity'. Some suggested words were- 'element', 'substance, 'item' , 'component'.  

In my humble opinion- I would like to go back to suggestions as defined in previously published LCA ontology (Kuczenski et al. 2016):

Activity- is a “thing that happens”

Flow- is a “thing in the world that exists because of some instance of an Activity."

Exchange- " An exchange is an established relationship between an activity instance and a flow instance." This can be an input/output/ determining.

 

I think this terminology is coherent with the vocabulary used by most industrial ecologist.

There is another term that I find slightly problematic is 'Balanceable properties' . As this class primarily consists of certain specific quantities, I was wondering if we could refer to it as 'quantity types' or 'quantity attributes' ?

I will also put this discussion as an issue in out GitHub repo. 


#ontology Can we come up with a better term than "Flow Object"? #ontology

 

Not trying to start a flame war or anything, but "flow object" is just... not great. It is inconsistent with all our other core terms, it rolls off the tongue like a porcupine, and I guarantee you that it will produce a confused look on 80% of the faces of people who see it for the first time.

The problem is that "flow" is good, but has no natural counterpart (aside from "flow"...). One possibility would be to switch to "flow" and "exchange" - I am sure this was considered and rejected at some point, however. We define "flow object" as:
Entity that is able to be exchanged between two activities, produced or consumed by activities, or stored by a (stock accumulation) activity. This is one of the identifying dimensions of a datapoint (and the database).
"Entity" is probably too loose, as is "object". "Flux" is a bit too cute, and too similar to "flow." What about "item"? It encapsulates the idea that every thing we want to track would be an item instance. One definition is "an individual article or unit, especially one that is part of a list, collection, or set," which fits pretty well. Or maybe someone else has a creative idea? There are lots of online thesaurus sites out there :)

If there is previous discussion on this, please post links - it is hard to get much from the wiki history.


Vote for BEP-0001 #bep0001 #poll

Michele De Rosa
 

Dear all, 

it is time to vote for the BEP-0001 (BONSAI Enhancement Proposal Template):

  • The proposal has been standing for a month.
  • The proposed template has already been used for other BEPs.
  • No major comments and/or modifications were submitted during the last 3 weeks.

Ballot question:
Do you accept the BEP-0001 (BONSAI Enhancement Proposal Template)?

The vote will be open until 17th of April 6pm CET. Results will be announced as soon as a valid majority is reached, thus earlier than the 17th if possible. 

The voting procedure is described in the following voting procedure 

Michele

Results

See Who Responded


Re: BEP-0004 BONSAI knowledge management and communication strategy | open for discussion / seeking editor

Michele De Rosa
 

Thanks Tom. Just a few update that should be in the text of the BEP:

  • the google drive has been removed and the file added to an Archive section of bonsai.uno as agreed. That bullet point could be removed.
  • Bonsai.uno includes now explicit references and links to the github, its wiki and the discussion list homepage. The "contribute" and "become a member" sections have also been updated as agreed before.
Michele


Re: BEP-0004 BONSAI knowledge management and communication strategy | open for discussion / seeking editor

 

Thanks Tom, this is really exciting!

I would like to remind people of the process around BEPs. The BEP is a draft, meaning that it is still under development. It doesn't need an editor yet. The "working group" for this BEP is everyone, as we need your input to make sure that this plan seems reasonable. However, please do not edit the BEP directly (unless you are Tom) - instead, either respond to this email with suggestions and comments, or fork the repo, make some changes, and submit a pull request that Tom will merge.

Some comments on the proposal itself:

  1. There are some cases where an active voice is needed, as this would be the ruleset. E.g. "It is proposed that no other new mediums should be created without advanced discussion" should be "No other ...".
  2. We are already building web apps for the hackathon as subdomains of bonsai.uno, e.g. https://hackathon.bonsai.uno/.
  3. "Proposed action (in addition to these):" - the link is broken. Maybe it is simpler just to list the additional actions.
  4. "The Mailing List" section - I think we should be clearer here that the mailing list of for conceptual discussion, in addition to areas where a consensus needs to be found (both within the working group, but also places where useful outputs could be obtained from the broader community), while issues are for project management and technical implementation.
  5. "apporpriate"
  6. "This issue" - Let's list the issue name
  7. Testing plad should be two-fold, the first phase being at the hackathon with its participants, the second being outside observers who are vaguely familiar with BONSAI, e.g. Xioajin Zhang, Oleg Lavrovsky.


BEP-0004 BONSAI knowledge management and communication strategy | open for discussion / seeking editor

Tom
 


Feel free to reply here.

Kind regards,
Tom


Re: #BEP0001 - Community governance through enhancement proposals #bep0001

Michele De Rosa
 

FYI: An improved version of the text above has been merged to the original text (see here).


Re: A new #project board to visualize #project #issues

Michele De Rosa
 

Correct. My opinion is that the project board should be under the "Main" Bonsai directory because:

  • it is becoming increasingly hard to figure what has been posted where; it will become even more so when the resources increase. Thus, a "root" folder with the project board would be welcome.
  • several projects may concern the hackathon as much as the longer term Bonsai goals and some of the sub-groups for the hackathon too. In these cases, under which directory should the project item be listed? Under the sub-group directories, the hackathon directory or the Bonsai directory?
  • some of the sub-groups have some dependencies. It would be an advantage to have a common directory that we will all have to access to find the project board, regardless of the sub-group we contribute to. 
  • the project board should have links to the tasks described in the wiki, which is un the Bonsai directory
PS: the name of the root GitHub, BONASMURAI (instead of BONSAI), is due to the fact that the latter name was taken.

Michele


Re: A new #project board to visualize #project #issues

Massimo Pizzol
 

>So the question is to know what the repository "bonsai" should really be about...

I have filed an issue in that repo that is precisely about this problem, I.e making a more clear read me about that the bonsai repo should be used for and reorganize the files and code into folders


Re: A new #project board to visualize #project #issues

romain
 

The issue though with moving the Project board to the first level (BONSAMURAIS), is that BONSAMURAIS is not really a repo in itself (it's more a like front page) and hence, and one cannot create Issues within it, it seems. It's a bit annoying. We can make a project board and populate it with Issues, but those Issues have to remain in one of the repos (e.g., bonsai). So the question is to know what the repository "bonsai" should really be about...


Re: A new #project board to visualize #project #issues

romain
 

OK then, we'll try to move that to the first level.

/romain


Re: A new #project board to visualize #project #issues

Massimo Pizzol
 

I second Chris’s suggestion to have the “High-level tasks, long run” project board as a project of the entire BONSAMURAIS organization (not in the “bonsai” repository).

In general, good idea to use project boards to organize issues, very nice feature.

BR
Massimo

 


Re: 2019 General Assembly

 

The BONSAI 2019 General Assembly will be held on Wednesday, May 8, from 17:00 to 18:00 Central European Time.

Participation in the General Assembly requires membership in the BONSAI non profit association, which costs
€150 a year, or €50 for active BONSAI participants. Members will receive a separate email with conference details.

You might also be interested in a few other BONSAI governance changes, which are detailed at the end of https://chris.mutel.org/bonsai-governance.html, as well as the BONSAI statutes: https://bonsai.uno/files/statutes.pdf.


Re: A new #project board to visualize #project #issues

 

Depending on the output of the communication plan, it might make sense to have this project board not be attached the "bonsai" repository, but for the entire BONSAMURAIS organization, i.e. here: https://github.com/orgs/BONSAMURAIS/projects/2. This would allow you to directly link issues from all the different repos, and would allow the "bonsai" repo to become more tailored to just the wiki (if that is what is proposed).


Re: A new #project board to visualize #project #issues

 

This looks great.

Perhaps we could modify the boards to be more reflective of BONSAI
stages? For example, I think we need something like "Concept-building"
for the tasks text mining and data scraping, as "to do" might mean
projects that are ready for execution, but don't have have volunteers
yet. Similarly, our review process (at least for now) is the BEP, so
instead of "needs review", we could have "proposed", drop "reviewer
approved", and change "done" to "accepted".

On Wed, 13 Mar 2019 at 10:16, romain via Groups.Io <r_s=me.com@groups.io> wrote:

Hello,

with Tom, we would like to suggest the use of Issues, Labels and the more general Project board features of GitHub to better visualize the long-term tasks described in the Wiki and benefit from the functionalities they provide (discussion, level of completion, assigning workforce, etc.).

This would allow us to quickly see who volunteers for which tasks, the priority level, etc., and hopefully better understand the work to be done and how far we've come.
Also, I find it particularly convenient for discussing and exchanging ideas within a given task.

As a try out, we've populated the Issues section with a few items (high-level tasks, as described in the Wiki), associated labels and milestones to them. Labels and milestones are jsut tehre for "illustration purpose" and we need to refine them, should we agree to manage tasks that way. You can them see then in the Projects tab within the BONSASAMURAIS/bonsai repo, divided in "to do", "in progress", "to be reviewed" and "done" categories. You can also filter out the tasks to be displayed on that board (should there be too many of them) by label (priority labels, for example).

Issues: https://github.com/BONSAMURAIS/bonsai/issues
Project board: https://github.com/BONSAMURAIS/bonsai/projects/2

Let us know what you think and we'll complete it further.

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


A new #project board to visualize #project #issues

romain
 

Hello,

with Tom, we would like to suggest the use of Issues, Labels and the more general Project board features of GitHub to better visualize the long-term tasks described in the Wiki and benefit from the functionalities they provide (discussion, level of completion, assigning workforce, etc.).

This would allow us to quickly see who volunteers for which tasks, the priority level, etc., and hopefully better understand the work to be done and how far we've come.
Also, I find it particularly convenient for discussing and exchanging ideas within a given task.

As a try out, we've populated the Issues section with a few items (high-level tasks, as described in the Wiki), associated labels and milestones to them. Labels and milestones are jsut tehre for "illustration purpose" and we need to refine them, should we agree to manage tasks that way. You can them see then in the Projects tab within the BONSASAMURAIS/bonsai repo, divided in "to do", "in progress", "to be reviewed" and "done" categories. You can also filter out the tasks to be displayed on that board (should there be too many of them) by label (priority labels, for example).

Issues: https://github.com/BONSAMURAIS/bonsai/issues
Project board: https://github.com/BONSAMURAIS/bonsai/projects/2

Let us know what you think and we'll complete it further.

/romain