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

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

Dear David,

   Inasmuch as we agree on the style tag, there is no need
to argue about the import tag.  I am happy with your
better solution.

   Hopefully James will support us in this minor but
useful addition to DDLm.

   Thank you for your help.

   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:

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

Reply to: [list | sender only]