[Cod-bugs] Missing Journal Information

[Robert McMeeking - STFC UKRI]

Hi Saulius & Antanas

I have prepared a .tsv file which hopefully will allow you to correct some IUCrData entries. These entries are missing the article ID/page number in the COD.

I have just realized I haven’t added the first line key for the .tsv. I retain the same scheme as last time. My understanding is that the publisher, in this case, has added an ID Article file in their CrossRef data with blank start and end pages numbers.

It looks like most entries have Article ID in the start page field. But that scheme seems to have broken down recently. The publishers have probably made format changes which have upset your workflow system!

Regards

Bob

From: Antanas Vaitkus <antanas.vaitkus90 at gmail.com>
Sent: 03 July 2025 12:23
To: Saulius Gražulis <grazulis at ibt.lt>
Cc: McMeeking, Robert (STFC,DL,SC) <robert.mcmeeking at stfc.ac.uk>; cod-bugs at ibt.lt
Subject: Re: [Cod-bugs] Missing Journal Information

Hello,
just a short note on article IDs in CIFs. Since version 3.2.0 the coreCIF dictionary [1]
defines the _journal.paper_number data item which is more or less a paper ID:

    Article number that is used by some journals instead of a page range.

    Usually applies to electronic-only journals.
However, we do not yet properly support it in the COD deposition pipeline.

[1] https://www.iucr.org/__data/iucr/cif/dictionaries/cif_core_3.2.0.dic

Sincerely
Antanas

On Thu, 3 Jul 2025 at 14:16, Saulius Gražulis <grazulis at ibt.lt<mailto:grazulis at ibt.lt>> wrote:
Hi, Robert,

thanks for your answer!

On 2025-07-03 14:00, Robert McMeeking - STFC UKRI wrote:

Thank you very much for the feedback. Getting my brain working again after being on a long holiday was a bit of a struggle! I am, however, now in a better position to streamline my processes at this and also.
Sounds great!


I have checked a number of the entries on the COD site and they now look fine.
Great, ACK.

I assume you are happy to map the Article ID onto the Start Page where this is appropriate. In the longer term perhaps “Article ID” might be a new field?

AFAIK (maybe my colleagues will chime in and correct m,e if I am wrong), there is no official IUCr data item for the "Article ID". Publishers are not decided either – some (re)use first-page as the article ID (RSC), some ditch page numbers altogether and add the article identifier, sometimes without even specifying what properties it has (e.g. will it change for the new revisions of the paper).

For our purposes, the first page serves as a good unique synthetic key together with the other bibliographic info (Journal+year+volume+issue+first-page is (nearly) guaranteed to be unique, unless publishers do something totally crazy as having duplicated page numbers in the same issue...). Thus, using Article ID as the first page when there is no page is suitable for this purpose, and we do it so far like this. A machine readable indication that we have Article ID and not the page number is the NULL value in the `lastpage` SQL column :).

For article identification we can increasingly rely on DOI nowadays.
The CrystalWorks link:
https://cds.dl.ac.uk/cgi-bin/rfm/crystalworks_trawl_new?8799_8892_9714

does not pick up the amended details as yet, but I am assuming it will be become available after the next overnight upload to our server – if not tomorrow quite soon. I will get back if there are any issues to report.

Let's see how it updates!

Regards,
Saulius

--

Dr. Saulius Gražulis

Vilnius University Institute of Biotechnology, Saulėtekio al. 7

LT-10257 Vilnius, Lietuva (Lithuania)

mobile: (+370-684)-49802, (+370-614)-36366

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


--
Antanas Vaitkus,
Vilnius University,
Life Sciences Center,
Institute of Biotechnology,
room C521, Saulėtekio al. 7,
LT-10257 Vilnius, Lithuania


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.crystallography.net/pipermail/cod-bugs/attachments/20250704/106587b4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out_iucrdata_saulius.file
Type: application/octet-stream
Size: 11199 bytes
Desc: out_iucrdata_saulius.file
URL: <http://lists.crystallography.net/pipermail/cod-bugs/attachments/20250704/106587b4/attachment-0001.obj>