Date   

Re: Two votes - please participate!

Massimo Pizzol
 

DCAFBE


#bonsamurai.github.io

romain
 

Hey, I start a discussion here on the new bonsai.uno webpage.

Here is the structure suggested by Chris.

  1. Vision (short)
    1. Common ontology for LCA, MFA, and IE
    2. Open data pipeline
  2. By the community, for the community
    1. Getting started guide
      1. Basic technologies
        1. Contribute with data
        2. Build web apps
        3. Using the API
    2. GitHub projects repo
  3. Community management
  4. Data reconciliation
  5. NPO (BONSAI on-profit organization)
    1. Become a member
    2. Archive of official documents

Did i get the hierarchy right?


Two votes - please participate!

 

Dear all-

1. If you haven't voted for or against BEP 1, please do it now! If not enough people participate, the proposal will automatically fail.

2. We have had a lively discussion on the terminology used in the ontology, and have several different options before us. It would be nice to get a sense of the broader groups preferences through an indicative, though not necessarily binding, vote. When multiple option are present, ranked choice voting (in this case in the form of instant runoff) is a decent polling choice. So please visit the list of candidates: https://github.com/BONSAMURAIS/BONSAI-ontology-RDF-framework/blob/master/Terminology-discussion.md, and reply to this email with your preferences in order by letter, from first to last. For example, here are my personal preferences:

BDACFE

Please rank all six possibilities, so we can get complete statistics.


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

 

I have created a bonsai.uno repo, which we need to fill out, to eventually replace the existing content of the website (this is included in BEP 4). The current website structure looks like:

Homepage
    Challenge and vision
    Organization
        Static downloads
    Strategy
        Many working group pages
    Archive
        Static downloads
    Become a member
        Contributions

Here is the beginning of a new layout which emphasizes our concepts and work methods. I really think that the web page will be better for documentation than the wiki, as we can control the presentation more, and add a little white space so we don't have the "wall of text" effect. See the proposed BEP4 for a discussion of how best to use the different communication media.

Homepage
    Vision (short)
        -> Common ontology for LCA, MFA, and IE
        -> Open data pipeline
    By the community, for the community
        -> Getting started guide
        -> GH projects repo

    Common ontology

    Data pipeline

    Getting started guide
        Basic technologies

        -> Contribute data
        -> Build web apps
        -> Using the API

    Community management

    Data reconciliation

    NPO (BONSAI non-profit organization)
        Become a member
        Archive of official documents

One possible way to separate the content from the presentation by storing the text with some simple markup (e.g. Markdown) in a separate directory.

@agneta and @romain, let's discuss how we can each participate. Perhaps we could start by better planning an outline, and writing down what we want to accomplish. Feel free to provide your thoughts and concerns.


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

 

I added a table with what I could make of the existing systems, and the possible alternatives we have discussed, here: https://github.com/BONSAMURAIS/BONSAI-ontology-RDF-framework/blob/master/Terminology-discussion.md. Feel free to edit this if you think I have made a mistake.

> To re-iterate: Flow is a verb

Flow can be a verb or a noun, and there is something to be said for having all the core terms be nouns (I think everything else is).


Re: Serializing large LD datasets

Massimo Pizzol
 

No opinion here, I trust those who have already worked hands-on on this, and their choice.

BR
Massimo

 

From: <main@bonsai.groups.io> on behalf of "Agneta via Groups.Io" <agneta.20@...>
Reply-To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Date: Friday, 5 April 2019 at 10.56
To: "main@bonsai.groups.io" <main@bonsai.groups.io>
Subject: Re: [bonsai] Serializing large LD datasets

 

+1 for turtle format

Much easier to read and write. 


Re: Serializing large LD datasets

Agneta
 

+1 for turtle format

Much easier to read and write. 


Re: Serializing large LD datasets

Miguel Fernández Astudillo
 

Hi!

 

In the correspondence table group we struggled a bit when we had to move from Turtle to json-LD. We spend some time trying to figure out how to do it in JSON and ended up writing turtle. We found it easier to write and read and we were told there was an automatic code to translate one to the other. I prefer Turtle, but I am not aware of the advantages of JSON-LD.   

 

Best,

 

Miguel

 

 

 

From: main@bonsai.groups.io <main@bonsai.groups.io> On Behalf Of Chris Mutel
Sent: 05 April 2019 10:06
To: main@bonsai.groups.io
Subject: [bonsai] Serializing large LD datasets

 

