Karen,
not necessarily, I believe.
In German library systems, we're used to linking authority records
(mostly for persons and corporate bodies) to bibliographic records,
using the authority control numbers as identifiers. The systems are able
to extract information stored in the authority records for retrieval.
This makes it e.g. possible to use variant names in keyword searching.
It would, on principle, also be possible to have an authority record for
every work and link these to the bibliographic records. In this case,
there wouldn't be a need to repeat work level information (stored in the
authority record) in the bibliographic record. So in the bibliographic
record, I would expect to have a link to the work record (corresponding
to the data element "work manifested"), but not also a link to the
authority record for the author (corresponding to the data element for
"creator") - this information would be stored in the authority record.
Of course, this wouldn't be true FRBR, as the remainder would still be a
mixture of expression and manifestation. It also wouldn't be a true
scenario 1 implementation, but rather a mixture between scenario 1 and
scenario 2.
Using text strings instead of numbers to express relationships is, to my
mind, indeed somewhat archaic. Personally, I find it hard to understand
why it is still widespread in MARC systems. But we shouldn't forget that
the MARC format already allows for transporting authority control
numbers (in subfield $0), although nobody in the Anglo-American world
seems to use this option... So maybe it wouldn't be necessary to wait
for a true FRBR-modeled carrier for RDA. Linking via numbers is already
possible in MARC, as is having authority records for works. So why
shouldn't it be possible to upgrade the library systems accordingly, at
least as a first step on the way to the "perfect" carrier for RDA data?
By the way: It was just announced that the the implementation of RDA in
the German speaking countries will conform to scenario 2. The
announcement can be found here (sorry, it's in German only):
http://lists.ddb.de/pipermail/rak-list/2012-June/001983.html
Heidrun
Am 03.06.2012 23:40, schrieb Karen Coyle:
Heidrun,
I've been assuming, perhaps incorrectly, that references to FRBR
relationships in RDA, like "work manifested," are essentially unusable
until there is a FRBR-modeled carrier for the bibliographic data. I
have a similar assumption about things like "identifier for the
expression," which really cannot exist until there is a FRBR-modeled
carrier that allows -- nay, requires -- those identifiers in order to
create the entities and their relationships.*
It makes very little sense to me to be creating a text string for
these relationships which have to be machine-actionable in order to
have the scenario 1 data structures.
kc
*Hopefully without diverting this discussion, I think there is a
difference between the system identifier for the expression *entity*
and a string, like an ISBN, that might be considered to identify, or
partially identify, an entity in the bibliographic description through
its use in various contexts.
On 6/3/12 7:51 AM, Heidrun Wiesenmüller wrote:
I am mulling over the data element "work manifested" in the examples
for RDA bibliographic records released by the JSC some time ago:
http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf
For instance, look at the example for Arlene Taylor's "The
organization of information" (book 1, p. 10): There, you'll not only
find the data element "creator" (Taylor, Arlene G., 1941-), but also
the data element "work manifested" (Taylor, Arlene G., 1941-.
Organization of information). Note the beautiful footnote: "No
equivalent encoding in MARC 21". In the earlier version of these
examples wich accompanied the full draft of 2008, this data element
wasn't there at all, and its appearance now strikes me as rather odd.
Granted: "Work manifested" (17.8) is a core element in RDA (cf. 17.3:
"When recording primary relationships, include as a minimum the work
manifested."). But in 17.4.2, three conventions for recording primary
relationships are outlined, and I believe that only the first and the
second presuppose "work manifested" as a single data element: For
these two methods, an identifier for the work (method 1) or the
authorized access point representing the work (method 2),
respectively, are used.
The third method, however, does not seem to require one single data
element "work manifested": "Prepare a composite description that
combines one or more elements identifying the work and/or expression
with the description of the manifestation." So, in this case, the
identification of the work is achieved by one or more elements which
really belong on work level, although in the record they are mixed
together with information on manifestation level. Typically, these
will be the data elements for the first "creator" and for the
"preferred title of the work" (vulgo: uniform title). I'd argue that
in cases where there's no need to determine a uniform title (e.g. if
there is only one manifestation of the work in question), the title
of the manifestation can be used instead.
The RDA example for "book 1" mentioned earlier follows this third
method for recording primary relationships, i.e. it is a "composite
description", which basically looks like the conventional MARC
record. Therefore, I find it hard to understand why the information
about the work manifested is given _twice_ in the same record: Once
_implicitly_ according to method 3 (by giving the data elements
"creator" and "title proper" as part of the composite description)
and a second time _explicitly_ according to method 2 (by giving the
authorized access point representing the work).
Shouldn't it be either the one (in a composite description) or the
other (in a different implementation scenario for RDA, something
closer to scenario 1)? As it stands now, the information given seems
to be redundant.
Any ideas?
Heidrun
--
---------------------
Prof. Heidrun Wiesenmueller M.A.
Stuttgart Media University
Faculty of Information and Communication
Wolframstrasse 32, 70191 Stuttgart, Germany
www.hdm-stuttgart.de/bi
