I 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