Sharing Bibliographic Records Created for the Program for Cooperative Cataloging
(PCC) Among LC, OCLC, and RLIN
TECHNICAL WORKING PAPER
OBJECTIVE: Bibliographic records (initially BKS records,
but eventually all formats) created as part of the national program for cooperative
cataloging need to be available to all participants in a timely manner to avoid
the high cost of duplicative original cataloging. All headings in a PCC record
will be authoritative, and represented by records in the national authority
file. (NACO participation will be a prerequisite to becoming a PCC bibliographic
record contributor.) To expedite broad participation, contributions may be
made from multiple sources -- LC's MUMS, OCLC, RLIN, or local systems.
The PCC time-frame: YR 1-2, expand NACO participation; YR3 start bibliographic
distribution from among the pool of NACO participants.
- WORKING ASSUMPTIONS
AUTHORITY RECORDS
Migration of NACO contributions from LSP to FTP is currently in progress
and outside the scope of this paper. The issue of allowing institutions
to contribute authority records from local systems to the national name
authority file depends on: (1) local systems' capability to export USMARC
Authority Records; (2) local system's support of on-line edits for inputting/updating
authority records; (3) sites' investment in resources (staff and equipment)
for NACO maintenance, such as are in place at OCLC, RLG, and LC. Initial
sharing of name authority records will continue to be through RLIN and
OCLC contributions to the LC master file, even if PCC bibliographic record
contributions are created on local systems.
BIBLIOGRAPHIC RECORDS
- PCC participants will be creating both PCC records *and* records
outside of the program.
- PCC records may be created at either "core level" or "full level" cataloging.
- PCC records may be in different formats (but given above time frame,
will be after Format Integration has been fully implemented) and may
include non-Latin scripts (Chinese, Japanese, Korean, Hebrew, Arabic,
Cyrillic).
- PCC records, regardless of format, will be "dynamic', subject to
continual "enhancements" by participants that may not be reflected
in a change of encoding level. It is therefore likely that there may
be more than one PCC record at the same encoding level for the same
item, and it is important that the most recent, or most complete, record
is available to all participants.
- A number of PCC participants will want to use local systems for creating,
enhancing, and contributing PCC records. Assume participants will expect
to create or enhance PCC records as a natural by-product of their technical
processing workflow and environment.
NOTE: Extra system requirements for PCC contributions
from local systems are included in the model below.
- Even if a PCC participant is contributing bibliographic records created
or updated on a local system, OCLC or RLIN will be used as an external
resource to check whether a PCC record already exists. PCC records
need to be added to both databases within the same timeframe.
QUESTION: Does LC plan to use Z39.50 client
on MUMS to access PCC records on RLIN and OCLC? Does LC also need
to load PCC records into MUMS?
- PCC records will also be created directly on-line on LC's MUMS, OCLC,
and RLIN. These records must be automatically exported and shared within
the same timeframe.
- The headings in PCC records are guaranteed to be authoritative and
represented by records in the national authority file. Therefore, these
records should always be given priority for both export and import
by each participating system.
- All PCC records will be exported in the USMARC format; records exported
by participants' various systems will be with the local extensions
to the USMARC format that they now use.
- PCC records (whether new records or newly updated records) will be
clearly identifiable and distinguishable from non-PCC records, even
when encoding level is the same. *How* these records stand out among
non-PCC records in the LC, OCLC, and RLIN system applications will
be up to each organization to determine and implement. Any developments
needed to identify PCC records for export or online applications will
need to be in place before any PCC bibliographic records are created.
- Assume that FTP is the file transfer mechanism only for now, since
it is widely available and avoids the possibly delays of tape delivery.
However, in the time-frame projected, the possible proliferation of
Z39.50 client-servers may require that they be included in the model
as a possible alternate method of sharing PCC records.
- PROPOSED MODEL
- Multiple sources of PCC record creation and update
LC MUMS, OCLC, RLIN. and various local systems
If local system, PCC participant would need to agree to check
either OCLC or RLIN for any existing PCC record and that records
exported include the data that makes the PCC record identifiable.
(NACO contributions to the LC master file will continue to be done
on OCLC and RLIN.)
- Export of PCC records
PCC records created on OCLC or RLIN would automatically be exported
to a central FTP "PCC reporting" server (see below).
QUESTION: For LC records, is normal distribution
through MARC Distribution Services (also available by FTP) considered
sufficient?
If PCC records are created or updated on a local system, the
site would need to filter out PCC records and export them to the
same central FTP "PCC reporting" server.
QUESTION: Is it realistic to expect PCC sites
to export *only* PCC records to a specific file on a file server?
Records would be exported with the local extensions to the USMARC
format the source system now uses. It is up to the recipient of
PCC records whether to retain any holdings information included.
Eventually, any holdings data that is exported will use USMARC
Holdings Format.
- "DISTRIBUTION CLEARINGHOUSE"
A single FTP site will be designated as the one point where all
PCC records are sent. The institution hosting the FTP site will
be responsible for receiving PCC records and making them available
for FTP access. Pulling files of PCC records from the single FTP
site, and subsequent conversion of records, would be the responsibility
of OCLC and RLG as part of their dataloading process into their
respective databases. (Server can also be viewed as a central "transfer
site".) FTP site could be located anywhere but must provide individual
ports to OCLC and RLG so that they do not have delays in pulling
the records, and a yet-to-be determined number of other ports for
other program participants. Assume that security mechanisms will
be needed to prevent retrieval by unauthorized users.
Assuming records will be given priority treatment and retrieved soon
after they are sent to the FTP file server, there will be no need for "archives" of
the records and the older files can be automatically deleted after
a to be determined number of days. Host of the clearinghouse must have
a fully operational, fully supported FrP service, with available ports,
sufficient space, and be able to maintain log files for overall reporting,
and troubleshoot if there are any interruptions in the service. (Full
set of responsibilities to be worked out.) Posit the Library of Congress,
as Secretariat of the PCC, as the logical site of the clearinghouse
functions.
- OTHER OUTSTANDING QUESTIONS
- Assuming source of records will be mixture of PCC and non-PCC records,
how are PCC records to be uniquely identified?
- Will MARBI Proposal 94-12 (new encoding level and/or 042
pcc value) be sufficient?
- Will we also want to require that all PCC records include
a Cataloging Source Code (leader 008/39) of "c" (Library of
Congress cooperative cataloging program), already defined?
Will this make identification of PCC records easier?
NOTE: PCC records may be either full
level or core level; non-PCC participants may also create
core-level records (but without a 042 [or CSC=c] value).
- How do we distinguish PCC records from each other for the same
item?
- How to distinguish newly-created (or newly-updated) PCC records
from records that are just copies of already distributed PCC
records (with no changes)?
- How can we ensure that a PCC record contributed by the *same*
source overlays an earlier version?
- How do we identify which of two incoming PCC records for
the same item, same encoding level, represent the "latest,
most complete" version?
- Do we need a "transmission (or version) date" *within* the
record that is added at the time the record is exported from
the original source system?
- What happens if a PCC non-Latin script record is distributed to
a system that does not support the scripts in the record?
- Require that receiving system must *suppress and not delete*
non-Latin scripts if intends to enhance the record for subsequent
PCC distribution?
- Allow systems to delete the non-Latin scripts field, but
require that they indicate this deletion (say with a new MOD
value, leader 008/38) that original record contained non-Latin
scripts? (The Latin-script fields should still conform to PCC
standards.)
Prepared by: Karen Smith-Yoshimura, RLG
Submitted to Sarah Thomas June 17, 1994
|