Date   

Hackathon logistics

 

Dear BONSAI hackathon participants:

Thanks again for agreeing to participate, and we look forward to
meeting you all in Barcelona!

Here are some logistical details:

Please plan to arrive on Sunday, March 24. We would like to get
started Monday morning. The hackathon will officially end on Friday
mid-afternoon, with the expectation that most people will leave Friday
evening.

The hackathon will be at a rented team space at Travessera de Dalt 33,
08024 Barcelona (see attached).

If we are covering your expenses, please be aware of the following:

* You should book your tickets and hotel/apartment yourself. You can
send receipts to Bo Weidema for reimbursement (bo.weidema@...).
* Our budget is given here:
https://github.com/BONSAMURAIS/hackathon-2019/blob/master/Financial.md.
Please stay within the suggested limits.
* We will eat group lunches & dinners. There will not be a cash per diem.

Please reply to this message (instead of me directly) if you have questions, as others may have the same question.

Yours,
Chris


Re: Hackathon logistics

Matteo Lissandrini (AAU)
 

Thanks a lot for the information,
is there any recommendation for hotels/airbnb near the place of the hackaton?

Kind regards,
Matteo

---
Matteo Lissandrini

Department of Computer Science
Aalborg University

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





On Wed, 20 Feb 2019 at 17:09, Chris Mutel
<hackathon2019+owner@bonsai.groups.io> wrote:

Dear BONSAI hackathon participants:

Thanks again for agreeing to participate, and we look forward to
meeting you all in Barcelona!

Here are some logistical details:

Please plan to arrive on Sunday, March 24. We would like to get
started Monday morning. The hackathon will officially end on Friday
mid-afternoon, with the expectation that most people will leave Friday
evening.

The hackathon will be at a rented team space at Travessera de Dalt 33,
08024 Barcelona (see attached).

If we are covering your expenses, please be aware of the following:

* You should book your tickets and hotel/apartment yourself. You can
send receipts to Bo Weidema for reimbursement (bo.weidema@...).
* Our budget is given here:
https://github.com/BONSAMURAIS/hackathon-2019/blob/master/Financial.md.
Please stay within the suggested limits.
* We will eat group lunches & dinners. There will not be a cash per diem.

Please reply to this message (instead of me directly) if you have questions, as others may have the same question.

Yours,
Chris


Re: Hackathon logistics

tomas Navarrete
 

Hi,

So now we have groups.io mailing list.

What about creating a slack (or other equivalent tool) to use during the hackaton ?

I mean, like to send URLS for example.

Of course, we could always use Google Hangouts for this as well.
What do you think ?

cheers,

"Matteo Lissandrini (AAU)" ---02/20/2019 11:51:59 PM---Thanks a lot for the information, is there any recommendation for hotels/airbnb near the place of th

From: "Matteo Lissandrini (AAU)" <matteo@...>
To: <hackathon2019@bonsai.groups.io>
Date: 02/20/2019 11:51 PM
Subject: Re: [hackathon2019] Hackathon logistics
Sent by: hackathon2019@bonsai.groups.io





Thanks a lot for the information,
is there any recommendation for hotels/airbnb near the place of the hackaton?

Kind regards,
Matteo

---
Matteo Lissandrini

Department of Computer Science
Aalborg University

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





On Wed, 20 Feb 2019 at 17:09, Chris Mutel
<hackathon2019+owner@bonsai.groups.io> wrote:
>
> Dear BONSAI hackathon participants:
>
> Thanks again for agreeing to participate, and we look forward to
> meeting you all in Barcelona!
>
> Here are some logistical details:
>
> Please plan to arrive on Sunday, March 24. We would like to get
> started Monday morning. The hackathon will officially end on Friday
> mid-afternoon, with the expectation that most people will leave Friday
> evening.
>
> The hackathon will be at a rented team space at Travessera de Dalt 33,
> 08024 Barcelona (see attached).
>
> If we are covering your expenses, please be aware of the following:
>
> * You should book your tickets and hotel/apartment yourself. You can
> send receipts to Bo Weidema for reimbursement (bo.weidema@...).
> * Our budget is given here:
> https://github.com/BONSAMURAIS/hackathon-2019/blob/master/Financial.md.
> Please stay within the suggested limits.
> * We will eat group lunches & dinners. There will not be a cash per diem.
>
> Please reply to this message (instead of me directly) if you have questions, as others may have the same question.
>
> Yours,
> Chris
>





