> -----Original Message----- > From: Resource Description and Access / Resource Description and Access > [mailto:[email protected]] On Behalf Of J. McRee Elrod > Sent: February 9, 2011 11:58 AM > To: [email protected] > Subject: Re: [RDA-L] RDA provisions > > Karen Coyle said: > > >One of the difficulties in implementing this in MARC is that, as > >Thomas showed, there isn't always a direct connection between what is > >in a MARC linking field and the thing it will link to. > > This would seem most evident in entires to which relationship > designators have been added. Wouldn't to URIs be required, one to the > name as established, and one to the relationship designator? > > Relationship designtors move description associated with a particular > edition into the entry, the opposite of moving 110 $kTreaties, etc. to > 240. >
Not only do relationship designators move "description", they actually transform that description into actionable elements. Take a look at IMDB for Clint Eastwood: http://www.imdb.com/name/nm0000142/ The entries are organized by his role in each film: actor, director, producer, soundtrack, composer, miscellaneous crew, camera and electrical equipment. This is a very user-friendly organization. The whole point to RDA is to allow properly differentiated and interconnected elements to thrive in these kinds of displays. Burying data in text descriptions is just that-- burying. It's wasted effort, and the data is of limited utility, happily living in flat file card-like environments, but not much use elsewhere. It's true that making full use of RDA elements in MARC is a problem, but it would be wise to assert that it is MARC that has the problem, not RDA. Thomas Brenndorfer Guelph Public Library
