Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .... .

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]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links