Discussion List Archives

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

Re: CCDC/IUCr journals recommendation 1: Recognition of scientistsresponsible for data collection

  • To: "Spek, A.L. (Ton)" <A.L.Spek@uu.nl>
  • Subject: Re: CCDC/IUCr journals recommendation 1: Recognition of scientistsresponsible for data collection
  • From: James Hester via coreDMG <coredmg@iucr.org>
  • Date: Mon, 27 Apr 2020 17:51:20 +1000
  • Cc: James Hester <jamesrhester@gmail.com>, Distribution list of the IUCr COMCIFS Core Dictionary Maintenance Group<coredmg@iucr.org>
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:references:in-reply-to:reply-to:from:date:message-id:subject:to:cc;bh=P8f5YnlYhiipHWVQsiS/I4FrsfFZSK3GZejdqW/2PGc=;b=nx/zheDrEVWa2cyESo5+Qs+cSi/loB3FZABlMREu1VA7nAEXUNPsCSpeLEHsxlEAXmp79nNgd14BjzP6c77idve4fWSSmJQTRqZfSo/JFZgwJK1VRz2ybCHG4zn8tsBkHhzo4l62+CalpeZMb8T2gDPdjae+ToDPxR7S5dSUrA4B1JDhy+1aBtVKUJ3YtcXv7UNB5TOHF8W9ai+6jQzwQ5zs46RdUDOtTjTdgfjok0WrNSKNMBvuGQcmmx/zOwuQwiO854c2Ct83596PgfhtgrO5y6k9dngDeeT9GMHi6xG7iuBHWWYW3gUAwZLbVJHfohh7UFAr64wrEV2pvRI8jQ==
  • In-Reply-To: <AM0PR05MB57455783C7E892FDA2C48FD5D6FF0@AM0PR05MB5745.eurprd05.prod.outlook.com>
  • References: <CAM+dB2dUaHLTsr0uY3EeTedYXEG7Cno7OVSp96nTzUpTnZ36Yw@mail.gmail.com><AM0PR05MB57455783C7E892FDA2C48FD5D6FF0@AM0PR05MB5745.eurprd05.prod.outlook.com>
Dear Ton,

Sorry for taking so long to pick this up. The issue of global blocks is a separate one that will probably be addressed by defining ways in which multiple blocks can be combined into a single, larger block.  I've started a conversation in ddlm-group (you can see it in the mailing-list archives). I expect that 'data_global' will not be a special block name, instead something within the block will define its 'global' role.  In this approach, repetition of data names in different blocks would be acceptable if their loops provided non-contradictory information, i.e. the category keys had different values. I don't think that would really work in terms of dividing the roles of authors.

thanks,
James. 

On Tue, 10 Mar 2020 at 20:48, Spek, A.L. (Ton) <A.L.Spek@uu.nl> wrote:
As PLATON/checkCIF developer and Acta Cryst. C co-editor I am in favour of making the data_global construct for publication related data official/standard and relegate info on the person responsible for the experiment etc. to the applicable data_ sections.

Ton   

Prof. dr. A.L.Spek (Emeritus)
Utrecht University
Bijvoet Center for Biomolecular Research
Padualaan 8
3584 CH, Utrecht
The Netherlands

Tel: (+31) 653562400

http://www.platonsoft.nl/spek/             (Personal WEBsite)
http://www.platonsoft.nl/platon/           (PLATON info)
http://www.platonsoft.nl/xraysoft/        (Download Directory)
http://www.cryst.chem.uu.nl/spek/       (Personal WEBsite)




Van: coreDMG <coredmg-bounces@iucr.org> namens James Hester <jamesrhester@gmail.com>
Verzonden: maandag 9 maart 2020 02:52
Aan: Distribution list of the IUCr COMCIFS Core Dictionary Maintenance Group <coredmg@iucr.org>
Onderwerp: CCDC/IUCr journals recommendation 1: Recognition of scientists responsible for data collection
 
For details see the original document attached to https://www.iucr.org/__data/iucr/lists/coredmg/msg00345.html

In summary, IUCr Journals and CCDC propose using audit_contact_author loops from January 2021 to determine the crystallographer(s) responsible for the structures presented in those blocks.

My comments: 

(1) While I know there is an ad-hoc practice of using data_global to hold information that is relevant to all data blocks within a single file, I don't think this practice is actually formalised. So for now I think the recommendation can only apply to the data block within which the structure is presented, as pointed out in the CCDC response.  Perhaps we could make an exception if the CIF makes use of the _audit_link_block mechanism to link the global block into the individual structure blocks.

(2) A CIF data block can contain information about anything that has CIF data names defined. So if a CIF holds raw data, but no structure, audit_author refers to the person collecting the data. If a CIF contains both raw data and a structure (e.g. a powder diffraction experiment with the resulting solved structure included) then the file was presumably produced by the person solving the structure and so audit_author refers to them.  So the principle is that "the person responsible for the most recent content in the file is the audit_author."   This will be important to emphasise for CIF software authors, as it means that they should not by default carry forward the contents of _audit_author.

(3) I note that IUCr Journals propose to use both audit_author and audit_contact_author, whereas CCDC will use only audit_contact_author.  Is there any reason for this discrepancy?  By definition, audit_contact_author will always be a single person, whereas more than one person could be involved in preparing the data block contents (audit_author).  If there is only one, and no audit_contact_author is nominated, then they by default become the contact author. If there is more than one, then a contact author must be nominated (who is not necessarily one of the audit_authors).  The particular chain of logic to be employed here should be clarified for the benefit of software and data block authors.

(4) I agree that there is a need for a new loop that allows roles to be assigned to authors.  It will need to be a separate category to allow for multiple roles for a single author, and would be simple to design but may take time to choose the appropriate descriptors. Is there anyone interested in taking the initiative on this?  If so, a new thread on this list can be started.
 
Do others have any comments?

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


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

[Send comment to list secretary]
[Reply to list (subscribers only)]