At 13:20 08/06/2004 +0200, Miguel wrote:
>> > Jmol would have recognized the element type if the PDB had bothered to >> > follow their own file format specification of 1996 and had filled in >> > columns 77-78 with the element symbol. > > This was a later addition - not in the original format.
But the *updated* specification is dated October 25, 1996. I would think that > 7.5 years would be long enough for them to act on it.
Without knowing I suspect this was part of the backlog before the addition. Part of what I was involved in was seeing whether the conversion could be automated.
>> > [/complain] >> > >> > If you feel that it is truly justified, I could try mapping ?C, ?N and >> ?O >> > to carbon, nitrogen, and oxygen. >> > >> > However, we will be unable to map AC because: >> > >> > AC = Ac = actinium >> > >> > Do you have any recommendations as to how we can address this problem? > > Please do not do this!
I will not demote actinium to a second class citizen.
But, from my perspective, I am already doing crazy mapping in order to turn CA into alpha carbon.
So long as the ***column*** is correct in a PDB file there isn't a problem. There are exactly 2 fields for the atom symbol
| C|A is carbon
|CA| is calcium
But I suspect your problem is that in the scripting language there are no columns and so CA and CA look pretty similar :-(. In CML I allow for this by having non-space delimiters in arrays, e.g.
<array dictRef="foo:pdbatom" delimiter="/">/ CA/CA/ NB/NB /</array>
which preserves this. If your users wish to use Calcium and Calpha you will need a clear convention
> I recommend that you do not make extensions for invalid PDB files.
I agree completely. I have absolutely no interest in doing hacks for invalid PDB files.
As a newcomer on the scene, it is clear to me that the PDB has brought most of these problems on themselves by not enforcing the file format and by continuing to publish files that do not meet their own format specification.
Be gentle... It was a pioneering effort in the early 1970's when scientific databases were very rare. It wasn't even intended that machines would read all this info - the primary motivation was bibliographic to start with.
What is not clear to me is whether or not this is an invalid entry. I do not have enough experience to judge. Perhaps the PDB considers this valid (since they really only care about biomolecules).
Q: Is it clear that this entry is invalid?
I think if it comes from PDB it represents "best endeavour with limited resources"
> I spent > 2 weeks in Brookhaven (the previous home of the PDB) about 8 years ago > looking at this problem. Their own format had varied enough over the years > that it was a major problem to reconcile all *their* files. Add to this > the > many creative deviations for other "PDB" files and it is a nightmare.
Understood.
> IMO you should implement the current specification to whatever extent you > have energy for and report deviations from this with warnings or errors.
I will continue to report them.
And, I fear, they will continue to reply to my data-quality bug reports by saying "No Plan To Fix".
The PDB is fully aware of the problem. In fact the protein community has put a lot of effort into cleaning up protein structure files. So I wouldn't spend time reporting.
I guess the likely response would be "we are migrating to mmCIF which should remove many of these problems"
> XML took precisely this approach. If it doesn't obey the spec it's broken. > So an XML parser can be as little as 20K (AElfred) while HTML parsers can > be huge because they have to cope with broken legacy
Agreed.
P.
Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069
------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
