[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] A rationalisation of DDLm
- To: ddlm-group <firstname.lastname@example.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 <email@example.com> on behalf of James Hester <firstname.lastname@example.org>
Sent: Thursday, October 15, 2020 11:56 PM
To: ddlm-group <email@example.com>
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):
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 firstname.lastname@example.org http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- [ddlm-group] A rationalisation of DDLm (James Hester)