Re: Expanding category key for publ_author.name

I think Solution (1) is less disruptive.

The publ_author category has traditionally relied on 'conventions' with respect to representing data

(e.g. _publ_author_name ought to be 'family name, initials')

and overall lacks the level of granularity that is becoming increasingly important

(e.g. _publ_author_address can contain any number of addresses as arbitrary text;

recognizing institutions/countrys relies on heuristics...)

That is, the publ_author category does not currently lend itself to more granular data collection

and I dont think it is linked to by other categories,

so rather than redefine it in a way that totally invalidates current practice [Solution (2)],

I would look forward to new categories and items to be defined as alternatives, fully exploiting the

key definitions...

I think there are other (DDL1) categories where the same may apply, e.g.

_audit_author (though I note that in the DDL2 pdbx dic there is_audit_author.pdbx_ordinal...)

So I'm in favour of a solution whereby keys can be inferred from the order in which loop rows appear

in the CIF in cases where there the key items are absent from the CIF

(in much the same way as space_group_symop_id is often inferred from the order in which space_group_symop_operation is listed).

Cheers

Simon

On Friday, 28 June 2019, 05:38:12 GMT+1, James Hester <jamesrhester@gmail.com> wrote:

Dear Cif-developers,

The CIF core group has not expressed an opinion on the following proposal, so before going ahead with one of the suggested fixes, I would like your opinion as CIF software developers and database curators on the options presented:

The publ_author category has _publ_author.name as the category key, meaning that _publ_author.name can be used to select a unique row of the loop. However, it has been pointed out that _publ_author.name is insufficient as a key for the _publ_author loop, as some authors have the same name (there are apparently 40 entries in the COD with this feature). 

Solution (1): Add a further disambiguating data name to _publ_author. The suggestion is that something like "_publ_author.id" could be defined, which would contain an arbitrary code and which would be added to the category key.  The lack of this dataname in historical CIFs can be worked around by assuming it has a constant value, and CIF curators can auto-generate it when a situation is encountered with multiple identically-named authors.

Solution (2): Define "_publ_author.id" as the new key of the category that can be auto-generated from each packet. While in a formal sense this makes all current CIFs non-conformant, I can't imagine that it would affect most software, which will continue to work with _publ_author.name.

Please indicate your preference or alternative solutions. Particularly important is the perspective of software authors and database curators who may be impacted.

thanks,

James. (CIF chair/acting core CIF DMG chair)

--

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