[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: James Hester <jamesrhester@gmail.com>
- Date: Thu, 20 Jan 2011 18:55:47 +1100
- In-Reply-To: <alpine.BSF.2.00.1101191647260.65107@epsilon.pair.com>
- 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><alpine.BSF.2.00.1101191647260.65107@epsilon.pair.com>
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 ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- 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)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (Herbert J. Bernstein)
- 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):