Maybe our approach to serializing large graphs is maybe not that great. You can see the current code here - basically, we convert Python to JSON line by line, with some text mangling. It sounds (and looks) a bit crazy; the idea behind this decision was that RDFLib can't really handle large datasets, such as BONSAI.

The latest straw was realizing that we need to declare a `dataset` for the actual data (not just metadata). In turtle, this is (for example):


@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix ns1: <http://creativecommons.org/ns#> .
@prefix dc: <
http://purl.org/dc/elements/1.1/> .
@prefix ns2: <http://purl.org/vocab/vann/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

brdfat: a dtype:Dataset ;
    ns1:license <http://creativecommons.org/licenses/by/3.0/> ;
    dc:contributor "BONSAI team" ;
    dc:creator <http://bonsai.uno/foaf/bonsai.rdf#bonsai> ;
    dc:description "ActivityType instances needed for BONSAI modelling of EXIOBASE version 3.3.17" ;
    dc:modified "2019-04-02"^^xsd:date ;
    dc:publisher "bonsai.uno" ;
    dc:title "EXIOBASE 3.3.17 activity types" ;
    ns2:preferredNamespaceUri <http://rdf.bonsai.uno/activitytype/exiobase3_3_17/#> ;
    owl:versionInfo "0.3" ;
    foaf:homepage brdfat:documentation.html .

In JSON-LD, if is... more involved:

 


{
  "@graph" : [ {
    "@id" : "http://rdf.bonsai.uno/activitytype/exiobase3_3_17/",
    "@type" : "dtype:Dataset",
    "license" : "http://creativecommons.org/licenses/by/3.0/",
    "contributor" : "BONSAI team",
    "creator" : "http://bonsai.uno/foaf/bonsai.rdf#bonsai",
    "description" : "ActivityType instances needed for BONSAI modelling of EXIOBASE version 3.3.17",
    "modified" : "2019-04-02",
    "publisher" : "bonsai.uno",
    "title" : "EXIOBASE 3.3.17 activity types",
    "preferredNamespaceUri" : "brdfat:#",
    "versionInfo" : "0.3",
    "homepage" : "brdfat:documentation.html"
  } ],
  "@context" : {
    "label" : {
      "@id" : "http://www.w3.org/2000/01/rdf-schema#label"
    },
    "versionInfo" : {
      "@id" : "http://www.w3.org/2002/07/owl#versionInfo"
    },
    "homepage" : {
      "@id" : "http://xmlns.com/foaf/0.1/homepage",
      "@type" : "@id"
    },
    "title" : {
      "@id" : "http://purl.org/dc/elements/1.1/title"
    },
    "publisher" : {
      "@id" : "http://purl.org/dc/elements/1.1/publisher"
    },
    "description" : {
      "@id" : "http://purl.org/dc/elements/1.1/description"
    },
    "preferredNamespaceUri" : {
      "@id" : "http://purl.org/vocab/vann/preferredNamespaceUri",
      "@type" : "@id"
    },
    "creator" : {
      "@id" : "http://purl.org/dc/elements/1.1/creator",
      "@type" : "@id"
    },
    "license" : {
      "@id" : "http://creativecommons.org/ns#license",
      "@type" : "@id"
    },
    "contributor" : {
      "@id" : "http://purl.org/dc/elements/1.1/contributor"
    },
    "modified" : {
      "@id" : "http://purl.org/dc/elements/1.1/modified",
      "@type" : "http://www.w3.org/2001/XMLSchema#date"
    },
    "dtype" : "http://purl.org/dc/dcmitype/",
    "brdfat" : "http://rdf.bonsai.uno/activitytype/exiobase3_3_17/",
  }
}

Moreover, it is difficult for me to reason about why the JSON-LD is formatted the way that it is. On the other hand, the Turtle file is much nicer to read and predict.

We had said earlier (though without a formal decision) that we want to use JSON-LD for data interchange, but it would make life a lot easier to use Turtle, if people were OK with that. Let me know what you think!

 


Serializing large LD datasets

 

Maybe our approach to serializing large graphs is maybe not that great. You can see the current code here - basically, we convert Python to JSON line by line, with some text mangling. It sounds (and looks) a bit crazy; the idea behind this decision was that RDFLib can't really handle large datasets, such as BONSAI.

The latest straw was realizing that we need to declare a `dataset` for the actual data (not just metadata). In turtle, this is (for example):

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix ns1: <http://creativecommons.org/ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns2: <http://purl.org/vocab/vann/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

