RDA 337 is from 007/00, which is for category of material and RDA 338 is
from 007/01, which is for specific material designation. Catalogers have
the option to use code, instead of word to describe 337$b and 338$b.
We could make the terms for "category of material" more user-friendly, e.g.
using 337$b g to stand for motion picture, movie, etc. instead of projected
graphic.
We could also give each category of material a single tag with clean
definition, instead of using one tag for two categories, e.g. 337$b g for
both {007/00 g - projected graphic if no motion}, and {007/00 m - motion
picture if no sound or sound}.
I am concerned about legacy data migration and auto-generation of 337$b and
338$b from legacy data in MARC 007/00 and 007/01 fields, as what we are
doing now with work-level title generation out of associated manifestations
based on concatenated MARC field and sub-fields from e.g. 130, 222, 240,
245, 250, 260$c, etc. within the constraint of certain rules for work-level
title generation by material type.
Thanks!
Amanda
On Thu, Feb 17, 2011 at 9:09 AM, Brenndorfer, Thomas <
tbrenndor...@library.guelph.on.ca> wrote:
> > -----Original Message-----
> > From: Resource Description and Access / Resource Description and Access
> > [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg
> > Sent: February 17, 2011 8:48 AM
> > To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> > Subject: Re: [RDA-L] RDA and MARC
> >
> > Looking at examples in the testdata, you find (spaces added for
> > clarity)
> >
> > 336 $a text $2 rdacontent
> > 337 $a unmediated $2 rdamedia
> > 338 $a volume $2 rdacarrier
> >
> > which reveals that the item is a plain book.
> > The same might, using the codes instead, also be recorded like this:
> >
> > 336 $b txt $2 rdacontent
> > 337 $b n $2 rdamedia
> > 338 $b nc $2 rdacarrier
> >
> > The codes suggest two things:
> >
> > 1. 337 is redundant (the letter is always the first letter of the 338
> > code)
> >
> > 2. The verbal terms are less useful for indexing. For if you use the
> > codes, you can truncate nc to n, for example, to get all unmediated
> > stuff, cx to c to get all computer usable stuff, and so on. This is
> > not possible with the words. One step further: if you string it all
> > together into txtnc, you get the idea what can be done with it.
> >
>
> The Media Type (337) is based on the attribute IntermediationTool in the
> RDA/ONIX Framework (http://www.loc.gov/marc/marbi/2007/5chair10.pdf).
> IntermediationTool is actually an attribute of the Carrier. There are only
> two sets of attributes in the original Framework-- those for Content and
> those for Carrier.
>
> I've found one area in RDA where Media Type is an actionable attribute--
> when a new description of a manifestation is required for serials,
> integrating resources, and multipart monographs (RDA 1.6).
>
> So for example, if a serial changes from an unmediated to a microform media
> type, a new description is required, but not if it changes from a microfiche
> to a microfilm roll carrier.
>
> I've thought that the labels for these categories of content type and
> carrier type would work primarily in drop-down menus. My ILS has drop-down
> menus for fixed fields, but not for variable fields (although I recently
> suggested to a rep from the company that a useful upgrade for the software
> would be to add drop down menus for controlled vocabulary RDA-based fields
> throughout the MARC record).
>
> Even better, I think, would be an entire overhaul of the inputting screen.
> Related values shouldn't be scattered all over the place. Inputting should
> bring together the human-readable form, the normalized or coded form,
> related notes, and preview displays of records and generated icons. Because
> RDA elements for relationships are based on FRBR entities, there is also an
> implication there for how inputting screens should be organized.
>
> Thomas Brenndorfer
> Guelph Public Library
>
>
