[octet-devel] Re: [QSAR-devel] QSAR compatibility layers

[Peter Murray-R. <pm...@ca...>]

At 22:06 26/05/2004 -0700, rich apodaca wrote:
>Hello All,
>
>Egon, I like your idea about an Octet-to-Octet converter. I liked it so 
>much I decided to try my hand at implementing it (or part of it at least).
>
>The idea is simple: I added a static method ("copyMolecule") to 
>MoleculeTools. It takes as a parameter a Molecule and a MoleculeBuilder. 
>It uses the Molecule as a template to provide instructions to the 
>MoleculeBuilder that result in a copy of the molecule being produced.
>
>I have committed my changes (and unit tests - contained in MoleculeTest) 
>to the Octet CVS.

Thanks - I haven't looked at this but your description makes sense. We 
clearly have to have translations and the more clearly this is encapsulated 
the safer it will be.

>
>Now, this is only part of the solution you were thinking about. The second 
>part needs to come from the "compatability layer." In particular, a 
>CDKMoleculeBuilder needs to be developed. It is a class that implements 
>the net.sourceforge.octet.molecule.MoleculeBuilder interface, and which 
>probably would have an additional method that could return a CDKMolecule 
>(say, "releaseCDKMolecule()"). With this class in place, one could then go:
>
>CDKMoleculeBuilder builder = ... ;
>Molecule molecule = ... ; // the molecule to be copied
>
>MoleculeKit.copyMolecule(molecule, builder);
>
>CDKMolecule cdkMolecule = builder.releaseCDKMolecule();
>
>// do something CDK-specific with cdkMolecule
>
>I imagine that there could be an analogous JOEMoleculeBuilder, 
>JUMBOMoleculeBuilder, etc.

This makes sense. The JUMBOMoleculeBuilder will essentially use DOM get/set 
to create a CMLDOM. Since the methods depend on the actual schema used it 
may be necessary to use reflection to ask whether a method exists. I 
haven't used reflection (I read about it many years ago) but basically I 
anticipate something like the pseudo code:

read octetMolecule info
create CMLMolecule
iterate through octetMolecule.properties
   if cmlMolecule.hasProperty(p)
     cmlMolecule.setProperty(p)

the reflection might be done in a generic cml.setProperty() - each class 
already has setAttribute(foo, bar) which are then rerouted to setFoo(bar) 
if they exist.

P.


>
>The nice thing about this solution is that the same code, namely the 
>MoleculeKit.copyMolecule() method, can be used to faithfully copy any 
>Molecule implementation to any other for which the MoleculeBuilder has 
>been written. Only one copy method need be written, tested, and debugged - 
>which I have done to a first approximation. Also, since only Octet 
>interfaces are involved, this places control of the process pretty much in 
>the hands of the compatability layer, rather than QSAR - which is where I 
>think it belongs.
>
>As an added benefit, this CDKMoleculeBuilder, once developed, could be 
>used seamlessly within the Octet IO package or with TestMolecules - 
>basically anywhere that a Molecule needs to be constructed.
>
>In summary, there are probably two key interfaces that a QSAR 
>compatability layer may need to implement for maximum utility: Molecule 
>and MoleculeBuilder. I am, of course, willing to help with writing any of 
>these that might be needed by QSAR-aware projects.
>
>cheers,
>rich
>
>
>"E.L. Willighagen" <eg...@sc...> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Wednesday 26 May 2004 07:16, rich apodaca wrote:
> > Peter, you raise an interesting point about simultaneously being able to
> > use functionality in multiple toolkits. I hadn't considered simultaneous
> > use of more than two toolkits.
> >
> > Because Java permits only multiple inheritance of interfaces, I can't
> > imagine that a three-way or four-way Adapter Pattern could be used - both
> > JOELib and CDK define model-level objects in terms of classes rather than
> > interfaces.
> >
> > Nevertheless, the two-way Adapter Pattern is just one way to try to 
> achieve
> > interoperability. And it may not be the best solution in every situation.
> >
> > Another approach to this problem is to develop a translator class that 
> will
> > use one toolkit's molecule as a template for building another toolkit's
> > molecule. I included a skeletal implementation of this concept in Octet's
> > CDKTools package (CDKKit).
>
>I've been thinking about this:
>
>a Octet2Octect convertor... i.e. a class that takes the input from a class
>implementing a certain octet interface, and stores it into a second (possibly
>different) implementation of that octet interface, obviously using this given
>interface...
>
>Then you only need one translater for each octect interface, no matter how
>many implementation there are... It also ensures that no information will be
>converted outside this interface.
>
>Egon
>
>- --
>eg...@sc...
>PhD on Molecular Representation in Chemometrics
>Nijmegen University
>http://www.cac.sci.kun.nl/people/egonw/
>GPG: 1024D/D6336BA6
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (SunOS)
>
>iD8DBQFAtE9zd9R8I9Yza6YRAv3zAJ948c5BaiuNIsrf/X2CAok5yDdTgQCfUvba
>CYKGD/HQdNSLaJWOl1tGmWc=
>=vw/p
>-----END PGP SIGNATURE-----
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com

Peter Murray-Rust
Unilever Centre for Molecular Informatics
Chemistry Department, Cambridge University
Lensfield Road, CAMBRIDGE, CB2 1EW, UK
Tel: +44-1223-763069