Updated Kadi4Mat examples

[jmanideep]

Based on the recent discussion Nesting vs. using references, the export function in Kadi4Mat has been updated.

Changes:

• Flattened all the nested entities in the metadata file(i.e., ro-crate-metadata.json), namely author, license, and publisher information.
• The RDF (Turtle) export of the record is also included during export along with the JSON export.
• Information about record links (i.e., mentions) is removed from the metadata file in favor of the information we already have in the exported JSON/RDF files and kept the metadata file to the basics.

Prospective:

• The export will be made customizable to select(by the user) the type of export data to be included.

[NicolasCARPi]

Hello,

Would you be able to add a sha256 property to objects? It has become mandatory in eLab for security and integrity reasons. Security because it helps prevent any shenannigans with path traversal. I realize I didn't communicate about this change with the community...

[nicobrandt]

Unfortunately not easily at the moment, as we only store MD5 hashes of files. Sure, MD5 is not secure, but we only use these as simple (and cheap) file integrity checks for downloading/uploading (similar to how e.g. Zenodo does it) and for showing file revisions.

That being said, we could calculate these on the fly when exporting crates, but that should probably not be the default behaviour, as in our case some crates can get really large. Or we switch from MD5 to SHA256 in general, but that is also easier said than done and something we need to discuss internally first. Is the plan to make this property mandatory in the specification or just in eLab for now?

[NicolasCARPi]

That being said, we could calculate these on the fly when exporting crates

Yeah that was my idea.

Is the plan to make this property mandatory in the specification or just in eLab for now?

It's up to the discussion. I think one good approach would be that I find a way in eLab to allow for the absence of this property while still prevent the arbitrary file read vuln that this could open. On the other hand, it would be better to always have it!

[nicobrandt]

Out of curiosity, which kind of vulnerabilities are you referring to? Something specific to eLab?

[NicolasCARPi]

@nicobrandt can you join this room: https://app.gitter.im/#/room/#eln-consortium:matrix.org ? and then we can discuss this privately.

[nicobrandt]

Yeah good idea, I joined :+1:

In the meantime, can this PR be merged? So we at least have an up-to-date example reflecting our current export.