Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [magCIF] magCIF working group

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.

David Brown

On 6/16/2014 5:37 AM, Vaclav Petricek wrote:

Dear magCIF members,


After returning from a short holiday I have found several new important contributions from James and Branton. I would like write my opinion:


1.       After comparing advantages and disadvantages of creating a separate dictionary and adding to existing dictionaries I would prefer a new separate magnetic dictionary.


2.       Concerning the type of dictionary I like the newest DDLm format with possibility of _alias.definition_id.


3.       I 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 James.


4.       A 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.


With best wishes,







From: magcif-bounces@iucr.org [mailto:magcif-bounces@iucr.org] On Behalf Of Campbell, Branton
Sent: Sunday, June 15, 2014 6:13 AM
To: Discussion list for the magnetic CIF dictionary project
Subject: Re: [magCIF] magCIF working group


I appreciate the positive comments from James.


Suppose 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.






From: magcif-bounces@iucr.org [mailto:magcif-bounces@iucr.org] On Behalf Of James Hester
Sent: Thursday, June 12, 2014 11:41 PM
To: Discussion list for the magnetic CIF dictionary project
Subject: Re: [magCIF] magCIF working group


Dear magCIF members,

Let me clarify and expand on a few of Branton's points.

Note 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. 

I 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 each concept.

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,

(COMCIFS chair)


On Fri, Jun 13, 2014 at 1:01 PM, Campbell, Branton <branton@physics.byu.edu> wrote:

Dear magCIF working group members (and others),

Our first big decision is whether to form a separate magCIF dictionary or to propose additions to existing dictionaries ("core", "symmetry" and "modulated structures").

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 correct me.

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.

Best wishes,

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
Email: branton_campbell@byu.edu

magCIF mailing list

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

magCIF mailing list

fn:I.David Brown
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773

magCIF mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.