Important CIF items for discussion
Herbert J. Bernstein
yaya at bernstein-plus-sons.com
Thu Jul 17 13:41:35 BST 2008
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 at 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 at 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 at 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 at iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs
>
More information about the comcifs
mailing list