Focusing on the present AACR2/MARC/standard-practice environment and
it's problems, one problem is that there's no good way to enter contents
in a controlled way.
You can put contents in a 505 free entry notes field. You can put them
in a _structured_ 505, which at least seperates out title and author.
But even in a structured 505, title and author are supposed to be
transcriptions, you can't enter controlled title and author names
necessary to 'collocate' (which is really another way to say 'neccesary
to relate to foreign FRBR entities in a machine-processable way').
You can enter contents in a 700 'added entry' instead. But the typical
way this is done leaves us (and machines) no good way to tell the
difference between a 700 that is 'contents' and a 700 that is a 'related
work'--very different things! I think it's actually possible to use
MARC to indicate unambiguously that a 700 is contents, and used
controlled values there---but it's not currently preferred practice, and
it's still kind of messy too, and I'm not sure it captures everything
one would want captured (perhaps the transcribed AND controlled values,
associated with each other, same as we have for the aggregating
manifestation itself. Among other things.)
So this is one case where current MARC may not be sufficient for what we
want---but current practice DEFINITELY isn't.
Jonathan
Karen Coyle wrote:
> I think the key thing here is "parts that have their own bibliographic
> integrity" -- which tells me that these parts deserve bibliographic
> access on their own. That's something that the cataloging rules don't
> address well, since cataloging (still) focuses on the distribution
> package. The most glaring examples are short stories and musical pieces.
> Oddly, these get different treatments in today's records: in the latter,
> there is an added entry for the composer and the (uniform) title of the
> piece. In theory, that heading does cause an analytic entry to be
> created (well, it would if we were still creating cards). For the
> former, added entries are rare. Yet the data in the ToC field is often
> enough to create one.
>
> That said, I think we have two different kinds of issues here. One is
> the desire to show users the ToC of a single work. Another is to create
> entries for "parts that have their own bibliographic integrity" and to
> be able to navigate up from the part or down from the whole. I don't
> think we want separate entries for individual chapters in a book that is
> a single unit. I agree with Judith that we need to be able to express
> whole/part (or package/resource) relationships in our databases, and we
> need to be able to give individual works their due, regardless of
> packaging.
>
> kc
>
> Judith Pearce wrote:
>> While time travelling on this list I noticed a discussion on how to
>> encode tables of content in MARC records to support controlled access to
>> authors of the listed parts. I've been mulling over this issue for some
>> time in relation to our still image and audio digitisation projects.
>> When it comes to describing parts that have their own bibliographic
>> integrity I don't think trying to put this data in a note field is the
>> way to go.
>>
>> In our new generation catalogues, why don't we throw tables of contents
>> in records away, start giving parts of things their own records and
>> express parent-child relationships in forms that enable users to
>> navigate up and down bibliographic hierarchies and that enable the
>> generation of tables of content dynamically in displays of the parent
>> record.
>>
>> Why not encode and share tables of content and other lists in a form
>> that can be used to spawn child records that inherit parent details in
>> the appropriate fields and not bother storing this information in the
>> parent record at all.
>>
>> This would make us look more closely at the information that needs to be
>> stored in the child record and the information that can be inherited
>> from the parent to create a full bibliographic citation.
>>
>> It would also make us look at ways of making the encoded relationship
>> persistent when metadata is shipped to other places - union catalogues,
>> federated metadata repositories, Google. Blogs, bibliographies.
>>
>> And it would make us look at ways of encoding the bibliographic citation
>> so that the content inherited from the parent is not lost on export and
>> the relationships can be fully exploited in the new context. I know
>> OpenURL and the DC Citation working group have been working on this
>> problem.
>>
>> This thinking can be extended to manuscript and archive collections,
>> where we tend to treat the finding aid as a table of contents to the
>> whole collection. When a whole collection (or an item in a collection)
>> is digitised, there's a need to support component level searching and
>> bibliographic citation.
>>
>> (How to handle parent-child relationships consistently and in a
>> user-friendly way is still a real issue in our own production systems.
>>
>> http://nla.gov.au/nla.cat-vn3769891 is the best we can do with Voyager.
>> Nuff said.
>>
>> http://nla.gov.au/anbd.bib-an40661746 is the same record in the
>> Australian union catalogue. The direct parent-child relationship is lost
>> because it was invoked by a local system number. The relationship has
>> been expressed as a series, which is certainly not FRBR correct and the
>> link retrieves all the bibliographic records with the same series
>> authority, not the parent record.
>>
>> http://nla.gov.au/nla.ms-ms9803-1-13 - the same record in our digital
>> delivery system. It gives a full bibliographic citation with item number
>> and series details from the finding aid and enables navigation up and
>> down the hierarchy through breadcrumbs.)
>>
>> Judith
>>
>> Judith Pearce
>> Director, Feasibility & Standards
>> National Library of Australia
>> CANBERRA ACT 2600
>> phone: +61 2 62621425
>> email: jpearce_at_nla.gov.au
>>
>>
>>
>
> --
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> kcoyle@kcoyle.net http://www.kcoyle.net
> ph.: 510-540-7596
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
>
--
Jonathan Rochkind
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Tue Jan 30 2007 - 10:41:20 EST