<div dir="ltr"><br>Thank you for this information.<br><br><br><div class="gmail_quote">On Tue, Mar 9, 2010 at 12:35 AM, Stacy Pober <span dir="ltr"><<a href="mailto:stacy.pober@manhattan.edu">stacy.pober@manhattan.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I loaded about 17,000 Springer ebooks into our catalog. I did not<br>
directly upload them into Koha, though. First, I edited them in the<br>
free MarcEdit program to add some fields.<br>
<br>
We use EZproxy to allow our users to access IP-restricted resources<br>
from off-campus. If you use something similar, you would use the<br>
Edit Subfield Data function to alter the 856$u data. You would<br>
replace "http: with something like<br>
"http:<a href="http://ezproxy.yourlibrary.edu:2048/login?url=http" target="_blank">ezproxy.yourlibrary.edu:2048/login?url=http</a>:"<br>
<br>
Additionally, the Springer ebook MARC records do not come with any<br>
custom link text. We added custom link text by adding an 856$y<br>
field. with the text "Available for our library via Springer eBooks.<br>
Click here for access". The custom link text is often provided in an<br>
856$w field rather than the $y field, and the $w and $y but they seem<br>
to display exactly the same in our catalog, so if you get other<br>
vendor-supplied records with 845$w fields, you don't need to change<br>
them unless you want to customize the link text.<br>
<br>
We also add a 952 field to specify the branchcode, ITYPE, shelving<br>
location and CCODE:<br>
\\$aMAN$bMAN$cEBOOKS$oELECTRONIC BOOKS$yEBOOKS$8EBOOKS<br>
<br>
The branch code needed to be added because without it, each ebook<br>
appeared in Koha with messages about availability that we did not want<br>
to see. Adding the ITYPE allowed us to add a "View this eBook" link<br>
to each summary record which is a nice convenience for end-users.<br>
<br>
We also add a 500$a field which lists the ebook service name (Springer<br>
eBooks) because that's the standard way we've been listing all other<br>
ebook packages (not all of the vendors have the package name anywhere<br>
in the record) and a 099$a field for Local Call Number of ELECTRONIC<br>
BOOKS because that's the way our other ebooks have always been listed.<br>
<br>
You may not need or want this level of customization, but it's nice to<br>
know it's available.<br>
<br>
When I first tried to upload the Springer records, I could not<br>
upload them in one step. Our catalog is hosted by LibLime and at the<br>
time I processed these records (a couple of months ago), the server<br>
response time was very slow and it would time out for large uploads.<br>
This was the only batch of MARC records I had that was quite so large,<br>
and I had to split the 17,000 records into batches of about 1500<br>
records. I don't know if there is any effective limit on file size<br>
for uploads in the official version of Koha.<br>
<br>
The processing of the initial file of the large Springer ebook record<br>
set was tedious but routine. However, Springer issues updated record<br>
sets for books they add to your subscription each month, and I am<br>
currently trying to work through some problems in the December update<br>
file. The monthly updates come in separate files for each publication<br>
year. We get five years of books, and rather than having to process<br>
them separately, I used MarcJoin in MarcEdit to concatenate them into<br>
one large file. This did not work, because it turned out there were<br>
some invalid characters in two of the records that caused errors in<br>
the joined file. I'm still working through that. The individual<br>
files validate correctly using the validator in MarcEdit, so I need<br>
to find a 'pickier' MARC validator to find the invalid characters.<br>
<br>
One more thing about ebook MARC records generally: I find that the<br>
quality of publisher-supplied MARC records is very variable. One<br>
problem we ran into with the MARC record sets for netLibrary and a<br>
couple of other vendors is that some of the records included multiple<br>
$856$u fields with URL's leading to other subscription-based online<br>
services to which we have no access. I had to find those bad URLs<br>
and strip them out of our records, and that was a little tedious.<br>
<font color="#888888">--<br>
Stacy Pober<br>
Information Alchemist<br>
Riverdale, NY 10471<br>
<a href="mailto:stacy.pober@manhattan.edu">stacy.pober@manhattan.edu</a><br>
</font></blockquote></div><br></div>