LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


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

BIBFRAME September 2011

Subject:

Re: Description and Access functions in a post-MARC environment?

From:

Jeffrey Trimble <[log in to unmask]>

Reply-To:

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

Date:

Sun, 25 Sep 2011 15:35:30 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (65 lines)

On Sep 25, 2011, at 12:17 PM, Karen Coyle wrote:

> Jeffrey,
> 
> You almost had me, up until the "baby and bathwater" statement. MARC is the bathwater; the baby is our data. There is no need to lose any data as we move forward, but we can lose some of the oddities of MARC that are making it hard to add new information to our record format. For example, we do not have a way in MARC to associate an identifier with a particular set of subfields within a field. Although a $0 has been added to the MARC format so that it can accept some of the RDA data, the subfield remains ambiguous in some fields, and therefore isn't usable in the intended way (substituting an identifier for a particular data element).
> 
> ISO 2709, the thing that is structured with a Leader, directory and a character string, is a very neat data transportation format -- genius, really. (All hail Henriette! We were so lucky she came to work for libraries.) What we have put into that format, however, is now rife with inconsistencies and ambiguities. If we could have a MARC do-over within ISO 2709 that would be great. However, we would once again find that over time ISO 2709 doesn't scale. We have fields that have used $a-$z and have nowhere to go. Should we have 2-character subfield codes? That doesn't solve the problem of ordering which seems to plague some systems. The 3-digit limitation on tags is also a hindrance, especially since we have designated tag areas to somewhat align with ISBD areas. Some systems have used letters in their tags to expand the record.
> 


So, let's spend the money and the time to revise the MARC structure a little to make sense of things.  We've done this before.  We had format integration in 1993/1994.  And Henrietta Avram even admitted that her biggest mistake was creating different formats and then the authority format.  If she had it all over to do again, she would have created the Authority MARC format and then a Bibliographic MARC format.

Now to the limitations.  I herewith make a proposal, and I should even be sold bold to say that this is something we need to take to MARBI.  As for ISO 2709, let's change it, don't let it box you in.  I propose:

1.	Record Length.  We'll need to adjust the Leader positions of 00-04, and move it to something much higher.  Perhaps push bytes 05-23 further out.  So we can reserve bytes
00-12 for record length (and bytes 05-23 become byes 17-31)  That give you up to 9.999999 TB.  That's one hell of a record.   Do you think you have enough content for that large of a record?  You can now include the actual printed book.

2.	Expand the MARC record to have a 4 character numeric tag, starting with  0001 and continue to 9999.  That too is quite big, many fields repeated, and more fields to define.  Oh boy can we define fields.

3.	Indicator count.  Again, expand it to 3.  We may not use it, but let's get rolling.

4.	Subfield code count.  Again, expand it to 3.  You can then tell the computer that after the "delimiter" ($), you have either a 1 or 2 byte subfield.  I can see us using $aa $ab $ac  (or if you go to 4 character count you
could do something like $a-b $d-a or even $a$b $d$a.  Or even a different delimiter sign as a secondary delimiter.

So you want more content.  I've just answered your question plain and simple, with little disruption to the current structure.  We can easily write conversion programs to deal with current MARC records.

We did something similar to this back in the 1999/2000 glitch.  Most mainframes at that time stored only the last digit in the VSAM records.  What was the answer?   Well, spend Trillions of dollars and throw out the mainframe
and buy a unix box.  (Unix store all 4 digits of the date (at least BSD and AIX).  Instead, what most people did was to address the VSAM record storage issue and expand it by 2 bytes.  This was not at easy task but it was
cheaper than buying new software.  (Oh, yes, IBM was happy to sell you AIX--Sun told you that you needed to get off the Mainframe--the Y2K was going to make you loose your hardware and it wasn't fixable).

Now what I've proposed is simple, straight forward, and most of our ILS vendors and OCLC could do this in a matter of months, maybe a year extra.  We've just bought ourselves several decades of time until technology is so advance we don't even need to worry about the printed word.

I'm no luddite, but in my experience as a programmer, MARC works, xml is just crap.  Every time I have to deal with it, I start charging customers more (in this case, I start to whine a lot at my place of business). 
Institutional Repositories have been using XML with limited success.  In fact, DSpace software now allows you to contribute using an Excel spreadsheet because the XML coding is so difficult for the end user.
We've stopped using XML here at YSU for DSpace contribution.  It's excel and then to Postgres.  I'm finishing up a daemon to take an OCLC export and send it over to DSpace--directly to the postgres database, skipping the XML apart.  Much simpler, and less work and our staff are much happier.

I'm not trying to derail LC and it's move, what I'm saying is think long and hard.  This is a very expensive move and RDA will seem like peanuts--and we already know how much its is disliked by many in our community.

Finally, I have to remind us all that we aren't even using all of the current MARC features, and we want to replace it.  How do you know it needs to be replaced when you haven't even scratched the surface of seeing if we can enlarge it, restructure it, change it up.  It was originally a communications format, not an end user input format.  That said, I can't wait to see some poor cataloger given a blank OCLC screen to input and original and type in xml coding.  Directors will really want to get rid of catalogers because this is really kludgy.

I'm really glad we are having this conversation.  It is long overdue.  We need to continue the dialogue, with respect, and we need to begin asking the simple question "How do we know if MARC is dying if we haven't attempted to push it further?"  And right now, I haven't seen a serious push to restructure and expand it.

Best wishes in programming.

--Jeff Trimble


> I think we should pay less attention to the physical format of our data and more to the CONTENT. I've been working on an analysis of MARC content [1] [2] for a while as a kind of hobby. If we define our content clearly, then we can choose a serialization (or two or three) that simply carries our data, it doesn't define its structure nor would it limit its growth.
> 
> kc
> [1] MARC as Data: A start. Code4lib journal. http://journal.code4lib.org/articles/5468
> [1] Futurelib wiki. MARC analysis. http://futurelib.pbworks.com/w/page/29114548/MARC%20elements
> 
> t

Jeffrey Trimble
System LIbrarian
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
""For he is the Kwisatz Haderach..."

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 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
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