[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Finalizing DDLm
- To: Nick.Spadaccini@uwa.edu.au, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Finalizing DDLm
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Tue, 30 Mar 2010 22:51:18 -0400 (EDT)
- In-Reply-To: <C7D8D2FE.130FF%nick@csse.uwa.edu.au>
- References: <C7D8D2FE.130FF%nick@csse.uwa.edu.au>
I really don't understand why _atom_site_label Cu _atom_site.fract_x 0.0 _atom_site.fract_y 0.0 _atom_site.fract_z 0.0 is a problem. It looks very clear and is easily coerced to loop_ _atom_site_label _atom_site.fract_x _atom_site.fract_y _atom_site.fract_z Cu 0.0 0.0 0.0 when a dictionary is available to tell you that this is supposed to be a looped list. And, while _atom_site_label Cu _atom_site.fract_x 0.0 loop_ _atom_site.fract_y 0.0 _atom_site.fract_z 0.0 is a little strange it is just as clear. The more interesting case is related to what David suggested, of mixing a single tag value pair with a loop with more than one row. That seems very useful and echoes some of what was already done in the mmCIF dictionary. If a sensible coercion is clear from the dictionary, why not just do it? ===================================================== 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 ===================================================== On Wed, 31 Mar 2010, Nick Spadaccini wrote: > > > > On 31/03/10 12:23 AM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com> > wrote: > >> 1. Existing DDL2 style dictionaries have many looped categories with >> subcategories. > > As do the dictionaries written in the DDLm. > >> 2. I do not understand why there is any special need to forbid the >> presentation of a single row list category as separate tags and >> values, nor why there is any special need to forbid the presentation >> of an unlooped catagory as a single row loop. Any necessary coercion >> is easily done in either case, and deserves at most a warning, if even >> that. > > The reasoning is that you are enforcing its "type" specification. It is a > List category object. ALL List category objects MUST be syntactically > presented by the loop_ keyword, followed by a sequence of tags, followed by > a list of values whose type then matches the tag type. Anybody reading the > data in the absence of a dictionary will immediately know it is a List > object. > > I must say Syd and my reasoning is pretty clear as to why we enforce it the > way we do. However I can't see the reasoning behind your and David's desire > to allow for, > > _atom_site_label Cu > _atom_site.fract_x 0.0 > > loop_ > _atom_site.fract_y 0.0 > > _atom_site.fract_z 0.0 > > The above is a logical consequence of what is being suggested. You may not > intend it, but "when you'se open the can, you'se eat the worms". > > Again (and again and again) I repeat IF the IUCr wishes this to be an > extension in its implementation of DDLm that is for it to decide. > > >> >> >> ===================================================== >> 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 >> ===================================================== >> >> On Tue, 30 Mar 2010, David Brown 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 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > > > _______________________________________________ > 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
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Finalizing DDLm (Nick Spadaccini)
- References:
- Re: [ddlm-group] Finalizing DDLm (Nick Spadaccini)
- 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):