Hackathon communication programs

 

Dear all-

Please fill out the following 1-minute survey on your preferred
chat/videoconference programs:

https://docs.google.com/forms/d/e/1FAIpQLSdrIydvdqDsMtydAm_vUox5tofctaYf1xD-nFq9GIdpW2QAbA/viewform?usp=sf_link

Thanks,
Chris


Hackathon concept and deliverables - request for comment

 

Dear Hackathon participants:

It is time to start preparing in earnest for our joint work at the end of March.

The following deliverables are required at the end of our time together:

a) Matching of EXIOBASE to the BONSAI ontology set, and import into an RDF database
b) Standards and implementation for updatable (transparent, executable) LCI data models
c) Matching of output from b to the same ontology, and import into an RDF database
d) Export of a reconciled database containing both input sources

This is already quite a lot, so I don't think we need to add more tasks, at least for now!

To actually accomplish these objectives in a large, diverse, and dispersed team, I propose that we follow the UNIX philosophy (https://en.wikipedia.org/wiki/Unix_philosophy), namely that we have a set of tools that each do one thing well. The BONSAI ontology can form the foundation for how these individual tools can transfer data with each other - in particular, the standards developed in task b become much easier if we just require the interface language spec to be the set of ontologies that BONSAI will use.

The model in task b will be either European electricity generation, distribution, trade, and losses/conversion; or, a model of automobile transportation where one can specify the model, number of passengers, etc. The groundwork for both of these models has already been done at PSI.

Before going into detailed planning, I would like your first reactions to the concept of the hackathon. If you are not familiar with these ideas, I have written a bit about my specific vision here: https://chris.mutel.org/next-steps.html

Yours,
Chris


Re: Hackathon concept and deliverables - request for comment

Brandon Kuczenski
 

You just wanted to show off that princess photo!

Thanks for conceiving and enacting the hackathon project, and for sending out this introduction. I have some comments that I wanted to send out right away as a "hot take" (acknowledging that one purpose of such a missive is to provoke responses), and I will also have some (perhaps more reasoned) comments later.

The task you have conceived of is exciting and useful. And probably achievable.

My first critique is: none of those is a deliverable; those are tasks. The deliverables should be things that we can look at and send around. Perhaps the deliverables would be the outputs resulting from those tasks executing successfully. But we should be precise in specifying them. "An RDF database containing EXIOBASE in terms of the BONSAI ontology." and there should be some standard by which we decide whether the deliverable has been met. (e.g. querying "x" against the database should return "y" from EXIOBASE). Maybe writing these tests is itself in-scope for the hackathon. (in which case: perhaps "operating unit tests for EXIOBASE import" is a reasonable deliverable?")

Second: Well, (b) is a kind of a deliverable.. I suspect what you mean is more like "a document that reports the group's consensus on" those standards. But I want to observe that one such standard has already been proposed: (https://doi.org/10.1111/jiec.12810)  The work in that paper was intended to achieve this goal. I humbly offer it for consideration (and possibly rejection on grounds) prior to the hackathon, since it might help us move the ball down the field. The key utilities of this framework are:
(1) it provides a precise statement of a narrowly scoped process-flow model which can be easily revised and parameterized, 
(2) it explicitly requires linkages to remote data sources, and
(3) it explicitly excludes elementary flow matching, assuming the solution to that problem to be located in (2).
A product system model disclosure includes: three entity lists (of foreground flows, background flows, and emissions), and three sparse matrices that connect the entities to one another. One could easily imagine the entries in the entity lists to simply be references to the RDF database.

There is also a (semi-)working brightway implementation: (https://github.com/pjamesjoyce/lca_disclosures) that casts a BW2 database to a JSON document according to the framework; writing an RDF output would not be hard.

Really, I am just fishing for critical feedback on my disclosures proposal. But I do think it's relevant.

-Brandon




On Thu, Feb 21, 2019 at 2:01 PM Chris Mutel <cmutel@...> wrote:
Dear Hackathon participants:

It is time to start preparing in earnest for our joint work at the end of March.

The following deliverables are required at the end of our time together:

a) Matching of EXIOBASE to the BONSAI ontology set, and import into an RDF database
b) Standards and implementation for updatable (transparent, executable) LCI data models
c) Matching of output from b to the same ontology, and import into an RDF database
d) Export of a reconciled database containing both input sources

