Discussion List Archives

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

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


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

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