What's Wrong With MARC?

Editor's Notes

• #4: In the beginning was the index card. This is a pre-AARC2 example. This is basically text, designed to be brief but readable by people. The elements are separated by punctuation. None of it makes sense or can be deciphered in isolation. Although genius in its own context, it is also the root of our problems.
• #5: MARC was created to essentially mount that index card onto a computer and share it. It is ideally placed to recreate the index card's data for human consumption. This could be for printing out more index cards, compiling a dictionary catalogue, or even a display screen for an OPAC, at least if you want to recreate the index card layout. Note: punctuation still (although not in UKMARC).
• #6: This is the same thing with an RDA record.
• #7: It's worth bearing in mind that this is what MARC actually looks like! Most of what we actually see of MARC is an abstraction for display or editing. To get any bit of information out, the data needs to pulled apart first. At the top is the Leader (RED), which includes some basic information about the record. Next is the Directory (GREEN), which has information about the fields and their length. The third part is the data itself (BLACK): note the MARC fields are all absent, as are the subfield markers. There are markers there but they are hidden! There is one invisible code to end the record, another to end each field, and a third to mark the beginning of subfields. In the above example, all the hidden codes have been replaced with underscores so you get an idea what's there. In BOLD you can see the 245 field. In ITALICS you can see the 710 field For the directory, Tag (00-02) [3], Length of Field (03-06) [4], Starting character position (07-11) [5]
• #8: What is MARC for? Is it used for these things anymore? Storage: rarely in its pure form. Manipulation: to manipulate MARC, you have to transform it to something else. E.g. in Marcedit. Or do bad thing to it. For example, to index and normalize involves dealing with lots of punctuation, which I'll deal with more in a moment. Display: Designed for traditional catalogue displays and standards, i.e. AACR2. However, the MARC and ISBD card index structure is more often hidden behind a labelled display. In discovery systems, this can be even more abstracted. Input: MARC fields are clearly used for inputting bibliographic data although it's unclear why they have to be. Rob Styles once recounted an anecdote where cataloguers were offered a simpler non-MARC interface and they didn't like it! As RDA is more element-based and takes out the ISBD, there are possibilities of this being more acceptable in the future. See RIMMF. Exchange and distribution. This is where MARC really lives on. To download records from others via z39 Publication. No. You would rarely want to publish your data for others to use as MARC except for immediate loading into another MARC system. See also: Manipulation above. Lingua franca: This is a Rob Styles phrase, which has afflicted many of us, especially those of us who talk to non-cataloguers. We talk of the 245a rather than the title proper. Some non-cataloguers believe that MARC replaced AACR2. Worth bearing in mind for linked data too. Many of the following are rather faults with rules and practices, or even with MARC21 over, say, UKMARC. Again, many non-cataloguers conflate MARC21 with other cataloguing practices.
• #9: If you are familiar with the deficiences of Dewey, which is constrained by its notation. 246 1 (printing/display), 8 (spine title), 4 (non-filing indicators) Answer: SuperMARC of which the last example is a pale shadow. The original proposal: <10 TB record 4 character tags 3 indicators 3 character subfield codes (including the $)
• #10: Admittedly, contexts can vary here, but do note the variety of methods for formatting the content too: codes, controlled full-language, language in free text. There are more possibilities here (130 etc.) but not really within a single record. I has an immense amount of recently with OCLC numbers in ebook records which I think I found in five separate fields formatted in about three different ways: 001 019 035 776 ….
• #11: A particularly MARC21 problem: First, ISBD punctuation only Second, MARC only Both of these make sense on their own. However we put them back together! Third, MARC and ISBD. This makes human editing harder than it needs to be and automatic processing a real headache. Even in RDA.
• #12: Many MARC data elements contain text. Especially when isolated they become harder to make sense of In the ISBN examples, qualifiers are included in the subfield. With the new subfield $q, this is at least partially solved…
• #13: …as this data is moved elsewhere \o/ … although
• #14: … the pricing and availability information still needs punctuation in front of it. 8-( The title and place of publication both have extraneous punctuation after them too. This is important as the place of publication is not "London" as that doesn't adequately identify the place.: Canada France (Burgundy village) USA (8) Christmas Island And an island in Tierra del Fuego Even if we qualify it, there will be variations in qualification. Some books may be under Londinium or Londres. The extent example shows the punctuation for an element divorced from the element it represents. This has to be cleaned out before any processing as to its meaning can take place. Even then, the units in this and the dimensions examples are mixed in with the numbers and can be very variable.
• #15: In the first example, some data about the media type is stuck in the middle of the title! Whatever the benefits of the GMD, this is not a good place to put it. [See also: the $e for relationship designators!!] In the third example, a lot of fine grained data is essentially dumped in a single box and it would be very hard to retrieve it. Clearly in this case, the record is designed only to provide display.
• #16: In the first example, poor Mr Niemeyer has passed away, so the heading changes. This is not helpful for linking or matching. Not to mention the huge maintenance issues. In the second case, preferences changes, or different communities might want to display different strings to users. The third example shows the kind of small textual issues that can break matching based on text matching. LMS's indexing these have to process these to figure out they match. The last of the three is what happens when you use a relationship designator then remove it!!!
• #17: Both these 700s express a relationship of some kind. But what? RDA, and the apparently enthusiastic adoption of relationship designators, has done a lot to address this with the $e. (Although note the weird comma between the heading and the relationship designator!)
• #18: MARC is record based, and that record is essentially a Manifestation record. However, Expression level elements are spread throughout (in red). Work and Expression level elements are implied and not explicit (e.g. title). There are internal relationships here: we know Berners-Lee is an expression level relationship merely by the relationship: the 700 and the $e otherwise give nothing away. Think of the language example given above: machine-readable expression information is all over the place. "Many survey respondents expressed doubt that RDA changes would yield significant benefits without a change to the underlying MARC carrier. "Most felt any benefits of RDA would be largely unrealized in a MARC environment.  MARC may hinder the separation of elements and ability to use URIs in a linked data environment.  "While the Coordinating Committee tried to gather RDA records produced in schemas other than MARC, very few records were received." "Demonstrate credible progress towards a replacement for MARC" -- Report and Recommendations of the U.S. RDA Test Coordinating Committee. Executive Summary
• #19: To do anything, you have to take the MARC file to bits. One piece of information will not stand alone.
• #20: e.g. Primo converts all data, even MARC, into something else before processing.
• #21: Eleven years ago, Roy Tennant addressed in particular, recognising that AACR2 and MARC so closely entwined and focussed on the card catalogue. - Unreadably esoteric format Granularity. E.g. authors' first and last names all in a string. Roles hidden within text in the title field! Extensibility, e.g. adding contents notes or additional content Clumsy handling of different scripts Technical marginalisation, i.e. only libraries use MARC limits us to niche vendors "With the advent of the web, XML, portable computing, and other technological advances, libraries can become flexible, responsive organizations that serve their users in exciting new ways. Or not. If libraries cling to outdated standards, they will find it increasingly difficult to serve their clients as they expect and deserve." 13 years later, not much has changed although slowyl creaking its way there.
• #22: Thank you. I mentioned that RDA, despite its sins, does make element based, non-ISBD, non-MARC cataloguing more possible. Alan will now talk about RIMMF.