Newsgroups: bit.listserv.notis-l
Date:         Mon, 12 Oct 1992 16:32:29 -0500
Comments:     Warning -- original Sender: tag was daviss@DAVIS.CUL.COLUMBIA.EDU
From:         Stephen Davis <daviss@CUNIXF.CC.COLUMBIA.EDU>
Subject:      Draft Recommendations to NSI on USMARC Format
              Integration--Version 2
Comments: To: LIB 1 Listserv <LIB1@ricevm1.bitnet>
Comments: cc: NOTIS Listserv <notis-l@tcsvm.bitnet>

[Also being distributed to the NOTIS-L listserv at the suggestion of several
Lib1s.)

		USMARC FORMAT INTEGRATION & NOTIS
	Draft  -  10/92 -  Draft (Revision 1: 10/12/92)

NB: This revised draft contains two omitted paragraphs (4.1 and 4.2) and
additional provisions in sections 2.3., 3.3., and 3.4, resulting from the
recent discussions at NUGM.   October 30 is the deadline for all additional
suggestions.
------------
The following was put forward for discussion by the Lib1 Interest Group.  It
is expected that it will lead to a concrete set of proposals to NOTIS on its
implementation of USMARC Format Integration (FI).  Please forward all comments
to Stephen Davis, Columbia University (daviss@cunixf.cc.columbia.edu) by
OCTOBER 30, 1992.

The document "Format Integration and its Effect on the USMARC Bibliographic
Format" (Library of Congress, 1992--ISBN 0-8444-0754-2) is highly recommended
as background reading.   Thanks to Michele Dalehite and Priscilla Caplan for
their input.

1.  TAG TABLES

FI potentially involves the following changes to NOTIS tag tables:

	--restructuring to remove format dependencies
	--consolidation of data elements for all bibliographic formats
	--removal of "deleted" data elements
	--special handling of "obsolete" data elements
	--addition of new data elements

Even though individual sites or vendors may update their database to reflect
Format Integration, not all sites exchanging records will do this at the time.
Some sites/record distributors may choose never to remove obsolete data
elements.

Proposed Recommendations:

1.1	NOTIS should consolidate tag table structure so that validity is
defined with reference to the non-overlapping higher-level formats only, e.g.,
bibliographic, authority, holdings, classification, community information
format.  All former "bibliographic" formats would be validated against the
same list.   (While implementing the newer MARC formats is not really related
to Format Integration, it may be desirable to add these elements to the tag
tables as part of their restructuring.)

	Comment:  In some cases (e.g., Leader,  008) there are still format-
dependent values.  Proposal 1.1 would mean that the content of these fields
could not be validated according to format.  An alternative would be to
include format-specific validation for those fields only.  (NB: fields 006 and
007 are "self-defining" and can be validated based on their first byte(s).
Any 006 or 007 type will need to be valid in any bibliographic record type.)

1.2.	NOTIS should encode obsolete values in the tag table in such a way
that obsolete data elements can be retained in records being loaded or
updated.   A message should be generated when such an element is encountered,
alerting the user to the presence of an obsolete data element and allowing the
user to modify the data element or not according to institutional policy.
(USMARC allows obsolete data elements to be retained in existing records; it
proscribes their use in newly created records only.)


2. 	DATABASE & FILE CONVERSION PROGRAMS

Some sites will want to update their databases programmatically to remove
obsolete fields, others will not.  Again, FI does not require changing
existing records to remove obsolete data elements, only deleted data elements.

Proposed recommendations:

2.1	NOTIS should provide Libraries with a database conversion program that
does the following, as separate options:

	--deletes "deleted" content designation
	--converts "obsolete" data elements to specified valid equivalents in
cases where there is a one-to-one match
	--adds new content designation in those few cases where the value can
be predicted (e.g., new Leader/08 Type of Control).

2.2.	NOTIS should provide a  parallel, optional conversion facility for
LSYS OPAC screen definition files that would remove or convert deleted and
obsolete tags, indicators and subfield codes.

2.3.	NOTIS should provide the following conversion related reports:

	--a report that can be run in advance of conversion showing all
instances of "obsolete" and "deleted" fields in the database.  In some cases,
a site may choose not to make the changes at all or to make them by hand.  The
report should also list those changes that would not be one-to-one, so that
sites may choose to handle these manually.
	--a post-conversion report showing all records that were changed as
well as any that presented problems, etc.


3. 	NOTIS FORMAT DEFINITIONS

USMARC format integration does not change the requirement that a cataloger
make a decision about the basic format of an item; this is reflected in the
choice of Leader /06 and /07 values and 008 type.   In view of this, the NOTIS
format code will still be a valid way to identify items and to generate
workforms, etc.   Similarly, NOTIS sites will continue to want to specify
different OPAC displays for different types of materials based on format.
(Rationalizing data elements across formats does not erase significant
differences in the applicability or importance of data elements when applied
to different types of material.)

The implementation of FI, however, does create the possibility that sites may
need to add numerous fields to their OPAC short and long view definition files
in order, for instance, to display serial or archival aspects of other basic
format types.  This may require an increase in the number of labels and tags
allowed (from the current 45?)

Also, the addition of secondary format information to records in the 006
fields suggests that it should also be made indexable in the way that LDR
information currently is, i.e., through the keword/Boolean "fmt" qualifier.

Proposed Recommendations:

3.1.	No change should be made to the NOTIS "format code" or basic database
structure.

3.2	No change should be made to MHI entry codes and displays.

3.3	NOTIS should model possible brief and long views under format
integration and determine whether the number of labels allowed should be
increased.

3.4.	NOTIS should allow the keyword "fmt" search qualifier to index the
first byte of all 006 fields along with the current LDR/NOTIS format values.

4.  INPUT AND DISPLAY OF 006 VALUES

Format Integration involves the definition of a new fixed field 006, which is
used for "Additional Material Characteristics".   Field 006 is "self-defining"
in that the acceptable values in all character positions are predictable from
the first byte of the field (and are tied to validity of
parallel 008 data elements).  Any type of record may need to include any type
of 006.

Proposed Recommendations:

4.1	NOTIS should allow 006 field templates to be selected on any
bibliographic input screen, similar to current 007 field handling, by keying
the tag and the first byte of the field, e.g., "006s" for a serial 006 field
template.

4.2	Because of the possible increase in fixed field information in the
bibliographic record, NOTIS should consider allowinginput and display of
fixed field information at the end of the MARC record, rather than at the
beginning, in staff-side displays.

5.  COORDINATION OF NOTIS PROGRAM UPDATES

Coordination is needed between NSI and NOTIS sites, between NSI the national
utilities'(OCLC, RLIN, WLN and LC's) implementation schedules, and internally
at NOTIS in coordinating changes among the various programs that might be
affected by FI.

Proposed Recommendation:

5.1.	NOTIS should issue the package of FI-related changes as a single
interim release.  It should be released no later than 6 months before the
major utilities implement FI--currently December 1993--so that NOTIS sites
will have time to come up to the current regular NOTIS release and also
implement the FI-release before the first FI record hits their system.

5.2.	NOTIS should carefully evaluate  loaders, GTO, BOVL, RLIN TOP, etc. to
determine whether any FI-related changes are called for.  If so, these
programs should be revised and released as part of the FI-package.

5.3.	All load and related programs should be written to accommodate both
pre- and post-FI records ("backward compatibility") since the implementation
of full FI among all MARC records creators will be unpredictable at best.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU