Great comments. A couple of thoughts...
Compactness. As a developer, I like how concise MARC is.. I even enjoy
the numerical tags and the aspiration of language neutrality. ISO2709
(aka NISO Z39.2) just brings a big smile to my face. I thought it was
funny that MARCXML typically takes up about an order of magnitude more
space to represent the same information. But you can't fool gzip, it
all compresses to the same space and ultimately it probably doesn't
matter. MARCXML is butt ugly but I really like it that you can use
standard tools to manipulate it and it eliminates character set issues.
I didn't think it could get any 'worse' than that, but I was just
looking at a MARCXML record side by side with its BIBFRAME2 equivalent
yesterday, and I'll be darned if the latter didn't look like 3-4 times
as many lines to my eyes (I didn't try to quantify). Our forefathers
would laugh!!! Compact or easy to approach BIBFRAME is not. Once when I
asked someone to convince me to like LD as a paradigm for representing
bibliographic data (I am a professional luddite), he asked me to
consider the benefits that XML/UNICODE have brought to our lives in
terms of simplifying the raw representation of things. Bringing in LD
technologies shows a promise of raising that to the next level by
bringing in semantics as well. This is intriguing to me, but I'm still a
sceptic -- LD tech promises certain things "for free", but to get our
messy bibliographic data to a point where the magic happens, you're
gonna need a lot of cleaning up. OCLC levels of horsepower.
Jeff, I liked your comments about how MARC evolved as a 'language' for
catalogers. This weird sideways step from computer exchange format to
human language (with all that that implies) has always puzzled and
confused me as a relative newcomer (26 years or so) in the industry, and
it drives me up the wall when some people assume this will be carried
forward into a BIBFRAME environment. You hit it right on the head when
you say "The interface for which the catalogers have to use CANNOT BE
lots of XML coding." I would take that a step further.. if BIBFRAME is
to play a role in cataloging, I personally believe that the whole
process will have to be MUCH more "facilitated" or guided/supported by
the underlying software. In other words, as you start to fill in data,
the software should look for existing entities or assertions made
available by trusted sources, create the links and populate fields as
you go along. The ergonomics will be quite different from conventional
MARC (copy) cataloging. But if the goal is a 'web' of interconnected
bibliographic entities, I think the platform must provide this kind of
support.... it has to be easier/faster to do it 'right' than not.
Again, BIBFRAME isn't just a new format in which to express the same
thing.. it forces or at least encourages a complete re-think of
established workflows. I think this is a Good Thing and may ultimately
be where the real value emerges.
On 2/3/17 10:53 AM, Jeffrey A Trimble wrote:
> So, from another “Jeff” not to confuse anyone.
> It is interesting to note that historically the MARC format (USMARC,
> MARC21, and other MARC-like standards) was created for two purposes:
> transmission of cataloging data from one computer to another and of
> course the creation of catalog cards. But when Henrietta Avram was
> creating the MARC structure, everyone was flying blind—she just lead
> one way which we all adopted. So some points for consideration:
> 1. MARC21 is a storage format for computer to computer transmission.
> Nothing more and nothing less. It is compact and computers can
> understand is and programmers look at it and go “nice, neat and
> compact”. The MARC21 format is best stored as a flat file like VSAM
> records (Think IBM Mainframe, CICS, 370 Assembler).
> 2. By the 1970s, cataloging were coding AACR1 data into MARC using
> the MARC tagging convention because OCLC never developed an input
> interface to enter the data easily.
> 3. By the 1980s several Universities had created Library Management
> Systems that in turn became Library Automation companies (Northwestern
> with NOTIS, Berkley with Innovative Interfaces, GEAC, Dynix, etc.)
> They were using the MARC21 record structure to create indexes and
> presentation screens of the data.
> Now we jump to the 21st century. You have the following issues that
> are facing Catalogers mainly, but others too.
> 1. MARC21 doesn’t lend itself to the semantic web. Why? Well no
> programmer looked at the data structure and said “Ah that looks like
> something we should attempt to index”. If it’s not XML, RDF, HTML,
> etc, it must not be good enough. Okay, I’ll acquiesce to that one,
> though misguided.
> 2. You have two generations of Catalogers, whom are experts in data
> delineation, description, access points, etc, who are trained on
> MARC21 via OCLC and their local systems.
> 3. LMS vendors have no incentive to add a BibFrame component as a
> “freebie” to their software at this time, and maybe they never will.
> There is going to be considerable investment made and that cost will
> be borne by the purchasers. And let’s face it, the public is not keen
> on supporting libraries and at universities the budget is even tighter.
> Some realities:
> 1. Libraries will only move to a new format structure when it is part
> of the system without having to “rebuy” the software. (Each time
> MARC21 has had a major update, we haven’t bought new systems…think of
> format integration from 1994).
> 2. The interface for which the catalogers have to use CANNOT BE lots
> of XML coding. That will just not fly. The screens must be clean and
> quick for input. Too much clicking, too much drop downs, just slows
> down the process of original cataloging. (Remember one can code a
> MARC21 record in under 15 minutes without touching one mouse click)
> 3. If there is to be a replacement for MARC21, it must be a strict
> standard that allows some flexibility.
> Oh one one personal diatribe of cataloging rules: The storage format
> (MARC21 or XML, RDF, whatever) should be agnostic to any Cataloging
> Rule set. On the flip side, Cataloging Rules should not be written
> specifically towards a favorite storage format. The Cataloging Rule
> should be Agnostic for storage.
> So will MARC21 get replaced? You bet it will. Will I support it?
> You bet—but it must be superior to MARC21 in all aspects
> (capabilities, specificity, compactness, adaptability).
> So, it will take some time for BIBFRAME to develop into a new standard
> for storage of cataloging data. Anyone remember AACR3? I believe
> that’s what morphed into RDA. So, perhaps BIBFRAME will morph into
> something else that we cannot foresee.
> I think it is excellent that there are diverse opinions on here and we
> all can learn from different points of view.
> Thanks for your time and consideration.
> Jeffrey Trimble, MLS
> William F. Maag Library
> Youngstown State University
> 330.941.2483 (Office)
> [log in to unmask]