[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: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Fri, 28 Jan 2011 22:23:22 -0500 (EST)
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA54166D7D1EF0@SJMEMXMBS11.stjude.sjcrh.local>
- References: <AANLkTi=ATdNovWFiecEwDrbtMdTwZ7guvYuBCGrdnb-i@mail.gmail.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EDE@SJMEMXMBS11.stjude.sjcrh.local> <4D404DAA.8070804@mcmaster.ca><a06240802c96600c48956@[192.168.2.102]><8F77913624F7524AACD2A92EAF3BFA54166D7D1EE1@SJMEMXMBS11.stjude.sjcrh.local> <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>
Dear Colleagues, I am sorry to hear that John Bollinger "cannot agree to the expanded key for the ALIAS category" because he believes "This is not a philosophical question, but rather one of correctly modeling the data domain. Furthermore, this particular question also has nothing to do with macromolecular data processing. DDLm is a language for writing *dictionaries*. Macromolecular data CIFs will not contain items from the ALIAS, DICTIONARY_XREF, or IDENTIFIER_SET categories, nor from any other DDLm category." This is remarkably strange coming from someone who was already pressing to expand the ALIAS category with the xref_code object, and who seems unaware the the only reason for any need to expand the key of ALIAS is to allow the denormalized form that he and David were originally asking for. It is even mare remarkably strange to hear the view that "this particular question has nothing to do with macromolecular data processing." The _only_ reason DDL2 exists at all was to allow for the creation of mmCIF. Without the needs of macromolecular crystallography and the efforts of John Westbrook to adapt CIF to the needs of that domain, we would only have to deal with the much simpler and flatter view of the world in DDL1 as represented by the very successful core CIF, and DDLm would have just been an exercise in adding methods to DDL1 without the need to manage complex related category structures. The only point of having the dictionaries and the various DDLs is to support the data domains, and if we cannot ground features in the needs of those domains we really should consider dropping those features. So, returning to actually getting work done -- if David needs similar features to support definition sets up at the ALIAS catgeory level then my proposal is a reasonable way to do both that and to support the more normaized form I will be using. If David is not going to be using such features for the core, we can leave out the ability to do the denormalized form for now. So, there seeming to be nothing left of substance in this discussion other than matters of taste, could we please choose one of three approaches to my introducing the definition sets: 1. As proposed; or 2. As proposed but without the ability to do the parent join and therefore without the need to expand the ALIAS key; or 3. As proposed, but with a BplusS_ prefix when I use it in the imgCIF dictionary and a modified version of the mmCIF dictionary to support imgCIF. I need to get to work on implementing this before Madrid. As entertaining as this discussion may be, it is time to make decisions and get real code implemented. Regards, Herbert P.S. "Data modeling is part and parcel of dictionary authorship, so there is every reason to expect that dictionary authors will be prepared to express their dictionaries in suitably normalized form, according to whatever presentation normalization rules ultimately are adopted for DDLm." is unrealistic for the macromolecular crystallographic community, which has vigorously rebelled against the strictures of DDL2 and seems likely to totally reject anything in DDLm that makes it any more complex and confusing. ===================================================== 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 Fri, 28 Jan 2011, Bollinger, John C wrote: > > On Thursday, January 27, 2011 5:53 PM, Herbert J. Bernstein > >> Here is the next pass with John W.'s name change and the category >> keys aligned. I would rather have followed the DDLm design philosophy >> of not requiring a parent category to know the innards of its children, >> but I would not want to hold up agreement on the basic idea over >> the detailed technical resolution of denormalization in DDLm. >> >> That being said, we will have to address the denormalization issue >> to fully support the realities of macromolecular data processing. > > I cannot agree to the expanded key for the ALIAS category. This is not > a philosophical question, but rather one of correctly modeling the data > domain. Furthermore, this particular question also has nothing to do > with macromolecular data processing. DDLm is a language for writing > *dictionaries*. Macromolecular data CIFs will not contain items from > the ALIAS, DICTIONARY_XREF, or IDENTIFIER_SET categories, nor from any > other DDLm category. > > DDLm has a different audience than do (other) dictionaries written using > it. Data modeling is part and parcel of dictionary authorship, so there > is every reason to expect that dictionary authors will be prepared to > express their dictionaries in suitably normalized form, according to > whatever presentation normalization rules ultimately are adopted for > DDLm. > > There is certainly still a normalization question to sort out, but even > if the denormalized presentation mode is ultimately disallowed, that > doesn't warrant denormalizing DDLm. It *might* warrant denormalizing > dictionaries expressed in DDLm terms, but that's a different story. > >> I shudder to point this out, but DDLm also seems to be missing >> the concept of implicit tags that is in DDL2 -- not a critical >> issue, but it probably should be addressed. > > To be clear: by an "implicit tag" you mean one defined with > > _item.mandatory_code implicit > > right? > >> Note that DDLm >> only addresses identifying tags that must be present in >> a given category so a strict reading would be that, as long >> as the value of a key is somehow known (e.g. by having >> an enumeration default), it does not have to be physically present >> in the data. > > I could accept something along those lines. From a data modeling > perspective, however, few possible values of "somehow known" are > suitable for a component of a category key. Having a defined default > value works, though. > > At least for non-key attributes, we have the possibility of using > methods to generate missing values. > > > 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 > _______________________________________________ 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] DDLm aliases (subject changed). .. .. .. .. .. .. . (Bollinger, John C)
- Re: [ddlm-group] Wrapping up the elide discussion (Herbert J. Bernstein)
- References:
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed). . (Bollinger, John C)
- Re: [ddlm-group] DDLm aliases (subject changed). . (David Brown)
- 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)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. . (Bollinger, John C)
- 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). .. .. .. . (John Westbrook)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Bollinger, John C)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. . (Bollinger, John C)
- Prev by Date: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .
- Next by Date: [ddlm-group] Wrapping up the elide discussion
- Prev by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .
- Next by thread: Re: [ddlm-group] Wrapping up the elide discussion
- Index(es):