05.08.2011 00:36, Karen Coyle:
> John Attig: > Access points are treated rather strangely in RDA. The access > point is not itself an element, but is a construct made up of other > elements, which contains instructions about what and when to > include various elements in an access point. That actually makes sense from a data design point of view. It means that compound "things" can be built up of simple "things", and that means that you have flexibility in what you can build. (read: tinker-toys, or, for the younger set, Legos)
Very important indeed, but elementary for any data technician. Not quite so for those who have been raised on AACR+MARC. They find it "strange", as John seems to indicate. Why is that so? Starting out from the mental image of MARC, one may find it "natural" that everything that can be accessed in a search must be recorded in some data field, and exactly in the way it is needed for the access. This notion needs to be shattered. It has led to such extremes that, for instance, in authority records you have 53 variant names, each and every one of them carrying the same dates for that person. The access points for the variant names can, however, easily be contructed out of a name field plus a date field - the latter always the same. MARC derives from the requirements of card printing. There, each "heading" (access point in the card catalog) had to be complete and correctly formed as part of the record. This is no longer true, and has never been true in data processing systems: 1. Headings can be constructed out of arbitrary elements, they need not be stored as monolithic strings inside the record 2. New access points can be constructed that had never been possible in card catalogs. All kinds of combinations and reformattings of field contents can be programmed, no need to have every access point prepared in advance and stored in its own field. For example, extract the publisher's name out of the 260 and remove certain particles from it, and then get the date out of the fixed fields to make a useful index entry (access point) like "name:date" This is easy to understand, but as a consequence, the rules, and thus the data model, will become more abstract and more difficult to understand. But maybe only for someone who has been brought up on the notions of the card catalog and later those of MARC. For someone with a background in abstract data structures, John Attig's clarifications are no surprise at all. One more reason, one might think, to get rid of MARC ASAP. Not really, though. Firstly, because it is utterly unrealistic, and second. because MARC is flexible enough to be used in new software applications that do new tricks with the old stuff AND are able to deal with some new data elements in novel ways. It is not the worst of ideas to look at the additions Germans and Austrians have thought up for their MARC dialect. It will allow us to continue with our scenario 2 applications as they are long since in operation, and the further step to scenario 1, if at all necessary and useful, would not be very difficult either. We are not using MARC internally, and are not going to, but our internal formats are no less complex. They are only not rooted in the mental image of the card. B.Eversberg
