On Tue, 12 Mar 2019 at 10:45, Matteo Lissandrini (AAU) <matteo@cs.aau.dk> wrote:

Hi Chris,

I've taken a look at your post, very interesting!

One thing is odd to me, you have all these modules that describe their functionality/values, and then you have "Jena database instance".

It is like you were describing how a car is made and said "A car as an engine, a steering wheel, brakes, and wheels with Michelin(r) tires"

(Complete aside, and not important, but: as a private person, you
never need to use someone else copyright/trademark/whatever symbols.
You aren't selling anything, there is no question over IP. People do
this in published papers and it drives me crazy!)

I think you can safely write there something like "RDF triplestore" or "Semantic Aware DBMS" or "Linked Data Platform" depending on what you really need. Is it just store and query RDF, for instance? Do you need first order logic reasoning? etc..

This is an excellent question! We chose (and Bo has an installed
version at Aalborg of) Jena based on a small survey that we did a few
years ago. For the time being, we are envisioning this as a dumb
triple store, where actual data processing happens externally.
However, this is mostly because I and the other people I have talked
to are much more comfortable writing Python than trying to express
ourselves in SPARQL.

Depending on your actual needs then, Jena may or may not be the tool you need.\

Let's talk about it at the hackathon!

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: Monday, March 11, 2019 10:37 PM
To: main@bonsai.groups.io
Subject: Re: [bonsai] Outreach in the buildup to the hackathon

Weekly post #3: Modular BONSAI components. Comments and critiques are welcome.

--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################

Hello,

the Bonsai enhancement proposal 0002 is now up for discussion: https://github.com/BONSAMURAIS/enhancements/blob/master/beps/0002-bonsai-project-community-governance-structure.md#bep-0002-bonsai-project-community-governance-structure

The outcomes of the discussion will be summarized in the Discussion section of the BEP: https://github.com/BONSAMURAIS/enhancements/blob/master/beps/0002-bonsai-project-community-governance-structure.md#discussion

At the end of the discussion process, which will be reached when all the relevant aspects of the BEP have been covered, a vote will be organized to validate, defer, or reject the enhancement proposal.
 
/romain

It is like you were describing how a car is made and said "A car as an engine, a steering wheel, brakes, and wheels with Michelin(r) tires"

(Complete aside, and not important, but: as a private person, you
never need to use someone else copyright/trademark/whatever symbols.
You aren't selling anything, there is no question over IP. People do
this in published papers and it drives me crazy!)

Agreed, I wrote it for stressing the point not for IP concerns :)

I think you can safely write there something like "RDF triplestore" or "Semantic Aware DBMS" or "Linked Data Platform" depending on what you really need. Is it just store and query RDF, for instance? Do you need first order logic reasoning? etc..

This is an excellent question! We chose (and Bo has an installed
version at Aalborg of) Jena based on a small survey that we did a few
years ago. For the time being, we are envisioning this as a dumb
triple store, where actual data processing happens externally.
However, this is mostly because I and the other people I have talked
to are much more comfortable writing Python than trying to express
ourselves in SPARQL.

I'm not questioning here the technical choice re the software.
My point is that you are "masking" the functionality you need with the name of a technology that should implement it.
This has 2 effects (i) you commit yourself to a specific software in a place where such decision is not necessary
(ii) your model is missing important information (which is assumed implicitly but it is not so): what functionality you need there.

Depending on your actual needs then, Jena may or may not be the tool you need.\

Let's talk about it at the hackathon!

Sure :)

Btw. Not sure what the relation is between Jena&Python

I really like the idea of a beginner's toolbox, with a presentation of tools that are expected to be used to produce relevant outputs for BONSAI.
I find myself sometimes dubitative as to where and how to contribute, as the project is both complex and vast.

But then, the types of deliverable needed in BONSAI are very wide: we need to format raw data, we need pieces of scripts that maybe scrap environmental data from the Internet, that sort of things.

Maybe we should categorize the types of contributions into a few general categories (e.g., raw data and formatting, database inter-operability, etc.) and present what we think is a relevant toolbox.
 
I guess you will have a clearer view about that after the hackathon.

Would not it make sense for such toolbox page to be on bonsai.uno, under a "Getting started" tab?

/romain

The draft getting-started guide is here. It currently describes how I perceive the state-of-affairs to be now (regarding task management, prioritisation etc.). As such, it is not really yet fit-for-purpose. I don't yet know how to contribute toward simple, manageable, useful tasks. So describing this is rather difficult!

