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