Certainly, more form/genre term would be helpful; but if "interactive material" (or whatever it was called) was a content type, we could use form/genre headings to record and provide access to specific genres of games and interactive documents (of which there are many).
I appreciate what you are saying about the difficulty of creating a generalized vocabulary. It has always been my understanding (or my hope) that these lists were not meant to be canonical for all time--that we should expect new terms to come into the vocabulary as people find new uses for it. I think that if content type is meant to categorize "the fundamental form of communication in which the content is expressed and the human sense through which it is intended to be perceived" then none of the existing content type express the fact that ludic material is meant to be "perceived" through interaction. "Text" implies static content (and anyways not all game are textual in nature--have you ever played Set? If not, I recommend it for any cataloger--in fact, I use it my cataloging class to demonstrate what "facets" are.) It also occurs to me that RDA 6.9.1.3 states, " Record as many [content type] terms as are applicable to the resource being described " so a computer game, for example, could be described: 336 $a computer $b c $2 rdacontent 336 $a interactive $b i $2 rdacontent Finally--I certainly agree with you about DVD's, and I don't really think RDA content/media/carrier vocabularies improve upon that situation. If anything they go backwards--under AACR2 it was common to code the 300 $a as "1 CD-ROM" or "1 DVD-ROM", but under RDA we're supposed to "record the extent of the resource by giving the number of units and an appropriate term for the type of carrier" which leads us to record "1 computer disc". The only way I've figured out to indicate "DVD" vs "Blu-Ray" or "CD-ROM" vs "DVD-ROM" is with a note. In any case this is an interesting discussion, so thank you. ==Ben Benjamin Abrahamse Cataloging Coordinator Acquisitions, Metadata and Enterprise Systems MIT Libraries 617-253-7137 -----Original Message----- From: Jonathan Rochkind [mailto:rochk...@jhu.edu] Sent: Thursday, October 25, 2012 1:31 PM To: Resource Description and Access / Resource Description and Access Cc: Benjamin A Abrahamse Subject: Re: [RDA-L] Additional work required by RDA On 10/25/2012 1:20 PM, Benjamin A Abrahamse wrote: > " If a library holds software, mightn't a user want to see a list of > all the software the library holds, whether games or word processors > or what have you" > > I suppose. But that seems to me like a less direct, or usual user > task than, "Show me what games your library has." (Which currently > cannot be answered, for computer games or otherwise, by the RDA > content/media/carrier vocabulary.) I'm not sure it seems to me like less direct or less usual, probably depends on the environment (maybe in a public library it's a usual question?). But at any rate. You can't do that with AACR2/MARC GMDs/SMDs either, can you? Perhaps the right place to record something to answer this question is actually in a 6xx/LCSH $v form/genre heading? I know LC is doing work on revising the LCSH form/genre heading thesaurus too -- like I said, this is a difficult thing to make a generalizable taxonomy for. Perhaps that's the right place for there to be a 'games' heading (entered in a 655), as 'game' is really more of a 'genre' having to do with the content and the author's intentions for it's use, than it is a form/format/carrier having to do with the physical properties of the item, that the RDA vocabularies we're talking about focus on. This stuff is really tricky to encompass with standardized shareable general and universal vocabularies, it's probably not possible to do so completely (and nothing libraries have tried yet comes close either. For instance, trying to display or limit by whether an item is a "DVD" (let alone blue-ray vs standard dvd!), which seems to me to be a VERY common user need in contemporary libraries accross communities and types (public as well as academic) -- is a somewhat herculean task with our legacy metadata).
