Date   

Re: Start of the #ontology sub-group #ontology

Agneta
 

Thanks Matteo for bringing the discussion to the platform.

My questions in relation to the schema and our discussions on friday are: 

1.  I personally find the terms ‘Flow’ and ‘Flow object’ interchangeable and hence confusing. Is there a consensus on the use of ‘Flow object’ instead of ‘Flow’? I would need some clarity on this.

2.   I don’t understand why  Input and Output should be separate subclasses of a flow? Instead I would think of this as a flow property, in which the flow instances are input and output. After all every flow is either an output or an input. Similarly reference flow is also a flow property, not a subClass.

3.  To follow up the question on adding an ‘Agent’ to the existing schema. An ‘Agent’ is defined as ‘one who performs the activity’. For example – Coal power plant (agent) generates electricity (activity). This adds the advantage for defining stocks, as an agent usually invests on stocks such as infrastructure or machinery. So in my understanding we need to add Agent as another class. Ofcourse the agent has properties like – location

So I envision the simple schema to have 3 main classes- Agent (performs activities), Activity (has flows) and Flows. Each of these classes have one of many properties.

 

4.   4. Then again I feel that our schema is pretty similar to the schema published by (Janowicz et al.) , without ofcourse some objects such as intermediate or elementary flows. The novelty of the new schema is not entirely clear to me. 

Cheers
Agneta


 


Re: Start of the #ontology sub-group #ontology

 

On Mon, 11 Mar 2019 at 14:14, Agneta <agneta.20@gmail.com> wrote:
1. I personally find the terms ‘Flow’ and ‘Flow object’ interchangeable and hence confusing. Is there a consensus on the use of ‘Flow object’ instead of ‘Flow’? I would need some clarity on this.
The problem is that "flow" can be a verb or a noun - we want to make
sure people use it as a noun, hence "object."

2. I don’t understand why Input and Output should be separate subclasses of a flow? Instead I would think of this as a flow property, in which the flow instances are input and output. After all every flow is either an output or an input. Similarly reference flow is also a flow property, not a subClass.
+1

3. To follow up the question on adding an ‘Agent’ to the existing schema. An ‘Agent’ is defined as ‘one who performs the activity’. For example – Coal power plant (agent) generates electricity (activity). This adds the advantage for defining stocks, as an agent usually invests on stocks such as infrastructure or machinery. So in my understanding we need to add Agent as another class. Ofcourse the agent has properties like – location
The working example should have a model of how we can store data
related to the coal plant (e.g. capacity, year built), as well as the
operator of the coal plant, which is what I would have thought of when
I hear the term "agent."


Re: Start of the #ontology sub-group #ontology

Bo Weidema
 

Den 2019-03-11 kl. 14.14 skrev Agneta:

1.  I personally find the terms ‘Flow’ and ‘Flow object’ interchangeable and hence confusing. Is there a consensus on the use of ‘Flow object’ instead of ‘Flow’? I would need some clarity on this.

The flow-object is the "thing" that can flow, e.g. "steel". The flow is the instance of a flow-object flowing in or out of an activity, e.g. "23 kg of steel output from steel mill X".

2.   I don’t understand why  Input and Output should be separate subclasses of a flow? Instead I would think of this as a flow property, in which the flow instances are input and output. After all every flow is either an output or an input. Similarly reference flow is also a flow property, not a subClass.

Correct!

3.  To follow up the question on adding an ‘Agent’ to the existing schema. An ‘Agent’ is defined as ‘one who performs the activity’. For example – Coal power plant (agent) generates electricity (activity). This adds the advantage for defining stocks, as an agent usually invests on stocks such as infrastructure or machinery. So in my understanding we need to add Agent as another class. Ofcourse the agent has properties like – location

Fine!

So I envision the simple schema to have 3 main classes- Agent (performs activities), Activity (has flows) and Flows. Each of these classes have one of many properties.

