>>> I guess by final proposal you are suggesting the use of BEP for this working group, do I understand right? I’ll try to make a summary of the discussion. In this working group we are discussing the schema proposed
by Matteo. Points of discussion: […]
I have started drafting a “PEP 0003 ontology” document to have an idea of how it should look like and it’s available
I mailed with Chris quickly and I understood that what we are supposed to do is:
1. first to clarify the points of discussion in my previous mail (+ others of course) and
2. only after we have reached a consensus (or non-consensus) update the document and include it to the bonsai repository (via pull request).
From: <email@example.com> on behalf of "Massimo Pizzol via Groups.Io" <massimo@...>
Reply-To: "firstname.lastname@example.org" <email@example.com>
Date: Tuesday, 12 March 2019 at 12.24
To: "firstname.lastname@example.org" <email@example.com>
Subject: Re: [hackathon2019] Start of the #ontology sub-group #RDFFramework #ontology
Sorry if sounded smart or know-all I just wanted to explain to Matteo some of the issues in layman terms. I apologized for my mistake on the negative input straight away so I assume we can make peace now.
>>> 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
I guess by final proposal you are suggesting the use of BEP for this working group, do I understand right? I’ll try to make a summary of the discussion.
In this working group we are discussing the schema proposed by Matteo. Points of discussion:
- The use and necessity of using the “input” and “output” subclasses has been discussed. Contra: seems redundant when there is already a property. Pro: useful for
filtering activities later on. Decision needed.
- The use and necessity of a reference flow.
- Not clear if it should be a class, subclass, or property. Pro/contra missing.
- Not clear if it should always be output or could be input.
à Clarified: mathematically it can be both but the convention choice has implications (e.g. IO people like it output and positive). Problem: According to Matteo having ref flow
both input and output is problematic in the schema. Reason still not clear though.
- Leave it out. Contra: information loss when importing from / exporting to LCA/IO format; without it we can’t determine causality. Pro: makes the model less complex.
- Environmental exchanges and waste flows missing in the schema, how to include them:
- I suggested that we could either 1) create a class “Substance” (or other meaningful name) similar to class “Product” or 2) remove class “Product” and just keep
class “Flow” that would be valid for both environmental and product exchanges.
- Bo argued that “Wastes, by-products and emissions do not need to be distinguished.” How does this translate in practice in the schema, is not clear yet. Perhaps
as in the point 2. above?
- Other solutions?