Discussion List Archives

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

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

  • To: ddlm-group <ddlm-group@iucr.org>
  • Subject: [ddlm-group] Clarifying semantics of _type.purpose 'Key'
  • From: James Hester <jamesrhester@gmail.com>
  • Date: Wed, 9 Jan 2019 14:58:05 +1100
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:reply-to:from:date:message-id:subject:to;bh=2kj0MIAuwwXgLj08GCqmF6trPlo5lmpEE4vBMux2SgM=;b=gV8wMWx2w9DtjDhTHiIcP4VFUkOfliFk0xEkcDGaJllzVvCrv3aS3DgFvT5IvxFlrrBbP+oXQXX9NDOiunR3dlp67YA4pqBxV347I33qUFmzdM5xvdVbFfApsFuyLm+/x+TmvGqLHC8mTGnwkoqOfzNpqItdg55mZRwOkPs3rreVaZj5pQ+i0+8N2H90do5Fa2y90q7xahN5mJJ00uzdd6riO5OvmARz6NnPLlZrNpM1eRMiDSmhyb5QkImG5qCaSfFL3NH05hDClso1Wn2YeOwK8jz9IumLKvBVjIRgQ3SEB2o0I0J7iBE9gCFrKsJzsSqXj/LSVq2Ut2Nc4MExRQ==
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.

James. 
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links