Some properties can also be classified. Especially important are the balanceable properties (dry mass, water mass, monetary value, time, ...)

4. Then again I feel that our schema is pretty similar to the schema published by (Janowicz et al.) , without ofcourse some objects such as intermediate or elementary flows. The novelty of the new schema is not entirely clear to me.

It does not have to be new! As long as it is precise :-) and does what we want it to!

Cheers

Bo


Re: Start of the #ontology sub-group #ontology

Bo Weidema
 

Den 2019-03-11 kl. 14.09 skrev Massimo Pizzol:


  1. Why do we separate between two subclass “input” and “output” when we have already the two relations: “b:isInputOf” and “b:IsOutputof”? I mean, “inputs” are always “inputs of” something so… In other words:  why don’t we link directly the “activity” and “flow” classes instead of linking them only indirectly via the “input/output” subclasses?

Good point. No need for separate subclasses, as also Agneta pointed out. It is just an input relation or an output relation of a flow-object in a specific activity context.

  1. How do environmental exchanges fit this scheme.? For example how is the emission of carbon dioxide as output from the steel production represented in this framework? Would we need a different class called, say, “environmental” that is linked to the “flow” class (in the same was the current “product” class is) or would environmental exchanges just be a different instance of the “product” class?

Environmental exchanges are also just flows (or flow-objects). CO2 can both be an emission to the environment and a (by-)product, but as a chemical it is the same. For this reason, it may be reasonable to distinguish between "carbon dioxide (product)" and "carbon dioxide (emission)". Whether that is best done by creating "product" and "emission" as sub-classes of flow-objects or just as properties, I am not completely sure. The general idea is not to be too specific if it can be avoided which would be an argument for the latter (property) option, but on the other hand the sub-calss option makes in clear that the "carbon dioxide" is placed in one or the other class. Any views on this?

Bo


Re: Start of the #ontology sub-group #ontology

Bo Weidema
 

Den 2019-03-11 kl. 12.42 skrev Matteo Lissandrini (AAU):

- Regarding PROV-O i have the impression that this is not appropriate. The ontology, as I understand it, is designed to describe 'provenance' in the sense of Data Lineage [7], so I think there would be a semantic mismatch.
Is there a semantic difference of the input of data and the input of a physical "thing"?

Note also that there are example use cases that are currently not well addressed by my draft, e.g., storage of goods.
We may need to distinguish between "stock" as an activity (having inputs and outputs over a specified period) for use in a transactions matrix and "stock" as the amount stored at a specific point in time for use in a balance sheet.

I'm also not sure about the class name "ReferenceFlow", the way I understood it is probably better described by "ReferenceOutput" ?
A reference flow does not need to be an output. It can also be an input, e.g. a waste or by-product for disposal or recycling.

Best regards

Bo


Re: Start of the #ontology sub-group #ontology

Massimo Pizzol
 

>>>Environmental exchanges are also just flows (or flow-objects). CO2 can both be an emission to the environment and a (by-)product, but as a chemical it is the same. For this reason, it may be reasonable to distinguish between "carbon dioxide (product)" and "carbon dioxide (emission)". Whether that is best done by creating "product" and "emission" as sub-classes of flow-objects or just as properties, I am not completely sure. The general idea is not to be too specific if it can be avoided which would be an argument for the latter (property) option, but on the other hand the sub-calss option makes in clear that the "carbon dioxide" is placed in one or the other class. Any views on this?

  • “Minimalist” solution:  We could remove the class “product” and add the rdfs:label property to the class “flow”.  So everything is a flow.  Pro: total flexibility. Contra: how do we then distinguish the flows from which we will build a tech matrix A and those from which we will build a intervention matrix B (that will be associated with a characterisation factor)? Not sure.
  • “Classic” solution: we could add another class “Substance” that works as the current class “product” but is only for only for environmental exchanges and is therefore linked to the class “flow” via the property “b:ofsubstance”. Pro: similar to current LCA framework (A and B matrices). Contra: limits us if we want to make models that feedback-loop between technosphere and biosphere.

 

