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

Re: [ddlm-group] Clarifying semantics of _type.purpose 'Key'

  • To: James Hester <james.r.hester@gmail.com>, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
  • Subject: Re: [ddlm-group] Clarifying semantics of _type.purpose 'Key'
  • From: "Herbert J. Bernstein" <yayahjb@gmail.com>
  • Date: Wed, 9 Jan 2019 07:53:24 -0500
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:references:in-reply-to:from:date:message-id:subject:to;bh=B0jDLIxy3LcbcTIbjv9WTUYKhTQHWkgT9OzgMDN8Oys=;b=TkorDD0dSXNsg1bHdvxEkVD/l/2qCgO/JMLxkOfMf2OtcB6LJJ+yumJWgL7J2/dQ4+jmoZHFtjciTLrAt9BX/ZeymRlLGscYRJuG2Y196tItQZ60UmLO9d3rQrU/c+DuqJVtUy6vJgxEMNqzlS4Yq58bPOJAeBfdsaI4zvVV17lh8YX7VIWuoXq7Za7J3g1vJua1YfXVTt6cteJFmB6BXzZhE1TAp13SapQ51uu8TVjHRTvfKLlCMtLGNtfVZOxCxkTKYQcOiHcumxkN1detRN53+Qu3Mvk7YGXgG41MOFuXAvlfB7YcgyAnUtWeLgRvdscsmZuP5OuTJ0jTC6utCw==
  • In-Reply-To: <CAM+dB2eSABT0BTQxmmC8wg3j3fMB+6wJe7_Od9x5Xf6LnqCpiw@mail.gmail.com>
  • References: <CAM+dB2eSABT0BTQxmmC8wg3j3fMB+6wJe7_Od9x5Xf6LnqCpiw@mail.gmail.com>
I beg to differ.  It is extremely difficult to ensure the negative purpose of _not_ containing any machine
interpretable information, especially when the very word key does normally imply an important machine
interpretable function.  I would suggest deprecating this tag and starting over with a clear affirmative statement of the purposes.  We should try for clarity and simplicity.

On Tue, Jan 8, 2019 at 10:58 PM James Hester <jamesrhester@gmail.com> wrote:
Dear DDLm-group,

It has been proposed (see https://github.com/COMCIFS/cif_core/issues/108) that the values 'Key' and 'Encode' for _type.purpose would have their meanings slightly clarified as follows: any dataname with a '_type.purpose' of 'Key' is considered to be strictly an opaque key that does not carry any machine-interpretable information. So, for example, _atom_site.label, which encodes both atom type and number, would not have a _type.purpose of 'Key', even if it were unique in its loop. Instead '_type.purpose' would be 'Encode' (as it is at the moment). The vital information that it does act as a key within its loop is still conveyed by the _category_key.name information in the atom_site category definition. On the other hand, _exptl_crystal.id, which has no machine-extractable information, would be better described as 'Key' instead of 'Encode'.

The advantages of this change are:
(1) CIF processors would know that data names identified as 'Key' can be missing or ignored when only a single row in a category is present
(2) Currently, both 'Encode' and 'Key' can be reasonable descriptions of a dataname's function. This ambiguity is removed.

The original cif_core dictionary provided by the Perth group appears to have used _type.purpose='Key' purely for artificially-constructed, single-dataname keys to be used by the dREL system for loop access using the category[keyvalue] construction.  This role has been taken over now by _category_key.name, so the present change is not relevant to dREL, except insofar as dREL systems can take advantage of the information that a dataname value is irrelevant for single-row loops.

I believe that there are no downsides, as the current core dictionary uses both 'Encode' and 'Key' for key datanames, and so there would be no software that relies on values of _type.purpose = 'Key' to make decisions.

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list
ddlm-group mailing list

Reply to: [list | sender only]