[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Objectives of CIF2 syntax discussion. .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Wed, 19 Jan 2011 16:49:42 -0500 (EST)
- In-Reply-To: <4D373AE4.8060406@mcmaster.ca>
- References: <AANLkTikZoEF_D+5-3+Eg4pbCx0cAu+SJvR-a_XkC3zK2@mail.gmail.com><alpine.BSF.2.00.1101190833560.91751@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1ECE@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1101191042290.42382@epsilon.pair.com><4D371BE7.3050501@mcmaster.ca><alpine.BSF.2.00.1101191234221.42382@epsilon.pair.com><4D373AE4.8060406@mcmaster.ca>
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]
- Follow-Ups:
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (James Hester)
- References:
- Re: [ddlm-group] Objectives of CIF2 syntax discussion (James Hester)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (Bollinger, John C)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (David Brown)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (David Brown)
- Prev by Date: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .
- Next by Date: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .
- Prev by thread: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .
- Next by thread: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .
- Index(es):