[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Finalizing DDLm
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Finalizing DDLm
- From: Nick Spadaccini <nick@csse.uwa.edu.au>
- Date: Wed, 31 Mar 2010 10:10:17 +0800
- Authentication-Results: postfix;
- In-Reply-To: <4BB21FED.3060600@mcmaster.ca>
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]
- References:
- Re: [ddlm-group] Finalizing DDLm (David Brown)
- Prev by Date: Re: [ddlm-group] Finalizing DDLm
- Next by Date: Re: [ddlm-group] Finalizing DDLm
- Prev by thread: Re: [ddlm-group] Finalizing DDLm
- Next by thread: Re: [ddlm-group] Finalizing DDLm
- Index(es):