Not sure how subclasses work honeslty.

 

BR
Massimo

 


Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#84) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Mute #ontology
Your Subscription | Contact Group Owner | Unsubscribe [massimo@...]

_._,_._,_


Re: Start of the #ontology sub-group #ontology

Michele De Rosa
 

On the topic bu also as a general comment - I would suggest to distinguish them not only to make clear that the "Carbon dioxide" is an emission (in the example made) but also to make more intuitive for users (LCA and beyond). 

The Contra of the "Classic solution" may also be easier to address.

Ultimately, we want the ontology to be user-friendly both to avoid confusions and to make the BONSAI solutions spread fast.

Similarly, referring to the earlier posts, couldn't we refer to the "Flow-object" as a "Flowing-object" or something like that, easier to grasp for who isn't an insider?

Michele


Re: Start of the #ontology sub-group #ontology

Matteo Lissandrini (AAU)
 

About why do we separate between two subclass "input" and "output", here is my reasoning.
On the one hand this is at the ontology level to restrict the domain of the input and output relationships.
Assume you are looking at a specific instance of a 10tonnes of coal in your database, then you ask yourself "is this an input for something or an output of something?" for sure you could find the answer by checking  "is this the source of inputOf relationships?",
but operationally you can ask "what is the type of this?" and in my view this would be the correct way to do this because something is either input or output.

It was also because my understanding was that only an output would be a "reference flow", so now I understand this is not true.
What is the utility and the actual definition of a "reference flow"?
The existence of the reference flow to be both input and output makes things a little bit more complex.

Regarding provenance, yes, the concept is extremely loaded of semantics in the field, I'm really sure we do not want to use that.
We will use that ontology instead when we will describe, for instance, that the data produced is coming from the exiobase dataset.
There we really want to use that  ontology.

The naming: the names of the classes may be not appropriate, here the instances of flow describe the tangibile things that get consumed/produced by the execution of an activty,
the instances of an activity are exactly that specific happening of the process in that place/time.

In general, we do not want, at all costs, to distinguish flows/activity types by using the "label", labels are hints for humans, but URI, classes and instances, are what provides an identity to things.


Re: Start of the #ontology sub-group #ontology

Bo Weidema
 

Den 2019-03-11 kl. 16.22 skrev Matteo Lissandrini (AAU):

What is the utility and the actual definition of a "reference flow"?
The more semantically precise term is actually "determining flow".

The definition is: "Flow of an activity for which a change will affect the production volume of the activity"

The utility is to be able to distinguish the flow that drives (causes) the activity from flows that are caused by the activity.

Regarding provenance, yes, the concept is extremely loaded of semantics in the field, I'm really sure we do not want to use that.
OK. Argument accepted.

Bo


Re: Start of the #ontology sub-group #ontology

Matteo Lissandrini (AAU)
 

What is the utility and the actual definition of a "reference flow"?
The more semantically precise term is actually "determining flow".
The definition is: "Flow of an activity for which a change will affect
the production volume of the activity"

The utility is to be able to distinguish the flow that drives (causes)
the activity from flows that are caused by the activity.

Now I see,
so, as you suggested earlier, a waste can be the determining flow as input of a waste disposal activity that produces something else, because we need to dispose of this waste.

Is this correct?


Thanks a lot for the clarification.

Matteo




---
Matteo Lissandrini

Department of Computer Science
Aalborg University

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


Re: Start of the #ontology sub-group #ontology

Massimo Pizzol
 

(Disclaimer: I am simplifying things a bit here I hope the LCA people will forgive me)

Dear Matteo

