Something is happening in the world of qualitative data analysis. Since the first versions of MAX, ATLAS and NUD*IST (now NVIVO) were launched in the early1990s, the field of (commercial) QDA-software suffered from one important shortcoming: Proprietary solutions blocking exchange and triggering painful questions by the trusted data repository of your choice.
When I learned earlier this year that all major developers of QDA software had agreed on a common exchange standard for QDA projects, I was more than just a little excited. As it turned out, the following major publishers began integrating it into their tools:
With the recent release of MAXQDA2020 also my favourite analysis software joined them. Yet what is this new exchange standard exactly? What can and what can it not do? And most importantly: What does this imply for the future of qualitative data analysis?
What is the REFI-QDA exchange standard?
REFI is shorthand for Rotterdam Exchange Format Initiative. This initiative originated in September 2016 during the KWALON Conference “Reflecting on the Future of QDA Software” in Rotterdam. There, the CEOs of eight software companies met and began working on an exchange standard that allows for interoperability between their products.
As a first step, they launched the REFI-QDA Codebook in March 2018. This is a standard format for defining codes (categories, tags) for usage in qualitative data analysis. This export format allows for interchangeability of different code systems between the software.
As a second step, they launched the REFI-QDA Project standard in March 2019. An exchange standard, that allows to move entire projects from one software to another. The standard exchange file is XML based and therefore not just allows specialised QDA software to open it but allows any software that is able to process XML to access the data. (You can find the XSD specifications of the XML format here ).
What can it (not) do?
The REFI-QDA standard is an exchange standard. Therefore, by the nature of how the thing came into existence, it is the minimum that the different software developers could agree upon. Some of these software programs have not just different terminologies but also differences in their underlying logic and, of course, many of them offer unique features. Thus, whenever a project is moved from one software to another, some information will be lost.
However, although something is lost, much is gained. As we can see bellow, the core of the project is transferred. Here, I took my Master thesis and exported it from MAXQDA2020 to ATLAS.ti 8:
Of course, some things look different. The code hierarchies of MAXQDA are reflected in the code names and code relations of ATLAS.ti. The table of document variables was transformed into a list of “document groups”. Also, the table documents of MAXQDA are not contained in the REFI standard. The result is the same when sending the data the other way and looking at a genuine ATLAS.ti project in MAXQDA: what is unique in a software, is lost.
What is that .qdpx file?
However, we cannot only look at our project from within (commercial) QDA software, but we can also look at the exchange file as an XML. For this, even a free and simple tool like Notepad allows us to access our project.
The “.qdpx” file that is created for the exchange, is basically a .zip file that can be opened after renaming it. This file contains a folder “sources” with the plain documents and one file called “project.qde” which is an XML.
The XML file contains an element <codebook> which lists all the <codes> used for annotation. The element <sources> contains a list of the documents (the element <TextSource>) and the <codings> within each document. The codings are defined by start and end position in the linked document. Furthermore, elements <note> for memos and <sets> for document groups and variables are available.
So we see from the structure that it is not a group of text documents with internal XML markup, but rather a list of codes and coded segments that are linked to external files (called ‘stand-off markup’). This format is interpreted by the QDA software and transformed into a corresponding project file. (You can download the entire project above as a .qdpx / xml file here).
We will go into these differences in more detail in a follow up article. For now, most importantly, our documents, codes and coded segments were successfully transferred from one software to another and we can even access them with an XML editor.
What does this imply for the future of QDA?
The exchange between software programs allows access to a much wider range of analysis tools
Cooperation and follow-up studies across the boundaries of research software are possible
Even after a license runs out the project remains accessible independent of proprietary software
Projects can be easily archived in an open format
The analysis done in (commercial) QDA software becomes now open to use as an XML