And as a footnote* ----------------------------------------------------------------------------------------------------------------------------------------------------------------- * I notice that, following discussion on this bulletin board, the space group of the 2wlv coordinate file has been updated.
But at this point did it not occur to the PDB to change the space group in the structure factor file as well? So the coordinates indicate P21 21 2 but the structure factor file still says P21 21 21... Hmm.... consistency is highly over-rated... Also the author's SF data listing starts with c axis reflections including 0, 0, l odd as well as even, which is sort of a hint here.... ________________________________ From: MARTYN SYMMONS <martainn_oshioma...@btinternet.com> To: CCP4BB@JISCMAIL.AC.UK Sent: Tuesday, 16 April 2013, 14:30 Subject: Re: [ccp4bb] Puzzling Structure Just as a postscript. It has been pointed out to me that the space group was correct in the uploaded PDB and in the mtz reflection file. And there was no editing of this data pre-deposition. I am sort of surprised how quickly people are to beat up on the authors in such cases since we do not have access to the full data and facts. Having the uploaded data available would allow better checking. I'm mainly ignorant of the details, but isn't this the way sequence data is dealt with? - there are the unannotated sequence files which are gradually checked and assimilated (but not over-written). Cheers Martyn ________________________________ From: Michel Fodje <michel.fo...@lightsource.ca> To: CCP4BB@JISCMAIL.AC.UK Sent: Monday, 15 April 2013, 17:19 Subject: Re: [ccp4bb] Puzzling Structure Just to round up this topic, a bug report was submitted to PDBe concerning entry 2wlv and the PDB has how responded acknowledging the problem. An updated entry will be available in one week. As pointed out by Savvas, it is very likely the CRYST1 record was manually edited prior to deposition resulting in the wrong spacegroup being parsed in by AutoDep and subsequent processing moving the waters around in the wrong space group. Since there is no logical reason for the authors to do this, it was probably inadvertent. I imagine somebody accidentally deleted a space between P 21 21 2 and 18 and tried to fix it by adding it back, between 1 and 8. /Michel >-----Original Message----- >From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of >Edward A. Berry >Sent: April-14-13 9:59 AM >To: CCP4BB@JISCMAIL.AC.UK >Subject: Re: [ccp4bb] Puzzling Structure > >Robbie Joosten wrote: >> Hi Martyn, >> >>> I think the question is where the error was made - seeing the >>> uploaded file would clear this up. But it seems unlikely to me that >>> the depositor saw a huge R factor discrepancy at the end of refinement >and just blithely uploaded it. >>> So scenario 3 :- >>> PDB : we cannot reproduce your R factor with our programs Depositor : >>> that's your problem mate - it was fine when it left me...up to you to sort >it... >>> Which seems a sort of reasonable attitude to me. > >> Not quite, the depositor has to give, i.e. type, the space group (example >depositions: https://www.ebi.ac.uk/pdbe- >xdep/autodep/AutoDep?param=QovCsvhNv06Mpnr%2BvIkqqfuqeeBd8leFN >AVymZgS%2Fe7mULyfrCaTMN8jsyaGZUTyUDQyN3gMF3o%3D). Don't ask me >why, because it is clearly a source of error. >> > >In my experience with RCSB autodep2, assuming the information was in the >uploaded pdb file, this information is already pre-filled and the depositor >just >glances over to see it is correct. A missing or extra "(1)" might not be >noticed. >So perhaps it is a parsing error, perhaps related to the different ways the >space group is represented on the CRYST1 card, and the different stringency >of different programs in interpreting the CRYST1 card. > >But the validation report is included with the approval request letter, and >major discrepancies are noted in the text of the validation letter in case the >depositor is too busy to actually read the validation report. >So if the depositor read more than the first line or two of the letter he should >have known there was a problem. > >Then there is the 2-week default release policy: > > "No major issues were raised during data processing. A summary of some of >the key annotations > in your entry is shown below. Please verify that these are correct. If we do >not hear from > you within two weeks, we will consider this entry to have been approved by >you. The entry > will then be released according to the release/hold instructions you have >provided." > >If this 2-week default release is the rule even when there are issues, the >depositor may have put it aside to find the problem when time was available, >and waited too long and let the default release kick in. > >eab
