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 moduleYep 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 notdisplaying, but..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:baseannotationatomtypecoredatasilentdatadebugisomorphismdictinterfacesreactionstandardvalencychecktool - that manipulate intrinsic properties and asking questions about structuresbuilder3dbuilder3dtoolsforcefieldformulafragmentgrouphash - aux property but used for testing identity rather than describing somethingpcoresdgsmartssmsdstructgentautomer
descriptors - that compute auxiliary attributes to be used for building models and screeningfingerprintionpot - hmm.. there are already ion pot and charge qsar descriptors, these are kind of intrinsic but kind of only used in the qsars..?chargescipsignatureqsarqsaratomicqsarbondqsarcmlqsarionpotqsarmolecularqsarprotein
deprecated - old code that is not used in the library but is required for backwards compatibility, only included in downstream projects when neededmiscellaneouscontrolextradifflog4jqm
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
Cdk-devel mailing list