Quoting michael.borr...@mail.cuny.edu:
In terms of films vs. texts, we can think of Shakespeare. The texts of his plays are entered under his name, but filmed productions are entered under title. In the case of adaptations of novels for the screen, there is a screenwriter involved, as well, so these productions are not the work of the original author. So I think this would be work related to work.
Hmm. In the role of advocatus diaboli, I ask: is a stage performance of a Shakespeare play, recorded on video or film, the same work as the text? It necessarily involves persons in quasi-creative roles (director, actors) whose contribution will materially affect the meaning, even the content, of the play (and, after all, the texts of some Shakespeare plays exist in different versions right from their first publication); and some modernized productions may be more in the nature of adaptations than simply expressions.
It appears that many modern theorists of literature, who also discuss the nature of the work and the distinction between text (meaning approximately what we call "work") and document (meaning what we call "manifestation", see a distinction between text and performance.
This seems to me to support the idea that there's space for a "superwork" entity -- which I too have long supported.
But (prescriptions of RDA perhaps notwithstanding -- I don't have the text of RDA available at present) we should not forget that FRBR is a conceptual framework, not a code: the limits and applications of the concepts are defined by the particular code and the application decisions made in implementing it. Those application decisions are heavily coloured by the fact that there has to be a level of compatibility between past practice (AACR2/LCRI, also in part earlier codes/practices). In particular the handling of work and expression entities in terms of authority data precludes us from doing what was envisaged: recording features of work and expression on the basis of what's common between different manifestations, and saving ourselves from having to reinvent the same wheel every time we catalogue a different manifestation -- common tabulation of relationships, access points for Group One entities, subject treatment, appropriate coded data, standard classifications -- and making clear what the differences between expressions and manifestations really are. The MARC 21 schemas handle agents (person, corporate body, family) as authority records and manifestations as bibliographic records (also items as Holdings data), but they have no way for us to compose work or expression records which tie together common data as I outlined above.
Nevertheless cataloguing is a pragmatic discipline and we have to do the best we can with the tools we actually have, not vapourware merely foreshadowed!
In an ideal environment, I would like to work in a pattern like this: (1) examine a manifestation (on my desk, screen, in earphones, etc.) to see if it represents (a) a new work, (b) a new expression of a previously-recorded work [recorded as in cataloguing, not as in recorded sound!]; (2) if new, create or compile the bibliographic data and deal with the item(s). in a system of coding or mark-up which includes simple flagging of work-level and expression-level data; (3) if not new, collate existing data for other manifestations to produce the common work and expression data, and add the manifestation data, and deal with the item(s). Much of that work of collating existing data can be prepared by good cataloguing software.
I see no point whatsoever in explicitly creating distinct datasets or records for works or manifestations for which only a sole expression exists! When or if it's required, the machine can do the preliminary grunt work if the tagging/markup of the data carries sufficient discrimination -- and that markup should be surely sufficient for processing bibliographic data for other contexts and applications. I'm well aware that much existing bibliographic data is not adequately discriminated (yet), but tools exists that embody these concepts or similar ones, e.g. OCLC's automated duplicate detection routines.
If I'm making unjustified assumptions about the possibilities for simplifying our labours, I hope others will make it clear how they're unjustified. If the mantra "doing more with less" is to me realized, we need smarter tools so our work (!) becomes less laborious. Superimposing RDA on existing structures, formats and workflows cannot achieve that (but it may be a necessary first stage -- in which case we need to make sure the interim costs don't kill the whole enterprise, which would indeed be discarding the baby along with the water and the tub!)
Hal Cain Melbourne, Australia hec...@dml.vic.edu.au ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
