100 _1 Hooks, Bell.
245 10 We real cool : ǂb Black men and masculinity / ǂc Bell Hooks.
I find it interesting and somewhat irritating that cataloging practice apparently denies bell hooks her preferred capitalization of her name. I can understand why perhaps the authority file, which controls the form of the name found in the 100 field, needs to be standardized on the "usual" capitalization for data-entry-conformity reasons (as indeed the Wikipedia article I linked to capitalizes "Bell" in the URL). But the statement of responsibility (the part after "/ ǂc" in the 245 field) is supposed to be as on the item, with the exception of dropping titles (only names as such are used). It's lowercased in the LC Cataloging-in-Publication block on the back of the title page, which is where the data for these fields usually gets initially slurped from, which probably means someone in the train DLC ǂb eng ǂc DLC ǂd UKM ǂd BAKER ǂd BTCTA ǂd YDXCP ǂd OCLCQ ǂd DEBBG ǂd OCL ǂd OCLCQ ǂd RV8 changed it at some point.* Pfeh.
I wonder if the upcoming switch from AACR2 to RDA**, which is really big on "transcribe what you see" to the point that people transcribe TITLE PAGE STUFF IN ALL CAPS JUST THAT WAY MAKING IT RATHER HARD TO READ, will allow "bell hooks" in this instance.
I think I may change it in our local copy of the record anyway. If it was good enough for LC when providing the CIP block, it's good enough for me.
--
* Except for "eng", which is a language code, these are called "OCLC symbols" and identify various cataloging institutions.
** Sets of cataloging rules. Don't worry about it.
245 10 We real cool : ǂb Black men and masculinity / ǂc Bell Hooks.
I find it interesting and somewhat irritating that cataloging practice apparently denies bell hooks her preferred capitalization of her name. I can understand why perhaps the authority file, which controls the form of the name found in the 100 field, needs to be standardized on the "usual" capitalization for data-entry-conformity reasons (as indeed the Wikipedia article I linked to capitalizes "Bell" in the URL). But the statement of responsibility (the part after "/ ǂc" in the 245 field) is supposed to be as on the item, with the exception of dropping titles (only names as such are used). It's lowercased in the LC Cataloging-in-Publication block on the back of the title page, which is where the data for these fields usually gets initially slurped from, which probably means someone in the train DLC ǂb eng ǂc DLC ǂd UKM ǂd BAKER ǂd BTCTA ǂd YDXCP ǂd OCLCQ ǂd DEBBG ǂd OCL ǂd OCLCQ ǂd RV8 changed it at some point.* Pfeh.
I wonder if the upcoming switch from AACR2 to RDA**, which is really big on "transcribe what you see" to the point that people transcribe TITLE PAGE STUFF IN ALL CAPS JUST THAT WAY MAKING IT RATHER HARD TO READ, will allow "bell hooks" in this instance.
I think I may change it in our local copy of the record anyway. If it was good enough for LC when providing the CIP block, it's good enough for me.
--
* Except for "eng", which is a language code, these are called "OCLC symbols" and identify various cataloging institutions.
** Sets of cataloging rules. Don't worry about it.
no subject
Date: Mar. 1st, 2012 12:00 am (UTC)From:I was also reminded of http://xkcd.com/327/ and what, if any, limits there might be on one's right to choose one's own name.
no subject
Date: Mar. 1st, 2012 12:22 am (UTC)From:Heh, Bobby Tables. I mean, the right to choose one's name, sure... but the systems we use do currently have some limits, especially in cases where you need a human to determine the context of things. Algorithms to work out what things mean are sometimes fiendishly difficult if they can be done at all.
no subject
Date: Mar. 2nd, 2012 04:26 pm (UTC)From:Naming systems in computer databases are pretty damned inflexible, really, and not just for people who case their name differently; a lot of the computer systems assume you have a Western-style name, with a given name, a middle name, and a surname, and maybe a title and a suffix. Spanish/Portuguese-style names, for instance, with more than one given name and more than one surname, are not properly reflected in most database structures. Arabic names are similarly problematic, with one given name and one surname, but multiple patronymics. As database structures tend to endure unless there's something seriously wrong with them, I anticipate that this is a problem that will last for quite a while, sadly.