On 02/06/2011 00:17, Wayne Richter wrote:
I believe that in internationalizing our practices, we need MUCH more granularity in personal names. In this respect, I believe the improved granularity of UNIMARC was an improvement over MARC21.
Each element or group of elements should have separate indicators for each type of name component. With some names the arrangement of elements will be different depending on locality and we need to be able to allow indexing depending on personal preference or local practice. Some examples of types of name components (certainly not a complete list):
2. Surname/Family name
I have to question the use of "we" here: specifically, "*we* need MUCH more granularity in personal names". Catalogers don't need more granularity to do their jobs; reference librarians don't need it, although all librarians do need the control that authorized forms provide, and at least I think, everyone needs that kind of control. The question is: does anybody really *need* greater levels of granularity than what we have now? With UNIMARC, it is true that they code surname and forename separately, primarily to allow for automatic punctuation, just as UNIMARC 200$g encodes Subsequent statement of responsibility and avoids the need to input the semi-colon manually.
So, do our *patrons* need more granularity in personal names? I have seen no indication that it is needed either for searching or display. Display would be the same as it is now unless someone can show that people need a display that shows each item separately, to display similar to how many catalogs display records now:
Main entry:and so on.
Personal names could display as:
Surname:and so on, so that Napoleon would display as:
Forename: NapoleonI can't imagine that too many people would prefer such a display to simply: Napoleon I, Emperor of the French, 1769-1821.
Title: Emperor of the French
Also, I have never heard or read that people want to search forenames separately from pseudonyms or patronymics. So, if there is no need to search or display these elements separately, there would not be a reason to encode them separately. While I won't argue that there may be some obscure academic value to encoding these concepts separately, so that someone could search all people with middle name of "Clarence", or numeration of "III", those are indeed very strange searches.
This is why I question if anyone needs more granularity than what we have now. Just because things can be coded in specific ways does not mean that it is practical or worthwhile to do so.