[Archivesspace_Users_Group] Different subjects with identical labels

Thu Jul 6 09:36:55 EDT 2017

Hi Steven,
Thank you for the fix! Yes, this would seem to be how I need to migrate the
terms, solving all my problems above.
Much obliged!
Olivia

On Wed, Jul 5, 2017 at 8:47 PM, Majewski, Steven Dennis (sdm7g) <
sdm7g at eservices.virginia.edu> wrote:

> I think you need to use Texas or France as subdivisions of the subject.
> The scope note is just a note/comment for documentation, and doesn’t
> distinguish the two subjects as being different. If you encode it like
> this, it will allow both “Paris — France” and “Paris — Texas” . Will this
> work for you ?   — Steve Majewski / UVA
>
>
>
>
>
>
>
>
>
> On Jul 5, 2017, at 1:32 PM, Olivia S Solis <livsolis at utexas.edu> wrote:
>
> Hello all,
>
> I am not sure how many ASpace users out there share the most recent issue
> I have encountered migrating data to ArchivesSpace. For a number of
> reasons, the Briscoe Center has decided to go with GeoNames as our
> canonical controlled vocabulary for subject/geographical terms.  This is a
> recent adoption and much of the legacy EAD we use goes with Library of
> Congress Geographic terms, which we are mapping to GeoNames. We are using
> Islandora for our digital repository for item-level description. i.e. We're
> using the MODS hierarchicalGeographic
> <https://www.loc.gov/standards/mods/userguide/subject.html#hierarchicalgeographic>
>  element, which works well with GeoNames because GeoNames also uses a
> hierarchical system to classify its terms. So for individual MODS records
> for digital objects you can do something like city: "Paris", country:
> "France" for one record vs city: "Paris", state: "Texas" in another. There
> would be two instances of "Paris" in our cities taxonomies, distinguished
> from each other by their broader terms and associated URIs. There is no
> disambiguating information in the labels themselves. The difference between
> the cities in records is given by the broader state or country elements
> plus URIs.
>
> That works great for item-level description, but causes a number of
> problems for collection level description in ArchivesSpace.
>
>    1. It appears that ArchivesSpace won't let me create a subject of the
>    same type (e.g. Geographic) from the same source (e.g. GeoNames) that has a
>    label identical to another term classified with the same type/source.
>    2. Just for the sake of experimentation in our ASpace sandbox, I
>    identified one of my "Paris" records as a cultural context term. It was
>    difficult to know the difference between the two when I tried to apply the
>    subject to a resource record. The autocomplete feature did not include any
>    disambiguating information (e.g. from the Scope field or the identifier
>    field in the subject records). The browser headers in the "Browse" subjects
>    link don't include the Scope note either.
>    3. Even if I could create two GeoNames geographical subjects with the
>    label "Paris", I'm not sure how to communicate to the ASpace end user the
>    difference between the cities when they are applied to records. I can add
>    notes in the "Scope" field for each subject record -- "France" and "Texas"
>    -- to communicate the info, but the scope field for the terms doesn't
>    appear in e.g. a resource record's linked subject.
>    4. Even if we apply the correct label, the human-readable
>    disambiguating information ("Texas" vs. "France") won't export to our EAD
>    and our end users might get confused about which Paris we mean, especially
>    if there happens to be a collection with both the Paris in Texas and the
>    Paris in France. In such a case would we include the two different "Paris"
>    subjects plus "France" and "Texas"? Again, this illustrates a difference in
>    item vs. collection-level description. We publish our EAD via a consortial
>    regional portal hosted by the University of Texas, TARO, which is how
>    researchers view our finding aids online. It's possible we'll open up the
>    public interface, but we're not there yet.
>
> Has anyone else encountered these problems? I'm sure there is a
> solution/numerous possible solutions to the problems above, though it might
> mean altering the GeoNames label in ArchivesSpace to include the
> disambiguating information. Not exactly kosher if we say we're using
> GeoNames terms, but we might have to. We want to use the same controlled
> vocabulary terms regardless of system for global consistency, ease of
> maintenance etc. I can imagine a kind of customization where our EAD
> exporter could grab, e.g. the "Scope" field with the broader term's label
> and append it to the label for, in this example "Paris", surrounded by
> parentheses. But that presumes we can enter two different
> GeoNames/geographical terms "Paris".
>
> See screen shots with fake data. FYI, we are on ASpace version 1.5.3.
>
> Thanks, and hopefully I'm not the only one with this problem!
>
> -Olivia
>
> --
> Olivia Solis, MSIS
> Metadata Coordinator
> Dolph Briscoe Center for American History
> The University of Texas at Austin
> 2300 Red River St. Stop D1100
> Austin TX, 78712-1426
> (512) 232-8013 <(512)%20232-8013>
> <Screen Shot 2017-07-05 at 11.35.49 AM.png><Screen Shot 2017-07-05 at
> 11.32.47 AM.png><Screen Shot 2017-07-05 at 11.42.54 AM.png><Screen Shot
> 2017-07-05 at 11.42.37 AM.png>_______________________
> ________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>

-- 
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170706/27c7ccc8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paris.edit.png
Type: image/png
Size: 328325 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170706/27c7ccc8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2paris.png
Type: image/png
Size: 540583 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170706/27c7ccc8/attachment-0003.png>