brdfat: a dtype:Dataset ;
    ns1:license <http://creativecommons.org/licenses/by/3.0/> ;
    dc:contributor "BONSAI team" ;
    dc:creator <http://bonsai.uno/foaf/bonsai.rdf#bonsai> ;
    dc:description "ActivityType instances needed for BONSAI modelling of EXIOBASE version 3.3.17" ;
    dc:modified "2019-04-02"^^xsd:date ;
    dc:publisher "bonsai.uno" ;
    dc:title "EXIOBASE 3.3.17 activity types" ;
    ns2:preferredNamespaceUri <http://rdf.bonsai.uno/activitytype/exiobase3_3_17/#> ;
    owl:versionInfo "0.3" ;
    foaf:homepage brdfat:documentation.html .

In JSON-LD, if is... more involved:


{
  "@graph" : [ {
    "@id" : "http://rdf.bonsai.uno/activitytype/exiobase3_3_17/",
    "@type" : "dtype:Dataset",
    "license" : "http://creativecommons.org/licenses/by/3.0/",
    "contributor" : "BONSAI team",
    "creator" : "http://bonsai.uno/foaf/bonsai.rdf#bonsai",
    "description" : "ActivityType instances needed for BONSAI modelling of EXIOBASE version 3.3.17",
    "modified" : "2019-04-02",
    "publisher" : "bonsai.uno",
    "title" : "EXIOBASE 3.3.17 activity types",
    "preferredNamespaceUri" : "brdfat:#",
    "versionInfo" : "0.3",
    "homepage" : "brdfat:documentation.html"
  } ],
  "@context" : {
    "label" : {
      "@id" : "http://www.w3.org/2000/01/rdf-schema#label"
    },
    "versionInfo" : {
      "@id" : "http://www.w3.org/2002/07/owl#versionInfo"
    },
    "homepage" : {
      "@id" : "http://xmlns.com/foaf/0.1/homepage",
      "@type" : "@id"
    },
    "title" : {
      "@id" : "http://purl.org/dc/elements/1.1/title"
    },
    "publisher" : {
      "@id" : "http://purl.org/dc/elements/1.1/publisher"
    },
    "description" : {
      "@id" : "http://purl.org/dc/elements/1.1/description"
    },
    "preferredNamespaceUri" : {
      "@id" : "http://purl.org/vocab/vann/preferredNamespaceUri",
      "@type" : "@id"
    },
    "creator" : {
      "@id" : "http://purl.org/dc/elements/1.1/creator",
      "@type" : "@id"
    },
    "license" : {
      "@id" : "http://creativecommons.org/ns#license",
      "@type" : "@id"
    },
    "contributor" : {
      "@id" : "http://purl.org/dc/elements/1.1/contributor"
    },
    "modified" : {
      "@id" : "http://purl.org/dc/elements/1.1/modified",
      "@type" : "http://www.w3.org/2001/XMLSchema#date"
    },
    "dtype" : "http://purl.org/dc/dcmitype/",
    "brdfat" : "http://rdf.bonsai.uno/activitytype/exiobase3_3_17/",
  }
}

Moreover, it is difficult for me to reason about why the JSON-LD is formatted the way that it is. On the other hand, the Turtle file is much nicer to read and predict.

We had said earlier (though without a formal decision) that we want to use JSON-LD for data interchange, but it would make life a lot easier to use Turtle, if people were OK with that. Let me know what you think!
 


Re: #infrastructure New working group and practice guidelines #infrastructure

Matteo Lissandrini (AAU)
 

Hi Chris,

my importer is actually doing the file upload, this is the command I ran yesterday night

```bash
for f in `find ../rdf -name '*.ttl'`; do bseeder -i $f; done
```

So you do not need to merge files in /rdf repo, actually if you do that
you end up with a big problem: you lose track of which triples go in which named graph.


In my view the RDF repo is for the instances of the taxonomies, small datasets that changes slowly (e.g., flow object/items or activity types).
While the actual data would remain out of it.

For very big files what we can do is:
1) upload them via scp/rsync to a dedicated directory on the server,
2) use the file importer utility provided by jena itself


I understand that restoring is not easy, but we need to have it for reproducibility and for reliability (if bad things happen we may need to restore the database from scratch)



Cheers,
Matteo

________________________________________
From: main@bonsai.groups.io [main@bonsai.groups.io] on behalf of Chris Mutel via Groups.Io [cmutel=gmail.com@groups.io]
Sent: Thursday, April 04, 2019 1:43 PM
To: main@bonsai.groups.io
Subject: Re: [bonsai] #infrastructure New working group and practice guidelines

