[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] (no subject)
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] (no subject)
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Thu, 16 Jun 2016 16:19:51 +0000
- Accept-Language: en-US
- authentication-results: spf=none (sender IP is )smtp.mailfrom=John.Bollinger@STJUDE.ORG;
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SJCRH.onmicrosoft.com; s=selector1-stjude-org;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;bh=MySNrJocDuedskn85x43h500IQvvsDDoaxptlvYtHOs=;b=J1jzgpL01cQasI2woElLQvvGIXzfP4T4dWVxeO4G4fDiQw2rdhFmZFS6e/veagVslpOZdPMCOpghmgkk9gyEBbz8D8nrzkEugUKzMJLG4HfU353lFPp69MiO4Ek7nuwkm9x+IxooKu16+z8XMJfQ8lry9L0vWoxb5caxmo/+gQ8=
- In-Reply-To: <CAM+dB2fdHvdZ-UUMuy6rbGXWvY567b769nO4R4c35kLvAYXyJg@mail.gmail.com>
- References: <CAM+dB2fdHvdZ-UUMuy6rbGXWvY567b769nO4R4c35kLvAYXyJg@mail.gmail.com>
- spamdiagnosticmetadata: NSPM
- spamdiagnosticoutput: 1:99
Dear James and Colleagues, I’m going to respond to several aspects of this discussion in separate messages to (I hope) make the individual threads easier to follow. This first response is directed to these comments of James's: > I don't actually think default values for keys are necessary until multiple-packet loops are set up. Also, I would need to see a clear formulation of how you would propose to convert Set to Loop in order to comment sensibly in light of all of the other constraints we are operating under. I do appreciate that I am favouring a particular application by giving 'Set' categories such significance. Apart from being bound to do this to keep compatibility with legacy applications, there are non-trivial efficiencies available by being able to make certain values 'global', and the DDL1, DDL2 entry.id, and 'Set' behaviour provides a neat way to do this. With respect to efficiency, it is not clear to me how a Set with a category key would be any more efficient than a Loop, and it is also not clear whether any efficiency gain that did accrue would be sufficient to justify the required change to DDLm. I would be interested in hearing a fuller explanation. In any case, whether it is classified as a Set or a Loop, if a category has a category key, then surely it is necessary for every instance / packet / row of that category to have a value for that key. If one does not want to oblige data files to provide an *explicit* value for the category key, then the only alternative is to permit them to rely on a default value. If we are going to do that -- as we must do to avoid changes such as we are discussing from invalidating existing data files -- then I don't see what is gained by making a special rule allowing the key to be defaulted in certain cases, as opposed to simply defining default values for keys where that is warranted, so that existing dictionary semantics provide for data files that present only one packet to omit the key. In particular, that does not interfere with requiring the key to be presented explicitly when multiple packets are presented, for if a file that presents multiple packets allows them to all take the key's default value then the resulting duplicate keys make the file invalid. Let's consider the SPACE_GROUP category, since it sparked this whole discussion. I append a cut at what I think we should do with it (only frames containing modifications are presented); I think I have marked all the changes and additions within via CIF comments. I rarely wrangle dictionaries, so I apologize for any errors I have committed. The key defaulting presented within formalizes how, when, and why SPACE_GROUP's category key and the associated child key in SPACE_GROUP_SYMOP can be omitted from data files. To the best of my knowledge, nothing within relies on any DDLm changes. Note, by the way, that I think the particular changes presented, or something very like them, are needed regardless of what we choose for the general case, because the DDL1 core and mmCIF are already structured this way. Best regards, John ---- save_SPACE_GROUP _definition.id SPACE_GROUP _definition.scope Category _definition.class Loop # CHANGED _definition.update 2016-06-16 # CHANGED _description.text ; The CATEGORY of data items used to specify space group information about the crystal used in the diffraction measurements. ; _name.category_id EXPTL _name.object_id SPACE_GROUP #### # ADDED: _category.key_id '_space_group.key' loop_ _category_key.name '_space_group.id' # ... end of additions #### save_ save__space_group.id _definition.id '_space_group.id' loop_ _alias.definition_id '_space_group.id' '_space_group_id' _definition.update 2016-06-16 # CHANGED _description.text ; Code identifying a space group if multiple symmetries. See _exptl_crystals.key. ; _name.category_id space_group _name.object_id id _type.purpose Encode _type.source Assigned _type.container Single _type.contents Code # Take note of this (ADDED): _enumeration.default '' save_ #### # ADDED: save__space_group.key _definition.id '_space_group.key' loop_ _alias.definition_id '_space_group.key' _definition.update 2016-06-16 _description.text ; Value is a unique key to a set of space_group items in a looped list. ; _name.category_id space_group _name.object_id key _type.purpose Key _type.source Related _type.container Single _type.contents Code loop_ _method.purpose _method.expression Evaluation '_space_group.key = _space_group.id' save_ # ... end of additions #### save_SPACE_GROUP_SYMOP _definition.id SPACE_GROUP_SYMOP _definition.scope Category _definition.class Loop _definition.update 2013-09-08 _description.text ; The CATEGORY of data items used to describe symmetry equivalent sites in the crystal unit cell. ; _name.category_id SPACE_GROUP _name.object_id SPACE_GROUP_SYMOP _category.key_id '_space_group_symop.key' loop_ _category_key.name '_space_group_symop.sg_id' # ADDED '_space_group_symop.id' save_ save__space_group_symop.key _definition.id '_space_group_symop.key' loop_ _alias.definition_id '_space_group_symop.key' _definition.update 2016-06-16 # CHANGED _description.text ; Value is a unique key to a set of space_group_symop items in a looped list. ; _name.category_id space_group_symop _name.object_id key _type.purpose Key _type.source Related _type.container List # CHANGED _type.contents 'Code,Index' # CHANGED loop_ _method.purpose _method.expression # CHANGED: Evaluation '_space_group_symop.key = [_space_group_symop.sg_id, _space_group_symop.id]' save_ #### # ADDED: # Note: this item is needed in any case because mmCIF and # the DDL1 core define it save__space_group_symop.sg_id _definition.id '_space_group_symop.sg_id' loop_ _alias.definition_id '_space_group_symop.sg_id' '_space_group_symop_sg_id' _definition.update 2016-06-16 _description.text # copied from mmCIF: ; This must match a particular value of _space_group.id, allowing the symmetry operation to be identified with a particular space group. ; _name.category_id space_group_symop _name.object_id sg_id _name.linked_item_id '_space_group.id' _type.purpose Link _type.source Related _type.container Single _type.contents Code # Take note of this: _enumeration.default '' save_ # ... end of additions #### ________________________________ Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer _______________________________________________ddlm-group mailing listddlm-group@iucr.orghttp://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] (no subject) (SIMON WESTRIP)
- References:
- [ddlm-group] =?utf-8?q?=28no_subject=29?= (James Hester)
- Prev by Date: Re: [ddlm-group] Dictionary conformance (was Re: Second proposal toallow looping of 'Set' categories)
- Next by Date: Re: [ddlm-group] (no subject)
- Prev by thread: [ddlm-group] =?utf-8?q?=28no_subject=29?=
- Next by thread: Re: [ddlm-group] (no subject)
- Index(es):