Think of IMP as a product. Think of future IMP users as a customer. Any successful development should be always focused on the customer. I know that in this case the end user would be a biologist, a physicist, a chemist, an engineer, etc. (very broad). However, you should try to adopt/use a logic that is familiar to the user, depending on the problem that is being attacked. Certainly, the case of proteins will be the more difficult to define clearly (biology is full of exceptions).
You should sit and discuss ideas, as Javier suggested. I know you have a great team down there, and of course, you will end up with a great application !
Cheers,
Pancho.
On Oct 9, 2009, at 1:11 AM, Javier Ángel Velázquez Muriel wrote:
On Oct 8, 2009, at 9:21 PM, Dina Schneidman wrote:
completely agree. these are resolved much faster by talking :)
I'm not entirely sure I agree (witness the last developers meeting :-). But am ambivalent. It could be structured better though which would help things converge faster.
IMP meetings, and each meeting in general tend to be focused explaining or convincing others from things already done rather than discussing future development or listening to others. Ideas are rarely discussed.
That said, we have several outstanding questions: - do we have PROTEINs which can contain CHAINs or just PROTEINS (which are chains). This we should probably just find something authorative and use it. I don't much care either way.
Or easier, agree on something. But agree everybody.
- what are the most useful things for one or more read_pdb functions to return? For this we should come up with standard usage cases. I would propose a couple here:
- someone is running through lots of PDB files and wants to load one protein from each file. To do this, it would be nice to have a function which loads a protein from the pdb and returns a hierarchy containing only that protein. Whether this protein has one or more chains depends on the answer to the first question - load the whole structure from a pdb complete with many proteins and ligands and other molecules. For this it is useful to be able to read everything from one PDB model record. - take one piece of the pdb and use it (such as a chain or ligand). For this it is nice not to have to dissect a hierarchy. - load a bunch of model records from a single pdb and deal with all the molecules in each record.
Everybody agrees on that, a I would bet that everybody agree on 4 levels for the hierarchy. The things that need to be clarified is what we get after doing each of the tasks proposed, and how we call them to obtain a result the least obscure possible.
Any other cases? Think about it and we will discuss it on Tuesday.
A proposal to think which handles the above cases is: - one function which reads a protein from a pdb - one function which reads everything from one model record in a pdb and returns it in a list/vector