All, in late July, Robert Bremer sent a request for comments to the CONSER
list with two scenarios for coding the 006 and the CONSER standard record
guidelines. There were not many replies, and I'd like to follow up on
this.
We are preparing to revise PCC documentation for cataloging integrating
resources and I think it would be good to ask the question in the context
of cataloging electronic integrating resources as well. Do we need to code
a computer file 006 for these resources as well when we already code
008/23 (Form) "s" in the record?
Please have a look at Robert's message pasted in below. Do you have a
preference for one scenario over the other for CONSER standard record for
e-serials? How about for integrating resources? Would you please let me
have your comments by Oct. 31st? Thanks!
Les Hawkins
CONSER Coordinator
Library of Congress
Washington, DC 20740
v. 202 707-5185
[log in to unmask]
<paste>
Liping Song wrote:
... I discovered in entering 006 I had to code beyond the first byte for
the Connexion to accept my command. Did I miss something? Thanks!
Reply:
OCLC staff (i.e., yours truly) missed picking up on the full impact of
the CSR requirements related to 006 so that not all the necessary
changes are in place to accommodate the CSR 006 coding practice.
However, reconsideration of the 006 issue has prompted new discussions
at OCLC which I have shared with Les Hawkins, and I would like to
propose changes to the CSR coding practice for 006.
The majority of 006 fields in CONSER records are for computer files. In
the PRISM era, OCLC strongly promoted their use as the way to correctly
identify electronic resources for indexing purposes. In Connexion,
other elements, including 008/23 (Form) in particular, serve that same
purpose so that the need for the computer file 006 in OCLC is not nearly
as important as it once was. Still, 006 may be useful in other systems.
A computer file 006 does not convey a lot of information anyway, but the
first position alone without the remaining positions being coded
actually duplicates the coding in 008/23 (Form). That raises the
question as to why field 006 needs to be coded at all. So, perhaps
field 006 should be optional. If included, then perhaps it should be
completely coded so that it does not just duplicate 008/23 (Form)
especially if that coding can be readily accomplished via use of
constant data, macros, etc.
For the rare non-textual serials, a continuing resource 006 may be
useful, but coding only the first position would mean that the 006
conveys nothing more than the same coding in Leader/07 (BLvl).
Presumably, elements like 006/04 (SrTp) and 006/17 (S/L) have the same
value as when they appear in field 008, and perhaps they should be fully
coded.
So, would a workable change the CSR requirements for field 006 be:
Scenario #1
* For non-textual serials, include a continuing resources 006 field
* All other 006 fields are optional
Or:
Scenario #2
* All 006 fields are optional
In either scenario, if field 006 is included, code it following the
guidelines for the same elements in 008.
Note that field 006 elements Freq, Regl, Conf, and Orig will already
accept input of the fill character as is the case for their 008
counterparts.
Your thoughts? Other possibilities?
Robert Bremer
[log in to unmask]
|