[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 <[email protected]>
- Subject: Re: [ddlm-group] Finalizing DDLm
- From: "Herbert J. Bernstein" <[email protected]>
- Date: Tue, 30 Mar 2010 12:23:26 -0400 (EDT)
- In-Reply-To: <[email protected]>
- References: <[email protected]><C7D104FC.13080%[email protected]><[email protected]><[email protected]>
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
[email protected]
=====================================================
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
> <[email protected]> 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
> >>>>> [email protected]
> >>>>>
> 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
> >>>> � � � � � � � � �[email protected]
> >>>>
> =====================================================
> >>>> _______________________________________________
> >>>> ddlm-group mailing list
> >>>> [email protected]
> >>>>
> 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
> >>> [email protected]
> >>>
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
> >>
> >> _______________________________________________
> >> ddlm-group mailing list
> >> [email protected]
> >>
> 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: [email protected]
>
>
>
>
> _______________________________________________
> ddlm-group mailing list
> [email protected]
> 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
> [email protected]
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
>
>
>
>
_______________________________________________ ddlm-group mailing list [email protected] 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):

