1. scientifically: I agree completely
2. technically: I am fighting since years against different coding standards
in our packages. And this is the same problem all the time. We have too much
hard coded expert systems. I think there is no doubt that we need this for
speed, but on the other hand this is bad for prototyping and high quality
What we really need are external text or better xml based rules and
primitive algorithms, which are fast and robust. Then the only thing we must
exchange are XML based definitions.
The highest standard at the moment for query matching is SMARTS at the
moment so I suggest to use that, on the other hand ... I do not like the
silly querying restrictions. We rather should use the MQL
Ewgenij Proschak is the contact person for that
Why? Because an extended MQL will us also allow to create 3D queries, which
can then be also used to assign atom types! And the underlying BNF is the
best thing we can do, and I have contributed some ideas here, so at least I
am satisfied with some parts;-)
> >I'm having a devil of a time with hydrogens, and it all seems to
> >boil down to the lack of documentation in the original OpenBabel
> >code. It appears that the notions of "implicit hydrogens" and
> >"implicit valence" aren't documented, and it seems to be used to
> >mean different things depending on who was writing code, where the
> >molecule came from, and where it's going.
> I'm not surprised and I'm sympathetic. It's non just Open Babel -
> it's the whole of the chemical community who for decades have omitted
> hydrogens because "it's obvious where they are".
> A typical example of the problems is Pubchem CID 945 "nitric oxide"
> whose formula is HNO - presumably some "smart" program decided to add an
> As I have suggested earlier I think this is something that the Blue
> Obelisk community should agree on - use the same rules over all their
> programs and make these explicit - what atoms can have "smart" H
> addition and when. Then we point the rest of the world to our ruleset.