On Thu, 4 Apr 2019 at 13:20, Matteo Lissandrini (AAU) <matteo@...> wrote:

Hi Chris,

I can imagine that some of my tests may have deleted some data from the database. Sorry for that. To be honest, I was under the impression that the data in jken
I would expect the database to be wiped out regularly until we reach a stable status.
But this should not be an issue.
I would like to help in establishing the (automatic) workflow that collects the data (in NON RDF formats) and parses and merges it with the ontology and the contents of the /rdf repo so that we can easily wipe and redeploy the Jena instance at will.
I believe this will require a coordination between the arborist repo, the rdf repo, the importer and probably some other?
No problem, this is to be expected as we are still evolving the
schema, and making sure our RDF is valid and implemented properly.
However, at some point soon we should get to a point where the Aalborg
server is considered stable, while db.b.u is still for playing.

It actually isn't that easy to restore everything, as we need a
relatively large amount of data currently (on the order of 3 gb for
EXIOBASE, and 300 mb for the electricity stuff). The metadata is easy
- arborist can rewrite the data in https://github.com/BONSAMURAIS/rdf,
which can in turn be the foundation of the triple store. It would be
nice to have a function that would take all these small turtle files
and merge them into one file (which could then be uploaded to the
triple store).

In the medium-term, I don't think that it makes sense to store
metadata for specific databases like exiobase in arborist - this can
just as easily be part of the file including the actual data as well.
We only evolved this code pathway because we were learning as we were
going. Indeed, it is probably more clever in the long term to have
https://github.com/BONSAMURAIS/rdf generated from the database itself.

I think the small importer you wrote will work fine for smaller
datasets, but we will need to do file uploads for larger ones, as they
won't fit into memory (to be loaded by RDFLib). This should be easy to
do, though there may be some Jena configuration bugs to work out
still.

So everything is in a bit of a flux, and it would be great if you
could take charge of this little bit of it! Please document the hell
out of stuff, so we don't have to bug you too much.

Probably in the triplestore repo?

Thanks,
Matteo






________________________________
From: main@bonsai.groups.io [main@bonsai.groups.io] on behalf of Chris Mutel via Groups.Io [cmutel=gmail.com@groups.io]
Sent: Thursday, April 04, 2019 10:34 AM
To: main@bonsai.groups.io
Subject: [bonsai] #infrastructure New working group and practice guidelines

Dear all-

As many of you have already realized, we need to organize and document our infrastructure a bit better. Specifically, I see a need for:

Standard practice guidelines on maintaining the RDF database. For example, it looks like https://github.com/BONSAMURAIS/bontofrom/issues/9 is fixed, but I am not sure by who or when. Also, I think someone (or more than one person :) has wiped this database since the hackathon, as the electricity data is missing.
A small guide to help everyday people know which named graphs to use, and how to use them.
Backup and restore procedures for the RDF database. We need to be dumping stuff anyway to make the downloads available.
A private repository with server configs and passwords. I have applied for https://github.com/nonprofit status, but we could also run a private instance of gitlab.
A list of all bonsai.uno websites, virtual servers, etc.

Tomas, would you coordinate this? It doesn't mean you have to do all the work.


--
############################
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: #infrastructure New working group and practice guidelines #infrastructure

 

On Thu, 4 Apr 2019 at 13:20, Matteo Lissandrini (AAU) <matteo@...> wrote:

Hi Chris,

I can imagine that some of my tests may have deleted some data from the database. Sorry for that. To be honest, I was under the impression that the data in jken
I would expect the database to be wiped out regularly until we reach a stable status.
But this should not be an issue.
I would like to help in establishing the (automatic) workflow that collects the data (in NON RDF formats) and parses and merges it with the ontology and the contents of the /rdf repo so that we can easily wipe and redeploy the Jena instance at will.
I believe this will require a coordination between the arborist repo, the rdf repo, the importer and probably some other?
No problem, this is to be expected as we are still evolving the
schema, and making sure our RDF is valid and implemented properly.
However, at some point soon we should get to a point where the Aalborg
server is considered stable, while db.b.u is still for playing.

It actually isn't that easy to restore everything, as we need a
relatively large amount of data currently (on the order of 3 gb for
EXIOBASE, and 300 mb for the electricity stuff). The metadata is easy
- arborist can rewrite the data in https://github.com/BONSAMURAIS/rdf,
which can in turn be the foundation of the triple store. It would be
nice to have a function that would take all these small turtle files
and merge them into one file (which could then be uploaded to the
triple store).

