Add README.md text to help others host index meta-databases #18
Conversation
There was a problem hiding this comment.
Very helpful! Thanks @rartino.
Now we have two official ways of creating index meta-databases (the other being Docker deployment via optimade-python-tools). Hopefully that lowers the barrier-of-entry significantly.
I found one change that should be applied (if I'm not mistaken), and then also a rather interesting concept I would like to discuss further - it's something we definitely should have, in my opinion.
README.md
Outdated
| - Include also the following segment: | ||
| ``` | ||
| { | ||
| "type": "parent", | ||
| "id": "optimade_index", | ||
| "attributes": { | ||
| "name": "OPTiMaDe providers", | ||
| "description": "OPTiMaDe index meta-database of known providers", | ||
| "base_url": "https://providers.optimade.org", | ||
| "homepage": "https://www.optimade.org" | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
This is new!
I like it - but it defeats our idea of "supporting" only two levels (as we write in the spec here) - whatever support means in this context.
I thought the way to include the providers, was simply to include them with the type provider, again, as is indicated in the spec here.
However! I am all for not replicating too much, i.e., having the same providers spread out over all the different implementations. And having the option to direct the client to a continuously updated list of providers seems to be a good one to me.
My only issue with this then, is actually how we should present this link to the list of providers. While this may be one way, it is a bit misinformative - since the list of providers is not a parent of the index meta-database, but rather it's on the same level (in some sense).
Another option would be to introduce a fourth type, like the plural of provider, i.e., "providers" or a combined type of "provider_list".
Another option would be to introduce a type that refers to implementation on the same "level", like "sibling" (to follow on with the child and parent nomenclature), but that feels a bit mis-informative as well, I feel.
So in the end, I am open to ideas, and it may even end up with what you have here. I would just like to raise the discussion to make sure it all makes sense with the rest of the spec (or adapt the spec accordingly).
There was a problem hiding this comment.
Oh... I had somehow gotten the idea that this was how it was supposed to work so that an unbroken tree was presented to the client, which could be traversed both up and down. But you are right that the present specification certainly do not mandate this setup. In particular, the fact that providers are linked out with provider-type objects instead of child already breaks this symmetry.
So, for now I should just remove this segment. But I like your version with a provider_list link.
There was a problem hiding this comment.
However, maybe my confusion ties into Materials-Consortia/OPTIMADE#217 a bit. Should these link objects really have these kinds of different types, or would it be better to change them to be links-type and put the relationship as an attribute field?
Co-Authored-By: Casper Welzel Andersen <[email protected]>
|
Link types should be changed according to this issue comment as soon as this is officially merged in the OPTIMADE specs. |
CasperWA
dismissed
giovannipizzi’s stale review
The changes mentioned by @giovannipizzi should be implemented in the README.md
|
I've updated this to confirm with the latest changes and utilize PR #34. |
|
@rartino After #34, do we still want to have people create a new repo to have a meta-DB? (maybe yes if they want to host it still themselves to decide how often to make changes?) I would then wait for #34 to be merged, clarify when one should create a new repo vs. just adding the files here, and check again the docs you wrote (I had to do some renaming in #34 after you updated this PR) |
@giovannipizzi Yes, this is still relevant. I'm going to use this setup to keep an index database that remains under my control. You can look at it as this, there is a range of user needs:
Users category 1 hosts their index meta-database in the providers repo. Cloning the repo is for users in category 2. |
|
Ok I see, fine! I'll wait for #34 to be merged first before reviewing, as there might be further changes requested that might affect this PR |
|
There're some conflict that need to be solved before merging |
|
@rartino I will resolve the conflicts here and merge this. |
This PR adds a segment of text to README.md that explains how one can easily fork this repository to host one's own index meta-database that fulfills the requirements to be added to OPTiMaDe's central list of providers.
A preview is visible at: https://deploy-preview-18--optimade-providers.netlify.com/