Publishing content at the book or book-part level
Please can your team check the description below and provide feedback. I'll then move this information to the wiki.
(cc @John.kopanas, @yannis and @jure, this affects our approach to versioning in the data model. Please add further questions for Stacy if you have any).
Content can only be processed at the book level or the book-part level.
Book level
A book that is published at the book level, such as a monograph, is released in its entirety. Here's one example and another example.
The book document could be submitted in either XML or PDF format as one or multiple files. The PDF-source files can originate via FTP or a user could upload the files directly to the SFM.
Rolling back to previous published versions cannot be supported at the book level. This is because the PMC database was developed for journal publishing.
However, when book level content is updated, new versions of the submitted-source and b-XML files should be stored in the SFM. b-XML means 'book XML'; this is one XML file containing all the book's content. The NCBI chops up the b-XML into p-XML (book-part xml); each p-XML file correlates to one page of rendered content to the Bookshelf website. There is an additional conversion is from p-XML to n-XML: this is the file that is stored in the PMC book database and rendered on the Bookshelf website. The NCBI team have a meeting on Monday to decide whether the p-XML and n-XML should be stored in the SFM or not.
When book level content is updated sufficiently to be considered a new edition, this edition is a new book record in the SFM. Previous editions should be archived, however there needs to be a way to link the book records for previous editions to the current book record.
There isn't a need to assign statues or user roles to chapters (book-part level) in the SFM when the content is being published at the book level. Even though the book has chapters (book-parts), it moves through the SFM as one unit.
Book-part level
Books are published at the book-part level (i.e. chapters) when these parts need to be treated as a discrete unit, for example, for journal articles that are updated multiple times.
The book-part documents could be submitted in either XML, PDF or MS Word format as one or multiple files. The PDF-source files can originate via FTP or a user could upload the files directly to the SFM. All Word files are expected to be uploaded in the SFM interface and the NCBI only publishes Word documents at the book-part level at this time.
Each book part is released separately. Here's one example from an XML-source workflow and another example from a Word-source workflow. Both of these books that are published at the book-part level.
Versioning of the published document can only be supported at the book-part level. For example, each book part in this book can have multiple published versions, as shown on the right of the screen in this example book part.
When an update is made to a book part, the editor decides if the update is a revision or a new published version. This decision can be made in the SFM at at the 'publish' moment.
A book published at the book-part level has metadata associated with each book-part and metadata that relates to the book as a whole.
It is not always the case that the TOC is ordered alphabetically, so there needs to be a way for editors to reorder the book-parts when new chapters are added.
Organisations need to assign statues or user roles to chapters (book-part level) in the SFM when the content is being published at the book level.
Question for NCBI
- In this example, it looks like the 'whole book' is everything that the publisher (StatPearls) releases collected into a TOC that is ordered alphabetically. Is this common? Also, in this example is 'StatPearls' both the book and the publisher?
- I assume an organisations knows well before they submit content to the NCBI whether it should be processed at the book or book-part level. Is this correct?