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

Re: [ddlm-group] Finalizing DDLm

On 30/03/10 11:59 PM, "David Brown" <idbrown@mcmaster.ca> wrote:
> 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
No. There are many examples of List categories that have subcategories inthe core CIF written for DDLm. atom_site and atom_site_aniso is one example. > 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
I have answered this. In the formal specification of DDLm it IS requiredthat a List category appear in a loop even if there is one row. Whether theIUCr accepts in its local implementation extensions to the formalspecification is for them to decide.
> 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>>> <http://www.csse.uwa.edu.au/%7Enick>>>> MBDP  M002>>>  >>> CRICOS Provider Code: 00126G>>>  >>> e: Nick.Spadaccini@uwa.edu.au>>>   >>>  >>> >>>  >>>  >>>  >>> _______________________________________________>>> ddlm-group mailing list>>>  ddlm-group@iucr.org>>>  http://scripts.iucr.org/mailman/listinfo/ddlm-group>>>  >>>  >>>  >>  >>  >>  >>  
--------------------------------Associate Professor N. Spadaccini, PhDSchool of Computer Science & Software Engineering
The University of Western Australia    t: +61 (0)8 6488 345235 Stirling Highway                    f: +61 (0)8 6488 1089CRAWLEY, Perth,  WA  6009 AUSTRALIA   w3: www.csse.uwa.edu.au/~nickMBDP  M002
CRICOS Provider Code: 00126G
e: Nick.Spadaccini@uwa.edu.au

_______________________________________________ddlm-group mailing listddlm-group@iucr.orghttp://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]