ºÝºÝߣ

Editor's Notes

1. In the beginning was the index card. This is basically text, designed to be brief but readable by people. The elements are separated by punctuation.
2. 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.
3. This is the same thing with an RDA record..
4. 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, which includes some basic information about the record.Next is the Directory, which has information about the fields and their length. The third part is the data itself: 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.
5. What is MARC for?Is it used for these things anymore?Storage: rarelyExchange and distribution. This is where MARC really lives on. To download records from others via z39 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.Lingua franca: This is another 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 barely believe that MARC replaced AACR2.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.
6. If you are familiar with the deficiences of Dewey, which is constrained by its notation.Answer:SuperMARC!
7. 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.
8. A particularly MARC21 problem:First, ISBD punctuation onlySecond, MARC onlyBoth 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.
9. Many MARC data elements contain text. Especially when isolated they become harder to make sense ofIn the ISBN examples, qualifiers are included in the subfield. With the new subfield $q, this is at least partially solved¡­
10. ¡­as this data is moved elsewhere \o/ ¡­ although
11. ¡­ 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 K?ln :, it is K?ln, or possibly Cologne, or the place we call Cologne, but the Germans call K?ln (unless you speak the local dialect: K?lle) but the Romans called Colonia Claudia AraAgrippinensium, and so on.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.
12. 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.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.
13. 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. LMS's indexing these have to process these to figure out they match.
14. Both these 700s express a relationship of some kind. But what?RDA, and the apparently enthusiastic adoption of relationship designators, have at least done something to address this with the $e.(Although note the weird comma between the heading and the relationship designator!)
15. To do anything, you have to take the MARC file to bits.One piece of information will not stand alone.
16. MARC is record based, and that record is 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
17. e.g. Primo converts all data, even MARC, into something else before processing.
18. Eleven years ago, Roy Tennant addressed in particular, recognising that AACR2 and MARC so closely entwined and focussed on the card catalogue.- Unreadably esoteric formatGranularity. 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 contentClumsy handling of different scriptsTechnical 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." Eleven years later, not much has changed.
19. Thank you.I mentioned that RDA, despite its sins, does make element based, non-ISBD, non-MARC cataloguing more possible. Celine will now talk about RIMMF.