Interoperability

[jamesbird58]

Hi,

When testing interoperability between Kadi4Mat, eLabFTW and RSpace (those I have access to currently), I found that in only one instance is expected behaviour given, when exporting from Kadi4Mat and importing into eLabFTW: see the table below. I'm using the latest version of eLabFTW, the hosted demo instance of Kadi4Mat and RSpace Community. This is a continuation from this post, where I've contained to use MWEs containing tagged single entries with text and a tag in each case.

Import (below) / Export (right)	Kadi4Mat	eLabFTW	RSpace
Kadi4Mat	n/a	❌	❌
eLabFTW	✅	n/a	❌
RSpace	❌	❌	n/a

[NicolasCARPi]

Thank you James for opening this issue. It would help tremendously if you could pinpoint specific issues, e.g importing Kadi to eLab will make tags look weird.

Here a red cross is not enough actionable information for us.

[jamesbird58]

Hi Nicolas, thanks for the reply. Sorry for leaving out detail (again!). RSpace will only read any .eln generated internally. It is stated in text when you go to import. Inevitably then, .elns fail from other ELNs. Kadi4Mat will import .json files only as records, not the .eln format. eLabFTW import of a .eln exported from RSpace gives unexpected behaviour as described previously. When importing .eln from a Kadi4Mat export, behaviour is as expected: basic entries (text, tag etc.) mapped successfully with no entry proliferation. I didn't trial any more complicated scenarios which would carry additional keys in the RO-crate. I'll be away from a PC all weekend, but the behaviour should be very easy to reproduce in demo instances.

[NicolasCARPi]

eLabFTW import of a .eln exported from RSpace gives unexpected behaviour

I disagree. As stated in elabftw/elabftw#5054, the issue is with how Rspace generates an .eln that is only suitable for their consumption, eLab does what it should do, but the eln is wrong in the first place.

Feel free to join us in our next discussion. I hope in the mean time we'll have time to look into it more thouroughly. Currently I'll have to focus a bit on elabftw <-> elabftw before looking into it.

[nicobrandt]

Regarding Kadi, we don't support importing ELN files via our GUI yet, so this is less of an interoperability issue and more of a missing feature I guess. However, we have a helper function to do this as part of our API library (https://kadi-apy.readthedocs.io/en/stable/usage/lib.html#kadi_apy.lib.misc.Miscellaneous.import_eln) if you want to test it out. It does have some Kadi-specific handling, but should be able to import the basic metadata and data from other ELN files as well.

[jamesbird58]

Thank you both @NicolasCARPi and @nicobrandt for your detailed answers.

the issue is with how Rspace generates an .eln that is only suitable for their consumption, eLab does what it should do, but the eln is wrong in the first place.

That makes total sense to me, thank you for explaining.

Regarding Kadi, we don't support importing ELN files via our GUI yet, so this is less of an interoperability issue and more of a missing feature I guess.

As does this!

I suppose what I'm truly wondering is then whether the table here could be padded out to demonstrate the current situation?

Website	GUI .eln export	GUI .eln import	API .eln export	API .eln import	Interoperable
eLabFTW https://www.elabftw.net	✅	✅	✅	❌	?
Kadi4Mat https://kadi.iam.kit.edu/	✅	❌	?	✅	✅
RSpace https://www.researchspace.com/	✅	✅	?	?	❌

The question marks are only for those scenarios which I either haven't tested or haven't been able to, only through a lack of means. As is probably obvious I'm new to engaging on Github, and am not particularly technical. I apologise for any misunderstanding. I really appreciate and respect the solutions you've built.

[stain]

The current specification is a bit soft on which annotations are needed in the ro-crate-metadata.json - would some additional types/properties in there help improve that interoperability?

[NicolasCARPi]

@stain To address this question we thought of having a script parsing all the .eln example ro-crate-metadata.json and listing the properties present for each nodes, so we can have an histogram of the most used. For instance @id will be 100% and text always present for @type: Dataset. But shasum might be present only in a few for File, and mention might be present only in eLab, etc...

Note that currently eLabFTW is working heavily on the .eln import/export so the current example is outdated and an update will come soon, including the fields discussed #58 .

[NicolasCARPi]

@jamesbird58 I've edited your table to mark eLabFTW ELN export through api supported (e.g. https://demo.elabftw.net/api/v2/experiments/275?format=eln). There is currently no exposed API endpoints for import. Also, the last column "Interoperable": what does it mean? This cannot be a yes/no. Also it depends what you compare it to. I'd suggest removing this column and restrict it to measurable things.

[jamesbird58]

@NicolasCARPi apologies for the delay. I get a 404 for the link unfortunately. wrt to the 'interoperable' column, that was reference to the OP.

So the measurable aspect is that the software can 'meaningfully' export a .eln that is readable in another. Of course, the interpretation of 'meaningful' is up for debate, but as we discussed, the RSpace .eln export couldn't be meaningfully imported into eLabFTW, hence the cross. Kadi4Mat's export was easily interpreted in eLabFTW. eLabFTW was left as a question mark only because I didn't have the means to import into another software. In short, I couldn't think of another obvious brief description for the column header.

[NicolasCARPi]

The demo is reset every 24h, so any link to it becomes stale pretty quick. But the point is that adding the query parameter format=eln will create an eln archive of the resource.