Comments on: Is MARC a data model? http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/ The occasional rambling of a digital library artisan Mon, 22 Feb 2010 22:08:57 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Bill Dueber http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/comment-page-1/#comment-93469 Bill Dueber Mon, 10 Aug 2009 20:39:46 +0000 http://lackoftalent.org/michael/blog/?p=452#comment-93469 One thing to not lose in this discussion is that not only do we mean two things when we say MARC -- AACR2 and the transmission format -- but that the latter influences and restricts the former. What I don't know is how many (incredibly smart) library folks are restricted in their ability to think about our data because they're internally influenced by the format of tag/ind1/ind2/subfield/string-value, although it's hard to look at RDA and think that (at least on average) our capacity to conceptualize new data models is unfettered by the limitations of the MARC data format. One thing to not lose in this discussion is that not only do we mean two things when we say MARC — AACR2 and the transmission format — but that the latter influences and restricts the former.

What I don't know is how many (incredibly smart) library folks are restricted in their ability to think about our data because they're internally influenced by the format of tag/ind1/ind2/subfield/string-value, although it's hard to look at RDA and think that (at least on average) our capacity to conceptualize new data models is unfettered by the limitations of the MARC data format.

]]> By: Jodi Schneider http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/comment-page-1/#comment-93468 Jodi Schneider Mon, 10 Aug 2009 18:35:52 +0000 http://lackoftalent.org/michael/blog/?p=452#comment-93468 I wish we could disambiguate MARC: "MARC now means multiple things, several of which it was never designed to be (such as a content/data model/standard)." Is anyone seriously working on that? Is there any sense in which RDA or the DCMI work will contribute to such a separation? I wish we could disambiguate MARC:
"MARC now means multiple things, several of which it was never designed to be (such as a content/data model/standard)."

Is anyone seriously working on that? Is there any sense in which RDA or the DCMI work will contribute to such a separation?

]]> By: Shana http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/comment-page-1/#comment-93467 Shana Mon, 10 Aug 2009 17:41:30 +0000 http://lackoftalent.org/michael/blog/?p=452#comment-93467 MARC21 actually includes five different formats for different purposes: bibliographic, authority, holdings, classification, and community information. Ultimately it is a syntax, with a communications piece and a data piece. There was a session at ALA Annual in Chicago (July 2009) called "The Future of MARC" which was immensely helpful in teasing out what MARC actually is and all the differences, in particular Rebecca Guenther's and Diane Hillmann's presentations. There's a recording available: http://library.csun.edu/mwoodley/Future_MARC10Jul2009.mp3 There are lots of limitations to MARC, of which you've mentioned a couple. I think you're on the right track. It's a tricky issue to tease out, mainly because we use MARC to mean multiple different things in the library world. As for AACR2, it should fall out of the discussion as it is a separate piece from MARC. We use MARC to "hold" AACR2 data, but they are fundamentally different (AACR2 is a set of cataloging rules/guidelines defining the data, MARC is a carrier for the data defined by those rules). MARC21 actually includes five different formats for different purposes: bibliographic, authority, holdings, classification, and community information. Ultimately it is a syntax, with a communications piece and a data piece.

There was a session at ALA Annual in Chicago (July 2009) called "The Future of MARC" which was immensely helpful in teasing out what MARC actually is and all the differences, in particular Rebecca Guenther's and Diane Hillmann's presentations. There's a recording available: http://library.csun.edu/mwoodley/Future_MARC10Jul2009.mp3

There are lots of limitations to MARC, of which you've mentioned a couple. I think you're on the right track. It's a tricky issue to tease out, mainly because we use MARC to mean multiple different things in the library world.

As for AACR2, it should fall out of the discussion as it is a separate piece from MARC. We use MARC to "hold" AACR2 data, but they are fundamentally different (AACR2 is a set of cataloging rules/guidelines defining the data, MARC is a carrier for the data defined by those rules).

]]> By: Michael Giarlo http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/comment-page-1/#comment-93466 Michael Giarlo Mon, 10 Aug 2009 14:44:16 +0000 http://lackoftalent.org/michael/blog/?p=452#comment-93466 @Ed: Thanks for the reference. That's helpful for grounding. Here's the <a href="http://cies.hhu.edu.cn/pweb/~zhuoming/teachings/POD/N4/English%20Readings/%28POD-R1-2%29%20Data%20models%20in%20database%20management.pdf" rel="nofollow">link (PDF)</a> for others if they're interested: @Shana: I'd be interested in hearing if my understanding of the issues, the bullet-points down near the bottom of my post, sounds about right to you. I tried to tease apart the different senses of MARC and also concluded that AACR2 may be beside the point. @Ed: Thanks for the reference. That's helpful for grounding. Here's the link (PDF) for others if they're interested:

