those.toolsis a software development and design studio for research, editorial and publishing practices in the arts and social sciences. We develop free and open source tools for writing, archiving, mapping, designing and publishing research.
We activate and adapt each tool to the context of every project we collaborate on. Wether for self-initiated projects or commissioned work, our aim is to explore new ways of doing things, recognizing the epistemological function of tools with a strong focus on collective creative processes.
These processes can produce a variety of objects: books, web platforms, sound installations… They may also, we hope, produce new ideas, new perspectives, new relations.
Open to collaborations, those.tools welcomes fellow designers, developpers, artists with an interest in these topics.
a / r asbl – art-recherche (art and research) - is a non-profit organization for the support, exchange, circulation and promotion of arts research in the Ecoles Supérieures des Arts (Higher Schools of Arts) of the Wallonia-Brussels Federation (FWB). Its website, made by La Villa Hermosa in 2020, contains an interface to a database of all the documents linked to the research projects the organization has supported.
Since the database had to be accessible with the OAI-PMH protocol (Open Access Initiative - Protocol for Metadata Harvesting) which is a protocol used by academic libraries to "harvest" metadatas from external sources, the database initially used the collection management software Collective Access which has a built-in implementation of the protocol. But Collective Access is pretty heavy, demands a lots of memory and cpu usage and is not meant to easily welcome custom modules and functionalities. So we re-built the database with Processwire, an open source CMS that we use a lot for its flexibility and its ability to handle complex database relations.
db interface on the a-r website
We kept most of the specific features of the original database architecture into the new one to maintain compability with the already encoded content while changing some specificities implied by Collective Access and its focus on "controlled vocabularies". This concept, linked to library taxonomies through the "semantic web" paradigm implies that every category, document type, relation type or document property has to be part of a vocabulary and that the creation of a new type has to be validated (or controlled) before being implemented into the system. For example, if a researcher wants to encode a relation between two documents, like "contradiction", but "contradiction" is not part of the relations vocabulary, she/he has to make a request to add "contradiction" into it. Considering the lack of normalized methodologies in the field of artistic research, defining such vocabularies is impossible and probably not even desirable. In the new database, it's up to the researcher to create their own categories, relations types and document types, while encoding the content.
The faceted search is a functionality that was already present in the old database and that we had to implement into the new one. This method of finding documents by narrowing gradually the documents list with combinable filters (i.e. document properties) can be process intensive, and was already slowing down the page display with the old system. To solve this issue, we had to write a simple cache system that makes the page display performance a lot better in comparison with the old database. The API responses and the database pages on the website are now almost instantaneous.
faceted search on the website interface
One of the original requisite of the project was that the database should be independent from the website, meaning that it should have its own server space and its own CMS. What it means in term of conservation practices is that any modification to the website (even a complete rebuild) doesn't imply any modification to the database and vice-versa. It also means that the interface to the database in the website is just one example of an interface that can be made to access the data. Any research project could make another one and use and display the data differently. In technical terms, it makes the CMS database a headless CMS, meaning a CMS that can be requested by external applications, with a dedicated API (Application Programming Interface). Collective Access had such an API built in but here we had to write it up completely, allowing us to make one that precisely fits the structure of the database. This API is meant to evolve with the database usages. In its current state, the access points are :
We changed the architecture of the database to make the encoding of the documents more accessible to the researchers themselves. Each research project has its own space, accessible only to its researchers with personnal credentials. Until now, the Collective Access interface was preventing researchers to encode their own content, it is now a lot easier. The new architecture was also built with the idea of implementing new tools (mapping/writing tools) for researchers in the future.
