[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: Tue, 1 Feb 2011 18:13:25 -0500
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA54166D7D1EF5@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]> <4D46EC21.40606@mcmaster.ca><alpine.BSF.2.00.1101311332260.18029@epsilon.pair.com><4D4828CA.90808@mcmaster.ca><alpine.BSF.2.00.1102011042080.28409@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EF5@SJMEMXMBS11.stjude.sjcrh.local>
Dear Colleagues, >If it affects the logic that my programs must perform to correctly >validate a CIF, including a dictionary CIF, then it is a technical >issue. If I can make a valid technical argument favoring one >position, then it is a technical issue. It becomes a matter of >taste only if we make a technical decision that it should be so. >Herbert clearly prefers that we make such a decision, but he is not >empowered to declare it made. I have been trying to find out what the consensus decision is, but I not only can declare a decision to be made with respect to my own work, I have to do so. Whether the result then is part of CIF or part of something else (call it "yaxdf") is then a matter for future consideration. I have a new grant I need to get moving on. I would rather that the work I am doing be well-coordinated with CIF. I have been trying. Unfortunately, we don't seem to be making progress. So, my fallback is to simply do the work I need to do with prefixed tags and show you the results in Madrid. I hope you will like the results and adopt them for CIF. Perhaps you won't and will decide to do something different for CIF. Perhaps the results will be a disaster and I will try something different myself, but I'll never know if this is a good idea, a bad idea or something in between unless until and unless I work it through with software and examples. I'll post the prefixed-tag version that I will be starting with to this list sometime soon for your information. Regards, Herbert At 4:56 PM -0600 2/1/11, Bollinger, John C wrote: >On Tuesday, February 01, 2011 9:55 AM, Herbert J. Bernstein wrote: >> There is no "point" in denormalizing for presentaion purposes. >>The normalized and denormailzed presentations carry the same >>information. > >As long as this is this is merely a presentation issue, that's true. >When the data model is denormalized in order to permit a >denormalized presentation, it is no longer true. It is to the >latter that I object. > >> This really is just a matter of taste. John B. is wrong when he >>tries to settle it as a technical issue. > >If it affects the logic that my programs must perform to correctly >validate a CIF, including a dictionary CIF, then it is a technical >issue. If I can make a valid technical argument favoring one >position, then it is a technical issue. It becomes a matter of >taste only if we make a technical decision that it should be so. >Herbert clearly prefers that we make such a decision, but he is not >empowered to declare it made. > >> If you, in working with the core want the alias information in >>denormailized form, that is fine. If you, in working with the core >>are more comfortable with the alias information normalized, that is >>fine. We don't need a uniform answer for all dictionaries. It is >>easy to go back and forth and to combine information from both >>forms. >> >> We already have multiple flavors of dictionaries because we are >>all different people and we have different work to do. >The important issue is not that the dictionary styles be the same >but that they contain the necessary information in ways that allow >them to be combined in a consistent, interoperable manner. > >Inasmuch as this is about the appropriate requirements for >presenting parent and child categories in joined form, I find the >argument somewhat persuasive. However, I'm still confused by the >emphasis that Herbert is placing on this issue. If the language >provides an adequate way to do the job, then why is it of such >importance that it also provide alternatives? Doing so makes the >language more difficult to process, which might overall outweigh any >benefit it provides to dictionary authors. I'm not sure where the >balance lies, but I don't think anyone is well served by >insufficiently considered action. > > >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 -- ===================================================== 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
Reply to: [list | sender only]
- 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). .. .. .. .. . (David Brown)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Herbert J. Bernstein)
- 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)
- 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):