Regine,
Thank you so much for suggesting this! It was indeed a whitespace issue.
Somewhere along the line, one of my XML editors stripped out the whitespaces
and I never noticed because 008 is not a field I was paying any close attention
to. I suspect this was from bouncing between versions of
Hi Sarah,
Following up on Brian’s suggestion that your 008 looks short—depending on how
your MARC-XML is being created, you may want to make sure that the blanks
aren’t being collapsed by some sort of whitespace normalization setting. I know
I’ve run into this with oXygen before.
Hope this
Aha! Thank you. I'll investigate 008 with our cataloging librarians.
__
Sarah Newhouse (she, her, hers)
Digital Preservation Archivist
Othmer Library of Chemical History
t. +1.215.873.8249
Science History Institute
Chemistry * Engineering * Life Sciences
315
Hi Sarah,
1. The MARCXML importer gets the language from 008/35-37. I’m not sure what
happened to it, but the 008 in your record looks short. Looking at the code,
if the language positions are blank the language is set to undefined. But that
would only work if there are actual blanks in
Hey all
We're about to jump to v3.3.1 and I'm wondering if anyone has any suggestions
for memory allocation for Solr?
Currently we're running 6GB for the entire suite in v3.1.1 and are looking to
keep the same overall memory footprint. Wondering if something like a 75/25
split (ie 4GB for AS