Differences between versions 2.0.x and 1.0 of the Core CIF Dictionary
- In versions 2.0 and subsequently, the limitation to 32 characters of data names is removed. Data names have no formal length limit. However, the limit of 80 characters on the overall line length restricts the useful length of data names to 76 characters (permitting the string "data" to be prepended in constructing data block names within the dictionary).
Dictionary formalismCIF dictionaries are themselves STAR data files, with data blocks or save frames containing the definition and properties of the data names described. These definitions and properties are recorded with the use of data names described in a Dictionary Definition Language (DDL). Version 2.0 of the Core CIF dictionary employs a DDL different from that used in release 1.0. Consequently the layout of definition entries in the two dictionaries differs. For more information on DDL, consult the DDL page on this server.
The major differences apparent to the average user are:
Formalisation of categories. In the original CIF dictionary, data names were constructed as a set of components separated by underscores, such as _atom_site_fract_x, which were chosen to reflect a hierarchical classification scheme. However, there was no formal mechanism for dividing a data name into its category and topic components. The new dictionary assigns each data name to a category, usually (but not always) corresponding in name to the first few components of the data name itself. Thus _atom_site_fract_x belongs to the atom_site category, _atom_type_description to the atom_type category, and _cell_length_a to the cell category.
It is a requirement of CIFs conforming to DDL version 1.4 and above that a single loop_ construct may contain only data names of the same category.
The data names in the dictionary are arranged alphabetically by category; in the formatted versions, the current category is identified in the running head to each page.
Descriptive sections. Within the dictionary, each category contains a data name designed to include information about that category, and not intended for use as an entry in a CIF data file. The data names fulfilling this function are all assigned to the category category_overview, have type 'null', and include square brackets, e.g.
data_atom_type_The square brackets may include a code for the relevant dictionary extension; e.g. a symmetry CIF dictionary might extend the contents of the atom_type category and have an annotation of the new features introduced to the category in a data block for _atom_type_[sym].
; Data items in the ATOM_TYPE category record details about
properties of the atoms that occupy the atom sites, such as the
atomic scattering factors.
A similar explanatory purpose was behind the _chemical_formula_appendix entry in the original Core dictionary, which has been deleted from version 2.0 and above.
Withdrawal of units extensions. The original Core dictionary permitted the derivation of new data names from existing ones by appending a suffix to indicate the use of different physical units (e.g. _cell_length_a_nm derived from _cell_length_a to yield a cell length in nanometres, instead of the default ångströms). This mechanism is no longer sanctioned, and all data names have a single associated physical unit (listed in the dictionary).
For strict compatibility with old data files, a compatibility dictionary has been produced. This may be used by dictionary validation software to permit the recognition of the old data names, but it should not be used to generate such data names in new data files.
Dictionary identification strings. Previous dictionary files were referred to by an informal file name such as cifdic.C91. The new dictionary contains a header section including strings for the _dictionary_name and _dictionary_version, e.g.
data_on_this_dictionaryThese strings should be used within a CIF to identify the dictionary version with which that CIF is compatible, e.g.
1991-05-27 Created from CIF Dictionary text. SRH
1996-11-27 Release version 2.0. IUCr
data_cif_exampleNote from the example a typical URL specifying the file name of the current Core dictionary. On the IUCr server, the local file name is compounded of the dictionary name and version strings; but if the dictionary were downloaded to a DOS computer, it would need to be stored under a different file name. It is the responsibility of an installation accessing dictionary files to provide the mapping between local file names and the dictionary identifiers.
- Names generated by the addition of suffixes listed as _units_extension in version 1.0. These may still be accessed through the compatibility CIF dictionary described above, but should not be used in new data files.
- _chemical_formula_appendix, which included a textual description of a group of data names and is replaced in version 2.0 by data names in the category_overview category.
- _diffrn_radiation_detector should be replaced by _diffrn_detector
- _diffrn_radiation_detector_dtime should be replaced by _diffrn_detector_dtime
- _diffrn_radiation_source should be replaced by _diffrn_source
Data filesEvery effort has been made to ensure that existing data files remain conformant to the new dictionary. Provided an existing CIF output application does not use derivative data names indicating the use of different physical units. as permitted in the original Core, the resultant files will fully conform to the Core CIF version 2.0 and upwards.
However, any data files wishing to use the new data names introduced in version 2.0 and later should include a record of the version of the dictionary against which the file was compiled. This is achieved by adding to each data block the pair of entries indicated below for the most recent version:
This will become increasingly important as dictionary validation software is written that checks data types, value ranges and interdependencies.
Updated 29 January 1997