Gjalt-Jorn Peters' website

Behavior change using medical analogies

Gjalt-Jorn Peters — Sun, 19 Oct 2025 22:00:00 GMT

Warning

This is a draft - it will be updated later.

Probably 😬

This is a brief thread / blog post about how concepts from behavior change science would map onto medical concepts.

If you’re seeing this in the fediverse, the URL to the blog post is https://sciencer.eu/posts/2025-10-behavior-change-using-medical-analogies.html.

The vocabulary we use here is based on the Intervention Mapping protocol. If you want to check these more in depth, you can have a look at the Acyclic Behavior Change Diagram article at https://doi.org/jp9t, or the glossary for the Intervention Mapping Work Book at https://im-wb.com/glossary.html.

Where in behavior change science we focus on addressing issues in society or at a larger scale where human behavior plays a role, medicine is concerned with issues in the human body. The analogy for the behavior we ultimately want to change is therefore a disease.

When a disease is cured or changed a behavior is changed, medicine and behavior change science’s job is done; so in a way we started at the end of the story.

The story begins with the diagnosis. In medicine, this process establishes what exactly the situation is and how the disease at hand can be targeted. In behavior change science, this consists of two things:

1️⃣ the needs assessment, to establish the broader context; 2️⃣ and determinant studies to establish what exactly should be targeted.

Especially determinant studies can be considered similar to the differential diagnosis: is the cause habits, perceived norms, or attitudes?

Once the diagnosis has been made, to address a disease, medicine uses, well, medicine. The analogy of a medicine is a behavior change intervention.

This medicine works through a mechanism of action. This is the theoretical process through which it targets whatever it targets.

Such mechanisms of action are clever exploitations of nature.

They leverage dynamics that generally evolved for wholly different purposes. For example, some medication binds to certain receptors or mimics a hormone.

This analogy also holds for the mechanisms of action in behavior change interventions. These mechanisms of action are the behavior change principles (behavior change methods in Intervention Mapping terms).

In medicine, the mechanisms of action are based on an understanding of the human body: anatomy, physiology, neurology, etc. Because we have theories about how the human body works, we can design medication that works with the natural processes that make our bodies work.

In behavior change science, the mechanisms of action are based on an understanding of the human psyche: health psychology, social psychology, cognitive psychology, etc. Because we have theories about how the human psyche works, we can design interventions that work with the natural processes that make our mind work.

Like in medicine, the mechanisms of action of behavior change science (i.e. behavior change principles or behavior change methods) are abstract, theoretical descriptions of how such natural psychological structures and processes can be leveraged to make certain changes.

For example, modelling relies on vicarious learning; the evolved learning process where organisms can learn through observation of other organisms. Because these behavior change principles leverage structures and functions that exist for very different reasons, correct application is a very delicate process.

To stick to the modeling example: modeling does not work when the audience does not identify with the used role model, or when the role model is not positively reinforced, or when it is a mastery model instead of a coping model, or when the audience does not have the requisite skills.

If one deviates from these parameters, the way the behavior change principle is applied in the intervention does not approximate the underlying evolved learning processes enough, and no learning will occur (in other words, the audience’s psyche will stay unchanged; and therefore, ultimately, so will their behavior).

In medicine, the analogy is found in things like dose (e.g. most medication has the desired effect at the right dose but does nothing at lower doses and can become toxic at higher doses) and molecular structure (e.g., benzylpenicillin or penicilin G treating syphilis and pneumonia with side effects including seizures, but phenoxymethylpenicillin or penicilin V treating otitis media with side effects including nausea).

Finally, in medicine, the mechanisms of action operate on specific structural or functional parts of the human body, lowering or increasing blood pressure, making blood thicker or thinner, or causing certain neurotransmitters to be released or inhibited. These dynamics are used to achieve a desirable state that should make the person more healthy.

In behavior change science, the mechanisms of action operate on specific structural or functional parts of the human psyche, lowering or increasing attitude, perceived norms, habits, or self-efficacy. These dynamics are used to achieve a desirable state that should make the person more healthy.

So, now the full causal-structural chain that underlies our model of why medication and interventions work is complete:

1️⃣ The mechanism of action [🧠 behavior change principle 🔄️ ⚕️pharmaceutical principle];

2️⃣ is applied [within its 🧠 parameters of use 🔄️ ⚕️ chemical constraints];

3️⃣ in a concrete implementation [🧠 practical applications 🔄️ ⚕️pills];

4️⃣ that targets specific elements [🧠 sub-determinants 🔁 ⚕️physiological variables];

5️⃣ that belong to an overarching cluster [🧠 determinants 🔁 ⚕️anatomical structure];

6️⃣ that causes an intermediate target [🧠 sub-behaviors 🔄️ ⚕️symptoms];

7️⃣ that is a part of the ultimate target [🧠target behavior 🔄️ ⚕️disease].

Free and easy and versatile QR codes

Gjalt-Jorn Peters — Tue, 16 Sep 2025 22:00:00 GMT

This is a Mastodon thread. The original thread is available here:

This is a brief thread / blog post about how to create QR codes in a way that’s free, easy, and versatile, using the userfriendly open source application @Inkscape@mastodon.art

By the way, the blog post URL is https://sciencer.eu/posts/2025-09-free-and-easy-and-versatile-qr-codes.html.

QR codes are very useful to efficiently share information (usually URLs).

QR codes are quite versatile and robust; they’re not too demanding in terms of colors and shapes, and even have a degree of error correction allowing them to still be ‘legible’ to QR code readers even if part of the QR code is obscured.

This allows you to create QR codes consisting of circles, pills, or other shapes; in red, blue, or pink; and embed shapes such as logos while still keeping their functionality.

A number of websites exist that can help you do this, but there’s a better solution: the awesome open source application InkScape.

This quick & dirty blog post / Mastodon thread briefly talks you through that process.

First, if you don’t have it yet, get @inkscape@mastodon.art from https://inkscape.org and install it in the version for your operating system.

Then open InkScape and open an empty document. Open the “Extensions” menu, and in the drop-down menu, open the “Render” submenu. In that submenu, open the “Barcode” submenu, and in that submenu, select the “QR Code…” option.

In the QR code dialog, you can copy-paste the URL (or other text) you want to encode in the QR code. You can also select the error correction level (from Low, where 7% of the QR code can be recovered, via M(edium, about 19%) and Q(uartile, about 25%) to H(igh, about 30%).

In that dialog you can aldo set other things. For example, the “Clones” section allows you to use, instead of the default QR “squares”, any shape you desire. The QR-code simply using the shape you have selected when creating the QR-code. You may have to play around a bit with the size of the object to get things working as you want.

Then, hit “Apply” and the QR code is created. It consists of a number of objects (well, they’re called “paths” in InkScape; there’s something else that’s actually called an object - sorry for the confusion!). First, a group of the background (a larger white square) and the foreground (the QR code squares/objects). That foreground is a group of all the tiny little squares.

First, select the QR-code group and ungroup the foreground and background so you can delete (or adjust) the background. You do this by rightclicking it and selecting “ungroup”, or by selecting it and hitting CTRL-SHIFT-G.

Then edit it further (you may want to ungroup into separate objects/paths first). You can edit the colors, and if the level of error correction you chose allows it, you can place a white square (or other color/shape) in front of some of the QR code and place a logo (or some text) inside it.

When you’re happy, don’t forget to adjust the page to the size of your QR code (SVG files have a kind of ‘page’ displaying the content). To do that, open the File menu and select the Document Properties option.

In the dialog that then opens, click the “Resize to content” button to, well, resize the page to the content.

If you’re a scientist, check this post too, about pro conference tips: https://sciencer.eu/posts/2024-08-open-science-conference-contributions-pro-tips.html

(actually, unfortunately, the OSF meetings service was discontinued… 😭)

And that was it! I hope it’s useful to somebody 🙂

ROCK Basics

Gjalt-Jorn Peters — Fri, 06 Dec 2024 23:00:00 GMT

Warning

This blog post is still a work in progress!

The Reproducible Open Coding Kit, the ROCK, allows you to do qualitative research in an Open Science way. It is a so-called Open Standard and a number of Open Source applications exist to work with ROCK files. This blog post is meant as a brief introduction to this standard.

Starting from coded ROCK sources

The simplest ROCK source

A very very minimal coded ROCK source might look something like this:

Being proud of oneself: is a
self-conscious emotion or self-directed [[emotion]]
emotion. It is based on considerations
of social standards and/or evaluation [[social]]
by oneself or by others.

Two codes are applied here. The first is identified by code identifier “emotion”, and the second by code identifier “social”. Each code identifier is delimited by two square brackets to designate that they represent the application of a code to a data fragment.

The key of the ROCK standard is that this coded source can be read by both humans and computers. The first enables easy sharing of coded data: people don’t need to install specific software to be able to understand what you did. The second enables processing by computers to do everything that software for qualitative analysis can do.

Each line of this source is a data fragment. In the ROCK, such a data fragment is called an “utterance”, and utterances are the shortest codable segment of data. They are separated by line breaks.

Adding more information

It is good practice to attach unique identifiers to each utterance as well, so as to enable unequivalent reference to them as well as easily compare coding from independent coding efforts. Such identifiers are prepended to the utterances (so they don’t distract from the data). They are called UIDs (Utterance Identifiers), and you can see examples in the source below.

In addition, you often want to encode data provenance (e.g. the data provider). These are attached using so-called class instance identifiers. These identify instances of classes, where a class can be, for example, participants, the time of the data collection, the questions asked in an interview, or who coded the interview. Class instance identifiers look the same as utterance identifiers: they start with the class identifier (e.g., participantId), followed by an equals sign (=) or a colon (:), and end with the instance identifier (e.g., base).

If we add this to the rudimentary example source, it looks like this:

[[uid=7xf3dl1g]] [[participantId=base]] [[tssid=20240901T0700Z]]
[[uid=7xf3dl1k]] 
[[uid=7xf3dl1l]] [[taskId=label]]
[[uid=7xf3dl1m]] 
[[uid=7xf3dl1n]] pride
[[uid=7xf3dl1p]] 
[[uid=7xf3dl1q]] [[taskId=definition]]
[[uid=7xf3dl1r]] 
[[uid=7xf3dl1s]] Being proud of oneself: is a
[[uid=7xf3dl1t]] self-conscious emotion or self-directed [[emotion]]
[[uid=7xf3dl1w]] emotion. It is based on considerations
[[uid=7xf3dl1x]] of social standards and/or evaluation [[social]]
[[uid=7xf3dl1y]] by oneself or by others.

As you can see, one of the benefits of UIDs is that they enable efficient reference to a specific data fragment (‘utterance’). Within a source, the last three characters of a UID suffice as unique references, so we will use these to further discuss this source.

On the line identified by l1g we see only two class instance identifiers. [[participantId=base]] encodes that these data were provided by a participant with identifier base, and [[tssid=20240901T0700Z]] is the so-called “time-stamped source identifier” (the TSSID). This is the minute the data collection started in ISO 8601 standard format and converted to the UTC timezone. Together with UIDs, TSSIDs are a virtually guaranteed unique reference to any data fragment from any qualitative data collection.¹

On the line identified by l1l, we see [[taskId=label]]. Apparently, what follows now are data provided for that task (label). Knowing what that task entails requires knowing more about the study itself (these data are from the Alice study, see here). The data that follows is one the line identified by l1n: the word “pride”, which has not been coded yet.

On the line identified by l1q, [[taskId=definition]] tells us that the next section of data relates to the second task, identified as ‘definition’. These data are the data fragments we saw earlier, on the lines identified by l1s to l1y.

The ROCK standard describes how software can process ROCK sources such as this example. Software that does that (such as the {rock} package in R, or the Shiny ROCK Feldspar web app that processes one or more sources into what’s called the Qualitative Data Table) will then label all data following a class instance identifier with that identifier.

As such, after processing the data, it’s clear that the data on the line identified with l1n belongs to task ‘label’, and the data on the lines identified by l1s to l1y belongs to task ‘definition’. For all data, it’s clear they belong to the participant identified by base, and that they came from the source identified by 20240901T0700Z.

These class instance identifiers can also be used to attach attributes to data fragments. For example, participant base may be somebody who, at the time of data collection, was aged between 22 and 30, identified as a woman, and resided in a rural area. They will be attached to all data fragments coded with the corresponding class instance identifier - in our example, all data, since this class instance identifier was on the first line.

If another class instance identifier for another instance of the same class appears later in the source, from that point on the attributes of that class instance will be attached instead. Attributes can be specified in a ROCK source in the YAML format, which will be explained below.

Now, it’s time to dive a bit into the idea of the ROCK standard.

The ROCK fundamentals

The ROCK format has a number of features, but for now I’ll focus on the most commonly used ones.

A ROCK file is a so-called plain text file. Plain text file are pretty self-explanatory: they’re files with text - plain text. So unlike text processor files, they have no markup: no bold, no italic, no bulleted lists, no tables, no hyperlinks, nothing. Kieran Healy wrote an excellent introduction with The Plain Person’s Guide to Plain Text Social Science, as did Tim Elder with Introduction to Plaintext for Research and Writing.

The ROCK uses plain text because it’s the most open file format there is. Anybody can open plain text files; in fact, pretty much all operating systems come with plain text editors.

The ROCK file extension

File extensions are the last characters of the filename, the ones following the period (.). They tell computers and humans about the type of information in a file. Some common file extensions are .jpg for photographs, .html for webpages, .mp3 for audio files, and .txt for regular plain text files. Some operating systems even go so far so as to hide the file extension from users, instead showing icons to represent the file type. The extension for ROCK files is .rock, so this is how you can recognize ROCK files.

ROCK codes

The ROCK standard consists of two things: concepts and conventions on how to represent them in plain text files. The concepts are the most important part, but also invisible: they embody a set of decisions on how to represent coded qualitative data.²

The way the ROCK represents coding (i.e. the application of a code to data), on the other hand, is very visible. Most codings are delimited by double square brackets, which contain one or more identifiers, such as code identifiers or class identifiers and class instance identifiers.

Identifiers (“ids” for short) are unique character sequences that represent something; for example, a code or a person. Identifiers start with a Latin letter (a-z or A-Z), followed by one or more Latin letters, Arabic digits (0-9), and/or underscores (_).

Coding patterns

The following coding patterns are defined.

Basic coding patterns

First the three we already saw:

[[codeId]]: the simplest coding just applies a flat code, without specifying any relationship to other codes.
[[classId:instanceId]] or [[classId=instanceId]]: class instance identifiers encode data provenance; either the origin of the data, such as the data provider (e.g. a participant), data collection location (e.g. a venue), or coder (e.g. a researcher). Class instances can be used to efficiently attach attributes to data fragments; for example, label all data provided by a participant from a rural area as such.
[[uid:xxx]] or [[uid=xxx]]: Utterance identifiers enable unequivocal reference to specific data fragments. They are also required to compare or merge codings from independent coders.

Advanced coding patterns

There are three more advanced patterns. The first is supported by most qualitative software:

[[parentCodeId>childCodeId]]: a hierarchical coding, or tree coding, specifies a parent-child relationship between codes.

The other two are as yet unique to the ROCK, and are mostly used for Advanced Qualitative/Unified Analysis (see below):

[[codeId||value]]: this specifies a value for the code referenced by the code identifier. This is useful for registering values inductively. For example, age or gender identity, but also categories or degrees, for example to code the intensity of statements.
[[fromCodeId>toCodeId||edgeCodeId]]: a network coding specifies a generic relationship. Unlike with hierarchical/tree coding, it is possible to specify the type of relationship. In addition, structures don’t need to be nested necessarily. This is discussed more in detail inb the Qualitative Network Approach (QNA) section below.

Structural coding patterns

In addition to specifying code identifiers to indicate how you want to code data, you can also specify the data structure in the ROCK. To do this, you use structural coding patterns.

Segmenting the data

The first type are section breaks, used to segment the data. These look as follows:

--<<sectionBreakId>>--

They enable analysing the data per segment, for example collapsing the codings per segment. You can use multiple segmentation schemes in parallel by using different section break identifiers (note that segmentation decisions can have far-reaching implications; see doi.org/j5sx).

Nested data

For data that are nested (e.g. social media data where posts reply to other posts), this nesting can be indicated using tildes (~), for example:

~ This is a post.
~~ This is a reply to that post.
~~~ This is a third reply.

Anchors to enable synchronization

Finally, anchors can be used to attach timestamps, useful to synchronize multiple data streams. Anchors look like this:

--+-{ anchorId }-+--

As with all identifiers, the anchor identifiers have to be unique; and they have to have the exact same order in all sources to be synchronized.

Advanced Qualitative/Unified Analysis (AQUA)

As mentioned above, the ROCK supports Advanced Qualitative/Unified Analysis (AQUA). In this blog post, three AQUA analyses will be briefly covered: Anchor-based Stream Synchronization, the Qualitative Network Approach, and Qualitative/Unified Exploration of State Transitions.

Anchor-based Stream Synchronization

Sometimes you have multiple data streams that you want to code and analyze together. In that case you will want the data streams to be synchronized, so that the codes correspond to roughly the same moments in time.

To this end, you can specify anchors as described above. This makes it possible for software that supports this functionality to synchronize multiple streams to a primary stream. If you want to do this, you have to include, in addition to anchors, class instance identifiers to identify the source and the stream. Specifically, the class identifiers to use are sourceId and streamId.

The following fragment of a coded source shows how this can look:

[[uid=7xy80zrp]] [[sourceId=participant6]] [[tssid=20241219T0954Z]]  
[[uid=7xy80zrq]] [[streamId=interviews]]
[[uid=7xy80zrr]]
[[uid=7xy80zrs]] --+-{ 2024-12-19 09:54 }-+--
[[uid=7xy80zrt]] 
[[uid=7xy80zrw]] At first, we were just friends.
[[uid=7xy80zrx]] However, soon I started developing feelings

For an application of Anchor-based Stream Synchronization, see doi.org/nxdj.

Qualitative Network Approach (QNA)

To explain QNA, we’ll first zoom out a bit. In qualitative research, your data collection is usually aimed at being as “lossless” as possible: you aim to register everything that is relevant, erring on the side of registration. As a consequence, you often collect audio or video data. To systematically detect patterns in the data (in a way where we make it as hard as possible to fool ourselves), we devise codes that define those patterns, and we attach those codes to the data where we identify the pattern. This simplest mode of code organization is called flat coding.

Because “everything is related”, as it were, the phenomena we study are also usually related to each other. Therefore, we often want to also code relationships. The simplest way to do this is to nest codes within each other. This mode of code organization is called hierarchical or tree coding.

However, hierarchical or tree coding requires that code relationships are all the same type (and the types of this relationship is usually not specified). Often, codes can be related in different ways; and not all relationships are nested.

In those situations, you can use network coding, as implemented by the Qualitative Network Approach (QNA). When you use QNA, you always specify three codes: one representing at which code the association starts; one representing at which code the association ends; and one represention what type of association you observed. For example, if you code an interview transcript and somebody expresses the belief that drinking coffee causes them to feel energetic, you could use [[coffee->energetic||causal_positive]].

Software (like the {rock} R package or the Shiny ROCK Crystal web app can then parse a coded source and produce the network that was coded, visualizing the relationships you observed.

For example, this fragment of coded data:

[[uid=7yww3938]] When I'm tired, I often get cranky. [[tired->cranky||causal_pos||1]]
[[uid=7yww3939]] In general, such things matter for my mood. [[cranky->mood||structural||1]]
[[uid=7yww393b]] For example, when I'm hungry, I also get cranky. [[hungry->cranky||causal_pos||1]] [[hungry->cranky||causal_pos||1]]
[[uid=7yww393c]] And when I have coffee, I feel cheerful. [[cheerful->mood||structural||1]] [[coffee->cheerful||causal_pos||1]]
[[uid=7yww393d]] But that's also because it's a drug I think. [[coffee->drug||structural||1]]
[[uid=7yww393f]] And coffee also makes me feel less tired of course. [[coffee->tired||causal_neg||1]]
[[uid=7yww393g]] My mood is also influenced by the weather. [[weather->mood||causal||1]]
[[uid=7yww393h]] Actually, the weather also matter for how hungry I get. [[weather->hungry||causal||1]]
[[uid=7yww393j]] For example, if it's very warm, I get much less hungry. [[warmWeather->weather||structural||1]] [[warmWeather->hungry||causal_neg||1]]

Produces this network:

Code

Ethical AI Use in Academia

Gjalt-Jorn Peters — Fri, 20 Sep 2024 22:00:00 GMT

This blog post describes some considerations around ethical use of artificial intelligence, or in most cases more accurately, stochastic parrots, in academia. I will start by describing use in scientific research, and then discuss use in teaching.

Guidelines for ethical work in academia

I will assume that ethical use of AI requires at the very least adherence to the following two sets of guidelines.

Open Science

Open Science principles have seen widespread adoption by the UN (see the UNESCO recommendation on Open Science) and pretty much every other influential actor and university. Therefore, they can be considered as wordwide parameters for academic work, both research and teaching.

Open Science principles cover many aspects of the scientific endeavour, with various perspectives. Three important ones are those of the UNESCO (see here), the EU (see here), and the Netherlands Open Science Program (see here).

UNESCO

UNESCO emphasizes that all infrastructure and products for the scientific endeavour must be open and free. Some aspects they describe are open source software, open hardware, and open science infrastructure. They also list core values and guiding principles. The listed core values are quality and integrity; collective benefit; equity and fairness; and diversity and inclusiveness. The listed core principles are transparency, scrutiny, critique and reproducibility; equality of opportunities; responsibility, respect, and accountability; collaboration, participation, and inclusion; flexibility; and sustainability.

EU

The EU lists a number of notable Open Science practices, including providing immediate and unrestricted open access to scientific publications, research data, models, algorithms, software […]. The EU Open Science Policy Platform also lists eight core areas, often called pillars, of Open Science: 1) rewards and incentives, 2) indicators & next-generation metrics, 3) future of scholarly communications, 3) European Open Science Cloud (EOSC), 5) FAIR data, 6) research integrity, 7) skills & education, 8) citizen science.

