Casper Welzel Andersen

> Since you already were on the idea of reporting JSON types, I think I would be OK with a specification of type per output format. In that case the...

> Thinking this through, no option seem particularly elegant. It feels odd to separate out type information into a separate top key, if everything else is grouped together by property....

On another note, the OPTIMADE data types does not take lists of unique elements into account (`set`s in Python - although `set`s in Python are different again, since they are...

> > > Furthermore, isn't the OpenAPI type representation also already present in the JSON schema for the output? > > > I don't think so. The OpenAPI type representation...

> @CasperWA Yes, there is no 'set' type in OPTIMADE, only lists. Any set can be represented as a list of the elements, so the need for this as a...

All right. So as a first suggestion for nested types, I have this example for three custom properties: - `_exmpl_list_prop`: list of list of floats or unknown values - `_exmpl_dict_prop`:...

> I like this approach. We don't have any mixed types in collections aside from unknown values, which are clearly described in the descriptions of fields that allow them. >...

For me, the original motivation and use case is your 4th stated use case above. Essentially, I have and am developing a client, which you can find here: https://dev-tools.materialscloud.org/optimadeclient/ In...

> I also understand that nested properties are allowed to be used but as far as I can know there is no way to describe them in `info/structures` endpoint. I...

Cheers @fekad. And I appreciate you continuing the discussion in this issue as well (instead of the PR). I'd like to see if we can keep the PR clear and...