@Shana: I'd be interested in hearing if my understanding of the issues, the bullet-points down near the bottom of my post, sounds about right to you. I tried to tease apart the different senses of MARC and also concluded that AACR2 may be beside the point.

]]> By: Shana http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/comment-page-1/#comment-93465 Shana Mon, 10 Aug 2009 14:13:20 +0000 http://lackoftalent.org/michael/blog/?p=452#comment-93465 MARC is not a data model. It is a transmission standard. Even the punctuation used within MARC is not dictated by MARC, but rather typically by ISBD. Other data models and punctuation standards beyond AACR2 and ISBD also use MARC for transmission (how else do we get those German records into OCLC?). It's a carrier, not a model. MARC was never supposed to be a data model. The problem is we, as librarians, have "MARC on the brain" (as described by Diane Hillmann). MARC now means multiple things, several of which it was never designed to be (such as a content/data model/standard). In addition, MARC is frequently used interchangeably with AACR2, which is not correct. Until we separate MARC from how we think about our data, it will be difficult for libraries and librarians to move forward into a world of linked data and true data models. 'Cause the data is good, it's just the carrier (MARC) that's so restrictive and flat. MARC is not a data model. It is a transmission standard. Even the punctuation used within MARC is not dictated by MARC, but rather typically by ISBD. Other data models and punctuation standards beyond AACR2 and ISBD also use MARC for transmission (how else do we get those German records into OCLC?). It's a carrier, not a model.

MARC was never supposed to be a data model. The problem is we, as librarians, have "MARC on the brain" (as described by Diane Hillmann). MARC now means multiple things, several of which it was never designed to be (such as a content/data model/standard). In addition, MARC is frequently used interchangeably with AACR2, which is not correct. Until we separate MARC from how we think about our data, it will be difficult for libraries and librarians to move forward into a world of linked data and true data models. 'Cause the data is good, it's just the carrier (MARC) that's so restrictive and flat.

]]> By: Ed Summers http://lackoftalent.org/michael/blog/2009/08/10/is-marc-a-data-model/comment-page-1/#comment-93464 Ed Summers Mon, 10 Aug 2009 13:37:04 +0000 http://lackoftalent.org/michael/blog/?p=452#comment-93464 Nice post. Your summary seems pretty much spot on to me. You got me thinking (not for the first time) about the definition of a "data model". Like you, I entered a maze of twisty little wikipedia pages. 15 minutes later I found myself gazing slack-jawed at Codd's paper where he defined "Data Model" for the first time <a href="http://tinyurl.com/lstv5b" rel="nofollow"></a> . The Intarwebs, they are truly astounding. It's interesting to me that Codd himself had to convince people that a data model should be considered distinct from its physical implementation. This seems like the same sort of conflation that happens when people consider MARC transmission format to be a data model. <blockquote> Numerous authors appear to think of a data model as nothing more than a collection of data structure types. This is like trying to understand the way the human body functions by studying anatomy but omitting physiology. The operators and integrity rules ... are essential to any understanding of how the structures behave. </blockquote> Kinda interesting to see how people argued (and presumably still do) about what a data model is. Nice post. Your summary seems pretty much spot on to me. You got me thinking (not for the first time) about the definition of a "data model". Like you, I entered a maze of twisty little wikipedia pages. 15 minutes later I found myself gazing slack-jawed at Codd's paper where he defined "Data Model" for the first time . The Intarwebs, they are truly astounding.

It's interesting to me that Codd himself had to convince people that a data model should be considered distinct from its physical implementation. This seems like the same sort of conflation that happens when people consider MARC transmission format to be a data model.

Numerous authors appear to think of a data model as nothing more than a collection of data structure types. This is like trying to understand the way the human body functions by studying anatomy but omitting physiology. The operators and integrity rules … are essential to any understanding of how the structures behave.

Kinda interesting to see how people argued (and presumably still do) about what a data model is.

]]>