In order to be most useful, Romain & I agreed that we want the getting-started page to link directly to specific tasks. But we find those tasks are described in various places in different ways (Wiki, website, hackathon agenda, blog posts etc.). So we realised that this needs to be solved in order for the Getting Started page to function properly. We agreed that GitHub issues are a sensible choice for this. I've dogfooded a suggestion to use them for Bonsai here. And started converting the Wiki task list into Issues in the same repo. An issue relating to completing the getting-started guide is also here.

Other suggestions such as "a sort of toolbox for beginners to bonsai", are beyond my reasonable scope at this time. Great if someone wants to make this, but perhaps tangible Bonsai software contributions could be a higher priority!

Dear all-

I created the beginning of a BEP based on Tom's audit here: https://github.com/BONSAMURAIS/enhancements/blob/bep4-communications/beps/0004-bonsai-communication-strategy.md. My idea was to make our ideas a bit more specific by using the BEP to provide details, and also to make us think about alternatives and why we are confidant that one direction is best. However, we can continue to use the #KnowledgeManagement tag, as the BEP is nowhere near ready.

For example, I am not sure why the wiki is the best place to host a getting started guide, or general introductions to B. The webpage not only gives us more freedom in terms of what we can show (no limits on embedded media), but I don't think the wiki provides a substantial ease of use advantage versus e.g. writing markdown and having an automatic processor to create HTML.

Some of these issues are most easily discussed in person, around a big sheet of paper, where we can draw different designs. For example, I don't see why the homepage wouldn't have a little search box allowing you to search to ontology/product list, as well as a dynamic widget that would allow you to do calculation based on the current database state. That would be awesome, and a clear differentiator with other DBs - but impossible on the wiki.

I would prefer to get a clear line between what content goes on the wiki, and what on the web page.

Dear all-

The legal entity BONSAI, a not for profit organization headquartered in Denmark, supports the efforts of the broader BONSAI project with fund-raising, substantial in-kind contributions, and IT. Pursuant to a decision by the organization's board of directors on March 12, 2019, and in accordance with the recent burst of activity related to the hackathon, we are actively soliciting nominations for two new members to the board of directors. We are looking for passionate people who are motivated to help move the entire BONSAI project forward. Keeping with the BONSAI core values of openness, inclusivity, and respect for different opinions, we are especially interested in candidates who would bring a diversity of locations, backgrounds, and experience to the organization. Board membership is not compensated - everyone is a volunteer.

