From: Syed A. R. <s9...@gm...> - 2014-01-20 13:49:53
|
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 |