I am wondering if we really need to support "direct" jsonl files in the optimade.yaml format.
Conceptually to me it seems that the current purpose of optimake is to generate a jsonl file from other structural data formats and optimade.yaml is something that help to achieve this.
If we already have a jsonl file, then the only purpose I see is validation, and the optimade.yaml file does not seem strictly necessary.
But perhaps generating jsonl files and validating them is different enough to separate them?
E.g. we could have a different optimake subcommand for validation (optimade validate <jsonl-file>?)
Regarding the Materials Cloud Archive service, this change would affect it, as then we should add support for a "direct" jsonl file without any optimade.yaml file.
I am wondering if we really need to support "direct" jsonl files in the
optimade.yamlformat.Conceptually to me it seems that the current purpose of
optimakeis to generate a jsonl file from other structural data formats andoptimade.yamlis something that help to achieve this.If we already have a jsonl file, then the only purpose I see is validation, and the
optimade.yamlfile does not seem strictly necessary.But perhaps generating jsonl files and validating them is different enough to separate them?
E.g. we could have a different
optimakesubcommand for validation (optimade validate <jsonl-file>?)Regarding the Materials Cloud Archive service, this change would affect it, as then we should add support for a "direct" jsonl file without any
optimade.yamlfile.