search

Materials-Consortia / OPTIMADE

Specification of a common REST API for access to materials databases
https://optimade.org/specification
Creative Commons Attribution 4.0 International
83 stars 37 forks source link

Materials classes: periodic table elements groups #448

Closed blokhin closed 1 year ago

blokhin commented 1 year ago

Dear colleagues,

we're now releasing the periodic table user interface component, and one of its features is the whole column or row selection, such as chalcogens, actinides, period 6, group 11, etc. While we are about to fully support such groups on MPDS (e.g. {"classes": "tetrels, actinide"} in our API /v0 or _mpds_classes HAS ALL "tetrels", "actinide" in our API /v1) as well as in the other projects, I'm thinking if it makes sense to promote the names of these groups further to the standard.

Of course, their support should be absolutely voluntary, but I personally think it's way much easier to query just alkaline instead of Be | Mg | Ca | Sr | Ba | Ra or period 2 instead of Li | Be | B | C | N | O | F | Ne. On top of that, it also stimulates reach and interesting queries exploring periodicity and chemical elements similarity. Note, this is relevant not only for the unary compounds, but for the compounds of any arity (binary, ternary), including those groups of elements.

Here is the whole list of the element groups, as we are now supporting (or about to support) them.

What would be your opinion on that? Beware, there are some caveats on the singular-plural forms or case-sensitivity.

JPBergsma commented 1 year ago

For this to be really useful, all the servers should support it. This would however make it a bit more complicated to implement an OPTIMADE server, and I think we should try to keep this a simple as possible. So I am not sure that we should add this to the OPTIMADE specification.

I do think it would be a nice addition for a client, though. Matthew has been working on creating an optimade client as part of the optimade-python-tools. Perhaps it could be added there.

merkys commented 1 year ago

I support @JPBergsma opinion that this should be a client-side feature. Translation of class names to lists of elements in queries should not be difficult.

blokhin commented 1 year ago

@JPBergsma @merkys OK, I agree with you. We will support this feature in our natural language parsing library for clients.