> On Sat, 2007-09-01, Conal Tuohy wrote:
> I agree that using human-readble names for identifiers is problematic.
> This is perhaps another "thing that LIS can learn from CS". In
> database
> design, best practice is to use opaque tokens as identifiers. Putting
> actual DATA about an entity into its identifier is a failure of
> normalisation rules for database design!
Making a computer readable identifier is a great idea and could/should be done relatively painlessly when people decide to get serious and just do it.
But the system will be used by humans, and they also must have a way of distinguishing these authors, so that they know which David Johnson to choose. Our current reliance on differentiation using readily available dates, and very occasionally a $c (Titles and other words associated with a name) is one way of doing it, but it has problems, too. But in any case, there must be a human-readable label of some sort so that the users (and catalogers, until the computer replaces them) can quickly differentiate one David Johnson from another. We can perhaps experiment with new ways. Still, we must recognize that the old way "works"--although not perfectly--since it allows the catalog to function correctly, it allows the users to see that there are different "David Johnsons," and it gives at least some sort of an idea of how they are different, i.e. when they lived.
Extending this, there is no reason to expect, or to demand, that all labels in the world should be the same. Russian labels should be different from Chinese, from English, French and so on. But the computer identifier could be the same. Once the computer identifier is the same, we can talk about genuine record sharing across borders. If genuine record sharing would begin, we could start to reconsider workflows in this new, huge, interoperable metadata environment, and a lot of the problems of getting control of the internet would become much more manageable.
Jim Weinheimer
Attachments
Received on Tue Sep 04 2007 - 02:53:37 EDT