I believe you have understood how it works, but there are some other details that perhaps you should know. Examples: If an activity produces electricity from burning coal, the determining flow is the product output flow ‘electricity’. If an activity produces simultaneously electricity AND heat from coal, then either electricity OR heat will be the determining flow. Waste example: You described an activity that converts waste into something else. For example this could be incinerating municipal solid waste to generate electricity. In this case the ‘treatment of municipal solid waste’ is the determining product output flow of the ‘waste incineration’ activity that has also another product output flow of ‘electricity’. Electricity is not the determining flow here because as you rightly concluded we burn  waste because we want to get rid of it (or in other words: we don’t produce more waste just because we want more electricity...).

Summing up:
- the determining flow is always a product output flow
- activities can have multiple product output flows, but
- there is only one determining flow per each activity
- ‘product’ is a generic term that includes both ‘goods’ (e.g. coal) and ‘services’ (e.g. treatment of waste)

Now the confusing thing here is that ‘waste treatment’ is a product flow (a service in fact) but *sounds* like an activity. Same with ‘transport’. So the next question for the LCA people in this thread is: how are we going to represent waste flows in the schema? My only reference for names is ecoinvent but I don’t think that is really super understandable (my students generally have a hard time understanding them, for example)

Massimo




On 11 Mar 2019, at 16.51, Matteo Lissandrini (AAU) via Groups.Io <matteo@...> wrote:

What is the utility and the actual definition of a "reference flow"?

The more semantically precise term is actually "determining flow".

The definition is: "Flow of an activity for which a change will affect
the production volume of the activity"

The utility is to be able to distinguish the flow that drives (causes)
the activity from flows that are caused by the activity.

Now I see,
so, as you suggested earlier, a waste can be the determining flow as input of a waste disposal activity that produces something else, because we need to dispose of this waste.

Is this correct?


Thanks a lot for the clarification.

Matteo




---
Matteo Lissandrini

Department of Computer Science
Aalborg University

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









Re: Start of the #ontology sub-group #ontology

Matteo Lissandrini (AAU)
 

Thanks Massimo,
now I would like to get a consensus from you and the other domain experts about the following statement you wrote:

- the determining flow is always a product _output_ flow

If this is true, then we have that Flow has two sub classes Input / Output, and Output has a the subclass Determining Flow, and there will be exactly one instance of Determining Flow associated with each activity in the database.

Is there in any dataset you have at hand, a case where this is not true?

*) names are provisional



From: hackathon2019@bonsai.groups.io [hackathon2019@bonsai.groups.io] on behalf of Massimo Pizzol via Groups.Io [massimo@...]
Sent: Monday, March 11, 2019 8:33 PM
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] Start of the #ontology sub-group #RDFFramework #ontology

(Disclaimer: I am simplifying things a bit here I hope the LCA people will forgive me)

Dear Matteo

I believe you have understood how it works, but there are some other details that perhaps you should know. Examples: If an activity produces electricity from burning coal, the determining flow is the product output flow ‘electricity’. If an activity produces simultaneously electricity AND heat from coal, then either electricity OR heat will be the determining flow. Waste example: You described an activity that converts waste into something else. For example this could be incinerating municipal solid waste to generate electricity. In this case the ‘treatment of municipal solid waste’ is the determining product output flow of the ‘waste incineration’ activity that has also another product output flow of ‘electricity’. Electricity is not the determining flow here because as you rightly concluded we burn  waste because we want to get rid of it (or in other words: we don’t produce more waste just because we want more electricity...).

Summing up:
- the determining flow is always a product output flow
- activities can have multiple product output flows, but
- there is only one determining flow per each activity
- ‘product’ is a generic term that includes both ‘goods’ (e.g. coal) and ‘services’ (e.g. treatment of waste)

Now the confusing thing here is that ‘waste treatment’ is a product flow (a service in fact) but *sounds* like an activity. Same with ‘transport’. So the next question for the LCA people in this thread is: how are we going to represent waste flows in the schema? My only reference for names is ecoinvent but I don’t think that is really super understandable (my students generally have a hard time understanding them, for example)

Massimo




On 11 Mar 2019, at 16.51, Matteo Lissandrini (AAU) via Groups.Io <matteo@...> wrote:

