Discussion List Archives

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

Re: [ddlm-group] Objectives of CIF2 syntax discussion. .


I have copied below the DDLm entry for the item you suggest.  Notice that it has a different name in the DDLm CIF-dictionary.  The input file includes all the information needed to calculate this item but _diffrn_standards.decay_% is not present in the input and we require to add it.  The values we need in the input file are read in and associated with the new DDLm datanames (is this what you call a tag?).  The user must make some decision what information he requires and must emter this into the program in the form of a dataname.  There are many ways this could be done, but this is a programming decision, not a dictionary one.  The information mau be supplied as
'_diffrn_standards.decay_percent' or '_diffrn_standards.decay_%'.  Either way the instruction is converted (via the alias) to '_diffrn_standards.decay_percent' which is the name that would be used in the method.  Note that changing a dataname does not require any change in the value of the item.  After execution of the method this item would be populated.  The user must also decide what output is needed, say mmCIF (i.e. a CIF2 datafile).  The program locates the correct output name  '_diffrn_standards.decay_%' in the alias list and writes the mmCIF file using this name.  Note that the name '_diffrn_standards.decay_%' does not correspond to the CIF2 syntax, but the input and output parts of the program recongnize when it is working with CIF1 syntax.

reason this is cleaner is that only one method is needed since all manipulations between reading the input and writing the output are carried out using the DDLm CIF-dictionary including the DDLm CIF-dictionary tags.  If we need different methods for different standards we would end up with three different dictionaries and we would loose the abitlity e..g., to read in a CIF1 data file and write out a CIF2 datafile.  Writing, and more to the point maintaining, the kind of dictionary you envision would be a nightmare.

Best wishes



    _definition.id             '_diffrn_standards.decay_percent'
    _definition.update           2008-06-09
;              The percentage decrease in the mean
               intensity of the set of standard reflections measured at the
               start of the measurement process and at the finish.  This value
               usually affords a measure of the overall decay in crystal
               quality during the diffraction measurement process.  Negative
               values are used in exceptional instances where the final
               intensities are greater than the initial ones.  If no
               measurable decay has occurred, the standard uncertainty should
               be quoted to indicate the maximum possible value the decay
               might have.  A range of 3 standard uncertainties is considered
               possible.  Thus 0.0(1) would indicate a decay of less than
               0.3% or an enhancement of less than 0.3%.
    _description.common         'DiffrnStandDecay%'
    _name.category_id            diffrn_standards
    _name.object_id              decay_percent
    _type.purpose                Measured
    _type.container              Single
    _type.contents               Real
    _enumeration.range           :100
;                    represents a decay between 0.2% and 0.8%
;                     the change in the standards lies between a decay of
                               2% and an increase of 4%'
;                     the change in the standards lies between a
                               decay of 0.6% and an increase of 0.6%.
           '_diffrn_standards_decay_%'       cifdic.c91
           '_diffrn_standards.decay_%'       cif_mm_1.0.dic

Herbert J. Bernstein wrote:
Let's take a concrete example:  Suppose we want to use a DDLm method to 
populate _diffn_standards.decay_% in an mmCIF dictionary from the actual 
measured reflections (or, more elegantly as a long-term goal directly from 
the data in a scan of image frames).

That tag cannot be used directly in a dREL method. Under David and John's 
proposed use of the alias mechanism, what aliases would have appear where 
and to what should be method itself refer, and in what save frame would it 
be defined.  Ideally, we would like to be able to have this all gathered 
into one dictionary, and the dictionary merge mechanism allows us to do 
that, so whatever we propose should not depend on the name or type of the 

I can see how the alias mechanism can be used to validate the value.  I 
don't yet see how it can be used to generate the value using the illegal 
tag. If I understand the DDLm docuemnt correctly, to generate a value for 
a tag, the method has to be in the same frame defining that tag, but we 
seem to have barred this tag from being the name of a save frame in a 
CIF2-style DDLm dictionary.  If we were to go back to allowing all the 
valid CIF1 tags as tags in DDLm dictionaries, then this particular problem 
would go away with a little jiggering either of the alias mechsnism or by 
adding the import ... as ... to the methods. I think the import is 
cleaner, but I msay be wrong and look forward to seeing the alias 
solution. I am not sure I see any simple solution if we don't relax the 
tag restriction back to CIF1 rules, but again, I may be wrong.


  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769


On Wed, 19 Jan 2011, Bollinger, John C wrote:

On Wednesday, January 19, 2011 7:37 AM, Herbert J. Bernstein wrote:

If the CIF1 interoperability with DDLm is an absolute given, we should be able to work things out.  That may or may not require changes in CIF2, but I am fairly sure it will require some new hooks in dREL and DDLm to be able to work fully with CIF1 tags.  Perhaps I've missed those hooks.
I trust those here having more practical experience with DDLm and dREL to correct me where I am wrong, but as far as I can tell, DDLm's alias system provides all the needed hooks.  Here are some implied details that might clarify matters:

1) Each dREL method appearing in a DDLm data dictionary refers to CIF items exclusively in terms of those items' data names (not aliases), as defined in the dictionary in which the referenced items and the method's item all appear.

2) Where necessary, DDLm aliases bind the data names actually used in input data CIFs to the corresponding names defined in the dictionary.  This aliasing is transparent to dREL methods and to data validation procedures.

3) When needed, a DDLm-based system can automatically select an output data name for an item, based on the name of the dictionary in which the user expects the output name to be defined.  If the chosen dictionary is not the DDLm dictionary itself then the given dictionary name is used to select the appropriate alias from among those defined for the item in question.  This activity also is transparent to dREL, if not outside dREL's scope altogether.

All of that depends heavily on the content of the dictionary, but it appears fully supported by DDLm and dREL as presently defined. None of those operations inherently depend on details of CIF syntax.

It is possible that part of the problem here is a disagreement over the meaning of "CIF1 interoperability".  The above description explains CIF1 interoperability over the full breadth of DDLm / dREL design goals as I perceive them, but Herbert has expressed an interest in embedding script in data files, and perhaps his concerns arise from that direction.  As far as I can tell, that would be outside dREL's design parameters, but dREL could conceivably still be applied in such a context.  Details and any semantic differences would need to be defined in the appropriate data dictionary, however, not in that dictionary's DDL (whether DDLm, DDL2, or DDL1).  As stimulating as a discussion of that topic might be, I think at the moment it would go rather too far afield.



John C. Bollinger, Ph.D.
Department of Structural Biology
St. Jude Children's Research Hospital

Email Disclaimer:  www.stjude.org/emaildisclaimer

ddlm-group mailing list

ddlm-group 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

ddlm-group 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.