Posting to RDA-L
Kelley McGrath wrote:
There was a discussion a while ago now about the problems (or not) with MARC. I gave a presentation at ALA Midwinter called “Will RDA Kill MARC?” I was sort of waiting for the official version to be posted, but, although the person organizing the presentation has tried to post it on the ALA/ALCTS site, apparently the site down a lot. So in order to belatedly get my two cents in, I’ve put the presentation up at http://pages.uoregon.edu/kelleym/KM_MWpresentation.pptx for anyone who might be interested. I guess my point is that we could make MARC do at least most of the things we need it to do to support RDA, but that’s probably not the best use of our limited resources.
Interestingly, one of the audience members asked rather if MARC will kill RDA…
Thank you so much for sharing this presentation. It’s no secret what I think about RDA, FRBR, and MARC but I agree with a lot of what you point out. Yet, I do have a question. On slide #15, you use an example MARC record to show how the current coding of our data is inadequate by referring to a record (which I discovered to be “Flume” by Martin Boykan) and at first, I could not understand how the coding you presented there was inadequate. But I realized that the problem (if it turns out to be one) is that the information for e.g. Cyrus Stevens, only pertains to the first work (Sonata for violin and piano), which was performed at the Sonic Temple, etc. and that the other pieces of music there had other performers and performance information. As a result, information for the separate pieces is spread around all over the place and as you point out, it cannot be brought together.
[As an aside, for the entire record, you can see the one at Princeton http://catalog.princeton.edu/cgi-bin/Pwebrecon.cgi?Search_Arg=A-200+CD+897&Search_Code=CALL&CNT=1&HIST=1 (You need to click into the record. It's the closest I can get), and it is also interesting to compare this with the version from Amazon, using that wonderful conversion tool: http://amazon.libcat.org/cgi-bin/az2marc.pl?kw=B00006IZMR. By the way, the library record seems superior in every way, allowing controlled access to every name and title.]
But I wonder if what you point out is a genuine problem, especially in an RDA/FRBR universe. The user tasks are to find, identify, yadda –> works, expressions, manifestations, and *items*. Not sub-items. This record seems to allow everything that FRBR requires, plus it allows even more because if I am looking for Boykan’s First string quartet, there is a beautiful controlled analytic. This level of analysis is rarely followed in regular cataloging of other materials.
So, as far as finding goes, there is absolutely no problem. It is just that in order to *see* the metadata associated with this particular piece (remember, I can still *find* it!), I have to look at the description for the entire item. Nevertheless, it can be found–and in a controlled way as well since the cataloger did a good job–and this information is available for the later user tasks of identifying, selecting and obtaining. This seems to fall squarely within the FRBR requirements.
Of course, breaking it all down could be achieved today in MARC through doing separate constituent entry/host entry records, so that the information that is scattered around within the single record would actually come together in the separate records. With a more flexible format than MARC, the information could be grouped within the same record, e.g.:
<metadata for host entry>
<metadata for 1st constituent>
<details of the performance>
</details of the performance>
</metadata for 1st constituent>
<metadata for 2nd constituent>
</metadata for 2nd constituent>
</metadata for host entry>
None of this would allow for more *access* than what we have right now however, since people would still be able to find exactly what they can today. I am sure that it would be just about as much work for the cataloger as doing constituent/host entries. The actual difference would be with display, since the constituents would display within the host entry, if it were desired. (Although they wouldn’t have to) While this *may* be more flexible than what we have today, I still believe that with XML and XSL Transformations, we could probably have almost the same displays available using our current constituent/host entry cataloging. (By the way, I am *NOT* at all advocating we institute host/constituent cataloging!)
A difference could be if we added controlled access for, e.g. place and date of a performance, perhaps similar to a conference heading, but I am also *NOT* advocating that, either!
I can imagine that a problem could arise with interoperability with another catalog/database that coded these matters separately, e.g. a music recordings database where you could search for specific dates and places of performance. But this raises a whole bunch of side issues that are not pertinent here.
So, what I am asking is that while what you point out here is true, does it constitute a problem in the practical world? And especially is it a problem in an FRBR/RDA world where it is assumed that people want *items*?
Or, is this merely a theoretical issue? I personally believe that this is a theoretical problem that impedes finding and access in no way at all.
But yes, I agree that for all kinds of reasons we need to provide the public with more useful formats than MARC, especially its ISO2709 instantiation. But this needs to be done in steps. The first step could be allowing the public access to an XML format of our records. I don’t care if it’s MARCXML or MODS or some other variant. After that, we play it by ear and see what the public needs, and what our needs are.