James seems to have summarized matters pretty well. The
implication is that a list category must be the end of the line - it
cannot have a subcategory. My real questions was whether a list
category must explicitly included as a loop, or whether the loop
structure is unnecessary if it only contained a single row. It is easy
enough to be safe by always inculding the loop, and I will probably
arrange to do this in the dictionaries. There are likely to be several
places with single fow loops appear, e.g., in examples or aliases.
David
James Hester wrote:
Thanks Nick for clarifying this. We then
return to David's question. If we assume that a 'Set' category cannot
be a child of a 'List' category (I hope this is written down somewhere
if it is the case) then my originally proposed solution would be
impossible. Therefore, what David should do is to put the invariant
items into a *parent* 'Set' category and state that the child 'List'
category. That would solve the immediate issue of separating out
looped and unlooped datanames. If some convenience is desired for dREL
processing, the child 'List' category could be made joinable to that
parent category, thereby making both invariant and looped items
available in shorthand form by looping over the parent category. Of
course, even if the child 'List' category is not explicitly joined to
the parent 'Set' category, the parent category can be explicitly
referenced in any dREL method using the full dataname.
Nick may wish to confirm that I have correctly understood the proposed
behaviour of DDLm.
James.
On Thu, Mar 25, 2010 at 3:18 PM, Nick
Spadaccini <nick@csse.uwa.edu.au> wrote:
I
have not had any time to respond to David¹s original email or the
subsequent discussions. However I have discussed it with Syd.
DDLm defines loopable categories strictly and sub-categories of those
have
strictly enforced outer joins (given we have ONLY considered
sub-categories
that are List). This is how we overcome the split versus non-split
versions
of atom_site and atom_site_aniso loops. List is strictly looped, Set is
strictly non-looped contrary to your reading, and possibly Syd¹s
original
text. He has since re-read what he wrote and clarified the ambiguity. I
will
send you that re-write shortly.
We had not considered a SET category being a sub-category of a List
category, but if it is allowed then it would not be an outer-join as you
suggested in your previous contribution but a relational Cartesian
product
(which is very different).
The DDLm specification has that List category data MUST appear in a loop
(irrespective of how many rows there are), and SET categories are
strictly
singular (non-looped data). The formal specification will formally
remain
that way.
HOWEVER the IUCr is free to ³extend² the specification of the DDLm for
its
own internal and private use, so long as you appreciate that the FORMAL
published specification of what Syd and I have created can¹t include it.
You might explain as to why you feel you have trouble with
loop_
_atom_site.label
_atom_site.frac_x
_atom_site.frac_y
_atom_site.frac_z
Cu 0 0 0
And yet
_atom_site.label Cu
_atom_site.frac_x 0.
_atom_site.frac_y 0.
_atom_site.frac_z 0.
Is so much more obvious? Given that people understand what the loop is,
I
can't see what they would gain from the unrolled version (apart from
confusion). The real danger is those less experienced who DON'T read a
dictionary and read the latter form may be encouraged to replicate it
when
there is more that 1 atom (thus corrupting the CIF structure).
However these are just personal observations, and if the IUCr wants to
qualify the use of DDLm with its own tweaks there is nothing stopping
them
from doing so.
>>>>
>>>> At 10:35 AM -0500 3/11/10, David Brown wrote:
>>>>>
>>>>> Dear Colleagues,
>>>>>
>>>>> I assume that we are essentially finished in
resolving syntax
>>>>> problems, but in that discussion some items were
identified as being
>>>>> related to DDLm rather than syntax, so before we
settle into serious
>>>>> dictionary writing we need to understand the DDLm
rules.
>>>>>
>>>>> 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.
>>>>>
>>>>> Is this something that can be clarified fairly
easily? It has an
>>>>> important bearing on how the CIF dictionaries are
written.
>>>>>
>>>>> David
>>>>>
>>>>> Attachment converted: Macintosh HD:idbrown 55.vcf
(TEXT/ttxt) (0046DFC7)
>>>>> _______________________________________________
>>>>> ddlm-group mailing list
>>>>> ddlm-group@iucr.org
>>>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>>
>>>>
>>>> --
>>>> =====================================================
>>>> 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
>>>> =====================================================
>>>> _______________________________________________
>>>> ddlm-group mailing list
>>>> ddlm-group@iucr.org
>>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>>
>>>
>>>
>>>
>>> --
>>> T +61 (02) 9717 9907
>>> F +61 (02) 9717 3145
>>> M +61 (04) 0249 4148
>>> _______________________________________________
>>> ddlm-group mailing list
>>> ddlm-group@iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>> _______________________________________________
>> ddlm-group mailing list
>> ddlm-group@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>>
>
>
cheers
Nick
--------------------------------
Associate Professor N. Spadaccini, PhD
School of Computer Science & Software Engineering
The University of Western Australia t: +61 (0)8 6488 3452
35 Stirling Highway f: +61 (0)8 6488 1089
CRAWLEY, Perth, WA 6009 AUSTRALIA w3: www.csse.uwa.edu.au/~nick
MBDP M002
CRICOS Provider Code: 00126G
e: Nick.Spadaccini@uwa.edu.au
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group
|