In the medium-term, I don't think that it makes sense to store
metadata for specific databases like exiobase in arborist - this can
just as easily be part of the file including the actual data as well.
We only evolved this code pathway because we were learning as we were
going. Indeed, it is probably more clever in the long term to have
https://github.com/BONSAMURAIS/rdf generated from the database itself.

I think the small importer you wrote will work fine for smaller
datasets, but we will need to do file uploads for larger ones, as they
won't fit into memory (to be loaded by RDFLib). This should be easy to
do, though there may be some Jena configuration bugs to work out
still.

So everything is in a bit of a flux, and it would be great if you
could take charge of this little bit of it! Please document the hell
out of stuff, so we don't have to bug you too much.

Probably in the triplestore repo?

Thanks,
Matteo






________________________________
From: main@bonsai.groups.io [main@bonsai.groups.io] on behalf of Chris Mutel via Groups.Io [cmutel=gmail.com@groups.io]
Sent: Thursday, April 04, 2019 10:34 AM
To: main@bonsai.groups.io
Subject: [bonsai] #infrastructure New working group and practice guidelines

Dear all-

As many of you have already realized, we need to organize and document our infrastructure a bit better. Specifically, I see a need for:

Standard practice guidelines on maintaining the RDF database. For example, it looks like https://github.com/BONSAMURAIS/bontofrom/issues/9 is fixed, but I am not sure by who or when. Also, I think someone (or more than one person :) has wiped this database since the hackathon, as the electricity data is missing.
A small guide to help everyday people know which named graphs to use, and how to use them.
Backup and restore procedures for the RDF database. We need to be dumping stuff anyway to make the downloads available.
A private repository with server configs and passwords. I have applied for https://github.com/nonprofit status, but we could also run a private instance of gitlab.
A list of all bonsai.uno websites, virtual servers, etc.

Tomas, would you coordinate this? It doesn't mean you have to do all the work.


--
############################
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: #infrastructure New working group and practice guidelines #infrastructure

Matteo Lissandrini (AAU)
 

Hi Chris,

I can imagine that some of my tests may have deleted some data from the database. Sorry for that. To be honest, I was under the impression that the data in jken
I would expect the database to be wiped out regularly until we reach a stable status.
But this should not be an issue.
I would like to help in establishing the (automatic) workflow that collects the data (in NON RDF formats) and parses and merges it with the ontology and the contents of the /rdf repo so that we can easily wipe and redeploy the Jena instance at will.
I believe this will require a coordination between the arborist repo, the rdf repo, the importer and probably some other?
Probably in the triplestore repo?

Thanks,
Matteo







From: main@bonsai.groups.io [main@bonsai.groups.io] on behalf of Chris Mutel via Groups.Io [cmutel@...]
Sent: Thursday, April 04, 2019 10:34 AM
To: main@bonsai.groups.io
Subject: [bonsai] #infrastructure New working group and practice guidelines

Dear all-

As many of you have already realized, we need to organize and document our infrastructure a bit better. Specifically, I see a need for:

  • Standard practice guidelines on maintaining the RDF database. For example, it looks like https://github.com/BONSAMURAIS/bontofrom/issues/9 is fixed, but I am not sure by who or when. Also, I think someone (or more than one person :) has wiped this database since the hackathon, as the electricity data is missing.
  • A small guide to help everyday people know which named graphs to use, and how to use them.
  • Backup and restore procedures for the RDF database. We need to be dumping stuff anyway to make the downloads available.
  • A private repository with server configs and passwords. I have applied for https://github.com/nonprofit status, but we could also run a private instance of gitlab.
  • A list of all bonsai.uno websites, virtual servers, etc.
Tomas, would you coordinate this? It doesn't mean you have to do all the work.


Re: #infrastructure New working group and practice guidelines #infrastructure

tomas Navarrete
 

Yes, I'll coordinate this.


#infrastructure New working group and practice guidelines #infrastructure

 

Dear all-

