[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .. .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .. .
- From: David Brown <idbrown@mcmaster.ca>
- Date: Fri, 21 Jan 2011 09:57:02 -0500
- In-Reply-To: <alpine.BSF.2.00.1101202038370.23849@epsilon.pair.com>
- References: <AANLkTikZoEF_D+5-3+Eg4pbCx0cAu+SJvR-a_XkC3zK2@mail.gmail.com> <alpine.BSF.2.00.1101190833560.91751@epsilon.pair.com> <8F77913624F7524AACD2A92EAF3BFA54166D7D1ECE@SJMEMXMBS11.stjude.sjcrh.local> <alpine.BSF.2.00.1101191042290.42382@epsilon.pair.com> <4D371BE7.3050501@mcmaster.ca> <alpine.BSF.2.00.1101191234221.42382@epsilon.pair.com> <8F77913624F7524AACD2A92EAF3BFA54166D7D1ED0@SJMEMXMBS11.stjude.sjcrh.local> <alpine.BSF.2.00.1101191632410.65107@epsilon.pair.com> <8F77913624F7524AACD2A92EAF3BFA54166D7D1ED1@SJMEMXMBS11.stjude.sjcrh.local> <alpine.BSF.2.00.1101191855500.30768@epsilon.pair.com> <AANLkTi=xn2ntdNTvdTBKQQTsJhCQFbKcxceJ1C_u1oOf@mail.gmail.com> <alpine.BSF.2.00.1101200440460.66943@epsilon.pair.com> <8F77913624F7524AACD2A92EAF3BFA54166D7D1ED6@SJMEMXMBS11.stjude.sjcrh.local> <alpine.BSF.2.00.1101201418310.85482@epsilon.pair.com> <8F77913624F7524AACD2A92EAF3BFA54166D7D1ED8@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1101202038370.23849@epsilon.pair.com>
Dear Coleagues, Herbert J. Bernstein wrote: Dear John B. You seem to have agreed to everything except calling the necessary addition tag a tag_style. You want to call it a virtual_dictionary_id. If the others agree with you on that naming change, I can live with that. That leaves the only point of disagreement your idea of overloading that concept onto the dictionary_uri. I object to that as being pointlessly confusing, but if a majority prefers to overload a virtual_dictionary_id which is simply a text string onto the URI type, I'll accept that. I need the functionality. It everybody else want to call the relevant tag by some other name, I can cope, but I really want a recorded vote on this. I am hoping a majority will prefer clarity. So we now have two small points to vote on: 1. Should the new tag be _alias.tag_style or _alias.virtual_dictionary_id 2. Instead of one of the above two tags, such the _alias.dictionary_uri be overloaded with the non-URI use of the above two tags? Regards, Herbert I would like to know exactly what I am voting on. There seems to be general agreement on the information that is needed for an alias, the only dispute is the format in which it will appear. If the various pieces of information I listed each had their own item, this would be agreeable and we could delegate someone to come up with the requisit DDLm save frames, but if this information is to be included, explicitly or implicitly, in a smaller number of items, then I would like to see the definitions and descriptions so that I could understand how each piece of information would be retrieved. John B, can you supply us with an example of what your normalized item(s) would look like? David ===================================================== 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 Thu, 20 Jan 2011, Bollinger, John C wrote:On Thursday, January 20, 2011 2:10 PM, Herbert J. Bernstein wrote:The existing alias mechanism has been used in the past to carry actual information about tags from entry to entry and dictionary to dictionary, allowing one side or the other of such a definition to be less complete than it might otherwise have been, but also creating the sort of conflicts noted.That seems an excellent reason for DDL2 software and dictionaries to not have used aliases in such a manner. I see nothing in their DDL2 definition that that suggests such use would be appropriate, but at this point that's moot. It sounds like you might join me in asserting that the move up to DDLm provides an excellent opportunity to make a clean break from that practice, consistent with the alias usage for which I have been arguing.Any software aside, it is certainly confusing to users of the actual dictionaries to have such conflicting information around. Just think of this as going back to Codd and trying to make sure we only have to update our data in one place and not several. It reduces the chance of error to gather the information about a group of tags with the same meaning, but different names in one place.I wholly favor that proposition, and I have never argued against it. I'm having trouble determining why you keep asserting otherwise. Please cite some comments of mine that you have taken as advocating something else, so that I can set the record straight.As David and John W. note, there are important differences in data file construction rules, dare I say "styles" for DDL1, DDL2 and DDLm dictionary-based data files.Acknowledged and agreed. You have previously remarked, however, that the proposed style tag was intended to serve a much more generic purpose than identifying the DDL compliance of the dictionary from which an alias was drawn. If you are now interested in limiting the concept to DDL compliance then I think we can come to an agreement, perhaps based on the inclusion of DDL compliance in David's list of needed alias attributes.However, once we have a tag-by-tag style identification so we get the right tags, there is also no reason we cannot give our validators and writers knowledge of which of the several over-all styles we are trying to conform to, even the ever troubling difference in approach as to what can and cannot be looped, and whether the use of the period for category identification is mandatory (DDL2), optional (DDLm) or not normally used (DDL1)You have agreed, as I understood you, that DDL compliance level is not sufficient for most purposes in this area. That is especially the case for writers. For most purposes one really wants to specify compliance with a specific logical *dictionary*. Such dictionaries need not have a physical representation independent of the DDLm dictionary that refers to them, and with David's separation of access URI from dictionary identifier, those that do not have an independent representation can easily be recognized. I'm still waiting for a use case for style_tag that is not well addressed by using (logical) dictionaries as the unit of alias grouping.David has made a nice case for even more precise detail in the alias category. Rather than trying to overload the URI or depend on other external resources, I urge that we provide the details we need in the alias category in the alias catgeory. Extending the key is an interesting issue. We may need to add the implicit concept from DDL2 to DDLm or to make a subcategory.As I wrote separately, I agree with David about the additional data that should be associated with aliases. And once more: I do not support, favor, claim, assert, promote, or in any other sense agree with DDLm dictionaries relying on external resources for any part of their normative content. As long as we're throwing around references to Codd, however, I do favor normalizing some of the dictionary details that would otherwise be duplicated for many aliases. I wrote about this in my response to David. [...]I would suggest we give David the extra alias category tags he is asking for as well as my tag_style identifier, with reasonable default assumptions when they are not used.I concur that we should provide the additional alias attributes, or, as I prefer, a more normalized equivalent. I still see no reason for tag_style.If I fail in what David calls my "noble" goal in DDLm-ing the imgCIF dictionary and he fails in whatever use he makes of the extended alias catgeory, what will it have cost those who choose not to use these features in their dictionaries.I have already answered this. At minimum, it will cost everybody incrementally longer software release cycles and incrementally more risk of bugs in the software they rely upon.If we succeed on the other hand, you will have a few extra useful tools you might decide to use in the future.How useful a tool tag_style would be is a key issue in dispute, and an essential one for the cost / benefit analysis that should inform our decision about whether to include it. I do see value in categorizing aliases. I currently see almost zero practical distinction between calling the grouping unit a "style" and calling it a "dictionary", however, and I see no benefit to providing redundant features. Regards, 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 |
begin:vcard fn:I.David Brown n:Brown;I.David org:McMaster University;Brockhouse Institute for Materials Research adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada email;internet:idbrown@mcmaster.ca title:Professor Emeritus tel;work:+905 525 9140 x 24710 tel;fax:+905 521 2773 version:2.1 end:vcard
_______________________________________________ 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] Objectives of CIF2 syntax discussion. .. .. .. .. . (Bollinger, John C)
- References:
- Re: [ddlm-group] Objectives of CIF2 syntax discussion (James Hester)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (Bollinger, John C)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (David Brown)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. . (Bollinger, John C)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. . (Bollinger, John C)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. . (James Hester)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. . (Bollinger, John C)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .. . (Bollinger, John C)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .. . (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .... .
- Next by Date: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .... .
- Prev by thread: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .... .
- Next by thread: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .. .
- Index(es):