Re: [ddlm-group] (no subject)
- To: SIMON WESTRIP <simonwestrip@btinternet.com>, "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 20:55:24 +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=npEwxClA3HRCqUiHCWLY76QkNXzat8LXgKTjdNKw79Q=;b=C4Dcm/+jbWv7u3b99G0aeXTtxF3aTw/VGsa40G/lCGkSbZwmcP25V6n4EWJsiqG3uxGd9PBsEMaoTaZpuyXZET6kB0/K09SIoPVqBadarTysSoNrhath52XcwAHnHKaPl15vWTVqd/VvLGyL6qhm6FvAqfR/buYugT0fdDtwQG8=
- In-Reply-To: <1568703469.7601150.1466100783200.JavaMail.yahoo@mail.yahoo.com>
- References: <CAM+dB2fdHvdZ-UUMuy6rbGXWvY567b769nO4R4c35kLvAYXyJg@mail.gmail.com><BN1PR0401MB0932FD0BC85A496DBD36FD17E0560@BN1PR0401MB0932.namprd04.prod.outlook.com><1568703469.7601150.1466100783200.JavaMail.yahoo@mail.yahoo.com>
- spamdiagnosticmetadata: NSPM
- spamdiagnosticoutput: 1:99
Hi Simon, The _enumeration.default values I presented are neither 'null' nor 'undefined'. They are empty strings, which is entirely different (unless you’re Larry Ellison).
Another value could be chosen instead, as long as the ones chosen for the parent and child keys match; I selected the empty string on the basis that it was unlikely to collide with or be confused with any key presented explicitly. Even if a given data file
used that key value explicitly, however, that would not in itself cause that file to be invalid. In any case, there is no magic here. A default value for an item is the value the item takes if it is not presented explicitly. By assigning a default value
for a category key, that category key need not be explicitly presented when there is no need to differentiate instances / rows / packets in the same category (i.e. when there is only one). That works fine for the usual case of only one space group being presented
in a given data block, and it does not rely on any DDLm changes. Dictionary-driven software (for DDLm) should handle all existing data files just fine with those definitions, whether they express a single space group or several, and, in the single space group
case, whether they explicitly express the category key or not. Non-dictionary driven software written against the given definitions is likewise informed how to handle the no-explicit-key case, though it needs to handle that case manually. I like your metaphor: providing default key values indeed affords some flexibility to data files, and the (non-exclusive) alternative is to provide a means to
change the shape of data definitions. As for metaphorical pegs and holes, however, if a DDL1 or DDL2 peg does not fit the corresponding DDLm hole then that is an inherent problem. The definitions in the DDLm core dictionary define the _same items_ that are
defined by our DDL1 core dictionary and by a subset of mmCIF. Because they disagree, either the definition of the SPACE_GROUP category in the DDLm version of the core is wrong, or those in the DDL1 core and mmCIF are wrong. Note also that this is all related to the old SYMMETRY and SYMMETRY_EQUIV_POS categories, which had already been deprecated in favor of SPACE_GROUP and SPACE_GROUP_SYMOP
when ITVG was published in 2005. SYMMETRY has no category key and cannot be looped, whereas SPACE_GROUP does have a category key and can be looped (in the DDL1 core and mmCIF and symCIF), so although data represented via the old categories can also be represented
via the new, the switch, now more than ten years ago, opened the possibility for data file misinterpretation that has now captured our attention. It is because the DDLm core fails to faithfully reproduce the DDL1 core’s pre-existing definitions of those categories
that I assert that a change along the lines I presented needs to be made to the DDLm core (not to DDLm itself), regardless of how we decide to handle future key problems. Cheers, John From: ddlm-group [mailto:ddlm-group-bounces@iucr.org]
On Behalf Of SIMON WESTRIP Hi John Please bear with me as an 'observer' (rather than someone who can speak with any authority about ddlm/drel), I assume the use of 'enumeration.default' as 'null' or 'undefined' is basically enabling an 'implicit/explicit' approach to key definitions for a looped
category? If this is something that can be readily worked into ddlm and (perhaps most importantly) drel, then I would welcome it. Currently, it seems to me that what we are trying to do is fit a square peg (i.e. ddl1 space_group) into a round hole (ddlm space_group) - James's proposal
enables the hole to become bigger to accommodate the peg... but requires a chisel (audit.schema) to do it, while an 'implicit/explicit' approach adds elasticity to the materials we're dealing with... (please forgive the metaphors - long day!) Thanks
Simon From:
"Bollinger, John C" <John.Bollinger@STJUDE.ORG>
|
_______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- [ddlm-group] =?utf-8?q?=28no_subject=29?= (James Hester)
- Re: [ddlm-group] (no subject) (Bollinger, John C)
- Re: [ddlm-group] (no subject) (SIMON WESTRIP)
- Prev by Date: Re: [ddlm-group] (no subject)
- Next by Date: Re: [ddlm-group] (no subject)
- Prev by thread: Re: [ddlm-group] (no subject)
- Next by thread: Re: [ddlm-group] (no subject)
- Index(es):