LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  February 2017

BIBFRAME February 2017

Subject:

Re: Failure

From:

Sebastian Hammer <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Fri, 3 Feb 2017 11:58:11 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (151 lines)

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
>
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager