Discussion List Archives

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

Re: DDLm dictionaries: treatment of alias data names

  • Subject: Re: DDLm dictionaries: treatment of alias data names
  • From: Antanas Vaitkus <antanas.vaitkus90@xxxxxxxxx>
  • Date: Fri, 8 Sep 2017 11:01:11 +0300
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=J+nGYdP5fv4EMZ2ye20w3NGLAOBShkcpbPfWcAkqAQQ=;b=K1GXjx+AaMULuLe0K6Xk7U5xwTybny4vaOEcKJ4SENeFSx9qzWqxhPuZlRiGrW14xrcJtL5CflfUTDs+rSy8C/MVGNUTXHbOF3MtskPyWj9Qdsprfn5w70sJiPd8vYTYdykwp4rO9py+RHrhbU6xVrWaQc7qyqeXUR7oLzk7BZsKcK6S3X46M0OpMZrAloiJ0jjYIIhxn6QG2GkaC72dsjkEgg1vQAVUYMn7/EqAIUIKSlzDDHy0SlAuIbFm+o9PY7gRzXBVixgl8BQQUOVllCYwXF2XGv4YbjiIiq83IVrCk1YVnVk0AcuicIa/Ny7anzuTZxMq8JuMD9JJrjgQKQ==
  • In-Reply-To: <CAM+dB2facJrg_OtX_uUgpUbBMWVqjcM4pP9sqLp99-qjW7yO5A@mail.gmail.com>
  • References: <CALHYoX76e9ygX5DeWd=wOi8bkTLrVCP8MOLV6wm04BxKMM7PNg@mail.gmail.com><1410035661.898634.1502037364100@mail.yahoo.com><CAM+dB2facJrg_OtX_uUgpUbBMWVqjcM4pP9sqLp99-qjW7yO5A@mail.gmail.com>
Thank you, that clears things up a bit.

2017-09-06 8:41 GMT+03:00 James Hester <jamesrhester@gmail.com>:
I think Simon's approach is sound, and that the correct approach is to treat such equivalences as semantic rather than syntactic.  In this case, disagreement in the values of aliased data names is treated in the same way as disagreement between cell parameters and cell volume. If software does not know of the aliasing (see the examples that Simon cites) then it can only act as if the data are consistent.

I will make sure that there is discussion of this point in the next edition of Volume G.

James.


On 7 August 2017 at 02:36, SIMON WESTRIP <simonwestrip@btinternet.com> wrote:
Hi Antanas

My 'unofficial' view:

Such a file will only be 'invalid' when you check it for dictionary compliance -
e.g. if a particular dictionary says _diffrn_special_details is an alias of _diffrn.special_details
and _diffrn.details is also an alias of _diffrn.special_details then
if both data names appear in the same data block of a CIF that claims conformance with that dictionary,
they represent a duplicate data name and are in invalid with respect to that dictionary.

It all depends on which dictionary the CIF adheres to,
e.g.

_diffrn.special_details and _diffrn.details are unknown to cif_core ddl1
(and should therefore raise an 'unknown' warning when validating).

_diffrn.special_details is unknown to cif_pdbx ddl2 but it does alias _diffrn_special_details as _diffrn.details
(similarly an 'unknown' warning for  _diffrn.special_details should be issued when validating,
and a 'duplication' warning issued if the block contains both _diffrn_special_details and _diffrn.details ).

The ddlm version of cif_core is aware of the ddl1 and ddl2 versions and thus defines aliases accordingly
(raising 'duplication' warnings when validating...)

All this highlights the importance of declaring dictionary conformance within each data block in a CIF file...
(a subject that is currently being fine-tuned for ddlm and CIF2).

As a practical approach, if an application is able to read a dictionary and understand alias definitions therein,
then it should process the data name in its 'canonical' form and store/process its value according to that canonical data name and associated definition, therefore readily identifying 'duplicate' data items, etc... (at least that's what I attempt do with mmCIF, where all core ddl1 items are aliased - being represented using the category 'dot' conventions...)


Cheers

Simon





From: Antanas Vaitkus <antanas.vaitkus90@gmail.com>
To: Forum for CIF software developers <cif-developers@iucr.org>
Sent: Friday, 28 July 2017, 12:24
Subject: DDLm dictionaries: treatment of alias data names

DDLm based dictionaries allow specifying alias data names for data items (i. e. _diffrn.special_details has two aliases -- _diffrn_special_details and _diffrn.details). I was wondering if there are any official IUCr guidelines how the CIF file should be interpreted if several of these values are present in the same data block. Does it become an invalid file (following the logic that a data name can only appear once in a file)?

--
Antanas Vaitkus,
PhD student at Vilnius University Institute of Biotechnology,
room V325, Saulėtekio al. 7,
LT-10257 Vilnius, Lithuania


_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers



_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers




--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers




--
Antanas Vaitkus,
PhD student at Vilnius University Institute of Biotechnology,
room V325, Saulėtekio al. 7,
LT-10257 Vilnius, Lithuania


_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers

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

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

ICSU 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.