[octet-devel] Re: [Cdk-devel] Common molecule interface

[rich a. <che...@ya...>]

Hello Joerg,
 
Thanks for looking over Octet. Your comments are very helpful, and I had a couple of questions:
 
What are the advantages of an Octet Atom inheriting from Node? The definition of the Atom interface is very short and contains mainly methods for identifying neighboring atoms and bonding systems. Octet doesn't use Bond, but rather BondingSystem, which allows for the connection of any number of Atoms using any number of electrons so that structures like ferrocene and transition metal complexes can be handled the same way as any purely organic molecule.
 
I thought about being able to store keys, properties, etc. in Atom, Molecule. However, since the design of Octet is based on the implementation of interfaces, doing so puts a burden on the implementor to provide this functionality. Marking atoms, bonding systems, and molecules could just as easily be done externally to those interfaces using a vector of visited atoms, for example. In fact, Octet uses this approach in, for example, the DepthFirstTraverser class. Is there something else I'm missing?
 
Do you consider AtomPair a "descriptor"? I noticed it is present in JOELib. Octet also has an AtomPair interface. However, in Octet, AtomPair simply represents an association between two atoms (no electrons involved - that happens through BondingSystem). To find all the atoms that are associated in a Molecule, use Molecule.iterateAtomPairs(). Your point about hashCode() is well-taken.
 
Your point about copy() clone() is also well-taken. However, this can't be forced through the interface definition but can be incorported into the reference implementations.
 
Can you give me an example of the readAsString() method and its advantages in handling corrupted file entries compared to just throwing an exception with the existing MoleculeReader methods? You're right about these methods needing to declare an exception.
 
I'm currently working on implementing some of the other features you asked about such as a descriptor framework, substructure/similarity searching. However, these features are independent of the interface definitions for the key model-level objects (Molecule, BondingSystem, and AtomPair). I've had a look at JOELib's descriptor framework, and it looks like a flexible way implement descriptor functionality.
 
Can you explain what a "descriptor IO helper class" is and why it is necessary?
 
cheers,
rich

"Joerg K. Wegner" <we...@in...> wrote:
Hi,

I've had a short look and i'm missing some things functionalities in octet:
- i would prefer Node and Edge objects as Atom and Bond base
- i would prefer a general NodeKey, EdgeKey, MoleculeKey, RingKey object 
as labelling the attributed molecular graph
both things are required for general graph algorithms, for the keys a 
factory pattern could/should be used, especially for assigning default 
labels.
This avoids calculating e.g. a ring search twice by using:
if(!mol.hasKey(myRingSearchKey))mol.calculateRingSearch()
- The AtomPair is ambigous, there exists a descriptor with an additional 
distance parameter, here you are using always one. Hashing is 
important here.
- Force Copy/Clone/Hash-methods.
- The reader should provide, readAsString, readToMoleculeObject, so we 
can catch corrupted file entries. Don't ask me why there are such a lot 
of corrupted entries, but they exists
- Add MoleculeIOException to read/write, to catch these corrupted 
entries, this will us enable to write skip files
- A general SubstructureSearch object would be fine, also a 
UniqueSubstructureSearch object or a transformer object.
- General descriptor objects are missing completely, but they can be 
handled by the hashed MoleculeKey objects, but eventually we distinguish 
between keys which can handle only one object (hashed) and keys which 
can handle multiple objects, so we need a GeneralPropertyHandler which 
accepts single and multiple entries by key.
- For descriptors IO helper classes are required, which have 
read(IOType) and write(IOType)

Kind regards, Joerg
-- 
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW: http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
(E. Hemingway)

Never mistake action for meaningful action.
(Hugo Kubinyi,2004)



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
Cdk-devel mailing list
Cdk...@li...
https://lists.sourceforge.net/lists/listinfo/cdk-devel
		
---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs