Books: Items: migrate volumes and series about cds-migrator-kit HOT 2 CLOSED

Here is a list of different cases where “volumes” are involved.
In most cases volumes can be identified from the BibRec via the field 246__n and/or 246__p (some 5000 records)
But there are cases where the information is only in 300__a:
https://cds.cern.ch/record/2196560?ln=en
(difficult to say between 500 and 1000 records)

CASE 1

1 Book record , with different volumes (246__n), where the volume titles are different (246__p). Different ISBNs (020__u). Paper and ebooks
Ex: https://cds.cern.ch/record/1644390?ln=en

In the new model we should have:

Main record
Title: The collected papers of Albert Einstein : English translation supplement
Publisher
…

Each volume -> 1 record
Title
Volume
ISBN (based on correspondence: 246__n and 020__u)
Publication date

Each volume record will have items (1 paper and/or 1 electronic)

CASE 2

1 Book record , with different volumes (246__n), but no different title and/or no different ISBN
https://cds.cern.ch/record/2637927?ln=en

In the new system we should have:

Main record
Title: Nanoelectronics : materials, devices, applications
….

Each volume -> 1 record
Volume

Each volume record will have items (1 paper and/or 1 electronic)

CASE 3

1 book series, different volumes, but the book series is not considered as a periodical
Book series information is stored in 490

https://cds.cern.ch/search?f=490__a&p=De%20Gruyter%20studies%20in%20mathematical%20physics

We leave as it is. No record needed for the book series. The information of the book series is stored in field 490 as it is currently, and we can from each book record make a link to all other volumes of the book series (based on a query)

CASE 4 (a few cases in our collection)

1 book series, different volumes, the book series is considered as a periodical with an ISSN and we have a subscription (small subset of above)
Book series information is stored in 490 in each volume.

Ex: https://cds.cern.ch/record/1346068?ln=en
https://cds.cern.ch/search?ln=en&sc=1&p=490%3A%22Lecture+notes+in+physics%22&action_search=Search&op1=a&m1=a&p1=&f1=&c=Articles+%26+Preprints&c=Books+%26+Proceedings&c=Presentations+%26+Talks&c=Periodicals+%26+Progress+Reports&c=Multimedia+%26+Outreach

We leave as it is. The book series record is a periodical record Each volume is catalogue separately with the information of the Book series in 490. Ideally, there is a link (based on a query) from the periodical record to all volumes and vice-versa.

Strategy to handle the migration of those records

In my view, the volume records should use the same data model as the main record, and both records should be linked by a parent/child relation. So we it would cover cases where there is only 1 information that differs (volume) and all other information are inherited (or simply visible) from Parent record, and cases where more information differ (title, publication date in some cases publisher, abstract…) Is it what you had it mind?
Then, we should find a good way to display this information, that might be the trickiest part actually ;-)

• Library to prepare list of records according to the different cases mentioned above
• Library to check /modify the fields where the information is embedded within the description in 020, 8564 and 0247 and should be cleaned (we could create different subfields to separate the information in view of the migration)
• Based on those lists create the corresponding records (main records and volumes) (CDS)
• Extract the corresponding items and automatically make the linking, based on the string that indicates the volume
• Manually correct what doesn't work. (Library)

from cds-migrator-kit.

In order to create the links between a parent record (main) and a child record (volume), I thought we could use this element already present in the data model: related_record.yml which is already used to create links between 2 editions of the same book (information currently stored in 775).
What do you think? Do you think it would be better to have a separate element?

I have modified a bit the element to make it more accurate. Please find it attached to this ticket, if you believe this is ok, you can replace it in the model. (I've replace .yml by .txt because Github wouldn't let me attach a .yml file...)
related_record.txt

from cds-migrator-kit.