Subject Heading #447
Replies: 22 comments 33 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.
-
|
Is there a downloadable version anywhere? |
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.
-
If there are only name and title part subfields and subfield $0/$1, can we say has subject work < external IRI>, and the RDA aap element, and the name and title part as a string, no nomen? |
Beta Was this translation helpful? Give feedback.
-
|
@cspayne, @pennylenger: The ISNI examples in @tmqdeborah'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. |
Beta Was this translation helpful? Give feedback.
-
|
I think we have agreed to assume that $0 and $1 refer to the whole subject heading, as that is the correct way to use the subfields. I would suggest that we use subfield $1 IRI for the entire subject heading when there are qualifier subfields. In this case we would still mint agent, work, place, timespan IRIs, but we would not need to mint a concept for the entire subject heading. |
Beta Was this translation helpful? Give feedback.
-
|
@cspayne: I agree with your suggestion. We can review some real data when this part of the transform is developed and applied to some test records. |
Beta Was this translation helpful? Give feedback.
-
|
@pennylenger tagging you here as it is relevant to the 6XX mappings! |
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.
-
|
Assigning a URI in $0 or $1, or a system number in $0, for only part of a subject heading with multiple subfields SHOULD be a NO-NO but... I think we would need to verify the process OCLC uses to assign WorldCat Entities to subject fields. FAST headings ($2 fast) are broken-down LCSH and are supposed to be granular at the "facet" level, but may have a subfield - I think just for 650 $a $x for topical subjects that have a subdivision. I think we can rely on a FAST URI (or authority ID in $0) to identify the entire subject. The examples you have given only have $a. Have you encountered any FAST headings with multiple subfields (650's with $a and $x probably) that have WorldCat Entities assigned, and if so, do the Entities cover the entire subject, or only $a? The MARC editing process in Connexion enabled validation of LC subfielded subjects at a fragment level, if no match for the entire heading was found. I'm not sure if this is still case. But that was internal to OCLC's interface, those connections weren't exported. I'm not aware of other institutions or other record sources that are doing this or something similar now, but... ...Ex Libris, in its "enrichment" of MARC records with $0 an $1 subfields, was doing it at one time and the IGELU-ELUNA Linked Open Data Working Group went to considerable trouble to eventually convince Ex Libris not to do it. (This enrichment only affected MARC records as they were being published from Alma as a file or retrieved via API, as MARC, but I think at some point ExL were and perhaps still are planning to offer these kind of "enrichment" processes to be saved to the actual MARC records). Customers outside the working group were also complaining about this less than full identification of the entire subject. Just because little me isn't aware of the practice doesn't mean that it doesn't happen. If there's not a PCC Policy or something somewhere prohibiting it, some library may have made it a practice - with multiple $0's or $1's for subject fragments tacked on to the end of 6xx. If you see it in records, please post examples! |
Beta Was this translation helpful? Give feedback.
-
|
Penny, There should never be a URI in a 6XX field for just a portion of the LCSH string (that is PCC best practice). See https://www.loc.gov/aba/pcc/taskgroup/linked-data-best-practices-final-report.pdf, page 9: Precoordinated subject strings such as those in LCSH present special difficulties in linked data. The subject heading in its entirety is intended to represent a single unit of meaning that is not reducible to its parts. To say that the subject of a book is “Law $x Study and teaching $z Indonesia” is to say more than it is about law, study and teaching, and Indonesia: it’s about the study and teaching of law in Indonesia. But while the individual concepts are enumerated in the vocabulary, the combination (unless explicitly established) is not. There is no URI that can be given in a 6XX $0 to represent the subject as a whole. Even if MARC did have a mechanism for associating each of the component parts with its own URI, it would still not be able to represent the relation among the terms in linked data terms. That is not an incidental omission in MARC, but a reflection of the fact that linked data representations have a richness that MARC structures can only very partially capture. The PCC Task Group on URIs in MARC considered this issue at some length and arrived at the following conclusion: After careful consideration, the Task Group recommends against providing URIs that represent only partial entities of a MARC field. Faceted vocabularies provide an alternative means to represent such concepts by post-coordination. If the entire concept is to be represented as a single semantic unit within the LCSH vocabulary, in our view that becomes an issue for the maintenance agency rather than for implementers. And on page 6: URIs are not given for portions of access points. Subfields implying an object other than that specified by the field as a whole (e.g., a name within a name-title access point) should not be given a URI within the same field. While systems may be able to parse out elements of a string internally and associate them with distinct URIs, the MARC format cannot itself convey discrete associations within the same access point. Only URIs corresponding to the full access point should be communicated when MARC data is exported. In the example below, $0 must refer to the work, not to the composer. In the example below, $0 must refer to the entire subject heading string, not to one or more partial components. |
Beta Was this translation helpful? Give feedback.
-
|
Here's what I could find about Worldcat Entity URIs... |
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.
-
|
@CECSpecialistI Hi Crystal, can we add this to tomorrow's meeting Check each of the commonly-used source vocabularies that the semantics are ok and that identifier normalization has a regular pattern. |
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.
-
|
@AdamSchiff: 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. |
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.
-
|
How does OCLC define a rwo? an authority? How does this fit into the Library Linked Data Incubator Group: Datasets, Value Vocabularies, and Metadata Element Sets report at https://www.w3.org/2005/Incubator/lld/XGR-lld-vocabdataset-20111025/? Rhetorical questions: the 'authority' community has been asked this many times, but the responses have been either non-existent or incoherent :-) |
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.
-
|
For the 647 question, see below. For the x, y, z question: Yes, we should mint a concept each time they appear. This will result in a large amount of redundancy, but this is automatically de-duplicated if the loca part of the minted IRI is the normalized values of x, y, and z. This allows the work/manifestation to be retrieved by a boolean combination of the primary subject, the personal name 'Jesus Christ', with the secondary qualifier string 'History of doctrines -- Early church, ca. 30-600'. Of course, the full heading string will also be available for retrieval, but this approach also satisfied the end-user requirement for all stuff on 'History of doctrines', etc. |
Beta Was this translation helpful? Give feedback.
-
|
@GordonDunsire In your document, you have: But for example, in Is "Influence" really a subject of the work Don Quixote? Did you mean Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
@pennylenger, @cspayne: My bad, it should be 'work' in the template. All of the examples correctly use 'work', not 'workS'. Everything is a subject of the work described in the record, and there is no 'subject of subject'. Apologies for the confusion. Note that the subfields assigned to 'name' and 'title' parts of the M21 heading in the document may need to be adjusted to be consistent with subsequent decisions taken about headings in 7xx, etc. fields and to match the consistency of xx0, etc. fields in the MARC 21 manual. I have not double-checked this because @pennylenger is working on the consolidation. In most, if not all, cases the transform templates should apply to all xx0, etc. fields; the main difference for the transform is the selection of the RDA relationship element that depends on the field and its indicator values. |
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.
-
|
OK, I have changed example 66, 647 output to be just a subject heading from FAST; that is, as a skos:Concept. This is the approach we can take if we decide not to normalize the subfield $0 URI and mint our own. Note that example 66 also includes the corresponding 648 field. |
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.
-
|
@cspayne: The document uses option a) only for field 648; and other fields use option b). Reviewing 648, I can't see a reason for the differentiation, so I think it's a typo. The uniform approach for when ind2 = 4 is b) (corrected): |
Beta Was this translation helpful? Give feedback.
-
|
If ind2=4 (no source), shouldn't we use AP and no nomen? |
Beta Was this translation helpful? Give feedback.
-
|
@pennylenger" Yes, that's my bad. |
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.
-
|
I thought that we were going to remove all punctuation (as well as spacing) when minting any IRI based on an authorized access point. |
Beta Was this translation helpful? Give feedback.
-
|
@tmqdeborah: That's what we are doing; the above example from @cspayne 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: 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. |
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 @cspayne @CECSpecialistI @szapoun we made the decision in yesterday’s meeting that for Subject headings - break out fields for FAST and not other sources. I would like to make sure my understanding is correct before updating mappings in Google Sheet. Currently, for a subject heading, the whole heading is mapped to has subject as a skos:concept
Now, according to the new decision, does it mean that there is no separate mapping for each heading field:
And for FAST, it can be mapped and transformed as normal, like has subject [concept], skos:prefLabel [fast heading], and skos:inScheme [fast]. No special action is needed. |
Beta Was this translation helpful? Give feedback.
-
|
@pennylenger: I think this was what was decided. The information embedded in the subfield codes is dropped during the transform, for all subject heading schemes except FAST. (The decision is inconsistent with the principle of retaining subfield semantics for other fields, where possible.) |
Beta Was this translation helpful? Give feedback.
-
|
@pennylenger |
Beta Was this translation helpful? Give feedback.
-
|
@CECSpecialistI @cspayne @GordonDunsire @AdamSchiff @lake44me @szapoun Based on today’s meeting, are we keeping the FAST headings as they are, without separating them? or do we separate $y as subject timespans, $z as subject places, not $x? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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