Maybe what we need to do is develop some use cases and see how
they would turn out. I'm less concerned about the cataloger view
than the user view. You've probably run into some description of
looking at FRBR from "bottom-up" vs. "top down." Some folks
consider the cataloger view to be bottom-up (from the thing in
hand to the Work) while the user view is top down (from the Work
to the item on the shelf).
Here are three items. I don't know if they are enough to
illustrate what worries me:
1.
LC control no.: 47003534
LCCN permalink: http://lccn.loc.gov/47003534
Type of material: Book (Print, Microform, Electronic, etc.)
Personal name: Nabokov, Vladimir Vladimirovich, 1899-1977.
Main title: Bend sinister [by] Vladimir Nabokov.
Published/Created: New York, H. Holt [1947]
Description: 242 p. 21 cm.
2.
LC control no.: 89040559
LCCN permalink: http://lccn.loc.gov/89040559
Type of material: Book (Print, Microform, Electronic, etc.)
Personal name: Nabokov, Vladimir Vladimirovich, 1899-1977.
Main title: Bend sinister / Vladimir Nabokov.
Published/Created: New York : Vintage International, 1990.
Description: xix, 241 p. ; 21 cm.
ISBN: 0679727272 : $9.95
Notes: Reprint. Originally published: New York : McGraw Hill, 1947.
3.
LC control no.: 81001594
LCCN permalink: http://lccn.loc.gov/81001594
Type of material: Book (Print, Microform, Electronic, etc.)
Personal name: Nabokov, Vladimir Vladimirovich, 1899-1977.
Main title: Bend sinister / Vladimir Nabokov ; with a new
introduction by the author.
Published/Created: Alexandria, Va. : Time-Life Books, 1981, c1947.
Description: xviii, 217 p. ; 20 cm.
Based on the report of the FRBR aggregates group, I believe that
we would have:
Work 1 (#1, #2)
Expression 1 (#1, #2)
Manifestation 1 (#1)
Manifestation 2 (#2)
Work 2 (#3)
Expression 2 (#3)
Manifestation 3 (#3)
The latter is an aggregate work. Professor Wiesenmüller's
approach would create in addition something like (if I'm wrong
about this, shout out):
Work 1
has part1
Expression 1
Manifestation 3
Now, how to make this into something useful for the user.
Unfortunately we now have two Works that, as far as the user is
concerned, have pretty much the same content. One of the Works
points to all of the manifestations with the expression; one of
them points to one of the manifestations. This will look
redundant to the user. And I don't see how Work 2 can be removed
from display algorithmically. If we then add what is essentially
an analytic entry that links the non-aggregate Work 1 to
Manifestation 3, we're adding even more redundancy for the user.
The bottom line is that if every manifestation that has some
differences (prefaces, illustrations) becomes a separate Work,
adding MORE Work entities to clear this up will result in
duplicate entries from the user's viewpoint.
I'd love to be proven wrong on this.
kc
Quoting Casey A Mullin <cmul...@stanford.edu>:
[Disclaimer: I haven't read the report yet, though it's waiting
for me on my desk]
To me, the desire/need to have WEM for an aggregate, as well as
W(EM) for some or all of the constituents, doesn't bring us back
to ISBD/MARC. In some cases (e.g., music sound recordings,
conference proceedings), the W and E of an aggregate is merely a
placeholder which allows us to describe the Manifestation as a
whole, while the constituent WE are the primary entities of
interest. But, even in those cases, it can be just as important
to describe the aggregate W too, say for purposes of assigning
subject terms, relating editors responsible for the compilation,
etc. I think WEM for both host and constituent entities always
exist; it's just that different types of resources call for
differing levels of fullness in describing each entity, ranging
from just identifiers (as Jonathan stated) to fleshed-out
records/graphs.
The bottom line IMO is that our cataloging and end-user
interfaces should suppress the entities that are of little
interest (i.e., minimally described) while allowing for
describing and navigating robust whole-part relationships as
needed.And this is definitely a far cry from what MARC allows.
Therefore, I don't see the same conflict that Karen does. We can
have our cake and eat it too. :)
Casey
On 1/5/2012 2:06 PM, Karen Coyle wrote:
Heidrun,
this is a really devilish problem, but I think the solution is
not going to be found within FRBR. That is because FRBR creates
a tight coupling between W, E, and M that (IMO) does not fit
the reality of publishing. In essence, nearly EVERY published
item is an aggregate - books have prefaces or illustrations
from other sources; musical recordings almost always include
more than one Work; serials are of course aggregates by their
nature. If each aggregate Manifestation is linked to an
aggregate Expression, and each aggregate Expression to an
aggregate Work.... well, then we have a one-to-one between
Manifestations, Expressions and Works. We're back to ISBD or
MARC in that case.
Then, if our assumption is that users are interested in the
individual Works as well as, or instead of, the aggregate, then
another entry has to be made for each individual Work as well.
I don't think that's how most of us envision FRBR.
I find there to be a conflict between the FRBR view and the
need to catalog a package. And I don't think FRBR resolves it
well, which is what the aggregate group struggled with. But
maybe the problem is deeper.
kc
--
Casey A. Mullin
Discovery Metadata Librarian
Metadata Development Unit
Stanford University Libraries
650-736-0849
cmul...@stanford.edu
http://www.caseymullin.com
--
"Those who need structured and granular data and the precise
retrieval that results from it to carry out research and
scholarship may constitute an elite minority rather than most of
the people of the world (sadly), but that talented and
intelligent minority is an important one for the cultural and
technological advancement of humanity. It is even possible that
if we did a better job of providing access to such data, we
might enable the enlargement of that minority."
-Martha Yee
