Open Insulin group to become part of OpenCare's SSNA. How do we organise coding?

Here is the group. The question is now how we structure the process of using it for research purposes. We could:

  • tweak the APIs so that @Amelia is served its content as coding material, using OpenEthnographer. This would automatically trigger harvesting of the coded content into GraphRyder (do you confirm, @Jason Vallet ?) Very easy. Disadvantage: there is no automatic way to extricate this coded material from other coded material, it all goes into the same SSN. 
  • deploy some other method that would lead us to having not just one, but more SSN (on more than one instance of GraphRyder). 

We will have the same problem with the group collaborating on OpenVillage. The main choice here is how separate we want the data from "collaboration in action" case studies like Open Insulin to be from the main data corpus. 

Thoughts, @melancon | @Federico Monaco | @Amelia | @Noemi ?



bimodal hypothesis

Federico Monaco's picture

Hi there,

my two pennies:

is there a way to develop it in a bimodal way? with data:

a) present research: harvested by OpenEthnographer;

b) new methods to be deployed: but at the same time keep it some place else independent and useful to deploy some more methods..what about dealing with it as open source software, so that every contribution can be represented and weighted according to product version (open Insulin 1.0, 2.0, etc..)?

Is it possible to keep tracking of the data just of the OpenInsulin by a tool meant for online open production? Otherwise i'm afraid it is needed tagging by hand of the events about it...

That would make possibile -if i have understood right- to solve the problems and have new options, for instance to work with conceptual models of predictivity and exploration.



Alberto's picture

I'm sorry, @Federico Monaco , I don't understand. :-(



Federico Monaco's picture

I try in a simpler way:

would it be feasible to have on one hand the usual processing of data from tags and on a other side to analyse only the Openinsulin dataset as if it were, for instance, the process of a open source software? I follow the hypothesis of collective intelligence searching for possible material output of it.


Model vs. coding

Alberto's picture

I think I get it a bit now. Coding is coding. With OpenEthnographer you can highlight a snippet of text, then assign a code to it. That's it. You can do this with some kind of model in your head. For example, with open source software development in mind as a template for understanding the process you are looking at. But this has no bearing on the software. It will still be coding: highlight, then assign a code. 

So, we have three choices: 

  1. We don't care to perform any coding in the Open Insulin group, or
  2. We code the Open Insulin group, but we do not want those coded data to be part of the main study.
  3. We code the Open Insulin group, and we do want those coded data to be part of the main study. 

How about usign a specific group ID for each?

Jason Vallet's picture

I think this one is more in @Matthias' area of expertise, so he should correct me if I am wrong.

Right now, all Opencare discussions belong to group 5954. If different group IDs are used in the threads on OpenInsulin and OpenVillage, we become able to distinguish the posts. We then only have to create different views to fetch this content exclusively if need be. Or if we want to add these discussions to Opencare, we only have to adapt our current OC views to include those groups in the data to export.



Alberto's picture

Small bug in mentions, not annyoing enough to fix: it only works if there is a space at the end of the username. So, this does not work: @Matthias. This neither: @Matthias! But this does: @Matthias . Matt, can you read the commen above this?


One piece of content, multiple groups

Matthias's picture

The idea to differentiate by group ID seems good to me. With one addition: you can assign content to multiple groups. So if you assign OpenInsulin content always to both its own and the main OpenCare group, it would automatically be included into the main research, while also allowing separate analysis in just  the OpenInsulin group with other Views and tools.

The multi-group assignment mechanism has some limitations / bugs in Drupal, but these do not concern queries created via Views (as far as I remember). Only when using tokens, and / or URL based tests, one is limited to testing the membership of content in its main group (which means, in the first one assigned to it in the form field).

(And yes @Alberto , there are still some ways for @ mentions to not work. Needs some tricky JavaScript debugging at some point of time :-) We already have a heavily modified version of the Drupal @ mentions module, plus our own auto-suggest module, and at some point I decided that it's enough of that for the moment … I have not forgotten about it though.)


Recent activity in this group

Fri, 28/04/2017 - 04:00
Fri, 28/04/2017 - 03:49
Thu, 27/04/2017 - 17:22
Thu, 27/04/2017 - 10:06
Wed, 26/04/2017 - 15:58