The new board members will be elected at the next BONSAI general assembly, which will be held on Wednesday, May 8, from 17:00 to 18:00 Central European Time. Please note that participation in the general assembly is limited to BONSAI members (https://bonsai.uno/contribute/ - note that as of today the membership fee has been reduced to €50 for active BONSAI participants), but board candidates do not have to be members.

To nominate yourself, please draft a statement of motivation and a CV/similar, and either respond directly to this email if you want your nomination to be public, or email me at chris.mutel@... to limit your nomination to BONSAI members. 

Please send this call to people you think would be interested!

-Chris Mutel, Chair of the Board

Great initiative! I think that a default time for discussion should be set and mentioned in the template. A default time could be 3 weeks from the publication of the BEP.

The template might also mention that the editor could modify (extend or shorten) the time depending on specific needs or the activity and liveliness of the discussion. For example, if no discussion occurs for 10 days the editor may propose to close the discussion if a decision is urgent (as perhaps in this case, since this template is already being used), or extend the discussion if there is lack of consensus (e.g. on controversial methodological issues).

The template could also mention that "the editors should never take the role of a judge of whether a suggested change should be implemented or not - it isn't their role to take potentially controversial decisions. (Chris M)"

Michele

For clarity, this is a discussion on the BEP-0001 BONSAI (BEP) Enhancement Proposal Template. 

The following is a follow up of the discussion started (wrongly) here, where I proposed to include in the template a short description for the procedure to actually implement/reject modifications to the BEPs.

Following Chris' input, I'd summarize the procedure that could be mentioned (depending on the type of BEP) in this proposal as:

1. BEP result of working groups already reflect some level of consensus, and will have a history of how the specifics came to be. In this case the group is the primary and preliminary place for discussing the proposal, before it is made public.
2. Once the BEP is public, the authors will implement the suggested changes that they do not object or motivate the rejection on the respective BEP discussion list. Since the proposal has to be agreed by the broader community, it is in the interest of the authors to agree to reasonable change requests - otherwise the proposal won't survive a vote.
3. Depending on the BEP. the author may chose to invite anyone to suggest a change (via pull request, not a half-baked idea via email) that will be voted by the community. This could lead to vote overload and it should therefore be used only when necessary. Fewer votes would mean that people pay more attention when they come up.
4. The author or the editor may invite the participant in the discussion to a call with the objective to reach consensus if this has not been reached yet in the within agreed or due time (a proposal on adding a default discussion time was made here).

Michele

Dear all-

I have added some of these changes in
https://github.com/BONSAMURAIS/enhancements/pull/6.

However, I think we need to have a broader discussion on who and how
to suggest changes. The current language suggest that only authors can
make changes, but maybe we don't want this. One can imagine a worst
case scenario where the authors reject one change, but the rest of the
community wants it - then we are faced with the choice of rejecting
the whole BEP or not.

I would love to hear some options/opinions on this!

--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################

Hello,

with Tom, we would like to suggest the use of Issues, Labels and the more general Project board features of GitHub to better visualize the long-term tasks described in the Wiki and benefit from the functionalities they provide (discussion, level of completion, assigning workforce, etc.).

This would allow us to quickly see who volunteers for which tasks, the priority level, etc., and hopefully better understand the work to be done and how far we've come.
Also, I find it particularly convenient for discussing and exchanging ideas within a given task.

As a try out, we've populated the Issues section with a few items (high-level tasks, as described in the Wiki), associated labels and milestones to them. Labels and milestones are jsut tehre for "illustration purpose" and we need to refine them, should we agree to manage tasks that way. You can them see then in the Projects tab within the BONSASAMURAIS/bonsai repo, divided in "to do", "in progress", "to be reviewed" and "done" categories. You can also filter out the tasks to be displayed on that board (should there be too many of them) by label (priority labels, for example).

Issues: https://github.com/BONSAMURAIS/bonsai/issues
Project board: https://github.com/BONSAMURAIS/bonsai/projects/2

Let us know what you think and we'll complete it further.

/romain

This looks great.

Perhaps we could modify the boards to be more reflective of BONSAI
stages? For example, I think we need something like "Concept-building"
for the tasks text mining and data scraping, as "to do" might mean
projects that are ready for execution, but don't have have volunteers
yet. Similarly, our review process (at least for now) is the BEP, so
instead of "needs review", we could have "proposed", drop "reviewer
approved", and change "done" to "accepted".

--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################

Depending on the output of the communication plan, it might make sense to have this project board not be attached the "bonsai" repository, but for the entire BONSAMURAIS organization, i.e. here: https://github.com/orgs/BONSAMURAIS/projects/2. This would allow you to directly link issues from all the different repos, and would allow the "bonsai" repo to become more tailored to just the wiki (if that is what is proposed).

The BONSAI 2019 General Assembly will be held on Wednesday, May 8, from 17:00 to 18:00 Central European Time.

Participation in the General Assembly requires membership in the BONSAI non profit association, which costs €150 a year, or €50 for active BONSAI participants. Members will receive a separate email with conference details.

You might also be interested in a few other BONSAI governance changes, which are detailed at the end of https://chris.mutel.org/bonsai-governance.html, as well as the BONSAI statutes: https://bonsai.uno/files/statutes.pdf.

OK then, we'll try to move that to the first level.

/romain

The issue though with moving the Project board to the first level (BONSAMURAIS), is that BONSAMURAIS is not really a repo in itself (it's more a like front page) and hence, and one cannot create Issues within it, it seems. It's a bit annoying. We can make a project board and populate it with Issues, but those Issues have to remain in one of the repos (e.g., bonsai). So the question is to know what the repository "bonsai" should really be about...

>So the question is to know what the repository "bonsai" should really be about...

Correct. My opinion is that the project board should be under the "Main" Bonsai directory because:

• it is becoming increasingly hard to figure what has been posted where; it will become even more so when the resources increase. Thus, a "root" folder with the project board would be welcome.
• several projects may concern the hackathon as much as the longer term Bonsai goals and some of the sub-groups for the hackathon too. In these cases, under which directory should the project item be listed? Under the sub-group directories, the hackathon directory or the Bonsai directory?
• some of the sub-groups have some dependencies. It would be an advantage to have a common directory that we will all have to access to find the project board, regardless of the sub-group we contribute to. 
• the project board should have links to the tasks described in the wiki, which is un the Bonsai directory

PS: the name of the root GitHub, BONASMURAI (instead of BONSAI), is due to the fact that the latter name was taken.

Michele