[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: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Fri, 21 Jan 2011 12:37:26 -0600
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <4D399EBE.7010003@mcmaster.ca>
- 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><4D399EBE.7010003@mcmaster.ca>
On Friday, January 21, 2011 8:57 AM, David Brown wrote: [...] > 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? Indeed, here is the formal proposal I promised, at the end of which is an example: Proposal: Extended Alias Attributes =================================== Introduction / Rationale ------------------------ This proposal aims primarily to provide all the ALIAS attributes that several members of this group have recently agreed are needed (at least in principle). However, attributes that are properties of dictionaries rather than of individual data names are normalized out of the ALIAS category and into the DICTIONARY_XREF category. The description of the DICTIONARY_XREF category is slightly modified to be explicitly consistent with this usage and with the concept of referencing logical dictionaries that have no independent physical manifestation. Proposed Actions ---------------- 1) Replace _alias.dictionary_uri with: _alias.xref_code: Specifies a code that identifies the logical or physical dictionary in which the alias is defined. This serves to categorize and fully identify the alias. _type.purpose Identify _type.container Single _type.contents Code 2) Add these attributes: _alias.dictionary_version: Specifies the first version of the dictionary identified by _alias.xref_code that defines the alias. _type.purpose Identify _type.container Single _type.contents Code _alias.deprecated: Specifies whether use of the alias is deprecated. _type.purpose State _type.container Single _type.contents YesorNo 3) In the ALIAS category, replace attribute _category_key.generic with: _category_key.primitive [ '_alias.xref_code' '_alias.definition_id' ] 4) Modify the definition of _dictionary_xref.format by changing its _type.contents attribute to "Code". 5) Remove _definition.xref_code (its purpose will be served via the alias mechanism) 6) Modify the description of the DICTIONARY_XREF category to: "The DICTIONARY_XREF attributes identify and describe logical or physical dictionaries to which items in the current dictionary are cross-referenced using the _alias.xref_code attribute." Comments -------- Here is the resulting correspondence between DDLm data names and David's list of alias attributes: "The tag" -> _alias.definition_id (unchanged by this proposal) "the dictionary in which it appears" -> a row/instance of DICTIONARY_XREF, identified by _alias.xref_code (added by this proposal) "the version of this dictionary" -> _alias.dictionary_version (added by this proposal) "the DDL in which the dictionary is written" -> _dictionary_xref.format (type attributes modified by this proposal) "a flag to indicate whether the dataname is deprecated" -> _alias.deprecated (added by this proposal) "a pointer to where the named dictionary can be found" -> _dictionary_xref.uri (unchanged by this proposal) Although this proposal chooses the existing DICTIONARY_XREF category as the normalized location for alias attributes that depend only on dictionary, it would also be possible to instead introduce a new, parallel category for this purpose. If the _definition.xref_code is merged into the alias feature as I propose, however, then DICTIONARY_XREF no longer has any other purpose. On the other hand, it is not essential to drop _definition.xref_code. As in my previous proposal concerning _alias.dictionary_uri, the key for the ALIAS category is expended to a compound one containing the dictionary identifier and the data name. This allows one data name's appearances in multiple dictionaries all to be aliased to the same defined name, without implying that all possible definitions of the name are aliased. Essentially, it scopes the alias to the dictionary in which it appears. DDL2's similar ITEM_ALIASES category is keyed not only to name and dictionary identifier, but also to dictionary version; the last seems needless, even in DDL2, because we can assume that once introduced into a dictionary, data names are not removed or incompatibly changed. The type attributes of _dictionary.xref_format are changed so that this attribute represents a computer-interpretable code describing at least the DDL compliance level of the referenced dictionary. Allowed values could be defined so that they encompass other information as well, very much like the proposed tag_style might do. It might be desirable for DDLm to enumerate allowed values for this attribute, but it would be more flexible to have an external register, such as Herbert proposed for tag_style. I presently take no position on the best course in that regard, but this proposal does not provide enumerated values. This proposal is offered for comment. Although I would be willing to have a vote on it as it stands, it could likely be improved. I am open to changing some of the details if that will contribute to broader acceptance. Example ------- loop_ _dictionary_xref.code _dictionary_xref.date _dictionary_xref.format _dictionary_xref.name _dictionary_xref.uri core '2010-Jun-29' DDL1 cif_core.dic ftp://ftp.iucr.org/pub/cif_core.dic mmcif '2005-Jun-27' DDL2 mmcif_std.dic ftp://ftp.iucr.org/pub/cif_mm.dic [...] save_diffrn_standards.decay_percent _definition.id '_diffrn_standards.decay_percent' [...] loop_ _alias.xref_code _alias.definition_id _alias.dictionary_version _alias.deprecated core '_diffrn_standards_decay_%' . no mmcif '_diffrn_standards.decay_%' . no save_ 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
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .. . (Herbert J. Bernstein)
- 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)
- Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .. . (David Brown)
- 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):