Discussion List Archives

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

Re: [ddlm-group] A rationalisation of DDLm

  • To: ddlm-group <ddlm-group@iucr.org>
  • Subject: Re: [ddlm-group] A rationalisation of DDLm
  • From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
  • Date: Fri, 16 Oct 2020 14:40:25 +0000
  • Accept-Language: en-US
  • ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=passsmtp.mailfrom=stjude.org; dmarc=pass action=none header.from=stjude.org;dkim=pass header.d=stjude.org; arc=none
  • ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=8y/7nABBHwGMc1UhWGqcxeljoOXKqEMS+fG4t+uiU1w=;b=WqjO0jVVDC3Zd3VcfuaAN7+ZXcDio0sgzmC6Ms6pmpOs1HMe38evUebrFHeMeX+a8lYZvFhSHBKQyIb9gJb1MALxC1jslVE0sH9IwPEQlvFShLprmHjKIsqeJda8fXkNrPuhhqadRcu7NOcNZvy6fNDT0kXpO9pQypLD0hdpY/0bqVWoHGjbJXeGgRwl2QfFM43AnqrBHfB4fgwvTdhObaHYfmvNW3Kq0FY38mvFIbXW+B0Ju6zDuIpHqUbTs8HCfvOKWhlMkYMhCN3B9vf86gwqz/stQMrB5itXMxCLxHxr/0SSG1a1SY5Xoaj3GDN6hRQyETzlKHHhieO2LOPjTQ==
  • ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;b=M4OPpW5gE8fLS8WVgkqWPjftNIwTKHAaTBDDmgUvPN7hf6no/HmrTL9Xguu4DRm0uAVOHBouI4Ihg62Rb2XEeyyv/sx59o2HKpTKKw/lRQya+yr754mgmCT/iDa7aDiSEMJUTJrpvqxzOvOfnS1wf4FSaRuyMqc0Q7AovdeuimyZkMO5+C8LsnmmbaaoU4YVV0y+UYfF0QTfLm1yqLKfOihBbFShguGKffUGr7KEL1vz7beDlNkagrEBMlYCZat6/nhn+MrU7q4Jh4GXIaANMgpM5I34+uL01e2P/i9aCbIeaSq1hEre6oYdxnUGX0r9nBco82qSlKXHexl9DmiHsQ==
  • In-Reply-To: <CAM+dB2d=ZESEs7ZO-fuA=2PQRPqH01dVVbyuO5HGCBP2zX07=Q@mail.gmail.com>
  • IronPort-SDR: v/dCuYZOPURJCWpRKMevN1Ho7RqHY/NCZI83qBidXrUamcYS4YxJWJ2u4XZ6NlEPpClSg9u5UwWO/6ihpyQ2sB+ZWiZd4XSBKJX0RRign+diIZVOLnwUe5tftt+FXSUC0IUUQsnSThhPu4DWwBMmUWNxofEkfVqEFVTh6OCeAWnyOZgrAyu+YrQ+qxsbCNEqo4YIy+D+8y1wXn7k/YpS+5tjzEtVqAOQdMmPqBMpwnujYzWKji5OT4J5pEJgxdiAd7t51bPfQiPrgnkzpixXSjZ8qxL+3Tkd6xR336JlIn0=
  • References: <CAM+dB2d=ZESEs7ZO-fuA=2PQRPqH01dVVbyuO5HGCBP2zX07=Q@mail.gmail.com>
Dear James and group,

To be sure I understand the nature of these changes, I ask you to confirm some details of my interpretation of the proposed changes:

The LOOP category: this is being removed because the only attribute it contains is _loop.level, which is unused because we do not avail ourselves of STAR nested loops in CIF, we do not anticipate doing so in the future, and we do not .  This has nothing directly to do with whether items are presented in a (single-level) looped list.  We still have Array and Table data types available for use in place of nested loops if we should discover a need for that.

Save frames: *text* elements of various item definitions are changed to avoid referencing save frames, so as to focus on semantics rather than representation.  The CIF-format representation of DDLm still uses save frames extensively.

Ref-loops: these are defined but not used in the present version of DDLm, they are unused in any of our current DDLm dictionaries, and (it is asserted) we do not anticipate a need or desire for them in the future, neither in DDLm itself nor in other dictionaries written in DDLm.  This is in part because we have backed away from (but not completely abandoned) the ref-table construct in terms of which ref-loops are defined, and in part because we want DDLm definitions to focus on semantics rather than representation.

List and Array data types: List is presently distinguished from Array in that the type of each element of a List is specified independently of the others, and can be any type, including complex ones, whereas all elements of an Array have the same type, which must be a numerical one.  These two are replaced with a generalized Array type whose elements are all the same type, but which type can be anything.  There is still Table if we want to define a complex type whose components have different types.

Supposing that all of the above are confirmed, I have some questions:

1. DDLm uses save frames as an organizational structure, or at least its CIF representation does.  Do we really come away cleanly from removing references to save frames without replacing them with a different, more generic concept?

2. With regard to synthetic keys previously specified as heterogeneous Lists: if our position is to be that synthetic keys should be opaque, then why are we defining any at all?  The multi-attribute natural keys we also have (right?) should be sufficient for defining the wanted identity, uniqueness, and relationship details for a category.  I am inclined to suppose that the single-attribute composed keys were intended to serve as an implementation aid, and I think we're throwing that out if we don't specify details of how those keys should be constructed.



John C. Bollinger, Ph.D., RHCSA
Computing and X-ray Scientist
Department of Structural Biology
St. Jude Children's Research Hospital

From: ddlm-group <ddlm-group-bounces@iucr.org> on behalf of James Hester <jamesrhester@gmail.com>
Sent: Thursday, October 15, 2020 11:56 PM
To: ddlm-group <ddlm-group@iucr.org>
Subject: [ddlm-group] A rationalisation of DDLm
Caution: External Sender

Dear DDLm group,

In preparation for setting things in stone (famous last words) for Vol G second edition I have made some edits to the DDLm specification file ddl.dic to remove unused or obsolete tags. You can see the full changes in the pull request at https://github.com/COMCIFS/cif_core/pull/188 . In summary (from the pull request):

A number of items are obsolete in DDLm:

  1. Save frames. DDLm aims to be format-agnostic. All references to save frames and ref-loops have been removed, except for import statements for which a save frame reference is currently unavoidable
  2. LOOP category. No official dictionary (DDL1/2/m) has ever used more than 1 level of looping, so there is no need for such attributes, which are also CIF-format-specific.
  3. Complex data types. Data types of the form 'Type1|Type2' to indicate that an item could have more than one type are not used, are complex to implement, and so have been removed. Data types of the form List(Type2,Type3,...) to indicate List objects where each element is composed of a tuple of values, each of potentially different types, have been removed. These were almost exclusively used for synthetic keys, which should be opaque. Any other current use can be changed to Array type.
  4. Allow arrays of strings. The current DDLm dictionary restricts Arrays to numeric values for no apparent reason.

If these changes are considered significant enough, we should change the major version number to 4.0. Please comment on this.

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
ddlm-group mailing list

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.