As many of you have already realized, we need to organize and document our infrastructure a bit better. Specifically, I see a need for:

  • Standard practice guidelines on maintaining the RDF database. For example, it looks like https://github.com/BONSAMURAIS/bontofrom/issues/9 is fixed, but I am not sure by who or when. Also, I think someone (or more than one person :) has wiped this database since the hackathon, as the electricity data is missing.
  • A small guide to help everyday people know which named graphs to use, and how to use them.
  • Backup and restore procedures for the RDF database. We need to be dumping stuff anyway to make the downloads available.
  • A private repository with server configs and passwords. I have applied for https://github.com/nonprofit status, but we could also run a private instance of gitlab.
  • A list of all bonsai.uno websites, virtual servers, etc.
Tomas, would you coordinate this? It doesn't mean you have to do all the work.


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

Bo Weidema
 

To re-iterate: Flow is a verb, and should remain as the central term for our observations.

There seems to be a tendency towards preferring flow-item (instead of flow-object).

If we cannot settle this now, then add it as an issue with the arguments given in this thread.

Bo

Den 2019-04-03 kl. 13.57 skrev Agneta:

My suggestions are similar to what is given in the  ILCD 
Just to reiterate I suggest to change:

Flow object (abstract ) to Flow (a thing that exists)
Flow (specific) to Exchange (a relationship between an activity and flow (object)) 

Because we dont have any compartments we dont necessarily make additional confusions as the ILCD. Moreover, I think these terms are frequently used  by practitioners and hence easy to understand (the terms were also introduced in previous LCA ontology papers). Introducing new terms can just add confusion (IMO) 

Alternatively I suggest we  just go ahead with the current terminology and open the case for a public review. 

Agneta


On Wed, 3 Apr 2019 at 13:45, <loekke@...> wrote:
Item is fine...
/Søren


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


--


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

Agneta
 

My suggestions are similar to what is given in the  ILCD 
Just to reiterate I suggest to change:

Flow object (abstract ) to Flow (a thing that exists)
Flow (specific) to Exchange (a relationship between an activity and flow (object)) 

Because we dont have any compartments we dont necessarily make additional confusions as the ILCD. Moreover, I think these terms are frequently used  by practitioners and hence easy to understand (the terms were also introduced in previous LCA ontology papers). Introducing new terms can just add confusion (IMO) 

Alternatively I suggest we  just go ahead with the current terminology and open the case for a public review. 

Agneta


On Wed, 3 Apr 2019 at 13:45, <loekke@...> wrote:
Item is fine...
/Søren



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



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

Søren
 

Item is fine...
/Søren


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

Rutger Schurgers
 

Hi group,

 

Bo is right, I looked at the ecospold2 source files to refresh my memory and they indeed call their master data elementary exchanges and intermediate exchanges. So it is actually only in the ILCD format that they do make the distinction between the flow-objects that they call flows and the flows that they call exchanges. And ILCD is confusing as well, as their flows are from both the technosphere and nature (so some have compartments while others don’t). So steel is a flow, as well as Carbon dioxide. That’s not very obvious, and I would say that by themselves, as we would like to consider them, they are not ‘flowing’ anywhere.

 

At PRé we haven’t come up with anything so far that covers all possible flow-objects. In the platform, we have a two types: substances and products. But the fact that they are separate and that substances also include things like labour and land use indicate that they aren’t the best solution either.

 

That was a bit of thinking out loud, not sure it is very helpful but it indicates that it has been a struggle for quite a few people already.

 

Back to what Bo suggested, intuitively flow-item sounds a bit better to me. Given the breath of things we want to cover with the term, there’s probably not much that sounds less abstract. But if someone comes up with a term that sounds a bit more friendly, I’m interested.

 

Regards,

 

Rutger

 

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

 

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

Massimo Pizzol
 

>>> 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").

>>> I do not think it makes much difference if we call it flow-object or flow-item.

 

IMO this is the clearest explanation so far, thanks Bo. I am fine with the word “item” instead of “object”.

 

Note there is an enhancements branch on BEP-0003 BONSAI Ontology and I guess these discussions should be reflected there….

 

BR
Massimo

 


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

Andreas Ciroth
 

Thank you Chris; I agree and would add that ‘Flow-object’ is also not too perfect. No other element is called “object”. And exchange just says: see flow.

Proposal from my side:

  • Flow object is changed to flow
  • Exchange takes the definition of flow
  • Flow is removed.

This without being aware of previous discussions, so please excuse if I am ignorant here..

All the best,

Andreas

 

Von: main@bonsai.groups.io <main@bonsai.groups.io> Im Auftrag von Chris Mutel
Gesendet: Mittwoch, 3. April 2019 11:07
An: main@bonsai.groups.io
Betreff: [bonsai] #ontology Can we come up with a better term than "Flow Object"?

 

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.