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

Re: [ddlm-group] Finalizing DDLm

See comments below.

On Fri, Mar 12, 2010 at 2:35 AM, David Brown <idbrown@mcmaster.ca> wrote:

> One item that I believe was raised under this heading was whether, if a loop
> contained a single set of items, it was necessary to formally include this
> in a loop structure.  If this is deemed to be necessary, then there has to
> be some way of identifying the items that must appear in a loop.  The
> presence in the dictionary of a _category_key.* item would seem to flag
> this, but it is applied at the level of the category rather than at the
> level of an individual item.  If the requirement that the loop structure
> must always be used, then all the items in the category must be loopable,
> i.e., the category cannot include items that would not normally be included
> in the loop, items for example that apply equally to all the listed items
> such as a scale factor that is the same for all the structure factors in a
> loop.  This seems to be workable, but I am not sure how the legacy CIFs
> would fit in, since categories may include some listable item and some
> non-listable items, and I am sure the listable items do not always appear in
> a loop if there is only one set of such items reported in the CIF.

The DDLm draft proposes the '_definition.class' attribute, which when
applied to a category specifies either a 'List' class (which means
items must be looped) or a 'Set' class (items do not have to be
looped).  The DDLm specification (section 4.1) states that "items in a
Set category are seen to be automatic members of the parent category",
whereas 'List' categories do not necessarily have this property.  So:
if an item value applies equally to all items in a loop, then I would
suggest that those items should be placed in a 'Set' category that is
a child of the looped category.   One approach for legacy dictionaries
would be to split mixed looped/unlooped categories into a 'List'
category and a 'Set' category, with the 'Set' category being the child
of the 'List' category if the 'Set' category values need to be
available when performing calculations on the 'List' loops.

A interesting side-effect of the 'List'/'Set' parent/child interaction
is that a 'Set' category with looped items would apparently be
automatically subsumed into a 'List' parent category, meaning that
each row of the 'Set' category loop is true for every row of the
'List' category loop - what I believe the database people call an
'outer product'.

I think that this scheme should be pretty workable for legacy
dictionaries - can you identify any specific problems associated with
splitting legacy categories into two?

> Is this something that can be clarified fairly easily?  It has an important
> bearing on how the CIF dictionaries are written.

I hope I have clarified rather than muddied the waters...

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list

Reply to: [list | sender only]