Discussion List Archives

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

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

Dear Colleagues,

   I am sorry to hear that John Bollinger "cannot agree to the expanded key 
for the ALIAS category" because he believes "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."

   This is remarkably strange coming from someone who was already pressing 
to expand the ALIAS category with the xref_code object, and who seems 
unaware the the only reason for any need to expand the key of ALIAS is to 
allow the denormalized form that he and David were originally asking for.

   It is even mare remarkably strange to hear the view that "this 
particular question has nothing to do with macromolecular data 
processing."  The _only_ reason DDL2 exists at all was to allow for the 
creation of mmCIF.  Without the needs of macromolecular crystallography 
and the efforts of John Westbrook to adapt CIF to the needs of that 
domain, we would only have to deal with the much simpler and flatter view 
of the world in DDL1 as represented by the very successful core CIF, and 
DDLm would have just been an exercise in adding methods to DDL1 without 
the need to manage complex related category structures.

   The only point of having the dictionaries and the various DDLs is to 
support the data domains, and if we cannot ground features in the needs of 
those domains we really should consider dropping those features.

   So, returning to actually getting work done -- if David needs similar 
features to support definition sets up at the ALIAS catgeory level then my 
proposal is a reasonable way to do both that and to support the more 
normaized form I will be using. If David is not going to be using such 
features for the core, we can leave out the ability to do the denormalized 
form for now.

   So, there seeming to be nothing left of substance in this discussion 
other than matters of taste, could we please choose one of three 
approaches to my introducing the definition sets:

   1.  As proposed; or
   2.  As proposed but without the ability to do the parent join
and therefore without the need to expand the ALIAS key; or
   3.  As proposed, but with a BplusS_ prefix when I use it
in the imgCIF dictionary and a modified version of the mmCIF
dictionary to support imgCIF.

I need to get to work on implementing this before Madrid.  As entertaining 
as this discussion may be, it is time to make decisions and get real code 
implemented.

Regards,
   Herbert

P.S. "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." is unrealistic for the macromolecular crystallographic community, 
which has vigorously rebelled against the strictures of DDL2 and seems 
likely to totally reject anything in DDLm that makes it any more complex 
and confusing.


=====================================================
  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, 28 Jan 2011, Bollinger, John C wrote:

>
> 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
>
_______________________________________________
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