Support for processing instructions in chapter-processed books / collections
cc @jordandc
Expected behaviour
NCBI needs to support all its chapter-processed book metadata and collection metadata at MVP deployment to ensure continued functionality in its indexing, rendering, and other integration.
Current behaviour
Following PIs are not currently supported but must be for frequently updated content:
-
<?eissn ....?>
- whenever we have a collection that has both print and electronic ISSN, we add this PI to the collection metadata, which we send to NCBI when we load to PMC (when we preview or publish the collection). We should use the same PI order as in the sample, where<?issn 2050-4365?>
comes first and<?eissn 2050-4373?>
second.<?issn 2050-4365?>
is already in place. This development is now separately tracked in #1404 (closed).
Example tagging:
<collection-id>ukemecollect</collection-id>
<collection-name>Efficacy and Mechanism Evaluation</collection-name>
<publisher>
<publisher-name>NIHR Journals Library</publisher-name>
<publisher-loc>Southampton (UK)</publisher-loc>
</publisher>
<?issn 2050-4365?>
<?eissn 2050-4373?>
-
<?book-chapter-manuscript?>
- Must write author manuscript PI for this funded content for chapter-processed chapters. For chapter processed books in the PDF workflow: In the UI when you add one of the content types to a chapter version (must be required), and that content type is author manuscript, then this PI is written into the<book-part-wrapper
for the version of the chapter. The other content types (final full text etc.) would also need a related PI in the same way (information to be provided by NCBI, they are the same as the wholebook context).
If taggers write the PIs into the <book-part-wrapper
in the book metadata, we are currently overwriting it, and if we didn't overwrite it, it would work, and might be easier than adding it to the UI. That is an alternative to adding it to the UI. We couldn't ask them to place it somewhere that we're not overwriting, because it wouldn't work. - this is now being handled separately in #1406 (closed).
Example tagging:
<book-part-wrapper xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ali="http://www.niso.org/schemas/ali/1.0/" id="wt292272_ch8" content-type="chapter"
from-where="front-matter" dtd-version="2.0">
<collection-meta collection-type="ncbi-books-collection">
<collection-id collection-id-type="pmcid">wtcollect</collection-id>
<title-group>
<title>Wellcome Trust–Funded Monographs and Book Chapters</title>
</title-group>
</collection-meta>
<book-meta>
<?select_chapters?>
<?book-chapter-manuscript?>
<book-id book-id-type="pmcid">wt292272</book-id>
<book-title-group>
-
<?select_chapters?>
- For funded content when only selected chapters are submitted, not ALL chapters / entire funded book. For chapter-processed chapters. For chapter processed books in the PDF workflow: when the System admin indicates that only select chapters are submitted, we add this PI to book-part-wrapper to the book metadata. This relates to broader discussions around the ideal funding flow targets.
Alternatively, as above, if taggers write the PI into the <book-part-wrapper
in the book metadata, we are currently overwriting it, and if we didn't overwrite it, it would work, and might be easier than adding it to the UI. That is an alternative to adding it to the UI. We couldn't ask them to place it somewhere that we're not overwriting, because it wouldn't work. - this is now being handled separately in #1406 (closed).
Example tagging:
<book-part-wrapper xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ali="http://www.niso.org/schemas/ali/1.0/" id="wt292272_ch8" content-type="chapter"
from-where="front-matter" dtd-version="2.0">
<collection-meta collection-type="ncbi-books-collection">
<collection-id collection-id-type="pmcid">wtcollect</collection-id>
<title-group>
<title>Wellcome Trust–Funded Monographs and Book Chapters</title>
</title-group>
</collection-meta>
<book-meta>
<?select_chapters?>
<?book-chapter-manuscript?>
<book-id book-id-type="pmcid">wt292272</book-id>
<book-title-group>
-
<?create-gtr-links?>
(For integration with Genetics Testing Registry requirements) - In the Word workflow (applies to Word chapter-processed books, not Word One docs, but since we use metadata template for both, it can appear in both), add a PI field that allows a string with validation, or dropdown of controlled list, or select buttons, in the UI in Word book metadata, when this exact PI is added by System admins, we write the PI into all the chapters/components of that book, when loading to PMC (at preview and publish), into the<book-meta>
. - now being tracked separately in #1407.
Example tagging:
<book dtd-version="2.0">
<book-meta>
<?create-gtr-links?>
<book-id book-id-type="pmcid">gtrbook</book-id>
<book-title-group>
<book-title>Medical Genetics Summaries</book-title>
</book-title-group>
-
<?pdfbuild-skip-alt-title-as-rhead?>
(For PDF building for some content like GeneReviews) - For Word and PDF workflows, whenever the setting to allow creation of PDF ('Create book level PDF' and/or 'Create chapter level PDF' is on in settings), make it possible to add this PI to all components of the book, in the book-meta, by allowing the user (Sys admin) to add this PI in the book metadata. Ideally this PI is only supported when the setting 'Create book level PDF' and/or 'Create chapter level PDF' is on in settings, but if it's not restricted it shouldn't be a problem (@lathrops1 to validate that). In general, when we have more than one PI, the order doesn't matter, except for the first case in this issue about ISSN and EISSN. - now being tracked separately in #1407.
Example tagging:
<book-meta>
<?get-external-navigation-xml related?>
<?pdfbuild-skip-alt-title-as-rhead?>
<book-id book-id-type="pmcid">gene</book-id>
-
<?get-external-navigation-xml related?>
(For GeneReviews integration with MGV databases and infrastructure requirements) - In the Word workflow (applies to Word chapter-processed books, not Word One docs, but since we use metadata template for both, it can appear in both), add a PI field with checkboxes in the UI in Word book metadata, that allows a string, when this exact PI is added by System admins (with validation for the supported ones, and feedback on the exact format), we write the PI into all the chapters/components of that book, when loading to PMC (at preview and publish), into the<book-meta>
. The order in which multiple PIs appear in book-meta doesn't matter. - now being tracked separately in #1407
Example tagging:
<book-meta>
<?get-external-navigation-xml related?>
<?pdfbuild-skip-alt-title-as-rhead?>
<book-id book-id-type="pmcid">gene</book-id>
-
<?external-xml-source-base /pmcdata/bookshelf/gene/external-xml/ready/?>
&<?external-xml-source-name .molgene.db.xml?>
(For GeneReviews integration with MGV databases and infrastructure requirements) – In the Word workflow, in checkboxes, Sys admins would add it to the book metadata in the same controlled list as the other PIs above, and we add it to the book-part-wrapper for every component in the book. We should maintain the order of the tagging example below, and other PIs above don't apply to Word workflow book-part-wrapper so we don't need to account for the order of those. - now being tracked separately in #1407
Example tagging:
<book-part-wrapper content-type="chapter" id="mdel17q12"><?external-xml-source-base /pmcdata/bookshelf/gene/external-xml/ready/?><?external-xml-source-name .molgene.db.xml?>
Steps to reproduce
See example tagging we need written that we cannot currently support
Possible solution
At minimum for deployment a Processing Instruction field for collection and chapter-processed metadata that permits user to add multiple ones required. This might be best achieved for all cases by checkboxes under a 'Processing instructions' heading, where only the relevant ones appear depending on the place (book or collection) and the workflow (e.g. Word, XML, or PDF). The user can use the checkboxes to tick the ones that should apply, and we write these into the XML.
NCBI's priority feedback
Y, MVP migration and deployment
QA Steps
[To be completed by Coko once dev is done]