One of the features in DDLm is the list of aliases. This
is a list of all the datanames under which the
item appears in other dictionaries. The
extract from the DDLm dictionary given below
shows that the item which appears
under the dataname _atom_site.fract_x
in DDLm has
as an alias, thus a program using the DDLm version
of the dictionary will automatically recognize either
To illustrate the flexibility of DDLm,
run time one
can define any other
alias that one may wish to use. For
example you might have a local file that
uses the name _x_atomic_coordinate
defined in a private CIF-like dictionary. At run
time the private dictionary can be
merged into the virtual dictionary to insert the name _x_atomic_coordinate
as an additional alias. The presence of a
private dataname in a CIF is legal, but it would
normally be ignored. It can be understood
by merging the private dictionary
into the run-time virtual dictionary,
a process that would add the name
to the list of aliases.
A dataname in DDLm has no
semantic content beyond labelling the
data item. It is never parsed.
As can be seen below, the dictionary
separately defines the category_id as
atom_site and the
object_id as fract_x.
As an illustration of how creation
of the virtual dictionary works, I
include here extracts from
two different dictionary files
of the coreCIF dictionary.
The first is from the
'structure' file and it
defines the item _atom_site.fract_x,
but at run time the
is replaced by the contents of _fract_coord
from the 'attributes' file. The
fract_coord items are common to
all the fract_* items in the
virtual dictionary. They are
included in a separate file
so that they only have to be
At this stage there is
no need to worry about the
meaning of the _type. and
other items. The purpose
of illustrating this
extract is to introduce
some of the features
that make DDLm
a good choice
for the magCIF
Atom site coordinates as
fractions of the cell length values.
On 6/17/2014 8:35 PM, Campbell, Branton wrote:
Vaclav’s inquiry: It’s normal to combine tags from
different dictionaries in the same CIF output file, even
if those dictionaries are written in different DDL
versions. This is already commonly done when using tags
from the symCIF dictionary (DDL2) together with tags from
the coreCIF (DDL1) dictionary.
David’s comment on merging multiple dictionaries: Does
tag name in the DDLm version of the core dictionary get
changed to “_atom_site.fract_x”? And how about the
case where the DDL1 core dictionary gets merged into a
composite DDLm dictionary – do the “_” separators get
changed to “.” in that case?
agree with the comments so far in this discussion. I
would just like to point out that DDLm was designed to
be able to read any CIFs written in DDL1 or DDL2. There
is already a version of the core dictionary written in
DDLm. Many programs are written with the data names
hard copied into the code, and for these the dictionary
is irrelevant. They will have no problem reading CIFs
written using DDLm dictionaries provided the CIFs do not
contain matrices and vectors written as single data
items. The only time that the dictionary becomes
relevant is when a program uses the dictionary itself in
order to recognize the datanames, e.g., programs like
checkcif. I imagine that by the time our dictionary is
complete, Chester will have DDLm compatible versions of
its programs running. DDLm can create seamless virtual
dictionaries by reading and merging all the required
dictionaries, e.g., magCIF, coreCIF, symCIF etc. The
coreCIF DDLm dictionary already exists. It may be
necessary to generate a DDLm version of symCIF, but that
will eventually be needed in any case.
On 6/16/2014 5:37 AM, Vaclav Petricek wrote:
returning from a short holiday I have found several new
important contributions from James and Branton. I would
like write my opinion:
comparing advantages and disadvantages of creating a
separate dictionary and adding to existing dictionaries I
would prefer a new separate magnetic dictionary.
the type of dictionary I like the newest DDLm format with
possibility of _alias.definition_id.
do not see problems to read into Jana CIF files having as
category/item separators ‘.’ or ‘_’.
I think this is in accordance with the last answer from
little bit is how to create as an output CIF file. One
possibility is to offer a user three possibilities – pure
DDL1, pure DDL2 or mixed output derived from the original
(standard) definition of each dictionary.
appreciate the positive comments from James.
that we use category.item for tags in the new magCIF
dictionary. Then also suppose that half the relevant
magnetic software packages in the world are willing to
read/write category.item, but that the other half decide
to read/write category_item instead for the same tags
(not an unlikely scenario). If I want my own software
to be compatible with all relevant software packages,
what am I to do? It seems that I must simultaneously
read/write both category.item and category_item for the
same tag, which would be very unpleasant.
On Behalf Of James Hester
Sent: Thursday, June 12, 2014 11:41 PM
To: Discussion list for the magnetic CIF
Subject: Re: [magCIF] magCIF working group
me clarify and expand on a few of Branton's
that officially, neither '.' nor '_' carry any
syntactical or semantic meaning in a dataname.
Conventionally in DDL2 and DDLm dictionaries a '.'
separates the category from the object name, but
this is purely convention and therefore software
should not rely on it. Furthermore, because in
DDL1 datanames no such convention applies, '.' is
just another character and datanames containing
'.' are in no way more or less acceptable.
Therefore, I would strongly urge that all new
magCIF datanames contain a '.' according to the
DDL2/m convention, as such datanames conform with
DDL1, DDL2 and DDLm conventions. There is
absolutely no practical issue with datafiles
containing datanames some of which have '.' and
some of which don't.
imagine that software authors in the magCIF domains
will simply treat the dataname as a string of
characters (as they should) that they use to
read/write a value in a file, and the presence or
absence of '.' or '_' should be completely
irrelevant in this form of usage. Given this, I do
not see the point of defining two new datanames for
what it's worth, I think Branton's suggestion of
developing the basic information in a simple ASCII
file is by far the best way to proceed.
all the best,
On Fri, Jun 13, 2014 at 1:01 PM,
Campbell, Branton <email@example.com>
Dear magCIF working group members
Our first big decision is whether to form a separate
magCIF dictionary or to propose additions to existing
dictionaries ("core", "symmetry" and "modulated
Advantages of a separate dictionary: (1) This would
be the fastest route to approval. (2) The discussion
would be influenced primarily by those with experience
with magnetic structures.
Disadvantages of a separate dictionary: (1) Nearly
all of the magnetic tags are highly analogous to tags
in other dictionaries. Separating them in a separate
dictionary weakens the analogies. (2) We have to
decide on a specific version of the Dictionary
Definition Language (DDL) for creating the dictionary.
Because the core and modulated-structures are written
in the older DDL1, while the symmetry dictionary is
written in newer DDL2, either choice will weaken the
connection to a large number of analogous tags. There
is also an even newer DDL version called "DDLm".
Advantages of adding to existing dictionaries: (1)
The obvious analogies between magnetic and
non-magnetic tags are emphasized. (2) No decision
between different DDL versions is necessary -- each
existing dictionary is already version specific.
Disadvantages of adding to existing dictionaries: (1)
Different committees would study and vote on tags
proposed for different dictionaries. (2) Those
debating the additions to each dictionary might have
little knowledge of the unique issues surrounding
magnetic structures. (3) The process of approval
could take a long time to complete, and requested
changes could create incompatibilities between tags
submitted to different dictionaries.
I think that adding to existing dictionaries would
produce the best final outcome if time were not an
issue. But the current adoption of various
magnetic-CIF variants by different software packages
makes the matter very time sensitive. For this
reason, I propose that we proceed to develop a
separate magCIF dictionary and to move forward as
quickly as possible. Please share your opinions.
If you agree to create a separate magCIF dictionary,
then we must deal the matter of the DDL version.
While the CIF tags developed for various DDL versions
seem similar on the surface, the technical differences
are quite profound. I personally take a superficial
(practical) view of the whole matter -- I am primarily
annoyed that the DDL2 tags always use "." to separate
the "category" from the "item", whereas DDL1 tags
always use "_" to accomplish this. Whichever decision
we make, we will place analogous tags with a mixture
of "." and "_" separators side by side (sometimes in
the same loop) in a CIF. This problem already exists
for users of the symmetry dictionary. But it will be
much worse for magCIF tags due to the strong analogies
between magnetic and non-magnetic tags within the same
category and sub-category. I imagine that some
software authors will ignore whatever standard we
choose, and simply use either "." or "_" uniformly.
And as a result, many programs will
need to take the approach of accepting either "_" or
"." as input, and always writing both "_" and "." in
the output (two copies of each tag). I believe that
there is at least one major structure-analysis program
that already does this for symmetry-dictionary tags.
If I misunderstand this whole situation, please
COMCIFs is quite interested in our decision on the
separate-dictionary issue and the DDL-version issue,
but will probably have less input on the real meat of
our work, which is the structure (name, value ranges,
units, and description) of each tag. I propose that
develop the tag structures now, in a simple ascii-text
file that includes a primitive markup system, and then
convert it into whatever DDL version is decided upon
at a later date. Please share your opinions.
Branton J. Campbell, Professor
Department of Physics & Astronomy
Brigham Young University
N261 ESC, BYU, Provo, UT 84602
Tel: 801-422-5758 Fax: 801-422-0553
magCIF mailing list
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
magCIF mailing list
magCIF mailing list