[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 <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed). .. .
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Wed, 26 Jan 2011 14:29:30 -0600
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <email@example.com>
- References: <AANLkTi=ATdNovWFiecEwDrbtMdTwZ7guvYuBCGrdnbfirstname.lastname@example.org><8F77913624F7524AACD2A92EAF3BFA54166D7D1EDE@SJMEMXMBS11.stjude.sjcrh.local ><4D404DAA.email@example.com> <firstname.lastname@example.org>
On Wednesday, January 26, 2011 11:34 AM, Herbert J. Bernstein wrote: >OK, so we need to pick a non-conflicting name for the tag that gives >the unifying identifier that will satisfy John W.'s concerns and >James's concerns, but that will not preclude John B. and David's >preference to allow the presentation to be unified with the >xref_code. How about "ensemble_id". This is a distinct concept >from the identifier of the dictionary itself, because one >dictionary can contain multiple ensembles and one ensemble >can span multiple dictionaries. Ok, that makes sense. > Here is my modified version of John B.' proposal: I think we are close here. There are a couple of additions I would like to see to Herbert's version of the proposal, however. Rather than quote the whole thing, I include it verbatim below, with my additions at the bottom and additional commentary following: 1) Deprecate _alias.dictionary_uri. 2) Add as a of subcategory of alias, alias_ensemble with the following tags: _alias_ensemble.definition_id a tag identifier belonging to an ensemble _alias_ensemble.ensemble_id a code identifying an ensemble of tags to which the tag belongs _alias_ensemble.xref_code All of these tags are members of the composite key of the sub category, so that it is possible to have a physical dictionary the same tag in multiple ensembles, or to break out this subcategory as a master index running over all tags alias giving both the physical dictionaries from which they are taken and and the ensembles to which they belong. 3) Add tag _alias.xref_code to the alias category _alias.xref_code specifies the physical dictionary from which the preferred definition of the tag alias has been taken, or is null if the current dictionary is the primary definer of the tag alias. This tag is the parent of _alias_ensemble.xref_code. There are some technical issues on use of the join mechanism, and which tags are keys, but they can be resolved if the flattened version is truly desired. 4) Add tag: _alias.deprecated: Specifies whether use of the alias is deprecated. _type.purpose State _type.container Single _type.contents YesorNo 5) Modify the definition of _dictionary_xref.format by changing its _type.contents attribute to "Code". 6) Deprecate _definition.xref_code (its purpose will be served via the alias mechanism) ---- JCB Adds: ---- 7) In the ALIAS category, replace attribute _category_key.generic with: _category_key.primitive [ '_alias.xref_code' '_alias.definition_id' ] This is still appropriate, inasmuch data names are not guaranteed to be globally unique across all dictionaries. For that matter, if it were inappropriate here then there would be no need for _alias_ensemble.xref_code, as no _alias.definition_id could be associated with more than one xref_code, and that one would be specified by _alias.xref_code. 8) 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 _definition.xref_code or _alias.xref_code attribute." I still think the concept of a logical dictionary is a sound and useful one, even alongside Herbert's _alias_ensemble idea. This wording change accommodates the concept without requiring any new attributes. Be it known, however, that if we agree to this then corresponding slight adjustments may be needed to the definitions of some of the other existing attributes in the DICTIONARY_XREF category. I think those can be discussed later, when and if the time comes. Naturally, if _definition.xref_code were removed instead of deprecated, then this definition should not refer to it. ======== I can live with deprecating _definition.xref_code and _alias.definition_uri, though my preference is still to remove them. Inasmuch as, to my knowledge, DDLm has so far been published and distributed only in draft / for-comments form, it will indeed be a new standard when it eventually is accepted by COMCIFS. Those developers and dictionary authors already working with the draft should be doing so with the understanding that it is subject to change. Also, I suspect we will consider further possibly-disruptive changes before we are done, and I am loathe to set a precedent that compatibility with the draft is a supremely compelling concern. Nevertheless, deprecation vs. removal of these attributes is too small a detail to be hung up over. When we are ready to vote on the overall proposal, I would prefer to vote separately on that question -- separately for each attribute, in fact. In the mean time, let's proceed. Question to consider: should there be a means in the DDL to identify the significance of a particular ensemble, at least for the benefit of humans? That might take a form as simple as a dictionary-scoped ENSEMBLE category, with attributes _ensemble.ensemble_id and _ensemble.description. I note also that Herbert did not bring forward my proposed _alias.dictionary_version attribute into his version of the proposal, nor have I added it back to this version. I see only limited potential use for it, and I am not prepared to argue for it. Others of you may think differently, however. 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 email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] DDLm aliases (subject changed). .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed). . (David Brown)
- 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). .. .