653 index term--uncontrolled

[CECSpecialistI]

https://github.com/uwlib-cams/MARC2RDA/blob/main/Working%20Documents/6XX.csv

[cspayne]

The examples I'm finding of 653 are all subjects:

        <marc:datafield tag="653" ind1="0" ind2=" ">
            <marc:subfield code="a">Biomedia</marc:subfield>
        </marc:datafield>
        <marc:datafield tag="653" ind1="0" ind2=" ">
            <marc:subfield code="a">Biopolitics</marc:subfield>
        </marc:datafield>
        <marc:datafield tag="653" ind1="0" ind2=" ">
            <marc:subfield code="a">Migration</marc:subfield>
        </marc:datafield>
        <marc:datafield tag="653" ind1="0" ind2=" ">
            <marc:subfield code="a">Sexuality</marc:subfield>
        </marc:datafield>
        <marc:datafield tag="653" ind1="0" ind2=" ">
            <marc:subfield code="a">Surveillance</marc:subfield>
        </marc:datafield>
        <marc:datafield tag="653" ind1="0" ind2=" ">
            <marc:subfield code="a">LGBTQ studies</marc:subfield>
        </marc:datafield>

Is there a way to tell whether 653 is a subject or category of work?

[pennylenger]

I don't know. We can ask @AdamSchiff Adam, Is there a way to tell whether 653 is a subject or category of work? Thank you.

[GordonDunsire]

Field 653 indicator 2 = 6 indicates that the uncontrolled term in subfield $a is a 'genre/form term' and we have agreed to map them to category of work.

Note that subfields $0 and $1 contradict the semantics of the field, which is 'uncontrolled', so they should be ignored if they appear.

[AdamSchiff]

Only if second indicator is 6 can you assume the values map to category of work. Except that they could instead map to category of expression or category of manifestation.

Adam

Adam L. Schiff Principal Cataloger University of Washington Libraries Box 352900 Seattle, WA 98195-2900 aschiff @ uw.edu

---

From: pennylenger @.> Sent: Monday, August 12, 2024 5:24:10 PM To: uwlib-cams/MARC2RDA @.> Cc: Adam L Schiff @.>; Mention @.> Subject: Re: [uwlib-cams/MARC2RDA] 653 index term--uncontrolled (Issue #248)

I don't know. We can ask @AdamSchiffhttps://urldefense.com/v3/__https://github.com/AdamSchiff__;!!K-Hz7m0Vt54!hZujfN5SDl0Q7WRLFs6s3qMD1fHTD32w6eDYty9WQNAMSpit45YXiGl9fDKtg7NQtvJFBVOmeHnd2vkkI7ujO54$ Adam, Is there a way to tell whether 653 is a subject or category of work? Thank you.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/issues/248*issuecomment-2285119899__;Iw!!K-Hz7m0Vt54!hZujfN5SDl0Q7WRLFs6s3qMD1fHTD32w6eDYty9WQNAMSpit45YXiGl9fDKtg7NQtvJFBVOmeHnd2vkkuw3VZAg$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB7NQRO7BCBKHAXERD3ZRFG2VAVCNFSM6AAAAABMNDVZ4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBVGEYTSOBZHE__;!!K-Hz7m0Vt54!hZujfN5SDl0Q7WRLFs6s3qMD1fHTD32w6eDYty9WQNAMSpit45YXiGl9fDKtg7NQtvJFBVOmeHnd2vkku_fHpL4$. You are receiving this because you were mentioned.Message ID: @.***>

[GordonDunsire]

@cspayne: Field 653 is given cursory attention in the subject headings discussion document, and none of the examples cover it. The document merely notes that it may be a subject or a genre/form.

Indicator 2 = 0 thru 5 show the type of subject entity. Indicator 2 = # (no information provided) should be mapped to the RDA 'has subject' element.

The heading/index values are uncontrolled by definition, so they map to the uncontrolled recording method with a datatype element and no provenance/source:

<work> rdawd:P10256 "Mann" . // has subject, ind2=0
<work> rdawd:P10321 "Dublin" . // has subject place, ind2 = 5
<work> rdawd:P10261 "Joyce" . // has subject person, ind2 = 1
<work> rdawd:P10256 "fuel cells -- molten carbonate -- power generation" . // has subject, ind2=#, multiple $a values separated by default/LCSH punctuation (double hyphen)
<work> rdawd:P10256 "AcousTech Mastering" //  has subject, ind2=#, ignore $0 (see comment above)
<work> rdawd:P10256 "Russian invasion of Ukraine" . // has subject, ind2=#, ignore $1 (see comment above - **this should be discussed**) 

[cspayne]

When there are multiple $a values, are these combined into one subject? Or are they each individual subjects?

[CECSpecialistI]

Looks like it's different subjects, of the same type. Weird. I hate the 653.

[pennylenger]

I think they can be combined.

[GordonDunsire]

In my example above, 'molten carbonate' is not a standalone subject (check google); it is a type of fuel cell. So I assume that multiple subfield $a should be combined. If there are separate subjects, surely they will be recorded in repeats of the field? Otherwise, I don't see how the index created from this field would be effective for retrieval (other than using boolean search).

[cspayne]

@pennylenger @GordonDunsire Hi Penny and Gordon, with other subject fields, when it is a "has subject [entity]" property (as indicated here by ind2 equaling 1, 2, 3, 4, or 5) but there is no source, we still mint the entity and use an access point instead of minting a nomen as an authorized access point. I think that is what we should do here as well. So instead of has subject person "a" it would be: has subject person <personIRI> personIRI has access point "a"

Unless we choose to go the opposite route and not mint entity IRIs when there is no source and only use a string value. This is what we have decided to do with 720, but I think we need to make a uniform decision either way.

[GordonDunsire]

@cspayne: I agree we should be consistent. The main issue is the deduplication of minted IRIs for entities. In the example above, 'Joyce' as the access point of a minted person needs to be deduplicated against 'Joyce, James, 1882-1941', etc.

However, the 'string as local part of minted IRI' approach may alleviate this, but also introduce new dangers by erroneously deduplicating distinct entities: '.../joyce' may not refer to James Joyce but to another person with the same family name. The possibilities for mischief (uncontrolled!) are great.

So I think we have to be inconsistent with field 653 and not mint an entity IRI. Just use the literal string and don't assume it is an access point, as in the example above. This better reflects the semantics of the field, which doesn't distinguish between name/title, access point, or identifier, and therefore maps to the RDA datatype element.

[szapoun]

My comment is about meetings.

In this mapping we correctly use the datatype property. I am thinking that for cases using the object property we can additionally use the rdaa:P50237 "has category of corporate body" with value 'meeting' to differentiate between corporate bodies and meetings.

[GordonDunsire]

@szapoun: I assume you mean we can map ind2 = 3 to rdaa:P0237, etc., in which case I agree. This is generally ok, so we should check that it has been applied to other fields which indicate a meeting vs corporate body.

[szapoun]

@szapoun: I assume you mean we can map ind2 = 3 to rdaa:P0237, etc., in which case I agree. This is generally ok, so we should check that it has been applied to other fields which indicate a meeting vs corporate body.

Yes @GordonDunsire this is what I am talking about. So, when a corporate body-meeting is minted we should add the rdaa:P50237 "has category of corporate body" with value 'meeting'. This means we should check 111, 611, 711. Am I missing any other meeting-related tag?