[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] dREL changes and removal of keys in cif_core
- To: Group finalising DDLm and associated dictionaries <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] dREL changes and removal of keys in cif_core
- From: "Herbert J. Bernstein" <email@example.com>
- Date: Thu, 1 Sep 2016 08:45:39 +0200
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=KlM0uq0ePwV6UEq+jDkMBbgBCqiO3Xk6sYw9dNt5/N0=;b=f27LnHEWFeOr0g/kLiLQ3SzmZ1J0+qUJ3khvkGTp6jNz76xF5HZVcr0/BjJCRmSzHp6C84zJ+DEm8LO/3e/y6bruv/qKqIDj8eGogMI7vNshPG3zDfxtPd3v92Q+WJcNDy/ExbgCJLZJYxsqMoFeG0qW4O/20lyIqV4yOIkiqVu7ee4Jng7KK9TOzSQ+PlWbDcSumR6U+5/nQrshrzQpD7cQhobuwTe6sfQP8ItRD9c5ktzXy864bx2V8+VOhG4QMllHJU2euvbt47Au3cXIT+C58zN5AYI4idIsLlc6RNgRb4KQQGpLpnyuXxT3DnxLTB98MsGWbH92pyK0tyOfAA==
- In-Reply-To: <CAM+dB2crgQnmKM+8FVGNx3AUS=y8LBFsB2DO4Di95uAeA06tBw@mail.gmail.com>
- References: <CAM+dB2crgQnmKM+8FVGNx3AUS=y8LBFsB2DO4Di95uAeA06tBw@mail.gmail.com>
Looks good. -- Herbert
On Thu, Sep 1, 2016 at 7:29 AM, James Hester <firstname.lastname@example.org> wrote:
James.Dear DDLm group,Below is a document following on from the hub and spoke / _audit.schema proposal. The main effects will be an expansion of the category[key].name syntax in dREL, and the removal of synthetic primary keys in cif_core. Due to the removal of these datanames, it is better that this is agreed before the cif_core dictionary is formally approved and these draft datanames become official. For reasons which I will provide in the COMCIFS forum, the timetable for cif_core approval is starting to become tight, and so I would welcome comments on this (hopefully final) proposal in a timely fashion. If no objections are forthcoming, I will advise the cif_core DMG and expedite the presentation of the latest cif_core dictionary to COMCIFS for final approval.
Proposal to adjust key operation in dREL/DDLm
This note follows through on the consequences for dREL of additional
keys being added to loops as per the hub-spoke proposal.
The current draft cif_core dictionary is written around the
requirement that each category has a single dataname that
acts as a key. Where necessary, this dataname is synthesised
from compound keys (e.g. '_refln.hkl = [_refln.h,refln.k,refln.l]').
This requirement appears to have arisen to cater to the
dREL construction 'category[key].name'.
In a situation where additional datanames might join the category key,
the previous primary key no longer functions as a key, and so DDLm
and/or dREL have to be retooled to allow for this eventuality.
The most common use of the category[key].name construction is searching
for atomic position by atomic label, for example the assignment to 'xf'
With b as geom_bond
xc = List()
For [label,symop] in [[b.atom_site_1,b.site_
xf = SymEquiv(symop, _atom_site[label].fract_xyz)
xc ++= _atom_sites_Cartn_transform.
matrix * xf
_geom_bond.distance = Norm ( xc - xc )
'label' is a key value in the atom_site list, and 'symop' is a key
value in the symmetry operator list (inside the Symop function, not
Imagine now that we have switched to the 'variant' _audit.schema, in
which the atom_site list has an additional variant id tag for
e.g. different possible structural solutions. How do we adjust or
rewrite the DDLm and dREL above to cater to this?
Proposal to Enhance dREL/DDLm
The following adjustments would require minimal changes to dREL code
when moving between different schemas, and significantly declutter the
1. The category[key].name construction is enhanced to become
dataname_1,...].name, where 'dataname_n'
is an object_id in 'category' and 'local_dataname_1' is an
object_id in the category of the dREL method.
'dataname=local_dataname_1' can become simply 'local_dataname_1',
if an unambiguous sibling dataname is available in the referenced
category. 'local_dataname_1' can be omitted altogether if both the
present and referenced category have unambiguous sibling key
datanames. A single 'value' can be provided instead of
'dataname=value' if there is only one key component in the
referenced category that cannot be matched with a sibling in the
2. 'Synthetic' primary keys are no longer needed and are removed from
In the above example, atom_site has only a single key, so the usage of
'label' is unambiguous and can remain as is. In our 'variant' schema
scenario, both atom_site and geom_bond are provided with an additional
key linking to the variant 'hub' category. Again, no change in the
above dREL is required, as there is an unambiguous link between the
two variant key datanames and the only remaining element of the compound
key is the atom_site label.
The only changes to the current cif_core dictionary are to remove
unnecessary synthetic keys and to rewrite the dREL that assumed a
certain internal structure for these keys (I have done this already).
The major cost is in rewriting dREL implementations to perform the key
matching. This cost can be deferred until different _audit.schemas are
approved, as the current cif_core does not actually use synthetic keys
for lookup (although it creates them).
The current cif_core dREL approach is untidy in a situation where
different categories may depend on different subsets of the keys of a
third category (I gather this occurs in the macromolecular context).
So, for example, Category A may have a compound key composed of items
1,2,3,4,5. Category B may have a compound key of items 1,2,3 and
Category C of items 2,3,4. In the current cif_core approach, each of
A,B,C have primary key values created from the values of the
respective compound key items. So in order for category A to index
the appropriate entry in category B or C, it must use its 'master'
primary key to find the values of the appropriate items, and then use
these to construct the 'master' key of the respective category, and
then finally use this key to find the row in the target category.
The suggested approach allows each key equivalence to be expressed
explicitly and directly in the lookup, if they are not already
available from DDLm.
For this reason, redefinition and/or renaming of the primary key was
not considered as a viable option when adding new key components to
categories. As well as causing an undesirable proliferation of
datanames, the above key construction step would have to be rewritten
in dREL for each _audit.schema and for every method that accessed
external categories affected by the schema.
ddlm-group mailing list
_______________________________________________ ddlm-group mailing list email@example.com http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- [ddlm-group] dREL changes and removal of keys in cif_core (James Hester)
- Prev by Date: [ddlm-group] dREL changes and removal of keys in cif_core
- Next by Date: [ddlm-group] Adjustment to the hub-spoke proposal
- Prev by thread: [ddlm-group] dREL changes and removal of keys in cif_core
- Next by thread: [ddlm-group] Draft audit.schema,looping proposal available on Github