Relationship between _publ_author.id and _audit_author.id

James Hester jamesrhester at gmail.com
Fri Aug 7 11:02:10 BST 2020


There is a bit of history to the publ_author category which those who have
been around longer than I might add to. Back around 1995 Acta C accepted
CIFs as the entire publication, that is, a CIF file was sent in and
transformed into a publication with no further text from the authors.
Fairly good idea at the time as it avoided messing around with document
formats and lowered the barriers to submission as far as possible with the
idea of getting all of those structures buried in drawers reported.

I believe pure CIF submissions are still possible for some IUCr journals
including Acta C. The "publ" categories therefore capture the information
relevant to publication such as author list, abstract and so forth, and
should only be used if the CIF is the primary source of the publication
itself.

On Fri, 7 Aug 2020 at 19:02, Horst Puschmann <horst.puschmann at gmail.com>
wrote:

> Hello,
>
> I think that this is an important question and I am with James on this
> one: I would go with number (4) -- these lists are independent (*).
> Conceptually, I don't think that (3) is correct.
>
> In fact, I would go a step further and say that the _publ_author loop
> should not be permitted in a data block.
>
> At the point of structure origination, nothing is known (for certain)
> about if and where the work might get published.
>
> Assembling the _journal_author list is the very last step and can only be
> done after a paper has been accepted for publication, at which point
> nothing in the data block(s) should be touched.
>
> Horst
>
> (*)  There are many cases where *none* of the audit_authors end up on the
> papers!
>
>
>
>
> On Fri, 7 Aug 2020 at 03:28, James Hester via coreDMG <coredmg at iucr.org>
> wrote:
>
>> Dear Core DMG,
>>
>> Related to my previous email today on author roles is the question of the
>> relationship between "publ_author" and "audit_author".  Recall that
>> publ_author lists authors on a publication that is based on the CIF file,
>> and is used by the journals. audit_author lists authors associated with the
>> production of the data. There are 4 possibilities that I see:
>>
>> (1) Audit author is the root source of author identifiers: all authors in
>> publ_author also appear in audit_author
>>
>> Objection: some authors on the publication may be associated with work
>> that is outside the crystallographic experiment and so not properly
>> included in audit_author
>>
>> (2) Publ_author is the root source of author identifiers: all authors in
>> audit_author also appear in publ_author
>>
>> Objection: Some contributions recorded in audit_author may not rise to
>> the levels required for ethical inclusion in an author list
>>
>> (3) A third "author" list is created that becomes the canonical author
>> list, from which authors in audit_author and publ_author are drawn
>>
>> Objection: duplication of information
>>
>> (4) audit_author and publ_author are formally independent lists, but can
>> link authors if required either via a new dataname pointing into the other
>> list, or indirectly via e.g. OrCID identifiers.
>>
>> My preference is for (4) as it recognises both the different underlying
>> scopes of the two author categories but also allows common authors to be
>> identified, and is minimally disruptive for existing software.
>>
>> If we had our time again, (3) would be the correct approach and we would
>> not duplicate address information in publ_author and audit_author. However,
>> making that change now would be very disruptive.
>>
>> Please comment.
>>
>> James.
>> --
>> T +61 (02) 9717 9907
>> F +61 (02) 9717 3145
>> M +61 (04) 0249 4148
>> _______________________________________________
>> coreDMG mailing list
>> coreDMG at iucr.org
>> http://mailman.iucr.org/cgi-bin/mailman/listinfo/coredmg
>>
>

-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iucr.org/pipermail/coredmg/attachments/20200807/e0de5d47/attachment.html>


More information about the coreDMG mailing list