What is the utility and the actual definition of a "reference flow"?

The more semantically precise term is actually "determining flow".

The definition is: "Flow of an activity for which a change will affect
the production volume of the activity"

The utility is to be able to distinguish the flow that drives (causes)
the activity from flows that are caused by the activity.

Now I see,
so, as you suggested earlier, a waste can be the determining flow as input of a waste disposal activity that produces something else, because we need to dispose of this waste.

Is this correct?


Thanks a lot for the clarification.

Matteo




---
Matteo Lissandrini

Department of Computer Science
Aalborg University

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









Re: Start of the #ontology sub-group #ontology

 

I think it would be a mistake to bake too many restrictions into the
general framework. There is a certain mental model that prevails in
LCA, but we don't want BONSAI to accept these restrictions at the
beginning unless they are absolutely necessary, and BONSAI is not just
for LCA (e.g. should also be useful for MFA). For now it might be
worth skipping the determining flow completely, as it doesn't seem
necessary for the hackathon.

Determining flows are not always outputs, treatment of waste by
landfill has waste as a determining flow input.


Re: Start of the #ontology sub-group #ontology

Massimo Pizzol
 

Chris is right that one can use a negative (= input) reference flow. I just never use this approach and I forgot, my mistake.

I don’t see how we can skip the reference flow concept though if we are going to work with LCA data (deliverable 2 and 3).

Massimo

From: <hackathon2019@bonsai.groups.io> on behalf of "Chris Mutel via Groups.Io" <cmutel@...>
Reply-To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Date: Monday, 11 March 2019 at 22.32
To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Subject: Re: [hackathon2019] Start of the #ontology sub-group #RDFFramework #ontology

 

I think it would be a mistake to bake too many restrictions into the

general framework. There is a certain mental model that prevails in

LCA, but we don't want BONSAI to accept these restrictions at the

beginning unless they are absolutely necessary, and BONSAI is not just

for LCA (e.g. should also be useful for MFA). For now it might be

worth skipping the determining flow completely, as it doesn't seem

necessary for the hackathon.

 

Determining flows are not always outputs, treatment of waste by

landfill has waste as a determining flow input.

 

 

 


Re: Start of the #ontology sub-group #ontology

Bo Weidema
 

Den 2019-03-11 kl. 22.31 skrev Chris Mutel:

For now it might be worth skipping the determining flow completely, as it doesn't seem necessary for the hackathon.
Not having this concept will mean a loss of information when importing from e.g. EXIObase or ecoinvent.

Bo


Re: Start of the #ontology sub-group #ontology

Michele De Rosa
 

Good point Massimo. In Fact, the output flow of the activity "Waste Incineration" should be "TREATED municipal solid waste" and not "Treatment of municipal solid waste"
Michele


Re: Start of the #ontology sub-group #ontology

 

Dear all-

I very much appreciate the work and active participation of people in
this working group! Unfortunately, I must make your lives a little bit
harder :)

1. The final proposal should include not just what you have found
consensus on, but also the alternatives you have considered, and why
they were not chosen. This has two purposes: to stop people from
bringing up the same issues over and over again, and to communicate
that you made informed decisions.

So, for example, when we debate over the modelling of waste treatment,
we should be drawing simple models of each possibility, and then
discussing the practical effects of these models. I don't think it is
sufficient (certainly not in the long term, maybe for the hackathon)
to just assert that it works like this, because I know/am smart and
have thought about it.

2. While I completely agree that in the scope of LCA flow objects are
universal, while activities are located in time and space, we still
need to be able to enter other types of data, such as:
- GDP/population of a country over a time interval
- Recycling rate of different materials in a country (independent of a
particular recycling activity, as this is not specified in the input
data - could be linked later by the system model)
- Total amount of CO2/other emissions observed at a specific spatial
scale over a particular time

