Jester's Cap

Disruptive Library Technology Jester

We're Disrupted, We're Librarians, and We're Not Going to Take It Anymore

Main menu

Skip to primary content
Skip to secondary content
  • About the Blog
  • About the Author
  • About the Tagline
  • Comment Policy
  • Contact

Post navigation

← Previous Next →

MARC isn’t Dead, but it is a Dead End

Posted on October 29, 2010 by Peter Murray
This entry was posted in L/IS Profession and tagged AACR, American Library Association, Functional Requirements for Bibliographic Records, Karen Coyle, linked data, MARC, metadata, Resource Description and Access, semantic web by Peter Murray. Bookmark the permalink.

This week I sat in on the first of the three “Using RDA: Moving into the Metadata Future” webinars being hosted by ALA. This one was hosted by Karen Coyle with the title New Models of Metadata where she talked about library-specific efforts such asRDA and FRBR as well as the linked data effort in the wider world of information. There was a great deal of concern expressed in the chat window by participants about the future of cataloging, of cataloguers, and of MARC. The latter brought up memories of Roy Tennant‘s “MARC Must Die” declaration. My take away, though, isn’t that MARC is dead as much as MARC is a dead end.

Cover art from 'Library of the Dead' audio book


MARC, not dead yet?


We know that MARC isn’t dead; the communications format, along with its AACR2 companion rules for describing bibliographic resources, are deeply and daily ingrained in our systems and processes. For the same reasons, I think it is fair to say that MARC isn’t dying. (The fate of AACR2 with respect to RDA may be a little closer to the edge.) What I propose, though, is that MARC is a dead end. Karen makes a comment — On the brokenness of MARC — that starts to enumerate some of the basic issues with the MARC format. (Karen’s writings from 10 years ago lists even more details.) Also, as Karen pointed out in her presentation (and many others have done before her), MARC is a format that is only used in the library community. As a communications format, it is cumbersome — requiring those outside the library community to use custom code toolkits to read and write the format. That is a pretty high barrier for the wider world to want to use library bibliographic data encoded in MARC.

What trips up our community even more, I think, is that we have a tendency to equate this communications format with mental model of how we describe things from a bibliographic point of view. We think of discrete records that describe these things rather than a network (or, more accurately, a graph) of interrelated nodes. This forces us to focus on the textual content of fields and not on the relationships between things. And in doing so, we are not making the best use of our limited efforts to describe the things in our curatorial care.

MARC may not be dead, but it is a dead end.

Link to this post!

Share this:

Links in "MARC isn’t Dead, but it is a Dead End"

Tags for "MARC isn’t Dead, but it is a Dead End"

Find Related Content: within DLTJ Technorati del.icio.us Wikipedia
AACR Find posts tagged 'AACR' in DLTJ Find posts tagged 'AACR' in Technorati Find posts tagged 'AACR' in del.icio.us Find posts tagged 'AACR' in Wikipedia (English)
American Library Association Find posts tagged 'American Library Association' in DLTJ Find posts tagged 'American Library Association' in Technorati Find posts tagged 'American Library Association' in del.icio.us Find posts tagged 'American Library Association' in Wikipedia (English)
Functional Requirements for Bibliographic Records Find posts tagged 'Functional Requirements for Bibliographic Records' in DLTJ Find posts tagged 'Functional Requirements for Bibliographic Records' in Technorati Find posts tagged 'Functional Requirements for Bibliographic Records' in del.icio.us Find posts tagged 'Functional Requirements for Bibliographic Records' in Wikipedia (English)
Karen Coyle Find posts tagged 'Karen Coyle' in DLTJ Find posts tagged 'Karen Coyle' in Technorati Find posts tagged 'Karen Coyle' in del.icio.us Find posts tagged 'Karen Coyle' in Wikipedia (English)
linked data Find posts tagged 'linked data' in DLTJ Find posts tagged 'linked data' in Technorati Find posts tagged 'linked data' in del.icio.us Find posts tagged 'linked data' in Wikipedia (English)
MARC Find posts tagged 'MARC' in DLTJ Find posts tagged 'MARC' in Technorati Find posts tagged 'MARC' in del.icio.us Find posts tagged 'MARC' in Wikipedia (English)
metadata Find posts tagged 'metadata' in DLTJ Find posts tagged 'metadata' in Technorati Find posts tagged 'metadata' in del.icio.us Find posts tagged 'metadata' in Wikipedia (English)
Resource Description and Access Find posts tagged 'Resource Description and Access' in DLTJ Find posts tagged 'Resource Description and Access' in Technorati Find posts tagged 'Resource Description and Access' in del.icio.us Find posts tagged 'Resource Description and Access' in Wikipedia (English)
semantic web Find posts tagged 'semantic web' in DLTJ Find posts tagged 'semantic web' in Technorati Find posts tagged 'semantic web' in del.icio.us Find posts tagged 'semantic web' in Wikipedia (English)

