Subject Heading #447
Replies: 20 comments 30 replies
-
My main question has been if the transformation will use the subject document or the google drive sheet. In the latter case, I will have to review the mapping of 630 there to align with the subject document |
Beta Was this translation helpful? Give feedback.
-
Decisions: Examples found in my copy of the partial LC file from 2022 are: These terms are a mix of carrier type, content type, and unknown (realia?) and it would be a challenge to map the official AACR terms (1.1.C1) to RDA values, much less the additional terms that have cropped up in records over time. I suggest that we do not attempt to map $h. • $m, $o, $r are associated with the distinct phrase "uniform title for a work"; that is, a work aap qualified by representative expression attributes. Do any music people know whether there is a list of types of compositions we could use? |
Beta Was this translation helpful? Give feedback.
-
Hi all, I also pull out questions in [HeadingsFieldsPersonalNames.20240305]. Sorry about the format. (https://docs.google.com/spreadsheets/d/1_wszM48Mrr2KTGsZgAboUVFVvAmJJm02/edit#gid=1691044164) <style type="text/css"></style>
<style type="text/css"></style>
$n - Number of part/section of a work (R) opus number IF 'op.' or 'opp.' Map only as part of AP, in order given? <style type="text/css"></style>
<style type="text/css"></style>
<style type="text/css"></style>
|
Beta Was this translation helpful? Give feedback.
-
Deborah,
See MLA's Types of Composition for Use in Authorized Access Points for Music: Complete List
https://cmc.wp.musiclibraryassoc.org/types-of-composition-for-use-in-authorized-access-points-for-music-a-manual-for-use-with-rda/
Adam
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: Deborah Fritz ***@***.***>
Sent: Tuesday, April 16, 2024 4:47 PM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
Decisions:
• I now think that $h is ok as an indicator of expression, and it maps to Expression "has content type".
DF: I disagree the $h carries 'content type' data. It contains what used to be called a "General material designation".
Examples found in my copy of the partial LC file from 2022 are:
braille; compact disc; computer file; electronic resource; Filmstrip; graphic; interactive multimedia; kit; microform; motion picture; pamphlet; Phonodisc; serial; slide; sound recording; videorecording
These terms are a mix of carrier type, content type, and unknown (realia?) and it would be a challenge to map the official AACR terms (1.1.C1) to RDA values, much less the additional terms that have cropped up in records over time.
I suggest that we do not attempt to map $h.
• $m, $o, $r are associated with the distinct phrase "uniform title for a work"; that is, a work aap qualified by representative expression attributes.
DF: I agree that they should be considered to be qualifiers for a work when the uniform title begins with a type of composition. But if they are added to a title that is not a type of composition, they should be qualifiers for an expression. The trick is distinguishing between those two types of titles.
Do any music people know whether there is a list of types of compositions we could use?
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-9135981__;Iw!!K-Hz7m0Vt54!gbn5x-lxQz2j79-xIdPguKU3rYV_25DQ9dJnKkVBsQWeGm2lSCBfPbYBgXLs2TiDW9v8tP3LnJ_9UHgOKCA5-x4$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB2G7NI5SBGUHV4ZFF3Y5W2APAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMZVHE4DC__;!!K-Hz7m0Vt54!gbn5x-lxQz2j79-xIdPguKU3rYV_25DQ9dJnKkVBsQWeGm2lSCBfPbYBgXLs2TiDW9v8tP3LnJ_9UHgOM4lhMcY$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I'm not aware of anything but the HTML list.
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: Deborah Fritz ***@***.***>
Sent: Wednesday, April 17, 2024 7:53 AM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
Is there a downloadable version anywhere?
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-9144220__;Iw!!K-Hz7m0Vt54!h1HH37al1dlRaRVLHlIm6cAhcLBeU6v4kb6ONQTt5fPa328FZw_L1IixujHsXqiQ71i8pVHiBAW9VUtU8-2Es7o$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB6BUQMNSYJVZR77SB3Y52EF7AVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNBUGIZDA__;!!K-Hz7m0Vt54!h1HH37al1dlRaRVLHlIm6cAhcLBeU6v4kb6ONQTt5fPa328FZw_L1IixujHsXqiQ71i8pVHiBAW9VUtUJiR83Pc$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
@GordonDunsire @AdamSchiff @tmqdeborah Hi, have we decided whether to use $1 or $0 directly if it is a uri such as those worldcat enetity https://entities.oclc.org/worldcat/entity/E39PBJccf4vKJMFQkyghCdgtKd.html in subject heading and ignore other subfields? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Hi Adam, Thank you very much for your reply. I am sorry I didn't make it clear. |
Beta Was this translation helpful? Give feedback.
-
@lake44me Hi Laura, thank you very much for your reply. I find this |
Beta Was this translation helpful? Give feedback.
-
Penny,
When you refer to a system number in $0, are you talking about FAST authority IDs? Such as:
650 #7 Mustelidae. ǂ2 fast ǂ0 (OCoLC)fst01031131
650 #7 Scavengers (Zoology) ǂ2 fast ǂ0 (OCoLC)fst01106593
650 #7 Wolverine. ǂ2 fast ǂ0 (OCoLC)fst01176533
650 #7 Zoology. ǂ2 fast ǂ0 (OCoLC)fst01184696
655 #7 Juvenile works. ǂ2 fast ǂ0 (OCoLC)fst01411637
It's easy to generate the FAST URI from this: Append the ID (number part only, and remove any leading zeros) to http://id.worldcat.org/fast/. The URI goes in $0 for FAST. (You can see all this at https://www.wikidata.org/wiki/Wikidata:WikiProject_URIs_in_MARC.)
So the equivalent of ǂ0 (OCoLC)fst01031131 is ǂ0 http://id.worldcat.org/fast/1031131
Is that what you meant?
Adam
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: pennylenger ***@***.***>
Sent: Tuesday, July 23, 2024 3:25 PM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
@lake44me<https://urldefense.com/v3/__https://github.com/lake44me__;!!K-Hz7m0Vt54!lSZ6vCBKrhxcxAYI_NTKo7rT_fW_SvCXo8uiK-bnGE6ysyIt6hwk9KRwtDWJaq7CgJHYbiIA59riL1ts5ubw1yo$> Hi Laura, thank you very much for your reply. I find this
651 #7<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/issues/7__;!!K-Hz7m0Vt54!lSZ6vCBKrhxcxAYI_NTKo7rT_fW_SvCXo8uiK-bnGE6ysyIt6hwk9KRwtDWJaq7CgJHYbiIA59riL1tsnTHgtNU$> Washington (State) ǂz Seattle ǂ2 fast ǂ1 https://id.oclc.org/worldcat/entity/E39PBJrWFwxmr6yX7fxxbMJv73<https://urldefense.com/v3/__https://id.oclc.org/worldcat/entity/E39PBJrWFwxmr6yX7fxxbMJv73__;!!K-Hz7m0Vt54!lSZ6vCBKrhxcxAYI_NTKo7rT_fW_SvCXo8uiK-bnGE6ysyIt6hwk9KRwtDWJaq7CgJHYbiIA59riL1tsQdPmM4M$> ǂ0 (OCoLC)fst01204940 The worldcat entity is for ǂz Seattle. But they both refer to Seattle.
@AdamSchiff<https://urldefense.com/v3/__https://github.com/AdamSchiff__;!!K-Hz7m0Vt54!lSZ6vCBKrhxcxAYI_NTKo7rT_fW_SvCXo8uiK-bnGE6ysyIt6hwk9KRwtDWJaq7CgJHYbiIA59riL1tsoTzJFlA$> Thank you. I got a more general question. For a system number in $0 in subject heading, how can we map it or do we map it? Is it a identifier or metadata or something else?
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-10131466__;Iw!!K-Hz7m0Vt54!lSZ6vCBKrhxcxAYI_NTKo7rT_fW_SvCXo8uiK-bnGE6ysyIt6hwk9KRwtDWJaq7CgJHYbiIA59riL1tsyVqpRpE$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB7FDARHN3VZTMOU6JLZN3J7FAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJTGE2DMNQ__;!!K-Hz7m0Vt54!lSZ6vCBKrhxcxAYI_NTKo7rT_fW_SvCXo8uiK-bnGE6ysyIt6hwk9KRwtDWJaq7CgJHYbiIA59riL1tsu-3fTGw$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
WorldCat Entities are not being created for subjects/subject strings. They are only created for agents. No entity would be created for an agent with a topical/form/geographic/chronological subdivision, since that is an LCSH string and these are not in scope for WorldCat Entities.
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: Laura Akerman ***@***.***>
Sent: Tuesday, July 23, 2024 5:01 PM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
Here's what I could find about Worldcat Entity URIs...
https://help.oclc.org/Metadata_Services/WorldShare_Record_Manager/Bibliographic_records/MARC_21_view/Insert_a_WorldCat_Entity_identifier_in_a_bibliographic_record<https://urldefense.com/v3/__https://help.oclc.org/Metadata_Services/WorldShare_Record_Manager/Bibliographic_records/MARC_21_view/Insert_a_WorldCat_Entity_identifier_in_a_bibliographic_record__;!!K-Hz7m0Vt54!lAPyaruxwcRQ_gdNPlbeIcnUHBiXUFGgA7OJ8ChkWcaDkuH9Rr2m1bw0PrBHEpG53WebehekNpzdAat7wj3QoWg$> . Right now they are only for 100, 110, 600, 610, 647, 651, 700, or 710 fields. There is an instruction "Note: For the 610, 647 and 710 fields, only insert an identifier for name headings (no titles)." - no mention is made of the 6xx fields having subfields x, y, z or v.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-10131885__;Iw!!K-Hz7m0Vt54!lAPyaruxwcRQ_gdNPlbeIcnUHBiXUFGgA7OJ8ChkWcaDkuH9Rr2m1bw0PrBHEpG53WebehekNpzdAat7AjEahEE$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB532U3IC4QTVA32X3LZN3VGJAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJTGE4DQNI__;!!K-Hz7m0Vt54!lAPyaruxwcRQ_gdNPlbeIcnUHBiXUFGgA7OJ8ChkWcaDkuH9Rr2m1bw0PrBHEpG53WebehekNpzdAat7U6OMSYE$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
@pennylenger: to sum up (I think): A subfield $0 or $1 in a 6xx subject heading field is assumed to represent the entire heading and not just a part. This applies if the heading has only a subfield $a thru a heading that is split between multiple subfields. It does not matter how the heading is split, say into a name part, title part, and qualifier/subdivision part that are accommodated in one or more distinct subfields. It is the whole heading that is represented by the $0 or $1 URI If the value of subfield $0 is a URI, it can be transformed directly because we assume that the record follows PCC guidance to use $0 instead of $1. If the value of subfield $0 is in the form of a source code in parentheses followed by a local identifier number, it may be ok to transform the value into an IRI by replacing the source code with the base domain of the source's RDF representation and normalizing the identifier. We have agreed that this is safe for '(OCoLC)'; from what I can see, it is also safe for the source code for AAT. We will have to check each of the commonly-used source vocabularies that the semantics are ok and that identifier normalization has a regular pattern. There is no need for an on-the-fly lookup in the transform. Instead, a simple transform/normalization template for each approved source is sufficient. We assume that if there is an identifier in subfield $0, there is a corresponding IRI in the source vocabulary's RDF. In general, the semantics of the value must match the semantics of the MARC 21 field and the whole heading. The example of WorldCat identities for 'Republic of India' in subfield $0 in field 651 with only subfield $a is safe, because WC types the value as 'AdministrativeArea', but it would be incorrect if subfields $g, $v, $x, $x, or $z were also recorded. Field 651 plus $a, of course, indicates that the RDA relationship is 'has subject place', otherwise the default 'has subject' must be used. Prefer subfield $1 over $0 if both are present. I don't see how the cataloguer choose between the subfields, unless this is part of the PCC guidance (I think there's some kind of list of sources which I haven't checked, but why WorldCat and FAST are treated differently is a mystery to me. |
Beta Was this translation helpful? Give feedback.
-
The folks from OCLC say that their URI for FAST should go in $0, while WorldCat Entities URI should go in $1. OCLC recently confirmed this regarding FAST.
The transformations from identifier to URI can be found at https://www.wikidata.org/wiki/Wikidata:WikiProject_URIs_in_MARC
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: GordonDunsire ***@***.***>
Sent: Wednesday, July 24, 2024 5:35 AM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
@pennylenger<https://urldefense.com/v3/__https://github.com/pennylenger__;!!K-Hz7m0Vt54!l_OXXjKwyCnkgP84W2KDDch2fVqRBE9T0kcSksgMtcQRs-ioP287G4ZkcWm7jiIPHWwQ5pA2nTCYQNvGmiPFRMo$>: to sum up (I think):
A subfield $0 or $1 in a 6xx subject heading field is assumed to represent the entire heading and not just a part. This applies if the heading has only a subfield $a thru a heading that is split between multiple subfields. It does not matter how the heading is split, say into a name part, title part, and qualifier/subdivision part that are accommodated in one or more distinct subfields. It is the whole heading that is represented by the $0 or $1 URI
If the value of subfield $0 is a URI, it can be transformed directly because we assume that the record follows PCC guidance to use $0 instead of $1.
If the value of subfield $0 is in the form of a source code in parentheses followed by a local identifier number, it may be ok to transform the value into an IRI by replacing the source code with the base domain of the source's RDF representation and normalizing the identifier. We have agreed that this is safe for '(OCoLC)'; from what I can see, it is also safe for the source code for AAT. We will have to check each of the commonly-used source vocabularies that the semantics are ok and that identifier normalization has a regular pattern.
There is no need for an on-the-fly lookup in the transform. Instead, a simple transform/normalization template for each approved source is sufficient. We assume that if there is an identifier in subfield $0, there is a corresponding IRI in the source vocabulary's RDF.
In general, the semantics of the value must match the semantics of the MARC 21 field and the whole heading. The example of WorldCat identities for 'Republic of India' in subfield $0 in field 651 with only subfield $a is safe, because WC types the value as 'AdministrativeArea', but it would be incorrect if subfields $g, $v, $x, $x, or $z were also recorded. Field 651 plus $a, of course, indicates that the RDA relationship is 'has subject place', otherwise the default 'has subject' must be used.
Prefer subfield $1 over $0 if both are present. I don't see how the cataloguer choose between the subfields, unless this is part of the PCC guidance (I think there's some kind of list of sources which I haven't checked, but why WorldCat and FAST are treated differently is a mystery to me.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-10137261__;Iw!!K-Hz7m0Vt54!l_OXXjKwyCnkgP84W2KDDch2fVqRBE9T0kcSksgMtcQRs-ioP287G4ZkcWm7jiIPHWwQ5pA2nTCYQNvGMX0yRQw$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB2LK4OSR2CJAQZD7BTZN6NRHAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJTG4ZDMMI__;!!K-Hz7m0Vt54!l_OXXjKwyCnkgP84W2KDDch2fVqRBE9T0kcSksgMtcQRs-ioP287G4ZkcWm7jiIPHWwQ5pA2nTCYQNvGqiQvosQ$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
This is what Morris Levy at OCLC told me when we noticed that FAST URIs were analyzed as representing entities by the Vapour validator:
"I also asked about using $0 and $1 for FAST URIs and it was confirmed that FAST URIs were not intended to be real world identifiers, even if the URI resolves to an RDF representation."
He has also told the task group that is working on URI best practices that the original FAST RDF was experimental and developed by OCLC Research and the Jeff Mixner has said that they will probably be redoing some of the coding to make it clear it is an authority and not an RWO.
FYI... this is what Vapour has to say about FAST URIs. I asked it to analyze http://id.worldcat.org/fast/1175365 and got this back:
[cid:71b0b6d3-b30a-4b11-980b-8f159aac809a]
This is why Morris Levy went back to the FAST folks at OCLC to ask if we should be putting FAST URIs in $1 instead of $0.
Adam
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: GordonDunsire ***@***.***>
Sent: Thursday, July 25, 2024 1:29 AM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
@AdamSchiff<https://urldefense.com/v3/__https://github.com/AdamSchiff__;!!K-Hz7m0Vt54!jkH978eDvGqfPx-KRyVLQI2w3w0LTz-y3tBOjancyGWImA3p1opzkxS8tyV271p169Z25ZdCkW0II1ExMPqzeQ0$>: Is this because FAST is a set of skos:Concepts and WorldCat Entities is not? If so, this is just current PCC guidance in action.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-10146393__;Iw!!K-Hz7m0Vt54!jkH978eDvGqfPx-KRyVLQI2w3w0LTz-y3tBOjancyGWImA3p1opzkxS8tyV271p169Z25ZdCkW0II1ExGExnp6Q$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB5MFMLT4UBII3DYL3DZOCZPTAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJUGYZTSMY__;!!K-Hz7m0Vt54!jkH978eDvGqfPx-KRyVLQI2w3w0LTz-y3tBOjancyGWImA3p1opzkxS8tyV271p169Z25ZdCkW0II1ExA5ed58M$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
@GordonDunsire Hi Gordon. I have a question about the example below for 647. If $0 references the complete heading as an event which is not an RDA entity, why can’t we use the converted URI as the object of the triple? If there is a $1, can we use it? And should we mint a skos:concept for the complete heading for 647? And if there is a $c - Location of named event (R), should we map it to subject place like the timespan? Another question is about concept for ( $x, $y, $z) For example, for 600, if there is a subject work, it will be: If there is no subject work, like: And should we mint a concept for ( $x, $y, $z) each time they appear or under some circumstance? They seem redundant. |
Beta Was this translation helpful? Give feedback.
-
I don't think you can say that there is a FAST authorized access point for timespan that is derived from the $d of a 647 field. The authorized access point in 647 is for an event, not a timespan.
To say that there is an authorized access point from FAST with nomen string 1939-1945 there must be a FAST authority for that timespan by itself, not as part of an access point for an event.
FAST timespans as subjects are given in 648:
648 #7 1939-1945 $2 fast
There is an authority for the time period 1939-1945 in FAST: http://id.worldcat.org/fast/1355886
Here's the MARC XML for that authority:
<marc:record>
<marc:leader>00000cz a2200000n 4500</marc:leader>
<marc:controlfield tag="001">fst01355886</marc:controlfield>
<marc:controlfield tag="003">OCoLC</marc:controlfield>
<marc:controlfield tag="005">20230821120000.0</marc:controlfield>
<marc:controlfield tag="008">070114nn anznnbbbn || ana d</marc:controlfield>
<marc:datafield tag="016" ind1="7" ind2=" ">
<marc:subfield code="a">fst01355886</marc:subfield>
<marc:subfield code="2">OCoLC</marc:subfield>
</marc:datafield>
<marc:datafield tag="024" ind1="7" ind2=" ">
<marc:subfield code="a">http://id.worldcat.org/fast/1355886</marc:subfield>
<marc:subfield code="2">uri</marc:subfield>
</marc:datafield>
<marc:datafield tag="040" ind1=" " ind2=" ">
<marc:subfield code="a">OCoLC</marc:subfield>
<marc:subfield code="b">eng</marc:subfield>
<marc:subfield code="c">OCoLC</marc:subfield>
<marc:subfield code="f">fast</marc:subfield>
</marc:datafield>
<marc:datafield tag="148" ind1=" " ind2=" ">
<marc:subfield code="a">1939-1945</marc:subfield>
</marc:datafield>
<marc:datafield tag="448" ind1=" " ind2=" ">
<marc:subfield code="a">World War II Period</marc:subfield>
</marc:datafield>
<marc:datafield tag="688" ind1=" " ind2=" ">
<marc:subfield code="a">LC (2022) Subject Usage: 0</marc:subfield>
</marc:datafield>
<marc:datafield tag="688" ind1=" " ind2=" ">
<marc:subfield code="a">WC (2022) Subject Usage: 0</marc:subfield>
</marc:datafield>
</marc:record>
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: pennylenger ***@***.***>
Sent: Tuesday, July 30, 2024 12:29 PM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
@GordonDunsire<https://urldefense.com/v3/__https://github.com/GordonDunsire__;!!K-Hz7m0Vt54!mvV-EUEbYYLZbUS19KLazlsc2oCl2xGyjSOjH3QmE_fFBEEKEJtSn6PcRiQLrKKj4te4Aox4sJeqvXgzLVEdhfk$> Hi Gordon. I have a question about the example below for 647. If $0 references the complete heading as an event which is not an RDA entity, why can’t we use the converted URI as the object of the triple? If there is a $1, can we use it? And should we mint a skos:concept for the complete heading for 647?
Example 66
647 7 $a World War $d (1939-1945) $2 fast $0 (OCoLC)fst01180924
rdawo:P10322 . // has subject timespan; ignore subfield $0 which references the complete heading as an event (not an RDA entity)
rdato:P70047 . // has authorized access point for timespan
rdand:P80068 “1939-1945” . // has nomen string
rdano:P80069 http://id.loc.gov/vocabulary/subjectSchemes/fast<https://urldefense.com/v3/__http://id.loc.gov/vocabulary/subjectSchemes/fast__;!!K-Hz7m0Vt54!mvV-EUEbYYLZbUS19KLazlsc2oCl2xGyjSOjH3QmE_fFBEEKEJtSn6PcRiQLrKKj4te4Aox4sJeqvXgzpebq0H8$> . // has scheme of nomen
And if there is a $c - Location of named event (R), should we map it to subject place like the timespan?
Another question is about concept for ( $x, $y, $z)
Concept (exists(600, 610, 611. 648, 651 $x, $y, $z))
rdawo:P10256 <tConcept(field)> . // has subject; topical subdivisions
<tConcept(field)> skos:prefLabel “stripEndStop(concatenateOA($x, $y, $z))” .
<tConcept(field)> skos:inScheme <tScheme(field)> .
For example, for 600, if there is a subject work, it will be:
[work] rdawo:P10257 . // has subject work
[workS] rdawo:P10256 <tConcept(field)> . // has subject
<tConcept(field)> skos:prefLabel “stripEndStop($x, $y, $z)” .
<tConcept(field)> skos:inScheme <tScheme(field)> .
If there is no subject work, like:
600 00$aJesus Christ$xHistory of doctrines$yEarly church, ca. 30-600.
Should we mint a concept for ( $x, $y)
And should we mint a concept for ( $x, $y, $z) each time they appear or under some circumstance? They seem redundant.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-10194179__;Iw!!K-Hz7m0Vt54!mvV-EUEbYYLZbUS19KLazlsc2oCl2xGyjSOjH3QmE_fFBEEKEJtSn6PcRiQLrKKj4te4Aox4sJeqvXgzpIJp_Mk$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB2FQS7VAQTCUEHOSA3ZO7SQFAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJZGQYTOOI__;!!K-Hz7m0Vt54!mvV-EUEbYYLZbUS19KLazlsc2oCl2xGyjSOjH3QmE_fFBEEKEJtSn6PcRiQLrKKj4te4Aox4sJeqvXgzHabUxO8$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I found those records in OCLC and deleted the ISNIs from those subjects. I also did the same with the French headings that had multiple $0s for the parts of the heading. I’ve told OCLC that they shouldn’t be doing that and should follow guidelines that say a $0 or $1 must refer to the entire subject string.
Adam
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
Box 352900
Seattle, WA 98195-2900
aschiff @ uw.edu
…________________________________
From: GordonDunsire ***@***.***>
Sent: Friday, August 16, 2024 4:56:43 AM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
@cspayne<https://urldefense.com/v3/__https://github.com/cspayne__;!!K-Hz7m0Vt54!koEzqEN1NOcc4LOF0cQAlgRfSEdoJmWnHWS_7JRY_RUtakNXxT4pxxssEZXs6kujIghBRfxfufN8oq92N5U_knU$>, @pennylenger<https://urldefense.com/v3/__https://github.com/pennylenger__;!!K-Hz7m0Vt54!koEzqEN1NOcc4LOF0cQAlgRfSEdoJmWnHWS_7JRY_RUtakNXxT4pxxssEZXs6kujIghBRfxfufN8oq92tIWQ0Wk$>: The ISNI examples in @tmqdeborah<https://urldefense.com/v3/__https://github.com/tmqdeborah__;!!K-Hz7m0Vt54!koEzqEN1NOcc4LOF0cQAlgRfSEdoJmWnHWS_7JRY_RUtakNXxT4pxxssEZXs6kujIghBRfxfufN8oq926aMa-dw$>'s list above have a subfield $1 which does not cover the whole subject heading (which has vxyz qualifiers), so they are technically 'bad' data, and it would be wrong to attach the heading as an access point or preferred term. Conversely, some of the LoC examples have a subfield $0 which does cover the whole subject heading. This is extremely messy :-(
We are treating a name + work + qualifiers, or a work + qualifiers, as a skos concept, so AP/AAP is not relevant; instead, we use skos:prefLabel. We have already decided to ignore subfield 1 in this case, and we need to establish the semantic validity of subfield $0 by source, as we have recently discussed; the default is to mint a skos concept with preferred label.
If we have no qualifier subfields, then AP/AAP is relevant, and it is useful to add the RDA AAP statement to the subfield $1 IRI as subject, with the value as a string object, no nomen, because we already 'know' the source from the IRI.
So I think the transform should only use the subfield $1 IRI when there are no qualifier subfields $v, $x, $y, or $z, and add the RDA AAP statement to that IRI. In all other cases, it seems better for the transform to mint agent, work, place, timespan, and concept IRIs which can be reconciled (using sameAs, etc.) as a post-transform process which is likely to require significant human intermediation.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-10358135__;Iw!!K-Hz7m0Vt54!koEzqEN1NOcc4LOF0cQAlgRfSEdoJmWnHWS_7JRY_RUtakNXxT4pxxssEZXs6kujIghBRfxfufN8oq92AvSyXco$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB3XKARY5VCMX5XETQDZRXSHXAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZVHAYTGNI__;!!K-Hz7m0Vt54!koEzqEN1NOcc4LOF0cQAlgRfSEdoJmWnHWS_7JRY_RUtakNXxT4pxxssEZXs6kujIghBRfxfufN8oq92gSDujvY$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
For subject heading fields that describe an entity (600, 610, 611, 630, 648, 651, 662), when ind2 = 4 and so the source is not specified, have we decided to: or b. Mint an IRI for the entity but use a nomen string as the access point i.e.
I pulled these examples from the subject headings document, which appears to indicate different approaches for different fields. Is this purposeful, or should we decide on a uniform approach for when ind2 = 4? |
Beta Was this translation helpful? Give feedback.
-
We have encountered a problem with automatic de-duplication when an ending period is added to the subject heading in a MARC record. For example: If we want to still attempt some automatic de-duplication instead of minting opaque IRIs for every single concept and entity, we have two options that I can see:
|
Beta Was this translation helpful? Give feedback.
-
There are plenty of cases where adding a period in would be incorrect. Many people use "Jr" in their names without a period. Many organizations use "Inc" without a period. Adding periods back in would be incorrect for these entities.
Adam
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
(206) 543-8409
***@***.***
…________________________________
From: GordonDunsire ***@***.***>
Sent: Wednesday, September 11, 2024 2:56 AM
To: uwlib-cams/MARC2RDA ***@***.***>
Cc: Adam L Schiff ***@***.***>; Mention ***@***.***>
Subject: Re: [uwlib-cams/MARC2RDA] Subject Heading (Discussion #447)
@tmqdeborah<https://urldefense.com/v3/__https://github.com/tmqdeborah__;!!K-Hz7m0Vt54!jilFRnwTe_m1ii64CQ6wJx16EgSXoA1Dp1TNZJZXNOMdos2RMnV2sGegYWlPmPEYWVlRo0vBT82RizQ3fdVP21w$>: That's what we are doing; the above example from @cspayne<https://urldefense.com/v3/__https://github.com/cspayne__;!!K-Hz7m0Vt54!jilFRnwTe_m1ii64CQ6wJx16EgSXoA1Dp1TNZJZXNOMdos2RMnV2sGegYWlPmPEYWVlRo0vBT82RizQ3w207O6A$> shows this. The problem is that we are not removing end-stop punctuation from the nomen string. We are retaining embedded punctuation in the nomen string, and making the big assumption that this does not vary depending on the subfield encoding. In the example, 'United States' with a period is not the last element of the heading, and 'United States.' with a period is the last element. The problem exists because we are trying to extract place (and other entity) nomens from main headings and auxiliary qualifiers; for example from tag 651 (main heading) and from tags 600, 610, and 611 subfield $x (auxiliary).
@cspayne<https://urldefense.com/v3/__https://github.com/cspayne__;!!K-Hz7m0Vt54!jilFRnwTe_m1ii64CQ6wJx16EgSXoA1Dp1TNZJZXNOMdos2RMnV2sGegYWlPmPEYWVlRo0vBT82RizQ3w207O6A$>: Your option 2 is better if it is flipped: post-process the nomen strings against the 'abbreviation that should have a period' table and add the period if a match is made against the last characters of the string. For example, if the last four characters of the transformed string are ' Inc', add the period. For acronyms, just test that the second last character is a period; for example, 'U.S.A' requires a period to be added to give 'U.S.A.', but 'medusa' does not.
Note that, strictly strictly speaking, we should mint the nomen IRI based on the nomen string with all punctuation retained (but spaces removed). This would significantly lower the de-duplication rate, but would avoid any risk in the 'big assumption'. I think we can take the risk and completely remove the punctuation and spaces in the IRI, but that does not resolve the end-stop/period problem. So I retain my vote for option 2 to remove ending periods in access points.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/MARC2RDA/discussions/447*discussioncomment-10612407__;Iw!!K-Hz7m0Vt54!jilFRnwTe_m1ii64CQ6wJx16EgSXoA1Dp1TNZJZXNOMdos2RMnV2sGegYWlPmPEYWVlRo0vBT82RizQ3sjJP4eM$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVBY73P2TIH45WXBIBRLZWAHTPAVCNFSM6AAAAABGGNQF4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRRGI2DANY__;!!K-Hz7m0Vt54!jilFRnwTe_m1ii64CQ6wJx16EgSXoA1Dp1TNZJZXNOMdos2RMnV2sGegYWlPmPEYWVlRo0vBT82RizQ3iYdyloQ$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi @lake44me @GordonDunsire @AdamSchiff @pennylenger @CECSpecialistI @tmqdeborah @corialanus @JianPLee @cspayne I have pull out questions in the subject documents for discussion. @szapoun Sofia, could you also put your questions in this discussion?
1, Question: Does LCSH make a formal distinction between Work and Expression in subject access points?
2, skos:inScheme & has scheme of nomen Do we need both?
has date of work or has date of representative expression (P10398)?
Work (exists(630; 600, 610, 611 $t))
rdawo:P10261 . // has subject work
rdawo:P50311 . // has authorized access point for work; if resentative expression
rdawd:P10221 ”stripEndStop($r)” . // has key of representative expression
rdawo:P10256 <tConcept(field)> . // has subject
<tConcept(field)> skos:prefLabel “stripEndStop($x, $y, $z)” .
<tConcept(field)> skos:inScheme <tScheme(field)> .ind2=4 (no source), then use datatype property and nomen string
rdand:P80068 “stripEndStop(concatenateOA($a, $b, $c, $d, $f, $h, $j, $k, $l, $m, $n, $o, $p, $q, $r, $s, $t, $u))” . // has nomen string; OA = in order of appearance
rdano:P80069 <tScheme(field)> . // has scheme of nomen; no statement if ind2=4
rdawd:P10088 “stripEndPunctuation($t + $n + $p)” . // has title of work
rdawd:P10219 “stripEndStop($f)” . // has date of work (or has date of representative expression (P10398)?
rdawd:P10220 “stripEndStop($m)” . // has medium of performance of musical content of rep
3, 600 30 $aClark family $v Fiction
Map subfield $v to rdaw:P10004 'has category of work' as a skos:concept taken from LCSH. (agreed?)
4, We need to check LCSH rules for the Bible and versions to determine the intended work/expression boundary.
630 00 $a Bible. $p Old Testament. $l Greek $x Versions $x Septuagint.
=>
rdawo:P10256 <ConceptLCSH(Bible.OldTestament.GreekVersionsSeptuagint)> . // has subject; complete heading
<ConceptLCSH(Bible.OldTestament.GreekVersionsSeptuagint)> skos:prefLabel “Bible. Old Testament. Greek – Versions – Septuagint” .
<ConceptLCSH(Bible.OldTestament.GreekVersionsSeptuagint)> skos:inScheme http://id.loc.gov/vocabulary/subjectSchemes/lcsh . // has scheme of nomen
rdaao:P10257 . // has subject work
rdaao:P50311 . // has authorized access point for work
rdand:P80068 “Bible. Old Testament. Greek” . // has nomen string
rdano:P80069 http://id.loc.gov/vocabulary/subjectSchemes/lcsh . // has scheme of nomen
rdawd:P10256 “ConceptLCSH(VersionsSeptuagint)”. // has subject
<ConceptLCSH(VersionsSeptuagint)> skos:prefLabel “Versions – Septuagint” . // based on standard punctuation for LCSH SES.
<ConceptLCSH(VersionsSeptuagint)> skos:inScheme http://id.loc.gov/vocabulary/subjectSchemes/lcsh .
End
5, Example 60
630 00$aBuffy, the vampire slayer (Television program)
=>
rdawo:P10257 . // has subject work
rdawo:P10331 . // has authorized access point for work
rdand:P80068 “Buffy, the vampire slayer (Television program)” . // has nomen string
rdano:P80069 http://id.loc.gov/vocabulary/subjectSchemes/lcsh . // has scheme of nomen
End
Decisions based on previous meetings
Beta Was this translation helpful? Give feedback.
All reactions