Additions to providers.json

[rartino]

I'd like to add provider 'httk' in providers.json, even though it is more of a framework than a database ("my" database is 'omdb'). I need this for providing 'httk'-specific features under an _httk_ prefix namespace that will be common to everyone who uses httk, which is separate from the namespace _omdb_ that I'll use completely local to the omdb database.

I see a similar need for our optimade implementations and libraries. So, it probably does not hurt to reserve the _optimade_ prefix for us. So that is also in this PR.

Furthermore, and this I suppose can be more controversial, we might want to also reserve _cif_ as a common standard for embedding cif filelds inside OPTiMaDe. (But if there is opposition to this, I'm fine with take it out or extract it into a separate PR.)

[merkys]

While I agree that reserving _cif_ is good, "type": "provider" for _cif_ sounds strange. Maybe in future it'd wise to separate providers and reserved prefixes.

[rartino]

I did not find anywhere in the spec where it said "type" must be "provider" here. But, if we change it to something like "reserved_prefix", the file probably shouldn't be 'providers.json'.

Standardizing a _cif_ namespace before implementations start to utilize their own prefixes for this may greatly help cutting down divergence on identifiers. I foresee that I am like to get a massive amount of _httk_cif_ ... properties otherwise.

[rartino]

Requesting reviews from a list of people to either get this approved or at least understand if this is controversial, and I should move out the (hopefully non-controversial) 'httk' prefix in a separate PR.

(I suppose none of these changes are release-blocking for v0.10, but with this system of "ask for a prefix via a PR" it is nice if we don't drag too long on such requests.)

[fawzi]

I second @merkys that seeing cif as provider sounds strange, but probably the best solution for the current situation these are actually the providers of the terms (metadata)

[merkys]

I approve this PR to get httk and optimade prefixes into 0.10.0. I have some reservations regarding the status of cif as a provider, but we can adjust that later.

[giovannipizzi]

I'm OK with adding HTTK. Actually, I'll probably add another PR to add the aiida prefix.

It's also ok that it's wise to reserve optimade, even if don't have an official optimade provider yet, it's better to reserve it to avoid confusion.

Instead I would remove cif - I don't see the usecase, this should be in my view the list of providers, and the ids are to be used in the form _ID_xxx for keywords. So I'm not sure this extension is correct. I would remove this for this PR and we rediscuss.

[sauliusg]

I agree with @giovannipizzi , cif is a format an thus orthogonal to providers. So a provider, say _cod_ can offer a response format cif.

optimade is a useful addition.

[rartino]

Ok, I removed 'cif' as it clearly needs more discussion. Please re-approve the new version.

Instead I would remove cif - I don't see the usecase,

The cif dictionaries provide a large number of already standardized properties. At least between e.g., httk and (I assume) cod, we will both be embedding data based directly on these. It would be nice with one common standardized prefix for these.

this should be in my view the list of providers,

In my view, there are three different entities that have use for reserved prefixes:

1. Database providers (e.g., mp, mcloud, omdb)
2. Framework implementations (e.g., aiida, httk, ase)
3. Common namespaces (e.g., cif)

But I note that in the spec right now, "provider" is defined broadly enough that it applies to 1 and 2, so with this we are in an OK shape as it is (without cif).

[giovannipizzi]

Exactly, I agree that at this point only 1 and 2 are covered.
For a common prefix for properties, this is something that needs to be specified in the specs (also because I think you are imagining to have properties like cif_xxx rather than _cif_xxx).

[rartino]

I had very much fully intended to use _cif_something.

I suppose we could standardize on cif_, etc., for "category 3"-type use, and have those prefixes in an appendix in the spec.

@sauliusg I'm not talking about cif as an output format (which is also a good idea), I am talking about serving e.g., _cif_space_group_name_Hall as a property in wait for us to create an OPTiMaDe standard for symmetry info.