This is already quite a lot, so I don't think we need to add more tasks, at least for now!

To actually accomplish these objectives in a large, diverse, and dispersed team, I propose that we follow the UNIX philosophy (https://en.wikipedia.org/wiki/Unix_philosophy), namely that we have a set of tools that each do one thing well. The BONSAI ontology can form the foundation for how these individual tools can transfer data with each other - in particular, the standards developed in task b become much easier if we just require the interface language spec to be the set of ontologies that BONSAI will use.

The model in task b will be either European electricity generation, distribution, trade, and losses/conversion; or, a model of automobile transportation where one can specify the model, number of passengers, etc. The groundwork for both of these models has already been done at PSI.

Before going into detailed planning, I would like your first reactions to the concept of the hackathon. If you are not familiar with these ideas, I have written a bit about my specific vision here: https://chris.mutel.org/next-steps.html

Yours,
Chris



--
Brandon Kuczenski, Ph.D.
Associate Researcher

University of California at Santa Barbara
Institute for Social, Behavioral, and Economic Research
Santa Barbara, CA 93106-5131

email: bkuczenski@...


Re: Hackathon concept and deliverables - request for comment

tomas Navarrete
 

Following a Test/Behavior driven approach as Brandon suggest (in fine) has my entire support.

Some of the artefacts that we would need to achieve the tasks are somehow already available. Pymrio to manipulate exiobase for example.
I suggest we start gathering a list of artefacts that could be used to produce the deliverables of each task.

After Brandon's mail, here is how I see things for task a:

a) EXIOBASE Meets BONSAI-ontology
a.1 Use pymrio to parse a subset (year?) of EXIOBASE3. Output called: exiobase3-dataset
a.2 design a tool capable of taking an element from exiobase3-dataset and transforming it to a BONSAI-ontology element. Output: specification + test design of `exiobase32bo`.
a.3 Implement exiobase32bo (happy coding)
a.4 apply exiobase32bo to exiobase3-dataset. Output called: bonsai-exaio3
a.5 Use (Apache jena) rdf tools to create a database from bonsai-exaio3

Of course, names are only examples and I have no particular attachment to them.

before diving into b Where is the BONSAI ontology ?

Anyway, I assume we should pay more attention to "b) Standards and implementation for updatable (transparent, executable) LCI data models"

@chris, how does b fit in your scheme of https://chris.mutel.org/next-steps.html ?

"Brandon Kuczenski" ---02/22/2019 12:11:11 AM---You just wanted to show off that princess photo! Thanks for conceiving and enacting the hackathon pr


From: "Brandon Kuczenski" <bkuczenski@...>
To: hackathon2019@bonsai.groups.io
Date: 02/22/2019 12:11 AM
Subject: Re: [hackathon2019] Hackathon concept and deliverables - request for comment
Sent by: hackathon2019@bonsai.groups.io





You just wanted to show off that princess photo!

Thanks for conceiving and enacting the hackathon project, and for sending out this introduction. I have some comments that I wanted to send out right away as a "hot take" (acknowledging that one purpose of such a missive is to provoke responses), and I will also have some (perhaps more reasoned) comments later.