3. Simple is better than complex, even if it loses a little bit of
"realism". The lesson that I have learned when re-implementing some of
the modelling choices in version 3 of ecoinvent is that even good
ideas can have weird and unpredictable side effects when combined with
other seemingly good ideas. People appreciate models that they can
understand completely in a few minutes!

On Tue, 12 Mar 2019 at 09:10, <michele.derosa@bonsai.uno> wrote:

Good point Massimo. In Fact, the output flow of the activity "Waste Incineration" should be "TREATED municipal solid waste" and not "Treatment of municipal solid waste"
Michele
--
############################
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: Start of the #ontology sub-group #ontology

Stefano Merciai
 

Hi,

I think that using negative inputs to indicate an outputs is already a complication that may be not clear for many people. I think that Bonsai can be also used by the IO community, not just by LCA. IO practitioners do not like negatives.

Then, for example, in Exiobase (or in the WIOM of Nakamura and Kondo) the determining product (or principal production or reference product) of waste activities is a waste service, for example the service of recycling waste. This to say that perhaps we should agree on the framework that we are going to use. I think there is not unanimous consensus so better to spend some time for deciding the approach to adopt.

Stefano




On 12/03/2019 00:10, Massimo Pizzol wrote:

Chris is right that one can use a negative (= input) reference flow. I just never use this approach and I forgot, my mistake.

I don’t see how we can skip the reference flow concept though if we are going to work with LCA data (deliverable 2 and 3).

Massimo

From: <hackathon2019@bonsai.groups.io> on behalf of "Chris Mutel via Groups.Io" <cmutel@...>
Reply-To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Date: Monday, 11 March 2019 at 22.32
To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Subject: Re: [hackathon2019] Start of the #ontology sub-group #RDFFramework #ontology

 

I think it would be a mistake to bake too many restrictions into the

general framework. There is a certain mental model that prevails in

LCA, but we don't want BONSAI to accept these restrictions at the

beginning unless they are absolutely necessary, and BONSAI is not just

for LCA (e.g. should also be useful for MFA). For now it might be

worth skipping the determining flow completely, as it doesn't seem

necessary for the hackathon.

 

Determining flows are not always outputs, treatment of waste by

landfill has waste as a determining flow input.

 

 

 


-- 
Best,
S.


Re: Start of the #ontology sub-group #ontology

Bo Weidema
 

Den 2019-03-12 kl. 10.28 skrev Chris Mutel:

2. While I completely agree that in the scope of LCA flow objects are universal, while activities are located in time and space, we still
need to be able to enter other types of data, such as:
- GDP/population of a country over a time interval
- Recycling rate of different materials in a country (independent of a particular recycling activity, as this is not specified in the input data - could be linked later by the system model)
- Total amount of CO2/other emissions observed at a specific spatial scale over a particular time
The three examples of data you mention are not (raw) data inputs, but rather outputs from querying the database, i.e. they can all be calculated from the raw data. As such these three examples are weel siuted as "competency questions" as requested by Matteo.

Best regards

Bo


Re: Start of the #ontology sub-group #ontology

Bo Weidema
 

Just to chip in on the discussion on waste and waste treatment activities:

- The problem that a service activity often has the same name as the service that it provides is a well-known problem. It is not solved by inventing new speculative unique names, but rather by linking the instances of the names to their classes (activity or flow-object).

- Principle: We try to avoid making fixed choices, like sign nomenclatures, that are only useful in specific contexts.

- Principle: It is a good practice for a model to stay as close to reality as possible

- Principle: Do not introduce unneccesary (obligatory) classifications

Therefore:

- Wastes, by-products and emissions do not need to be distinguished. Following the physical reality, they are all just non-determining output flows of the activity that produces them and determining input flows to the activity that is activated by their prescence (waste treatment for wastes, recycling activities for by-products for treatment, markets for by-products that do not need treatment, ecological fate activities for emissions). The fact that some calculations require that non-determining outputs are calculated as negative inputs does not mean that the database needs to use such artificial conventions.

Best regards

Bo

81 - 100 of 273