[Archivesspace_Users_Group] Different subjects with identical labels

Wed Jul 5 13:32:35 EDT 2017

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170705/f1110f12/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-07-05 at 11.35.49 AM.png
Type: image/png
Size: 100769 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170705/f1110f12/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-07-05 at 11.32.47 AM.png
Type: image/png
Size: 55472 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170705/f1110f12/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-07-05 at 11.42.54 AM.png
Type: image/png
Size: 88822 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170705/f1110f12/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-07-05 at 11.42.37 AM.png
Type: image/png
Size: 19364 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170705/f1110f12/attachment-0007.png>