.eln import from RSpace

[jamesbird58]

Detailed description of the problem

Exported minimal data from RSpace community instance: two documents with text in the main body. Exported the notebook containing them from RSpace into .eln format. Imported into experiments in eLabFTW and got much more than two untitled entries, none of which appeared to correspond to the two experiments: the text in the main body of each RSpace document appeared nowhere.

Expected Behavior

Expected to see just two entries with matching names and text in the body. This behaviour was expected to ensure interoperability.

Steps to reproduce the behavior

1. Export .eln from RSpace
2. Import into eLabFTW experiments

What eLabFTW version are you using? Visible in bottom right of a page.

5.0.4

Do you have any idea what may have caused this?

No response

Do you have an idea how to solve the issue?

No response

Additional information

No response

[NicolasCARPi]

Hello,

It would be most helpful if you can provide a .eln from Rspace, so I can have a look and try and reproduce the behavior you see.

If we look at this example file: https://github.com/TheELNConsortium/TheELNFileFormat/tree/master/examples/RSpace

we can see 5 parts:

And importing this creates 5 experiments. So it looks like intended behavior. But maybe something changed in-between. So if you can export non-secret things, it would be most helpful, otherwise, there is nothing we can do about it.

[jamesbird58]

Hi, I had to compress it to zip to share on Github. Otherwise it's unaltered:
RSpace-2024-04-23-12-52-xml-user-Cp3k0hlibwUOtA.eln.zip
I went with an even more MWE. In RSpace there's the one file (plus defaults):

Exported all from RSpace:

Imported from file in eLabftw:

Selected .eln filetype input:

A total of eleven entries appeared. The tag appeared in one of the 11 entries, with the text appearing in an uploaded .xml within the same entry. If the behaviour is intended, is it useful?

[NicolasCARPi]

I can confirm that the import doesn't work as expected.

But, looking at the files in the .eln, and the ro-crate-metadata.json, I see a few issues:

1. The node with @id ./ references folders in hasParts that don't exist in the archive, but they are relative to the archive, so that's a bit weird:

Most of the folders shown in the image below don't exist in the ro-crate!!

So we endup with Snippets that are part of Gallery and contains SNIPPETS_Shared, but none of this can be found in the archive. So I'm not sure why they are added to the JSON-LD graph in the first place.

All these nodes that are declared as Dataset in the ro-crate-medata.json file end up being an Experiment in eLab.

And the one real experiment (with Tag1) is pretty empty because it doesn't contain anything:

See this node above? It should contain things such as text or description or author or other similar fields that describe the experiment in a standardized format. That's the whole point of .eln. But here they simply link to their XML files, which of course is simply considered as a File and not interpreted.

So I have a feeling their .eln export is far from being finished and usable, at least outside of Rspace context.

What they need to do is extract useful info from their xml file, add it as attributes to the Dataset node, and then eLab and others can import it. Here it's too basic to be useful.

[jamesbird58]

Thanks Nicolas, I've contacted RSpace with the information. Would you happen to know if other .eln-using ELNs have tested their interoperability? I can do some digging if not.

[NicolasCARPi]

See: TheELNConsortium/TheELNFileFormat#61 (comment)