Discussion List Archives

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

Re: [magCIF] magCIF working group

 Dear Branton,

I have followed the DDL development till DDL2. I know almost nothing about DDLm but the example given by David is very interesting and clarifying. It points out a question that is normally forgotten during the design of new dictionaries: they contain everything about the data items. Meaning, type, category, aliases, cross references... In general everybody tries to extract information just from the name itself, something that in my opinion is an error although I recognise that ad hoc solutions could simplify parser coding. In this context I will always prefer extensions to existing dictionaries rather than new closed ones in which one needs always redefine existing data items. The atomic fractional coordinates have the same meaning in normal, modulated or magnetic structures. Let,s the dictionaries play their role.


Enviado desde mi iPad

El 18/06/2014, a las 21:09, Branton Campbell <bjc79@physics.byu.edu> escribió:

Thanks David,

This example of the _alias.definition_id (mentioned previously by Vaclav) is very helpful.


On Jun 18, 2014, at 8:37 AM, David Brown wrote:

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 _atom_site_fract_x listed as an alias, thus a program using the DDLm version of the dictionary will automatically recognize either name

To illustrate the flexibility of DDLm,
at 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 _import.get item 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 updated once.  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 dictionary.

    _definition.id             '_atom_site.fract_x'
    _alias.definition_id       '_atom_site_fract_x'
    _import.get         [{"file":'templ_attr.cif',"save":'fract_coord'}]
    _name.category_id            site
    _name.object_id              fract_x

    _definition.update           2012-05-07
     Atom site coordinates as fractions of the cell length values.
    _type.purpose                Measurand
    _type.source                 Derived
    _type.container              Single
    _type.contents               Real
    _enumeration.range           -1.:1.
    _units.code                  none


On 6/17/2014 8:35 PM, Campbell, Branton wrote:

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


Regarding David’s comment on merging  multiple dictionaries: Does the “_atom_site_fract_x” 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?




From: magcif-bounces@iucr.org [mailto:magcif-bounces@iucr.org] On Behalf Of David Brown
Sent: Tuesday, June 17, 2014 10:14 AM
To: Discussion list for the magnetic CIF dictionary project
Subject: 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


magCIF mailing list

magCIF mailing list

magCIF mailing list
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.