Posting to Autocat
On Mon, 7 Mar 2011 16:58:21 -0500, Brenndorfer, Thomas wrote:
The issue of “forcing” the variety of relationships through a limited set of designators is a complete red herring in discussing RDA.
>Justification of access points by other elements is one thing, but the problem is that’s often the only method users have of inferring relationships. The reason why access points are what they are is not readily transparent. For example, how many users think of a “work” when looking at a 100 field? Catalogers have no choice but to identify a work in order to catalog an AACR2 record.
What strikes me in these kinds of discussions is that we see an increasing complexity to reach what is precisely the same result. Adding the relator codes will not help anyone *find* anything more than they do now, it is that adding relators *may* help people *identify* a specific item they want. (That still remains to be demonstrated) By this I mean that when people search, they will select (at the most) “author, title, subject” as they do now, and not from the entire gamut of terms at http://www.loc.gov/marc/relators/relaterm.html.
While there may be some kind of minor utility for the user in seeing the relator codes, this discussion shows clearly that it will definitely be more complex for the cataloger and take more time. For example, let’s say that someone is cataloging a “remote-accessed electronic resource” and you come across someone who is the “web coordinator”? Which relator code do you use? Often, you see names not with “editor” or “compiler” but a person’ job title, and who in the world can know what that is supposed to mean? How do you choose a relator code for “web coordinator”? If I choose one of the terms, how do I know if the next cataloger will do the same thing? This is the brilliance of the statement of responsibility, which is far more exact and easy to implement because all you do is transcribe what you see.
And Mac mentions that consistency will be broken, and this is a *very serious* matter that should not be brushed aside. The old records will never be “updated” and that is a concern since you potentially make all of your previous records obsolete.
So, complexity and difficulty of record creation increases, without a doubt, and the benefits to the users are highly dubious, and I would even say, remain theoretical. While it is clear that the public has lots and lots of problems understanding our records, they increasingly have problems even understanding *what our records are* because they have become used to seeing the results of Google full-text searches, with that small clip underneath each link that shows how their search term has been used. Of course, the Google “record” that they see is completely different from anything we do. To demonstrate, here are first three results for the search “metadata” on Google:
Metadata – Wikipedia, the free encyclopedia
The term Metadata is an ambiguous term which is used for two fundamentally different concepts (Types). Although a trite expression “data about data” is …
Definition – Metadata types – Metadata structures – Metadata standards
en.wikipedia.org/wiki/Metadata – Cached – Similar
[PDF] Understanding Metadata
File Format: PDF/Adobe Acrobat – Quick View
Understanding Metadata is a revision and expansion of Metadata Made … Metadata can be embedded in a digital object or it can be stored separately. …
The definition of Metadata defined and explained in simple language.
www.techterms.com/definition/metadata – Cached – Similar
Of course, it is very natural for the public to relate our catalog records to these types of “records” which are just clips that show keyword in context. This type of result is pretty easy for anyone to understand, but comparing it to a catalog record is simply wrong since they are completely different, with separate purposes. This is the sort of thing that confuses our public, and not relator codes.
It seems to me that adding the relator codes is a solution in search of a problem. There are plenty of genuine problems out there that need genuine solutions. This is not one of those.