Evaluating changes to the ELN File Format for RO-Crate validator compliance

[jmanideep]

This issue arises from the behavior discussed in crs4/rocrate-validator#43, where the rocrate-validator validate CLI command fails to validate a zipped RO-Crate unless the ro-crate-metadata.json file is located at the root level of the ZIP archive, as specified by the RO-Crate specification .

The current ELN file format structure may produce RO-Crates that fail validation under these conditions.

This raises to two questions:

1. Should the ELN File Format structure be modified to ensure compliance with the RO-Crate specification, specifically by placing ro-crate-metadata.json at the ZIP root?
2. Alternatively, should the validation errors be ignored, given that the ELN file format serves a specific use case and might not need full compliance with the RO-Crate validator?

[NicolasCARPi]

1. No. Once unzipped, the resulting folder is a valid ro-crate, so I don't see an issue with that approach, except the need to unzip before using the validator on it.
2. Which errors?

[jmanideep]

1. I agree that unzipping the archive results in a valid RO-Crate. However, the need to manually unzip files before validation might introduce additional steps. The intent behind this discussion is to explore whether to align the zipped format directly with the RO-Crate specification. The requirement to have a single folder at the root of the archive to prevent the accidental file overwrites makes sense. But this approach conflicts with the RO-Crate specification.
2. The validation errors occur when the rocrate-validator checks a ZIP file containing an RO-Crate where the ro-crate-metadata.json file is not located at the root of the archive.