RLG staff comments on MARBI Annual 2000 matters
Discussion Paper 119
Leader 07. If a code is defined to distinguish integrating
resources, it is highly likely that RLG will have to direct all
records with that code to either the RLIN BKS database or the RLIN
SER database. RLG's targetting of records to specific RLIN
databases is based on the values in Leader/06-07. An attempt to
discriminate records with the integrating resource code in Leader/07
for targetting to more than one RLIN database would require
consideration of other parts of a record. It is possible that such
a wider consideration would have serious negative consequences on
proper overlay of existing RLIN records. This matter can better be
explored when the specific types of resources that will be assigned
the integrating resources Leader/07 value are defined. RLG will of
course ask its members for input when deciding how to target records
with the new Leader/07 value to RLIN databases.
008/18. RLG uses the 008/18-19 values to generate a statement of
frequency in the RLIN LONG display when a record in RLIN MDF or SER
lacks either a 310 or now obsolete 315 field. It would be easy to
accommodate a new code 'k' in 008/18.
008/21. The discussion does not make clear what quality loose-leafs
have that makes them deserving of a unique code, while other
resources such as updating databases are satisfactorily treated with
blank in this position.
008/34. RLG uses this code as one factor in determining whether an
incoming record clusters with other RLIN records. If a new code is
defined for integrating publications, RLG will have to determine
whether an incoming record with that new code will cluster with
similar latest entry records in RLIN (i.e., matching in all
signficant parts except for 008/34) or in a separate cluster of only
integrating publication records.
It does not seem appropriate for MARBI to discuss questions 1-3.
They are all cataloging questions whose answers will come from the
Joint Steering Committee when it considers Jean Hirons' draft
revision of AACR2 Chapter 12.
Question 4. The impact of multiple 260 fields in records for
indexing and display will of course vary depending on the system and
on the specifics of AACR2 and MARC changes. In addition to indexing
and display concerns, RLG will have to figure out the impact on
clustering records in RLIN, as well as on date retrieval with the
RLIN ALSO and LIMIT commands. RLG also needs to consider the
implications of such changes on special date indexes in the RLIN
ESTC and HPB databases as well, though the implications have to be
considered once the cataloging decisions for those materials have
been made.
Proposal 2000-01R
In the STATUS/COMMENTS section, the revised proposal says that the
MARC Advisory Committee discussion determined that a new proposal
should consider "indicating symbolic vs. ordinal numbers." An
example given in that discussion was volumes marked with * or **
instead of numbers or letters. However, the revised proposal does
not provide coding options in Position 1 for such symbols. Was this
an oversight? If not, what led to determination that it was
unnecessary to code for such symbols?
The coding in Position 2 does not distinguish when the letters are
in a mixture of upper and lower cases. How should such examples be
coded?
The proposal defines $z as a repeatable subfield, but no example
illustrates such a repeat. It seems useful to provide such an
example. It would also be useful to have examples of complete
853/854/855 fields with a single $z and with multiple $z's to give a
proper context for evaluting the addition of $z to those fields.
MARBI should carefully consider making 4 blanks a default for
Latin script in positions 3-6. Defining blanks in that way adds
another Latin script bias to the format, which might be an obstacle
to wider adoption of the format. The default blanks would save
having to input the data, but automatic system provision of the
proper ISO script code would also serve the same goal. However,
given the unlikelihood that automated library system consumers and
vendors will give any priority to redesigning systems to
automatically provide such an ISO script code default, it will be
hard to ignore the convenience of the default blanks.
Proposal 2000-07
RLG staff agree there is a need for a subfield for link text in the
856. However, before $y is used, perhaps a comprehensive review of
856 subfields to remove unnecessary ones should be done. It might
be that redefinition of some subfield for link text is preferred to
using $y. For example, someone might think of a reason why it is
better to have the link text come before the URI in the field, so
that use of $t is preferred to $y.
RLG staff are concerned that adding a subfield for link text will
significantly affect the display of the 856, when MARC 21 does not
now make clear when subfields should be input in a particular order
to allow for an intelligible display to a user. MARC 21 should at
least give guidance on the order for $3, $u and the new link text
subfield. The format should also make clear the relationship
between those subfields and the second indicator in generating
constants/labels for the 856 field.
RLG staff think it would be helpful if display constants were
recommended for each 856 subfield, as most subfields are
unintelligible without constants. RLG has defined constants for all
the subfields for use in its databases, but if the need for the
constants is a common one, wouldn't it be better to have a standard
in MARC 21 that everyone could use? Ideally, the MARC 21 format
should also provide full examples of common types of 856 fields and
give input conventions when it is important that subfields (other
than $3, $u and the new link text one) appear in a certain order.
These general matters should be worked out before the link text
subfield is added to the 856.
Proposal 2000-08
Since this field is for taxonomic identification, which is
hierarchical in nature, it is logical to define a number of
different subfields to convey the hierarchical levels. However,
it is not clear from the proposal if all levels must be given in
the 754, or if a portion may be given. If partial taxonomies are
allowed, should subfields be skipped in the $b to $m range to show
missing levels in the hierarchy? For instance, if only genus and
species were given in a particular 754, should $b and $c be used for
input, or other subfields that match the proper level of genus and
species in the taxonomic classification used in that field?
The MARC 21 format should give both undifferentiated (using
$a's) and differentiated (using $b-$m) examples of a complete
taxonomic hierarchy, and a partial taxonomy (if permitted).
Proposal 2000-09
It is important to make the CI format consistent with the other MARC
formats.
To: [log in to unmask]
cc: BL.CJA
|