Currently, when generating the OPTIMADE jsonl file, custom/provider properties automatically get the mcloudarchive prefix by default, or a different prefix if changed via the MC_OPTIMADE_PROVIDER_PREFIX env variable.
I am still thinking whether it might make sense to keep jsonl file provider-agnostic (e.g. using a placeholder prefix like _custom or _provider). Possible reasons:
- you don't need to know the provider when generating the jsonl file.
- cleaner to serve the same jsonl from different providers.
- easier to distinguish between provider vs the future namespace prefixes (e.g. is
_stability a provider?)
Although I understand that there is value in having the jsonl file exactly mirror the underlying data (mongoDB in our case) and the API responses. So actually, maybe it's good to keep it as it is now.
thoughts, @ml-evs?
Currently, when generating the OPTIMADE jsonl file, custom/provider properties automatically get the
mcloudarchiveprefix by default, or a different prefix if changed via theMC_OPTIMADE_PROVIDER_PREFIXenv variable.I am still thinking whether it might make sense to keep jsonl file provider-agnostic (e.g. using a placeholder prefix like
_customor_provider). Possible reasons:_stabilitya provider?)Although I understand that there is value in having the jsonl file exactly mirror the underlying data (mongoDB in our case) and the API responses. So actually, maybe it's good to keep it as it is now.
thoughts, @ml-evs?