Print

Print


Thanks Stephen!  Agreed that sh 99001269 should have been used for the 
Maps genre subelement.
We will also revisit the other issue (change of the original LCSH 
string) raised by these two examples.

Best,
Melanie

On 5/1/2017 11:00 AM, Stephen Hearn wrote:
> I see possible problems with examples 2b and 2d. Both of these show 
> elements of LCSH headings being authorized by non-LCSH vocabularies. 
> Example 2d explicitly codes <subject authority="lcsh" .... for the 
> whole subject element.
>
> In Example 2b, the indirect place subdivision "--Mississippi--Tippah 
> County" is replaced by separate geographic elements from NAF 
> "Mississippi" and "Tippah County (Miss.)". This changes the text of 
> the original LCSH string. It also introduces "Mississippi" as a direct 
> descriptor for the resource, which arguably it was not when used as a 
> lead-in term for the county name. The NAF authority includes a 781 
> field giving the form used for indirect subdivision. Could there be a 
> way to reference not just the NAF authority, but also the 781 field? 
> Both the 151 and the 781 contain strings authorized for use in access 
> points.
>
> In both examples, authorizing "Maps" with the LCGFT authority seems 
> questionable when LCSH subdivision authority "185 $v Maps" (sh 
> 99001269) could have been used. The scope of the two terms is 
> different--the LCSH subdivision "Maps" has see references from 
> geographic atlases, while the LCGFT term "Maps" has a broader/narrower 
> term relationship to Atlases. If the LCSH string is describing an 
> atlas, then the LCGFT term is not assigned as specifically as it 
> should be.
>
> The mix of authorities used to authorize elements of the original LCSH 
> string suggests an intent to deconstruct the string into standalone 
> elements. Unless there's an intent to preserve the original form and 
> meaning of the LCSH string, it might be better to treat these 
> encodings as deconstructions which are still <subject> but no longer 
> <subject authority-"lcsh">.
>
> Stephen
>
> On Sun, Apr 30, 2017 at 12:32 PM, Melanie Wacker <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     Dear MODS Implementers,
>     the MODS EC has received requests for clarification/updates to the
>     MODS best practices and examples for MODS <subject>, particularly
>     with regard to valueURI encoding.
>     The MODS EC has revisited the examples and proposes to replace the
>     existing examples at
>     https://www.loc.gov/standards/mods/userguide/subject.html
>     <https://www.loc.gov/standards/mods/userguide/subject.html>
>     with the ones listed here:
>     http://www.loc.gov/standards/mods/v3/mods-3-7-subject-examples.pdf
>     <http://www.loc.gov/standards/mods/v3/mods-3-7-subject-examples.pdf>
>
>     Please let us know if you have any comments, concerns or suggestions.
>
>     Best regards,
>     Melanie Wacker
>     on behalf of the MODS Editorial Committee
>
>     Melanie Wacker
>     Metadata Coordinator
>     Original and Special Materials Cataloging
>     Columbia University Libraries
>     New York, N.Y.
>     (212) 854 9676 <tel:%28212%29%20854-9676>
>
>
>
>
> -- 
> Stephen Hearn, Metadata Strategist
> Data Management & Access, University Libraries
> University of Minnesota
> 160 Wilson Library
> 309 19th Avenue South
> Minneapolis, MN 55455
> Ph: 612-625-2328
> Fx: 612-625-3428
> ORCID:  0000-0002-3590-1242