Thank you both for the feedback itís good to see what perhaps should and shouldnít go together.
I think the prediction module could be better described as qsar (with the renaming of the current qsar module) or else descriptors, since the module doesn't actually have code that makes predictions. In fact, I think it would even be OK if the descriptors were placed in the tools module
Yep that was the one i liked the least. With the qsars in tools thatís quite a large collection of disparate functionality. Actually as the descriptors could go in tools - maybe it makes more sense to have a descriptors modules that includes non-qsar descriptors (see below).
* tool - yes. Does 'cip' really not go in base? I think 'isomorphism'
should be, although I appreciate that it might be superseded by SMSD?
Talking of which, I agree with Rajarshi that SMSD belongs in tools.
There are several packages and classes in there that could usefully be
moved to other places.
Out of interest why would you put CIP in base? I would say itís a stereo-descriptor, thatís only useful for labelling absolute centres (not that useful). Also yes isomorphism should probably go in base and I've moved that.
* display - can't 'control' be in display? I know controlling is not
So yeah it is mainly used by JChemPaint and Bioclipse when displaying structures but Iím not sure it fits in with the renderers. Would need to think more about that - CDK-JChemPaint adds a lot of classes to the module that might make it clearer where it should live.
With regards to the 'qm' module, that looks like a
partially-implemented effort. The renderer seems like something for
rendering orbitals or something.
The qm.math stuff could be packaged with 'group' ? Perhaps a module
(not a super-module) called 'mathí.
Thatís a possibility - we can do merges once all is in place. I think it might be better just to deprecate the code though - leaving it still in place for people to use but indicating this isnít (and most likely wonít be) completed.
Oh, and for that matter -
shouldn't signatures be with inchi and smiles?
Are you able read signatures back as an AtomContainer? I would have thought these are more similar to hose codes that describe (i.e. descriptors) the environment of each atom?
Hereís an updated hierarchy with a 'descriptors' module. Not sure about ionpot and charges - ionpot is only used by qsarionpot and charges by qsarmolecular, ionpot and forcefield. Let me know how this feels:
tool - that manipulate intrinsic properties and asking questions about structures
hash - aux property but used for testing identity rather than describing something
descriptors - that compute auxiliary attributes to be used for building models and screening
ionpot - hmm.. there are already ion pot and charge qsar descriptors, these are kind of intrinsic but kind of only used in the qsars..?
deprecated - old code that is not used in the library but is required for backwards compatibility, only included in downstream projects when needed