[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: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Sat, 22 Jan 2011 08:30:57 -0500 (EST)
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA54166D7D1EDC@SJMEMXMBS11.stjude.sjcrh.local>
- References: <AANLkTikZoEF_D+5-3+Eg4pbCx0cAu+SJvR-a_XkC3zK2@mail.gmail.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><8F77913624F7524AACD2A92EAF3BFA54166D7D1EDA@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1101211435160.67042@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EDC@SJMEMXMBS11.stjude.sjcrh.local>
The point of deprecation is to allow an overlap period of both uses. It saves people conversion stress and is normal in standards work. If your eally don't like normalizing, we can make the categories joinable. This is an old difference in taste in CIF, similar to the difference in approach for anisotropic temperature factor between coreCIF and mmCIF. I am more used to the nromalized approach. Inasmuch in this case the data files at dictionaries with save frames, it does not make a big practical difference is size, but the normalized approach does have the advantage of allowing a neat little separate concordance of tags versus groups, which when sorted by groups will give you complete tags lists by use (e.g. a list of all the DDL1 tags and then a Lists of all the DDL2 tags and then a list of all the DDm tags, ...) While joinability, the subcategory approach gives you the flatter style you prefer _and_ the normalized approach I prefer. We all have different needs in using DDLm. Might it not be appropriate to allow the standard to be flexible enough to accommodate a wider range of uses than it now does? Regards, Herbert ===================================================== 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, 21 Jan 2011, Bollinger, John C wrote: > > On Friday, January 21, 2011 2:48 PM, Herbert J. Bernstein wrote: > >> This can be made to work, > > I am pleased to hear it. > >> but for my uses, there are >> some minor issues: >> >> 1. I will be grouping the primary DDLm tag. With the >> _definition.xref_code removed, the primary DDLm tag >> will have to be aliased; and > > Ok. > >> 2. With multiple xref codes for a given tag (e.g. >> DDL2 and DDLm), it would be more appropriate to >> normalize and put the tags and xref codes into >> a sub-category, rather than to keep repeating the >> same tag. This would have the advantage of allowing >> the alias category to return to a non-compound key >> and would also allow all the grouping of >> tags in a dictionary to be gathered on a separate >> block, if desired. > > > The tags and xref could certainly be moved into a subcategory, but that cannot both reduce duplication and model the same data because (xref_code, definition_id) is a candidate key for whichever category you put it in. Or rather, it could reduce duplication if you pulled ALIAS_XREF up to dictionary level, gave it at least one non-key attribute, and had multiple definitions referring to the same rows, but it doesn't look like that's how Herbert proposes scoping things. > > >> For these reasons, I suggest >> >> 1. Leave _alias.dictionary_uri, but deprecate it in >> favor of: > > I'm missing something here. Why is it appropriate to issue a brand new standard that already contains a deprecated feature? > >> 2. Create an ALIAS_XREF category with the >> following tags, forming a composite key >> >> _alias_group.definition_id >> a tag identifier belonging to a group >> _alias_group.xref_code >> a code identifying a real or virtual dictionary >> or other logical groups of tags to which the tag >> belongs > > > Thus the repetition of definition_id would appear in ALIAS_XREF instead of in ALIAS, and ALIAS_XREF would have a compound key instead of ALIAS having one. And with this approach there is no way to model a defined item being aliased to some definitions of a particular data name but not to others. > > We could take this route as long as the last is of no concern. It is unlikely that we would ever encounter a problem in practice. From the perspective of a data modeling purist, however, it makes me uncomfortable. I could live with it, but to me it looks like the benefits don't justify the costs. > > >> The other tags that John proposes for David's uses >> actually fit better in terms of normalization in this sub- >> category, than on the top level, but that is a decision >> for David to make. I am happy either way. > > The other tags would be _alias.dictionary_version and _alias.deprecated. Herbert is right: if ALIAS_XREF were introduced per his proposal then these attributes would best go there. Personally, I would not be satisfied for ALIAS_XREF to be introduced but these two tags placed in ALIAS instead. I would most prefer, however, to not introduce ALIAS_XREF at all. > > > Regards, > > John > > 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]
- References:
- Re: [ddlm-group] Objectives of CIF2 syntax discussion (James Hester)
- 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)
- 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)
- Prev by Date: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .... .
- Next by Date: Re: [ddlm-group] DDLm aliases (subject changed)
- Prev by thread: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .... .
- Next by thread: Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .
- Index(es):