> On Mon, 13 Nov 2000, Dan Brickley wrote:
>
> > Absolutely. This issue (representing structure/groupings, complex
> > inter-relations) has bedevilled DC for far too long. One-to-one seems to
> > be our name for that family of problems. I'm not sure how best this can
> > best be expressed for the issue list though...
>
Possible solutions depend largely on what one considers as entities
to be described.
In the music-related cases cited in this debate, there is always an
abstract, immaterial entity involved, a "work", however difficult
this may be to define.
Regarding a "work" as an entity, one may go ahead and describe it,
(this would then contain the "uniform title" as a prominent element)
and then relate every concrete realization's description to it.
This would be a clean one-to-one scenario, at the cost of having
this abstract entity - which means a description without a surrogate.
The "authority records" (in library parlance) have the extra benefit
of providing a place for all those title variations and name
variations which are not desirable to have in every manifestation
record but which can make retrieval much more effective.
But Who is going to manufacture and maintain such descriptions and
make them available, and how? Within one project, no problem
(just labor), but across projects?
Shying away from the extra expense of having immaterial "work"
records, one may (as music cataloging has done for a long time)
use formalized names or titles to consistently name the concrete
items. These qualified names or titles would behave like other
titles for all practical purposes (indexing).
We have a one-to-one scenario here too, if we deny the "work" any
status of entity.
But Title and name variations, in this case, are a problem, esp.
with names like Tchaikovsky. Where to put them all?
This scenario works well for classical music, probably less
so for other areas.
Taking the "Functional Requirements" study seriously leaves no
option but regarding the abstract "work" as an entity in its own
right. Conceptually, everything becomes very elegant, but
implementations become more costly (at least initially) and tricky.
Seen from the users' point, it depends on what they expect.
Is all they ever need to be able to find concrete manifestations,
knowing exactly what it is that they want? Then there's no need for
the "work" concept. Or do they expect to retrieve lists of all
manifestations of one "work", and be sure they get them all in
one query, essentially not knowing what different forms of names and
titles etc. there may exist? Then approach 1 is the way to go.
Regards, B.E.
Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329,
D-38023 Braunschweig, Germany
Tel. +49 531 391-5026 , -5011 , FAX -5836
e-mail [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|