Hi everyone,
I would like to share a workflow we have been developing at LabµFab, a bioengineering and microfabrication laboratory at Universidad Nacional de Villa Mercedes, Argentina.
One of the challenges we encountered was not the lack of software, but rather the difficulty of making different Open Source tools work together as part of the same laboratory workflow.
We are currently starting to use eLabFTW as our electronic laboratory notebook and BookStack as our technical documentation and knowledge-management platform.
Both systems are useful independently, but we wanted to connect them in a way that reflected how we actually work.
From experimental record to documentation
Our initial approach was to use the export functionality of eLabFTW and then import the resulting information into BookStack.
In practice, the structures were not directly compatible with the documentation workflow we wanted. This meant that transferring an experiment often required manual transformation, copying and restructuring of information, and we now that extra efforts in documenting is… sometimes… a lot!!
Instead of building a manual procedure around that limitation, we decided to treat the problem as an interoperability and workflow-design problem.
We developed an Open Source synchronization layer:
eLabFTW
│
│ REST API
▼
┌─────────────────────────────┐
│ eLabFTW → BookStack │
│ Synchronization Layer │
└─────────────────────────────┘
│
│ REST API
▼
BookStack
The result is a new workflow in which eLabFTW remains the source of experimental information, while BookStack becomes a continuously updated documentation layer.
How the workflow works
An experiment can be marked in eLabFTW with a specific tag:
publicar-bookstack
The synchronization process periodically checks for experiments carrying this tag and transforms them into structured BookStack pages.
The process currently handles:
Experimental content and procedures
Custom metadata
Images and attachments
Related experiments
BOM / material information
Drawings
Automatic generation of additional experiment metadata
Change detection
Idempotent synchronization
The integration also calculates a deterministic hash of the relevant experiment information. This allows the system to determine whether an experiment has actually changed before updating its corresponding documentation.
This means that the synchronization can run continuously without repeatedly generating unnecessary changes.
Why use two systems?
We intentionally do not try to make one platform replace the other.
eLabFTW is the experimental record.
BookStack is the documentation and knowledge layer.
The synchronization layer sits between them and provides the workflow that connects those two roles.
Conceptually:
Experiment
↓
Structured experimental record
↓
Synchronization / transformation
↓
Technical documentation
This separation also means that changes to the presentation and documentation structure can be developed without changing the original experimental record.
What is interesting about this for an Open Source laboratory?
For us, the interesting part is not only the software itself.
The important result is the workflow created by combining existing Open Source tools.
Rather than asking researchers to manually maintain several representations of the same information, we are trying to make the infrastructure itself carry part of that organizational work.
This also changes how we think about laboratory documentation.
Documentation is no longer necessarily a separate activity performed after an experiment. It can become a derived and continuously updated layer of the experimental workflow.
Why are we sharing this with GOSH?
We are sharing this because we believe this kind of interoperability problem is common in Open Science laboratories.
Many laboratories already use several Open Source tools:
- ELNs
- Wikis
- Documentation systems
- Inventory systems
- LIMS
- Data repositories
- Automation platforms
However, the challenge is often not the individual tools, but the spaces between them.
Our experience suggests that relatively small integration layers can create substantially different workflows without requiring a laboratory to replace its existing infrastructure.
We are particularly interested in discussing:
How other Open Science laboratories connect their experimental records with documentation systems.
Whether similar workflows already exist in other communities.
How interoperable laboratory software could make these integrations easier.
Whether event- or API-based mechanisms could become common building blocks for Open Science infrastructure.
How we can design these workflows so that they remain understandable, reproducible and maintainable over time.
The current implementation is available as Open Source:
eLabFTW → BookStack Integration
We would be very interested in hearing how other GOSH members approach this problem, and whether similar interoperability layers are already being developed elsewhere.
Best,
Lorenzo Tell
LabµFab — Universidad Nacional de Villa Mercedes
Argentina