In some ways there is already a simplification in RDA-- the conflation of the
FRAD Person and Name Entities.
In FRAD, a Person entity has a relationship to a Name entity, and the Name
entity has its own attributes, such as Scope of Usage and Date of Usage. In
FRAD, Name also applies to titles of works, expressions, and manifestations.
In the RDA Element Set View, one can even see the FRAD entity Name listed
apart from the Person/Family/Corporate Body entities.
Where the boundaries are can make a difference in what the data model can
accomplish.
By separating out a biological person into separate bibliographic entities then
one can also more easily align the data surrounding the usage of particular
names, but this might not go as far as what FRAD offers. In RDA, the FRAD
entities Person (as in bibliographical identity called Person) and Name are
combined, so the simplification might also have some limitations.
I can also see a use for the Name entity having relationships to
manifestations, for both title used and for form of the name of the author on
the manifestation. One could then start with a Person entity or Work or
Expression entity, go to a variant form of name used, and then follow a link to
only those manifestations that used that variant form. This might assist in
determining such issues as predominant usage of a form of a name, or act as a
trigger for when a permanent name change occurs, facilitating decisions about
creating new entities.
Thomas Brenndorfer
Guelph Public Library
-Original Message-
From: Resource Description and Access / Resource Description and Access
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller
Sent: January-06-13 3:11 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Separate bibliographic identities
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
