Discussion List Archives

[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
                  [email protected]
=====================================================

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
>       ���������������� [email protected]
>       =====================================================
>
>       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
>             ����������������� [email protected]
>             =====================================================
>
>             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
>             [email protected]
>             http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 
> 
>
>             _______________________________________________
>             ddlm-group mailing list
>             [email protected]
>             http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 
> 
> 
> 
> 
>
>       ____________________________________________________________________________________________________________
> 
> _______________________________________________
> ddlm-group mailing list
> [email protected]
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 
> 
> 
> 
>
_______________________________________________
ddlm-group mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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.

Useful links