Related Posts on Disruptive Library Technology Jester

  • The Problem with MARC and AACR: the World Doesn’t Disco Anymore
  • Solr-ized MARC Record Catalog
  • Defining Metadata and Making Metadata Accessible
  • Real Life Example of Creative Commons License Applied to MARC Records

Track and Share With Others

• Technorati iconTechnorati Cosmos

• TrackBack URI


Logging In...

Profile cancel

Sign in with Twitter Sign in with Facebook
or

Not published

  • 21 Replies
  • 20 Comments
  • 0 Tweets
  • 0 Facebook
  • 1 Pingback
Last reply was March 9, 2012
  1. Diane Hillmann
    View October 29, 2010

    Peter, we’ve started to talk about MARC as a ‘fairly lossy exchange format’, with the notion that yeah, it’ll be around for a lot more years, but no longer at the center of our universe.

    Reply
  2. Peter Murray
    View October 29, 2010

    Ah! I think that is a good way to think of MARC now — something that you’d want to transform out of, but not something you’d want to go back to because you couldn’t get the same content fidelity.

    Reply
  3. nathalie vielleuse
    View October 30, 2010

    marc is dead ???
    http://dltj.org/article/marc-as-dead-end/

    Reply
  4. Suzuki Takao
    View October 31, 2010

    MARC isn’t Dead, but it is a Dead End (Disruptive Library Technology Jester) http://bit.ly/9erW9f

    Reply
  5. Ron Murray
    View October 31, 2010

    Peter: MARC was very much a child of it’s time – an effort to develop a “practical” data format for bibliographic information which had resided largely on catalog cards. The format was modeled and defined very quickly. As we critique MARC’s deficits now, we should make sure that we are not doing so from the point of view of another “practical” resource description approach that will require replacement in time as well.

    FRBR – as a resource description theory – possesses great reach and precision (e.g., this exemplar which connects an 8th C. Chinese poem to a 21st C. Sign Language performance of it on a web page – https://files.me.com/kandroma1/6r9uhv). This does not mean that “practical” implementations of FRBR will inevitably realize its full capabilities.

    Just as we (can!) critique commercial relational databases from the POV of the Relational Model to see how well they implemented useful & powerful ideas in the model, we can do the same for FRBR implementations with respect to a well-articulated FRBR model.

    Reply
  6. George Duimovich
    View November 1, 2010

    I agree, only I’m surprised and dismayed by the apparent lack of urgency with the situation. There are some real challenges to be sure, but still too many in our community don’t see anything wrong with duplicating data (e.g. 034 vs. 255), or in continuing on with the ‘rule of three’ with regards to, say, authors (yes, let’s make it even harder for people to find things!). I don’t bash tech services but we need a greater sense of urgency from all towards having better machine-readable data, essential to “playing ball” with any modern web infrastructure.

    IMO, some of the work with institutional repositories offers some glimpse into a future out of the MARC/AACR2 prison, one where multiple bibliographic schemas can coexist together (e.g. see the Fedora Commons content model). The IR space also teaches us that we’re no longer the only game in town with regards to bibliographic standards. Yep, and some communities won’t ever want to come back once they’ve found their own special standard to meet their needs. Who needs MARC when you can have FGDC or whatever the flavor is for this or that particular community.

    Also critical to this discussion is the idea of **getting help for moving forward.** And recognizing that to change we need to better situate ourselves to get the help we need to actually move forward!! And IMHO that means taking some incremental but critical steps *ASAP* towards much more developer friendly platforms (like open source) and standards (like MARCXML, MODS, etc.). But even those steps need more re-thinking too (e.g. see http://tinyurl.com/2ugmobs).

    Reply
  7. ALA_TechSource
    View November 1, 2010

    RT: MARC isn’t Dead, but it is a Dead End @DataG post #lldata http://bit.ly/a0CWtK

    Reply
  8. John Ridener
    View November 1, 2010

    Good assessment of MARC | RT @ALA_TechSource: RT: MARC isn’t Dead, but it is a Dead End @DataG post #lldata http://bit.ly/a0CWtK

    Reply
  9. Susan Berdinka
    View November 1, 2010

    RT @ALA_TechSource: RT: MARC isn’t Dead, but it is a Dead End @DataG post #lldata http://bit.ly/a0CWtK

    Reply
  10. Ana C. Griebler
    View November 1, 2010

    RT @ALA_TechSource: RT: MARC isn’t Dead, but it is a Dead End @DataG post #lldata http://bit.ly/a0CWtK

    Reply
  11. Peter Murray
    View November 2, 2010

    Ron: What we face now is somewhat of a unique situation, and I say this with some hesitation since the future cannot be predicted. The monumental task before us is to change from a “machine readable” format to a “machine actionable” format. MARC is machine-readable in the sense that its original mission was to automate the process of reproducing cards for a card catalog. What is needed is a machine-actionable format; the leading thought on this appears to be coming from the linked data community.

    I don’t doubt that the next format won’t be the last format. That said, I don’t think the next transition will be as painful as this one from machine-readable to machine-actionable. What we have now is not only large change of systems and workflow, but also a large conceptual change about how bibliographic data is viewed inside the community (and potentially how it can be used outside the community).

    Reply
  12. Celine Carty
    View November 2, 2010

    Wish I had attended these webinars -good read on MARC "not dead, but a dead end" from @DataG http://dltj.org/article/marc-as-dead-end/

    Reply
  13. Peter Murray
    View November 2, 2010

    George: I’m not surprised as much. There is a whole lot of momentum behind the status quo: processes, training, documentation, software, contracts, service agreements, etc. That much weight behind a standard makes it hard to turn quickly. But, much like one needs to nudge an asteroid heading on a doomsday collision course with Earth by altering its course while it is far off in the distance, there are efforts afoot to change this. (How about that for election season hyperbole on how we are all going to die if we don’t change right now!) The three webinars in the “Using RDA” series are an example of how the ground is shifting. I also hope highlighting MARC as “dead end” rather than simply wishing it dead could be considered part of that effort. (This has certainly been the most tweeted and re-tweeted post I’ve written.)

    I take Alexander’s critique of MARCXML (the link you included at the end of your comment) with a grain of salt. MARCXML certainly loses points for self-documenting readability, but as a commenter pointed out the roots of MARCXML lie in its round-trip nature with binary MARC. Where I disagree with Alexander is that:

    <datafield tag="245" ind1="1" ind2="0">
      <subfield code="a">Arithmetic /</subfield>
    </datafield>

    is the same as:

    <title>Arithmetic</title>

    That is the equivalent of saying the definition of Dublin Core element Title is the same as the MARC 245 tag. The definition of the former is simply “A name given to the resource.” It is possible to say quite a bit more with the latter — titles, subtitles, non-filing characters, dates, etc. One can quibble whether this information really needs to be captured, but it cannot be disputed that the MARC 245 tag is more expressive.

    That the institutional repository space takes us out of “the MARC/AACR2 prison” is a useful thing to think about. As you point out, there is software there that can be used to describe resources in the most expressive manner necessary for the target community while still having ways to pull information back together for cross-community searching. I’m a big fan of Fedora and although I’ve been on the edges of that community for a while I did give some thought half a decade ago on how desciptions datastreams can best be used in Fedora objects.

    The text was modified to update a link from http://dltj.org/tag/fedora-dr/ to http://dltj.org/tag/fedora/ on January 19th, 2011.

    Reply
  14. Ron Murray
    View November 2, 2010

    I agree that *some* of the leading thought comes from the linked data community, in the course of addressing data representation issues familiar to themselves. This does not mean that the current range of linked data solutions satisfies all of *our* needs. This is where attention to FRBR data modeling becomes important – so that we can express our needs in a common language.

    For example, the concept and implementation of a Named Graph (implemented as “packaged” RDF statements) is perfectly adequate for representing data derived from a single point of view on a resource. Except that they did not finish their homework assignment: graphs can contain subgraphs – and so should Named Graphs.

    This current limitation to Named Graph definition impacts a significant data modeling finding in our community: FRBR resource descriptions document multiple, complementary, points of view on target resources. This characteristic is readily modeled as a resource description subgraph for each POV. In the absence of the ability to define subgraphs, collapsing data that represents complementary descriptions into a single-level graph becomes a lossy process.

    Even though the scientific community is well aware of the complementarity of some descriptions of phenomena (Neils Bohr, after all…), parties participating in the linked data initiative have not (as far as I can tell) engaged that issue. More problematic than myriad recognitions and idiosyncratic solutions to the complementarity of description issue would be no attention to it at all.

    The best strategy would be to finish the homework assignment and provide a uniform solution for this particular issue.

    Of course it’s very early in the linked data scheme of things, and everyone (me too!) is aglow with the simple *availability* of it all. This also means that there is time to examine – and grow – the concept of linked data to include more sophisticated perspectives on that data.

    Reply
  15. ALA_TechSource
    View November 6, 2010

    MARC isn’t Dead, but it is a Dead End @DataG post #lldata http://bit.ly/a0CWtK

    Reply
  16. heather pena
    View November 7, 2010

    RT @ALA_TechSource: MARC isn’t Dead, but it is a Dead End @DataG post #lldata http://bit.ly/a0CWtK

    Reply
  17. Sergi Montes
    View November 8, 2010

    RT @ALA_TechSource: MARC isn’t Dead, but it is a Dead End @DataG post #lldata http://bit.ly/a0CWtK

    Reply
  18. Susan Berdinka
    View November 8, 2010

    I addressed this issue in my article “Some thoughts about FRBR—It is a Beautiful Thing” (http://susanrb.wordpress.com/2010/10/30/some-thoughts-about-frbr%e2%80%94it-is-a-beautiful-thing/).

    The Marc record itself is an entity—a specific bibliographic edition. Within that entity are other entities. FRBR adds the aspects of work, expression, and manifestation. Mathematically speaking, an entity can contain other entities. These entitles should be stored outside of the bibliographic entity each in their own table, and only REFERENCED from the Marc bibliographic record.

    I don’t think marc is a dead end – I think it simply needs mathematical normalization.

    Reply
  19. Ron Murray
    View November 9, 2010

    The critical issue from my perspective is that FRBR specifies networks of resource descriptions.**

    The MARC record – a child of its times, IT-wise – does not readily support the specification of network structures (a.) within a single MARC record, or; (b.) across multiple MARC records. For example – and even though it is conceivable – I have not yet seen “zoned” MARC records.

    A zone within a MARC record could host its own unique IDs, which would serve as link origins/destinations for whatever purpose. Tags placed within a zone would subsequently be reference-able from elsewhere in the same record or from other records. One hopes there would be a logical reason for putting tags in the same zone. Of course, zoning a MARC record like this would indicate that information representing different types/levels of bibliographic description – FRBR’s W|E|M|I – are jammed together into a single storage unit – and perhaps should no longer be.

    Note that networks – being graph structures capable of representation as sets – could undergo a normalization process. Recall though (sorry, Dr. Codd!), that normalization can be taken too far.

    ** See: http://www.slideshare.net/RonMurray/the-graph-theoretical-library (Slides# 80-102). If you like the Gardens of Versailles and graph theory, start at the beginning.

    Reply
  20. Peter Murray
    View November 9, 2010

    Susan — thank you for responding to my tweet and linking to your post in a comment. I would agree that normalization is one issue with MARC and its current usage today. If authorities in bibliographic records were defined as identifiers (say, a URI) to an authority record, we would start to eliminate the issues of findability, and you talk about in your blog. As Ron Murray points out in his comment, when normalizing what we use as bibliographic records now, it isn’t long before we get into graphs of entities linked by meaningful predicates. Unfortunately, I haven’t seen evidence that MARC — as a communications format — can effectively transmit graphs of entities.

    Beyond that issue, though, is that MARC is used by no one but libraries, and as such will always be an inwardly-facing format. If we only want library systems to talk with other library systems, that would be okay. I don’t think such an inwardly-facing focus is good for the health of our profession. The rest of the information world won’t come to us; we will need to meet it more than half-way by using more commonly accepted data formats.

    Reply
  21. What ... in scope — Council on Library and Information Resources
    View March 9, 2012

    Kramer auto Pingback[...] Peter Murray adds this note about constraints embedded in the mental model that evolved alongside library metadata practice [...]

    Reply

Home

Search

Recent Posts

  • LYRASIS’ “Reposervice” Setup Pushed to GitHub
  • Code4Lib Journal Issue #20 Published; My Editorial: “It is Volunteers All the Way Down…”
  • Notes on the Code4Lib Virtual Lightning Talks
  • Interlibrary Loan Standards Undergoing Revision at the ISO Level
  • Vote for an ALA2013 Ignite Session on Open Source Communities
  • A Great iPad Keyboard/Case Combination: New Trent Airbender

Archives

  • 2013: J F M A M J J A S O N D
  • 2012: J F M A M J J A S O N D
  • 2011: J F M A M J J A S O N D
  • 2010: J F M A M J J A S O N D
  • 2009: J F M A M J J A S O N D
  • 2008: J F M A M J J A S O N D
  • 2007: J F M A M J J A S O N D
  • 2006: J F M A M J J A S O N D
  • 2005: J F M A M J J A S O N D

Feeds and Such

  • Link to Podcast (RSS feed) for this blog
    Add Podcast to iTunes subscription
    Receive DLTJ by e-mail:


    Delivered by FeedBurner
  • View Peter Murray's profile on LinkedIn

Copyright

This work by Peter Murray is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States.

Creative Commons License
© 2013 | Theme based on Twenty Eleven by Wordpress.org | DLTJ strives for Standards Compliant XHTML & CSS | RSS Posts & Comments
From the Disruptive Library Technology Jester (http://dltj.org/), printed on Thursday the 20th of June 2013 at 3:39:36 AM UTC (+0000). The URL to this page is

[Creative Commons Logo] This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/us/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
This work by Peter Murray is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States.