[Pdbwiki-devel] checking remediated pdbs

Dan Bolser dan.bolser at gmail.com
Thu Jul 16 05:21:08 EDT 2009


2009/7/16 Jose M. Duarte <jose.m.duarte at gmail.com>:
>>
>>
>> Jose, can you double check 1ifc (http://pdbwiki.org/index.php/1ifc) as
>> you originally raised this issue? From what I can tell, looking in
>> PDBase, the problem you raised looks to have been corrected in the
>> remediation. i.e.
>>
>> select * from pdbx_poly_seq_scheme where entry_key = 10107;
>
>
> It looks as though it is still as it was:
>
> SELECT id, label_alt_id, label_atom_id, label_comp_id, label_seq_id FROM
> pdbase.atom_site  WHERE entry_key=10107 AND label_asym_id='A' AND
> model_num=1;
>
> The label_alt_id field is the alt loc and there are still 2 of them (A and
> B) for all atoms. The latest mmCIF and PDB files also have the same alt
> locs. Of course this is not really an error but more a non-standard way of
> annotating things.
>
>
>>
>> The only 'format inconsistency' that I haven't checked yet is 1ifq.
>
> That one looks also still the same in the latest mmCIF file (the one model
> is tagged as 0).

OK, in this case it looks like 6 out of 6 'format inconsistencies' are
still problematic post remediation. If you agree, I'll send an email
to the PDB asking them to take a look at these reports.

In the meantime, it would be great if we could document a set of
'sanity check' queries somewhere. I think such a library of tests (and
a list of the corresponding failures) could be very informative. I
know Ioannis had a set of such queries, however, I wouldn't want to
bother him about this for a little while at least!


> By the way, not strictly related to this but important anyway. We have just
> discovered this week that in the latest remediated release of the PDB
> (February 2009) one of the tables of the mmCIF files is now gone:
> atom_sites_alt. The table used to contain foreign keys to all atoms with alt
> locs. That was actually redundant as the same info is also in the atom_site
> table.
>
> Anyway we used to read that table in our parsers and thanks to that we've
> discovered there was a problem. Hopefully there are no other major changes
> in the CIF format but let's bear in mind that this kind of things can happen
> (and that openMMS might become obsolete eventually...)

Yeah, this is a good point. At some point we should go over to the
supported 'DBLoader' or star parser modules to create the relational
version of the PDB. I'll have to look into details and come back with
a proposal.

Also, lets document the CIF format as we have been doing for the
OpenMMS database (as the latter is derived from the former). I really
think that such a nice summary of core 'tables' and fields would be
useful for the community.


Thanks for help Jose,

Dan.

> Jose
>
>
>




More information about the Pdbwiki-devel mailing list