[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: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Tue, 30 Mar 2010 12:23:26 -0400 (EDT)
- In-Reply-To: <4BB21FED.3060600@mcmaster.ca>
- References: <279aad2a1003242044k36ad7d0cgcc6200d35ed5634f@mail.gmail.com><C7D104FC.13080%nick@csse.uwa.edu.au><279aad2a1003292316g38921bdftf8b76cdfc6410ae7@mail.gmail.com><4BB21FED.3060600@mcmaster.ca>
1. Existing DDL2 style dictionaries have many looped categories with subcategories. 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. ===================================================== 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
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Finalizing DDLm (Nick Spadaccini)
- References:
- Re: [ddlm-group] Finalizing DDLm (James Hester)
- Re: [ddlm-group] Finalizing DDLm (Nick Spadaccini)
- Re: [ddlm-group] Finalizing DDLm (James Hester)
- 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):