 |
 |
Peter Winn says: >I'm honestly not thrilled with either name or email address since either >could change. (I rather like the ULAN approach of allowing any of a number >of legal variants for name - although I understand even that is not without >its problems.) I don't think it's a good idea to include email address or any other specific attribute of the creator/contributor/publisher/agent in the metadata for the resource either. But it seems to me that the "dumb down" principle requires at least a name. Whether the metadata supplier makes a link to ULAN (which allows name variants equal weight) or LCNAF (which codes an authorized form) is really immaterial. There needs to be something for the dumb browser and the smart suppliers will also link to some other database of metadata info for the agent (which may or may not include contact info--that will largely depend on the choices made by the supplier). Even though I'm a librarian with a very deep set of prejudices towards inverted forms of names (despite the clean, green sound of "natural order"), I don't realistically think that we can mandate that people use inverted forms, though we have certainly suggested that they do so in the first Userguide. They will use what makes sense in their context, even if, in their context, it makes sense to separate forename from surname (though I think I'd recommend using a local extension to do that at this stage). Inverted forms make the most sense if you're trying to sort and display data in some logical manner--if that's not important to you, and there's not much you're doing besides keyword indexing of names, you're not likely to do much beyond "natural order." As Karen Coyle points out, it may be that consistency over time (and knowing your metadata supplier) is likely to be more important than universal adherence to one set of rules. >My big concern is that each metadata implementation pick some "hook" to >relate resources with their agents - but keep the metadata sets for the >agents logically separate from the resources they create. Taking the >logical extreme ... I could include an entire Vcard as the value of each >Agent, but who is ever going to go back and clean up all the obsolete >information as the agent's personal details change? As I understand it, >Jim is having trouble just going through and cleaning up Name - never mind >keeping up with other personal (changeable) details like phone numbers and >email addresses if they are replicated throughout the resource base - not >to mention wasting space storing the same information over and over and >over. If you can't yet do anything with your "hook," you might, as an interim measure, include some or all of the VCard info in your metadata (which can be ignored later). But I agree, it's not a good long term solution--such data starts to smell of age rather quickly. >Simply put, my issue is that the more agent information we encourage people >to jam into a resource record using qualifiers, the more likely we are to >end up with a bunch of conflicting, useless, outdated detail. I don't think you need to convince most of us of this, but some people will have to learn by hard experience. "Life will teach them" must be our mantra. Diane §§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§ § Diane I. Hillmann § § Head, Technical Services Support Unit § § Cornell University Library E-mail: [log in to unmask] § § 107B Olin Library Voice: (607) 254-5290 § § Ithaca, New York 14853 Fax: (607) 255-6110 § § WebGoddess: http://www.library.cornell.edu/tsmanual § §§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%