Dutch Open Science Program

The Dutch Open Science Program defines four core values: Quality and integrity; Collective benefit; Equity and fairness; and Diversity and inclusiveness. They translate these into the following guiding principles: Scientific knowledge is a public good and access to it is a universal right; Scientific outputs and processes must be as open as possible, but as restricted as necessary; Reproducibility and scrutiny are essential to safeguard the quality and integrity of scientific work; Diversity, equity, and inclusiveness are crucial for the success of Open Science; Academic and digital sovereignty must be safeguarded. In this last principle, they explicitly state:

To guarantee scientific knowledge as a public good for collective benefit, it is important to consider the sustainability, governance, and financial models of scholarly infrastructure, (retention of) copyright and open licensing of scientific work. The risks of becoming more and more dependent on commercial or foreign providers and their terms of use in all stages of the research life cycle asks for open (not-for-profit) alternatives for digital services and regulation.

The Netherlands Code of Conduct for Research Integrity

One thing these key stakeholders in the Open Science landscape have in common is that integrity is a core value. This shows how scientific integrity and open science are intertwined. This becomes even clearer when inspecting the Netherlands Code of Conduct for Research Integrity. This code of conduct defines five principles: Honesty, Scrupulousness, Transparency, Independence, and Responsibility.

This code of conduct is binding to all Dutch universities, universities of applied science, academic medical centers, funders, and related organizations. Other countries have similar codes of conduct, and the basic tenets will be the same.

For scientists, integrity is not an optional nice to have. At all times, scientists must be transparent, accountable, independent, scrupulousness and responsible.

Parameters for choosing scientific infrastructure

Both Open Science principles and scientific integrity principles mandate that scientific infrastructure is fully open and transparent (so, open source); that the applications and tools forming this infrastructure are developed in an integreous manner, responsibly and sustainably, and for the collective benefit of mankind; and that academic sovereignty is safeguarded.

The responsibility to consider these principles lies with both the individual scientist and at the institutional level. Institutions must survey their scientific infrastructures (their enterprise architecture choices, so to speak) and plan for phasing out closed (commercial, industry-owned) applications in favour of open science alternatives (open source and community-owned). Individual scientists must carefully evaluate the nature and provenance of any new tools they consider exploring or adopting.

Requirements for using AI in scientific applications

Applied to uses of AI (which I here use loosely to encompass large language models, other generative AI, and machine learning applications), the following requirements emerge (I use the word ‘tool’ as an umbrella term to encompass all aspects of any AI application, including the software and any underlying models):

the tool is fully open source
the provenance of the tool is fully transparent
the tool was developed ethically
the tool can be used sustainably
the tool is controlled by academic or public organizations

Applying these requirements: ChatGPT and OpenAI

These requirements mean that, for example, the generative AI products produced by OpenAI can not be used for scientific work. OpenAI practices pretty much the opposite of openness (see this comparison by Mark Dingemanse). Their tools are not open source, but neither are the procedures they use(d) to develop the tools (i.e. the provenance).

