No last page field for journal articles?

Content Registration New Metadata Manager
1

In the new Metadata Manager, there is a field for first_page but nowhere to enter last_page as far as I can tell.

  1. Is there a last page field I’m missing? If not, is one planned?
  2. Meanwhile, is an XML re-deposit the right way to add last_page to a journal article originally registered with the new Metadata Manager?
  3. If I edit the record in Metadata Manager after that, will the form keep last_page and other fields it doesn’t display, or overwrite them?

Thanks!

2

Hello, and thanks for your questions.

  1. You’re not missing the last page field in Metadata Manager. It’s purposefully not there, and there aren’t plans to add it. Whenever we’re designing a manual metadata entry tool, we have to strike a careful balance between ease of use and maximal thoroughness of the available metadata. If we add in too many optional fields, metadata quality decreases, because people feel compelled to put something in a field just because it’s there, even if they don’t have any relevant metadata of that type. So, we end up with a lot of placeholders (“null”, “none”, “N/A”, etc.) or nonsense data that just unhelpfully clutters up the records. But, if we only limit the forms to what’s strictly required, we’d lose out on a lot of potentially rich and meaningful data. So, it’s a balance. For example, we have fields for ORCID and ROR IDs, even though those are optional elements, because linking DOI records to other PIDs is really powerful and beneficial. Page numbers are in the metadata schema for the purposes of citation matching and discovery (e.g. via link resolvers embedded in discovery software), but it’s really only the first page that’s strictly needed for those purposes, so we’ve opted to not include last_page or other_pages.
  2. You can include a last_page element if you prepare and submit XML directly.
  3. If you redeposit through Metadata Manager, the last_page will be overwritten. Basically, all the core bibliographic data (titles, authors, dates, pages) will be overwritten, while certain types of ancillary data (licenses, references, post-publication updates, relationships, etc.) will not be overwritten unless they’re included in the redeposit. It’s just a feature of how our schema is built.

Please let me know if you have any further questions.

1 Like
3

Thanks Shayn. That’s very helpful for better understanding how all this works.

I’ve added the last page by XML, and I’ll try to remember to make any later changes by XML too, so nothing gets lost.

Two thoughts on the design, with journal articles in mind:

Even if first page is enough for matching and the deposit, journals that paginate as well as reference managers and citation formatters that pull metadata from Crossref still need the whole range. A record with only a first page produces a reference with “89” where one normally needs “89–107”. This could give the false impression of a single-page article or equally result in people putting the whole range in first_page.

It seems that the bibliographic metadata best practices ask for the last page in last_page too, while the form has nowhere to put it. Point taken about placeholders. However, if you know the first page, you will most likely also know the last page, right?

Suggestion: Could the form keep the fields it doesn’t display, or warn before it overwrites them? Someone correcting a typo in a field wouldn’t expect to lose an unseen value like last page that was added by XML.

Also, what about the abstract? Is it overwritten on a Metadata Manager redeposit or untouched?

I realize you have a far better view of how the form gets used but wanted to relay my experience. Thanks for your speedy response and consideration.

4

Even if first page is enough for matching and the deposit, journals that paginate as well as reference managers and citation formatters that pull metadata from Crossref still need the whole range. A record with only a first page produces a reference with “89” where one normally needs “89–107”. This could give the false impression of a single-page article or equally result in people putting the whole range in first_page.

It seems that the bibliographic metadata best practices ask for the last page in last_page too, while the form has nowhere to put it.

Those are all good points. I’ll pass that on to our product management team for Metadata Manager for their consideration.

Suggestion: Could the form keep the fields it doesn’t display, or warn before it overwrites them? Someone correcting a typo in a field wouldn’t expect to lose an unseen value like last page that was added by XML

There is a warning that appears when you first import a DOI into Metadata Manager that was originally registered using some other method (Web Deposit Form, most typically). It indicates that some metadata may be overwritten. But, it’s pretty rare for someone to regularly switch between deposit methods. Once they use Metadata Manager, almost no one goes back to Web Deposit Form. And for members that have facility with XML, they typically avoid the manual metadata entry tools entirely. So, I don’t think this use case is common enough to warrant additional warnings.

Also, what about the abstract? Is it overwritten on a Metadata Manager redeposit or untouched?

Abstracts are supported by Metadata Manager, so there’s no reason they’d have to be lost. They’d be included in the deposit from Metadata Manager. Technically, they are overwritten, but they’d be overwritten either with the same abstract that was submitted previously or with an updated version of that abstract that was edited/corrected in the new Metadata Manager submission.