-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for "direct" jsonl files #50
Comments
Would you still want people to provide an optimade.yaml to trigger the scraper at the your end? Otherwise you have to rely on file extensions and the file header which might have many false positives (we can also extend the yaml file to support/require the new database description field to be served in the OPTIMADE metadata) |
Could be that we accept either E.g. the example
I think currently it doesn't do anything, right? And in the future, would it just validate the file? But maybe this makes sense, open to discuss further. |
Coming back to this (perhaps it can be closed in the original context), I would quite like |
yep, i agree that |
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 andoptimade.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.The text was updated successfully, but these errors were encountered: