We are working on a proposal on something called energy citizenship (codename: PARTENAIRE). Here is the concept note. Research-wise, the main idea is to run two things:
A classic ER-style SSNA study on communitarian use of energy and energy tech.
Participant observation on three (possibly four) sites where energy communities are forming and launching local initiatives around energy. Presumably, these will be:
one in a very working class neighborhood in Bologna.
one in a ājust transitionā area, probably Poland or eastern Germany.
one in an ecovillage.
The classic-ER part of the study is going to happen in English and in writing ā no argument there. But the work on the ground in the sites is going to be mostly oral, and in the respective local languages, also no argument. That leaves us with the problem of integrating the two layers.
To a first approximation, I was thinking of having ethnographers deployed on the ground that are native to the local languages, or as good as, but also fluent in English. They will be the ones to relay (in Engligh) the what happens onsite to the online conversation. Then, the coding happens only in English, though we do allow people to write on the forum in whatever language. We also encourage community members on the ground in the test sites to join the conversation online, but we know most people will not.
Iām not sure how to do better. I think in this model the key is picking the right people to do the work on the ground. They would have to do all that you describe but also know enough about energy issues and solutions that they could pick their way into the less obvious examples. Going to an eco village is pretty easy. But many projects and setups are just people trying to do something interesting and worthwhile and are not quite so easy to find.
@hugi, what about using the same kind of coding that we use to identify ācharactersā in the Babel OE for this? So as the ethnographer, youāre the one posting the story, but you code it with the same kind of ācharacterā code, except that code is the true informant. That way you donāt lose the association of the informant (the one giving the interview) with their own input. And then you could even start to see how the ideas of particular informants, those off the platform, interact with those who are on the platform.
Do you mean, to post the interview in video form and then code it? It would present the same issues ā the poster would still be an ethnographer and not community member, and community member wonāt be on platform to have a conversation. Also, multimedia coding isnāt great for something like an interview ā better to code the transcription, so you have the underlying annotations saved as well in easily accessible form. The reason to use the multimedia function rather than a transcription would be to take notes on a live event or an art form, where thereās more going on than just speech. Otherwise, much better to transcribe and code. Coding a video would also take a really long time, so it needs to be worth it in terms of the value-added e.g. be more than just someone talking, be observational data too.
@johncoate just asked me on a Riot about the time-consuming nature of transcription ā ethnographers use automatic transcription software like dragon and otter.ai to make that faster, then edit the errors, so if we are doing a lot of transcription we should definitely invest in a software to augment the process.
Using the character coding method would be one way, certainly. Itās very easy. You just define a suffix for a code, like ( C) for character or (I) for informant, and then introduce an alternative view where you can see the concepts cluster around informant codes, which can be colored differently. This is interesting because it allows you to see at a glance how groups of informants cluster around concepts. This method has the benefit of being very easy to apply and nearly working out of the box, we just had to do a few minor modifications of Graphryder.
Another way could be to introduce a second āuserā class for informants who are not, themselves, posting on the platform. It could work like this:
An ethnographer in the field keeps field notes on pen and paper, transcribing interviews but also conversations between informants in the field, as well as their own observations
When they digitize their notes, they actually assign the transcribed text to Discourse users that they themselves create. This is very easy if they use the form software to create new users.
If they are transcribing a conversation between many informants, that becomes a thread. These threads will obviously not be very easy to read, but are rather a structured way to keep notes on a conversation.
Technically, they transcribing notes happens in three steps. First, posting all the texts and threads from their own user account. Then creating the āmockā informant user accounts, for example with a certain suffix like _informant. Finally, reassigning all the posts to the right āmockā user account.
All of the above could be made very easy if we were to devise a script that imported field notes structures in a certain way. For example, treating each new text file as a new topic, and keeping track of who said what through some simple syntax. Field notes could then be imported into Discourse in batch and new informant users created as needed.
We would then create ways to filter and visualize the graph in Graphryder so that it becomes apparent where the data comes from. For example by:
Separating the user graphs of the field informant account user nodes and real user nodes
Allowing filtering of the correlation graph to include codes mention by the online conversation, the field conversation, by either or by both.
This method has the benefit of keeping the social part of the SSNA methodology. We can still keep track of the interactions in conversations. It has the other added benefit that if a field informant later becomes a participant in the online conversation, they can choose to adopt some or all of their transcribed contributions to their own user account.
Making user accounts was my second thought, yes! Weāve discussed it before (and somewhere on platform thereās a list I made on this) ā the best (if they donāt want to post themselves) is if we can make them user accounts and post their contributions as them. Itās more labour intensive but does preserve the social part of SSNA better.
This is also how Iād approach this. (Means, letās not use Open Ethnographer codes for anything but meta-data about the content of the coded text. Metadata about the author etc. is the concern of Discourse.)
Here is a quick outline of how Iād create this piece of software:
Data format. Markdown with some wrapper format to encode a dialogue. Ideally weād use an established format that ethnographers use to note down dialogs before coding them. Or alternatively a format that falls out of transcription software that is able to recognize multiple speakers (if such a thing exists). Or alternatively a cross-platform-compatible format used by online forums to represent dialogues. The format should allow to assign sections both to new and to existing Discourse accounts.
Import destination. The transcriptions of offline dialogues should by default not be publicly visible, because it is out of context and also requires the consent of the original speakers to publish it online. It should however be accessible to ethnographers by placing it into categories accessible by Discourse group annotator. It should also be accessible to the artificially created accounts of speakers by means of assigning a newly created Discourse group.
Import function. Importing the dialogs should be a feature of the Open Ethnographer backend, not of external tools or scripts. Because in the interest of software quality, Open Ethnographer should become a coherent whole in the end, not a wild collection of scripts of which nobody has an overview, or knows which versions of the scripts are compatible with one another.
Re-import function. A frequent use case will be that an ethnographer prepares a transcript, imports it to Discourse, then refines the transcript and imports it again. If no annotations have been added to the previously imported content, this should automatically replace the previously imported content.
Export function. For completeness, we might want to add a function that can export Discourse topics in the same format that the import function expects. This makes sense if there is indeed a standard format that ethnographers use to represent dialogs, in which case this export function allows the integration of Open Ethnographer with other QDA tools.
Effort estimation: 2.5ā4 person months, targeting the same software quality that Open Ethnographer has right now, and then some more (āwell usable, but some rough edges remainā).
