Discussion List Archives

[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>>>  >>>  >>>  >>  >>  >>  >>  
cheers
Nick
--------------------------------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]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.