[Archivesspace_Users_Group] Different subjects with identical labels

Wed Jul 5 21:47:17 EDT 2017

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

[cid:8FF6B995-F62C-4098-952C-754E9476D30C at zyxel.com]

[cid:FFE8CF28-CD1F-4EEF-8DF7-36CD963C387B at zyxel.com]

On Jul 5, 2017, at 1:32 PM, Olivia S Solis <livsolis at utexas.edu<mailto: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
<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<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170706/dd276c41/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paris.edit.png
Type: image/png
Size: 328325 bytes
Desc: paris.edit.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170706/dd276c41/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2paris.png
Type: image/png
Size: 540583 bytes
Desc: 2paris.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170706/dd276c41/attachment-0003.png>