The task you have conceived of is exciting and useful. And probably achievable.

My first critique is: none of those is a deliverable; those are tasks. The deliverables should be things that we can look at and send around. Perhaps the deliverables would be the outputs resulting from those tasks executing successfully. But we should be precise in specifying them. "An RDF database containing EXIOBASE in terms of the BONSAI ontology." and there should be some standard by which we decide whether the deliverable has been met. (e.g. querying "x" against the database should return "y" from EXIOBASE). Maybe writing these tests is itself in-scope for the hackathon. (in which case: perhaps "operating unit tests for EXIOBASE import" is a reasonable deliverable?")

Second: Well, (b) is a kind of a deliverable.. I suspect what you mean is more like "a document that reports the group's consensus on" those standards. But I want to observe that one such standard has already been proposed: (https://doi.org/10.1111/jiec.12810)  The work in that paper was intended to achieve this goal. I humbly offer it for consideration (and possibly rejection on grounds) prior to the hackathon, since it might help us move the ball down the field. The key utilities of this framework are:
(1) it provides a precise statement of a narrowly scoped process-flow model which can be easily revised and parameterized, 
(2) it explicitly requires linkages to remote data sources, and
(3) it explicitly excludes elementary flow matching, assuming the solution to that problem to be located in (2).
A product system model disclosure includes: three entity lists (of foreground flows, background flows, and emissions), and three sparse matrices that connect the entities to one another. One could easily imagine the entries in the entity lists to simply be references to the RDF database.

There is also a (semi-)working brightway implementation: (https://github.com/pjamesjoyce/lca_disclosures) that casts a BW2 database to a JSON document according to the framework; writing an RDF output would not be hard.

Really, I am just fishing for critical feedback on my disclosures proposal. But I do think it's relevant.

-Brandon




On Thu, Feb 21, 2019 at 2:01 PM Chris Mutel <cmutel@...> wrote:
    Dear Hackathon participants:

    It is time to start preparing in earnest for our joint work at the end of March.

    The following deliverables are required at the end of our time together:

    a) Matching of EXIOBASE to the BONSAI ontology set, and import into an RDF database
    b) Standards and implementation for updatable (transparent, executable) LCI data models
    c) Matching of output from b to the same ontology, and import into an RDF database
    d) Export of a reconciled database containing both input sources

    This is already quite a lot, so I don't think we need to add more tasks, at least for now!

    To actually accomplish these objectives in a large, diverse, and dispersed team, I propose that we follow the UNIX philosophy (
    https://en.wikipedia.org/wiki/Unix_philosophy), namely that we have a set of tools that each do one thing well. The BONSAI ontology can form the foundation for how these individual tools can transfer data with each other - in particular, the standards developed in task b become much easier if we just require the interface language spec to be the set of ontologies that BONSAI will use.

    The model in task b will be either European electricity generation, distribution, trade, and losses/conversion; or, a model of automobile transportation where one can specify the model, number of passengers, etc. The groundwork for both of these models has already been done at PSI.

    Before going into detailed planning, I would like your first reactions to the concept of the hackathon. If you are not familiar with these ideas, I have written a bit about my specific vision here:
    https://chris.mutel.org/next-steps.html

    Yours,
    Chris



--

Brandon Kuczenski, Ph.D.
Associate Researcher

University of California at Santa Barbara
Institute for Social, Behavioral, and Economic Research
Santa Barbara, CA 93106-5131

email:
bkuczenski@...


Re: Hackathon concept and deliverables - request for comment

Bo Weidema
 

Den 2019-02-22 kl. 08.57 skrev tomas Navarrete:

before diving into b Where is the BONSAI ontology ?

https://github.com/BONSAMURAIS/bonsai/wiki/Data-Storage#specify-minimum-core-data-and-metadata-formats

(this is not provided in any formal ontology-language, but I assume someone more well versed in such languages should be able to translate from the text?)


Anyway, I assume we should pay more attention to "b) Standards and implementation for updatable (transparent, executable) LCI data models"


I think there may be some confusion here. As I understood Chris's request, this is what we in ecoinvent informally have called "LCI modules" - not to be confused with full "system models" as I understand Brandon's interpretation. But "LCI modules" (or maybe better call them "activity modules") have not been defined as part of the BONSAI ontology yet (nor have they been implemented in ecoinvent). So the first task here would be to make a more precise definition of what is an "activity module".

Best regards

Bo


Re: Hackathon concept and deliverables - request for comment

Massimo Pizzol
 

Dear all

 

Seems like it would be useful to have a sort of “meta” reflection and formalize the “why and how and what” of this hackathon, so that we can have clear goals and optimize the work. I have prepared a draft (attached), hoping this can be of help. Not sure how/where I should upload it (github or google docs…the latter probably best for comments?). Let me know.


Thanks Brandon for sharing your paper. I think what you have formalised there is quite reasonable (I wrote something on this line here some time ago) so OK for me to follow these suggestions.

 

BR
Massimo

 

 

-- 

 

Massimo Pizzol 

 

DCEA | Department of Planning

Aalborg University (DK)

 

Mobile: +45 2067 5275

 

From: <hackathon2019@bonsai.groups.io> on behalf of Brandon Kuczenski <bkuczenski@...>
Reply-To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Date: Friday, 22 February 2019 at 00.10
To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Subject: Re: [hackathon2019] Hackathon concept and deliverables - request for comment

 

You just wanted to show off that princess photo!

 

Thanks for conceiving and enacting the hackathon project, and for sending out this introduction. I have some comments that I wanted to send out right away as a "hot take" (acknowledging that one purpose of such a missive is to provoke responses), and I will also have some (perhaps more reasoned) comments later.

 

The task you have conceived of is exciting and useful. And probably achievable.

 

My first critique is: none of those is a deliverable; those are tasks. The deliverables should be things that we can look at and send around. Perhaps the deliverables would be the outputs resulting from those tasks executing successfully. But we should be precise in specifying them. "An RDF database containing EXIOBASE in terms of the BONSAI ontology." and there should be some standard by which we decide whether the deliverable has been met. (e.g. querying "x" against the database should return "y" from EXIOBASE). Maybe writing these tests is itself in-scope for the hackathon. (in which case: perhaps "operating unit tests for EXIOBASE import" is a reasonable deliverable?")

 

Second: Well, (b) is a kind of a deliverable.. I suspect what you mean is more like "a document that reports the group's consensus on" those standards. But I want to observe that one such standard has already been proposed: (https://doi.org/10.1111/jiec.12810)  The work in that paper was intended to achieve this goal. I humbly offer it for consideration (and possibly rejection on grounds) prior to the hackathon, since it might help us move the ball down the field. The key utilities of this framework are:

(1) it provides a precise statement of a narrowly scoped process-flow model which can be easily revised and parameterized, 

(2) it explicitly requires linkages to remote data sources, and

(3) it explicitly excludes elementary flow matching, assuming the solution to that problem to be located in (2).

A product system model disclosure includes: three entity lists (of foreground flows, background flows, and emissions), and three sparse matrices that connect the entities to one another. One could easily imagine the entries in the entity lists to simply be references to the RDF database.

 

There is also a (semi-)working brightway implementation: (https://github.com/pjamesjoyce/lca_disclosures) that casts a BW2 database to a JSON document according to the framework; writing an RDF output would not be hard.

 

Really, I am just fishing for critical feedback on my disclosures proposal. But I do think it's relevant.

 

-Brandon

 

 

 

 

On Thu, Feb 21, 2019 at 2:01 PM Chris Mutel <cmutel@...> wrote:

Dear Hackathon participants:

It is time to start preparing in earnest for our joint work at the end of March.

The following deliverables are required at the end of our time together:

a) Matching of EXIOBASE to the BONSAI ontology set, and import into an RDF database
b) Standards and implementation for updatable (transparent, executable) LCI data models
c) Matching of output from b to the same ontology, and import into an RDF database
d) Export of a reconciled database containing both input sources

