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

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

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

Reply to: [list | sender only]