Discussion List Archives

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

Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .


On Thursday, January 27, 2011 5:53 PM, Herbert J. Bernstein

>Here is the next pass with John W.'s name change and the category
>keys aligned.  I would rather have followed the DDLm design philosophy
>of not requiring a parent category to know the innards of its children,
>but I would not want to hold up agreement on the basic idea over
>the detailed technical resolution of denormalization in DDLm.
>
>That being said, we will have to address the denormalization issue
>to fully support the realities of macromolecular data processing.

I cannot agree to the expanded key for the ALIAS category.  This is not a philosophical question, but rather one of correctly modeling the data domain.  Furthermore, this particular question also has nothing to do with macromolecular data processing.  DDLm is a language for writing *dictionaries*.  Macromolecular data CIFs will not contain items from the ALIAS, DICTIONARY_XREF, or IDENTIFIER_SET categories, nor from any other DDLm category.

DDLm has a different audience than do (other) dictionaries written using it.  Data modeling is part and parcel of dictionary authorship, so there is every reason to expect that dictionary authors will be prepared to express their dictionaries in suitably normalized form, according to whatever presentation normalization rules ultimately are adopted for DDLm.

There is certainly still a normalization question to sort out, but even if the denormalized presentation mode is ultimately disallowed, that doesn't warrant denormalizing DDLm.  It *might* warrant denormalizing dictionaries expressed in DDLm terms, but that's a different story.

>I shudder to point this out, but DDLm also seems to be missing
>the concept of implicit tags that is in DDL2 -- not a critical
>issue, but it probably should be addressed.

To be clear: by an "implicit tag" you mean one defined with

  _item.mandatory_code implicit

right?

>   Note that DDLm
>only addresses identifying tags that must be present in
>a given category so a strict reading would be that, as long
>as the value of a key is somehow known (e.g. by having
>an enumeration default), it does not have to be physically present
>in the data.

I could accept something along those lines.  From a data modeling perspective, however, few possible values of "somehow known" are suitable for a component of a category key.  Having a defined default value works, though.

At least for non-key attributes, we have the possibility of using methods to generate missing values.


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

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

ICSU 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.