RE: [open-bibliography] MARC Codes for Forms of Musical Composition

All
 
Karen is spot on - this is the content v. carrier issue, difficult to avoid in
Libraryland although things may get better when RDA starts to kick in. RDA
clarifies the issue by applying the RDA/ONIX framework for resource
categorization to create high-level concepts for content and carrier types. An
immediate utility of this approach is that users can more accurately filter
searches by specific aspects of the content and/or carrier of the items in a
library collection, for example content that does not require the visual sense.
The issue became acute in the 1980s as more and more content appeared on digital
carriers. Query: is the ambiguity of the term "book" reflected in some way in
digital libraries?
 
The FRBR WEMI classes are aspects of a whole; a "full" catalogue record will
usually consist of a Work, an Expression, a Manifestation, and an Item. A
significant utility of FRBR is that it gives cataloguers a better context for
their activity, as the WEMI classes and individual properties are assigned to
the four identified user tasks (find, identify, select, acquire/obtain). A
corollary is that FRBR makes it easier to present the metadata in more useful
ways to the user; typically, the user can drill-down from Work (essentially
equivalent to the brief author/title display often seen in library interfaces)
to Expression (content-related stuff like editions, translations) to
Manifestation (carrier-related stuff) to Item (is it on the shelf?) There is
also the potential for more effective metadata management through reduction of
duplication (one Work record can be linked to multiple Expression records, etc.)
and increased sharing of the cataloguing effort (only create a Manifestation if
no-one else has done so, and then link it to an existing Expression)
 
But I see WEMI as an intermediate stage twixt the record and the statement. The
WEMI classes essentially group bibliographic metadata properties at a lower
granularity than the traditional full record, and perhaps the greatest utility
of FRBR will be to break the hegemony of the catalogue record in the cult(ure)
of cataloguing. See my presentation at
http://gordondunsire.com/pubs/pres/EvolCatRec.ppt(also listed on the wiki).
 
Cheers
 
Gordon
 

On 09 July 2010 at 16:48 Karen Coyle <kcoyle@kcoyle.net> wrote:

> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
>
>
> >
> > Barbara believes the concept of "book" is ambiguous. I believe her.   
> > As far as I know, FRBR does not resolve this conflation by   
> > encouraging us to believe a "book" is a "manifestation".
>
> It seems to me that we've run into the "content v. carrier" issue, 
> something that RDA has attempted to clarify (for the first time in 
> library data, AFAIK). When a person says: "That was a great book" are 
> they referring to the content (the story) or the fact that what they 
> read had pages and a cover? In a sense, they may mean both. But the 
> same person could have read "the book" on a Kindle. Now something 
> changes. The content is the same, the carrier has changed. The person 
> has still read a book.
>
> It is only library cataloging that separates out Work Expression 
> Manifestation. Those distinctions aren't meaningful in "real life", 
> although they may come into play:
>
> "I am reading Proust in English" (translation + expression)
> "Order 7 copies of that book" (Manifestations)
>
> A key point is that you truly cannot separate WEMI - they are aspects 
> of a whole. There is no manifestation without expression, no 
> expression without work.
> In fact, the only one that seems to be able to stand alone is work. 
> ("Professor X is an expert in Moby Dick"). IMO, WEMI will remain a 
> library cataloging concept, and everyone else will have "books" -- 
> which sometimes may have translators and publishers, and other times 
> will only have an author and a title. It will depend on the context.
>
> kc
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>

Received on Tuesday, 13 July 2010 08:43:31 UTC