We are currently working on improving the base HTML reports that are
generated and sent out with every Backfile or Current Cataloging
processing.
>From 2004 to 2012 we contented ourselves with having reports in HTML
format only. Over some of those same years, we had requests to make the
reports able to be sorted, edited, and generally rearranged. In an
effort to address these requests, we developed an in-house solution to
convert the existing reports to XLS. Now, nearly every report is also
available in a simplified version (which may not always mean better) as
XLS.
But we are now revisiting the HTML reports. Our lead programmer has
figured out a way to improve the efficiency and usability of these
reports. In fact, I have attached a sample of the latest prototype for
the revised HTML reports (see: R07 attached). This new functionality
allows you to sort the results on nearly anything (control number, tag,
field data). You can also search through the results for specific fields
or headings that start with certain characters. It even finds results if
they have diacritics (without requiring you to input the diacritics).
Our philosophy with respect to reports is that we do not like to leave
any stone unturned. If it is possible for us to report out on something,
we elect to do so. Currently, we have in the neighborhood of roughly 90
separate reports (AC, RDA, Notification, etc). This can be wonderful for
clients that love that kind of detail and view all of the different
updates that have or have not been made to their data. It can also be
overwhelming to other clients that may just be interested in a quick
report that tells them the salient information with further access to
these other reports when desired.
So we are exploring the development of a single report which is
comparatively brief (around 1 page), that provides a sort of executive
summary of the process itself. The intent is to present you with a
general overview of the process while also allowing you to dip into the
other reports at your discretion.
The hope is that this brief report would help satisfy those clients that
are not interested in poring over our other reports and just want
something relatively simple that gives an overview of the processing.
And it might help our other clients that do make use of the other
reports we have that go into much more specific detail. As we make more
progress on this front, we will keep you updated.
As always, please feel free to tell us what you like or don't like about
our existing reports. If there is a way to improve the experience for
you, we would love to figure it out with you.
Nate Cothran
Vice President, Automation Services
25 East 1700 South
Provo, Utah 84606
Phone: +1.800.288.1265, ext. 697
Direct: +1.801.342.5697
nate(a)bslw.com
<mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> *
www.bslw.com <http://www.bslw.com>
As a core group within our department, we meet regularly to discuss our
RDA Enrichment service. During these meetings, we talk about three
topics:
1. What isn't working
2. What needs to be added
3. What needs further review
We are continuing to make improvements to the service, though at this
point, most of them are minor adjustments to programming we already have
in place. Sometimes, it does mean we are adding in functionality where
it didn't exist previously. Our hope is that as you become ready to
address RDA within your system, you gain the confidence you may need by
knowing that we are continually focusing our efforts on this.
Here are some of the RDA updates we've discussed and have either
implemented or are implementing shortly (*please note that these changes
will only happen for clients that have filled out the RDA online
profile):
* Change <space>p. to <space>pages in 5xx notes
* Change pagespages to pages in 300 $a, 5xx notes
* Only spell out bracketed 260 $a info if RDA; even with this
one, there are specific instances where certain state abbreviations are
acceptable in RDA
* Do not change 260 $a n.d. (or N.D.) to date of publication not
identified; this should only be spelled out when appearing in 260 $c,
otherwise it should be expanded to North Dakota
* Tighten up programming for adding 9XX Enriched to RDA enriched
bibs; this was acting like our normal change stamps so we are looking
into making sure this tag (if desired) is added specifically to records
that have been enriched / validated by our RDA processing, rather than
just to any record that has been changed due to processing
* We have a client that wants their non-RDA bibs to have access
points updated only, but also wants their RDA bibs to have enrichment +
validation; we decided in cases like this it makes sense to use 2
profiles:
o 1) non-RDA bibs: run Step 5 only (which addresses access points in
RDA)
o 2) RDA bibs: run all of RDA profile
* For our GMD to (33X) CMC processing, we are addressing what
happens when the resulting set of 33X fields contains 2 or more
'unspecified':
o If all three 33X (336, 337, 338) contain 'unspecified' then we are
choosing to not add any of those fields to the record and report on it
(R132 - CMC Not Added);
o If 2 of the fields are 'unspecified', then we will report those out;
in conjunction with this we are replacing our R130 - CMC Added report
with R130 - CMC Unspecified instead as we feel this report would be more
informative than CMC fields that have been added
* We are also looking at changing the priority of checking
certain fields when it comes to trying to establish the most correct set
of 33X fields. Currently, we search for existing values in the following
fields in this order: 245 $h GMD, LDR-06, LDR-07, 007-00, 007-01,
007-xx, 008-xx, 300 $a. But we have discovered that, in some cases, the
2nd 007 may contain the better field from which to derive the 33X
fields; however, our system only considers the first 007 at this time.
So we are looking into a couple different options:
o If two 007 fields exist and are unique, then we look for 007-00 'c'
(electronic resource) first;
o Or consider checking 300 $a first when 2+ 007 fields exist;
o We are testing both scenarios to see which may be the better fit for
processing
* Add a rule to change 'cm.' to 'cm' for all records (not just
RDA only bibs); the 300 field no longer needs to end in a period and we
have had a few requests to have this changed
* Move existing $e rda to follow last $b in 040 field; note: we
are not adding $e rda at any point during machine processing
My team may have more to say on these (especially if I have
misinterpreted any part of the above!). Also, please feel free to ask
any questions you may have about the information presented today.
Nate Cothran
Vice President, Automation Services
25 East 1700 South
Provo, Utah 84606
Phone: +1.800.288.1265, ext. 697
Direct: +1.801.342.5697
nate(a)bslw.com
<mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> *
www.bslw.com <http://www.bslw.com>
