Menu
▾
▴
[Joelib-devel] RE: [QSAR-devel] Data storage API summary -> net.sf.qsar.api.data package
|
From: <gra...@sy...> - 2004-05-06 13:29:32
|
Folks, just in case it's worthwhile, crystallographers, for example the CCDC ( http://www.ccdc.cam.ac.uk/products/csd/ <http://www.ccdc.cam.ac.uk/products/csd/> ) have had to worry about how to handle complex "bonding" representations programmatically. See if they can add anything to your understanding of not just the range of problems but the possible solutions. For example, the now pretty ancient 'FCON' file format http://www.ccdc.cam.ac.uk/support/documentation/quest/volume3/z317.html <http://www.ccdc.cam.ac.uk/support/documentation/quest/volume3/z317.html> covers the representation of a variety of atom and bond properties. (The more object-oriented among you may wish to wash your hands after reading the (FORTRAN) format statements ;-) Also related is the CIF (Crystallographic Information File) format, see http://www.iucr.org/iucr-top/cif/home.html <http://www.iucr.org/iucr-top/cif/home.html> regards, Graham Graham Mullier Chemoinformatics Team Leader, Chemistry Design Group, Syngenta, Bracknell, RG42 6EY, UK. direct line: +44 (0) 1344 414163 -----Original Message----- From: rich apodaca [mailto:che...@ya...] Sent: 05 May 2004 19:46 To: joe...@li...; qsa...@li... Subject: Re: [QSAR-devel] Data storage API summary -> net.sf.qsar.api.data package Hello All, Joerg, I appreciate your concerns regarding the implementation of Octet model-level interfaces by JOELib clients, and now I have a much clearer idea of why you think it's a good idea to first solve that problem before moving on to implement qsar functionality. I now agree with your postition on this. I also think I understand how you'll be developing and why you need developer access to Octet. So within a day or so, I'll add you as a developer. If you think it would be helpful, I'd be interested in working with you (and any others...?) to implement the Octet interfaces with JOELib classes. As I posted on the cdk-devel list, I believe the main challenge will be in reconciling Octet's bonding model with those of CDK and JOELib, but I think the problem can be solved. Interestingly, this issue goes beyind CDK or JOELib, and arises from fundamentally different views of how bonding should be modeled computationally. cheers, rich "Joerg K. Wegner" <we...@in...> wrote: Hi, > I don't want to spend time getting things to compile that I do not > need to use... So are we here doing things we like, or things we need ? But, what if i need them, that's the point. A Octet-CDK interface will work and from the actual design there are no problems, but i promise that a Octet-JOELib interface will cause problems, also as already the CDK-JOELib interface, because we have, as expected, different opinions about our requirements, because we have started from different design criterias. So kick JOELib and you can proceed as you like, if you want to use it, i prefer eventually (not sure at all) Octet interface changes, and this causes that you must change the actual Octet-CDK interface definition. If you will not complain about this, i'm fine with your approach, i would prefer to be a direct Octet deve! loper to try to reduce complications for Octet, CDK, Jumbo and JOELib, because i think this is much more elegant and more efficient than resolving every personal preferred complications. > I thought that that was what we were working on... a common API??? I don't think we know already what we want and need in common. Everyone prefers his already available well-know object structure, that's clear. And we have different opinions, of how we like to proceed. Let's stop this discussion here, and continue in two weeks. Again, Rick, i would like to be a Octet developer and would like to check in the Octet-JOELib interface implementations directly to octet or in a new CVS directory at the Octet project. So i can start with implementing and filling the stubs and change things i will need directly. Then we can discuss things for these implementations, before they are taken to Octet and dicuss on the mailing list, how to proceed and iterate our consens on the actual interface. Or we can use the tracking system with upload ability. > I think that MDL was interested in posting their substructure set > which is used to calculate their fingerprint... that could be used as > a standard. Fine, and: The expert systems are the main critical step in my opinion. I've also heard people saying, 'who is intersted in slight differences?'. At least from the scientific standpoint i disagree heavily on such comments. So what expresses [a;$(#6:#6-N)] if we use another expert system ? Surely not a random match, but eventually not what we've expected. 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Qsar-devel mailing list Qsa...@li... https://lists.sourceforge.net/lists/listinfo/qsar-devel _____ Do you Yahoo!? Win <http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/hotjobs_mail_signature_ footer_textlink/evt=23983/*http://hotjobs.sweepstakes.yahoo.com/careermakeov er> a $20,000 Career Makeover at Yahoo! HotJobs |
