Discussion List Archives

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

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

Title:
Dear Herbert,

I suggested earlier that we could easily add the style tag you suggest.  In some cases where an earlier dataname has already been superceded by a second dataname it would be necessary to indicate which is the proper (i.e., later) name that should be used on writing since all datanames that have ever been approved must appear in the alias list.  With the style tag the _alias_uri would not be as important and could be omitted.

There are a number of reasons why your import scheme would have made life considerably more complicated.  The first is that the old tags do not conform to CIF2 syntax and therefore would have to be insulated within the routines that manipulates the data under DDLm CIF-dictionary control.  The second is that DDLm has a much tighter heirarchical category structure that is desinged to simplify the merging and updating of the dictionaries.  This was introduced to overcome some of the weaknesses of the earlier file structures.  Allowing the DDL1 and DDL2 datanames to be defined in save frames within the DDLm dictionary would lead to incompatibilities that would prevent many of the newly introduced
features in DDLm being used.  For example in DDLm the category and object parts of the datanames are defined independently and represent the two components out of which the dataname is constructed at run time.  The dataname in the save_ statement is, by convention, a composite of these two components, but it is not the definition of the name.  Since it is not possible with the older datanames to separate them into a catagory and object component without in some cases misnaming the category, their presence would effectively mean that the tighter features of DDLm could not be used either in programming or in updating and merging.  One should not try to put new wine into old wine skins.

Anyway it sounds as if we have agreement on at least something. and knowing that DDLm can achieve compatibility with the earlier archive by using the aliases on reading and writing, and proper DDLm names otherwise, should simplify the discussions on syntax.



Herbert J. Bernstein wrote:
Dear David,

  That was very helpful.  You want to maintain one dictionary that will dynamically act as a DDL1, DDL2 or DDLm dictionary. Fair enough.  But then shouldn'e the information on what alias is intended for what style of output simply be in the alias tags.  It is not really a matter of which dictionary it come from, but of which of several alternate styles of tags it conforms to.

  Right now the alias category has 2 tags,

  _alias.definition_id
  _alias.dictionary_uri

We could both do what we need to do without conflicting if there were a third tag

  _alias.tag_style

which would simply be a character string, such as DDL1, DDL2, DDLm, my_new_style, ... which could be used to tie together the style of tags to be used for a particular dictionary use, both for validation of input and for generation of output.  If no particular style had been specified, the save frame name would win.  This would bring the data on which are DDL1 names and which are DDL2 names for the core values neatly together on one core dictionary without having to know if any other dictionaries were DDL1 style and which are DDL2 style.  The DDLm dictionary would have all the information right there and would not even need to refer to the older dictionaries on most cases to work with DDL1 and DDL2 data files.

  For my work, this would be just as effective as the import ... as ... or my method_alias suggestion in allowing me to use CIF1 tags that are illegal under CIF2 without requiring us to allow those names as valid tags in DDLm dictionaries.

  Could you accept _alias.tag_style, and perhaps allowing _alias.dictionary_uri to be omitted when not really needed?  This would be a big help to me in then making a DDLm imgCIF dictionary that could not only replace the DDL2 dictionary, but could also, for the first time provide a DDL1 version of all imgCIF tags.  I could even then automatically produce valid DDL1 and DDL2 dictionaries from the DDLm dictionary source, making thr DDLm dictionary the only version that I would have to maintain.

  Thank you again.  That was really very helpful.

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

                 +1-631-244-3035
                 yaya@dowling.edu
=====================================================

On Wed, 19 Jan 2011, David Brown wrote:

Herbert,

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.

The 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

David

------------------------------------------

save_diffrn_standards.decay_percent
    _definition.id             '_diffrn_standards.decay_percent'
    _definition.update           2008-06-09
    _description.text
;              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
loop_
    _description_example.case
    _description_example.detail
                  '0.5(1)'     
;                    represents a decay between 0.2% and 0.8%
;
                   '-1(1)'
;                     the change in the standards lies between a decay of
                               2% and an increase of 4%'
;
                   '0.0(2)' 
;                     the change in the standards lies between a
                               decay of 0.6% and an increase of 0.6%.
;
loop_
           _alias.definition_id
           _alias.dictionary_uri
           '_diffrn_standards_decay_%'       cifdic.c91
           '_diffrn_standards.decay_%'       cif_mm_1.0.dic
     save_
 




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

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.

Regards,
    Herbert

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

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================

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 a
ble 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 c
orrect me where I am wrong, but as far as I can tell, DDLm's alias system p
rovides all the needed hooks.  Here are some implied details that might cla
rify 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 a
ppear.

2) Where necessary, DDLm aliases bind the data names actually used in input
 data CIFs to the corresponding names defined in the dictionary.  This alia
sing 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 ex
pects the output name to be defined.  If the chosen dictionary is not the D
DLm 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 altogethe
r.

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


It is possible that part of the problem here is a disagreement over the mea
ning of "CIF1 interoperability".  The above description explains CIF1 inter
operability over the full breadth of DDLm / dREL design goals as I perceive
 them, but Herbert has expressed an interest in embedding script in data fi
les, and perhaps his concerns arise from that direction.  As far as I can t
ell, that would be outside dREL's design parameters, but dREL could conceiv
ably still be applied in such a context.  Details and any semantic differen
ces would need to be defined in the appropriate data dictionary, however, n
ot 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 r
ather too far afield.


Regards,

John

--
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@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group



_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group








_______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group


begin:vcard
fn:I.David Brown
n:Brown;I.David
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
email;internet:idbrown@mcmaster.ca
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773
version:2.1
end:vcard

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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

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

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