Here is an idea that has a larger scope than just Coot, but might be of interest.
In the PDB format definition (and I'm sure there is the equivalent mmCIF tag) there is the HETNAM statement. In this statement you match a 3 letter code to a code with an open-ended length. If one defined their data block in the restraint cif using the longer name and included the proper HETNAM statement in each coordinate file Coot could look up the proper cif every time despite all inhibitors being named INH in each PDB. To handle the current practice of not having HETNAM statements Coot should default to looking for data blocks using the three letter code when there is no HETNAM statement. To handle downloaded PDB's that have HETNAM's created by the wwPDB I would suggest first a look up for cifs with the long name, and if that fails attempt the three letter code. The translation could be different for each PDB loaded into Coot. With this scheme people working with compounds from large libraries could keep a set of cifs with data blocks named with the actual library names of the compounds, but each PDB file could have INH with a HETNAM that translates. Dale Tronrud On 01/24/12 14:12, Sheriff, Steven wrote: > All: > > > > At BMS, we use the same ligand identifier, e.g. LG1, for all compounds > that bind at overlapping sites. If we have multiple compounds bound in a > single structure, i.e. non-overlapping sites, then we would use LG2, > etc. for them. Using a common naming system makes it easy for upstream > and downstream programs and users to know what to look for. So, if I > want to compare two proprietary structures in COOT pre-0.7, then > something along the lines that Paul suggests is the easiest way to deal > with this. Otherwise I have to modify both the PDB file and relevant > CIF restraint file. Someday some of these structures do end up in the > wwPDB and they do a good job of disambiguating them and assigning unique > 3-character identifiers (BTW, the PDB as far as I know is still using > only capital letters, so this translates into only 36**3 (46656) unique > 3-character names of which >8000 have been assigned as of the last time > I paid attention). > > > > And, yes, companies do have unique “names” for their compounds. At BMS, > they consist of 9 characters, but I have seen other companies naming > schemes use 11 characters. Neither of which is easily translated into 3 > characters. > > > > Steven > > > > *From:* Mailing list for users of COOT Crystallographic Software > [mailto:[email protected]] *On Behalf Of *Seth Harris > *Sent:* Tuesday, January 24, 2012 4:53 PM > *To:* [email protected] > *Subject:* Re: New restraints, same name > > > > Hi all, > > Working in industry, we do end up with conventions that just give a > generic name to whatever small molecule happens to be in that structure, > typically LIG or DRG or XXX, e.g.. Makes it easy to navigate solved > structures en masse without having to figure out what arbitrary name it > has in structure X vs Y vs Z and the benefits of the convention outweigh > the potential drawbacks, so far. Generally I don't find conflict between > different structures because at that stage I'm done with refinement and > the viewer programs don't care about the restraint dictionaries. I'm > assuming coot can still draw the atoms based on coordinates and only > creates the tangles if you try to refine those with the restraints, yes?? > So then the issue of multiple small molecules in one structure, > Carsten's point is spot on for me as well, where there's no point in > having a coot-specific solution since the other refinement packages are > going to choke as soon as you have two different ligands sharing the > residue name so you might as well fix it on the pdb side. I think Paul's > original question was really around the issue of loading two separate > structures which have a common residue name identifier despite being > different chemical entities. I guess I am wondering more and more about > the opening statement of "Now that Coot uses the restraints dictionary > to render ligands..." as i have not kept up with the > latest...Nonetheless for my particular workflow I have scripts that > launch an instance of Coot with a given structure and maps and it is > rare that I bring in a second one. If I did, and Coot is going to not > display the ligand correctly because its name is already taken then true > it would be handy if Coot could sort this out and keep the separate > restraints definitions appropriately sorted by molecule number of some > internal identifier. If the molecules look fine and it's only when one > attempts real space refinement or such that it would get scrambled > (current behavior in my admittedly-not-the-most-recent version of Coot, > 0.6.1) then I wouldn't bother as that situation is rare for me (and I > imagine for others(?)) and I agree with the votes that the fix should be > on the user to sort out. Perhaps Paul you can clarify if we're talking > even simple display is affected or just refinement operations as past? > > On a side note, during yesterday's run by the bay here I passed a > grazing flock or two of what must surely have been coots given their > striking resemblance to the splash screen icon. Watching my step, I can > attest that there is certainly quite a mess in their internals, but I > imagine Paul's coot is better kept...! > > Cheers, > Seth > > On Tue, Jan 24, 2012 at 12:46 PM, Ed Pozharski <[email protected] > <mailto:[email protected]>> wrote: > > On Tue, 2012-01-24 at 15:26 -0500, Kendall Nettles wrote: >> That didn't come out right. What I meant to say was that he are often >> comparing structures from a series of closely related compounds. > > But isn't it true that non-identical compounds should have different > names? Paul also refers to refinement (i.e. when dictionary is needed), > not comparison (the latter should be fine with identical names). > > Cheers, > > Ed. > > -- > Oh, suddenly throwing a giraffe into a volcano to make water is crazy? > Julian, King of Lemurs > > > > > ------------------------------------------------------------------------ > This message (including any attachments) may contain confidential, > proprietary, privileged and/or private information. The information is > intended to be for the use of the individual or entity designated above. > If you are not the intended recipient of this message, please notify the > sender immediately, and delete the message and any attachments. Any > disclosure, reproduction, distribution or other use of this message or > any attachments by an individual or entity other than the intended > recipient is prohibited.
