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).
CIF 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
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,
; 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.
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].
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.
1991-05-27 Created from CIF Dictionary text. SRH
1996-11-27 Release version 2.0. IUCr
These strings should be used within a CIF to identify the dictionary version
with which that CIF is compatible, e.g.
Note 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
Considerable effort has been expended in ensuring compatibility with data
names in old data files. To this end, version 2.0 of the Core dictionary
includes all data names in version 1.0, with the following minor
exceptions (both discussed further in the Dictionary
formalism section above):
In addition, the following data names, though still present in the version
2.0 dictionary, carry an indication that they should be replaced in future
data files by alternative names. The purpose of this to align data names
with the name structure of their parent category (i.e. it is
potentially confusing that the data name _diffrn_radiation_detector
should belong to the diffrn_detector category and not the
- 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.
The following 203 data names are new in version 2.0 of the Core. They
represent 55 category descriptions and 148 `real' data names. (The total
number of data names defined in version 2.0 is 624.)
- _diffrn_radiation_detector should be replaced by
- _diffrn_radiation_detector_dtime should be replaced by
- _diffrn_radiation_source should be replaced by
Every 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
This will become increasingly important as dictionary validation software
is written that checks data types, value ranges and interdependencies.
Updated 29 January 1997
Copyright © 1997 International Union of Crystallography