Thomas said:
Just a suggestion-- would not relationship designators serve as the data to accomplish much of this. That is, without adding anything to existing records, or deciding a priori that one entity is a "super entity". For example, the use of the relationship designators "real identity" and "alternate identity" would create an on-the-fly arrangement through reciprocal relationships that would point to one entity as the "real" entity when pseudonyms are used. Subsequently one could construct on-the-fly displays with priority ranking (much like relevancy ranking done today by placing hierarchical values on certain fields and subfields) where the real entity would be given some prominence for the user. If there is only entity it wouldn't matter if it's the "real" entity or a pseudonym-- specifying the real identity would only need to occur when multiple entities start to appear.
In theory, of course you're absolutely right. What's more, these kind of relationship designators are already there in our German authority records: The kind of relationship expressed in a 5XX field is always coded in a $4. E.g. there is a pair of codes "vorg" and "nachf" for predecessor (Vorgänger) and successor (Nachfolger), when there is a chronological split between corporate bodies. At the moment, real name and pseudonym are still together in one single authority record in our authority file, but they are already coded with "pseu" for pseudonym and "nawi" (wirklicher Name) for real name. If we're going to split them into separate records, these will be connected in 5XX, and the codes pseu/nawi will tell you (or a machine) that it is really the same person. So, in theory, you can easily keep the relationship between pseudonym and real name apart from a relationship between a person and, say, its brother (this relationship can also be put in a 500, but will be coded differently in $4).
If we had really good systems, these codes should certainly be enough to achieve what I'm thinking of. Perhaps they are indeed already enough in a linked data environment. But IT people tell me it is very hard to create a cluster of e.g. several chronologically linked corporate bodies on the fly (by following the links and interpreting the codes) in present OPAC systems. Even our Pica system, which is generally quite good with links, doesn't seem to be able to do this, and e.g. in an Aleph system it seems it would be almost unthinkable. As long as we have these limitations, a super identifier seems a good alternative. You'd still need software which can follow links and interpet codes, but this wouldn't have to be done on the fly, but could be done in some batch process on the data, outside of the OPAC system.
Admittedly, this would be a sort of "crutch". But I must say that I'm getting a bit tired of waiting for the brilliant systems which are always, we're told, just around the corner. So I prefer a simple, workable solution any day. My motto nowadays is: Better a small and imperfect solution, which I can have today (or at least tomorrow), than having to wait for a "big" solution which perhaps may never materialize.
Heidrun -- --------------------- Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstr. 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi
