[DCRM-L] CCDA: discussion paper on machine-actionable data elements in RDA chapter 3

[Robert Maxwell]

Book format is a separate element (RDA 3.12) from extent (RDA 3.4) and dimensions (RDA 3.5). The discussion paper was only about extent and dimensions.

There is, however, a new MARC subfield for recording format, 340 subfield $m, designed for the RDA book format element. We might want to consider recording it there, rather than 300 $c, which is dimensions. Book format is not the same thing as dimensions, so it might be good to use the MARC subfield specifically designed for the information.

Bob

Robert L. Maxwell
Special Collections and Ancient Languages Catalog Librarian
Genre/Form Authorities Librarian
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568

"We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued"--Eliza R. Snow, 1842.

From: dcrm-l-bounces at lib.byu.edu [mailto:dcrm-l-bounces at lib.byu.edu] On Behalf Of Carpenter, Jane
Sent: Monday, July 02, 2012 11:14 AM
To: 'DCRM Revision Group List'
Subject: Re: [DCRM-L] CCDA: discussion paper on machine-actionable data elements in RDA chapter 3

Francis,
Was there any discussion of including format of rare books as another potentially machine-actionable data element?

Jane
From: dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu> [mailto:dcrm-l-bounces at lib.byu.edu]<mailto:[mailto:dcrm-l-bounces at lib.byu.edu]> On Behalf Of Lapka, Francis
Sent: Monday, July 02, 2012 6:57 AM
To: dcrm-l at lib.byu.edu<mailto:dcrm-l at lib.byu.edu>
Subject: [DCRM-L] CCDA: discussion paper on machine-actionable data elements in RDA chapter 3

One of the more interesting items on the agenda of the CC:DA meetings at Annual was a discussion paper on machine-actionable data elements in RDA chapter 3. I encourage everyone to take a look:
http://www.libraries.psu.edu/tas/jca/ccda/docs/tf-MRData3.pdf

>From the Summary and Recommendations section of the paper:

The Task Force was charged to evaluate the structure of data elements in RDA Chapter 3 that contain quantitative information.

After studying the elements for Extent and Dimension, the Task Force recommends an overhaul of RDA's treatment of these elements. Our study of this issue has also highlighted the ambiguity in RDA between content and carrier, especially in regards to extent. We therefore have two recommendations:

1. We recommend that RDA add a treatment of extent that is machine-actionable, using this report and the Aspect-Unit-Quantity model described here as a basis of discussion and detailed recommendations.

2. We recommend a review of the treatment of extent of content ("extent of Expression" in FRBR terminology) at the same time, to strengthen its representation in RDA and provide a more coherent treatment of extent.

The Task Force asks CC:DA to send this report to the JSC for discussion at the JSC's 2012 meeting.

...

The paper proposes a model for recording extent and dimensions using granular data elements. A (very simple) example from the paper illustrates the proposal:

Currently, and using ISBD punctuation, RDA would have us describe a printed volume as:
245 pages ; 23 cm

The Aspect-Unit-Quantity model would break up that statement into its separate parts:

Aspect:            extent/number of subunits
Unit:                pages
Quantity:         245

Aspect:            height
Unit:                centimeters
Quantity:         23
...

Here, aspect and unit are based on controlled vocabularies, and quantity is always a numerical value. I think it is assumed that if data is recorded in this fashion, it would probably be rendered in a different form (via algorithm) when presented in the catalog.

A couple of points merit emphasis:
1. The paper leaves unanswered the question of whether or not the proposed machine-readable version of these elements would replace the current model or exist in parallel. Given the vast amount of legacy records using the traditional model for recording these elements (i.e. with text strings), it seems unlikely that discarding the old model would be a reasonable alternative (nor does it seem likely that the data recorded in textual strings could be automatically converted to machine-actionable form).
2.  This is just a discussion paper, not a revision proposal.

At Annual, CC:DA approved the TF's request to send the paper to JSC for discussion at their upcoming 2012 meeting.

Peter Rolla, chair of the TF, indicated that he still welcomes comments (and possible examples) from various cataloging communities. I would be happy to collect and forward such comments.

I think the paper is an interesting exercise, but I wish it had included several complex examples. I'm not entirely convinced the proposed model, as-is, could handle aspects of the extent and dimensions elements that are quite common in catalog records for early printed material.  Take, for example, the following made-up statement of extent:

x, [8], 15-32, 186 [i.e. 168] p., 12 leaves of plates ([2] folded)

In RDA, using the alternatives for early printed material and the policy statement proposed by PCC for early printed material, I think this would be described as:

x, [8], 15-32, 186, that is 168, pages, 12 leaves of plates ([2] folded)
An attempt to encode this description in the Aspect-Unit-Quantity model proposed in the paper reveals a number of concerns. Some of these include:

*         It's not clear how the model would handle numbered ranges in an extent statement, such as "15-32" in this example.

*         How would the model handle corrections to misleading numbering, as in "186, that is 168, pages" in the example?

*         At times, it seems a qualifier element would be useful, to handle data such as "([2] folded)".

*         If we are recording each subunit as a granular data element, then must we also hard-code the sequence of those subunits? That is, we must specify that "x" comes before "[8]" which comes before "15-32," etc. This is one place where the order of data values very much matters. Even if the specification is hidden from the cataloging interface, shouldn't this be recorded in a distinct field, as part of the model?

Those who find this interesting may wish to see the similar treatment of this topic in CCO (Cataloging Cultural Objects), which also employs a comparable data model for physical descriptions:
http://cco.vrafoundation.org/downloads/PartTwo_3-PhysicalCharacteristics.pdf

Again, I'd be happy to forward any thoughts from our community to the task force.

Best,

Francis

RBMS Liaison to CC:DA


_________________________________
Francis Lapka, Catalog Librarian
Yale Center for British Art, Department of Rare Books and Manuscripts
1080 Chapel Street, PO Box 208280, New Haven, CT  06520
203.432.9672    francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20120702/96281e65/attachment-0001.htm>