Registering metadata for titles belonging to two book series

Content Registration XML Deposit
, ,
1

I initially wrote this in an e-mail to the support team, but then found this online community and thought it would be a better fit here.

I work for an academic publisher that publishes books and journals, including a number of book series. Several of our book series have subseries, and volumes in some of these are numbered in both the main series and the subseries. To give an example, the series Carsten Niebuhr Institute Publications (CNIP) contains the subseries The Carlsberg Papyri (CP), and all volumes in the latter are also numbered in the former; the most recent volume, for example, is simultaneously vol. 48 in CNIP and vol. 18 in CP.

Looking through the documentation for metadata submission via XML, I cannot find any information on how the XML structure should be for books that belong to multiple book series like this.

If Iā€™m understanding the schema documentation correctly, <book_series_metadata> requires exactly one <series_metadata> child element, and the <volume> and <issue> elements are direct children of the <book_series_metadata> with no relation to the <series_metadata> element (to which they are sibling elements).

The logical XML structure for a book belonging to one or more book series would to me be something like this (simplified):

<book type="edited_book">
  <series>
    <book_series_metadata>
      <contributors>
        [Editors of Series A here]
      </contributors>

      <titles>
        <title>[Series A title here]</title>
      </titles>

      <issn>[Series A ISSN here]</issn>
    </book_series_metadata>

    <volume>[Volume no. in Series A]</volume>
    <issue>[Issue no. in Series A]</issue>
  </series>

  <series>
    <book_series_metadata>
      <contributors>
        [Editors of Series B here]
      </contributors>

      <titles>
        <title>[Series B title here]</title>
      </titles>

      <issn>[Series B ISSN here]</issn>
    </book_series_metadata>

    <volume>[Volume no. in Series B]</volume>
    <issue>[Issue no. in Series B]</issue>
  </series>

  <book_metadata>
    [Book-level metadata here]
  </book_metadata>
</book>

ā€“ but this is significantly different from the actual schema, where the book metadata is given in the <book_series_metadata> element, and the book series metadata (excluding volume and issue number) is nested inside a <series_metadata> element, for reasons I admit I do not understand at all.

If my understanding of the XML structure is correct, how can we handle a case such as the one mentioned here, which would require two <series_metadata> elements and a relationship between the metadata of each series and the corresponding volume/issue number? Is it just not possible at all? Surely this cannot be the first time the fairly common practice of multiple series affiliation has popped up?

2

Hi,

Youā€™ve uncovered a flaw in how our book series (and other types) are structured - the container hierarchies are very strict at the top level, we unfortunately arenā€™t able to associate a volume with multiple series.

Itā€™s a known problem that exists in part because of the limitations of our current system, which does not allow us to create relationships between container records like book series, journals, conference series, and other records. It hasnā€™t come up specifically for books - itā€™s possible that, given DOIs are citation identifiers, members are registering distinct DOIs for each version of the series as this will create a metadata record for each volume. Ideally weā€™d also be able to connect these records using relationships, but as mentioned our system does not currently allow this.

In the example youā€™ve given, a single volume has two volume numbers - I assume when a volume is cited a single volume number is used, or is that not the case?

We do have long-term plans to correct the overall issue of relationships between containers like series and volumes, but unfortunately have no short-term solution to this at the moment.

-Patricia

1 Like
3

Hi Patricia,

Thanks for the reply. It would of course be nice to have the container records linked as well, so itā€™s searchable that Series A is a subseries of Series B, but ā€“ to us, at least ā€“ what is really missing is a one-to-many link between the book record and the book series (container) records.

When citing a volume, we would normally expect both series to be included with their respective volume numbers; for example (using an authorā€“date style), the most recent volume would be cited as:

SchiĆødt, Sofie, & Anne Grons. 2024. Two Medical Manuscripts. The Hieratic P. Carlsberg 8 and the Coptic Codex P. Carlsberg 500 (CNI Publications 48; The Carlsberg Papyri 18). Copenhagen: Museum Tusculanum Press.

I believe all of our books that belong to multiple series are like this, with one series being a subseries of the other, but it isnā€™t always so ā€“ I have seen cases where the same book is published as part of two completely unrelated series. One example I can think of is interdisciplinary conferences organised and hosted jointly by people from two different subjects/organisations, where the conference is simultaneously ā€˜The 12th Annual Conference of the Society for Subject Aā€™ and ā€˜The 8th Biennial Seminar of the Subject B Associationā€™. Of course, when the proceedings are published, the book is subsequently also simultaneously vol. 12 in Proceedings of the Conferences of the Society for Subject A and vol. 8 in Acts of the Biennial Seminar of the Subject B Association, and you would expect both series and volume numbers to be listed in citations.

This highlights the inconvenience of having <volume> as a property of the <book_series_metadata> element: unlike things like titles and contributors, volume numbers are not inherent properties of the book itself, but of the bookā€™s relation to the container (series). I assume similar considerations are the reason why contributor roles (author, editor, etc.) are included in an attribute to the <person> element, rather than as a child property of it.

The simplest and least disruptive update to the schema that I can envisage that would enable cases like ours and the joint conference case to be correctly registered would be to ā€“

  • allow multiple <series_metadata> elements in <book_series_metadata> ā€“ {1,unbounded} instead of {1,1}
  • add volume_number as an optional attribute to the <series_metadata> element
  • make both the <volume> properties optional in <book_series_metadata> (currently one is optional and one is not ā€“ and why are there two of them, anyway?)
1 Like
4

Incidentally, another hierarchical feature which is completely missing ā€“ as far as I can tell ā€“ is the ability to register book parts.

There is a <journal_article> element which can only be the child of a <journal> element, but there is no corresponding element for articles or chapters published in monographs or edited books.

This hasnā€™t cropped up for us yet (though I know it will within less than a year), but itā€™s far from uncommon for digital books to be made available both in their totality and as individual chapters/articles ā€“ but unless Iā€™m missing something, it doesnā€™t look like itā€™s currently possible to register metadata for and assign DOIs to such individual book parts.

Is that really so?

Edit: No, it isnā€™t ā€“ I had missed the <content_item> element, which has an attribute that can specify it as being of the type chapter. So this is all as it should be!

6

Thanks for this additional information, itā€™s really helpful.

  • make both the <volume> properties optional in <book_series_metadata> (currently one is optional and one is not ā€“ and why are there two of them, anyway?)

I am not sure why there are two volume properties to be honest - looking at the structure, I suspect there was supposed to be a choice between a required volume element or a required title with optional volume, thus requiring either a volume or title be present. The books series structure was created many years ago and hasnā€™t received much (if any) attention since then, but can certainly be revisited. We have a number of updates already in the works but can consider this in the future, Iā€™ll also make a note to discuss it with our Books Interest Group (Books interest group - Crossref)

7

You can register chapters and other book parts, within the ā€˜bookā€™ structure there is something called ā€˜content_itemā€™ that will capture a chapter.

Hereā€™s an example of a book series XML deposit with a chapter: best-practice-examples/book_series5.3.0.xml Ā· master Ā· crossref / Schema Ā· GitLab.

1 Like
8

Thank you for the update!

For now, Iā€™ve gone with submitting the volumes in question with the primary series (defined as the one we list first, which will usually be the parent series rather than the subseries). If and when additional series become available, I can easily change the code we use to generate XML files to include all series.

I just discovered that earlier today ā€“ I had missed it in the XML examples. (The fact that the examples shown in the documentation have no indentation doesnā€™t help.)