This is already quite a lot, so I don't think we need to add more tasks, at least for now!

To actually accomplish these objectives in a large, diverse, and dispersed team, I propose that we follow the UNIX philosophy (https://en.wikipedia.org/wiki/Unix_philosophy), namely that we have a set of tools that each do one thing well. The BONSAI ontology can form the foundation for how these individual tools can transfer data with each other - in particular, the standards developed in task b become much easier if we just require the interface language spec to be the set of ontologies that BONSAI will use.

The model in task b will be either European electricity generation, distribution, trade, and losses/conversion; or, a model of automobile transportation where one can specify the model, number of passengers, etc. The groundwork for both of these models has already been done at PSI.

Before going into detailed planning, I would like your first reactions to the concept of the hackathon. If you are not familiar with these ideas, I have written a bit about my specific vision here: https://chris.mutel.org/next-steps.html

Yours,
Chris



--

Brandon Kuczenski, Ph.D.
Associate Researcher

University of California at Santa Barbara
Institute for Social, Behavioral, and Economic Research
Santa Barbara, CA 93106-5131

email: bkuczenski@...


Re: Hackathon concept and deliverables - request for comment

Elias Sebastian Azzi
 

Hello,

I had read your vision couple of months ago. It is great to see you diving into action with this hackathon.

While I am reading - on a 15-hour-long train ride -  the “assigned literature” about RDF, SPARQL, Linked Data, your email made me realise that I also should re-read and get familiar with the BONSAI ontology set (https://github.com/BONSAMURAIS/bonsai/wiki/Data-Storage & https://github.com/BONSAMURAIS/bonsai/wiki/Data-Integration; anything more specific?)

/Elias

 


Github user names

 

Dear all-

1. Please register for a Github acount, if you don't already have one.
2. If you don't yet have write access to the hackthon planning repo, please let me, Bo, or Tomas know.
3. Please add your Github user names to https://github.com/BONSAMURAIS/hackathon-2019/blob/master/Participants.md

Thanks!
-Chris


Hackthon management/software development philosophy

 

Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.

I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.

I see the following key questions:
- How strict do we want to be following a particular system?
- How can we make sure that software/other efforts aren't duplicated?
- How can we make sure that each persons capabilities are being used effectively and in line with their interests?
- What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?

We can create a hashtag (https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.


Code of conduct

 

Dear all-

Please note that I have added a code of conduct (https://github.com/BONSAMURAIS/hackathon-2019/blob/master/Code-of-conduct.md), taken from https://www.contributor-covenant.org/. Please note that adherence to this code, which I can't imagine would be an issue for anyone in this group, is a requirement for participation in the BONSAI hackathon


Re: Hackthon management/software development philosophy

 

Some more specific questions/suggestions:

- Expectation/requirement for CI testing?
- Expectation/requirement that people follow the Github PR workflow
(https://guides.github.com/introduction/flow/)?
- Expectation/requirement on implementation language?
- Expectation/requirement on (automatic) containerization? Standardize
on Docker or something else?
- Set up Python repo with expected directory structure, metadata, and
guides on how to set up docs/CI/etc.

On Sat, 23 Feb 2019 at 08:01, Chris Mutel via Groups.Io
<cmutel=gmail.com@groups.io> wrote:

Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.

I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.

I see the following key questions:
- How strict do we want to be following a particular system?
- How can we make sure that software/other efforts aren't duplicated?
- How can we make sure that each persons capabilities are being used effectively and in line with their interests?
- What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?

We can create a hashtag (https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.


--
############################
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: Hackathon concept and deliverables - request for comment

Matteo Lissandrini (AAU)
 

Hi all,

I though would be appropriate for me to help with the definition of the deliverables.
I think task "a) Matching of EXIOBASE to the BONSAI ontology set, and import into an RDF database"
would be the crucial one.

For that to be successful, that is, for the RDF data to be accessible, understandable, maintainable, expandable, and - very importantly- interoperable, we would require to move from the description of the ontology here

https://github.com/BONSAMURAIS/bonsai/wiki/Data-Storage#specify-minimum-core-data-and-metadata-formats
to a proper ontology definition + an RDF Schema.
These should be mapped and matched with existing standards and vocabularies, in particular I suggest the QB[1] and QB4OLAP [2] as vocabularies, and to link to established ontologies like GeoNames [6].

Hence, on the side of the domain experts, I would imagine the first deliverables to be pictures like the one here [3] for the ontology and here [4,5] for the schema.
These are to be accompanied with a set of URI and RDF predicates which will constitute the BONSAI vocabulary.
With similar pictorial representation and the provided URI/predicates, it would be easy for any programmer to provide the required RDF specification and translation code for the data, and for anyone else to understand and re-use or link to the data you are publishing.

The decisions about how to structure those are the crucial point where those familiar with the data and the domain can clearly provide the "added-value".

I hope the above is useful to you, and please let me know whether I should elaborate in more details about anything.
I'll be happy to help you navigate the technicalities of the specifications of course.

Best,
Matteo




[1] https://www.w3.org/TR/vocab-data-cube/
[2] https://github.com/lorenae/qb4olap/wiki
[3] http://kbpedia.org/knowledge-graph/
[4] http://tcga.deri.ie/
[5] http://qweb.cs.aau.dk/qboairbase/
[6] http://www.geonames.org/ontology/documentation.html




Re: Hackthon management/software development philosophy

tomas Navarrete
 

I have the impression that SCRUM is maybe a little too much when dealing with teams of less than 6 members. Luckily, we may end up being more than 6 ;)

- I think we can follow a light version of SCRUM, maybe with less stand-up meetings and more work (since our sprint may be too small). Something like Trello could be used to asign tasks/user stories and keep track of who is participating in which one.

- Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)

- As for quality, we could use sonar metrics as the tool ( https://www.sonarsource.com/products/codeanalyzers/sonarpython.html )  + define a base threshold for coverage. The drawback is that we would need to get used to do some checking before pushing code.

More importantly, I think that we must first to production and secondly to quality in this phase where we want to "see that it works".




"Chris Mutel" ---02/23/2019 08:01:52 AM---Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that

From: "Chris Mutel" <cmutel@...>
To: hackathon2019@bonsai.groups.io
Date: 02/23/2019 08:01 AM
Subject: [hackathon2019] Hackthon management/software development philosophy
Sent by: hackathon2019@bonsai.groups.io





Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.

I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.

I see the following key questions:
- How strict do we want to be following a particular system?
- How can we make sure that software/other efforts aren't duplicated?
- How can we make sure that each persons capabilities are being used effectively and in line with their interests?
- What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?

We can create a hashtag (
https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.


Re: Hackthon management/software development philosophy

 

On Mon, 25 Feb 2019 at 09:33, tomas Navarrete <tomas.navarrete@...> wrote:

I have the impression that SCRUM is maybe a little too much when dealing with teams of less than 6 members. Luckily, we may end up being more than 6 ;)

Thanks Tomas. As you seem to know what you are talking about here, can I nominate you as the head of this working group?

- I think we can follow a light version of SCRUM, maybe with less stand-up meetings and more work (since our sprint may be too small). Something like Trello could be used to asign tasks/user stories and keep track of who is participating in which one.

Can we use Github projects (https://github.com/BONSAMURAIS/hackathon-2019/projects)? Just to keep things simple?

- Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)

- As for quality, we could use sonar metrics as the tool ( https://www.sonarsource.com/products/codeanalyzers/sonarpython.html )  + define a base threshold for coverage. The drawback is that we would need to get used to do some checking before pushing code.

If we follow the pull request workflow, then there is no drawback - hopefully you get things right the first time, but have a chance to see the code quality reports before merging into the master branch. This has worked well for me in the past, as I always seem to forget something...


Re: Hackthon management/software development philosophy

tomas Navarrete
 

+1 for Docker ... but, on which components ? The RDF server + database ?

+1 also for the PR workflow (this is a defacto standard)

As for language, no one will deny that python is almost a de facto standard around the community, but we must not forget that the point is using the right tool for the right job.
Testing, quick prototyping in my mind is very easy with python (hence it's de facto standard). It requires much less boilerplate to be up and running. The downside would be in the docker side: miniconda3 images are huge compared to a java runtime


+1000 setting up the python repo with directory structure metadata. Like this, providing testing scripts would be easier, as well as letting others the option to work on forks and accept PRs after right code review.

This last point seems important to me because it will help to identify the concrete deliverables ;)


"Chris Mutel" ---02/23/2019 09:05:11 AM---Some more specific questions/suggestions: - Expectation/requirement for CI testing?

From: "Chris Mutel" <cmutel@...>
To: hackathon2019@bonsai.groups.io
Date: 02/23/2019 09:05 AM
Subject: Re: [hackathon2019] Hackthon management/software development philosophy
Sent by: hackathon2019@bonsai.groups.io





Some more specific questions/suggestions:

- Expectation/requirement for CI testing?
- Expectation/requirement that people follow the Github PR workflow
(
https://guides.github.com/introduction/flow/)?
- Expectation/requirement on implementation language?
- Expectation/requirement on (automatic) containerization? Standardize
on Docker or something else?
- Set up Python repo with expected directory structure, metadata, and
guides on how to set up docs/CI/etc.

On Sat, 23 Feb 2019 at 08:01, Chris Mutel via Groups.Io
<cmutel@...> wrote:
>
> Thanks for Brandon and Tomas for bringing up the principle of test-driven development. I agree that this approach is absolutely correct, but I want to open up the broader question of hackthon task management and resource planning - do we want to formally adopt something like SCRUM (https://www.scrum.org/resources/what-is-scrum)? Having participated in several hackathon-type events, I have seen several examples of poor resource management.
>
> I would very much appreciate someone volunteering to take the lead here, and create a small working group that will development a guidance document (in the Github repo) and prepare a presentation for Monday morning (March 25) introducing the approach agreed upon to the rest of the group.
>
> I see the following key questions:
> - How strict do we want to be following a particular system?
> - How can we make sure that software/other efforts aren't duplicated?
> - How can we make sure that each persons capabilities are being used effectively and in line with their interests?
> - What tools can we use to improve the quality and usability of the code produced (e.g. TDD/BDD, documentation)?
>
> We can create a hashtag (
https://groupsio.zendesk.com/hc/en-us/articles/202739265-Hashtags) for this discussion so people not directly involved can more easily filter it.
>



--
############################
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: Hackthon management/software development philosophy

Bo Weidema
 

My skills are probably best suited for working on the formalisation of the ontology, as outlined by Matteo.

Bo

Den 2019-02-25 kl. 09.33 skrev tomas Navarrete:

- Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)
--


Re: Hackthon management/software development philosophy

tomas Navarrete
 

under the SCRUM methodology, we would also need a product owner: someone capable of prioritizing the user stories / tasks

"Bo Weidema" ---02/25/2019 09:58:03 AM---My skills are probably best suited for working on the formalisation of the ontology, as outlined by

From: "Bo Weidema" <bo.weidema@...>
To: hackathon2019@bonsai.groups.io
Date: 02/25/2019 09:58 AM
Subject: Re: [hackathon2019] Hackthon management/software development philosophy
Sent by: hackathon2019@bonsai.groups.io





My skills are probably best suited for working on the formalisation of the ontology, as outlined by Matteo.

Bo

Den 2019-02-25 kl. 09.33 skrev tomas Navarrete:

    - Now that the list of participants a bit more "stable", I suggest we start identifying skills and interests so that we can create teams (and eventually make them responsible for the user stories)
--