Christophe Guéret: Stop making tools! An afternoon at the E-Humanities Group.
[ Note: A group of DiXiT fellows may develop some of the ideas presented here during the next DiXiT Convention ... but this is still to come! ]
The E-Humanities Group is an initiative of the KNAW (Royal Academy of Arts and Science – Netherlands). Researchers of KNAW institutes and universities collaborate, using digital technologies in the humanities and social science. The projects of the E-Humanities Group include different subjects: “The riddle of literary quality“, “Tunes & Tales. Modelling oral transmission” or the Dutch Census Data, which aims to build a semantic web-data of historical information.
The last one I went to has a provocative title: Stop making tools!
Information about the speaker, here.
And the slides of his presentation, here.
Christophe presents the common situation in which the output of a research project is (also) a TOOL, that allows users to search and visualize data gathered and processed. Let’s make clear that he is considering those tools, as web applications, that are built at the end of a project, not the one used during the research. (see slide 2).
Tools have several problems: it’s quite impossible to build a tool that satisfies all researcher’s questions; actual tooling heavily depends on the skills and preferences of the team member coding it, so that the tool maintenance is very hard (once the developper changes job, as it happens quite often especially in small and medium size DH centers).
The main assumption behind Christophe’s talk, largely shareable, is that DATA are the important thing, and not tools. And, hopefully, data will survive applications. This last is clearly illustrated with the wine/fish metaphor, from James Governor’s post 🙂
DATA are the important thing and we need easy ACCESS to them.
How to do it? The keywords in Christophe talks are: API, REST and JSON (JSON-LD, for a step further). So, expose your data in JSON and build an API with a REST architecture. Using the API, then each researcher will build the TOOLS that s/he needs.
Some of the advantages of an API is that it needs less code, it allows to open just a part of your data and enables fine-grained access to them.
We can define an API as a software interface to data. An example will make it clearer. Twitter has an API, on which its tools are built. If a researcher wants to use Twitter data, s/he cannot download them, but can use them through the API. It’s like listening to music in streaming: you use it, but not own it.
In Christophe’s words: the difference is between “the making of tools with baked in data as compared to making data available via APIs“.
An animated discussion follows the talk. The ideas presented were convincing and impressive, but some concerns were raised.
Someone objects that, even if building a tool on an API requires less code, it is still too complicated for the common humanist, including digital humanists. One could respond that also making TOOLS is complicated and requires technical skills. But it is also true that CMSs, as WordPress, are simplifying a lot the process of building a web-application.
Preferences also depend on what the researcher will do. If the project is NOT interested in making available data for further tooling, build an API is probably not very important; it has been stressed that in some cases the possibility to download the whole set of data in, let’s say, csv format would be enough for the researcher’s analysis.
Useful and lively talk, I felt I have learnt something, waiting for the next E-Humanities Group meeting!