Discussion List Archives

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

Re: Important CIF items for discussion

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.


  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769


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]