Print

Print


We don't yet have a work AAP for this aggregation, so we can't formulate an
expression AAP for it. It would have to be different from the work AAP for
the novel, and arguably would not have the same choice for main entry (cf.
the RSC Aggregates Working Group discussion paper
<http://www.rda-rsc.org/sites/all/files/RSC-AggregatesWG-1-AggregatesWG-response-rev.pdf>,
page 7, LC question 2 and response, calling for entry of aggregates under
the compiler name).

Currently in RDA we can only assert "Work A / Container of (work) / Work
B," so logically we have to be able to formulate an AAP for Work A, which
as Yang says is very difficult, mainly because we have relatively little
precedent for work AAPs. Most works are only implicit in manifestation
descriptions. Manifestation descriptions have not needed AAPs because we
are used to identifying them with flexible concatenations of data or with
proximate identifiers like ISBN, not with strictly pre-coordinated AAPs.

If we could assert in RDA "Manifestation A / Container of (work) / Work B"
and accept that the ways we identify manifestations are sufficient for our
user tasks and don't require AAPs,  that could be a step toward a more
practicable solution.

Stephen

On Tue, Apr 4, 2017 at 10:29 AM, Yang Wang <[log in to unmask]> wrote:

> Thanks. For all practical purposes, allow me to return to our original
> scenario:
>
> 245 00 $a Mail carrier = $b El cartero / $c JoAnn Early Macken.
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier. $l English.
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier. $l Spanish.
>
> Per Appendix J, there must be a container (of expression) that is larger
> than either of 2 700 fields, do we agree? That would be, in olden days, an
> entity like this:
>
> 100 1  $a Macken, JoAnn Early, $d 1953- $t Mail carrier. $l Spanish &
> English
>
> But that possibility is gone, and now we would have to construct an
> expression-level AAP for it (very difficult to do) or simply look somewhere
> else and avoid using "Container of (expression)" altogether. Would the
> following relationship designators work at all?
>
> a) based on J.3.2 (derivative expression relationship):
> 700 12 $i Translation of: $a Macken, JoAnn Early, $d 1953- $t Mail
> carrier. $l English.
> 700 12 $i Translated as:  $a Macken, JoAnn Early, $d 1953- $t Mail
> carrier. $l Spanish.
>
> Or
>
> b) based on J.3.5 (accompanying expression relationship):
> 700 12 $i Complemented by (expression): $a Macken, JoAnn Early, $d 1953-
> $t Mail carrier. $l English.
> 700 12 $i Complemented by (expression):  $a Macken, JoAnn Early, $d 1953-
> $t Mail carrier. $l Spanish.
>
> Just a thought. Comments, please.
>
> Yang
>
> -----Original Message-----
> From: Program for Cooperative Cataloging [mailto:[log in to unmask]]
> On Behalf Of McDonald, Stephen
> Sent: Monday, April 03, 2017 4:28 PM
> To: [log in to unmask]
> Subject: Re: [PCCLIST] Container of/Contained in
>
> Yang Wang asks, "That being said, for consistency, do we all agree then
> that the designator "Container of (...)" in the bibliographical description
> represents the physical container, whereas in authority records we stick to
> single entity types and don't mix?"
>
> No, I don't agree.  I think that in _all_ of the whole-part relationships
> in Appendix J, the entity type in the parentheses applies to both sides of
> the relationship.  Container of (expression) is used for an expression
> which contains another expression.  Container of (manifestation) is used
> for a manifestation which contains another manifestation.  This is true
> whether the relationship designator is used in a bibliographic record or an
> authority record.  I believe the descriptions of the subtypes listed under
> the designators in Appendix J supports this interpretation.
>
>                                         Steve McDonald
>                                         [log in to unmask]
>
>
> -----Original Message-----
> From: Program for Cooperative Cataloging [mailto:[log in to unmask]]
> On Behalf Of Yang Wang
> Sent: Monday, April 3, 2017 11:27 AM
> To: [log in to unmask]
> Subject: Re: [PCCLIST] Container of/Contained in
>
> Adam,
>
> I agree. In practice, most of us do seem to have been viewing the
> designator "Container of (...)" "as being the manifestation ... the
> physical container."
>
> In theory (per RDA), however, there is this complication. A quick look in
> the Glossary under "Container of/in (...)" makes one question their
> universal applicability in the bibliographic description. "Container of
> (work)" means " A work that is a discrete component of a larger work" ...
> etc. For a compilation of the same-type aggregates, it may work nicely. For
> a compilation of aggregates of varying types, it's confusing, unless of
> course we consistently view the entire manifestation itself as the
> "container." By the way, the definition for "Container" itself (in the RDA
> glossary) is:  "A housing that is physically separable from the carrier
> being housed."
>
> I realize that RDA/LRM is designed not just for the current MARC
> environment, but for whatever replaces it in the future. Due to certain
> limitations in MARC, mixed entities or usages are unavoidable.  That being
> said, for consistency, do we all agree then that the designator "Container
> of (...)" in the bibliographical description represents the physical
> container, whereas in authority records we stick to single entity types and
> don't mix?
>
> Yang
>
>
> -----Original Message-----
> From: Program for Cooperative Cataloging [mailto:[log in to unmask]]
> On Behalf Of Adam L. Schiff
> Sent: Friday, March 31, 2017 8:45 PM
> To: [log in to unmask]
> Subject: Re: [PCCLIST] Container of/Contained in
>
> In the bibliographic description, I view the "container" as being the
> manifestation that is being described by the bibliographic record, that is,
> the physical container.  Therefore I don't see the self-reference that
> others refer to as "work contains itself".  I do realize that in most
> simple cases, we let the 100/245 do the duty of saying what work is
> contained in the manifestation.  I think in an ideal MARC world for RDA we
> would do away completely with using 1XX and 240 and simply use 245 to
> transcribe what appears on the manifestation, and then use 7XX to provide
> access to the works and expressions contained in the manifestation, so:
>
> 245 00 $a Mail carrier = $b El cartero / $c JoAnn Early Macken.
> 700 12 $i Container of (work): $a Macken, JoAnn Early, $d 1953- $t Mail
> carrier.
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier. $l Spanish.
>
> or if you needed to explicitly name BOTH expressions:
>
> 245 00 $a Mail carrier = $b El cartero / $c JoAnn Early Macken.
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier. $l English.
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier. $l Spanish.
>
> Actually, there would be nothing preventing one from naming the work AND
> both expressions:
>
> 245 00 $a Mail carrier = $b El cartero / $c JoAnn Early Macken.
> 700 12 $i Container of (work): $a Macken, JoAnn Early, $d 1953- $t Mail
> carrier.
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier. $l English.
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier. $l Spanish.
>
> Mark Ehlert wrote: "If proceeding with the calculus that the work AAP =
> the original language expression AAP, then perhaps the following
> clarification is in order:
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier."
>
> I think the use show in the LC/PCC PS is a shortcut for convenience (and
> perhaps to avoid split files with how we currently describe things in
> MARC), and I agree with Bob Maxwell that "Macken, JoAnn Early, 1953- Mail
> carrier" can only be a work access point in RDA.  To be an expression
> access point, one must add an expression element (content type, date of
> expression, language of expression, and/or other distinguishing
> characteristic of expression) to the authorized access point for a work.
> Therefore, using "Container of (expression)" is never appropriate with a
> work access point.
>
> Doing away with the 1XX and 240 fields when we implemented RDA might have
> made things more simple and clear, but they would have also required us to
> always explicitly record an authorized access point for the work(s) or
> expression(s) manifested in 7XX fields, which would have created somewhat
> more work for catalogers.
>
> Adam Schiff
> University of Washington Libraries
>
> -----Original Message-----
> From: Program for Cooperative Cataloging [mailto:[log in to unmask]]
> On Behalf Of Ehlert, Mark K.
> Sent: Friday, March 31, 2017 2:26 PM
> To: [log in to unmask]
> Subject: Re: Container of/Contained in
>
> From: Program for Cooperative Cataloging [mailto:[log in to unmask]]
> On Behalf Of Yang Wang
> Sent: Friday, March 31, 2017 3:15 PM
> >
> > Interesting and fair enough. But if the combination of the Name/Title
> > entries (100/245) in the bib itself could stand for the larger “work”
> > of which the first 700 is a constituent...
>
> Which produces the statement that the work contains itself, which rankles
> me to no end.  I did away with this practice in my local video cataloging.
> For dubbed films, I add a 130 when appropriate for the work and incorporate
> 730 02s with "Container of (expression)" for each language version,
> including the original.
>
> If proceeding with the calculus that the work AAP = the original language
> expression AAP, then perhaps the following clarification is in order:
> 700 12 $i Container of (expression): $a Macken, JoAnn Early, $d 1953- $t
> Mail carrier.
>
> --
> Mark K. Ehlert                 O'Shaughnessy-Frey Library
> Cataloging and Metadata        University of St. Thomas
>   Librarian                    2115 Summit Avenue
> Phone: 651-962-5488            St. Paul, MN 55105
> <http://www.stthomas.edu/libraries/>
>
>   "Experience is by industry achieved // And perfected by the swift course
> of time"--Shakespeare, "Two Gentlemen of Verona," Act I, Scene iii
>
>
>


-- 
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID:  0000-0002-3590-1242