ELN Consortium Meeting XII - November 17th 2025 - 3PM CEST

[NicolasCARPi]

visio link

[akos326]

@NicolasCARPi what is the meeting about? My team is planning on working with the ELN format (and RO-Crate profiles in general). Can some of us join?

[NicolasCARPi]

@akos326 sure, please join. We did not set an agenda yet.

[omkar-ethz]

Dear ELN Consortium

We are SciLog, an open source electronic logbook developed and used at Paul Scherrer Institute in Switzerland.

As part of Open Research Data initiative, we are looking to interoperate with other ELNs / related systems (mainly in Switzerland - e.g. openBIS).

We found the ELN format quite useful as it would help us interoperate beyond the ORD project, and are planning to adapt the format slightly to better suit our use case. Our adapted spec of the ELN Format is here.

In the spec we've also included an example .eln export, that corresponds to this logbook:

As you may have noticed, our adaptation mainly differs in allowing more types than just Dataset on the entities - this would help us write parsers more easily, and better semantically describe our entities.

If possible, I'd like to drop in in today's meeting to get your thoughts on our project.

Best
Omkar on behalf of SciLog at PSI

[NicolasCARPi]

Hello,

Please come to the meeting. But my suggestion would be to stick to the specification and use another attribute, such as genre to discriminate your types of entries. Sticking to the RO-Crate/ELN standard is the most useful thing you can do. It's customizable enough that you shouldn't have to deviate from it. If you deviate from the standard then you're just implementing yet another file format that we won't have time (nor want to) write code to handle your special case.

So to summarize: stick to the standard and have a useful .eln that is actually interoperable OR live by your own rules and have something that no-one can read which defeats the whole point of an interchangeable format.

I would be immensely surprised if you cannot describe your entries exactly how you want with JSON-LD and the current RO-Crate spec.

All of our import codes look for a node of type Dataset, deviating from that is really a sure way to kill your .eln as importable in other software.

[NicolasCARPi]

Raw output from AI, didn't read it:

Summary

The ELN consortium team discussed the integration of ELN solutions into their respective platforms, addressing technical challenges related to the ELN format and interoperability between different systems. Sydney presented the website created to enable sharing of ELN templates between institutions and the challenges related to international scientific categorization. The team also discussed questions from consortium members, technical issues concerning datasets, and developments in their fork of Dataverse.

Next Steps

Omkar: Open a pull request on the repository with the ELN file for Scilog after discussing with OpenBiz about using a type table including “dataset”.

Nicolas: Review the logic handling type tables in eLabFTW to accept multiple values as long as one of them is “dataset”.

Florian: Merge pull request number 1 on the ELN specifications repository concerning child datasets.

Sydney: Draft a motivation and intent statement for the ELN consortium website.

Sydney: Create step-by-step instructions on how to become a member of the ELN consortium.

Nicolas: Add a link to the validator created by Stefan on the consortium website.

Sydney: Finalize the choice of scientific categories for the template-sharing site, exploring Wikidata as a potential source.

Nicolas: Add a FAQ section to the ELN consortium website.

Balazs: Continue discussions with the Dataverse team to create a meaningful pull request regarding the integration of ArrowCrate.

Synthesis
Integration of ELN Solutions

The ELN consortium team discussed how ELN solutions integrate into their respective platforms. Balazs explained that the Staki Institute in Hungary is evaluating ELN solutions to integrate with their data platform, while Omkar and his team at PSI are working on interoperability between their Silog logbook and other Swiss systems. The team addressed technical challenges related to the ELN format, especially handling node types and “genre” properties, with Omkar noting they need to consider interoperability requirements with OpenBase.

Sharing ELN Templates

Sydney explained that the website was created to allow users to share ELN templates between institutions, responding to requests from the Research Data Manager Club. Templates help structure entries in electronic lab notebooks more efficiently, with pre-filled information for repetitive experiments. The team is discussing categorizing templates by scientific discipline, potentially with subcategories, though the question of which existing vocabularies to use remains open.

International Scientific Categorization System

Sydney and Torsten discussed the challenges in finding an international scientific categorization system, expressing a preference to avoid the DFG system, which is highly specific to Germany. Torsten suggested exploring Wikidata as a potential source, noting that it may be useful in fields where other resources offer little information. Sydney raised the question of whether categorization should be limited to scientific disciplines or be broader, and the team agreed to continue research while seeking suggestions from the community.

Consortium Membership Process

Sydney proposed writing detailed instructions on how to become a member of the consortium, including the steps for submitting a GitHub request with an ELN file and the approval process. Florian explained that there had been issues with datasets not being imported into the root, but current examples would allow these datasets to be included at the root while keeping them separate. The team discussed an unresolved issue mentioned by Stefan, though Florian noted it was no longer a high priority.

Dataset and ELN Restrictions

Nicolas and Florian discussed a pull request related to restrictions on datasets in a repository, while Torsten noted that this simple use case was not yet covered by the API. Balazs explained that his team is currently evaluating different ELN solutions (Laboratory Information Systems) and working with AeroCrate, especially on the ARP platform that integrates Dataverse with a schema registry based on CDAR and Arrow Create import/export features. Balazs mentioned that this dataset restriction is no longer necessary in their current configuration.

Dataverse ArrowGrid Fork Developments

Balazs described developments in their Dataverse fork, which includes improved ArrowGrid support, including import and export. He noted they are in discussions with Harvard and Dataverse developers to create a significant pull request based on their improvements in Starky. The meeting concluded with a brief discussion about the next ELN Consortium meeting.