Discussion Paper 2008-DP04: Encoding RDA, Resource Description and Access data in MARC 21
(2nd part)
3.8: Leader/18 (bib), 008/10 (auth), 040 $e values for RDA and RDA/ISBD
It is essential that libraries be able to identify which rules a record was created under. This is essential for day 1 of RDA implementation.
Two values are needed, to indicate whether or not ISBD punctuation is also being applied. It is preferable to identify this as early as possible in the record (i.e. by using a Leader code) but the 040 $e code is eye-readable and maybe handier for cataloguers assessing whether or not to use a record for copy. (See comments in 3.12.2.)
3.9: FRBR group 1 entities
A code in the authority record 008 may be needed to identify works vs expressions. The code could be applied to 100, 110, 111 with $a$t and to all 130. If a $l is present, it would be automatically expression, all others would default to work, which would usually be correct. This is not essential for initial implementation, but could be useful in the long run.
3.10: Relationships
3.10.1: Relationships between group 1 entities
Many of these are in the 76X-78X linking fields already, but some are missing. However, if RDA is getting away from the FRBR relationship categorization which takes the group 1 level into account and using instead the 7 broad Tillett categories, then there is little to really encode, the present linking fields are already more detailed.
Relationships between group 2 and group 1:
The relator codes list can surely be enhanced if needed. Using relator codes in 7XX has in the past hit the snag of how to handle a single name with many roles in relation to the resource (i.e. should one repeat the entire tag or just repeat the relator code or term subfield).
This is not essential for initial implementation but could be useful in the long run.
3.10.2: Identifiers.
This is not essential for initial implementation but could be useful in the long run.
3.11: Controlled lists of values in 007 in particular.
Where the RDA list of values is longer than those defined in MARC 21, there is no reason not to define the additional values.
If the MARC 21 list is longer (and the RDA list is a nice subset of it without conflicts), then no action is necessary for MARC 21 (example
3.10.0.4 and 007/09 sound recording).
Problematic cases are where the RDA and MARC 21 lists are at different levels of granularity (example 3.17.0.6 and 007/05 sound recording: MARC 21 has a single value each for microgroove/fine and coarse/standard, while RDA has 4 values). This will require obsoleting values and defining a new one, without any migration possible.
Not making the easy and obvious additions right away will force cataloguers to code « other » or fill character in those cases, to no one's benefit. Conflicts will eventually need to be resolved.
3.12.1: Data about data.
An interesting concept and important but more information is needed to figure out how to code this. Not essential for initial implementation.
3.12.2: Options at 1.6.
Is this a need strictly for the bibliographic record or also for the authority record? Could this be combined with the values in LDR/18 (see 3.8), 040 $e, or 042? More values would be needed to express:
RDA/RDA transcription has been followed;
RDA/RDA transcription has not been followed;
RDA/ISBD/RDA transcription has been followed;
RDA/ISBD/RDA transcription has not been followed.
3.12.3: Elements with English language canned text.
The language of description in 040 $b could guide the flipping of text. Flipping would rely on identification and matching of accurately-in put text. It would be desirable for systems to assist, or ensure, the accurate input of the texts. Perhaps a future environment (e.g. XML) will provide a better opportunity for this.
3.13: Identifying supplied data by coding instead of square brackets.
Control characters: much more painful to implement for most systems. It would be a beautiful role for an indicator, but adding a 3rd indicator would be just as bad. Perhaps a future environment (e.g. XML) will provide an opportunity for encoding.
3.14: Punctuation
This has reopened the debate about adding enough subfields to 245 etc. to generate all punctuation. It is opportune to align those changes with RDA implementation.
3.15: Authority format
3.15.1: Elements used in construction of access points.
These are not needed for day one. Should there be free-standing authority fields for 100 $c $d $q: Maybe for dates, and then dates could be recorded whether wanted in the access point or not.
3.15.2: Granularity
There advantages to encoding birth, death and activity dates separately. This could avoid the language specific term: b./né, d./m.
FRAD optional elements: places could probably be found for these, but this is not an essential task for day 1.
3.15.3: Content type
In access points for expressions the $h will need to be redefined. As it exists yet is little used (not called for in present rules), it can easily be renamed and given a new description.
As a free-standing data element, whatever solution is used in the bibliographic format (under 3.1) could be applied to the authorities format.
3.15.4: Technique for graphic image.
Is this potentially going to end up in a heading as a qualifier and not separately subfielded, or as a free-standing subfielded element? Then it is the same issue as 3.15.2.
Overall there a very few RDA elements which cannot be accommodated in MARC 21.
Pat Riva
Coordonnatrice section des monographies
Direction du traitement documentaire de la collection patrimoniale
Bibliothèque et Archives nationales du Québec
2275, rue Holt
Montréal (Québec) H2G 3H1
Téléphone : 514 873-1101 poste 3624
Télécopieur : 514 873-7296
[log in to unmask]
www.banq.qc.ca
|