[Joelib-devel] Cheminformatics meta project

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

Hello All,
 
I almost don't want to bring this up because the discussion around the QSAR project is pretty involved as it is. But I can't resist...
 
Egon, your comment about QSAR being a "meta project" hit home with me in a big way.
 
The thought occurs:
 
Are we (QSAR, CDK, JOELib, Octet, Jumbo) trying to do too much at the same time?
 
Here's my impression of the line of discussion that led to where we are now (which I believe is a good place, by the way):
 
(1) Wouldn't it useful to have an open-source project devoted exclusively to QSAR with open implementations based on existing projects, a GUI, and which makes use of open-source data mining tools (such as weka)?
 
(2) Yes it would.
 
(3) Wouldn't it be even more useful if project we're planning interacted with a single "standard" Java API for accessing and manipulating Molecular information?
 
(4) Yes it would, but such a thing doesn't exist! How can we ensure that the new API will be general enough, robust, and useful? How can we meet this objective AND minimize refactorings of existing cheminformatics projects to accomodate this new API?
 
This is where we are now, in my view. The problem is, just tackling point (4) will be a very big job in itself.
 
My point is this: would it be useful to tackle the problem of developing a single standard Molecular API separately from the development of a QSAR framework?
 
Would it be even more helpful to devote a separate project toward cheminformatics standardization and/or integration in general? This project could start off by trying address our point (4), but could easily expand to deal with any number of standardization/integration issues currently plaguing cheminformatics research. The focus of the project needn't be Java-centric either, although it would probably start out that way.
 
As a model for such an effort, how about the Apache Jakarta project (http://jakarta.apache.org/)? This project nicely ties together a lot of technologies and serves as an essential resource for experienced developers and newcomers alike. More importantly, experiences in one project often lead to new projects that address novel problems.
 
Any thoughts?
 
cheers,
rich
 

Egon Willighagen <eg...@sc...> wrote:
The interfaces and the wrappers can be in Octet, but personally I prefer to do 
this is the common, implementation neutral, QSAR project... The compile 
scheme is identical, the only difference is where people get added as 
developer. I prefer this setup, because it more clearly shows that the QSAR 
part is sort of meta project which tries to connect available OS tools for 
QSAR research. Please comment.

		
---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs