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.

   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]