Import of Metadata Schemas as a Template

[reetuelzajoseph]

Describe your feature request precisely

There are multiple metadata schemas out there (json/xml). For example, https://github.com/kit-data-manager/Metadata-Schemas-for-Materials-Science. There are also extraction and mapping tools available which produce metadata documents according to these schemas (SEM, SEM-FIB Tomography). But the metadata documents need to be visualised in a user friendly way and many times missing information need to be added like metadata pertaining to a sample, which are not available for extraction from machine generated data.

It would be great if eLabFTW can have an import button, which would then display the keys from a metadata schema as a template (like the extra fields), and then the metadata can be viewed and edited in the lab notebook itself.

In my ideal world, the extractor/mapper can be also called from eLab and then the resulting metadata can then be inspected and updated then and there itself (or later). This data and metadata can then be uploaded by eLab into repositories which allow schema validation and live interaction with the content, such that the experiment is started with eLab and the data management including storage in a FAIR way is done through eLab. Then eLab accompanies the scientist through the entire workflow.

As an example, I can also show a snapshot of how the SEM schema looks in another ELN, currently importable with the api, but integrated workflow is in development:

Pro Support

No response

[NicolasCARPi]

Hello again Reetu,

I will try and see how feasible importing and using such a schema in eLab is.

[juliomateoslangerak]

Now that we talk about this... It would be great to be able to use linkml to write yaml schemas (way more readable than other formats and interoperable. https://linkml.io/

and there is this tool, dataharmonizer that creates, using linkml schemas, a relativelly user-friendly excel-like form. https://github.com/cidgoh/DataHarmonizer

[tomio13]

Reading this issue, I have the feeling that it is quite about how to make forms, and the current form editor I find to be good on the way (personal opinion only).

Looking into those two projects, they are nice, but may be rather complex extra dependencies...

Looking into the metadata schema, a quick look shows the following:

• it is complex with using links ($ref) instead of a flat tree structure
• it uses 'object' elements, which are about the same as the subsets I talked about in issue 4166
• it is a bit mixing a triplet store and a form description. I will try to dig up the description of the structure, then it would be possible to build a converter

As it looks, it can be interpreted and straightened out for a form structure (like in extra fields), but the modular structure would require some kind of subsets to be supported.