Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What definition of float does DDLm follow (CIF1.1 vs mmCIF)? #384

Open
vaitkus opened this issue May 8, 2023 · 1 comment
Open

What definition of float does DDLm follow (CIF1.1 vs mmCIF)? #384

vaitkus opened this issue May 8, 2023 · 1 comment
Labels

Comments

@vaitkus
Copy link
Collaborator

vaitkus commented May 8, 2023

One of the goals of DDLm is to serve as a common format for small-molecule and protein crystallography. This is reflected by the fact, that DDLm versions of the dictionary contains data names from both worlds, often as aliases of the same concept (i.e. _atom_site.B_iso_or_equiv). However, I recently noticed that the float format defined by the mmCIF dictionary [1] and the one specified by the CIF1.1 grammar [2] are not compatible.

Besides some small differences (e.g. CIF1.1 allowing a leading '+' sign), the main difference is the order in which the exponent and the standard uncertainty parts appear, that is:

  • CIF 1.1: <numb><exp><su>
  • mmCIF: <numb><su><exp>

Up to now, I operated under the compliance to CIF1.1 when dealing with CIF files. Are there any guidelines on which format should be selected?

Alternatively, maybe it would be worthwhile to contact the mmCIF dictionary maintainers and ask them to change the float format so it more resembles the CIF1.1 one? The change might be feasible given that mmCIF files normally record standard uncertainties using separate data items rather than the parenthesis notation.

[1] https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Data/index.html, float
[2] https://www.iucr.org/resources/cif/spec/version1.1/cifsyntax, <Float>

@jamesrhester
Copy link
Contributor

Yes, fortunately mmCIF standard style is to use a separate su data name everywhere, so this problem is hopefully easy to solve. We don't currently have a wwPDB representative on COMCIFS so I will need to sort that out first. Meanwhile, the CIF1.1 format should be preferred simply because that is the form you are overwhelmingly likely to encounter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants