I'll take on these two questions about MARC.
> Maybe you can explain a couple things about MARBI for me. First, by what authority does MARBI even exist and do what it does? Second, can anybody join MARBI and participate in its deliberations, whether or not that "body" is an ALA member?
MARBI is an ALA *advisory* body to LoC. I don't know who fixed the
composition of the group initially, but it consists of 9 voting members,
3 each from LITA, ALCTS and RUSA. The committee also consists of
non-voting members representing key stakeholders: RLG & OCLC (well, now
OCLC, and once WLN, RLG and OCLC); various national libraries (NAL,
NLM); representatives from associations of non-general libraries (Ass'ns
of Music Libraries, Law Libraries, etc.); one vendor representative
(AVIAC).
The meetings are held at ALA and anyone can attend and speak up. The
listserv is open (marc_at_loc.gov).
HOWEVER, LoC has control over just about everything. If you submit a
proposal for a change, it goes to LoC and they decide *if* it goes to
the advisory group. If they do send it to the AG, they can and do edit
it beforehand, so as the submitter you do not control the content of the
proposal. And because the group is *advisory*, LoC can choose to ignore
the advice, or to make changes after votes are taken. This happens
seldom, but it has happened.
More info at: http://www.loc.gov/marc/marbi/marcadvz.html
Andrews, Mark J. wrote:
> One more thing...as I recall, ISO 2709 = ANSI/NISO Z39.2, correct? If there are complaints about field and record length limits, limits built into these transport formats, then one way (not necessarily the best way) to proceed would be to increase the record length and field lengths. Of course then everybody gets to re-write, well, a lot of code.
>
Length limits cannot be increased because the ISO 2709 structure allows
only 5 characters for record length (99999) and 4 characters for field
length (9999). What could be changed would be the number of indicators
(0-9, currently at 2) and the size of the subfield code (0-9, currently
at 1). But the lengths are fixed, which is why moving to MARCXML is seen
as an advantage by some. (MARCXML does not solve other problems, like
running out of subfield codes when you have exhausted a-z, 0-9). For
some statistics on the MARC record, see this pbwiki page
http://futurelib.pbwiki.com/Data+and+Studies where I put some of the
results of a study I did. And this page
(http://futurelib.pbwiki.com/DataFormatIssues) enumerates some of the
limits we have run up against.
kc
> Mark Andrews
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Sun May 27 2007 - 08:07:49 EDT