Notes. Stanford; Vitus Tang; 2/18/10
1. What was intended to take 3 months took 3 years, in part because of the RLIN merge with OCLC.
With the introduction of IRs, the reclamation had to be retooled. File sent originally in Dec 2006 had
4.2 million records; the file sent in 2008 to generate IRs was 4.1 million records. Gap file sent Oct.
2009 (2.2 million). From that point, continuous export (daily).
2. One problem was that there was a limit on the size of the uploaded file (90K per file). They sent 19
files every day. The process took about 9 days in total. The records then went into the record
loading queue (further delay).
3. Stanford created IRs for all reclamation records. (exception: MARCIVE gov docs did not give
permission to create IRs (350,000 records).
4. Testing. Stanford sent OCLC a sample file. Analysis took 2-3 months. [I didn’t get how the analysis
affected the reclamation files; however, OCLC did not reject anything because it was too brief—
keeping in mind that they didn’t send in-process records—see 6.]
5. Three holdings symbols: Stanford, Hoover, & Law. Caused part of the delay. Affected whether they
could create an IR [?]
6. Who? Head of metadata, systems 1, programmer 1, head of Tech Serv. Hard to quantify time spent
due to the delays. Took 2/3 months to develop the specs & how to deal with the data.
7. Ongoing updates. The Stanford system is set up to upload whenever any update is made to the
bibliographic record. They do not send holdings, only bibliographic records. [my sense was that they
were concerned about the additional maintenance required; their policy is to keep the IRs up to
date. But this is rather early on]
8. Stanford excluded records for uncataloged resources. (If we choose IRs for all resources and do not
exclude uncataloged records, would this result in a lot of additional exporting as the records are
upgraded?)
9. Like Yale, Stanford sends newly cataloged records to an outside vendor for authority processing. All
of the returned records are automatically exported a second time.
10. What if Stanford has multiple records in its local system (intentionally) but they all match on the
same master record? Haven’t reviewed; may not be aware of the problem; not clarified by OCLC.
11. Why IRs for everything. Not a high level, much-discussed decision. The 2 reasons VT gave were:
non-roman already used IRs, so why not roman script? and an advantage if they go to Local
WorldCat in the future (although they have no immediate plans to use Local WorldCat).
12. Maintenance issue in the local catalog. If a different record overlays, the linking number field is lost.
13. Maintenance issue in OCLC. The reclamation process identified 300,000 records in OCLC that had
the Stanford holdings symbol attached but that did not have a corresponding record in the
reclamation files sent by Stanford. OCLC default policy is to delete anything older than a set date;
Stanford not giving the OK until they can investigate further. In some cases it was because a title
was attached to a different master record.
14. They did send records for electronic resources for the vendors that permitted this. Apparently they
identified the source of the record as part of the loading process into their local catalog, so
identifying the usable records was not an issue. The records they do not want to send are in a
permanent uncataloged status (see 5.)
1
15. What they get from OCLC: processing summary, cross reference file, the unresolved file [14,000 why
something didn’t load]; the udev file [I think these are the actual records?]; gap file; scan/delete file
(see 11); UTF8 errors (small).
16. The cross reference report file has this information: system control # in 001, ISBN/ISSN, LCCN,
Master ID in 079 [prefixed with OCLC-M]; Institution Record ID in 035 (prefixed with OCLC-I); title.
Using the cross reference file report initially caused problems because OCLC sent a text delimited
file with fields separated by commas, $ used for the delimiter and titles wrapped; plus problems
with diacritics and character encoding. Worked when the files were delivered in MARC format.
17. The report turnaround is good; as soon as the file is processed, the report can be retrieved from the
OCLC server.
2