_publ_author_name is not a good key for _publ_author

[Herbert J. Bernstein]

Dear James,
  That is a solvable problem.  If they don't have one, use a "." until they
get one, and bug them periodically
about getting one.  At worst we will end up with some small number of
people who happen to have identical
names and who also refuse to get an ORCID id.  That is a much smaller
problem than we have now.
  Regards,
    Herbert

On Tue, Jun 23, 2020 at 10:05 AM James Hester <jamesrhester at gmail.com>
wrote:

> It would be great to use ORCID, but not everyone has one.
>
> On Tue, 23 Jun 2020 at 19:54, Herbert J. Bernstein <yayahjb at gmail.com>
> wrote:
>
>> Dear James,
>>   Having an unambiguous key is a fine idea, but shouldn't it just be the
>> ORCID id, as in _publ_aithor_id_orcid
>>   Regards,
>>     Herbert
>>
>> On Tue, Jun 23, 2020 at 12:51 AM James Hester via coreDMG <
>> coredmg at iucr.org> wrote:
>>
>>> Dear Core DMG,
>>>
>>> Please see proposed new definitions for the publ_author category, as
>>> suggested in my previous email (below). If no objections are forthcoming, I
>>> will be updating the dictionary a week from today.  Note that this change
>>> will in turn pave the way for adding author roles to a CIF file.
>>>
>>> best wishes,
>>> James.
>>> ===========
>>>
>>> save_PUBL_AUTHOR
>>>
>>> _definition.id                          PUBL_AUTHOR
>>> _definition.scope                       Category
>>> _definition.class                       Loop
>>> _definition.update                      2020-06-30
>>> _description.text
>>> ;
>>>      Category of data items recording the author information.
>>> ;
>>> _name.category_id                       PUBL
>>> _name.object_id                         PUBL_AUTHOR
>>> _category.key_id                        '_publ_author.id'
>>> loop_
>>>   _category_key.name
>>>          '_publ_author.id'
>>>
>>> save_
>>>
>>> save_publ_author.id
>>>     _definition.id              '_publ_author.id'
>>>     _definition.update          2020-06-30
>>>     _description.text
>>> ;              Arbitrary identifier for this author
>>> ;
>>>     _name.category_id                       publ_author
>>>     _name.object_id                         id
>>>     _type.purpose                           Key
>>>     _type.source                             Assigned
>>>     _type.container                         Single
>>>     _type.contents                          Code
>>> save_
>>>
>>> On Tue, 26 Mar 2019 at 17:28, James Hester <jamesrhester at gmail.com>
>>> wrote:
>>>
>>>> Dear Core CIF group,
>>>>
>>>> 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).
>>>> One way to fix this is to 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.
>>>>
>>>> An alternative approach would be to 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 who may be impacted.
>>>>
>>>> thanks,
>>>> 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 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/20200623/c1e6c388/attachment-0001.html>