Miguel, ah, right. That makes sense. You really aren't kidding about those BIG files. OK, so what these actually are are all the possible nonprotein structures that are in PDB files. Fascinating. No desire to conserve space here. Wow, a 13 Mb cif file. One thing I noticed at

http://pdb.rutgers.edu/mmcif/dictionaries/pdb-correspondence/pdb2mmcif.html

was the interesting statement at the atom_site.auth_atom_id:

Section _atom_site.group_pdb <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.group_pdb.html> Serial_No _atom_site.id <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.id.html> Atom_Name _atom_site.auth_atom_id <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.auth_atom_id.html> Alt_Loc _atom_site.auth_alt_id <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.auth_alt_id.html> Residue_Name _atom_site.auth_comp_id <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.auth_comp_id.html> Strand_ID _atom_site.auth_asym_id <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.auth_asym_id.html> Residue_No _atom_site.auth_seq_id <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.auth_seq_id.html> [1] Ins_Code _atom_site.pdbx_PDB_ins_code <http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Items/_atom_site.pdbx_PDB_ins_code.html>



[1] As recommended in the mmCIF definition _atom_site.auth_seq_id is the concatenation of the PDB residue number and insertion codes. The insertion code is maintained as separated local data item for convenience.


the link for atom_site.auth_atom_id reads:

             An alternative identifier for _atom_site.label_atom_id that
              may be provided by an author in order to match the identification
              used in the publication that describes the structure.


So this seems to me to allow for traditional PDB names in the mmCIF format. Am I reading that correctly?
For example:


http://pdb.rutgers.edu/mmcif/dictionaries/mmcif_pdbx.dic/Categories/atom_site.html

Have you looked closely at the following?

http://pdb.rutgers.edu/mmcif/CIFLIB/index.html
http://pdb.rutgers.edu/mmcif/PDB_EXTRACT/index.html
http://deposit.pdb.org/mmcif/PDB_EXTRACT/pdb_extract-manu-htm.htm

Are you looking more for something like this, from the source of PDB_EXTRACT?
If so, I hate to tell you, there doesn't appear to be an algorithm--just a dictionary....


CHANGE_ATOM_NAME IU_ALA = {
       3,
        { { "1HB",  "HB1"  },
          { "2HB",  "HB2"  },
          { "3HB",  "HB3"  }
        }
};

CHANGE_ATOM_NAME IU_ARG = {
      10,
        { { "1HB",  "HB2"  },
          { "2HB",  "HB3"  },
          { "1HG",  "HG2"  },
          { "2HG",  "HG3"  },
          { "1HD",  "HD2"  },
          { "2HD",  "HD3"  },
          { "1HH1", "HH11" },
          { "2HH1", "HH12" },
          { "1HH2", "HH21" },
          { "2HH2", "HH22" }
        }
};

CHANGE_ATOM_NAME IU_ASP = {
       2,
        { { "1HB",  "HB2"  },
          { "2HB",  "HB3"  }
        }
};

CHANGE_ATOM_NAME IU_ASN = {
       4,
        { { "1HB",  "HB2"  },
          { "2HB",  "HB3"  },
          { "1HD2", "HD21" },
          { "2HD2", "HD22" }
        }
};

CHANGE_ATOM_NAME IU_GLU = {
       4,
        { { "1HB",  "HB2"  },
          { "2HB",  "HB3"  },
          { "1HG",  "HG2"  },
          { "2HG",  "HG3"  }
        }
};

CHANGE_ATOM_NAME IU_GLN = {
       6,
        { { "1HB",  "HB2"  },
          { "2HB",  "HB3"  },
          { "1HG",  "HG2"  },
          { "2HG",  "HG3"  },
          { "1HE2", "HE21" },
          { "2HE2", "HE22" }
        }
};

But there is also in iupac_atom_name.c the function

void create_public_component_with_iupac_name(char *infile, char *outfile)

and more in _atom_change.c


This any help?

Bob

Miguel wrote:

Bob wrote:



> http://www.bmrb.wisc.edu/referenc/aa_chem.html

Second reference on this page:
http://www.bmrb.wisc.edu/ref_info/atom_nom.tbl
It seems to me that this is the sort of thing you are looking for?
Holy cow! That's quite a list.



It certainly is! But it is too much data for me ... I don't understand it.



Would you like, basically, to add a CIF or mmCIF column?



Well, that would help.



Or isn't this the right list?
(From which perhaps you could design an algorithm?)



Truth is, I don't want to design the algorithm ... I assume that someone else has already done it.

The people at the PDB have converted everythign to CIF ... what algorithm
did they use?



see the files in the pdb ftp area under directory
data/monomers/
components.cif (PDB names)
components_iupac.cif (mmcif iupac names)



Boy, these files look awfully big and ugly to me.



The above two look like a good bet. What exactly are you after, Miguel?
What are the desired inputs and outputs?



Assuming that CIF follows the IUPAC standard, I want someone to give me the implementation of:

String convertPdbNameToIupacName(String pdbAtomName) { ... }


The problem I am trying to solve is this: The RasMol/Chime expression language is very specific to .pdb files. Jmol now does a pretty good job of supporting .cif files. But the expression language does not work because of the */' confusion. Therefore (in the best of all possible worlds) I would like to have the Jmol internal representation be the IUPAC standard. Then, I would convert the expression language into IUPAC and we could do queries regardless of the source of the file.


Miguel



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers



--

-- Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr




------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to