[Archivesspace_Users_Group] Enumerations Findings

Carlos Lemus carlos.lemus at unlv.edu
Wed Feb 15 14:08:52 EST 2017


Hello,

At UNLV Special Collections, we've been working on cleaning up our
enumeration values because in many cases there were duplicates caused by
imports (i.e value: linear_feet vs value: Linear feet vs Linear Feet). We
wanted to stick as close as possible to ArchivesSpace standards and decided
to make our enumeration values all lowercase seperated by an underscore and
then merge any records with incorrect enumerations into that correct value
(i.e value: linear Feet into linear_feet). We also have some custom
enumerations such as: value: oversized_box, translation: Oversized Box;
digital_file; Digital File

After we had that set up correctly, we had some findings and was wondering
if anyone has experienced the same things or had a standard we could use.

1. When generating PDFs and EADs the enumeration values that were custom
(such as the oversized_box) would come out as machine readable
oversized_box instead of using our local en.yml value (located in the local
plugin).
     This was something I found in the EAD serializer (
https://github.com/archivesspace/archivesspace/blob/master/backend/app/exporters/serializers/ead.rb#L490)
and
was able to create a temporary solution of generating it , but required
altering the enumeration instead of referencing our file. I thought i'd
point it out because anyone creating custom enumerations even with a
translation in an en.yml  file would not see their change reflected in the
EAD export. (I've attached an image reflecting this) Anyone experience this?

2. Another example of this case was in the container "type" attribute.
Before something like Oversized Box would be export to EAD as is because
that was it's value in the enumeration. After we changed the value
correctly to oversized_box, it would export to the EAD container "type" as
is and translate to the PDF as well. With some XSLT manipulation I was able
to get it to show up as oversized box (shown in attachments). I've looked
through https://www.loc.gov/ead/tglib/elements/container.html and cannot
find an example of a two+ attribute value.

Should attributes be machine readable (i.e oversized_box), human readable
(Oversized Box), or does it even matter? Of course, exporting it as
Oversized Box would be easiest to translate a user friendly version to the
user.

Excuse me for the lengthy post, I'm trying to be thorough with my
explenation, but please let me know if you've come accross something
similar or have a finite solution.

Carlos Lemus
Application Programmer, Special Collections Technical Services
University Libraries, University of Nevada, Las Vegas

*How often have I said to you that when you have eliminated the impossible,
whatever remains, however improbable, must be the truth? - Sherlock Holmes*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170215/91ff6f36/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enumeration_ead.PNG
Type: image/png
Size: 35440 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170215/91ff6f36/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: containers_enum.PNG
Type: image/png
Size: 21847 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170215/91ff6f36/attachment-0001.png>


More information about the Archivesspace_Users_Group mailing list