[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Important CIF items for discussion
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>
- Subject: Re: Important CIF items for discussion
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Thu, 17 Jul 2008 08:41:35 -0400 (EDT)
- In-Reply-To: <279aad2a0807162343r2fa9b0cby1b31a2845c273f69@mail.gmail.com>
- References: <48777D55.6050606@mcmaster.ca><279aad2a0807162343r2fa9b0cby1b31a2845c273f69@mail.gmail.com>
Dear Colleagues, Allowing a dictionary to be the value of a tag is a reasonable extension of the range of possible URI's for dictionaries, but to avoid ambiguities we need to include such tag-located dictionaries within the DDLm import paradigm, so that we know precisely where within the composite virtual dictionary the tag-located dictionaries should be placed. With respect to the use of \; to allow embedded text fields within text fields, we need to deal with the long-standing use of \; as ogonek, and other existing uses of \. Rather than continue flagging special treatment of text fields in context, I would suggest adding the syntax and semantics of a dictionary text field as a DDLm data type. 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 Thu, 17 Jul 2008, James Hester wrote: > My thoughts on the three issues raised by David. > > 1. Virtual dictionaries > > I favour option D (the dictionary is contained within the datablock as > the text value of a dataitem). This ensures that the dictionary > remains as close as possible to the dataitems it is concerned with. > Note that creating a CIF with such a built-in definition in no way > forces the IUCr to condone the content of that definition: if someone > were to define betas in their CIF and then submit a CIF with betas > rather than UIJs, the IUCr remains free to act as it has in the past > (especially if the beta definition boils down to a description along > the lines of "beta i j as conventionally defined"). > > The technical issues boil down to being able to escape the > "<EOL><semicolon>" digraphs in the embedded dictionary text, which > would otherwise prematurely end the datavalue. Some suggestions: > > (1) Define "<backslash><semicolon>" as being an escaped semicolon (and > this would require defining "<backslash><backslash>" as an escaped > backslash in order to cope with those situations in which you actually > want the text that comes out to be "<backslash><semicolon>"). > Obviously the escaping character doesn't have to be backslash. > > (1a) Define "<EOL><backslash><semicolon>" to be an escaped "<EOL><semicolon>". > > (2) Substitute <EOL><hash> for <EOL> in the entire text field. This > immediately signals to the human reader that the entire text field is > a single block, rather than bits of a CIF file (same as quoting in > emails), and is easily reversible. And nestable, but let's not go > there... > > I would note in passing that Option B (the IUCr accepts and > administers deposited dictionaries) is appealing in that the IUCr > could take care of checking dictionary correctness and keeping track > of what was defined by whom and when. But if DDLm were actually to > expand beyond the confines of the IUCr this would not be a useful > option, as other fields may not have a well-developed central > organisation and at the same time would be in even greater need of a > method of passing around dataitem definitions. > > 2. Hierarchy of methods > > I would cautiously advocate allowing a looped list of methods with a > priority indicator. Dictionary validation tools should attempt to > test both methods and make sure that the resulting values are > identical to within some precision. In general I wouldn't expect this > situation to crop up all that often. > > 3. Intermediate values > > I go with option A, to prohibit the definition of intermediate values. > An item defined in an official CIF has an important status and we > shouldn't water that down or introduce unnecessary complexity. I > believe that the correct way to deal with the intermediate result > issue is to add a new function to the function category (e.g. > BetaFromUIJ). *Implementations* of dREL are then free to attempt > caching of results (eg by defining for themselves an internal dataitem > attached to that function) for efficiency and the dictionary retains > its purity. > > Best wishes, > James Hester. > > On Sat, Jul 12, 2008 at 1:33 AM, David Brown <idbrown@mcmaster.ca> wrote: >> I have attached to this email a dicsussion paper concerning three issues >> that have arisen during our evaluation of the new DDLm. These are important >> issues for the future of CIF, and before I ask the voting members of COMCIFS >> to make a decision, I would like to see the issues fully discussed and, if >> possible, a consensus reached. The attached document is six pages long, but >> I hope you will take the time to read it and comment on the issues raised. >> >> I apologize if you have received this message more than once by being on >> more than one discussion list. Please ignore the second email. >> >> David Brown >> Chair, COMCIFS >> >> _______________________________________________ >> comcifs mailing list >> comcifs@iucr.org >> http://scripts.iucr.org/mailman/listinfo/comcifs >> >> > > > > -- > T +61 (02) 9717 9907 > F +61 (02) 9717 3145 > M +61 (04) 0249 4148 > _______________________________________________ > comcifs mailing list > comcifs@iucr.org > http://scripts.iucr.org/mailman/listinfo/comcifs >
Reply to: [list | sender only]
- Follow-Ups:
- Re: Important CIF items for discussion (James Hester)
- References:
- Important CIF items for discussion (David Brown)
- Re: Important CIF items for discussion (James Hester)
- Prev by Date: Re: Important CIF items for discussion
- Next by Date: Re: Important CIF items for discussion
- Prev by thread: Re: Important CIF items for discussion
- Next by thread: Re: Important CIF items for discussion
- Index(es):