Andrius Merkys

> However, I have two concerns regarding this change: > > 1. the cmake debian helper seems to cope ok with the existing install variables, I've in fact already packaged...

Thanks for the pointer @ashatch!

@kilinchange there seem to be ways to call Java from Python, see for example [this thread at Stack Overflow](https://stackoverflow.com/questions/476968/using-a-java-library-from-python).

Suggestion in #422 describes two places where this info can be added: `/info` endpoint (preferred then by @ml-evs) or `meta` of every response. I would also prefer `/info` to retain...

> Or do you think we should add a separate SMILES field instead? I would suggest so. `chemical_formula_descriptive` has its own purpose and semantics, and they should not change.

I support standardizing a separate property for SMILES. However, there are some issues related both to its definition and usability. 1. There is a bunch of competing SMILES specifications. I...

(For brevity, I am not citing and explicitly responding to @JPBergsma sentences with which I completely agree) > Ideally, we would also use the SMARTS extension, which is specifically focused...

> > > Ideally, we would also use the SMARTS extension, which is specifically focused on querying structures, although it is not included in the OpenSmiles standard. > > >...

Looking back at my [discussion checklist](https://github.com/Materials-Consortia/OPTIMADE/issues/368#issuecomment-945621632), I think we at least agree on using OpenSMILES. However, other issues still need more discussion. My suggestions to speed up the introduction of...

I agree that we can define SMILES as a regular OPTIMADE String with all string handling operations. Thus for the time being `"O" != "[OH2]"` is true as these strings...