Another fundamental rule of identifiers is that what is identified should not change significantly. That generally holds true in LC authority practice, but not in the case of undifferentiated personal name authorities. By rule and standard procedure, an LCCN for an authority of this kind can refer uniquely to one person now, and a different person later, and yet another person later still.
This is another reason why a system which restricts the data elements that can be used to make a unique heading to the point that making a unique heading is not always possible is problematic. Good identifiers can always be made unique to correspond to a unique entity. LC/NACO personal name headings can't, which is another reason why they're not good identifiers under the current rules. Stephen On Mon, Apr 25, 2011 at 11:20 AM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > I am talking about our library-community database as "the database [someone] > is linking to." > > If we're always changing our identifiers (considering our authority 1xx > "preferred display forms" to be identifiers), that makes it very hard for > anyone to link to things in our database. > > Even just for our own database with their internal links, always changing > the effective 'identifiers' (auth 1xx) makes our own housekeeping much more > expensive for ourselves. > > Again, this is because of using the very same string (auth 1xx) as both a > functional "identifier" and a functional "preferred display term". A > practice that is highly discouraged in actual contemporary software/metadata > engineering, although it worked fine 100 years ago. > > Seriously, it is a fundamental idea in identifier management, decades old, > that you should not change your identifiers, and for this reason you should > not use strings you will be displaying to users as identifiers. One way this > idea is expressed, for instance, is that you should not use a 'natural key' > as a 'primary key' in a relational database. You can google on those terms > if you want. In the sense that an rdbms pk serves as a kind of identifier, > that is just one expression of the fundamental guideline not to change your > identifiers, and thus not to use things you might want to change as > identifiers. > > I am seriously not sure why you are arguing this, James. This is a pretty > fundamental concept of data design accepted by every single contemporary era > data/database/metadata designer. This is probably my last post in this > thread, this is getting frustrating to me. Perhaps it's my fault in not > being able to explain this concept adequately, in which case I don't think I > can personally do any better then I've done. Otherwise, I am not sure why > you are insisting on arguing with a basic principle accepted by everyone > else doing computer-era data/database/metadata design -- which has been > proven in practice to be a really good prinicple. It's not a controversial > principle. At all. Anywhere except among library catalogers, apparently. > > Jonathan > > On 4/25/2011 12:12 PM, James Weinheimer wrote: >> >> On 04/25/2011 05:56 PM, Jonathan Rochkind wrote: >> <snip> >>> >>> If you maintain the "preferred display form" as your _identifier_, then >>> whenever the preferred display form changes, all those links will need to be >>> changed. >>> >>> This is why contemporary computer-era identifier practice does NOT use >>> "preferred display form" as an identifier. Because preferred display forms >>> change, but identifiers ought not to. The identifier should be a >>> _persistent_ link into your database for the identified record. >> >> </snip> >> >> So long as the link from your database links unambiguously to the resource >> you want to link to, that is all that matters. There are different ways of >> allowing that. This function is most efficiently handled by the database you >> are linking into, instead of the single database expecting everybody in the >> world to change their own databases to add their URIs. For example, I could >> add a link for the NAF form of Leo Tolstoy to dbpedia to interoperate with >> it. If they had a special search for exact NAF form, like in the VIAF, it >> would definitely be unambiguous. >> >> My point is: this is something that is achievable. Probably through a >> relatively simple API, it could be implemented in every catalog pretty >> easily. There is just no hope that each catalog will add URIs within any >> reasonable amount of time. >> >> Certainly, if we were creating things from scratch, we could redo >> everything that would be better for us (there is no doubt in my mind that >> future information specialists/catalogers 80 years from now will be >> complaining about whatever we make), but you must play the cards you are >> dealt and be creative with what you have. Perhaps it wouldn't be perfect, >> or maybe it would, I don't know, but in any case, it would be vastly better >> than what we have now and people could start discovering and using our >> records in new ways. >> > -- Stephen Hearn, Metadata Strategist Technical Services, University Libraries University of Minnesota 160 Wilson Library 309 19th Avenue South Minneapolis, MN 55455 Ph: 612-625-2328 Fx: 612-625-3428
