[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .. .
- To: "'Group finalising DDLm and associated dictionaries'" <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .. .
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Wed, 2 Feb 2011 14:06:52 -0600
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <alpine.BSF.2.00.1102021228580.45252@epsilon.pair.com>
- References: <AANLkTi=ATdNovWFiecEwDrbtMdTwZ7guvYuBCGrdnb-i@mail.gmail.com><a06240800c9668e1faa7c@[192.168.2.102]><8F77913624F7524AACD2A92EAF3BFA54166D7D1EE8@SJMEMXMBS11.stjude.sjcrh.local ><a06240802c9674292646e@[192.168.2.102]><8F77913624F7524AACD2A92EAF3BFA54166D7D1EEB@SJMEMXMBS11.stjude.sjcrh.local ><4D41C6E7.2040109@rcsb.rutgers.edu><8F77913624F7524AACD2A92EAF3BFA54166D7D1EEF@SJMEMXMBS11.stjude.sjcrh.local ><a06240800c967b204830b@[192.168.2.102]><8F77913624F7524AACD2A92EAF3BFA54166D7D1EF0@SJMEMXMBS11.stjude.sjcrh.local ><alpine.BSF.2.00.1101282147550.61818@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EF1@SJMEMXMBS11.stjude.sjcrh.local ><a06240801c96cc655685e@[149.72.7.214]><8F77913624F7524AACD2A92EAF3BFA54166D7D1EF4@SJMEMXMBS11.stjude.sjcrh.local ><a06240801c96e3f206f96@[192.168.2.102]> <4D48A3F6.9090202@rcsb.rutgers.edu><a06240804c96e5ac0e924@[192.168.2.102]><8F77913624F7524AACD2A92EAF3BFA54166D7D1EF6@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1102021228580.45252@epsilon.pair.com>
On Wednesday, February 02, 2011 11:46 AM, Herbert J. Bernstein wrote: >I disagree -- once the keys of the parent category and child category >are settled, the question of keys for the denormalized presentation >is settled -- it has to be the union of the two sets of keys. That in no way conflicts with anything I wrote. As far as keys go, I am and have been talking exclusively about the keys of the parent and child categories. You have rephrased one of my opening comments: "To the extent that the question is answered by the choice of category keys, it is [...] only incidentally a presentation issue." > The >rest really are just presentation issues, e.g. providing mechanisms >for alternate tag names in the denormalized presentation, whether >we need to explicitly say what is implicitly forced by allowing >denormalization at all, etc. I daresay that's hardly a description of "the rest", considering that I have not discussed any of those particulars. Another issue relevant to this area that I did raise, however, is whether denormalizing category joins should be allowed at all. I do not construe the current draft to say that they are allowed, but I have not formed an opinion on whether they should be. >Once you accept that we are working with relations and following >Codd's rules, almost everything we are discussing is a matter of >taste in completely equivalent presentations of the same >information. I don't see how anyone could interpret my commentary to mean that I am thinking in any terms other than Codd's relational model. I do think DDLm leaves open some questions about how categories are mapped to the relational model, however. In particular, it's unclear whether DDLm's mapping relies on relation-valued attributes (and thus on Date's version of the relational model), or whether instead it relies on implicitly flattening the contents of definition frames into a single set of relations. I think either mapping could work, actually, but which one we choose affects any analysis of normalization we perform. For example, when we determine to which normalization forms the various proposed structures of the ALIAS category comply, the answer depends on whether we look at each per-definition ALIAS list separately, or whether we look at a flat, global list, whose key is necessarily expanded to include _definition.id. I'm not sure what "following Codd's rules" means in our context, however. I infer that Herbert would like to allow any data presentation to be valid relative to a given dictionary if it is equivalent, under relational algebra, to the form actually defined by that dictionary. I hope and presume that Herbert agrees that "Codd's rules" as applied to our situation do not prevent restricting the valid presentations according to the category joins that are explicitly allowed by the dictionary. To the extent that that capture's Herbert's meaning, I don't think anyone here disagrees. On the other hand, if "following Codd's rules" implies that DDLm must allow presentations involving denormalizing joins to be valid, then it is not established that we in fact are following those rules. Perhaps we should be, but the DDLm draft indicates that currently we are not. Exhorting us simply to accept it is no substitute for a discussion and informed group decision on whether DDLm should in fact follow that path. I have not yet formed an opinion on the question, but I will not be railroaded. >As for the rest, in which you wish to extend CIF to cover more >general choice of domains with conflicting uses of the same tags, >we alsready have the prefix mechanism, that is similar to the >approach on XML, except with an _ instead of a ":". Prefixes are a centrally-managed mechanism for avoiding data name clashes, and for identifying the dictionaries defining the data names that use them. They are indeed analogous to XML namespace prefixes, and perhaps they adequately address the issue. That's a relevant consideration. The assertion that they in fact DO address the issue, however, is equivalent to the assertion that we should assume a global name space. None of the scenarios I presented for name clashes are foreclosed by prefixes. Furthermore, if prefixes solve this problem, then why does John W. maintain that DDLm ALIASes need to have an associated dictionary identifier and even dictionary version? Seriously, I would like to know. Maybe it doesn't bear on the question. > I think >it would be a very bad idea to move CIF in the direction of >needing access to particular dictionaries to understand >which of several alternative meanings of, say, _cell.length_a >we intended in a particular data cif. No one has suggested that there should be any need to access other dictionaries. So far as I know, no one wants one. As I have written before, nothing we have been discussing places any such requirement. Provide some foundation for this argument or stop raising it. > It would make publishing >journals and running archives even more difficult tasks than they >now are. I think the original COMCIFS decision of a global >name space was a wise choice for the major applications of >CIF, and would suggest we stick to it for DDLm. Noted. John -- John C. Bollinger, Ph.D. Department of Structural Biology St. Jude Children's Research Hospital Email Disclaimer: www.stjude.org/emaildisclaimer _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed). .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. . (John Westbrook)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... . (John Westbrook)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. . (Bollinger, John C)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. . (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .
- Next by Date: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .
- Prev by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .
- Next by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .. .
- Index(es):