*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
... and if I use mmCIF format for input to Refmac will I get an mmCIF formatted output file? If not then obviously important information will be lost. Doc just says "XYZOUT: Current format is PDB." -- Ian > -----Original Message----- > From: Eleanor Dodson [mailto:[EMAIL PROTECTED] > Sent: Friday, August 11, 2006 12:13 PM > To: Ian Tickle > Cc: Miguel Ortiz Lombardia; [EMAIL PROTECTED]; CCP4bb > Subject: Re: [ccp4bb]: gap links > > Obviously we all should accept using the mmCIF format for > coordinates. > That assigns > a residue NAME which can be 1 2 3 7 6 8 8A etc etc" and > a residue NUMBER which will be 1 2 3 4 5 6 etc for sequential > residues.. > > This discussion demonstrates the inadequacy of the PDB 80 char record > Eleanor > > > > Ian Tickle wrote: > > >*** For details on how to be removed from this list visit the *** > >*** CCP4 home page http://www.ccp4.ac.uk *** > > > > > > > >I come down strongly on Bernhard's side here, and have to > disagree equally strongly with Miguel. This is an issue I've > tried to take up on the CootBB (sadly so far with limited > success!). There will always be conflicts between the > 'natural' scientists (i.e. physicists, chemists, biologists > etc) and the computer scientists over what is feasible in > software, but it seems to me that a fundamental principle > should be that in the first instance the natural scientist > dictates his/her requirements to the computer scientist, not > the other way around! The natural scientist is the > 'customer' and the computer scientist is the 'service > provider' and we all know that the customer is always right > (even when he's wrong!). Too many times the programmer > produces software 'features' (or bugs depending on how you > look at it!) that are convenient from the programming point > of view but are not what the scientist actually wants. Now > clearly there will be situations where the scientist is ask! > > ing for something that's just totally unfeasible in > software, and then there will have to be some negotiation, > but it still behoves the programmer to accommodate the > scientist's wishes as far as is practical. > > > >It seems to me that 'biological' (i.e. essentially > arbitrary) residue numbering most definitely falls way short > of the class of unreasonable requests. The biologist > essentially wants the residue 'number' (actually a name if > you include the chain ID and insertion code) to be merely a > label, nothing more, obviously firstly to identify the > residue on the graphics, but also to relate it to the > corresponding residue in homologous structures. Therefore > the programmer must not infer anything concerning the > sequence (such as the residue connectivity) purely from the > labels! It seems to me completely crazy that the biologist > has to relabel his meaningfully labelled sequence just to > make life comfortable for the programmer - and to maintain > different sets of numbers for different purposes! If the > biologist really wants to label his/her contiguous sequence > '12345 -15X 5 6 -99W ...' then so be it (anything > becomes possible if the numbers are treated purely as > labels). It's the! > > programmer's job to accommodate that in software, it's not > his place to question the wisdom of the biologist. > > > >In the majority of structures each unique chain identified > by the chain ID is contiguous, so that obviously has to be > the default presumption, regardless of the labelling. Since > we are assuming that the residue labels provide absolutely no > information concerning the connectivity, and given the > current limitations of the PDB format, I think the programmer > is entitled to require that the ordering of residues in the > file is the same as that in the sequence (otherwise you would > need an additional column to specify the ordinal numbers of > the residues). Then there has to be a way of telling the > software where the breaks in the sequence are. In most cases > this will be obvious (e.g. the C-N distance is 10 Ang). In > the few cases that the program is unable to infer a break > from the distance, the user clearly would be expected to > provide that information. In the RESTRAIN program I required > that each chain break is flagged by a TER record, though > strictly that is only used to flag ! > > end-of-chain (AFAIK other software ignores the TER record). > It seems to be that fixing this on-going problem is not > beyond the bounds of what we can reasonably expect from the software. > > > >Cheers > > > >-- Ian > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >>Behalf Of Miguel Ortiz Lombardia > >>Sent: Thursday, August 10, 2006 8:01 AM > >>To: [EMAIL PROTECTED] > >>Cc: 'CCP4bb' > >>Subject: Re: [ccp4bb]: gap links > >> > >>*** For details on how to be removed from this list visit the *** > >>*** CCP4 home page http://www.ccp4.ac.uk *** > >> > >> > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >> > >> > >>>>refmac5 must be assuming that you number your protein > >>>> > >>>> > >>according to your > >> > >> > >>>protein sequence, which is continuous. In my opinion, this > >>> > >>> > >>is reasonable. > >> > >> > >>>Uhhh... this assumption turns perilious quickly, because there > >>>are post-translational mods and splicing (see Concanavalin), > >>>and biologists sometimes prefer keeping the > >>>key residues in related structures (trypsin, fabs, etc) at > >>>a certain residue number. This causes > >>>sequence insertions (addressed correctly, as you say) > >>>and gaps (not addressed correctly, my situation.) > >>> > >>> > >>> > >>Sure, but after any modification whatsoever the sequence of > the final > >>protein is, except for perhaps a few pathological cases, continuous. > >>Now, I can understand, though not always agree, that > biologists (I am > >>one) prefer to give a consistent number to a particular residue in a > >>family of proteins, but for a refinement program I still think it is > >>reasonable to consider the numbering as continuous by default: this > >>would be the most usual situation, I would say. > >> > >>In any case, knowing that you can fix the problem using > TRANS (perhaps > >>even CIS if the thing is really bizarre) is very useful, thanks! > >> > >> > >>Miguel > >>- -- > >>Miguel Ortiz Lombardía > >>Centro de Investigaciones Oncológicas > >>C/ Melchor Fernández Almagro, 3 > >>28029 Madrid, Spain > >>Tel. +34 912 246 900 > >>Fax. +34 912 246 976 > >>email: [EMAIL PROTECTED] > >>www: http://www.ysbl.york.ac.uk/~mol/ > >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>~~~~~~~~~ > >>Je suis de la mauvaise herbe, > >>Braves gens, braves gens, > >>Je pousse en liberté > >>Dans les jardins mal fréquentés! > >> > >>Georges Brassens > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.1 (GNU/Linux) > >> > >>iD8DBQFE2tmRF6oOrDvhbQIRAoW9AJoCpyWRpC+R6XGzn6IGxniwwRK2UgCgoyDe > >>RRece2CHvTn8P22eekYjbZc= > >>=61Z2 > >>-----END PGP SIGNATURE----- > >> > >> > >> > >> > > > >Disclaimer > > > >This communication is confidential and may contain > privileged information intended solely for the named > addressee(s). It may not be used or disclosed except for the > purpose for which it has been sent. If you are not the > intended recipient you must not review, use, disclose, copy, > distribute or take any action in reliance upon it. If you > have received this communication in error, please notify > Astex Therapeutics Ltd by emailing > [EMAIL PROTECTED] and destroy all copies of the > message and any attached documents. > > > > > > > >Astex Therapeutics Ltd monitors, controls and protects all > its messaging traffic in compliance with its corporate email > policy. The Company accepts no liability or responsibility > for any onward transmission or use of emails and attachments > having left the Astex Therapeutics domain. Unless expressly > stated, opinions in this message are those of the individual > sender and not of Astex Therapeutics Ltd. The recipient > should check this email and any attachments for the presence > of computer viruses. Astex Therapeutics Ltd accepts no > liability for damage caused by any virus transmitted by this > email. E-mail is susceptible to data corruption, > interception, unauthorized amendment, and tampering, Astex > Therapeutics Ltd only send and receive e-mails on the basis > that the Company is not liable for any such alteration or any > consequences thereof. > > > > > > > > > > > > > > > > Disclaimer This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing [EMAIL PROTECTED] and destroy all copies of the message and any attached documents. Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof.
