Re: [Cdk-devel] Module Hierarchy - Help/Opinions Needed

[Syed A. R. <s9...@gm...>]

Your work on stereo was of great use to us. Keep it up!

-A


On 20 Jan 2014, at 13:47, John May <joh...@gm...> wrote:

> Yeah the IStereoElements do the stereochemistry representation. The CIP is just for labelling R/S E/Z which is useful when naming or editing in structure editor but isn’t good for computation (it can’t label everything).
> 
>> Signatures can certainly be converted back to atom containers,
>> although it is not the prettiest code:
> 
> 
> Cool - this is really hard to place then… it can be used to store structures, ask questions (do these two atoms have the same environment) and used to build models. 
> 
> I guess we need to think what is it most commonly used for?
> 
> Thanks,
> J
> 
> On 20 Jan 2014, at 13:34, gilleain torrance <gil...@gm...> wrote:
> 
>> Hi,
>> 
>> I guess CIP is a descriptor. I was thinking of chirality functionality
>> in general - but that is covered in core?
>> 
>> Yeah, you're right about control. If other packages come in, maybe it can move.
>> 
>> Certainly deprecate qm - unless the original author, or some other
>> contributor wants to take it on now? :)
>> 
>> Signatures can certainly be converted back to atom containers,
>> although it is not the prettiest code:
>> 
>> https://github.com/johnmay/cdk/blob/master/src/test/org/openscience/cdk/signature/MoleculeFromSignatureBuilderTest.java
>> 
>> See the 'reconstruct' method. Perhaps this should be a static method
>> in MolFromSigBuilder class.
>> 
>> gilleain
>> 
>> On 1/20/14, Nina Jeliazkova <jel...@gm...> wrote:
>>> John,
>>> 
>>> Great to see this CDK mavenizing effort.
>>> 
>>> One question - will all packages be available as maven modules, or only the
>>> "super modules" ?
>>> 
>>> Nina
>>> 
>>> 
>>> On 20 January 2014 15:11, John May <joh...@gm...> wrote:
>>> 
>>>> 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
>>>> 
>>>> displaying, 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:
>>>> 
>>>> *base*
>>>> annotation
>>>> atomtype
>>>> core
>>>> data
>>>> silent
>>>> datadebug
>>>> isomorphism
>>>> dict
>>>> interfaces
>>>> reaction
>>>> standard
>>>> valencycheck
>>>> *tool* - that manipulate intrinsic properties and asking questions about
>>>> structures
>>>> builder3d
>>>> builder3dtools
>>>> forcefield
>>>> formula
>>>> fragment
>>>> group
>>>> hash - aux property but used for testing identity rather than describing
>>>> something
>>>> pcore
>>>> sdg
>>>> smarts
>>>> smsd
>>>> structgen
>>>> tautomer
>>>> 
>>>> *descriptors* - that compute auxiliary attributes to be used for building
>>>> models and screening
>>>> fingerprint
>>>> ionpot - hmm.. there are already ion pot and charge qsar descriptors,
>>>> these are kind of intrinsic but kind of only used in the qsars..?
>>>> charges
>>>> cip
>>>> signature
>>>> qsar
>>>> qsaratomic
>>>> qsarbond
>>>> qsarcml
>>>> qsarionpot
>>>> qsarmolecular
>>>> qsarprotein
>>>> 
>>>> *storage*
>>>> io
>>>> ioformats
>>>> iordf
>>>> libiocml
>>>> libiomd
>>>> pdb
>>>> pdbcml
>>>> inchi
>>>> smiles
>>>> 
>>>> *display*
>>>> render
>>>> renderawt
>>>> renderbasic
>>>> renderextra
>>>> 
>>>> *deprecated* - old code that is not used in the library but is required
>>>> for backwards compatibility, only included in downstream projects when
>>>> needed
>>>> 
>>>> *miscellaneous*
>>>> control
>>>> extra
>>>> diff
>>>> log4j
>>>> qm
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> 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.
>>>> 
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Cdk-devel mailing list
>>>> Cdk...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>>>> 
>>>> 
>>> 
>> 
>> ------------------------------------------------------------------------------
>> 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. 
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Cdk-devel mailing list
>> Cdk...@li...
>> https://lists.sourceforge.net/lists/listinfo/cdk-devel
> 
> 
> ------------------------------------------------------------------------------
> 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. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Cdk-devel mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel