RE: Are MARC subfields really useful ?

Posting to NGC4LIB

Gray-Williams, Donna wrote:

I’ve been following all of these discussions about MARC and its limitations, and sometimes it’s beyond me because I’m not especially familiar with XMTL and the like–so here’s my question:
Why can’t MARC be expanded to function like these other formats if the data isn’t presented in a ideal way to be extracted? Why does it have to be totally thrown out to adopt something completely different? Is that so impossible?

I would like to point out the difference between MARC in its different formats: there is MARC21, UNIMARC, etc. Trying to bring these together is one level of complexity. Then there is the point I bring up, its ISO2709 problem, which is at a level deeper.

An example of some basic structural problems with MARC21 is that it is based on a single main entry, i.e. the 1xx field is not repeatable. Therefore, we have in-depth rules for determining a single main entry although there may be many other authors just as important. While the single main entry was absolutely critical in a printed/card catalog, and in fact, the idea of “multiple main entries” in the card catalog was nonsensical, in computerized records, we have the same problem from the opposite point of view: the idea of making the 1xx field non-repeatable is just as nonsensical.

Yet, if we just decide to make the 1xx field repeatable, we have problems in other fields that allow only single main entries, e.g. analytics and subjects. So for example, while you could easily do something like:
100 1_ |a Masters, William H.
100 1_ |a Johnson, Virginia E.
100 1_ |a Kolodny, Robert C. |d 1946- (I made up thie date)
245 10 |a Masters and Johnson on sex and human loving / |c William H. Masters, Virginia E. Johnson, Robert C. Kolodny.

You run into trouble with another book about this book:
600 1_ |a Masters, William H. |t Masters and Johnson on sex and human loving.
(how do we add Johnson and Kolodny?)

So, therefore, if we would make 1xx repeatable, it means that we would have to make the related subfields in 6xx, 7xx and 8xx repeatable as well. This is complex and one reason why we remain stuck with figuring out a single main entry, all remnants of the bygone print world. While it may be possible to fix this with our current formats, this would become much more complex and there are better formats to work with.

None of this presents any difficulties in more robust formats like XML, which could easily have something like:
<subject>
<author>Masters, William H. </author>
<author>Johnson, Virginia E. </author>
<author>Kolodny, Robert C.
<dateOfBirth>1946-</dateOfBirth></author>
<title>Masters and Johnson on sex and human loving.</title>
</subject>

Each field and subfield can easily be entered. When you begin to play with it, the sky is the limit and you can even create things that look totally weird to an experienced cataloger:
<subject>
<author>Masters, William H. </author>
<author>Johnson, Virginia E. </author>
<author>Kolodny, Robert C.
<dateOfBirth>1946-</dateOfBirth></author>
<title>Masters and Johnson on sex and human loving.</title>
<pubInfo>
<place>Boston</place>
<publisher>Little, Brown</publisher>
<dateofPublication>c1986.</dateofPublication>
</pubInfo>
<physicalDetails>
<paging>598 p.</paging>
<illustrations>ill.</illustrations>
<dimensions>25 cm.</dimensions>
</physicalDetails>
<edition>
<statement>Rev. ed. of:</statement>
<title>Human sexuality.</title>
<edition>2nd ed.</edition>
<dateofPublication>c1985.<dateofPublication>
</edition>
<notes>
<bibligraphyNote>Bibliography: p. [565]-580.</bibligraphyNote>
</notes>
</subject>

I’m not saying we should do this, but we could. Instead of entering all of this information manually, it could be imported as well, which is at least some of the idea of FRBR/RDA. (I personally don’t think the problems lie with the cataloging rules–RDA even retains single main entry–but with the formats, which are simply worn out and unused by everyone in the world except libraries)

There are lots of other problems with MARC as well, including MARCXML–primarily because it must be “round-trippable” between XML and ISO2709 and as a result, the limitations of ISO2709 are transferred en masse into MARCXML.

So, the idea of reworking ISO2709 seems to me a bizarre, modern example of the old “Horsey Horseless” from 1899. http://tinyurl.com/2ayd3h

It’s time to move on. And when we do, I am pretty sure that we and our users will find it all much more interesting than what we have today.

-227

Share