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

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

Alas, no, I can't support it until I can see that it actually solves a
problem.  But I do agree with the general philosophy of finding
solutions to problems by working with DDLm and domain dictionaries.

On Thu, Jan 20, 2011 at 8:49 AM, Herbert J. Bernstein
<yaya@bernstein-plus-sons.com> wrote:
> 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

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list

Reply to: [list | sender only]