However, investigative journalists revealed that they exploited Kenyan workers to train their large language models; very emotionally taxing, potentially traumatizing work, for excessively low salaries and without proper support (see here, here, here, or here. Without this training, their LLMs would spit out the racist, sexist, violent content that large swaths of the internet consist of.

Keep this crucial human training of a generative AI model in mind; we will come back to this later.

In addition, they knowingly imported works protected by intellectual property law, then refusing to be open about what they ingested ‘to avoid being sued’ (see here, here, or here.

In addition to these unacceptable practices, once constructed, the use of generative AI models is excessively costly in terms of the required energy (and so, harm to the planet; see for example here, here.

Using (free or paid) products that were developed with these methods cannot be commensurated with the principles in the scientific code of conduct and the open science principles.

This is true for any use of AI tools developed Big AI / Big Tech by scientists, including seemingly trivial use cases such as summarizing an email, meeting notes, or just for fun. Use of these products creates more value for this industry, an industry that clearly has no regard for the collective benefit of humandkind, planetary health, or intellectual property.

Epistemology and Sovereignty

However, specifically when applying such AI tools to the scientific endeavour (not just answering emails, but conceptualizing studies, collecting data, or conducting analyses), there is an important additional problem with using AI tools developed by industry organizations.

One of the reasons why academic sovereignty is so important to safeguard, as set out in the open science principles outlines above, is that scientists’ jobs are epistemic in nature. We produce knowledge, ideally ultimately to make the world a better place. The process of knowledge production is not neutral or objective; it is a subjective endeavour, rife with bias and influenced by politics and human convitions. The transparency and openness mandated by scientific integrity codes of conduct and open science principles partly serve to mitigate this unfortunate truth.

Any scientific enterprise consists of a plethora of decisions: which sampling strategy to employ, which analysis to use, which tools to use, the list goes on and on. Each of these decisions has epistemic implications. More concretely, the tools scientists use shape the way they produce knowledge in a variety of ways.

For example, the fact that the widely used quantitative analysis package SPSS only implemented Cohen’s d in version 27 (released in 2019). Cohen published his landmark book on power analysis and effect sizes in 1977, with a second edition published in 1988. In 1977, SPSS was on version 2; in 1993, version 5 was released, and in 1999, version 10. The fact that Cohen’s d was only included in SPSS in 2019 has considerably slowed down its widespread adoption in the social sciences, and as a consequence, adoption of sample size computation when planning studies.

Similarly, software for qualitative data analyses typically lets users label qualitative data fragments using codes organized hierarchically. This constrains how scientists construe the patterns in the data they analyze to hierarchical structures. For example, the analysis usually results in a code structure; the same code structure for all participants, requiring the assumption that the patterns of interest exist identically in all participants. In addition, Scientists typically do not specify what kind of hierarchical relationship exists between codes. Both characteristics of the used tools fundamentally change the knowledge that is created through those studies.

Both examples show how software fundamentally changes how knowledge is generated in the social sciences. Many things now considered “psychological knowledge” because of quantitative or qualitative research are in fact far from the truth, partly because software implicitly or explicitly favoured certain epistemic alternatives over others.

It is the responsibility of the researcher to be aware of their epistemic aims and keep these in mind when determining their ontological and epistemological stance, the theory to use, the methods to employ, as well as the operational procedures, including whichs tools to use. For example, it is common for researchers to select one analytical software package over another based on the analyses that are supported.

When using AI tools in scientific applications, whatever is produced is determined by the company developing the model. For example, the instructions provided to the Sama workers who trained OpenAI’s ChatGPT to stop spewing out sexual abuse, violence, and other problematic results shaped the responses the system will provide and which are trained out of the system. Any use of this system is constrained by the parameters provided by OpenAI.

In addition to this deliberate influence to determine the system’s output, the system’s input does not represent an unbiased sample of the human mind. This is because online activity differs per age group, country, and with other characteristics; and in addition, OpenAI made a lot of decisions when they decided which sources to ingest and which to ignore.

In other words, OpenAI controls what is returned by their generative AI models. This is the same for other Big AI models. Not only do they have full control over what the models produce, because the models and their development procedures are not fully open, biases cannot be spotted.

Applications of these AI tools in the scientific endeavour fulful an epistemic role; as such, using such tools delegates this responsibility from scientists and universities to exploited workers retraining AIs and their Big AI employers in Silicon Valley. Relocating this epistemic responsibility from academia to industry while simultaneously ‘academy washing’ the efforts seems quite inconsistent with the code of conduct for scientific integrity, as well as with open science principles such as protecting academic sovereignty.

Open Science Conference Contributions: Pro Tips

Gjalt-Jorn Peters — Thu, 29 Aug 2024 22:00:00 GMT

At conferences, people often present slides and/or posters. Ideally, these help interested researchers to find you and your work, so in the old days it was common to bring handouts of your poster or slides for audience members to take - or hand out business cards.

Nowadays, most scientific infrastructure is digital. For example, most professional conferences now use Open Science Framework (OSF) Meetings pages to collect slides and posters so they can be easily found by other researchers.

This creates an awesome opportunity to help people find your slides or poster, link them to related work, and/or make it easier for them to find other slides or powers from the same session.

OSF Meetings

OSF Meetings is a great resource for sharing conference materials. For a list of OSF meetings pages for Health Psychology conferences, please see https://hpss.one.

Once an OSF Meetings page for a conference has been created, it’s supereasy to add slides or posters:

Compose a new email from your OSF account address (no account yet? See the tip in the box below)
Address it to an address like “X-poster@osf.io” or “X-talk@osf.io”, where you replace X with the conference name in the OSF Meetings page URL (e.g. “EHPS2024”)
As the email subject, use the title of your poster or presentation
As the email body, include the abstract
As the attachment, include the PDF of the poster or slide deck
Hit send

Tip: OSF accounts and email

Multiple emails

OSF accounts support multiple emails. You can click your name in the top-right corner; then go to My Profile, and then visit the Account Settings. You can add Alternate emails there (and switch which one to use as primary email, which is where OSF will email you). You can send emails to OSF Meetings accounts from any of your primary or alternate emails.

Creating an account

If you don’t have an OSF account yet, you can also create one at https://osf.io/register before sending the email.

The Open Science Framework then creates a new repository with the file you sent. That file is then also displayed in the list at the OSF Meetings page.

Being ahead and in control of things

Now, the trick is: you can edit that repository like any other OSF repository! This is great, because you can do the following:

Use the “wiki” component to link people to other cool resourced: related publications, your Mastodon or other social media profike, your OpenAlex profile, a blog, etc.
Link to other OSF projects or components
If you’re in a symposium, create another repo for that symposium, and then link to each of the contributions’ repo’s

But most importantly: you can also update the file later (as long as you do it by uploading a new version of the file, so you won’t be able to change the filename any more).

This means you can do the following:

Create a first draft of your slides or poster
Give it a sensible filename (I always use author1--author2---year---title.pdf - I use dashes to separate the components because spaces are best avoided, see this excellent slide deck) - remember, you won’t be able to change it later!
Email it to the OSF Meetings page for your conference as explained above
Get the URL to the shiny new repo that OSF will create
Include that in your poster or slide deck, ideally with a QR code (see below)
When your poster or slide deck is done, update the file in the OSF repo, et voila!

You now have a super-easy way for people to find your slides or poster, plus all the other stuff you want to link them to, and your contribution is easy to find through the conference’s OSF Meetings page! 👌

And as a cherry on the cake, you can request a DOI for the repository! 🍒

That helps people to cite your poster or talk. And finally, the final touch: after about 24 hours, the DOI will have been ‘minted’ (as it’s called) by CrossRef. Once that’s done, you can then generate a ShortDOI for the DOI at https://shortdoi.org!

That means you have a better, shorter URL (e.g. https://doi.org/mh3s), which also makes for a better QR code (fewer, larger blocks, making it easier to scan from a distance)! 🤩

Creating QR Codes

There are several ways to create a QR code.

For quick and dirty situations, I use the Tab2QR (Firefox, Chrome) browser plugin to create a PNG file.

For more serious situations (e.g. slides or other more ‘high stakes’ situations where I want more control, I use the awesome InkScape. There is a great explanation of how to create a QR code with InkScape here: https://daviesmediadesign.com/how-to-generate-qr-codes-in-inkscape/.

One advantage of using InkScape is that you get an SVG file, which you can scale up as much as you want without it ever becoming ugly (as you get when enlarging low-resolution images).

A second advantage is that you can set the ‘error correction’; with low error correction, you get a simpler QR code (fewer, larger blocks, making it easier to scan from a distance); but with higher error correction levels, the QR code contains redundancies so it can still be reconstructed if part of it is obstructed when it’s scanned.

And that allows you to insert, for example, a logo in the QR code 🤩

There also exist various websites where you can create QR Codes; you can use search engines to find those. I have no recommendations as I never use them myself 😬

A pro tip for pros

Finally, if you’re in a symposium, there’s one last step to really round things off. Before submitting the symposium abstract, you can create an OSF repository for the symposium. You will later link to the separate contributions’ repositories as explained above.

You can then create a DOI for the symposium repo, and then a ShortDOI. And you can then include that in the abstract. This way everybody with the abstract book can easily find your contributions!

Code book elements

Gjalt-Jorn Peters — Mon, 10 Jun 2024 22:00:00 GMT

A codebook specifies the codes used to organize data.

For quantitative data, code books describe what each data series represents, linking the variable names (for rectangular data such as spreadsheets, these are the column names) to more details about the data series’ provenance (for example how those data were obtained, which categories are represented by which values, et cetera).

For qualitative data, such as coded sources from interview studies (e.g., transcribed audio recordings) or systematic reviews (e.g., extracted text fragments), code books describe what each code represents, linking the code identifiers as used in the coded sources to the code label, definition, and coding instructions.

This blog post concerns qualitative code books, and will describe which elements a code book should have and why.

What is a code?

In this blog post, a code is defined as the interface between a theoretical concept and empirical data. The code is used to label bits of a qualitative data source (such as data fragments in a transcribed interview or parts of a text fragment extracted from a scientific article). To fulfill their function of linking a theoretical concept to empirical data, codes have a number of components.

Code identifier

The code identifier is a short sequence of characters that uniquely identifies the code in a project. The identifier (or id for short) is used to label (or annotate or mark) data fragments as being coded with that code. That act signifies the coder’s observation that the data describes or otherwise expressed the theoretical concept that the code represents.

Code identifiers may only consist of lower ([a-z]) and upper case ([A-Z]) Latin letters, Arabic digits ([0-9]), and underscores (_) and must start with a letter. Because code identifiers must be unique, if you use a hierarchical organizational mode for your codes (i.e. tree coding as opposed to flat coding or network coding), it is often a good idea to include an abbreviation for the parent code in the code identifier.

For example, let’s say you have codes for advantages (let’s use code identifier adv) of various holiday destinations (let’s use identifier slugs beach and city). You use holiday destinations as parent codes (or clusters, or themes). You cannot then use the code identifier adv to represent both the advantages of beach holidays and the advantages of city holidays: those refer to different things and so should have unique identifiers. You can use for example beach_adv and city_adv as identifiers so it’s unequivocal what you code a data fragment with.

Code label

The code label is the human-readable name for a code. Because identifiers secure the ability to uniquely refer to a code, code labels do not need to be unique. In the above advantage, you could use the code label Advantages for both beach_adv and city_adv. However, this would still be messy; future you (and other researchers) will probably not be very grateful for that particular decision.

Code labels have no rules; they just have to be short. You can describe the concept that the code represents more fully in the code description.

Code description

The code description describes the concept that the code represent in as much detail as you want. Or, more accurately, maybe more detail than you want, but as much details as possible and useful. If you give somebody the code label and this description, they should obtain the same representation as you have. This means it’s important to be careful to avoid tacit knowledge, jargon, and other terms that themselves may be heterogeneously defined by people.

In qualitative work, it is often said that the coding phase represents the analysis of the data. That work does not consist of applying codes; that work consists of iterative improvement of the codes, as specified in the code book. It can be tempting to pay lip service to the code book once you and your project team have consensus about the codes you want to use. After all, documenting things is time consuming; and by making your assumptions about your shared representations explicit, it may turn out you didn’t quite agree as much as you thought beforehand. This prompts more discussion and maybe changes of the code description.

It is important to keep in mind that that is a feature, not a bug. The result of those discussions will be a comprehensive description of the theoretical concept you are interested in; one that is clear to all project members as well, hopefully, to others. The product of the coding exercise is the development of the theoretical concepts the codes represent, and that work is done through code explication.

For example, imagine a project where we are interested in why people have the sleeping patterns they do. One code may be Descriptive norms (i.e. that’s the code label), with identifier descriptive_norms, and its description could be:

Descriptive norms are defined as somebody’s perception of the behavior of others in their environment (so-called “social referents”). Note that this is different from injunctive norms, which refer to somebody’s perception of the approval or disapproval of social referents.

(For more information about descriptive norms, see https://psycore.one/descriptiveNorms_73dnt5zp.)

Coding instructions

The coding instructions differ from the code description in that they describe when to apply the code, when not to apply the code, and which other codes to consider before deciding which code to apply. Coding instructions therefore do not describe the concept the code represents (as code descriptions do) but instead provide specific instructions to follow when evaluating data fragments as ones you potentially want to code with a code.

An example from the hypothetical project into sleeping patterns would be the instruction for the descriptive_norms code:

Apply this code when a data fragment expresses that somebody engages in certain sleeping pattern-related behavior because (they believe) other people do the same. This code should not be applied to people going to bed earlier or later in response to other behaviors of others (e.g. going to bed later because housemates play music until a late time).

Contrast this with the description: this is much more focused on the operational act of coding, not on defining what the code represents.

Examples

Code development often happens at the hand of concrete examples: data fragments that you decide do or do not “fall within” a code. Similarly, concrete examples can help people to understand what your code represents “in the real world” and what it doesn’t. Together with the label, description, and coding instructions, the examples furnish the reader (which includes future you) with the full understanding of what the code represents, both conceptually and in its interface to empirical data.

Examples fall within four categories, defined by two characteristics. An example can be either an edge case (where whether the code should be applied or not is not directly obvious) or a core case (where the code should clearly be applied or not applied); and an example can be either a match (where the code should be applied) or a mismatch (where the code should not be applied).

The four categories of code examples, then, are core matches, core mismatches, edge matches, and edge mismatches. By having a few examples of each, you make it clear to everybody what exactly you mean by the code (and what you don’t mean).

A machine-readable code book specification

There’s a standard for machine readable code book specifications. There is an example at https://rock.science/codebook.

How to create a Tabulated Open Questionnaire (TOQ) specification

Gjalt-Jorn Peters — Wed, 10 Apr 2024 22:00:00 GMT

In this brief blog post, I describe a number of steps you could take to create a Tabulated Open Questionnaire specification.

Tabulated Open Questionnaire specifications (or TOQ specs for short) are questionnaires described in an open standard. This allows converting them to Serialized Open Questionnaire specifications (or SOQ specs for short), which in term can be included in open repositories such as https://operationalizations.com. For more background information, you can check the brief blog post / Mastodon thread Towards interoperability for psychological data.

The examples in this blog post are taken from the TOQ specs for the questionnaires with UQID URLs https://operationalizations.com/questionnaire/eq60eng_7rs8g3bd and https://operationalizations.com/questionnaire/bfi10eng_7sp9mjx3.

This post starts with a step-by-step guide to specifying a new questionnaire. That guide is followed by a full description of the spreadsheet format.

Specifying a new questionnaire

If you want to specify a new questionnaire in TOQ format, first copy an empty TOQ specification, for example that at https://measurement.rocks/toq-spec-example (click the File menu and select “Make a copy”).

The questionnaire label

Then, in the metadata_content column, in the row that has “label” in the metadata_field column, type the name of the questionnaire. The recommended format has the name, followed by, between parentheses, the language as an ISO-639-3 code and the number of items.

The questionnaire language

In the language_ISO639_3 row, specify the questionnaire’s language. This is the language used for the verbal stimuli presented to participants, for example in the questions, in the introduction, or in any other way.

Specify the language as an ISO 639 3 standard code. You can find these at https://iso639-3.sil.org/code_tables/639/data, through https://en.wikipedia.org/wiki/ISO_639-3, or through a variety of other resources.

The Unique Questionnaire Identifier

Then, produce a Unique Questionnaire Identifier (UQID) for the questionnaire. This consists of two parts. The first part is called the uqid_prefix, and you create it yourself. It can only contain Latin letters (a-z and A-Z) and Arabic digits (0-9) and must always start with a Latin letter. The recommended format is a short acronym for the questionnaire, followed by the number of items, and then the ISO 639-3 language code for the language, for example “eq60eng” and “bfi10eng”.

The second part is a string of characters as produced by the {psyverse} R package (see the manual at https://psyverse.opens.science) or the Elsa Shiny App (see https://opens.science/apps/elsa. So either visit Elsa or fire up R and create the full UQID.

The measured construct(s)

Another important field to provide content for is the ucids field. Here, you can specify a URL linking to a comprehensive construct definition using it’s Unique Construct Identifier (or UCID), such as https://psycore.one/personality_79n2fh4s or https://psycore.one/expAttitude_expectation_73dnt5z1. Make sure to use the URL format (unlike for the UQID), so that the construct definition is immediately available (without people having to find out which construct repository it’s stored in).

This is a field that can be repeated on multiple rows; the metadata_field content is ucids on every row, and by specifying a different UCID URL in the metadata_content column, you can specify multiple constructs that you think should be measurable with the questionnaire you’re adding.

If there is no construct definition stored yet, you can either add it yourself (see https://doi.org/jnjp), contact others and add it together, or leave ucids field empty.

Sources

Often, one or more articles or websites will be available with more background information on the questionnaire. You can specify these in content on rows identified with sources in the metadata_field column. Like ucids rows, the sources rows can appear multiple times, so you can specify multiple sources.

If you specify scientific sources, try to find the Digital Object Identifier (DOI) for the source, and enter it at https://shortdoi.org to obtain the corresponding ShortDOI. ShortDOIs are very handy short unique identifiers for articles, chapters, and other objects with a DOI. ShortDOIs have a number of advantages over DOIs, such as being short 😬 – but also only consisting of Latin letters [a-z] and Arabic digits, [0-9], which means they can be (part of) filenames or column names in datasets (unlike DOIs, which contain slashes (/) and can contain other special characters). Therefore, ShortDOIs are used by the {metabefor} system for systematic reviews to unique identify sources (such as articles), which is another reason to use them here, too.

Regardless of whether you managed to obtain a ShortDOI, enter the sources as URLs, for example https://doi.org/djzd32, https://doi.org/dbh (how awesome is that?!? A three-character unique identifier for an article 🤩), or something like https://measures.scienceofbehaviorchange.org/measuredetails/da946282-a16c-46cf-a67c-40a2eb47d398.

Ontology references

In some cases, you may want to refer to an ontology, for example to a representation of the construct or the measurement instrument. You can use ontologyRefs for this. Like rows for ucids and sources, rows for ontologyRefs can be repeated to specify multiple references. And like for those two fields, make sure that you enter a valid URL that resolves to the relevant element in the relevant ontology.

The questionnaire description

In the description row, you can briefly describe the questionnaire. There are dedicated fields for more specific information, so you don’t have to go into too much detail (see below).

The measurement theory

A measurement instrument like a questionnaire is always based on a theory of how the measurement instrument works. This often involves the target construct and how the answers people give to the questions somehow crucially depend on that target construct. You can specify this as the measurement_theory. If you don’t know the measurement theory, you can also specify that (and then hopefully you can add it in a later version).

Note that while, if we take the idea that questionnaires can measure constructs seriously, the measurement theory underlying the questionnaire is very important, when adding questionnaires to a repository, specifying the measurement theory in detail is not your main responsibility. Also, many questionnaires are developed without corresponding measurement theories. Although that is a problematic practice, it is also often simply a fact of life, and should not prohibit those questionnaires from being added to an open repository.

Therefore, your primary task here is to be as transparent as you can. If as far as you know there is no source describing the measurement theory, it’s ok to just say that. If there might be sources but you don’t have time to look, similarly, just say that. And if you suspect the measurement theory to be described in a given source, but you don’t have time to read it, it’s also ok to say that.

Often, the important thing is to specify the questionnaire and its items in a machine-readable format (in the TOQ spec). That will also facilitate further work on the questionnaire’s measurement theory. There will be ample opportunity to specify that later.

The measurement scope

Questionnaires (and other measurement instruments) are developed with certain constrainsts. For example, thermometers generally only work on Earth and in a narrow range of temperatures (only -40 to 50 degrees celcius). Similarly, questionnaires also only work for specific populations in specific circumstances. This scope is described here.

For example, if a questionnaire has only been studied among a very narrow, specific population (for example, first- or second-year psychology students in the Netherlands), it is unknown how it will perform in different populations (for example, students in other studies; or students in other countries; or the general population in the Netherlands; or the general population in other countries; or parents with one or more children; or people who are retired; or adolescents; etc).

For scope, like for measurement theory, the most important thing is to maximize transparency. Describe what you know. Doing this already enables others to build on this, for example by adding extra information they have about the scope where we know the questionnaire can be used.

The composition, administration, and aggregation

TOQ specs were developed as a machine-readable (and so, interoperable) format for questionnaires. They contain the most important parts: the questions (and ‘flanking’ content). However, the way these components need to be composed into one questionnaire can differ. For example, if a certain font needs to be used or a certain paper color, or the items need to be presented in a certain way, this can be specified in the composition_instructions.

Sometimes, there are specific procedures or requirements for the administration of a questionnaire (i.e. the procedure used to present the questionnaire to participants and register the responses). This can be provided as administration_procedure.

Often, the data series produced by participant responses to each item are somehow aggregated into one or several (if there are subscales) data series. For some questionnaires, this can mean averaging the data series for all items; for others, it can mean summing them; sometimes, some items have to be inverted first (e.g. by subtracting the data series from a number, e.g. for 5-point likert scales scores 1-5, subtracting every value from 6), and sometimes, a questionnaire has multiple subscales, and those are aggregated to arrive at multiple final estimates. Whatever the procedure is, it can be described here in the aggregation_procedure_narrative.

TOQ spec version, date, and authors

The version of the TOQ specification is stored in metadata field toq_specification_version. Note that this is the version of the TOQ specification format, not of the contents, which is specified in the version metadata field. Four other fields that start with toq_specification_ do refer to the contents: the date field and three repeated fields with author information. Specifically, these are toq_specification_date for the date of the TOQ specification (this occurs only once) and toq_specification_authorNames, toq_specification_authorOrcids, and toq_specification_authorContacts, each of which is a field that can repeat on multiple rows if multiple people specified the TOQ. The authors of the questionnaire specified in the TOQ spec can be found through the sources.

Precursors

Precursors are questionnaires that preceded the questionnaire. These can be earlier versions or otherwise related questionnaires. These are stored in metadata field toq_specification_precursors, which can be repeated if there are multiple precursors. These should be the UQIDs of the relevant specifications, including the full URL (i.e. starting with the repository’s URL).

Comments

If you have any additional comment,s you can specify them as comments.

Worksheets in a TOQ spec

A TOQ spec is a spreadsheet with six worksheets (each will be explained in detail below):

metadata: metadata about the questionnaire
items: the items in the questionnaire
response_registration_templates: templates that describe how participants’ responses are registered
adapters: information about how adapters should convert the questionnaire to their corresponding formats
flanking_content: “non-item questionnaire content”, such as an introduction or closing message
content_types: the content types that can use used to specify the stimuli that comprise the questionnaire

The `metadata` worksheet

The metadata worksheet has two columns. The first is named metadata_field and the second is named metadata_content. In each row, the metadata_content cell holds information that is identified by the metadata_field column.

Each field (as identified in the metadata_field column) can only occur once (i.e. on one row), with three exceptions: the ucids field, the sources field, and the ontologyRefs field can occur multiple times.

The metadata fields that can occur are the following:

label: A human readable label (title or name) for the questionnaire. The recommended format is “Name (Language, # items)”, for example “Empathy Quotient (English, 60 items)” and “Big Factor Index (English, 10 items)”.
uqid_prefix: The prefix of the Unique Questionnaire Identifier (UQID). This can only contain Latin letters (a-z and A-Z) and Arabic digits (0-9) and must always start with a Latin letter. The recommended format is a short acronym for the questionnaire, followed by the number of items, and then the ISO639-3 language code for the language, for example “eq60eng” and “bfi10eng”.
uqid: The full UQID, which consists of the UQID prefix, an underscore, and a string of characters as produced by the {psyverse} R package (see the manual at https://psyverse.opens.science) or the Elsa Shiny App (see https://opens.science/apps/elsa.
ucids: One or more Unique Construct Identifiers (UCIDs), in the URL format (for example https://psycore.one/personality_79n2fh4s). These UCID URLs link to comprehensive construct definitions of the construct(s) that this questionnaire measures.
sources: One or more URLs to source(s) with more information about this questionnaire, preferably using the ShortDOI format for articles, for example https://doi.org/djzd32 and https://doi.org/dbh.
ontologyRefs: One or more URLs to relevant entities (or, classes, attributes, etc) in an ontology.
description: A description of the questionnaire.
language_ISO639_3: The language of the questionnaire, as ISO639-3 code (e.g., to list the 10 most spoken languages: “eng” for English, “zho” for Chinese, “hin” for Hindi, “spa” for Spanish, “fra” for French, and “ara” for Arabic, “ben” for Bengali, “por” for Portuguese, “rus” for Russian, and “urd” for Urdu).
measurement_theory: The measurement theory underlying the measurement instrument. This explains the assumptions and theory that valid measurement relies on.
measurement_scope: The scope of the measurement instrument. Just like most thermometers only work on Earth and in a narrow range of temperatures (only -40 to 50 degrees celcius), questionnaire also only work for specific populations in specific circumstances. This scope is described here.
composition_instructions: Instructions for composing the measurement instrument from the items and the flanking content. This can be, for example, something like “Typically, the items are presented in a matrix/array format (with the question texts in rows and the response options in four columns).”
administration_procedure: The procedure used to administer the measurement instrument. For example, whether participants can be disturbed while completing the questionnaire; whether there is any additional instruction that has to be provided verbally by the administrator; whether the participant has to be in quiet surroundings or whether that doesn’t matter; etc.
aggregation_procedure_narrative: A narrative description of the aggregation procedure for the data series formed by participants’ responses to the items. For example, responses to some items may need to be transformed (for example, subtracting the resulting value from another value, to invert them); and the data series can be averaged or summed, etc.
toq_specification_version: The version of the TOQ specification - note that this is the version of the TOQ specification format, not of the contents, which is specified in the version metadata field.
toq_specification_date: The date of the TOQ specification
toq_specification_authorNames, toq_specification_authorOrcids and toq_specification_authorContacts: The names, Orcids, and contact information for the people specifying the TOQ. Note that the authors of the questionnaire specified in the TOQ spec can be found through the sources.
toq_specification_precursors: Questionnaires that preceded the questionnaire, e.g. earlier versions or otherwise related questionnaires. These should be the UQIDs of the relevant specifications, including the full URL (i.e. starting with the repository’s URL).
version: The version of the specification. For example, you may want to update information about the measurement scope as you learn more about how the measurement instrument works / performs. Note that if you change items, you cannot assume that you don’t change the nature of the measurement instrument, so you should update the identifiers (and so, technically, you are creating a new measurement instrument).
comments: Any comments you may want to make.

The `items` worksheet

The items worksheet has the following columns:

sequence: Numbers that indicate the order of the items in the questionnaire.
uiid_prefix: The prefix to the Unique Item Identifier (UIID). This prefix is a more or less human-readable component of the UIID the helps with quick identification of the item. The prefix does not have to be unique; the other components of the UIID takes care of that. The UIID prefix can only contain Latin letters (a-z and A-Z) and Arabic digits (0-9), and must always start with a Latin letter. The recommended format is to use one word (or two, or three; as few as possible) to describe the item content. Examples are reserved and enterConverse.
uiid: The item’s full Unique Item Identifier (UIID). The recommended format is to start with the questionnaire’s UQID prefix, followed by an underscore, followed by the UIID prefix, followed by an underscore, and a string of characters as produced by the {psyverse} R package (see the manual at https://psyverse.opens.science) or the Elsa Shiny App (see https://opens.science/apps/elsa. Examples are bfi10eng_reserved_7sp9pd51 and eq60eng_enterConverse_7rs8rnq8.
question_text: The text of the question, in the format specified in the content_type column. Together with the item’s response registration template (see the rrTemplateId column) the question text forms the item.
rrTemplateId: The item’s response registration template. This is a response registration template identifier of a response registration template described in the response_registration_templates worksheet.
content_type: The content type of the question text. At present, this can only be “html” (for HTML), “text” (for plain text), and “markdown” (for Markdown formatted text). In principle “image”, “audio” and “video” can also be used, but at present, none of the adapters process those content types yet.
subscale: Optionally, a subscale of the item. These can be referred to in the content for the aggregation_procedure_narrative field in the metadata worksheet, to enable aggregating subsets of items.
comments: Any comments you may want to make.

The `response_registration_templates` worksheet

This worksheet has the following columns:

template_id: The response registration template identifier. All response options with the same response registration template identifier together form that response registration template. Response registration template identifiers can only contain Latin letters (a-z and A-Z) and Arabic digits (0-9), and must always start with a Latin letter.
response_option_content: The content of the response option, in the format specified in the content_type column.
identifier: The response option identifier within the response registration template. Response option identifiers can only contain Latin letters (a-z and A-Z) and Arabic digits (0-9), and must always start with a Latin letter. This will be used by SOQ or TOQ adapters and can be used to unequivocally and efficiently refer to a response option in a questionnaire.
content_type: The content type of the response option. At present, this can only be “html” (for HTML), “text” (for plain text), and “markdown” (for Markdown formatted text). In principle “image”, “audio” and “video” can also be used, but at present, none of the adapters process those content types yet.
response_option_sequence: Numbers that indicate the order of the response options in each item.
response_option_value: The value to register when this response option represented participant’s response.

The `adapters` worksheet

This worksheet contains information for SOQ and TOQ adapters: software that can convert a questionnaire specified in a SOQ or TOQ specification to another format. This enabled automatic creation of files that can be imported into software for data collection, such as LimeSurvey or {formr}, or even closed science (paywalled) software such as Qualtrics.

Each row in this worksheet specifies a directive for an adapter by specifying the field name and the contents. These directives are read by adapters to parametrize their conversion of this questionnaire.

This worksheet has the following columns:

target_format: The format for which this row specifies a directive. This is used by the relevant adapter when it reads this worksheets and collects its directives. As such, this has to be meaningful given how the adapter is written (i.e. it has to look for rows with these values).
target_wikidata_id: If available, a wikidata identifier for the format to which the adapter will export.
uiid: Either a star (*) to indicate that this directive pertains to all items, or the UIID to which this directive pertains.
field: The field for which this row specifies a directive.
content: The directive’s content.

The `flanking_content` worksheet

This worksheet has the following columns:

position: Whether the content should appear before or after the items.
sequence: If multiple bits of content are specified, their order.
content: The content to present.
content_type: The content type (see the content_types worksheet).

The `content_types` worksheet

This worksheet enables processing different content types in different ways. Its has the following columns:

id: The content type identifier.
comments: Any comments about this content type.

Towards interoperability for psychological data

Gjalt-Jorn Peters — Wed, 20 Mar 2024 23:00:00 GMT

This is a Mastodon thread. The original thread is available here:

From Monday the 18th of March 2024 to Thursday the 21st of March 2024, Rik and me had a writing week in Leuven ✍️🍻

During this week, Rik worked on a Narrative Response Model for a self-efficacy item (more later, for example in our EHPS symposium in Cascais 💃), and I worked on a repository for psychological questionnaires ✅

I’ll explain a bit in this Mastodon Thread and blog post (at https://sciencer.eu/posts/2024-03-towards-interoperability-for-psychological-data.html).

Loads of repositories exist already, so let me explain what’s so different about this one and why I’m currently so stoked about the progress 🤩

So, Rik and me are working on trying to work our way out of the theory crisis and the measurement crisis. I try to summarize this in https://sciencer.eu/posts/2022-12-knowing-what-we-re-talking-about–mastodon-thread.html.

Part of our proposed solution is using comprehensive construct definitions that have Unique Construct Identifiers, UCIDs (also see https://doi.org/jnjp).

However, these have limited value if they cannot be linked to measurement and data.

In addition, most existing repositories for questionnaires (‘scales’) suffer from a number of problems that I’ve been aching to address for a while now:

1️⃣ They are often not open infrastructure. The database and interface are often not publicly available for anybody to copy, adjust and run.

2️⃣ They often do not link to unique construct identifiers that are built on open infrastructure (although they often have system-specific unique identifiers).

3️⃣ They often are not openly machine-readable (for example with an API).

4️⃣ They often do not allow easy conversion of a questionnaire to import them into open software.

This new repository is built upon a number of existing open tools:

1️⃣ The same Quarto website that underlies the Psychological Construct Repository (https://psycore.one);

2️⃣ Open standards for specifying questionnaires in machine-readable formats, with identifiers for questionnaires and single items;

3️⃣ The {psyverse} R package to work with the specifications we designed (https://psyverse.opens.science);

4️⃣ The {limonaid} R package for working with LimeSurvey (https://limonaid.opens.science).

All this is wrapped together to create the repository of which the first so-fresh-it’s-not-even-beta version is live at https://operationalizations.com.

The little ecosystem consists of a number of things (spread over two Mastodon posts, sorry 🤷):

👉 A way to set up a spreadsheet to specify questionnaire content in a Tabulated Open Questionnaire specification (a TOQ spec).

👉 A way to assign Unique Questionnaire Identifiers (UQIDs) to questionnaires.

👉 A way to convert a TOQ into a Serialized Open Questionnaire specification (a SOQ spec) in YAML format.

👉 A Quarto site that embeds a set of TOQs in a website with an interface for humans and one for machines.

👉 A Shiny app that, when you provide a UQID, imports the SOQ spec from that repository and produces a LimeSurvey group file (a .lsg file) that can then be directly imported into LimeSurvey.

Because TOQs and SOQs contain a field to specify one or more Unique Construct Identifiers (UCIDs), it’s always clear what a questionnaire (and so, an item) measures.

This means it’s relatively easy to devise a convention for naming columns or for the code book with metadata that accompanies a dataset that makes datasets fully machine readable. It will make it possible to automatically determine for every column in a dataset which construct the data in that column pertains to.

That makes it possible for psychological data to become FAIR. The Interoperability was always challenging, but now within reach.

This also enables accumulation of evidence. As Individual Participant Data meta-analyses are becoming more common, being able to automatically and reliably determine which constructs are represented how in a dataset can really help accelerate evidence synthesis.

Also, although I now wrote an adapter for LimeSurvey (as it’s an excellent open source application for online studies), adapters can also be written for other software (such as {formr} or even for closed science software such as Qualtrics).

This means repositories can contain links to questionnaires in a variety of formats.

To use the LimeSurvey adapter, I created 💅LAFOQS🦊: the LimeSurvey Adapter For Open Questionnaire Specifications: https://measurement.shinyapps.io/LAFOQS/.

All in all, this is a puzzle piece that I think can really help us move forward. And it all works! There are two examples. One is the BFI-10, which has:

✅ a TOQ specification: https://docs.google.com/spreadsheets/d/1atGTOs9RGTISDxiSH0IfSH5fDPYaDhnJEdbXqWqDRto;

✅ a ❄️UQID: bfi10eng_7sp9mjx3;

✅ a SOQ specification: https://codeberg.org/measurement/operationalizations-website/src/branch/main/data/questionnaires/bfi10eng_7sp9mjx3.yml;

✅ a page in the repo: https://operationalizations.com/questionnaire/bfi10eng_7sp9mjx3;

✅ if you throw the UQID in 💅LAFOQS🦊, a LimeSurvey group that you can directly import 🤩

And of course there’s the overview page with the questionnaires at https://operationalizations.com/questionnaires. Well, for now, with two questionnaires 😬

I still need to do a lot on work on all of this. For example, the repository doesn’t show the information very usefully yet. And of course we need to start adding questionnaires. But as a proof of concept I think this is pretty cool 🤩

So, a work week well spent I’d say. Time to celebrate! 🥳🍻

PS: the beer symbolizes both this week in Leuven (or Louvain; and the beer is called Louve, which is close enough for barbarians like us 😬), and the 💅LAFOQS🦊 Shiny App, since the can shows a fox, and 💅LAFOQS🦊 is, obviously, also a fox 😬

(Ow, Rik found out that Louve is apparently the name for a female wolf 🐺 Ah well, close enough 😬)

You (or your university) don’t own your data

Gjalt-Jorn Peters — Sat, 03 Feb 2024 23:00:00 GMT

This is a Mastodon thread. The original thread is available here:

This is a brief thread/blog post about ownership of data. I created it because of efficiency (basically, I find myself explaining this a lot). Apparently, there are a lot of misunderstandings around data ownership. Here, I hope to correct some misunderstandings.

The TL;DR: the only data you own are your personal data as per the GDPR. If you process others’ personal data, you don’t own them, but just temporarily process them. Data that are not personal data (i.e. that are not about a person) are about the world and cannot be owned. All data falls within one of these two categories, and as such, only personal data is somebody’s property. Your institution (or you) cannot own anonymous data.

Data about the world are facts, and facts cannot be owned: they are defined as existing in the public domain. For example, you cannot claim to own the fact that the earth revolves around the sun. For more information see https://copyrightalliance.org/faqs/whats-not-protected-by-copyright-law/.

If you conduct a qualitative study, audio or video recordings can easily be considered personal data (not always, but it’s generally best — and easiest — to assume they will be). This means you, as a temporary data processor, can only do with the data what you agreed to with the participants whose data you’re processing (except in some edge cases where your grounds for processing the data are not consent).

Once the data are transcribed into a text file, the data will often still enable identifying the participant who was interviewed (with reasonable effort; arguably, anything can be identified when infinite resource are thrown at it). That makes everything in the transcript about that participant personal data as per the GDPR, and so you cannot own those data.

In most cases, it’s possible to anonymize such data. Campbell, Javorka, Engleton, Fishwick, Gregory and Goodman-Williams describe a systematic approach to this end in https://doi.org/k7fm.

For qualitative data, it is possible the interviewees could claim the copyright for the narrative they provided. In that case that would still disallow you from making the data public. Therefore, it’s important to provide for this in your informed consent, which then serves three purposes: the ethical informed consent as per most ethical committees’ requirements; the consent as per the GDPR; and the agreement to deposit the anonymized data in the public domain.

To make it easy to create such informed consent forms, Szilvia Zorgo, James Green and me created an example informed consent insert that covers this. It is freely available at https://behaviorchange.eu/files/open-consent.odt.

Especially in the social sciencs, quantitative data are much easier. This is because of the low quality of our “measurement instruments” (the scare quotes reflecting the question of whether it’s reasonable to consider this measurement).

The large measurement error, and often even larger transient measurement error (https://doi.org/mkqn), are usually problematic, decimating effect sizes and requiring considerable sample sizes — but when it comes to identifiability, they are a boon.

A spreadsheet with answers to, for example, three measurement instruments of psychological constructs contains no personal data (the low reliability of these instruments means that even if people were to complete the same questions again and you’d use those results to try to identify them, you wouldn’t be able to locate their row in the spreadsheet since their answers will differ).

Therefore, for quantitative data, the best approach is to collect anonymous data: data that cannot be linked to the persons providing the data. In this respect, the concept of k-anonymity comes in handy (see https://en.wikipedia.org/wiki/K-anonymity).

K-anonimity means that there are always at least k participants that share any combination of data points.

For example, if you collected age, gender, and region, if you store age as date of birth, your sample would need to be pretty huge to no longer have unique dates of birth. If you store age in years at the time of data collection, you achieve k-anonimity with smaller datasets; and if you store age in decades at the time of date collection (0-10, 11-20, 21-30, etc), dozens of participants suffice.

The same goes for gender: if you measure gender in three categories (non-binary, female, and male), you achieve k-anonymity with smaller sample sizes than if you provide an open text field where participants can specify their gender (tempting to say “how they identify”, but that might be confusing in this context).

Of course, you can always include such an open question and then have an anonymization procedure where you categorize the answers into a smaller number of categories, for example using the :rstats: {gendercoder} R package (unfortunately not on CRAN: see https://docs.ropensci.org/gendercoder).

Whether participants can be identified also depends on your sampling frame. If you sample from “people in the Netherlands who use drugs and are between 20 and 40 years of age”, your sampling frame is much larger than if you sample from “primary school teachers in Valkenburg” (a village in the south of the Netherlands that has four primary school; also see https://nltimes.nl/2023/12/01/valkenburg-among-10-trendiest-destinations-worldwide-bookingcom-survey).

After all, the larger the group you sample from, the harder it is to identify any group member given a set of attributes. There are many more people with red hair among “people in the Netherlands who use drugs and are between 20 and 40 years of age” than among “primary school teachers in Valkenburg”.

For more details on anonymization, see https://behaviorchange.eu/posts/2019-09-a-poor-person-s-guide-to-open-sciencing-gdpr-compliant-data-management.html.

Once anonymized, a dataset contains no personal data, so it only contains facts about the world. Therefore, you or your university cannot claim to own those data.

(And if it had contained personal data, you or your university still wouldn’t have to be able to claim to own those data; personal data are only owned by the relevant person, and at most can be temporarily processed by others.)

There is one exception to this relatively simple state of affairs. First, a person or university (or other organization) can invoke what we’ll call “database right”: this is an instrument created to make it worthwhile for commercial organizations to invest in compiling large datasets (e.g. the yellow pages, https://en.wikipedia.org/wiki/Yellow_pages).

This means you claim to own a specific configuration of data that otherwise consists in the public domain. While this is a perfectly legal instrument, invoking it is incompatible with open science principles, and in the case of the Netherlands, with the Dutch Code of Conduct on Research Integrity, which mandates transparency. As such, this exception remains, um, academic 😬

I hope this helps to clarify why you never need to engage in discussions with your university administrators, or with external organizations, about “who owns the data”. The data cannot be owned by anybody other than the person who provided the data, and then only if the data are personal data as per the GDPR (i.e. identiable data).

As a final note: the fact that data exist in the public domain and cannot be owned does not mandate publication of the data. An organization is under no obligation to make data they collect public, even if they cannot claim to own the data. There are no obstacled to publishing the data, but that doesn’t mean organizations are forced to do so.

This imperative follows from scientific ethical integrity principles, as well as the implicit contract entered into with participants: that the data will be used for scientific research (which includes the ability for close scrutiny by other researchers and replicability of any analyses done on the data).

Researchers and universities have to make all data they collect public (well not all: following the principle “as open as possible, as closed as necessary), not because the legislator forces them, but because they adhere to standards of scientific integrity.

Preregistering Systematic Reviews

Gjalt-Jorn Peters — Thu, 05 Oct 2023 22:00:00 GMT

This is a Mastodon thread. The original thread is available here:

The article about the generalized preregistration form for systematic reviews is finally out (see doi.org/kt87)! 🥳

It was published on the 22nd of September 2023 - and the process start culminated in that preregistration form and article started on the 9th of February in 2018, so over five years ago 😶

It started when I supervised the Bachelor’s thesis of Tim Vincken. He was doing a systematic review about the home advantage: the idea that soccer teams have an advantage when they play at home versus in their adversary’s city.

We wanted to preregister this systematic review, but we found out that no preregistration form or service existed that we could use 😱

That was of course not acceptable, so I reached out on Twitter.*

For those who haven’t brushed up on their history lately: Twitter used to be a social media service, back in the days. It has since been bought by a billionaire and expertly destroyed. An unexpected side effect of this was widescale migration to the fediverse, revealing this development to be a blessing in disguise.

That yielded some responses, but not many - until it was retweeted by James Coyne, a much bigger account.

This prompted more discussion, and at some point Nieky van Veggel chimed in. He is a senior lecturer in Animal Health; quite a different field, but he had run into the same problem. He got Brian Nosek’s attention, and he put us in touch with Matt Spitzer.

That initiated the development of the form that just got published.

We then gathered a large group of people with expertise in doing systematic reviews, and set out to develop a (pre)registration form that was as inclusive as possible (both to disciplines as well as systematic review types).

In this process, Olmo van den Akker (https://www.ovdakker.com/) became the de facto leader, and he expertly guided the project to the finish line.

The result is a form that is relatively elaborate, but with items formulated such that they should fit for reviews in fields such as chemistry, law, and psychology, and review types such as scoping reviews, qualitative systematic reviews, and meta-analyses.

The form has six sections:

1️⃣ Metadata; 2️⃣ Methods; 3️⃣ Search Strategy; 4️⃣ Screening; 5️⃣ Extraction; and 6️⃣ Synthesis and Quality Assessment.

The Metadata section just contains, well, metadata.

The Methods section describes the general methodological constraints of the review: the review type, stages, start and end date, background, research questions, hypotheses and/or expectations, software, funding, conflicts of interest, and how to deal with overlapping authorships.

The form only uses open fields, i.e. no ‘categorical choices’. We figured that if we want to be inclusive, we shouldn’t impose whatever we happen to think is an exhaustive list of options.

In the Search Strategy section, you list the databases and interfaces, how you plan to deal with grey literature, your query, in- and exclusion criteria, search strategy validation, how you’ll deal with contacting authors (to get missing info), and search expiration and search repetition planning.

The Screening section has 10 items, covering things like screening stages, screened fields and masking, exclusion criteria, instructions, reliability and reconciliation, and sampling.

The idea is that as much as possible, if you complete these items comprehensively, this should be all that screeners need to start screening.

After screening, it’s time to extract stuff! In the Extraction section, you specify which entities you extract, in which stages, with which instructions, as well as whether extractors will be masked and how you deal with reliability and reconciliation.

In my experience developing good definitions of the entities to be extracted is one of the hardest and most time-consuming parts of doing a systematic review - so this section may be one of the hardest to complete.

And then, finally, you specify your plans for Synthesis and Quality Assessment.

Here, you describe your planned data transformations, your missing data plans, your data validation plans, quality assessment plans, and of course your synthesis plans, as well as your inference criteria (if you have any), synthesist masking, reliability, and reconciliation, and finally, planned publication bias analyses and sensitivity analyses.

And that’s it. Ths whole form has 65 items. Yes, 65. That’s a feature, not a bug. The form was designed to enable pretty comprehensive documentation of your plans.

And as a pleasant side-effect, that means the form lends itself well to supporting the planning of your systematic review.

For example, it prompts you to think about whether you want to mask screeners from some fields (common), and/or extractors (rare), and/or synthesists (almost never done).

The form is, however, designed to be applicable to all disciplines and review types. More specialized forms will generally contain items that are more pertinent to your discipline or review type. However, for many combinations, those may not exist yet.

One of the nice things about this form is that it’s available in the {preregr} R package (see https://preregr.opens.science).

That means you can easily adjust it - or create an R Markdown template to fill out.

You can do that with:

preregr::form_to_rmd_template(‘genSysRev_v1’, file = ‘C:/path/to/file.Rmd’);

That loads the form and writes it to the file you specified. You can put that in a Git repository (for example) and then complete it. Once you and all co-authors agree on the contents, you can move the contents to the form on the OSF, if you want.

Or, alternatively, you can render the {preregr} form to an HTML file. It will then also include both the form specification and the form’s contents as machine-readable embedded JSON.

Or both, of course.

The Center for Open Science posted a blog post about the form at https://www.cos.io/blog/generalized-systematic-review-template-joins-osf-registries, and I recorded a talk about the form which is available at https://youtu.be/qB3n9u4VnY0?feature=shared.

And of course, the form itself is also always available at doi.org/kt87.

I hope this thread was useful!

If you plan to do a systematic review, feel free to get in touch - I’m still working on {metabefor} and R package to help with Modular, Extensible, Transparent, Accessible, Bootstrapped Extraction For Systematic Reviews (i.e. METABEFor), and recently created the Extraction Validation App, EVA: https://opens.science/apps/eva. Not documented well yet, though - so as I said, get in touch 🙂

A-bit-of-X-odus

Gjalt-Jorn Peters — Fri, 25 Aug 2023 22:00:00 GMT

This is a Mastodon thread. The original thread is available here:

I finally full-on joined the X-odus and left X (ex-Twitter).

It’s a bit painful (I met a lot of nice people there, and it really helped build my network), but I just can’t justify contributing to it in any way any more.

The straw was that I saw that (already in July apparently), Elon Musk proclaimed that “cis” would be considered a slur on Twitter henceforth:

https://web.archive.org/web/20230708033233/https://www.forbes.com/sites/kimelsesser/2023/07/02/elon-musk-deems-cis-a-twitter-slurheres-why-its-is-so-polarizing/

I’ve barely used Twitter since November, only for some retweeting of initiatives I endorse (e.g. open science-related promo etc).

But the point is, by sticking around, it makes Twitter seem more alive than it is. Finally leaving for real and only using Mastodon shows the X-odus more clearly.

And of course, Mastodon represents the social medium to use if you care about open science; as the UNESCO points out, it’s important that the infrastructure we as scientists use is community-owned and open, not corporation-owned and subject to the CEO’s whims.

Since I use social media to discuss science, meet colleagues, network, and disseminate to the general audience and colleagues, I can’t keep using X with integrity.

https://unesdoc.unesco.org/ark:/48223/pf0000379949.locale=en

So farewell little blue bird. It was fun while it lasted. But I’m with the elephant now 🐘🤩

Using Git in Shiny Apps

Gjalt-Jorn Peters — Wed, 23 Aug 2023 22:00:00 GMT

This is a brief blog post to document how you can use Git in a Shiny app.

In August 2023, Rik and me were revising our “Knowing What We’re Talking About: Facilitating Decentralized, Unequivocal Publication of and Reference to Psychological Construct Definitions and Instructions” article (preprinted here)https://doi.org/jnjp. If you find the topic interesting, I have a brief blog post here and the same in a Mastodon thread here - but this post is about one part of Constructor, the Shiny app we created to accompany this article.

Constructor allows people to import or create a DCT specification. The app allows people to edit the DCT specification, shows a human-readable overview, and produces the YAML code used to store DCT specifications. Finally, it allows people to upload their DCT specification to the PsyCoRe.one repository.

These uploads work with a git repository: the PsyCoRe.one repository is a Hugo website, and the overview table with constructs, as well as the other pages (e.g. each construct’s overview page) are produced by Hugo as it loops over a series of YAML files (that hold each DCT specification). The rebuilding of this Hugo site is triggered by a webhook called by the Git forge (currently GitLab, but we may migrate to Codeberg at some point).

For all this magic to work, Constructor has to commit each newly added DCT specification to the Git repository holding the PsyCoRe.one website. For another project I’m involved in and that uses almost the same back-end infrastructure, OpenDrawer, James Green and Cillian McHugh added such Git functionality. So, I respectfully, um, borrowed ir for Constructor. However, this broke down at some point (for both Shiny apps). In the process of fixing it, I ended up switching to {gert}. However, even there I didn’t get it to work. After trying for an hour or two, I decided to ask on Mastodon whether maybe somebody had solved this already (see this post). Gabor Csardi, one of the amazing developers at Posit, responded. And finally, after about four more hours, I got it working.

I wrote this brief blog post to explain how. The thing that was going wrong turned out to be that I set the Personal Access Token (PAT) as an environment variable using:

Sys.setenv(PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT = "token");

(But then with token replaced with the token.)

However, it turned out (after those four more hours of troubleshooting) that Shiny doesn’t succesfully bundle this environment variable when it pushes the image of the Shiny app to the ShinyApps.io server…

I found out by throwing a message, warning, and error in the Shiny app:

message(paste0("PAT:[", Sys.getenv("PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT"), "]"));
warning(paste0("PAT:[", Sys.getenv("PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT"), "]"));
stop(paste0("PAT:[", Sys.getenv("PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT"), "]"));

This showed me in the logs that that environment variable was empty.

Now I use .Renviron, located in the project directory, and added to the .gitignore file since it contains the token. Its contents are simply:

PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT=token

(Again, with token replaced with the token.)

For a bit more information about this, see this Posit post as well as this reply by Hadley to a Stack Overflow question.

The full code fragment (for the entire application, see this Codeberg repo) for cloning a git repo, adding a file, staging it, committing it, and pushing to the remote git repo is:

###-------------------------------------------------------------------------
### Git repo and credential configuration
###-------------------------------------------------------------------------

userName <- "PsyConstructor";
userMail <- "psyconstructor@psycore.one";
gitForge <- "https://gitlab.com";
repoUrl <- paste0(gitForge, "/psy-ops/psycore-one.git");

###-------------------------------------------------------------------------
### Clone git repo
###-------------------------------------------------------------------------

tempPath <- tempfile(pattern = "gertTempRepo-");

tempRepo <- gert::git_clone(
  repoUrl,
  path = tempPath
);

### I know it's weird and seems ill-advised, but without this, it doesn't work.
setwd(tempPath);

### New approach: project should create a .gitignored file called
### ".Renviron" and which should contain a row:
### PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT=token
### where "token" is the token. Note that upon a new clone, you will
### have to create this file again.

### So _don't_ set environment variables with `Sys.setenv()`!
# Sys.getenv("PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT");
# Sys.setenv(PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT = "token");
# Sys.getenv("PSYCORE_CONSTRUCTOR_CODEBERG_PAT");
# Sys.setenv(PSYCORE_CONSTRUCTOR_CODEBERG_PAT = "token");

### https://fosstodon.org/@gaborcsardi/110940818918930959

system(paste0("git config --global credential.helper cache"));
system(paste0("git config --global credential.username ", userName));
system(paste0("git config --local user.name ", userName));
system(paste0("git config --local user.email ", userMail));
gitcreds::gitcreds_approve(list(
  url = "https://gitlab.com",
  #url = "https://codeberg.org",
  username = userName,
  #password = Sys.getenv("PSYCORE_CONSTRUCTOR_CODEBERG_PAT")
  password = Sys.getenv("PSYCORE_PSYCONSTRUCTOR_GITLAB_PAT")
))

###-------------------------------------------------------------------------
### Write, stage, and commit file, and push to repo
###-------------------------------------------------------------------------

### {gert} wants the path relative to the repository root
tempFile <-
  file.path("data", "dctspecs", paste0(ucid(), ".dct.yaml"));

psyverse::save_to_yaml(
  dctSpec(),
  file = file.path(tempPath, tempFile)
);

gert::git_add(
  files = tempFile,
  repo = tempRepo
);

gert::git_commit(
  paste("Submission of DCT specification with UCID ", ucid()),
  repo = tempRepo
);

gert::git_push(
  repo = tempRepo
);

In my view it’s superweird that the working directory has to be set, but when I remove it, it stops working… That might a a {gert} thing?

In any case, I hope this post can help potential future people who run into the same problem. And otherwise at least James Green and Cillian McHugh, can use it for OpenDrawer. Or future me 😬

Health Psychology in 2023: Transforming Paradigms

Gjalt-Jorn Peters — Mon, 31 Jul 2023 22:00:00 GMT

This is a Mastodon thread. The original thread is available here:

This is a thread for #HealthPsychologists (or others interested in #Psychology) who will be attending EHPS 2023: the 37th Annual Conference of the European Health Psychology Society, which will take place in Bremen, Germany, from 4-8 September 2023 🗓️

Specifically, I’ll briefly describe an awesome symposium we put together 🤩

The symposium focuses on the paradigms transformations that are impending in #HealthPsychology (and perhaps in #Psychology in general) 💫

Since many of these theoretical and methodological transformations originated in the replication, theory, and measurment crisis, the symposium also covers quite a bit of #OpenScience ⚗️

You could almost say it’s a kind of mini @improvingpsych@fediscience.org at the EHPS 🙂

Oeh, speaking of which - we also created an OSF project for the symposium already, with its own ShortDOI: https://doi.org/jxkz. This is where we will post the slides and references to other materials (as well as at https://osf.io/meetings/EHPS2023.

This allowed us to include that ShortDOI URL in the abstract itself when we submitted the abstracts. Assuming this will be retained in the abstract book, that means everybody will always easily be able to find the slides 🔍

In the first presentation, “The Regression Trap: Why Regression Analyses Are Not Suitable For Pretty Much Anything in Psychology”, Rik Crutzen will explain, well, why regression analyses are not suitable for pretty much anything in psychology 🔥

He will explain this at the hand of a theoretical rationale based on the nature of psychological constructs as well as based on how regression coefficients are computed.

So, we’re off to a nice comforting start 😬

Next, in “Knowing What We’re Talking About: Facilitating Decentralized, Unequivocal Reference to Psychological Construct Definitions and Instructions”, I will discuss the mess (health) psychology is in regarding construct definitions.

Briefly: we barely really have them, we don’t use them, and when we comapre them, it turns out that we all have different elaborated definitions in our heads… 🤯

I also present a potential route to start solving this ✅

Third, in “Towards Improving the Precision of Health Psychology Theories: The Importance of Translating Narrative Theories into Dynamical Systems Models”, Olga Perski will discuss the benefits of formalizing narrative theories, with special emphasis on system approaches.

Where the first 2 talks highlighted problems of current approaches, this contribution shows a path forward - a very promising path at that, that seems more epistemologically defensible.

In other words: exciting! 🤩

Fourth, since moving forward will require both quantitative and qualitative approaches, Szilvia Zörgő will present “Qualitative/Unified Exploration of State Transitions (QUEST): taking time into account in qualitative research”.

This will present a way to study state transitions using qualitative data, which also enables exploring system thinking from a qualitative perspective!

For people not so much into math, this ia a great way to take dynamical systems seriously anyway 🎙️

Finally, Annick de Paepe will present “Encouraging causal thinking in applied health research with causal Directed Acyclic Graphs (DAGs)”, covering the question of how (health) psychologists can study causality.

DAGs are a great tool, both to become aware of your assumptions & to transparently communicate them to other researchers.

Also, they’re quite easy to use - though supporting your assumptions can be challenging. Which is an asset of the method, not a drawback 🤩

Together, these five talks touch on a number of issues that have been highlighted as causes of the replication crisis, and as such, they outline paradigm transformations that can take us further as a field.

We’re really looking forward to this session, and you come to the EHPS this year, we hope you see you there!

Oh, and - it’s at Friday the 8th of September at 9:30, room HS 1010 🙂

The Intervention Mapping Summer Course 2023

Gjalt-Jorn Peters — Wed, 26 Jul 2023 22:00:00 GMT

This is a Mastodon thread. The original thread is available here:

Friday the 7th of July 2023, the #InterventionMapping (IM) summer course that trains professionals to systematically design theory- and evidence-based #BehaviorChange interventions ended, certifying around fifty fresh IM-trained professionals.

The closing session beautifully reflected the nature of the Intervention Mapping community. I’ll explain a bit about that here.

(after three more introductory toots with some background info)

Intervention Mapping is around thirty years old, having been conceived in the nineties: the first publication is from 1998 (https://doi.org/c32mz5), and the first book from 2001.

Since then, IM has continuously improved and grown, became integrated in more and more curricula, and is currently seen as a kind of gold standard for systematic intervention development.

The main drawback people report is that it can take a lot of time and effort to do properly (but also see https://doi.org/jb8k).

Unfortunately, this is a fact of life: there are no silver bullets. In fact, this is a property of the types of problems IM is applied to, not of IM: by the time IM is involved, all easy solutions have usually been tried (and failed). If a problem is complicated, learning what you need to learn to tackle it will always take a lot of time and effort.

For those unfamiliar with Intervention Mapping, I’ve written a super-brief Mastodon thread to introduce it: https://mastodon.nl/@matherion/110695074850807794. It was tooted with the {quartodon} R package, so you can also read this blog post instead: https://behaviorchange.eu/posts/2023-07-intervention-mapping-in-a-thread.html

Ok, enough intro.

As I said, the closing session highlighted the nature of the Intervention Mapping community.

This community reflects the generous and open attitude of its “founders”. They created IM to support the development of effective health promotion programs, and in the following decades they took the role of facilitators and stewards.

Although this may seem natural, this isn’t always the shift that occurs.

For example, sometimes when a method becomes popular, it sort of becomes a means of amassing fame or prestige for its founders. In such situations it becomes more about the persons, rather than about the methods.

Instead of facilitating the further development of the method, their role may even shift to policing who is and who isn’t allowed to contribute to its development.

Fortunately, instead, Intervention Mapping was generously nurtured by its founders.

As a consequence, Intervention Mapping has steadily kept improving over time. One testament to these changes are the way the main terms changed over time.

For example, “change objectives” (the very specifically formulated psychological constructs that an intervention targets) were originally called “learning objectives”; and “environmental conditions” were originally called “external determinants”.

Now, around thirty years after its inception, the IM protocol is used and taught all over the world - and its founders have retired.

This year, 2023, marked the last time Guy Parcel made the trip from Houston to Maastricht to co-facilitate the Intervention Mapping Summer School.

To celebrate this moment, co-founder Gerjo Kok asked the core group of people involved in IM to ensure we could attend the Summer School’s closing ceremony.

Although some of us tutored a group, others (like me) only gave a lecture (for a very old recording of that lecture, see https://youtu.be/BuOkDTo4vA0), so Sarah (Stutterheim) and me had a ☕ first to ensure we’d be on time, and at 12:00 started awkwardly standing outside the lecture hall, as one does 😬

Mariëlla (Muermans) joined us and Gerjo let us in. We joined while students asked questions about using IM in the real world (very relevant questions; this was clearly an excellent cohort).

When all questions had been asked, Gerjo took “the stage”, after having asked me to collect a “fragile” box from outside and bring it to the front of the room.

Gerjo then started his presentation, reminiscing about the stained glass artwork of the IM logo that the IM founders had commissioned years earlier, and then moving on to show and describe the new artwork to commemorate the present occasion.

This art is special partly because it was created by Nora Oosting. Nora was the partner of Herman Schaalma, a cherished Intervention Mapping expert who passed away in 2009.

In addition, it perfectly symbolizes the joint development of IM. The star figures prominently in both the Texas and the Maastricht flag. Finally, the base is made of merle, a type of stone common in the Maastricht region, and the star is made of aluminum, a metal that has long been produced in Texas.

It looked amazing and was very well thought through, so everybody was very impressed.

This is when the twist happened: Gerjo announced that in fact this occassion was where the three authors of the original IM book (2001) that were present, Guy Parcel, Nell Gottlieb, and Gerjo Kok, symbolically “handed the Intervention Mapping keys” to “the next generation”.

Us “the next generation” (TNG) people didn’t see this coming, and it took a while to sink in through our baffled states.

This twist nicely reflects the attitude that characterizes the IM founders. Their focus on passing on the method and including others in the community, rather than on themselves, helps Intervention Mapping to flourish.

As for us TNG people, I think we were all simultaneously proud and humbled.

For my part so much so that I decided to write this somewhat awkward toot thread / blog post to memorialize this occasion – but also to take a moment to reflect on how remarkable it is that Gerjo, Guy, and Nell (and Nora) made this moment about others rather than themselves.

This way, the closing ceremony highlighted the community that has grown around Intervention Mapping, and of which we (well, I at least) were hardly aware until that Friday.

It showed the fertile ground for further growth, emphasizing the potential for the future, to work towards more effective health promotion in an ever expanding community.

Alcohol of drugs: wat is slechter voor je?

Gjalt-Jorn Peters — Fri, 21 Jul 2023 22:00:00 GMT

Dit is een Mastodon draadje. Het originele draadje is hier beschikbaar:

De Universiteit van Nederland (https://universiteitvannederland.nl) is een fantastische organisatie die zich hard inzet om wetenschap toegankelijk te maken voor een breed publiek.

Wetenschappers zijn daar niet altijd goed in; maar de mensen van de Universiteit van Nederland kunnen heel goed met wetenschappers samenwerken om dingen uiteindelijk toch duidelijk uit te leggen voor iedereen.

En nog gratis ook! 🤩

Ik heb het geluk dat ze met mij wilden samenwerken over een filmpje om de uitgebreide zogenaamde “multi decision multi criteria decision analysis” over MDMA beleid te produceren (https://www.universiteitvannederland.nl/college/moeten-we-drugs-legaliseren).

Onlangs maakten we samen weer een nieuw filmpje, en in deze Mastodon thread en blog post (https://sciencer.eu/posts/2023-07-alcohol-of-drugs-wat-is-slechter.html) geef ik een inkijkje in het proces en wat meer achtergrond informatie.

Eerst het proces en dan de info 🙂

Het start met een intake waarin iemand van de Universiteit van Nederland het onderwerp met je doorneemt, en jullie samen de grove lijnen van een script bedenken. Hierna volgen nog een of meer sessies om dit uit te werken.

Hierbij let de Universiteit van Nederland goed op dat er een balans wordt getroffen tussen correctheid en begrijpelijkheid. Als wetenschapper leer je hier onder andere van dat je vooral een hoop niet kunt vertellen 🙂

In ons geval wilden we iets doen met de vergelijking van schadelijkheid van drugs. David Nutt heeft in 2010 in de Lancet een bekende ranking van drugs gepubliceerd met de Multi-Criteria Decision Analysis methode zie https://doi.org/djcthv.

We wilden deze uitleggen, maar daarvoor moesten we een eenvoudigere utivoering hebben, met minder drugs en maar een paar uitkomsten (‘criteria’).

We besloten daarom om een versimpelde versie van die oefening uit te voeren om het concept uit te kunnen leggen.

Hiervoor kozen we 5 drugs (alcohol, cocaine, cannabis, ecstasy, en koffie) en 4 uitkomsten of criteria (schade voor de gebruiker zelf, schade voor anderen, verslavingsgevoeligheid, en voordelen van gebruik).

Ik maakte hier een “Nano-MCDA” van die experts hebben ingevuld (preventiewerkers, artsen, wetenschappers, etc).

Je kunt de data bekijken op https://matherion.gitlab.io/nano-mcda-uvnl.

Bij deze specifieke rubriek, de Werkplaats, werk je bovendien met ‘props’, als in, je kunt ook echt met objecten werken. Da’s superleuk, maar dan moet je natuurlijk wel bedenken hoe die zinnig in te zetten zijn om het verhaal beter uit te leggen.

In ons geval wilde we de staafdiagram laten zien, dus daar gebruikten we blokjes voor.

We wilden bovendien uitleggen waarom ecstasy niet (psychofarmacologisch) verslavend is, en dat hebben we uiteindelijk met knikkers gedaan.

De opnames waren in Amsterdam. Ik was daar om half elf (ik kwam uit Maastricht tenslotte), en we zijn ongeveer bezig geweest vanaf 11:00, en dan dik vier uur tot iets over 15:00.

De Universiteit van Nederland was met z’n vieren, dus in totaal waren we met z’n vijven - dat is al 20 “mens-uur” dus, en dan tellen we de voorbereiding en het editen niet eens mee… 😶

Het resultaat, “Alcohol of drugs: wat is slechter voor je?” staat op https://youtu.be/dlCGnS4AyOg.

Als je dit interessant vindt en meer informatie wil, staat op de site van de Jellinek de samenvatting van een uitgebreide studie die in Nederland is gedaan: https://www.jellinek.nl/vraag-antwoord/welke-drug-is-de-gevaarlijkste.

Ik zal nu nog wat extra uitleg geven over vragen die mensen in de comments op YouTube en Nu.nl stelden.

Een veel gestelde vraag was of er wel rekening werd gehouden met de standaardinname van de verschillende drugs.

Het is absoluut waar dat dosis bepaalt hoe schadelijk iets is. Als je bijvoorbeeld drie liter water drinkt in een uur, kun je daaraan overlijden. Ook voor alcohol en ecstasy geldt dat als je er te veel van gebruikt, je daar diezelfde dag nog aan kunt overlijden.

Het is ook zo dat een biertje (ongeveer 10 gram alcohol) veel minder schadelijk is dan twintig biertjes (ongeveer 200 gram alcohol; zie ook https://en.wikipedia.org/wiki/Standard_drink).

En een kwart pil (zeg 45 milligram MDMA) is minder schadelijk dan een hele pil (zeg 180 milligram MDMA).

Tegelijkertijd is er geen standaardinname van middelen.

Er zijn wel suggesties: de WHO adviseert bijvoorbeeld om geen alcohol te drinken, en als je toch drinkt, maximaal 1 eenheid (dus 1 pilsje, of tweederde speciaalbiertje, of een glas wijn, etc).

En voor ecstasy is er een zogenaamd ‘harm reduction’ advies om maximaal 1-1.5 milligram MDMA per kilo lichaamsgewicht te gebruiken (dus als je 70 kilo weegt, maximaal ongeveer 105 gram MDMA; zie ook https://www.jellinek.nl/informatie-over-alcohol-drugs/drugs/xtc-mdma/risicos/).

En dan zijn er nog gemiddelden: je kunt uitrekenen hoeveel alcohol Nederlanders gemiddeld drinken per week of per dag.

Maar op een zaterdag ligt dat gemiddelde een stuk hoger dan op een dinsdag; en de meeste mensen drinken (veel) minder of (veel) meer dan dat gemiddelde: bijna niemand zit precies op het gemiddelde.

Dat geldt altijd voor gemiddelden; er is een gemiddelde leeftijd in Nederland (42 jaar), maar de meeste mensen zijn (veel) jonger of (veel) ouder (https://www.cbs.nl/nl-nl/visualisaties/dashboard-bevolking/leeftijd/bevolking).

Als we naar effecten van drugs kijken, is er geen ‘typische gebruiker’ voorhanden waar we naar kijken, want er bestaat geen typische gebruiker.

Meestal kijk je daarom naar de effecten zoals je ze nu ziet in de maatschappij, gecombineerd met wat je weet over de middelen.

Als ecstasy bijvoorbeeld legaal zou zijn, is de verwachting dat gebruik iets toe zou nemen, maar niet veel (daar zijn ook weer allerlei redenen voor).

Dit soort overwegingen kun je ook meenemen, om zo te corrigeren voor de verschillende legale status van de drugs.

Een andere vraag die mensen hadden, is of er werd meegenomen in de inschattingen hoeveel de verschillende drugs worden gebruikt.

Dat wordt inderdaad meegenomen. Het is belangrijk om in dit kader stil te staan bij hoe de verschillende drugs werken. Alcohol en koffie worden veel gebruikt, en beide drugs lenen zich daar ook goed voor.

Ecstasy wordt veel minder gebruikt, en die leent zich ook niet voor frequent gebruik, zelfs als het legaal is.

Verder werd drugscriminaliteit genoemd in de comments: dat veroorzaakt een hoop slachtoffers, en die criminaliteit bestaat wel voor cocaine en ecstasy, maar niet voor alcohol.

Echter, deze criminaliteit is niet het gevolg van de drug zelf, maar van onze maatschappelijke keuze om die drug illegaal te maken.

Als we de drugs legaliseren verdwijnt die schade door drugscriminaliteit ook.

Ik breid deze Mastodon thread en blog post wellicht nog uit met meer uitleg, als er nog iets langskomt dat kort genoeg uitgelegd kan worden.

Dat wil zeggen, ik breid de pot dan uit, en toot de thread dan opnieuw 😬

Voor meer achtergrondinfo over hoe schadelijk alcohol is ten opzichte van cocaine, zie dit interessante interview met Tom Bart van Jellinek: https://www.nu.nl/gezondheid/6251405/zo-schadelijk-is-een-lijntje-coke-ophef-terecht-maar-alcohol-is-ook-slecht.html.

Andere filmpjes van de Universiteit van Nederland over drugs staan hier: https://www.universiteitvannederland.nl/college?search=drugs#filter.

Andere filmpjes van de Universiteit van Nederland met collega’s van de Open Universiteit staan hier: https://www.universiteitvannederland.nl/college?school=open-universiteit#filter.

En, last en least, mijn andere filmpjes: https://www.universiteitvannederland.nl/college/waarom-werkt-bangmakerij-niet-ontmoedigend-als-het-gaat-om-drugs en https://www.universiteitvannederland.nl/college/moeten-we-drugs-legaliseren.

Intervention Mapping in a thread

Gjalt-Jorn Peters — Sun, 09 Jul 2023 22:00:00 GMT

This is a Mastodon thread. The original thread is available here:

Ages ago, I wrote a Twitter thread to very briefly introduce the Intervention Mapping protocol.

The Mastodon thread that follows (and the blog post at https://behaviorchange.eu/posts/2023-07-intervention-mapping-in-a-thread.html from which it was posted with the {quartodon} R 📦, see https://quartodon.opens.science) is the migration of that thread.

Intervention Mapping is a framework for developing behavior change interventions, achieve knowledge translation, facilitate implementation, address health problems; basically for anything that requires some sort of intervention in the world. This thread ‘nutshells’ IM.

1: Establish planning group with stakeholders; create logic model of problem (including environmental factors and personal determinants); analyze population, context, community strengths etc; specify goals.

2: Determine desired behavior; specify sub-behaviors (performance objectives); consult literature and do qualitative and quantitative research to map the environmental factors and personal determinants of target behaviors; compile into matrices of change objectives.

3: For each environmental factor, identify which agents control it; then for each agent, identify desired behavior to change the environmental condition; again determine sub-behaviors, personal determinants, and (‘next iteration’) environmental factors. Repeat as needed.

4: Use literature (both theory and empirical evidence) to identify behavior change principles that can target the personal determinants of the target population individuals as well as the environmental agents.

5: Translate these theoretical psychological principles into practical applications while respecting their parameters for use (because behavior change boils down to exploiting an organism’s capacity for learning, this is tricky).

6: Compile the applications for each target individual into coherent interventions, establishing a theme, the scope, and sequence of the intervention components.

7: Pretest intervention (components) for both effects on determinants and behaviors as well as characteristics such as understandability, usability, and fit with target population.

8: Regularly check to make sure you still address all change objectives and that the applications that make up the final intervention still respect the parameters of use for the behavior change principles they embody (i.e. that the logic model of change ‘survives’).

9: Throughout the process, use the planning group (from the first tweet 🙂) to make sure that what you end up with is acceptable and feasible to the target population members, implementers, and relevant stakeholders (who should all be in your planning group).

10: Throughout the process, anticipate on implementation. This is achieved by repeating (at least) steps 2-6 for implementers (who has to do what to make sure the intervention gets implemented/disseminated/maintained etc?).

11: Throughout the process, anticipate on your evaluation, both process and effect. For example, make sure the objectives you formulate in steps 1 & 2 (as well as iterations of those steps for environmental agents and implementers) are measurable.

12: Throughout the process, use the Core Processes: pose questions; brainstorm provisional answers; review empirical literature for theory and evidence; derive theoretical additions; collect new data if needed.

13: There are more resources at https://interventionmapping.com, there is a list of papers that describe applications of IM at https://interventionmapping.com/references, and there is a list of free related resources at https://effectivebehaviorchange.com.

Converting a Quarto blog post to a Mastodon thread and posting it

Gjalt-Jorn Peters — Tue, 10 Jan 2023 23:00:00 GMT

This is a Mastodon thread. The original thread is available here:

This thread explains the {quartodon} R 📦 (see https://quartodon.opens.science).

The #rstats quartodon 📦 allows you to post a Mastodon thread from a plain text file (e.g., a blog post from a Quarto, {blogdown}, or {distill} website, another Quarto or R Markdown file, or just a plain text file).

This effectively allows you to post blog posts to Mastodon in a thread of toots 📑➡️🪄➡️🐘🐘🐘

The {quartodon} package comes with an RStudio addin with two commands

🚀 “Extract and preview all toots”

🚀 “Extract and post all toots”

These take the currently active document, extract all toots, add thread counters, and do some preparation and checking (toot lengths, image sizes, and alt texts) 🔍🧐

When previewing, the thread will be shown in the viewer with character counts and showing any errors 🪟

When posting, the thread will be posted to Mastodon 📬

The basic use of {quartodon} is very simple.

1️⃣ You set up your credentiasl with {rtoot} in an environment variable 🔐

2️⃣ You structure your blog post as a thread of toots 🧵🐘

3️⃣ You preview the toot thread and double check everything ✅✅

4️⃣ You post your thread, et voila 👌

The first post will be posted as “public” 🌏

The other posts will be replies to each other, and will be posted as “unlisted” 🔓

Some details about how it works (this describes the default settings, most are customizable):

🤖 Basics 💫

👉 The text is separated into toots by looking for lines containing only “-----” (five dashes).

👉 The first fragment (before the first five dashes) is ignored, allowing you to add stuff to your post that won’t be part of the toot thread.

👉 It automatically adds thread counters to the end of every toot, like this one 👇

🤖 Images 💫

👉 It checks whether images can be found, and I didn’t implement a check for URLs yet, so images have to be local for now.

👉 Image alt texts are checked for minimum lenght (currently, 10 characters)

👉 For now, only one image can be included (if multiple are included, only the first one is retained

🤖 Cleaning 💫

👉 All headings will be removed (all lines starting with #)

👉 All backticks will also be removed (since Markdown uses that to display code, but Mastodon doens’t).

👉 All strings of more than three consequtive newline characters will be replaced by two newline characters

🤖 URLs 💫

👉 {quartodon} replaces all URLs with their title, which means that hyperlinks where the title (the part between the square brackets in Markdown) isn’t the URL will just disappear in the toot.

👉 Note that relative URLs will not work from Mastodon; all URLs have to start with “https?://”, because {quartodon} processes the raw .qmd, .rmd, or .md file, before {Quarto} (or {rmarkdown} or {knitr}) did any replacement work.

🤖 Toot character counts 💫

👉 When counting toot lengths, {quartodon} counts all URLs as 23 characters, conform the Mastodon defaults.

👉 When counting toot lengths, it also corrects usernames, stripping the instance information (i.e., the last @ and everything following it (see https://docs.joinmastodon.org/user/posting/).

You can find the {quartodon} documentation at https://quartodon.opens.science

The vignette from which this Mastodon thread was extracted and posted is located at https://quartodon.opens.science/articles/quartodon_intro.html

If you would like to check out the GitLab repo with the source code, check https://gitlab.com/r-packages/quartodon

Finally, you can check out the Quarto blog post with the same information at https://gjyp.nl/posts/2023-01-converting-a-quarto-blog-post-to-a-mastodon-thread-and-posting-it.html

For now - have fun!

These are the basics. Of course, this is the first version of the package: who knows what we can add in the future? 🚀

This package was fun to create, and will hopefully be useful. Hopefully many others can use this to let Quarto (or other) blog posts do double duty as threads of toots posted to Mastodon 🐘

At the same time I’m not sure how much time I’ll have to extend and maintain this, so if this seems like a fun project to you, please drop a line!

Using the Reproducible Open Coding Kit & Epistemic Network Analysis to model qualitative data

Gjalt-Jorn Peters — Mon, 02 Jan 2023 23:00:00 GMT

This is a Mastodon thread. The original thread is available here:

🚨 Publication alert! 🚨

At EHPS 2021, Szilvia Zörgő presented “Bridging the qualitative and quantitative with Epistemic Network Analysis: a worked example”. 🌉

Based on this, we were invited to write a tutorial for the Advanced Methods section of an EHPS #OpenAccess journal, Health Psychology and Behavioral Medicine.

That tutorial is now out!

Get it at https://doi.org/jrfb - main points in this 🧵!

#Psychology #OpenScience #BehaviorChange #QualitativeMethods #RStats @rstats@gup.pe

🧵 1/21

Qualitative, quantitative, and ENA

Qualitative methods are typically contrasted with quantitative methods – so much so that at EHPS 2012, the Synergy Expert Meeting addressed overcoming the ‘irreconcilable epistemological differences’ between both approaches.

Analyses have described this contrast using terms such as facts vs opinions, objective versus subjective, and masculine versus feminine.

🧵 2/21

If qualitative and quantitative methods are combined within one study (i.e., a mixed-methods study), they often have complementary functions.

Epistemic Network Analysis is a method that instead strives to unify qualitative and quantitative approaches, ultimately producing data visualizations that provide a novel lens to aid understanding the patterns in qualitative datasets.

🧵 3/21

ROCK to ENA

In this tutorial, we explain how to create an Epistemic Network for a qualitative dataset.

Because we want to work conform the #OpenScience principles, we use the Reproducible Open Coding Kit (the ROCK 🤘).

The ROCK is an open standard for coded qualitative data, and we also explain a bit about that.

🧵 4/21

The example study

As illustration, we use a qualitative study into perceptions of illness etiology, comparing patients who chose complementary or alternative medicine with patients who chose biomedical treatments. This example uses five codes:

1️⃣ ‘psych’: emotion, stress, trauma, nerves

2️⃣ ‘vital’: energy/qi/prana, flow, block

3️⃣ ‘eco’: environmental toxins, chemicals

4️⃣ ‘nutri’: quality or type of food, additives

5️⃣ ‘genetic’: inherited illness or susceptibility, genes

🧵 5/21

This figure shows Epistemic Networks from this example. The left (purple) network is for patients who chose biomedicine, the right (green) network is for patients who chose complementary or alternative medicine, and the center network shows the difference between the other two plots.

The edges represent how often codes co-occurred: for example, in the biomedicine group, the “psych” and “genetic” codes co-occurred most frequently. This allows easy visual comparison of such patterns.

🧵 6/21

But that is not all! With ENA, you can create networks for any subsample of participants! 🤩

For example, these are six networks also split on diagnosis (columns). This shows that there is considerably heterogeneity within each diagnosis group, placing the differences between patients choosing the biomedical route and those choosing alternative of complementary medicine in perspective. 👓

🧵 7/21

The CLIFF

So, next we explain how you can obtain those visualizations!

Before we begin: in the tutorial, we follow the Clean Lean Initial Formatted File (CLIFF).

That’s a prestructured set of directories and files meant to help you start a ROCK project. It’s available in a Git repository at https://rock.science/cliff.

Don’t worry – you don’t need Git to use the CLIFF – you can also download as a .ZIP file!

🧵 8/21

The ROCK standard

The ROCK standard is designed as a human- and machine-readable standard for coded qualitative data. Some terms:

👉 source: a file containing qualitative data
👉 utterance: smallest codable unit of data, typically (but not necessarily) a sentence
👉 identifier: a character string added to the data to represent codes and other things
👉 code: a concept/construct of interest. Codes are represented by their code identifier in double brackets: [[code]], [[parent>child]]

🧵 9/21

👉 section break: a type of identifier used to segment data, by inserting a line containing e.g. ---<>---
👉 class: a group, e.g. cases (participants) or interview locations
👉 class instance: a single case or location: [[cid=1]], [[locationId=library]]
👉 attribute: characteristics of class instances (e.g. age, diagnosis, etc), attached to utterances through class instance identifiers
👉 utterance identifier: a unique identifier for an utterance

🧵 10/21

The `{rock}` R 📦

To work with these ROCK files, we will use the {rock} R package. You can get it from CRAN using:

install.packages('rock');

You can use the ROCK standard without using the {rock} R package, but as yet, the standard hasn’t been implemented in any other software yet that we know of. In addition, the {rock} R package produces a .CSV file that we can import into the rENA tool to create the Epistemic Networks.

🧵 11/21

Step-by-step tutorial

We place our raw data sources as plain text files in a directory named 010—raw-sources.

Usually raw sources are a bit messy, and the ROCK requires every utterance to be on a separate line. For this, we use the rock::clean_sources() function.

As its input argument, we specify the directory with the raw sourcs, and as its output argument, the directory where we want to write the clean sources 020—cleaned-sources.

🧵 12/21

Next, we add utterance identifiers before every line. These uniquely identify every utterance, which makes two things possible.

1st, efficient reference to utterances, e.g. to add codes or describe results.

2nd, when multiple coders code the same source independently, utterance identifiers allow determining which codes were attached to each utterance (and merging them).

To prepend utterance identifiers, use rock::prepend_ids_to_sources(), again specifying the input and output paths.

🧵 13/21

Attributes are specified for each class instance. The most common type of class is participants (or ‘cases’, following the REFI terms), so each instance or case is a person. In the YAML chunk, for each class instance identifier, attributes can be specified - this enables querying data and codes using those attributes.

Attributes are indicated using YAML fragments. This is a bit hard to explain in a toot, but feel free to peruse the article 😬

🧵 14/21

Coding

Coding qualitative data in the ROCK standard just consists of adding code identifiers to the plain text sources.

This can be done with any text editor, but there is also a rudimentary (but GDPR-compliant) javascript/html/css web app available at https://i.rock.science.

It’s very simple: just load a source, create some codes (or load those from a file, too) and you can drag and drop the codes to code utterances.

🧵 15/21

Merging codes from independent coders

If you used independent coders, the utterance identifiers make it possible to merge the codes from all coders into one primary source.

The {rock} R 📦 has a function for this: rock::merge_sources(). You can specify which ones are the primary sources by regular expression or by path.

This writes new sources to disk that contain the codes from all separate sources (using the utterance identifiers).

🧵 16/21

Parsing the coded sources

If you got to this point (in the tutorial in the paper, not this tootorial 😬), you have coded and merged sources, so we’re ready to parse them.

In the {rock} R 📦, there’s rock::parse_sources() function for this. It produces an object with a lot of info, but the only thing we need for ENA is the mergedSourceDf data frame, which we can export with the rock::export_mergedSourceDf_to_csv() function.

That .csv file can then be imported into the ENA web app to produce Epistemic Networks.

🧵 17/21

Epistemic Network Analyses

To create an Epistemic Network, you can use the web app available at https://app.epistemicnetwork.org.

You have to specify which column designates ‘units’, which designates ‘conversations’, and which contain the codes you want to see in the network. In ENA, co-occurrences are computed per ‘unit’, and only for codes from the same ‘conversation’. So, ‘conversations’ are usually interviews (e.g., sources), and units are often participants (or groups of participants).

🧵 18/21

You also have to specify “stanza window”, which also determines when codes are considered to co-occur. For more details on the meaning of ‘units’, ‘conversations’, and ‘stanzas’, as well as how the networks are created from the coded utterances, please see the tutorial at https://doi.org/jrfb 🙂

You should now be rewarded with a pretty visualization as shown here 🤩

Well done! 💪

🧵 19/21

Conclusion

In the tutorial, we also discuss a number of strengths and limitations of Epistemic Network Analysis.

ENA offers a unique perspective on your data, helping you see patterns you may otherwise miss. By inspecting the networks in parallel with the coded data, you can use the richness of qualitative data to its fullest, while also benefiting from the visualizations possible by quantification.

🧵 20/21

In the process we introduced the Reproducible Open Coding Kit, a human- and machine-readable standard for coded qualitative data. We also showed some functions from the {rock} R 📦 to help you work with .rock files.

We hope this tutorial can help you to answer new, interesting research questions - and in an Open Science way!

Oh, and the tutorial itself was at https://doi.org/jrfb 🙂

🧵 21/21

Acyclic Behavior Change Diagrams: A Tool to Report and Analyze Interventions

Gjalt-Jorn Peters — Tue, 13 Dec 2022 23:00:00 GMT

This is a Mastodon thread. The original thread is available here:

Intro

🚨 Publication alert! 🚨

Happy to share that “Acyclic Behavior Change Diagrams: A Tool to Report and Analyze Interventions” is now out in Health Psychology & Behavioral Medicine!

You can get it at https://doi.org/jp9t - or read this brief thread to get the main points!

#Psychology #OpenScience #BehaviorChange #InterventionDesign #HealthPromotion #PublicHealth #RStats @rstats@gup.pe

🧵 1/21

Behavior change is hard

We started creating the ABCD because #BehaviorChange is hard.

That’s because behavior is complicated and the result of many psychological constructs or behavioral determinants.

There’s no list of a number of ‘tricks’ you can use for behavior change: instead, interventions often have multiple components, targeting multiple determinants on multiple levels.

🧵 2/21

Intervention content is inadequately reported

This complexity means that accurate, comprehensive and transparent communication about what an intervention uses to target which psychological constructs (determinants) is vital.

However, research by De Bruin et al. (2021; https://doi.org/ggjwbg) has shown that only about a quarter to a third of the behavior change techniques (BCTs) in interventions are reported.

This is a big problem for replication and for evidence synthesis: in short, for cumulative science.

🧵 3/21

Causal-structural chains

Acyclic Behavior Change Diagrams (ABCDs) aim to address this problem, and in addition, provide a tool to support intervention development.

ABCDs are not an intervention development framework (such as #InterventionMapping, the #BehaviorChangeWheel, or #SocialMarketing), but they complement such frameworks by providing a tool to document and communicate about the assumptions underlying an intervention.

We call these assumptions the causal-structural chains.

🧵 4/21

Causal-structural chains end with the target behavior. The preceding links are sub-behaviors, because target behaviors are often defined at a generic level (e.g., “healthy diet”, “safe sex”, or “sufficient exercise”).

Sub-behaviors are caused by determinants: psychological constructs such as attitude, habit, or skill, norms (another link). The 4th link is central: sub-determinants, which are concrete, specific, context-dependent ‘sub-constructs’ comprising or causing the determinants.

🧵 5/21

Where determinants are defined on the generic level (and are studied across populations, behaviors, and contexts), they are usually assumed to describe representations that are much more specific and concrete, and very by population, context, and behavior (e.g, “If I drink too much, I will get a hangover” or “Nobody I know was vaccinated”).

This distinction is important because intervention content (e.g. messages) necessarily exists on the sub-determinant level.

🧵 6/21

These last four links describe the assumptions about why people do what they do: which parts of their psyche an intervention targets, and so are considered the most important (e.g., habits, attitude, impulse control, self-efficacy, etc).

This is one half of why intervention developers believe that an intervention will change behavior.

🧵 7/21

The other half describes the assumptions about what can change what.

Specifically, which behavior change principles (also known as behavior change techniques, BCTs, or methods of behavior change) will be used to target which sub-determinants (and so, which determinants).

These behavior change principles form the first link of each causal-structural chain: they make change possible in the first place.

🧵 8/21

The second link of the chain is formed by the so-called “parameters of use” of the behavior change principle. These conditions for effectiveness describe which conditions have to be satisfied for the behavior change principle to “work”.

The why & how of this is more complicated; see the manuscript for details 😬

But they’re very important, and therefore, so is the second link of the causal-structural chains that make up Acyclic Behavior Change Diagrams.

🧵 9/21

Then we get to the final link of the causal-structural chain.

This 3rd link connects the behavior change principles (link 1) that aim to target the sub-determinants (link 4), while securing the conditions for effectiveness (link 2), and ultimately changing the determinants (link 5).

The 3rd link are the applications: the tangible, concrete parts that make up the intervention. Any given BCP can be implemented in a (practically infinite) variety of applications.

🧵 10/21

Interventions as a set of chains

Each casual-structural chain represents one path through which the intervention could have (a bit of) effect.

Any intervention is based on multiple such chains. The more chains there are, the larger the accumulative effect.

If one of the links in the chain is broken, for example because a sub-determinant isn’t important for a behavior, or because a behavior change principle cannot change the determinant it targets, that chain can no longer contribute to the intervention’s effect.

🧵 11/21

Acyclic Behavior Change Diagrams (ABCDs)

In other words: it’s important to have a clear idea of these causal-structural chains, to critically reflect on these assumptions, and to communiate them transparently and accessibly.

Acyclic Behavior Change Diagrams help you to achieve both goals.

ABCDs are intuitive visualizations of the causal-structural chains that represent the assumptions about why an intervention would work.

This facilitates communication about an intervention, during development as well as in articles.

🧵 16/21

ABCD matrices

But - ABCDs have a second purpose. They are generated from so-called ABCD matrices.

Especially researchers who have done a #SystematicReview or two about behavior change interventions will appreciate the ABCD matrices, because ABCD matrices are machine-readable.

This means no more coding of BCTs - and guaranteed exhaustive and 100% accurate specification of BCTs!

It also means you know exactly which (sub)behaviors an intervention was designed to target, and which (sub)determinants.

🧵 17/21

An ABCD matrix is a table with seven columns, where each row represents one causal-structural chain, from a

1️⃣ behavior change principle (BCT) with its
2️⃣ corresponding conditions for effectiveness, as implemented in
3️⃣ a practical, tangible Application, which targets
4️⃣ a given concrete, contextualize sub-determinant, that is part of
5️⃣ a determinant (a psychological constructs), which causes
6️⃣ a sub-behavior, which together with other sub-behaviors forms
7️⃣ the ultimate target behavior.

🧵 18/21

Creating an ABCD yourself

The ABCD matrix is also how you produce an ABCD. We created a function “abcd()” in the {behaviorchange} :rstats: 📦, as well as added a function to the “behaviorchange” jamovi module, but, most importantly, Luke McGuinness (https://www.lukemcguinness.com/) created an R Shiny app!!!

It’s at https://a-bc.eu/apps/abcd, and allows you to upload an .xlsx file or import directly from Google Sheets!

🧵 19/21

Once you imported an ABCD matrix, you can produce the Acyclic Behavior Change Diagram itself, and then download it as .PDF, .PNG, or .SVG.

If you download it as .SVG, you can then edit it using, for example, InkScape (@inkscape@mastodon.art), to emphasize certain elements.

The defaut colors are based on a color scheme to help students distinguish between these seven central behavior change concepts, by the way (from another project) 🎨

🧵 20/21

Hopefully, ABCDs can help you maintain an overview of the assumptions in your interventions; help discuss interventions with stakeholders; and help to transparently and machine-readably report intervention contents.

There’s a whole thread just about the Shiny app here: https://mastodon.nl/@matherion/109338006503804990

Also, the manual page for the R function is available at https://behaviorchange.opens.science/reference/abcd.html

Oh, and the article is at https://doi.org/jp9t

🧵 21/21

Example of an ABCD in the wild

Oh, and I forgot, stupid of me: Gido Metz, the amazing first author of this paper, also published an example where the ABCD was applied to an intervention, so check out https://doi.org/jqmc for a real-world example.

🧵 22/21

Knowing what we’re talking about: a Mastodon thread

Gjalt-Jorn Peters — Thu, 01 Dec 2022 23:00:00 GMT

This is a Mastodon thread. The original thread is available here:

Intro

🚨 Preprint alert! 🚨

#Psychology #OpenScience #Measurement #Validity #RStats @rstats@gup.pe

Ever had trouble understanding exactly how to interpret a construct’s definition?

Ever wondered why different articles seem to have different definitions of the same construct?

Ever wanted a solution for this?

We address this issue and present a set of #OpenSource tools to deal with it!

🧵 1/15

A GIF of a woman’s face with lots of equations

Replication, measurement, and theory crises

The replication crisis (or credibility revolution) revealed an underlying “measurement crisis” and a “theory crisis”. One symptom of this theory crisis is the “jingle jangle jungle”, both at the conceptual level and in measurement 🤔

On the one hand, sometimes on closer inspection, constructs or measurement instruments that are purportedly different turn out to be practically identical, preventing accumulation of knowledge and hindering evidence syntheses.

🧵 2/15

A GIF of two spidermen pointing at each other

On the other hand, sometimes measurement instruments supposedly measuring the same thing exhibit substantial differences in content, or in qualitative studies about the same construct, codebooks vary substantially. This means the findings from such studies cannot be compared or aggregated.

🧵 3/15

A GIF of a woman saying “those are two very different things”

Construct Definitions

One cause of this is the exceptionally brief construct definitions used in psychology. Most construct definitions appear to be about 20 words or less - exceptionally concise for things that cannot be directly observed.

As a consequence, researchers using such concepts must first elaborate those definitions for themselves. Such elaborations, however, often remain hidden.

🧵 4/15

A screenshot of a paragraph from the preprint

This heterogeneity in “study-level elaborated construct definitions” is in itself not bad. Epistemic diversity has a number of benefits, and studying multiple variations of construct definitions seems sensible.

However, it is a problem that this heterogeneity is hidden.

So: we want to avoid curation of construct definitions by a central authority, but simultaneously eliminate this hidden heterogeneity.

🧵 5/15

A GIF of a girl saying “Why don’t we have both?”

Decentralized Construct Taxonomies

Enter: Decentralized Construct Taxonomies 💫

The idea is simple; a way to openly share:

1️⃣ A unique construct identifier
2️⃣ A human-readable label
3️⃣ A comprehensive construct definition
4️⃣ Instructions for developing measurement instruments
5️⃣ Instructions for identifying/coding measurement instruments
6️⃣ Instructions for qualitative research

These DCT specifications can easily be shared, re-used, or adapted.

🧵 6/15

A screenshot from the Constructor Shiny App

By combining the comprehensive construct definitions with corresponding instructions for using the construct in quantitative and/or qualitative research, there will hopefully be less need for individual researchers to “fill in the blanks” when they design a study.

In addition, DCT specifications can easily be adapted. This way everybody can redefine constructs if they want to - and through the unique identifiers it’s always clear exactly which construct definition is used.

🧵 7/15

A GIF of a woman saying “We speak the same language”

Producing comprehensive construct definitions

We explain a number of ways to arrive at such comprehensive construct definitions, such as expert consensus, using the Delphi approach, using scoping reviews, and using qualitative and quantitative primary research.

One method is basically documenting the comprehensive, elaborated definitions your research team uses. No extra work, but less ambiguity and more transparency and openness!

🧵 8/15

A GIF of a cat opening a door

The point is that to decrease the hidden heterogeneity, any effort to explicate construct definitions is helpful.

For example, in your research team, you could try the following.

Get together, take a construct you’re studying, and independently write down comprehensive definitions.

You’ll likely end up with different definitions. In some cases, the differences will be small; in others, larger.

🧵 9/15

A GIF from The Big Lebowski with the main character saying “That’s just, like… your opinion, man.

Once you did this, you can start discussing these differences in “implicit elaborated construct definitions”. This will allow you to make sure you’re all on the same page regarding what exactly you’re studying.

Or, alternatively, you could design studies based on where you differ, which can then feed into further theory development.

In any case, this will help you to be more transparent: more Open Science!

🧵 10/15

Five tools for better construct definitions

We also discuss how to work with decentralized construct taxonomies in practice. First, we introduce five tools we developed:

1️⃣ A YAML standard for DCTs

2️⃣ The {psyverse} #rstats 📦

3️⃣ Unique Construct Identifiers

4️⃣ The Constructor Shiny App 🏗️

5️⃣ The open source Psychological Construct Repository, PsyCoRe.one

🧵 11/15

A screenshot of the PsyCoRe.one repository

The Constructor Shiny app, for example (at https://psycore.one/constructor) allows you to:

1️⃣ Type in a DCT specification (a comprehensive construct definition and the corresponding instructions for using it);
2️⃣ Or import it from a spreadsheet (or a Google Sheets URL);
3️⃣ And then creates a Unique Construct Identifier;
4️⃣ Lets you download the .YAML file;
5️⃣ And/or lets you submit it to PsyCoRe.one.

🧵 12/15

A screenshot from the Constructor Shiny App

How to use DCT specifications

Then, we discuss how to use DCT specifications in primary empirical research, both quantitative research and qualitative research; how to use DCT specifications in literature reviews; how to use them in theory development; how to use them in practice; and how to use them in large-scale collaborations.

🧵 13/15

A screenshot from the preprint

What I really like about DCTs is that they’re so super-simple, almost trivial.

Mostly, they’re a concrete, tangible tool for better conceptual clarification - but a tool that also helps to share, re-use, and adapt.

They can help a lab to do more consistent research; in teaching, repositories can help students; and they can help knowledge translation towards practitioners.

🧵 14/15

A GIF of the Negan character from the Walking Dead saying “Easy peasy lemon squeezy”

Review along at Meta-Psychology

Last toot: we submitted this to Meta-Psychology. That means that everybody’s invited to peer review along!

Head over to https://doi.org/jnjp and you can annotate using https://hypothes.is 🤩

🧵 15/15

A GIF from the Simpsons showing Mr. Burns saying “Thanks for the feedback” and shows disposing of shredded paper

Gjalt-Jorn Peters' website

Behavior change using medical analogies

Free and easy and versatile QR codes

ROCK Basics

Starting from coded ROCK sources

The simplest ROCK source

Adding more information

The ROCK fundamentals

The ROCK file extension

ROCK codes

Coding patterns

Basic coding patterns

Advanced coding patterns

Structural coding patterns

Segmenting the data

Nested data

Anchors to enable synchronization

Advanced Qualitative/Unified Analysis (AQUA)

Anchor-based Stream Synchronization

Qualitative Network Approach (QNA)

Ethical AI Use in Academia

Guidelines for ethical work in academia

Open Science

UNESCO

EU

Dutch Open Science Program

The Netherlands Code of Conduct for Research Integrity

Parameters for choosing scientific infrastructure

Requirements for using AI in scientific applications

Applying these requirements: ChatGPT and OpenAI

Epistemology and Sovereignty

Open Science Conference Contributions: Pro Tips

OSF Meetings

Being ahead and in control of things

Creating QR Codes

A pro tip for pros

Code book elements

What is a code?

Code identifier

Code label

Code description

Coding instructions

Examples

A machine-readable code book specification

How to create a Tabulated Open Questionnaire (TOQ) specification

Specifying a new questionnaire

The questionnaire label

The questionnaire language

The Unique Questionnaire Identifier

The measured construct(s)

Sources

Ontology references

The questionnaire description

The measurement theory

The measurement scope

The composition, administration, and aggregation

TOQ spec version, date, and authors

Precursors

Comments

Worksheets in a TOQ spec

The metadata worksheet

The items worksheet

The response_registration_templates worksheet

The adapters worksheet

The flanking_content worksheet

The content_types worksheet

Towards interoperability for psychological data

You (or your university) don’t own your data

Preregistering Systematic Reviews

A-bit-of-X-odus

Using Git in Shiny Apps

Health Psychology in 2023: Transforming Paradigms

The Intervention Mapping Summer Course 2023

Alcohol of drugs: wat is slechter voor je?

Intervention Mapping in a thread

Converting a Quarto blog post to a Mastodon thread and posting it

Using the Reproducible Open Coding Kit & Epistemic Network Analysis to model qualitative data

Qualitative, quantitative, and ENA

ROCK to ENA

The example study

The `metadata` worksheet

The `items` worksheet

The `response_registration_templates` worksheet

The `adapters` worksheet

The `flanking_content` worksheet

The `content_types` worksheet

The `{rock}` R 📦