Prefixes not directly connected to databases

[rartino]

During the OPTIMADE call came up the question that we already have two types of prefixes in https://providers.optimade.org/providers.json

Those that are specifically tied to databases, and those that are more "general", i.e., tied to a tool, or, we discussed things like _cif_ that refers to a definitions out of a different standard.

We seemingly agreed that it is in our interest to keep allowing both these types, and that requires at least a bit of clarification in the specification as it is presently written. But also the consensus seemed to be that we still want to keep them in the same register since they occupy the same namespace (i.e., https://providers.optimade.org/providers.json ). There was also the point that a prefix not tied to a database provider still should have a maintainer pointed out (so, presumably we point out that entity in the prefix database).

This issue is for doing the necessary update to the text.

There may be a good idea to also separately discuss the idea of a _cif_ prefix. (Actually lifted the first time in #143 but rejected there.)

[ml-evs]

Just to pick this up, this was often posed as a solution at the workshop to many problems/enhancements (#468, #466, #455, etc.). I'm happy to write something up this week on the specification side and try to make the first example namespace. Now we have the advanced property definitions basically in, I think this is the time to pull the trigger on this.

[ml-evs]

I've started writing this (and will make a draft PR shortly) -- there are lots of changes to the spec where we talk about database-specific providers, but I am still toying with how to name this new "thing".

My options so far are:

• Definition-provider-specific prefixes, where we simply extend the concept of database provider to a definition provider, and the mechanism for registering them remains identical (perhaps with one additional metadata field in the providers list that makes it clear who is a database and who is not --- this would mean that each definition provider has a base URL that could also potentially serve a static info endpoint.
• Namespace-specific prefixes
• Community-specific prefix

[merkys]

I like "Namespace-specific prefixes". This nicely encompasses both the meanings of database-specific and field-specific prefixes.

[vaitkus]

The IUCr uses the term "reserved prefixes" in their dictionaries [1], but it might be a bit too generic for OPTIMADE.
"Namespace-specific prefixes" does sound good.

[1] https://www.iucr.org/resources/cif/spec/ancillary/reserved-prefixes

[rartino]

Is "specific" needed? Does "namespace prefixes" say the same thing?

[ml-evs]

Sorry, typed up my suggestions in a bit of a hurry. In #473 I refer to "namespace prefixes" as encompassing both database-specific and "new collaborative thing"-specific prefixes.

The name I currently have for "new collaborative thing" is a definition provider, but I'm not entirely set on it. My call for suggestions that mixed these concepts probably confused things :P

[merkys]

Can we close this as #473 has just been merged?

[ml-evs]

Gladly! Closed by #473