Hej allihop,

I guess all of us have an outline in mind for the ontology-related paper. Here is what I have in mind; I guess we can build on it, iterate and agree on a suitable structure and contents.
Not sure if groups.io is the best way to keep track of edits in the long run; not sure that google.drive suits everyone either; GitHub would be public; we use BOX.com internally.

INTRODUCTION

§ Paragraph IE

IE's object of study is SEM.

The accounting of social, environmental and economic flows in time and space.

Many fields of sustainability and decision-making towards sustainability rely on such accounting.

Several approaches can exist: MFA / LCA / IOA; but all share the same structure; despite different vocabularies/inconsistencies (ref).

Call to lift up IE methods: Reference to Pauliuk

Call to generalise: Bo, 2018

 

 

§ Paragraph CS

• Ontology definition
• Linked Data, Web of Data, background, e.g. in life sciences and what it has enabled
• Open-source

 

§ IE and CS

Acknowledge previous efforts: LCA ontologies existing, IE GitHub repo open source,…

Still, as of today:

• Conventional databases, ecoinvent; exiobase, have not yet made the move towards these flexible data structures.
• Remains a challenge to have interoperability between databases
• Validation of databases
• Transparency of assumptions (constructs / system model)
• Updates of databases

 

§ Bonsai organisation, strech goals, hackhathon

• BONSAI organisation / Working rules / BEP process
• Strech goals; highlight the sub-goal of the ontology group
• Hackhathon, background info

 

§ Paper's aim

• Describe the ontology developed, providing examples and possible extensions
• Report on BEP process, main choices, alternatives left out + reproducability

 

§ Outline plan of article

[not sure an IMRaD structure is best suited, maybe better to have numbered section]

Section 2 = BEP process, rules, principles

Section 3 = Ontology description (link to online documentation)

Section 4 = Examples (unlinked, linked)

Section 5 = Advanced example, ideally with actual URIs, online;

Section 6 = Discussion of key choices, extensions per field, future enhancements, validation of rdfs

Section 7 = Conclusions, link to other working groups (e.g. correspondance tables, rdf triplestore)

 

SECTION 2  BEP process, rules, principles

Rules for agreeing; definition; BEPs

Principles:

• Minimalist principle: core; complementary ontologies for different fields; extensions upcoming
• On the distinction between A and B; for IA: atmospjhere as a process

 

SECTION 3 Ontology description

Table: 3 columns: Key vocabulary in the ontology; labels as in ontology; other usual names given in different fields (LCA, MFA, IOA, LCC, etc)

 

Figure: online viz of rdfs

 

§ Text description of:

• Classes
• Sub-classes
• Properties, balanceable properties, …
• Sub activities: market, transport, …

 

§ External ontologies

• Measure, location,…

 

§ To add:

• Uncertainty, …

 

 

EXAMPLE / APPLICATION [Section 4 , 5]

§ Current hosting of the ontology; examples are available at the URIs mentioned and on GitHubRepo

 

§ Several examples with figures, from simple to complex

Example Raw data; System model

Example with transport, market, impact assessment

 

DISCUSSION [based on BEPs, Section 6]

• Validation [oops thing]
• Why we have made certain choices
• Alternatives left out
• Reproducibility
• Extensions: field specific extensions, agent theory (usually lacking in our field), linkages with other resources on WebOfData
• Give one example of "re-use" by others of the ontology: accounting framework for Stockholm municipality (REFLOW project), how it fits in the ontology (or not) + ref to

 

CONCLUSIONS / VISION /EXTENSIONS [Section 7]

• how we see them;
• e.g. GDP, economic data
• agent theory (unless we want to add it to the ontology right away)
  

 

 

Some references

 

(1)     Pauliuk, S.; Majeau-Bettez, G.; Mutel, C. L.; Steubing, B.; Stadler, K. Lifting Industrial Ecology Modeling to a New Level of Quality and Transparency: A Call for More Transparent Publications and a Collaborative Open Source Software Framework. J. Ind. Ecol. 2015, 19 (6), 937–949; DOI 10.1111/jiec.12316.

(2)     Pauliuk, S.; Majeau-Bettez, G.; Müller, D. B. A General System Structure and Accounting Framework for Socioeconomic Metabolism. J. Ind. Ecol. 2015, 19 (5), 728–741; DOI 10.1111/jiec.12306.

(3)     Pauliuk, S.; Majeau-Bettez, G.; Müller, D. B.; Hertwich, E. G. Toward a Practical Ontology for Socioeconomic Metabolism. J. Ind. Ecol. 2016, 20 (6), 1260–1272; DOI 10.1111/jiec.12386.

(4)     Weidema, B. P.; Schmidt, J.; Fantke, P.; Pauliuk, S. On the Boundary between Economy and Environment in Life Cycle Assessment. Int. J. Life Cycle Assess. 2018, 23 (9), 1839–1846; DOI 10.1007/s11367-017-1398-4.

Hi everyone

The ontology group understands that most of us are currently busy converting their raw data to rdf format based on the bonsai ontology. We have the following namespaces to refer to the vocabularies we need to refer to. Here are some example prefixes* and the URLs the refer to:

@prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#>; . #(generic rdf schema to define class, subclass, etc)

@prefix bont:<http://ontology.bonsai.uno/core#>;. #(Bonsai rdf schema to define activity, flow, flow objects)

@prefix om2:<http://www.ontology-of-units-of-measure.org/resource/om-2/>; . #(Schema for units of measure, used to define units, give numerical value)

@prefix time:<https://www.w3.org/TR/owl-time/>;. #(Schema to define temporal extent)

@prefix act:<rdf.bonsai.uno/activitytype/exiobase3_3_17/>. #(exiobase URI to define the activity type instances)
@prefix flo:<rdf.bonsai.uno/flowobject/exiobase3_3_17/>. #(exiobase URI to define the flow object instances)
@prefix unit:<rdf.bonsai.uno/unit/exiobase3_3_17/>. #(exiobase URI to define the unit instances)
@prefix loc:<rdf.bonsai.uno/location/exiobase3_3_17/>. #(exiobase URI to define the location instances)

*prefixes used to shorten the URL, it can be defined by the user

Dear all



For consistency I think we should specify a bit more the format of the
final tables



Separator: I’d propose “,”

null values: An empty value seems reasonable to me, but I do not have a strong preference.

Header: just one row, the first one



That should help the parser later on. What do you think?



Miguel



From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io>
On Behalf Of michele.derosa@bonsai.uno
Sent: 25 March 2019 18:21
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format



Agree. Isn t this also the current format of the tables?

Dear all



For consistency I think we should specify a bit more the format of the final tables



Separator: I’d propose “,”

null values: An empty value seems reasonable to me, but I do not have a strong preference.

Header: just one row, the first one



That should help the parser later on. What do you think?



Miguel



From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io> On Behalf Of michele.derosa@bonsai.uno
Sent: 25 March 2019 18:21
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format



Agree. Isn t this also the current format of the tables?

Agree. Isn t this also the current format of the tables?

From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io> On Behalf Of michele.derosa@...
Sent: 25 March 2019 18:21
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format

Agree. Isn t this also the current format of the tables?

Hello all

should the correspondence table have only two columns?



For example, the exiobase to nace codes: to classify exiobase activities to nace codes the names (descriptions) are not needed. For me it would make more sense to have nace code to nace name in a different table. What do you think?

Miguel