Jeff,

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.

My 2c.

--Sebastian




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.
>
> Jeff
>
> Jeffrey Trimble, MLS
> William F. Maag Library
> Youngstown State University
> 330.941.2483 (Office)
> [log in to unmask]
> http://www.maag.ysu.edu
> http://digital.maag.ysu.edu
>
>