Print

Print


Depicted might be all right, but singul "art" connotes something like a
painting.  Is Ali depicted or portrayed?  Change "art" to "arts."
Also someone or something is depicted in an expression (of the work).

Gene Fieg

On Thursday, March 9, 2017, Adam L. Schiff <[log in to unmask]> wrote:

> Actual, the MARC relator terms/codes do have “depicted” already:
>
>
>
> Depicted [dpc]
>
> An entity depicted or portrayed in a work, particularly in a work of art
>
>
>
> The PCC Task Group on Relationship Designators in Authority Records has
> recommended that the MARC relators “depicted” and “setting” be permitted to
> be used in authority records.  For example:
>
>
>
> 100 1  Giacometti, Alberto, ǂd 1901-1966. ǂt Portrait of James Lord
>
> 380     Painting ǂ2 lcsh
>
> 380     Oil paintings (visual works) ǂ2 aat
>
> 400 1  Giacometti, Alberto, ǂd 1901-1966. ǂt James Lord
>
> 500 1  ǂi Artist: ǂa Giacometti, Alberto, ǂd 1901-1966 ǂw r
>
> 500 1  ǂi Depicted: ǂa Lord, James ǂw r
>
>
>
> 100 1  Henry, O., ǂd 1862-1910. ǂt Last leaf
>
> 380     Short stories ǂ2 lcgft
>
> 551    ǂi Setting: ǂa Greenwich Village (New York, N.Y.) ǂw r
>
>
>
> We are still waiting for the final version of the guidelines to be
> published.  Not sure if this recommendation has been accepted though.
>
>
>
> Adam Schiff
>
> University of Washington Libraries
>
>
>
> *From:* Program for Cooperative Cataloging [mailto:[log in to unmask]
> GOV <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>] *On
> Behalf Of *Gene Fieg
> *Sent:* Thursday, March 09, 2017 12:05 PM
> *To:* [log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>
> *Subject:* Re: More confusing RDs (RSC/RelationshipWG/1/Sec final)
>
>
>
> With regard to the movie about Ali, wouldn't it be more accurate to say
> "portrayed in"?
>
> "Described in" implies a sort of objective point of view.
>
> In works of art, that probably isn't true.  There may be truth in the
> portrayal, but it is not "description."
>
>
>
> Gene
>
>
>
> On Thu, Mar 9, 2017 at 11:56 AM, Chiat Naun Chew <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>> wrote:
>
> It’s not immediately obvious from the new examples that Adam cited in
> kicking off this thread, but the Appendix M relationship designators can be
> more granular than existing MARC fields allow. Under “described in (work)”,
> for example, we find “analysed in (work)”, “critiqued in (work)”, etc. It
> would not take many such new relationship designators to outpace the number
> of MARC fields available to express them. The recently approved proposal
> from the British Library and the PCC URI group to use $4 for relationship
> URIs gets around this limitation by allowing this information to be carried
> in a subfield with what is in effect a controlled value.
>
>
>
> Naun.
>
> --
>
> Chew Chiat Naun
> Director, Cataloging & Metadata Services
> 110D Olin Library
> Cornell University
> 607 254 8031 <(607)%20254-8031>
>
>
>
>
>
> *From:* Program for Cooperative Cataloging [mailto:[log in to unmask]
> GOV <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>] *On
> Behalf Of *Amy Turner
> *Sent:* Thursday, March 09, 2017 9:30 AM
>
>
> *To:* [log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>
> *Subject:* Re: [PCCLIST] More confusing RDs (RSC/RelationshipWG/1/Sec
> final)
>
>
>
> Within MARC, it seems redundant to identify a subject by both tag and
> subfield.  Couldn’t this be better handled by sticking to tag in MARC and
> then cross walking into relationship designators in BIBFRAME or whatever?
>
>
>
> Amy
>
>
>
> *From:* Program for Cooperative Cataloging [mailto:[log in to unmask]
> GOV <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>] *On
> Behalf Of *Chiat Naun Chew
> *Sent:* Thursday, March 09, 2017 9:22 AM
> *To:* [log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>
> *Subject:* Re: [PCCLIST] More confusing RDs (RSC/RelationshipWG/1/Sec
> final)
>
>
>
> An alternative may be to continue to use 6XX but define $i (or broaden the
> definition of $e) for it. $4 is already available.
>
> --
>
> Chew Chiat Naun
> Director, Cataloging & Metadata Services
> 110D Olin Library
> Cornell University
> 607 254 8031 <(607)%20254-8031>
>
>
>
> *From:* Program for Cooperative Cataloging [mailto:[log in to unmask]
> GOV <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>] *On
> Behalf Of *Netanel Ganin
> *Sent:* Thursday, March 09, 2017 9:05 AM
> *To:* [log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>
> *Subject:* Re: [PCCLIST] More confusing RDs (RSC/RelationshipWG/1/Sec
> final)
>
>
>
> While I agree with much of what's been said in this thread, I also have a
> practical question:
>
>
>
> the LC-PCC-PS at M.2 states:
>
>
>
> LC practice/PCC practice: The relationship designators found in
> M.2.2-M.2.5, if used, are recorded in $i of a 7XX added entry field or a
> 7XX linking entry field, or incorporated into a note. If applying LCSH, the
> optional use of these relationship designators does not replace any
> applicable LCSH subject access fields (e.g., a 6XX heading for a work in a
> bibliographic record that represents a commentary on that work).
>
>
>
> All these proposed terms will be entering at M.2.6 or later and thus are
> currently outside the scope of the LC-PCC-PS. Thus my question is: will the
> scope of the policy statement be adjusted to incorporate these new terms
> and therefore we'll be entering an array such as:
>
>
>
>
>
> 130 0 _ Ali (Motion picture)
>
>
>
> 600 1 0 Ali, Muhammad, $d 1942-2016.
>
>
>
> 700 1 _ $i Description of (person): $a Ali, Muhammad, $d 1942-2016.
>
>
>
> That is, so long as we're cataloging in the MARC environment, will we be
> doubling subject access points for Agents?
>
>
>
>
> in solidarity,
>
>
>
> Netanel Ganin
>
> ------------------------------------------------------------
>
> Metadata Coordinator -- Hebrew Specialty
>
> Brandeis University
>
> (781) 736-4645 / [log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>
>
>
>
> My pronouns are he/him/his
>
>
>
>
>
> On Thu, Mar 9, 2017 at 8:58 AM, Folsom, Steven <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>> wrote:
>
> Agreed, a simple subject/subjectOf set of properties would be sufficient.
>
>
>
> Are PCC members free to choose already existing less complicated non-RDA
> properties? (sorry for all those adjectives in one sentence)? Maybe this is
> more possible with URIs in the $4?
>
>
>
> ————
>
> Steven Folsom
>
> Metadata Technologies Program Manager
>
> Harvard Library
>
> http://orcid.org/0000-0003-3427-5769
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__orcid.org_0000-2D0003-2D3427-2D5769&d=DwMGaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=Dc2zJWQZhGVM4krkr2m4NTiSqZ5Ld3IvJ8wM_1HzJMc&m=RTk1mwPJydKcNpU1rGzj2_BHTUAVH3aw8b9UKXmgS10&s=z5mHWxR2Aj4xMDpgSTZvEl3-M83EDvzUoxwVmqAiBEY&e=>
>
>
>
>
>
> *From: *Program for Cooperative Cataloging <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>> on behalf of
> Chiat Naun Chew <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>>
> *Reply-To: *Program for Cooperative Cataloging <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>>
> *Date: *Thursday, March 9, 2017 at 8:14 AM
> *To: *"[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>" <
> [log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>>
>
>
> *Subject: *Re: [PCCLIST] More confusing RDs (RSC/RelationshipWG/1/Sec
> final)
>
>
>
> I had hoped that RDA would reconsider its practice of duplicating
> relationships for different entity types, but it does not appear that this
> is happening. It is not self-evident that because a person is a different
> kind of thing from a corporate body, it requires two distinct kinds of
> activity to describe them. It’s also not clear that the FRBR model requires
> it. It may be noted that personal and corporate authorship are covered by
> the same RDA relationship. Why does the same not apply to subjects?
>
>
>
> --
>
> Chew Chiat Naun
> Director, Cataloging & Metadata Services
> 110D Olin Library
> Cornell University
> 607 254 8031 <(607)%20254-8031>
> ------------------------------
>
> *From:* Program for Cooperative Cataloging <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>> on behalf of
> Stephen Hearn <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>>
> *Sent:* 08 March 2017 19:01:53
> *To:* [log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>
> *Subject:* Re: [PCCLIST] More confusing RDs (RSC/RelationshipWG/1/Sec
> final)
>
>
>
> I agree. In some cases the parenthetical specifies the domain of the
> relationship and in other cases it specifies the range of the relationship.
> It would be less ambiguous and more user friendly if this difference was
> reflected in syntax:
>
>
>
> (person) described in
>
> description of (person)
>
>
>
> etc.
>
>
>
> Stephen
>
>
>
> On Thu, Mar 9, 2017 at 8:22 AM, Adam L. Schiff <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>> wrote:
>
> RSC/RelationshipWG/1/Sec final lists a number of new subject relationship
> designators that will be going into RDA:
>
>
>
> M.2.6  Person as Subject of aWork
>
>
>
> described in (person) A work that describes a described person.
>
> Reciprocal relationship: description of (person)
>
>
>
> description of (person) A person described by a describing work.
>
> Reciprocal relationship: described in (person)
>
>
>
> M.2.7 Family as Subject of a Work
>
>
>
> described in (family) A work that describes a described family.
>
> Reciprocal relationship: description of (family)
>
>
>
> description of (family) A family described by a describing work.
>
> Reciprocal relationship: described in (family)
>
>
>
> M.2.8 Corporate Body as Subject of a Work
>
>
>
> described in (corporate body) A work that describes a described corporate
> body.
>
> Reciprocal relationship: description of (corporate body)
>
>
>
> description of (corporate body) A corporate body described by a describing
> work.
>
> Reciprocal relationship: described in (corporate body)
>
>
>
> While I applaud finally having designators to use for persons, corporate
> bodies, and families that are the subjects of works, we again have a
> situation where the “described in” designators are completely
> incomprehensible with the parenthetical addition.   If these designators
> display in ILS’s users will not understand them.  The definitions are quite
> clear, but wouldn’t the designators have been much clearer if they’d been
> formulated some other way, e.g.  “person described in”, “family described
> in”, and “corporate body described in”?  I understand that the qualifier
> refers to the agent being described, but there must be a more clear way of
> making the designators suitable for both RDF and linked data as well as ILS
> displays.
>
>
>
> I’m also wondering why we shouldn’t use “subject” instead of “description
> of”.  Isn’t this much simpler and clear?  “subject of” could replace
> “described in”.
>
>
>
>
>
> Adam L. Schiff
>
> Principal Cataloger
>
> University of Washington Libraries
>
> Cataloging & Metadata Services
>
> Box 352900
>
> Seattle, WA 98195-2900
>
> [log in to unmask] <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>
>
>
>
>
>
>
>
> --
>
> 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 <(612)%20625-2328>
>
> Fx: 612-625-3428 <(612)%20625-3428>
>
> ORCID:  0000-0002-3590-1242
>
>
>
>
>