You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Just to document here: one possible idea we discussed during the optimade workshop is to use the _optimake prefix for all custom properties in jsonl files made by optimake.
Currently, when generating the OPTIMADE jsonl file, custom/provider properties automatically get the
mcloudarchive
prefix by default, or a different prefix if changed via theMC_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:_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?
The text was updated successfully, but these errors were encountered: