From Henry.Steele at tufts.edu Wed Jan 2 11:39:27 2019 From: Henry.Steele at tufts.edu (Steele, Henry) Date: Wed, 2 Jan 2019 16:39:27 +0000 Subject: [Archivesspace_Users_Group] question about digitization work order plugin Message-ID: Good morning, Have any of you had trouble getting the digitization work order plugin to work on ASpace 2.5.1? We are eager to use this plugin, but had trouble installing it according to the directions on https://github.com/hudmol/digitization_work_order When I installed the plugin using these directions, we still did not see the work order button in the context in which it was supposed to appear. I took the additional step of initializing the plugin, but still did not see the button. I did notice after I initialized the plugin that the plugin was continually trying to render in our log files. So I uninstalled it. Has anyone been able to successfully install the Digitization Work Order plugin on ASpace 2.5.1? And has anyone else had issues with this, and be willing to share the steps they took to address the issue? Thank you Henry Steele Systems Librarian Tufts University Library Technology Services (617)627-5239 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachel.searcy at nyu.edu Wed Jan 2 11:54:35 2019 From: rachel.searcy at nyu.edu (Rachel Aileen Searcy) Date: Wed, 2 Jan 2019 11:54:35 -0500 Subject: [Archivesspace_Users_Group] question about digitization work order plugin In-Reply-To: References: Message-ID: Hello Henry, We are successfully using the Work Order plugin with v.2.5.1. I'm not sure if this will solve your issue, but we have noticed that the plugin is only an available option in the "More" button on the menubar when a resource record is in view mode and not edit. We also have some instructions of using the plugin in our local manual here . Hope this helps! Rachel On Wed, Jan 2, 2019 at 11:39 AM Steele, Henry wrote: > Good morning, > > > > Have any of you had trouble getting the digitization work order plugin to > work on ASpace 2.5.1? We are eager to use this plugin, but had trouble > installing it according to the directions on > https://github.com/hudmol/digitization_work_order > > When I installed the plugin using these directions, we still did not see > the work order button in the context in which it was supposed to appear. I > took the additional step of initializing the plugin, but still did not see > the button. I did notice after I initialized the plugin that the plugin > was continually trying to render in our log files. So I uninstalled it. > > > > Has anyone been able to successfully install the Digitization Work Order > plugin on ASpace 2.5.1? And has anyone else had issues with this, and be > willing to share the steps they took to address the issue? > > > > Thank you > > > > > > Henry Steele > > Systems Librarian > > Tufts University Library Technology Services > > (617)627-5239 > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=LUH5OUuzh27uN9_epyrWdNjJRct32BZp_0F1syFzJCg&s=YLuYmGj-1uqeFf2BUreRTOWoHmkho7NNHRSCUh29wdA&e= > -- Rachel Searcy Accessioning Archivist, Archival Collections Management New York University Libraries 212.998.2539 | rachel.searcy at nyu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From reesj at mail.nlm.nih.gov Fri Jan 4 09:59:23 2019 From: reesj at mail.nlm.nih.gov (Rees, John (NIH/NLM) [E]) Date: Fri, 4 Jan 2019 14:59:23 +0000 Subject: [Archivesspace_Users_Group] PUI question: external indexing of container list tree link text Message-ID: Hi all, I administer a finding aids aggregation service that in part scrapes HTML-source code as a data input and I am looking for some advice/start a conversation. Several of our contributing repositories with this data type moved to ArchivesSpace in 2018 and we are not able to crawl ASpace's collection_organization#tree source which seems to be the only organized view of container list data. As many of you probably know these are coded as URIs in the HTML-source and are only rendered as visible text at runtime via javascript and css in the browser. Our crawler cannot translate these HTML-source URIs into text that it can index. The only workaround we've been able to find is indexing the PDF view, but not everyone implements this feature. Additionally, our crawler sometimes times out on large PDFs as it can take ASpace a while to generate them at runtime. I'm also wondering if PUI implementers have noticed any issues with other search engines having difficulty indexing their PUI content at a full-document level? I searched the Jira backlog and PUI Enhancements wikispace and did not find anything specifically addressing this use case. Thanks, John John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Fri Jan 4 11:03:37 2019 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Fri, 4 Jan 2019 16:03:37 +0000 Subject: [Archivesspace_Users_Group] PUI question: external indexing of container list tree link text In-Reply-To: References: Message-ID: I would suggest crawling the OAI endpoint for indexing, but linking to the PUI record. oai_ead metadata just EAD in an OAI wrapper, and has the complete resource tree. The problem with that is that not everyone may have configured OAI or made it public. But yes: that?s a problem with progressive web apps: all of the data you want indexed isn?t in the page. I wonder if there is a way thru google webmaster console or sitemaps to configure this sort of action, i.e. Use this other URL to index this resource. ? Steve Majewski > On Jan 4, 2019, at 9:59 AM, Rees, John (NIH/NLM) [E] wrote: > > Hi all, > > I administer a finding aids aggregation service that in part scrapes HTML-source code as a data input and I am looking for some advice/start a conversation. > > Several of our contributing repositories with this data type moved to ArchivesSpace in 2018 and we are not able to crawl ASpace?s collection_organization#tree source which seems to be the only organized view of container list data. As many of you probably know these are coded as URIs in the HTML-source and are only rendered as visible text at runtime via javascript and css in the browser. > > Our crawler cannot translate these HTML-source URIs into text that it can index. The only workaround we?ve been able to find is indexing the PDF view, but not everyone implements this feature. Additionally, our crawler sometimes times out on large PDFs as it can take ASpace a while to generate them at runtime. > > I?m also wondering if PUI implementers have noticed any issues with other search engines having difficulty indexing their PUI content at a full-document level? > > I searched the Jira backlog and PUI Enhancements wikispace and did not find anything specifically addressing this use case. > > Thanks, > John > > > John P. Rees > Archivist and Digital Resources Manager > History of Medicine Division > National Library of Medicine > 301-827-4510 > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3598 bytes Desc: not available URL: From mark.custer at yale.edu Fri Jan 4 15:58:41 2019 From: mark.custer at yale.edu (Custer, Mark) Date: Fri, 4 Jan 2019 20:58:41 +0000 Subject: [Archivesspace_Users_Group] PUI question: external indexing of container list tree link text In-Reply-To: References: Message-ID: John, Exactly what Steve said! As an aside, one thing that I thought about (quite a while back now, I guess it was) was adding those mappings to the JSON-LD metadata that are currently only applied on Resource, Repository, and Agent pages within the PUI (if you view the source of a Resource landing page, for example, you?ll see a bit of JSON-LD at the very top). In other words, the Resource JSON-LD could have https://schema.org/hasPart statements which would include the URL of the immediate archival object children. But, that could result in a lot of extra data since sometimes folks have very, very flat hierarchies (e.g. 10,000 children archival objects all attached to 1 resource record?. yikes!). Because of that very real possibility, it might be a better mapping strategy not to use hasPart in ASpace, but instead to just add a single https://schema.org/isPartOf to each archival object page, but then I don?t think that would help your use case. We haven?t done this just yet, but I was planning to add a readme file in Github that just lists out all of the EAD files for this sort of aggregation purpose. E.g. https://github.com/YaleArchivesSpace/Archives-at-Yale-EAD3/blob/master/med-ead/README.md We?re not using the OAI endpoint right now, though, since we post-process and validate our EAD files after export. For folks who are using it, then that would be a very good way to get the data harvested. As for search engines indexing at a deep level in the PUI, I suspect that could be an issue. It would probably be best if the PUI had sitemaps out of the box. That said, we have a LOT of archival objects being indexed by Google in our instance of the PUI, but I don?t think the crawler is getting the entire finding aids (as long as they get all of the Resources, I?m happy for now). I?d expect that a sitemap would be best for ensuring that, but I?ve honestly no clue in this day and age of the Web! Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Majewski, Steven Dennis (sdm7g) Sent: Friday, 04 January, 2019 11:04 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] PUI question: external indexing of container list tree link text I would suggest crawling the OAI endpoint for indexing, but linking to the PUI record. oai_ead metadata just EAD in an OAI wrapper, and has the complete resource tree. The problem with that is that not everyone may have configured OAI or made it public. But yes: that?s a problem with progressive web apps: all of the data you want indexed isn?t in the page. I wonder if there is a way thru google webmaster console or sitemaps to configure this sort of action, i.e. Use this other URL to index this resource. ? Steve Majewski On Jan 4, 2019, at 9:59 AM, Rees, John (NIH/NLM) [E] > wrote: Hi all, I administer a finding aids aggregation service that in part scrapes HTML-source code as a data input and I am looking for some advice/start a conversation. Several of our contributing repositories with this data type moved to ArchivesSpace in 2018 and we are not able to crawl ASpace?s collection_organization#tree source which seems to be the only organized view of container list data. As many of you probably know these are coded as URIs in the HTML-source and are only rendered as visible text at runtime via javascript and css in the browser. Our crawler cannot translate these HTML-source URIs into text that it can index. The only workaround we?ve been able to find is indexing the PDF view, but not everyone implements this feature. Additionally, our crawler sometimes times out on large PDFs as it can take ASpace a while to generate them at runtime. I?m also wondering if PUI implementers have noticed any issues with other search engines having difficulty indexing their PUI content at a full-document level? I searched the Jira backlog and PUI Enhancements wikispace and did not find anything specifically addressing this use case. Thanks, John John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From harmjager at ruerddevries.nl Mon Jan 7 05:38:47 2019 From: harmjager at ruerddevries.nl (Harm Jager) Date: Mon, 7 Jan 2019 11:38:47 +0100 (CET) Subject: [Archivesspace_Users_Group] ArchLight Documentation Message-ID: <2013154053.1014695.1546857527471@webmail.strato.com> Hello fellow Archivesspace users, We are sending this mail out to you because we are currently in the process of doing research in to the best way to use the user-interface of Archivesspace. We would like to use the user-interface not only to present our finding-aids but also those of other institutions in the Netherlands that are complementary to our finding-aids and if possible provide extra information surrounding these Finding-Aids This brings me to our point. Namely the fact that we recently heard of ArchLight and someone said that would be a good fit for us and our objectives with the staff-interface. We are looking to expand our knowledge when it comes to ArcLight. Using Google to find Archlight brings us to a couple of DuraSpace pages, but that?s it. Therefore I share the following question/request. Does anyone of you have any experience with ArchLight and if so could you share with us your documentation surrounding ArchLight? We would like to know as much as possible about ArchLight before we start to fiddle around with it. Any links or documents would be greatly appreciated. Thank you very much for helping us along. Greetings, Harm Jager -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Mon Jan 7 11:59:31 2019 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 7 Jan 2019 16:59:31 +0000 Subject: [Archivesspace_Users_Group] ArchLight Documentation In-Reply-To: <2013154053.1014695.1546857527471@webmail.strato.com> References: <2013154053.1014695.1546857527471@webmail.strato.com> Message-ID: <2A9B7956-927D-48D7-A67A-BC5898880FCA@virginia.edu> ArcLight project on GitHub: https://github.com/sul-dlss/arclight ArcLight is a Ruby/Rails+Solr Gem for searching and displaying finding aids. The display is somewhat similar in style to ArchivesSpace Public User Interface, but ArcLight is only for serving published finding aids ? it has none of the authoring and management capability of the ArchivesSpace staff interface. ArcLight imports EAD finding aids and indexes the pieces in Solr for fast retrieval, so it doesn?t have to parse an entire XML finding aid on each access. If all of your finding aids are in ArchivesSpace, there is not much to be gained from ArcLight over the ArchivesSpace PUI. However, if you?ve got legacy EAD finding aids that you cannot yet import into ArchivesSpace, or you are trying to build a union catalog with other institutions, then exporting EAD from different systems is probably the only common denominator. We are currently using XTF https://xtf.cdlib.org , https://github.com/cdlib/xtf.git for displaying EAD finding aids online, however that technology stack has gotten a little long in the tooth, so we?ve been evaluating ArcLight as a replacement. My evaluation was based on the initial MVP release, which was a while ago, so they may have fixed some of the issues since then. The main issue I ran into was that ArcLight, like ArchivesSpace, had some restrictions and limitation on the EAD that it would import, particularly on the values. I made an attempt to override and fix this, but it was not completely successful, so I had to resort to preprocessing the EAD to transform it to ArcLight?s restrictions. ( ArcLight uses eadid value to link all of the sub records together in Solr index, so fixing this issue was less trivial than making some other mods to the application or EAD import process. I will likely make another attempt to dig deeper into this problem when I have the time. ) Several Virginia Heritage http://vaheritage.org members are also ArchivesSpace members and we have been testing using the ArchivesSpace OAI endpoints as a feed into our current XTF implementation, and if we do migrate to ArcLight, we will use the same method to feed updates. ( https://github.com/bloomonkey/oai-harvest.git ) I had initially thought there might be some way to manage the entire union catalog in ArchivesSpace, but my experience with managing an ArchivesSpace instance with 4 different library repositories convinced me that trying to do the same for a much larger group would not be practical. There might be other ways to build a searchable union catalog of ArchivesSpace instances ( merging Solr records, for example ) however they would all require access to ArchivesSpace backend or Solr service, which are both likely to be restricted or firewalled. ? Steve Majewski > On Jan 7, 2019, at 5:38 AM, Harm Jager wrote: > > Hello fellow Archivesspace users, > > We are sending this mail out to you because we are currently in the process of doing research in to the best way to use the user-interface of Archivesspace. We would like to use the user-interface not only to present our finding-aids but also those of other institutions in the Netherlands that are complementary to our finding-aids and if possible provide extra information surrounding these Finding-Aids > > This brings me to our point. Namely the fact that we recently heard of ArchLight and someone said that would be a good fit for us and our objectives with the staff-interface. We are looking to expand our knowledge when it comes to ArcLight. Using Google to find Archlight brings us to a couple of DuraSpace pages, but that?s it. > > Therefore I share the following question/request. Does anyone of you have any experience with ArchLight and if so could you share with us your documentation surrounding ArchLight? We would like to know as much as possible about ArchLight before we start to fiddle around with it. Any links or documents would be greatly appreciated. > > Thank you very much for helping us along. > > Greetings, > > Harm Jager > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3598 bytes Desc: not available URL: From reesj at mail.nlm.nih.gov Mon Jan 7 12:20:45 2019 From: reesj at mail.nlm.nih.gov (Rees, John (NIH/NLM) [E]) Date: Mon, 7 Jan 2019 17:20:45 +0000 Subject: [Archivesspace_Users_Group] PUI question: external indexing of container list tree link text In-Reply-To: References: Message-ID: We have several ASpace users (and others) that provide EADs for harvesting outside their user interfaces, but those take effort/capacity, desire to collaborate, and supervision/management that not everyone can muster. I am hoping for an unsupervised option that would be a native ASpace default configuration. I had looked at the jsonld and tree-builder javascript hoping for some sort of hook but I reckon the base-functionality just isn?t in the stack. Like you say, I?ve found lots of atomic resources in various PUI instances via Google, but not a whole document ? Google-magic must be stronger than that of the commercial engine we use as a crawler. I doubt I could muster support for a workaround on our end. Any idea how difficult it might be to add something like a title attribute to those URIs? John From: Custer, Mark Sent: Friday, January 04, 2019 3:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] PUI question: external indexing of container list tree link text John, Exactly what Steve said! As an aside, one thing that I thought about (quite a while back now, I guess it was) was adding those mappings to the JSON-LD metadata that are currently only applied on Resource, Repository, and Agent pages within the PUI (if you view the source of a Resource landing page, for example, you?ll see a bit of JSON-LD at the very top). In other words, the Resource JSON-LD could have https://schema.org/hasPart statements which would include the URL of the immediate archival object children. But, that could result in a lot of extra data since sometimes folks have very, very flat hierarchies (e.g. 10,000 children archival objects all attached to 1 resource record?. yikes!). Because of that very real possibility, it might be a better mapping strategy not to use hasPart in ASpace, but instead to just add a single https://schema.org/isPartOf to each archival object page, but then I don?t think that would help your use case. We haven?t done this just yet, but I was planning to add a readme file in Github that just lists out all of the EAD files for this sort of aggregation purpose. E.g. https://github.com/YaleArchivesSpace/Archives-at-Yale-EAD3/blob/master/med-ead/README.md We?re not using the OAI endpoint right now, though, since we post-process and validate our EAD files after export. For folks who are using it, then that would be a very good way to get the data harvested. As for search engines indexing at a deep level in the PUI, I suspect that could be an issue. It would probably be best if the PUI had sitemaps out of the box. That said, we have a LOT of archival objects being indexed by Google in our instance of the PUI, but I don?t think the crawler is getting the entire finding aids (as long as they get all of the Resources, I?m happy for now). I?d expect that a sitemap would be best for ensuring that, but I?ve honestly no clue in this day and age of the Web! Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Majewski, Steven Dennis (sdm7g) Sent: Friday, 04 January, 2019 11:04 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] PUI question: external indexing of container list tree link text I would suggest crawling the OAI endpoint for indexing, but linking to the PUI record. oai_ead metadata just EAD in an OAI wrapper, and has the complete resource tree. The problem with that is that not everyone may have configured OAI or made it public. But yes: that?s a problem with progressive web apps: all of the data you want indexed isn?t in the page. I wonder if there is a way thru google webmaster console or sitemaps to configure this sort of action, i.e. Use this other URL to index this resource. ? Steve Majewski On Jan 4, 2019, at 9:59 AM, Rees, John (NIH/NLM) [E] > wrote: Hi all, I administer a finding aids aggregation service that in part scrapes HTML-source code as a data input and I am looking for some advice/start a conversation. Several of our contributing repositories with this data type moved to ArchivesSpace in 2018 and we are not able to crawl ASpace?s collection_organization#tree source which seems to be the only organized view of container list data. As many of you probably know these are coded as URIs in the HTML-source and are only rendered as visible text at runtime via javascript and css in the browser. Our crawler cannot translate these HTML-source URIs into text that it can index. The only workaround we?ve been able to find is indexing the PDF view, but not everyone implements this feature. Additionally, our crawler sometimes times out on large PDFs as it can take ASpace a while to generate them at runtime. I?m also wondering if PUI implementers have noticed any issues with other search engines having difficulty indexing their PUI content at a full-document level? I searched the Jira backlog and PUI Enhancements wikispace and did not find anything specifically addressing this use case. Thanks, John John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfay at athenslibrary.org Mon Jan 7 12:20:23 2019 From: rfay at athenslibrary.org (Robin Fay) Date: Mon, 7 Jan 2019 12:20:23 -0500 Subject: [Archivesspace_Users_Group] ArchLight Documentation In-Reply-To: <2013154053.1014695.1546857527471@webmail.strato.com> References: <2013154053.1014695.1546857527471@webmail.strato.com> Message-ID: I am very interested in learning more about Archlight. Although I am new to ArchivesSpace dev, I have considerable CMS and IR/digital lib dev experience (and crosswalking/harvesting metadata even with ASpace). The ArchivesSpace interface is on my list to address as part of my larger site redesign goals. Thanks, Robin Fay @georgiawebgurl Digital Media Librarian/Web (re)Designer Athens Regional Library System On Mon, Jan 7, 2019 at 5:38 AM Harm Jager wrote: > Hello fellow Archivesspace users, > > We are sending this mail out to you because we are currently in the > process of doing research in to the best way to use the user-interface of > Archivesspace. We would like to use the user-interface not only to present > our finding-aids but also those of other institutions in the Netherlands > that are complementary to our finding-aids and if possible provide extra > information surrounding these Finding-Aids > > This brings me to our point. Namely the fact that we recently heard of > ArchLight and someone said that would be a good fit for us and our > objectives with the staff-interface. We are looking to expand our knowledge > when it comes to ArcLight. Using Google to find Archlight brings us to a > couple of DuraSpace pages, but that?s it. > > Therefore I share the following question/request. Does anyone of you have > any experience with ArchLight and if so could you share with us your > documentation surrounding ArchLight? We would like to know as much as > possible about ArchLight before we start to fiddle around with it. Any > links or documents would be greatly appreciated. > > Thank you very much for helping us along. > > Greetings, > > Harm Jager > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CurbowJ at bvu.edu Mon Jan 7 15:40:34 2019 From: CurbowJ at bvu.edu (Joan Curbow) Date: Mon, 7 Jan 2019 20:40:34 +0000 Subject: [Archivesspace_Users_Group] ArchLight Documentation In-Reply-To: <2013154053.1014695.1546857527471@webmail.strato.com> References: <2013154053.1014695.1546857527471@webmail.strato.com> Message-ID: Would it make sense to make a bibliographic record in OCLC with a link to your finding aids? I know this means yet another step, i.e. massaging the data to make a bib record, but I?ve done it, and it?s not THAT onerous. Personally, I am very grateful to those institutions who have seen fit to put their archival collections into OCLC WorldCat/First Search, but I suppose I can see reasons not to go to this trouble, too. The non-library world may not access WorldCat to any degree, so collections may not be quite as discoverable. Just a thought. Sincerely, Joan Curbow Reference Librarian and Archivist Buena Vista University Library Buena Vista University 610 West Fourth Street Storm Lake, Iowa 50588 712-749-2094 curbowj at bvu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Harm Jager Sent: Monday, January 7, 2019 4:39 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] ArchLight Documentation CAUTION: This email originated from outside of BVU. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello fellow Archivesspace users, We are sending this mail out to you because we are currently in the process of doing research in to the best way to use the user-interface of Archivesspace. We would like to use the user-interface not only to present our finding-aids but also those of other institutions in the Netherlands that are complementary to our finding-aids and if possible provide extra information surrounding these Finding-Aids This brings me to our point. Namely the fact that we recently heard of ArchLight and someone said that would be a good fit for us and our objectives with the staff-interface. We are looking to expand our knowledge when it comes to ArcLight. Using Google to find Archlight brings us to a couple of DuraSpace pages, but that?s it. Therefore I share the following question/request. Does anyone of you have any experience with ArchLight and if so could you share with us your documentation surrounding ArchLight? We would like to know as much as possible about ArchLight before we start to fiddle around with it. Any links or documents would be greatly appreciated. Thank you very much for helping us along. Greetings, Harm Jager -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcramer at stanford.edu Mon Jan 7 16:01:14 2019 From: tcramer at stanford.edu (Tom Cramer) Date: Mon, 7 Jan 2019 21:01:14 +0000 Subject: [Archivesspace_Users_Group] ArchLight Documentation In-Reply-To: References: <2013154053.1014695.1546857527471@webmail.strato.com> Message-ID: <50079431-51A8-4090-BAD8-4BDC248FBBCB@stanford.edu> Thanks Steve for this extensive write up on ArcLight. Two other things to note: 1.) ArcLight is based on Blacklight, and as such does and should continue to benefit from cross-pollination with Blacklight?s extensive community and ongoing code developments. 2.) ArcLight is still a bit rough around the edges; I?m not aware that anyone has put into production yet, though there are multiple ?evaluation? sites live. Several of the institutions that have been active in its development up to now are tentatively planning for another work cycle on it in mid-2019. At Stanford (at least) that is when we would plan to finish up development and move it into a live, production service for all our archival collections. Of course, as open source software, you could become the first to go into production! For anyone curious about ArcLight development, here are the communication channels (from the DuraSpace wiki page): Email list: To get updates or communicate with us about ArcLight, please join the ArcLight Google Group (arclight-community at googlegroups.com). Slack channel: To communicate with us more informally, please join the #arclight channel on the Code4lib Slack team. If you're not on the Code4lib Slack team, you can request an invitation using this form or by contacting us via the email list. - Tom | Tom Cramer | Associate University Librarian | Director, Digital Library Systems & Services | Chief Technology Strategist | Stanford University Libraries | tcramer at stanford.edu On Jan 7, 2019, at 9:20 AM, Robin Fay > wrote: I am very interested in learning more about Archlight. Although I am new to ArchivesSpace dev, I have considerable CMS and IR/digital lib dev experience (and crosswalking/harvesting metadata even with ASpace). The ArchivesSpace interface is on my list to address as part of my larger site redesign goals. Thanks, Robin Fay @georgiawebgurl Digital Media Librarian/Web (re)Designer Athens Regional Library System On Mon, Jan 7, 2019 at 5:38 AM Harm Jager > wrote: Hello fellow Archivesspace users, We are sending this mail out to you because we are currently in the process of doing research in to the best way to use the user-interface of Archivesspace. We would like to use the user-interface not only to present our finding-aids but also those of other institutions in the Netherlands that are complementary to our finding-aids and if possible provide extra information surrounding these Finding-Aids This brings me to our point. Namely the fact that we recently heard of ArchLight and someone said that would be a good fit for us and our objectives with the staff-interface. We are looking to expand our knowledge when it comes to ArcLight. Using Google to find Archlight brings us to a couple of DuraSpace pages, but that?s it. Therefore I share the following question/request. Does anyone of you have any experience with ArchLight and if so could you share with us your documentation surrounding ArchLight? We would like to know as much as possible about ArchLight before we start to fiddle around with it. Any links or documents would be greatly appreciated. Thank you very much for helping us along. Greetings, Harm Jager _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhocking at litchfieldhistoricalsociety.org Tue Jan 8 13:25:35 2019 From: lhocking at litchfieldhistoricalsociety.org (Linda Hocking) Date: Tue, 8 Jan 2019 18:25:35 +0000 Subject: [Archivesspace_Users_Group] Renumbering Folders Message-ID: Does anyone know how to bulk change/update folder numbers? My apologies if this has already been addressed, but I can't seem to find an answer in the documentation. In Archon, one could renumber a group of folders by selecting them and then choosing to move the number up or down. Is there a way to do this in ArchivesSpace? In this particular case, they are entered as children of top containers. If it were possible to edit using the "Rapid Entry" mode it would still be faster than manually opening each file and changing the number in the Instances field, but I can't seem to find a way to do that either. Thanks in advance for your help! Linda Linda Hocking, CA Curator of Library & Archives Litchfield Historical Society P.O. Box 385 Litchfield, CT 06759 860-567-4501 lhocking at litchfieldhistoricalsociety.org eboardman.tumblr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From epyers at slv.vic.gov.au Tue Jan 8 17:56:39 2019 From: epyers at slv.vic.gov.au (Emily Pyers) Date: Tue, 8 Jan 2019 22:56:39 +0000 Subject: [Archivesspace_Users_Group] Alma Integration In-Reply-To: References: Message-ID: <9b219171dcca4600b3d2ae930b30ad00@STAFFEXCH01.staff.local> Hullo, State Library Victoria is very interested in this. We?re running Primo and Voyager at present, but are currently looking at potential replacements for Voyager ? unsurprisingly, Alma is a strong contender. Centralising our search is pretty crucial too ? we?ve integrated a lot of our workflows and it doesn?t make sense to our staff to have to search another interface for part of our collection ? plus, as a cultural institution, our archival collections are one of our biggest points of difference and we really want them to be front and centre for the user as well. Very interested to hear how other institutions with any integration with a discovery layer, but particularly Primo. Cheers, Emily Emily Pyers | Metadata & Archival Systems Specialist | Collection Development & Description In the office Monday, Wednesday - Friday 9.30am-3pm State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 T +61 3 8664 7368 | epyers at slv.vic.gov.au slv.vic.gov.au [http://www.slv.vic.gov.au/sites/default/files/email_signature/signature.jpg?6] [follow us] [SLV facebook] [SLV twitter] [SLV youtube] [SLV instagram] [RACV logo] From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Ryan Edwards Sent: Thursday, 1 November 2018 6:54 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Alma Integration Hello, We, here at the Getty Research Institute are also interested in ArchivesSpace/Alma/Primo integration. We have experimented a bit with the Denver plugin in our Sandbox environment. Currently, we are indexing the full-text of our EADs in Primo. We may also be interested in exploring the interplay between Alma bibliographic/holdings/items records and resource records/instances in ArchivesSpace. Thanks, Ryan Ryan Edwards Digital Access and Systems Librarian Getty Digital ? Collection Management Systems Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 reedwards at getty.edu 310.440.7398 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Hilton, Adrien Sent: Wednesday, October 31, 2018 6:45 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Alma Integration Hi All, At Houghton Library, part of the Harvard Library, we too are interested in ArchivesSpace/Alma integration. In terms of functionality for resource description, we looked a bit at the Denver plug-in and like the type of data exchange it offers between the ArchivesSpace resource record and the Alma Bib and Holdings records using the MMS ID. We could also envision the exchange working the other way, starting from the Alma record and looking to ArchivesSpace for a resource record with that MMS ID (in a locally specified field), creating a resource if non-existent or updating if existent. We would also like to think through subject and agent access points and keeping those up-to-date in both systems (using URIs), and optimally, up-to-date with the authority file (functionality that Alma currently offers). Lastly, exchanging and maintaining container inventories and barcodes (instances in ArchivesSpace and item records in Alma) across the systems is another area of functionality we?d like to explore. We?d like to host a conference call for interested parties. Can folks respond if they are interested in taking part? If there?s enough momentum, I?ll send around a Doodle poll with some available times. Best wishes, Adrien, Susan, and Vernica Houghton Library From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Chad Mills Sent: Wednesday, October 24, 2018 2:30 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Alma Integration Hi all, Attached is the reference architecture and test/sample implementation architecture we developed at Rutgers. We have not implemented this yet. Best, Chad From: Chad Mills Sent: Friday, October 12, 2018 8:43 AM To: Archivesspace Users Group > Subject: RE: [Archivesspace_Users_Group] Alma Integration Hi, We are interested! At Rutgers earlier this year we developed a reference architecture for our Special Collections. We tested the reference architecture by creating an implementation architecture using Alma, Primo, ArchiveSpace and a generic repository framework. In June we migrated to Alma so we will be looking to integrate ArchiveSpace with Alma in the near future using our the reference architecture as a blue print. I?ll see if I can share that reference architecture with the group. Best, Chad ------------------------------------- Chad Mills Digital Library Architect Rutgers University Libraries Phone: 848.932.5924 Cell: 732.309.8538 ------------------------------------- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Megan Firestone Sent: Wednesday, October 10, 2018 1:34 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Alma Integration Hi, We us Alma as our library ILS here, so we have been looking at the possibility of integrating Alma and ArchivesSpace. I was curious if anyone else is interested in this type of integration and if there is any work being done? Thanks! Megan -- Megan M. Firestone Archivist and Public Services Librarian Munday Library St. Edward's University 3001 S. Congress Ave. Austin, TX 78704 512.428.1047 This message and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please delete all copies of the message and its attachments and notify the sender immediately. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From epyers at slv.vic.gov.au Tue Jan 8 18:12:43 2019 From: epyers at slv.vic.gov.au (Emily Pyers) Date: Tue, 8 Jan 2019 23:12:43 +0000 Subject: [Archivesspace_Users_Group] Anyone making use of Harvard's aspace-import-excel plugin? Message-ID: <042c7614daeb4a4a8af2d68205f6a56d@STAFFEXCH01.staff.local> Link to it in GitHub here: https://github.com/harvard-library/aspace-import-excel We?re really excited about it (the 80% rule!) and have implemented it on our test system (v2.4.0). We?ve been testing it and it?s mostly working fine, until we attempt to load spreadsheets that have more than around 100 lines. Attempts to load spreadsheets over this size are resulting in job timeouts and overall system slowdowns, and we?ve tested pretty thoroughly ? it doesn?t seem to be an issue with the data. Our tech team have reviewed the system logs, but are unable to pinpoint the source of the problem. I was hoping someone out there might be able to confirm that a) they have successfully used the plugin to load spreadsheets greater than 100 lines (since this seems to be a point of scepticism for some of our internal stakeholders), and that b) if you might be able to point us towards any potential areas of investigation? I would be so appreciative for any help on this! Cheers, Emily Emily Pyers | Metadata & Archival Systems Specialist | Collection Development & Description In the office Monday, Wednesday - Friday 9.30am-3pm State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 T +61 3 8664 7368 | epyers at slv.vic.gov.au slv.vic.gov.au [http://www.slv.vic.gov.au/sites/default/files/email_signature/signature.jpg?6] [follow us] [SLV facebook] [SLV twitter] [SLV youtube] [SLV instagram] [RACV logo] This message and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please delete all copies of the message and its attachments and notify the sender immediately. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Tue Jan 8 18:51:44 2019 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 8 Jan 2019 23:51:44 +0000 Subject: [Archivesspace_Users_Group] Anyone making use of Harvard's aspace-import-excel plugin? In-Reply-To: <042c7614daeb4a4a8af2d68205f6a56d@STAFFEXCH01.staff.local> References: <042c7614daeb4a4a8af2d68205f6a56d@STAFFEXCH01.staff.local> Message-ID: <034F9226-1CAA-4C19-A88E-56B46D6B5299@virginia.edu> We have been using the plugin routinely. We did recently have some problems when we tried it on a very large spreadsheet ( > 2000 rows ) It seemed to me that when the web app appeared to have finished importing the spreadsheet, it was really still processing in the background for a long time. ( hours! ) That made it appear that it didn?t completely work. We then tried to delete and redo again, which caused even more problems. Or It might be that the archival_objects are created but not yet indexed. (*) So I would suggest first doing import on a test server, and to wait a long time for the job to complete. When we redid it again, on production, waiting overnight for completion, we got everything but a couple of rows. We didn?t spend any more time trying to locate the exact error on those rows ? we just added the missing values manually. So I?m not 100% sure of my diagnosis and description of the problem. But even with the manual fixup, it still saved a lot of time on the other 2000 archival objects! But if you?re seeing issues with 100+ lines, perhaps we need to implement some post import QA check to verify that everything imported correctly. (*) In one case, we tried to delete archival_objects after what appeared to be an unsuccessful import, however after some were deleted, more continued to appear, and the 2nd attempt to import hit errors trying to recreate still existing records. ? Steve Majewski > On Jan 8, 2019, at 6:12 PM, Emily Pyers wrote: > > Link to it in GitHub here: https://github.com/harvard-library/aspace-import-excel > > We?re really excited about it (the 80% rule!) and have implemented it on our test system (v2.4.0). We?ve been testing it and it?s mostly working fine, until we attempt to load spreadsheets that have more than around 100 lines. Attempts to load spreadsheets over this size are resulting in job timeouts and overall system slowdowns, and we?ve tested pretty thoroughly ? it doesn?t seem to be an issue with the data. Our tech team have reviewed the system logs, but are unable to pinpoint the source of the problem. > > I was hoping someone out there might be able to confirm that a) they have successfully used the plugin to load spreadsheets greater than 100 lines (since this seems to be a point of scepticism for some of our internal stakeholders), and that b) if you might be able to point us towards any potential areas of investigation? > > I would be so appreciative for any help on this! > > Cheers, > > Emily > > Emily Pyers | Metadata & Archival Systems Specialist | Collection Development & Description > In the office Monday, Wednesday - Friday 9.30am-3pm > State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 > T +61 3 8664 7368 | epyers at slv.vic.gov.au > slv.vic.gov.au > > > > > This message and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please delete all copies of the message and its attachments and notify the sender immediately. Thank you. _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3598 bytes Desc: not available URL: From aep3 at williams.edu Tue Jan 8 18:53:23 2019 From: aep3 at williams.edu (Peale, Anne) Date: Tue, 8 Jan 2019 18:53:23 -0500 Subject: [Archivesspace_Users_Group] Anyone making use of Harvard's aspace-import-excel plugin? In-Reply-To: <042c7614daeb4a4a8af2d68205f6a56d@STAFFEXCH01.staff.local> References: <042c7614daeb4a4a8af2d68205f6a56d@STAFFEXCH01.staff.local> Message-ID: Hi Emily, We installed the plugin about a year ago and it's been working brilliantly. We have loaded several very large files (up to c. 1500 items), and the process is a little slow but it does complete. However, we have also noticed that when we use the plugin in our sandbox environment, it is much less tolerant of large sets of items and can only cope with short lists. I'm not the administrator for ASpace at Williams and don't know much about the way our server is set up, but I wonder if the problem has something to do with server capacity and if the plugin will actually work fine when you try to load to your main ASpace system. If you'd like more information, I can ask our administrator for details. The plugin has been an absolute joy to work with, especially for importing legacy finding aids. We've also had good luck having student assistants enter data into a google form or sheet, then proofreading before importing -- much smoother than trying to proofread additions made directly by rapid data entry. All best, Anne On Tue, Jan 8, 2019 at 6:12 PM Emily Pyers wrote: > Link to it in GitHub here: > https://github.com/harvard-library/aspace-import-excel > > > > We?re really excited about it (the 80% rule!) and have implemented it on > our test system (v2.4.0). We?ve been testing it and it?s mostly working > fine, until we attempt to load spreadsheets that have more than around 100 > lines. Attempts to load spreadsheets over this size are resulting in job > timeouts and overall system slowdowns, and we?ve tested pretty thoroughly ? > it doesn?t seem to be an issue with the data. Our tech team have > reviewed the system logs, but are unable to pinpoint the source of the > problem. > > > > I was hoping someone out there might be able to confirm that a) they have > successfully used the plugin to load spreadsheets greater than 100 lines > (since this seems to be a point of scepticism for some of our internal > stakeholders), and that b) if you might be able to point us towards any > potential areas of investigation? > > > > I would be so appreciative for any help on this! > > > > Cheers, > > > > Emily > > *Emily Pyers | Metadata & Archival Systems Specialist | Collection > Development & Description * > In the office Monday, Wednesday - Friday 9.30am-3pm > State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 > T +61 3 8664 7368 | epyers at slv.vic.gov.au > slv.vic.gov.au > > > > [image: follow us] > [image: SLV facebook] > [image: > SLV twitter] [image: SLV youtube] > [image: SLV instagram] > [image: RACV logo] > This message and any attachment is intended only for the use of the > Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. > If you are not the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please delete all copies of the > message and its attachments and notify the sender immediately. Thank you. > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltang5 at lib.msu.edu Wed Jan 9 15:43:00 2019 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Wed, 9 Jan 2019 20:43:00 +0000 Subject: [Archivesspace_Users_Group] Records Management with ArchivesSpace? Message-ID: <9E0DF107-C175-45E9-83F4-2A0752995078@lib.msu.edu> Hi all, The SAA Records Management listserv had a discussion about using ArchivesSpace for Records Management and I just wanted to start the conversation on this list as well. Does anyone here currently use (or would like) to use ArchivesSpace for records management? If so, are you using the Dartmouth plug-in? https://github.com/hudmol/aspace_rms I wonder if there are ways the plug in could be expanded and adapted into the core code, potentially. If not, what program do you currently use? I wonder if there may be an interest in integrating with an existing system. I?d love to hear your thoughts! Lydia -- Dr. Lydia Tang, CA, DAS, DMA, MLIS Special Collections Archivist-Librarian Philosophy, Aesthetics, and Ethics Bibliographer Michigan State University Libraries 366 W. Circle Drive (DB 6) East Lansing, MI 48824-1048 Email: ltang5 at msu.edu Phone: 517-884-8984 From jhoffman at library.msstate.edu Thu Jan 10 15:50:32 2019 From: jhoffman at library.msstate.edu (Hoffman, Jenifer) Date: Thu, 10 Jan 2019 20:50:32 +0000 Subject: [Archivesspace_Users_Group] Deleting Rapid Data Entry templates Message-ID: <2c3bc355c366458ab67fa83ff204bcf9@mail06.ad.msstate.edu> I have a simple question, but haven't been able to find out any information about how to do this - how do you delete a specific rapid data entry template from your dropdown list? There is a link to "delete templates" but the "s" is scaring me off because I don't want to delete all of them. Any ideas? Jenifer Ishee, M.A., MLIS Assistant Professor/Manuscripts Librarian Special Collections jhoffman at library.msstate.edu https://orcid.org/0000-0001-8877-4745 From lcalahan at umn.edu Fri Jan 11 10:21:28 2019 From: lcalahan at umn.edu (Lisa Calahan) Date: Fri, 11 Jan 2019 09:21:28 -0600 Subject: [Archivesspace_Users_Group] Deleting Rapid Data Entry templates In-Reply-To: <2c3bc355c366458ab67fa83ff204bcf9@mail06.ad.msstate.edu> References: <2c3bc355c366458ab67fa83ff204bcf9@mail06.ad.msstate.edu> Message-ID: If you click on "Remove Templates," you will get a drop down list of all the templates and can select the one(s) you wish to delete. [image: Screen Shot 2019-01-11 at 9.20.53 AM.png] On Thu, Jan 10, 2019 at 2:50 PM Hoffman, Jenifer < jhoffman at library.msstate.edu> wrote: > I have a simple question, but haven't been able to find out any > information about how to do this - how do you delete a specific rapid data > entry template from your dropdown list? There is a link to "delete > templates" but the "s" is scaring me off because I don't want to delete all > of them. > > Any ideas? > > > Jenifer Ishee, M.A., MLIS > Assistant Professor/Manuscripts Librarian > Special Collections > jhoffman at library.msstate.edu > https://orcid.org/0000-0001-8877-4745 > > > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- Pronouns: She/her/hers Head of Archival Processing University of Minnesota Libraries Archives and Special Collections Elmer L. Andersen Library, Suite 315 222-21st Ave. S. Minneapolis MN 55455 Phone: 612.626.2531 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-01-11 at 9.20.53 AM.png Type: image/png Size: 65775 bytes Desc: not available URL: From lmcphee at ucsd.edu Fri Jan 11 10:59:11 2019 From: lmcphee at ucsd.edu (McPhee, Laurel) Date: Fri, 11 Jan 2019 15:59:11 +0000 Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records Message-ID: Hi all, and happy Friday. We're attempting to troubleshoot a strange problem. I'd appreciate knowing if anyone else has this issue, or has any suggestions. Our database analyst has started looking into it, but it's a puzzler. We have 2,600 accession records. As far as I know, the Collection Mgmt subtable has a 1-to-1 relationship with the Accession table. However, if I filter a search on Collection Mgmt (Browse-->Collection Mgmt) over 3,600 records display. A careful search through the results shows that often (not always!) when we update the processing status on an accession, using the little pull-down menu, a "ghost" collection management record lingers on, and will appear in search results sets within Collection Management. So one accession record, although it looks perfectly correct and updated in the accession record staff view, will have two collection management records, one showing "processed" and one showing "unprocessed" if you search for that same record in the Collection Mgmt browse feature. We thought a purge of our deleted records and a re-index might fix this. But, the plot thickens: at the end of the day yesterday, when we purged our deleted records and reindexed in our test instance, the Collection Mgmt table now shows over 4,000 results! It's like it made the problem WORSE. Instead of duplicate ghosts, we now have triplicate ghosts. Does anyone else have this problem with a numbers mis-match between Coll Mgmt and Accessions? I can't replicate it in the Sandbox because the problem doesn't seem to happen with "new" accession records. If I make a new test accession record, the problem won't occur. But if I change the processing status of an older, legacy record (one that imported over from AT a few years ago), it sometimes occurs. We're running v2.3.2. Laurel McPhee Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | * 858-534-5619 | * lmcphee at ucsd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhoffman at library.msstate.edu Fri Jan 11 11:11:55 2019 From: jhoffman at library.msstate.edu (Hoffman, Jenifer) Date: Fri, 11 Jan 2019 16:11:55 +0000 Subject: [Archivesspace_Users_Group] Deleting Rapid Data Entry templates In-Reply-To: References: <2c3bc355c366458ab67fa83ff204bcf9@mail06.ad.msstate.edu> Message-ID: Thank you ? I thought it was probably that simple! From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lisa Calahan Sent: Friday, January 11, 2019 9:21 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Deleting Rapid Data Entry templates If you click on "Remove Templates," you will get a drop down list of all the templates and can select the one(s) you wish to delete. [Screen Shot 2019-01-11 at 9.20.53 AM.png] On Thu, Jan 10, 2019 at 2:50 PM Hoffman, Jenifer > wrote: I have a simple question, but haven't been able to find out any information about how to do this - how do you delete a specific rapid data entry template from your dropdown list? There is a link to "delete templates" but the "s" is scaring me off because I don't want to delete all of them. Any ideas? Jenifer Ishee, M.A., MLIS Assistant Professor/Manuscripts Librarian Special Collections jhoffman at library.msstate.edu https://orcid.org/0000-0001-8877-4745 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Pronouns: She/her/hers Head of Archival Processing University of Minnesota Libraries Archives and Special Collections Elmer L. Andersen Library, Suite 315 222-21st Ave. S. Minneapolis MN 55455 Phone: 612.626.2531 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 42103 bytes Desc: image001.png URL: From blake.carver at lyrasis.org Fri Jan 11 11:20:58 2019 From: blake.carver at lyrasis.org (Blake Carver) Date: Fri, 11 Jan 2019 16:20:58 +0000 Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records In-Reply-To: References: Message-ID: If you look in the actual MySQL tables, what's the counts? ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of McPhee, Laurel Sent: Friday, January 11, 2019 10:59:11 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records Hi all, and happy Friday. We?re attempting to troubleshoot a strange problem. I?d appreciate knowing if anyone else has this issue, or has any suggestions. Our database analyst has started looking into it, but it?s a puzzler. We have 2,600 accession records. As far as I know, the Collection Mgmt subtable has a 1-to-1 relationship with the Accession table. However, if I filter a search on Collection Mgmt (Browse-->Collection Mgmt) over 3,600 records display. A careful search through the results shows that often (not always!) when we update the processing status on an accession, using the little pull-down menu, a ?ghost? collection management record lingers on, and will appear in search results sets within Collection Management. So one accession record, although it looks perfectly correct and updated in the accession record staff view, will have two collection management records, one showing ?processed? and one showing ?unprocessed? if you search for that same record in the Collection Mgmt browse feature. We thought a purge of our deleted records and a re-index might fix this. But, the plot thickens: at the end of the day yesterday, when we purged our deleted records and reindexed in our test instance, the Collection Mgmt table now shows over 4,000 results! It?s like it made the problem WORSE. Instead of duplicate ghosts, we now have triplicate ghosts. Does anyone else have this problem with a numbers mis-match between Coll Mgmt and Accessions? I can?t replicate it in the Sandbox because the problem doesn?t seem to happen with ?new? accession records. If I make a new test accession record, the problem won?t occur. But if I change the processing status of an older, legacy record (one that imported over from AT a few years ago), it sometimes occurs. We?re running v2.3.2. Laurel McPhee Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619 | ? lmcphee at ucsd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmcphee at ucsd.edu Mon Jan 14 10:51:30 2019 From: lmcphee at ucsd.edu (McPhee, Laurel) Date: Mon, 14 Jan 2019 15:51:30 +0000 Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records In-Reply-To: References: Message-ID: Hi Blake, The MySQL tables show: mysql> select count(*) from accession; +----------+ | count(*) | +----------+ | 2702 | +----------+ 1 row in set (0.01 sec) mysql> select count(*) from collection_management; +----------+ | count(*) | +----------+ | 2695 | +----------+ 1 row in set (0.00 sec) Without knowing much about what that means, my hunch is that our "real" number of records is correct, or just off by a mere handful. But for some reason we're seeing lots of junk appear in the staff interface filters and view. Any insights? (and sorry for confusion on my originally reported numbers, I meant to type we had 2,700 accessions, not 2,600. So the number in the tables is exactly what we expect to see there). Laurel From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Blake Carver Sent: Friday, January 11, 2019 8:21 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records If you look in the actual MySQL tables, what's the counts? ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of McPhee, Laurel > Sent: Friday, January 11, 2019 10:59:11 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records Hi all, and happy Friday. We're attempting to troubleshoot a strange problem. I'd appreciate knowing if anyone else has this issue, or has any suggestions. Our database analyst has started looking into it, but it's a puzzler. We have 2,600 accession records. As far as I know, the Collection Mgmt subtable has a 1-to-1 relationship with the Accession table. However, if I filter a search on Collection Mgmt (Browse-->Collection Mgmt) over 3,600 records display. A careful search through the results shows that often (not always!) when we update the processing status on an accession, using the little pull-down menu, a "ghost" collection management record lingers on, and will appear in search results sets within Collection Management. So one accession record, although it looks perfectly correct and updated in the accession record staff view, will have two collection management records, one showing "processed" and one showing "unprocessed" if you search for that same record in the Collection Mgmt browse feature. We thought a purge of our deleted records and a re-index might fix this. But, the plot thickens: at the end of the day yesterday, when we purged our deleted records and reindexed in our test instance, the Collection Mgmt table now shows over 4,000 results! It's like it made the problem WORSE. Instead of duplicate ghosts, we now have triplicate ghosts. Does anyone else have this problem with a numbers mis-match between Coll Mgmt and Accessions? I can't replicate it in the Sandbox because the problem doesn't seem to happen with "new" accession records. If I make a new test accession record, the problem won't occur. But if I change the processing status of an older, legacy record (one that imported over from AT a few years ago), it sometimes occurs. We're running v2.3.2. Laurel McPhee Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | * 858-534-5619 | * lmcphee at ucsd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Mon Jan 14 13:45:43 2019 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 14 Jan 2019 18:45:43 +0000 Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records In-Reply-To: References: Message-ID: I noticed, while researching this issue, that there is no .dat file in my archivesspace/data/inderer_state directly named container_management. Perhaps that info is kept in corresponding resource files, however, I see that there is a primary_type in Solr records for container_management. Which makes me suspicious that there is something missing in the codebase to keep these records in sync. ( I?m on 2.5.x, so I don?t know what would be different in 2.3.x ) It also makes me question if you did a complete reindex ( i.e. delete ALL of data/indexer_state/* and data/solr_index/ and restart ) or partial, as that might make a difference here. Usually, deleting the indexer_state files in enough, but I?m suspicious here. I suggest you open the Solr web console to ArchivesSpace ? usually at port 8090, unless you have changed the default, and enter: primary_type: collection_management in the Query console. Look first at response.numFound, which from your description, I expect doesn?t match the number returned from SQL query. Then you might drill down to inspect if there are duplicate records with the same parent_id, or if there are id # returned in the solr query that have been deleted from SQL. What else you might look at depends on what clues you initially see. BTW: I found it very simple to add collection_management_subreports to accession_report and resource_list_report in 2.5.x, However, I think the reports subsystem was very different in 2.3.x. And that would still only give you the records that are in SQL, not the ones that aren?t, which seems to be the problem. ? Steve Majewski > On Jan 14, 2019, at 10:51 AM, McPhee, Laurel wrote: > > Hi Blake, > > The MySQL tables show: > > mysql> select count(*) from accession; > +----------+ > | count(*) | > +----------+ > | 2702 | > +----------+ > 1 row in set (0.01 sec) > > mysql> select count(*) from collection_management; > +----------+ > | count(*) | > +----------+ > | 2695 | > +----------+ > 1 row in set (0.00 sec) > > Without knowing much about what that means, my hunch is that our ?real? number of records is correct, or just off by a mere handful. But for some reason we?re seeing lots of junk appear in the staff interface filters and view. Any insights? (and sorry for confusion on my originally reported numbers, I meant to type we had 2,700 accessions, not 2,600. So the number in the tables is exactly what we expect to see there). > > Laurel > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Blake Carver > Sent: Friday, January 11, 2019 8:21 AM > To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records > > If you look in the actual MySQL tables, what's the counts? > From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of McPhee, Laurel > > Sent: Friday, January 11, 2019 10:59:11 AM > To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records > > Hi all, and happy Friday. > > We?re attempting to troubleshoot a strange problem. I?d appreciate knowing if anyone else has this issue, or has any suggestions. Our database analyst has started looking into it, but it?s a puzzler. > > We have 2,600 accession records. As far as I know, the Collection Mgmt subtable has a 1-to-1 relationship with the Accession table. However, if I filter a search on Collection Mgmt (Browse?Collection Mgmt) over 3,600 records display. A careful search through the results shows that often (not always!) when we update the processing status on an accession, using the little pull-down menu, a ?ghost? collection management record lingers on, and will appear in search results sets within Collection Management. So one accession record, although it looks perfectly correct and updated in the accession record staff view, will have two collection management records, one showing ?processed? and one showing ?unprocessed? if you search for that same record in the Collection Mgmt browse feature. > > We thought a purge of our deleted records and a re-index might fix this. But, the plot thickens: at the end of the day yesterday, when we purged our deleted records and reindexed in our test instance, the Collection Mgmt table now shows over 4,000 results! It?s like it made the problem WORSE. Instead of duplicate ghosts, we now have triplicate ghosts. Does anyone else have this problem with a numbers mis-match between Coll Mgmt and Accessions? > > I can?t replicate it in the Sandbox because the problem doesn?t seem to happen with ?new? accession records. If I make a new test accession record, the problem won?t occur. But if I change the processing status of an older, legacy record (one that imported over from AT a few years ago), it sometimes occurs. We?re running v2.3.2. > > Laurel McPhee > Supervisory Archivist, Special Collections & Archives Program > UC San Diego Library | ( 858-534-5619 | * lmcphee at ucsd.edu > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3598 bytes Desc: not available URL: From livsolis at utexas.edu Mon Jan 14 14:26:03 2019 From: livsolis at utexas.edu (Olivia S Solis) Date: Mon, 14 Jan 2019 13:26:03 -0600 Subject: [Archivesspace_Users_Group] Anyone making use of Harvard's aspace-import-excel plugin? In-Reply-To: References: <042c7614daeb4a4a8af2d68205f6a56d@STAFFEXCH01.staff.local> Message-ID: Hi Emily, We have been using the plugin (We're using 2.4.1 of ASpace and 2.1.13 of the Harvard plugin.), and as with for others, it is working great!! Thank you Harvard, so much. The largest inventory we did was for a record with approximately 3500 lines of inventory. I worked great, taking about 50 minutes to complete the job, but that would probably depend on your system specs. We made some modifications to the spreadsheet to suit our needs and uploaded the Excel spreadsheet as a Google Sheets doc, which processors make copies from. I am sharing below: https://docs.google.com/spreadsheets/d/1-hCN-1OZDctrRnWO8Hg_3SXbtPATTT9l6Z8CueWVPKQ/edit?usp=sharing Some of the changes: - I added data validation so that processors can only enter kosher dates for begin and end dates. - Same for our EAD ID column, which requires a certain syntax. - You can only upload 1 date record through the spreadsheet, but you can add any column you want. We added a column for processors to keep track of their dates should they want more than one date record per archival object. They go back in the GUI and manually add dates not uploaded through the spreadsheet. - We keep track of container profiles and locations for top containers. We added columns for those so processors can document those and go back and add them through top container/bulk updates in the GUI. - Added values in dropdown menus for the columns (container profiles, instance type, etc.). One other thing we've found in our ongoing experiments with the plugin is that it is easy to make mistakes that ASpace would normally catch in the GUI if you just use the spreadsheet. (e.g. you might forget to enter the date type.. ASpace/the plugin will reject the date). Yes, the plugin will throw you an error, but it is much better to catch the mistakes up front. I am working on a workflow for checking for varied possible mistakes using Google Sheets filter views, which can be saved and copied over to the spreadsheets processors use. Those checks are described here , but disclaimer: this is very drafty! I'm not done with container checks and the things we need to check for grows. But I think filters are a good way to check that you've got all the required info to make an archival object record or subrecord within that archival object. A few other things. If you go Google Sheets (which I believe Harvard would discourage) and download as xslx, make sure all your columns are in Text (vs. auto or number mode) in your Sheets template. In fact, I feel it is risky to write in Google Sheets and open in Excel because it might (e.g.) mess with your dates and transform them to a syntax ASpace will reject ... mess with other formatted text. We sometimes have boxes reserved for oversize or restricted materials and these boxes already exist in ASpace as top containers. Processors sometimes add materials to them and need to refer to those top containers in their inventories. The barcode column is how you link to the existing top container record using the spreadsheet/plugin. But we are having problems doing that with barcodes that are strings of numbers, though not with anything that includes both numbers and letters works fine. This is also because we implemented this config fix (see also here ). We don't totally understand the issue, but the linkage is not made when we have the config fix turned on. It does when we don't. At any rate, thank you again, Harvard! I strongly recommend your plugin. Best, Olivia On Tue, Jan 8, 2019 at 5:53 PM Peale, Anne wrote: > Hi Emily, > > We installed the plugin about a year ago and it's been working > brilliantly. We have loaded several very large files (up to c. 1500 items), > and the process is a little slow but it does complete. > > However, we have also noticed that when we use the plugin in our sandbox > environment, it is much less tolerant of large sets of items and can only > cope with short lists. I'm not the administrator for ASpace at Williams and > don't know much about the way our server is set up, but I wonder if the > problem has something to do with server capacity and if the plugin will > actually work fine when you try to load to your main ASpace system. If > you'd like more information, I can ask our administrator for details. > > The plugin has been an absolute joy to work with, especially for importing > legacy finding aids. We've also had good luck having student assistants > enter data into a google form or sheet, then proofreading before importing > -- much smoother than trying to proofread additions made directly by rapid > data entry. > > All best, > Anne > > On Tue, Jan 8, 2019 at 6:12 PM Emily Pyers wrote: > >> Link to it in GitHub here: >> https://github.com/harvard-library/aspace-import-excel >> >> >> >> We?re really excited about it (the 80% rule!) and have implemented it on >> our test system (v2.4.0). We?ve been testing it and it?s mostly working >> fine, until we attempt to load spreadsheets that have more than around 100 >> lines. Attempts to load spreadsheets over this size are resulting in job >> timeouts and overall system slowdowns, and we?ve tested pretty thoroughly ? >> it doesn?t seem to be an issue with the data. Our tech team have >> reviewed the system logs, but are unable to pinpoint the source of the >> problem. >> >> >> >> I was hoping someone out there might be able to confirm that a) they have >> successfully used the plugin to load spreadsheets greater than 100 lines >> (since this seems to be a point of scepticism for some of our internal >> stakeholders), and that b) if you might be able to point us towards any >> potential areas of investigation? >> >> >> >> I would be so appreciative for any help on this! >> >> >> >> Cheers, >> >> >> >> Emily >> >> *Emily Pyers | Metadata & Archival Systems Specialist | Collection >> Development & Description * >> In the office Monday, Wednesday - Friday 9.30am-3pm >> State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 >> T +61 3 8664 7368 | epyers at slv.vic.gov.au >> slv.vic.gov.au >> >> >> >> [image: follow us] >> [image: SLV facebook] >> [image: >> SLV twitter] [image: SLV youtube] >> [image: SLV instagram] >> [image: RACV logo] >> This message and any attachment is intended only for the use of the >> Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. >> If you are not the intended recipient, you are hereby notified that any >> dissemination of this communication is strictly prohibited. If you have >> received this communication in error, please delete all copies of the >> message and its attachments and notify the sender immediately. Thank you. >> _______________________________________________ >> 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: From bobbi at bobbifox.net Mon Jan 14 14:35:25 2019 From: bobbi at bobbifox.net (Bobbi Fox) Date: Mon, 14 Jan 2019 14:35:25 -0500 (EST) Subject: [Archivesspace_Users_Group] A Word Of Caution (was Re: Anyone making use of Harvard's aspace-import-excel plugin?) In-Reply-To: References: <042c7614daeb4a4a8af2d68205f6a56d@STAFFEXCH01.staff.local> Message-ID: Thank you, Olivia, for your kind words. Please note that at the moment, downloading and initializing this plugin fails, apparently due to the release of Bundler 2.0 (https://bundler.io/blog/2019/01/03/announcing-bundler-2.html) We are working on a fix, but unfortunately do not have an ETA for its delivery. Once we have a working solution, we will make an announcement. Sorry, Bobbi (No longer at Harvard, but still supporting aspace-import-excel) On Mon, 14 Jan 2019, Olivia S Solis wrote: > Hi Emily, > We have been using the plugin (We're using 2.4.1 of ASpace and 2.1.13 of the > Harvard plugin.), and as with for others, it is working great!!? Thank you Harvard, > so much. The largest inventory we did was for a record with approximately 3500 > lines of inventory. I worked great, taking about 50 minutes to complete the job, > but that would probably depend on your system specs. > > We made some modifications to the spreadsheet to suit our needs and uploaded the > Excel spreadsheet as a Google Sheets doc, which processors make copies from. I am > sharing below: > https://docs.google.com/spreadsheets/d/1-hCN-1OZDctrRnWO8Hg_3SXbtPATTT9l6Z8CueWVPK > Q/edit?usp=sharing > > Some of the changes: > * I added data validation so that processors can only enter kosher dates for > begin and end dates. > * Same for our EAD ID column, which requires a certain syntax. > * You can only upload 1 date record through the spreadsheet, but you can add any > column you want. We added a column for processors to keep track of their dates > should they want more than one date record per archival object. They go back in > the GUI and manually add dates not uploaded through the spreadsheet. > * We keep track of container profiles and locations for top containers. We added > columns for those so processors can document those and go back and add them > through top container/bulk updates in the GUI. > * Added values in dropdown menus for the columns (container profiles, instance > type, etc.). > One other thing we've found in our ongoing experiments with the plugin is that it > is easy to make mistakes that ASpace would normally catch in the GUI if you just > use the spreadsheet. (e.g. you might forget to enter the date type.. ASpace/the > plugin will reject the date). Yes, the plugin will throw you an error, but it is > much better to catch the mistakes up front. I am working on a workflow for checking > for varied possible mistakes using Google Sheets filter views, which can be saved > and copied over to the spreadsheets processors use. Those checks are described > here, but disclaimer: this is very drafty! I'm not done with container checks and > the things we need to check for grows. But I think filters are a good way to check > that you've got all the required info to make an archival object record or > subrecord within that archival object. > > A few other things. If you go Google Sheets (which I believe Harvard would > discourage) and download as xslx, make sure all your columns are in Text (vs. auto > or number mode) in your Sheets template. In fact, I feel it is risky to write in > Google Sheets and open in Excel because it might (e.g.) mess with your dates and > transform them to a syntax ASpace will reject ... mess with other formatted text. > > We sometimes have boxes reserved for oversize or restricted materials and these > boxes already exist in ASpace as top containers. Processors sometimes add materials > to them and need to refer to those top containers in their inventories. The barcode > column is how you link to the existing top container record using the > spreadsheet/plugin. But we are having problems doing that with barcodes that are > strings of numbers, though not with anything that includes both numbers and letters > works fine. This is also because we implemented this?config fix?(see also here). We > don't totally understand the issue, but the linkage is not made when we have the > config fix turned on. It does when we don't. > > At any rate, thank you again, Harvard! I strongly recommend your plugin. > > Best, > Olivia > > > On Tue, Jan 8, 2019 at 5:53 PM Peale, Anne wrote: > Hi Emily, > We installed the plugin about a year ago and it's been working brilliantly. > We have loaded several very large files (up to c. 1500 items), and the > process is a little slow but it does complete.? > > However, we have also noticed that when we use the plugin in our sandbox > environment, it is much less tolerant of large sets of items and can only > cope with short lists. I'm not the administrator for ASpace at Williams and > don't know much about the way our server is set up, but I wonder if the > problem has something to do with server capacity and if the plugin will > actually work fine when you try to load to your main ASpace system. If you'd > like more information, I can ask our administrator for details. > > The plugin has been an absolute joy to work with, especially for importing > legacy finding aids. We've also had good luck having student assistants enter > data into a google form or sheet, then proofreading before importing -- much > smoother than trying to proofread additions made directly by rapid data > entry. > > All best, > Anne > > On Tue, Jan 8, 2019 at 6:12 PM Emily Pyers wrote: > > Link to it in GitHub here: > https://github.com/harvard-library/aspace-import-excel > > ? > > We?re really excited about it (the 80% rule!) and have > implemented it on our test system (v2.4.0).? We?ve been testing > it and it?s mostly working fine, until we attempt to load > spreadsheets that have more than around 100 lines. Attempts to > load spreadsheets over this size are resulting in job timeouts > and overall system slowdowns, and we?ve tested pretty thoroughly > ? it doesn?t seem to be an issue with the data.? Our tech team > have reviewed the system logs, but are unable to pinpoint the > source of the problem. > > ? > > I was hoping someone out there might be able to confirm that a) > they have successfully used the plugin to load spreadsheets > greater than 100 lines (since this seems to be a point of > scepticism for some of our internal stakeholders), and that b) if > you might be able to point us towards any potential areas of > investigation? > > ? > > I would be so appreciative for any help on this! > > ? > > Cheers, > > ? > > Emily? > > > Emily?Pyers | Metadata & Archival Systems Specialist | Collection > Development & Description > In the office Monday, Wednesday - Friday 9.30am-3pm > State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 > T +61 3 8664 7368 | epyers at slv.vic.gov.au > slv.vic.gov.au > > > [signature.jpg?6] > ? > follow us > SLV facebook > SLV twitter > SLV youtube > SLV instagram > RACV logo > This message and any attachment is intended only for the use of the > Addressee and may contain information that is PRIVILEGED and > CONFIDENTIAL. If you are not the intended recipient, you are hereby > notified that any dissemination of this communication is strictly > prohibited. If you have received this communication in error, please > delete all copies of the message and its attachments and notify the > sender immediately. Thank you. > _______________________________________________ > 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 > > -- Bobbi Fox bobbi at bobbifox.net Database-driven and Web-enabled applications development http://www.bobbifox.net From lmcphee at ucsd.edu Mon Jan 14 17:01:11 2019 From: lmcphee at ucsd.edu (McPhee, Laurel) Date: Mon, 14 Jan 2019 22:01:11 +0000 Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records In-Reply-To: References: Message-ID: Steve, thank you so much for this tip. With this information, we were able to discover we hadn?t really been purging our deleted records and running a true re-index, when we thought we were. We had only been deleting the one index-related directory, not both. It does seem to take longer to re-index when deleting both directories ? so much so that I was getting really nervous that we?d messed something up. But we?ll all good now. Thank you so much for the solution! Laurel From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Majewski, Steven Dennis (sdm7g) Sent: Monday, January 14, 2019 10:46 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records I noticed, while researching this issue, that there is no .dat file in my archivesspace/data/inderer_state directly named container_management. Perhaps that info is kept in corresponding resource files, however, I see that there is a primary_type in Solr records for container_management. Which makes me suspicious that there is something missing in the codebase to keep these records in sync. ( I?m on 2.5.x, so I don?t know what would be different in 2.3.x ) It also makes me question if you did a complete reindex ( i.e. delete ALL of data/indexer_state/* and data/solr_index/ and restart ) or partial, as that might make a difference here. Usually, deleting the indexer_state files in enough, but I?m suspicious here. I suggest you open the Solr web console to ArchivesSpace ? usually at port 8090, unless you have changed the default, and enter: primary_type: collection_management in the Query console. Look first at response.numFound, which from your description, I expect doesn?t match the number returned from SQL query. Then you might drill down to inspect if there are duplicate records with the same parent_id, or if there are id # returned in the solr query that have been deleted from SQL. What else you might look at depends on what clues you initially see. BTW: I found it very simple to add collection_management_subreports to accession_report and resource_list_report in 2.5.x, However, I think the reports subsystem was very different in 2.3.x. And that would still only give you the records that are in SQL, not the ones that aren?t, which seems to be the problem. ? Steve Majewski On Jan 14, 2019, at 10:51 AM, McPhee, Laurel > wrote: Hi Blake, The MySQL tables show: mysql> select count(*) from accession; +----------+ | count(*) | +----------+ | 2702 | +----------+ 1 row in set (0.01 sec) mysql> select count(*) from collection_management; +----------+ | count(*) | +----------+ | 2695 | +----------+ 1 row in set (0.00 sec) Without knowing much about what that means, my hunch is that our ?real? number of records is correct, or just off by a mere handful. But for some reason we?re seeing lots of junk appear in the staff interface filters and view. Any insights? (and sorry for confusion on my originally reported numbers, I meant to type we had 2,700 accessions, not 2,600. So the number in the tables is exactly what we expect to see there). Laurel From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Blake Carver Sent: Friday, January 11, 2019 8:21 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records If you look in the actual MySQL tables, what's the counts? ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of McPhee, Laurel > Sent: Friday, January 11, 2019 10:59:11 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] # of Collection Mgmt records not matching # of Accession records Hi all, and happy Friday. We?re attempting to troubleshoot a strange problem. I?d appreciate knowing if anyone else has this issue, or has any suggestions. Our database analyst has started looking into it, but it?s a puzzler. We have 2,600 accession records. As far as I know, the Collection Mgmt subtable has a 1-to-1 relationship with the Accession table. However, if I filter a search on Collection Mgmt (Browse-->Collection Mgmt) over 3,600 records display. A careful search through the results shows that often (not always!) when we update the processing status on an accession, using the little pull-down menu, a ?ghost? collection management record lingers on, and will appear in search results sets within Collection Management. So one accession record, although it looks perfectly correct and updated in the accession record staff view, will have two collection management records, one showing ?processed? and one showing ?unprocessed? if you search for that same record in the Collection Mgmt browse feature. We thought a purge of our deleted records and a re-index might fix this. But, the plot thickens: at the end of the day yesterday, when we purged our deleted records and reindexed in our test instance, the Collection Mgmt table now shows over 4,000 results! It?s like it made the problem WORSE. Instead of duplicate ghosts, we now have triplicate ghosts. Does anyone else have this problem with a numbers mis-match between Coll Mgmt and Accessions? I can?t replicate it in the Sandbox because the problem doesn?t seem to happen with ?new? accession records. If I make a new test accession record, the problem won?t occur. But if I change the processing status of an older, legacy record (one that imported over from AT a few years ago), it sometimes occurs. We?re running v2.3.2. Laurel McPhee Supervisory Archivist, Special Collections & Archives Program UC San Diego Library | ? 858-534-5619 | ? lmcphee at ucsd.edu _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.dibella at lyrasis.org Tue Jan 15 11:48:31 2019 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Tue, 15 Jan 2019 16:48:31 +0000 Subject: [Archivesspace_Users_Group] announcing the first ArchivesSpace Online Forum - March 18 beginning at 5:00 p.m. UTC Message-ID: Please join your fellow ArchivesSpace users on March 18 beginning at 5:00 p.m. UTC* for our first ever Online Forum. Our first event to specifically aim to span the many timezones of our community, this 11-hour ArchivesSpace extravaganza will be divided into three blocks of 3 hours each, with a 1-hour break between each block. As with our in-person forums, our Online Forum will include a mix of opportunities to share and learn from each other about many different aspects of ArchivesSpace. As our first online forum, this event will be an experiment and a chance for us to try out some different ways for our community to engage and interact. We anticipate recording many parts of the forum, but for it to be a success we will also need as many live participants as possible. We encourage you to dip in and out of the live program as you much as you can. You will no doubt "meet" a different set of colleagues each time. We are now accepting both session proposals and ideas for topics via our online form at https://goo.gl/forms/olTRwsxOkGwkXJAs2. We highly encourage you to submit your proposals and ideas by February 18 so that we can get the program squared away as early as possible. Information about how to register for the event will be released closer to March. A special thanks to our international working group, featuring ArchivesSpace users from Brooklyn to Bangalore. Feel free to reach out to any of us with ideas and questions: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/802127927/ASpace+Online+Forum+2019. We're looking forward to a great event, with your help! Christine * That means Honolulu 7 am | Los Angeles 10 am | Dallas noon | New York 1 pm | London 5 pm | Bangalore 10:30 pm | Auckland 6 am (following morning) - see https://goo.gl/sCKvA9 to find your local time Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [ASpaceOrgHomeMedium] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 6608 bytes Desc: image003.jpg URL: From julie_wetherill at harvard.edu Tue Jan 15 12:23:56 2019 From: julie_wetherill at harvard.edu (Wetherill, Julie M.) Date: Tue, 15 Jan 2019 17:23:56 +0000 Subject: [Archivesspace_Users_Group] PUI: when component has multiple container instances, PDF displays only the last one Message-ID: All, We noticed recently that the PUI PDF is not displaying all top container data for a component. For example, a particular component has 8 physical containers defined as follows: Box: 1 (Mixed Materials) Box: 13 (Mixed Materials) Box: 19 (Mixed Materials) Box: 21 (Mixed Materials) Box: 23 (Mixed Materials) Box: 26 (Mixed Materials) Box: 27 (Mixed Materials) Box: 49 (Mixed Materials) In the PUI, all of these top containers display OK but in the PUI PDF, only the last one displays: Personal and professional correspondence, circa 1960-2004 Identifier: Box 49 Date: circa 1960-2004 The number of top containers does not matter -- this happens if there are 2 physical containers or 20; always it's the last container only that displays in the PDF. Anyone else experience this? Any solutions? Thanks. --julie Julie Wetherill Library Technology Services Harvard University -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.dibella at lyrasis.org Tue Jan 15 15:00:22 2019 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Tue, 15 Jan 2019 20:00:22 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace v2.5.2 now available Message-ID: ArchivesSpace is announcing the availability of v2.5.2. You can download it at https://github.com/archivesspace/archivesspace/releases/tag/v2.5.2. This release contains program-led and community pull requests that provide feature enhancements, bug fixes, infrastructure improvements, and documentation updates. In addition to more accessibility improvements, the release fixes an issue that those with Windows servers were experiencing when producing a PDF from the staff interface. The release also includes an enhanced agent merge function and more options for configuring OAI-PMH harvesting. There is a short video demonstration of the new agent merging functionality on our YouTube channel at https://www.youtube.com/watch?v=MkOhCkUPJic. This release coincides with a substantial restructuring of the technical documentation, including an improved table of contents, led by our Technical Documentation sub-team. The site to find our static documentation is still the same: http://archivesspace.github.io/archivesspace/, but you can submit suggested edits or additions by visiting the tech-docs repository at https://github.com/archivesspace/tech-docs. Thanks very much to community members James Bullen, Blake Carver, Mark Cooper, Chris Fitzpatrick, Dave Mayo, Trevor Thornton, Mark Triggs, and Lora Woodford for their code contributions to this release. Thanks also to the contract developers we were able to hire through member funds, Alyx Rossetti and Manny Rodriguez (via LibraryHost). Thanks as always to LYRASIS Digital Technical Services for their technical support. And last, but certainly very far from least, we greatly appreciate the efforts of our Development Prioritization sub-team, Core Committers Group and Testing sub-team, as well as individual ArchivesSpace users like Miloche Kottman, Nancy Kennedy, and Cory Nimer, who identified and helped us work through particular bugs and new features that are addressed in this release. Information on upgrading to a new version of ArchivesSpace is available at http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/. If you have not yet upgraded to a recent version, we recommend going directly to 2.5.2. If you have any questions or need help upgrading - or deciding whether to upgrade - please let us know. Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [ASpaceOrgHomeMedium] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6608 bytes Desc: image001.jpg URL: From mark.custer at yale.edu Tue Jan 15 15:01:03 2019 From: mark.custer at yale.edu (Custer, Mark) Date: Tue, 15 Jan 2019 20:01:03 +0000 Subject: [Archivesspace_Users_Group] when component has multiple container instances, PDF displays only the last one In-Reply-To: References: Message-ID: Julie, It looks to me like this works as expected in a vanilla instance of the ASpace PUI. See http://test.archivesspace.org/repositories/2/resources/45 (complete aside: it's great that LYRASIS keeps this test site up, especially for testing purposes!). I just mocked up an example, and here is the output for one of the archival objects: Box 1; Folder 1 (Mixed Materials) Box 2; Folder 1-6 (Mixed Materials) The Harvard PDFs are pretty customized (and they look great and load very quickly, by the way!), so I'd expect that there might be some small issue that's just causing the last instance to be grabbed when it's creating the array of instances (either that or it could be a display issue in the view?). Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Wetherill, Julie M. Sent: Tuesday, 15 January, 2019 12:24 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] PUI: when component has multiple container instances, PDF displays only the last one All, We noticed recently that the PUI PDF is not displaying all top container data for a component. For example, a particular component has 8 physical containers defined as follows: Box: 1 (Mixed Materials) Box: 13 (Mixed Materials) Box: 19 (Mixed Materials) Box: 21 (Mixed Materials) Box: 23 (Mixed Materials) Box: 26 (Mixed Materials) Box: 27 (Mixed Materials) Box: 49 (Mixed Materials) In the PUI, all of these top containers display OK but in the PUI PDF, only the last one displays: Personal and professional correspondence, circa 1960-2004 Identifier: Box 49 Date: circa 1960-2004 The number of top containers does not matter -- this happens if there are 2 physical containers or 20; always it's the last container only that displays in the PDF. Anyone else experience this? Any solutions? Thanks. --julie Julie Wetherill Library Technology Services Harvard University -------------- next part -------------- An HTML attachment was scrubbed... URL: From Henry.Steele at tufts.edu Tue Jan 15 16:58:01 2019 From: Henry.Steele at tufts.edu (Steele, Henry) Date: Tue, 15 Jan 2019 21:58:01 +0000 Subject: [Archivesspace_Users_Group] question about digitization work order plugin In-Reply-To: References: Message-ID: Thank you for your response and sorry for the delay in testing this. This was the issue?I just didn?t know where to look for it. Much appreciated! Henry Steele Systems Librarian Tufts University Library Technology Services (617)627-5239 From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Rachel Aileen Searcy Sent: Wednesday, January 02, 2019 11:55 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] question about digitization work order plugin Hello Henry, We are successfully using the Work Order plugin with v.2.5.1. I'm not sure if this will solve your issue, but we have noticed that the plugin is only an available option in the "More" button on the menubar when a resource record is in view mode and not edit. We also have some instructions of using the plugin in our local manual here. Hope this helps! Rachel On Wed, Jan 2, 2019 at 11:39 AM Steele, Henry > wrote: Good morning, Have any of you had trouble getting the digitization work order plugin to work on ASpace 2.5.1? We are eager to use this plugin, but had trouble installing it according to the directions on https://github.com/hudmol/digitization_work_order When I installed the plugin using these directions, we still did not see the work order button in the context in which it was supposed to appear. I took the additional step of initializing the plugin, but still did not see the button. I did notice after I initialized the plugin that the plugin was continually trying to render in our log files. So I uninstalled it. Has anyone been able to successfully install the Digitization Work Order plugin on ASpace 2.5.1? And has anyone else had issues with this, and be willing to share the steps they took to address the issue? Thank you Henry Steele Systems Librarian Tufts University Library Technology Services (617)627-5239 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=LUH5OUuzh27uN9_epyrWdNjJRct32BZp_0F1syFzJCg&s=YLuYmGj-1uqeFf2BUreRTOWoHmkho7NNHRSCUh29wdA&e= -- Rachel Searcy Accessioning Archivist, Archival Collections Management New York University Libraries 212.998.2539 | rachel.searcy at nyu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Adrienne.Pruitt at tufts.edu Wed Jan 16 10:32:59 2019 From: Adrienne.Pruitt at tufts.edu (Pruitt, Adrienne) Date: Wed, 16 Jan 2019 15:32:59 +0000 Subject: [Archivesspace_Users_Group] Tufts University Digital Collections and Archives RFP for CUID-generating plug-in Message-ID: Hello, all, Tufts DCA is looking for an independent contractor familiar with ArchivesSpace to create a plug-in to auto-generate component unique identifiers at the archival object level. The request for proposals is attached. Please submit a proposal by January 31, 2019 if interested. If you have any questions, please email me and I'll be happy to get in touch and discuss it further. Thank you for your consideration. Best regards, Adrienne Pruitt | Collections Management Archivist Digital Collections and Archives Tufts University adrienne.pruitt at tufts.edu |617-627-0957 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ASpace_CUID_RFP.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 15644 bytes Desc: ASpace_CUID_RFP.docx URL: From vaddoniz at jhu.edu Wed Jan 16 13:16:56 2019 From: vaddoniz at jhu.edu (Valerie Addonizio) Date: Wed, 16 Jan 2019 18:16:56 +0000 Subject: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input In-Reply-To: References: Message-ID: <6dadc66b369c4033bff23b89dabce761@ESGMTWEX14.win.ad.jhu.edu> I know that the comment period is closed, but this seemed like a logical place to ask whether the idea of container merging functionality was considered as part of this effort (I know it is not in the scope of work, but was it considered and not selected?) and whether other institutions are in need of such functionality? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, December 20, 2018 4:16 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input Dear ArchivesSpace community: Apologies for the length of this. I?ll try to address a lot of comments, but not all! Please let me know if (as they may well do) my elaborations only elicit more questions! In general, most of these proposals are derived from facing problems of scale. Harvard has 30 repositories and over 200 users of ArchivesSpace. Others have to do with managing ?medium rare? materials? locations and containers in ArchivesSpace. (Medium-rare is a tongue-in-cheek term used to cover materials that might exist in multiple manifestations but that have archival or rare characteristics or treatment. Examples include entire libraries ingested into an archives, author?s own copies of their books, annotated books, or the record copy of serials or reports kept by institutional archives.) ? Multi-field top container indicators Some commenters wondered if the multiple fields were to accommodate child containers. To clarify, the suggestion was to facilitate parsing top container identifiers. As a few commenters have surmised, this is to cope with legacy numbers. These are especially common on medium-rare materials. One suggestion was to use a sort algorithm that would obviate the need for separated fields for data. However, because there would be is more than one algorithm necessary over the installation, such a solution would require an added field to identify the algorithm and probably a third field retain a value derived by the algorithm to be sorted alphanumerically. Thus, the direct 3-field solution seems simpler. (A 4-field suggestion was mooted in the committee as potentially more useful communally.) It does occur to me that there just might not be enough really old, really big repositories with lots of legacy identifiers in the ArchivesSpace community for the parsing of legacy numbers to be a common problem. I appreciate the recognition that a plug-in might be needed instead, but it would be worth hearing from any repositories with similar issues. ? Container and location profiles by repository We were envisioning a one-to-one profile-to-repository scenario. Due to the ArchivesSpace staff user interface requirement that one identify only a single repository at login, it is extremely easy for users to forget the impact they might have beyond their repository if they change or delete a shared record. We have already experienced mistaken mergers and deletions of agents due to the design of AS staff user interface that does not allow one to see where the record may be linked beyond their repository. For this reason, it is wise to be able to limit changes and deletions of location profiles and container profiles impact to the same chosen repository. ? Inactive As Maureen wisely intuited, inactive locations are necessary to recording a complete location history. However, there are additional use cases. When a repository is renovating, for example (as is happening now at the Schlesinger Library) the shelves in a location may be inactive for a time and become active again when the building re-opens. Other scenarios include water intrusion or other occasions when a smaller sub-set of shelves may have to become inactive until repairs are completed and tested before the shelving can again come into use. Because inactive locations are to be eliminated by default from search results, we can prevent them from overwhelming staff members? search results or sending staff to unusable locations. ? Notes in containers and locations Notes are for dedicated shelving or rehousing issues. Notes on containers may contain things like ?Label falling off? ?Acidic-needs replacing? ?Acid box replaced with acid-free box 2017-06-08? ?Not on shelf 2015-10-10?. Notes on locations may contain things like ?only use as last resort?overhead drip pan makes retrieval difficult? ?reserved for outgoing transfers until 2019-01-01?. In locations especially, we would expect the reason for a location becoming inactive might be noted. ?Made inactive because next to heating duct?do not reactivate?. ? Bibliographic record IDs in containers This data would allow for more sustainable interoperability between systems and more flexibility in workflows. Especially with medium-rare materials, the physical item?s location might need to be recorded before description is finalized, and if the description is to be created in foreign system and ingested to ArchivesSpace, hooking up the container and location will be problematic. In this scenario, a resource with initial description in a bibliographic system could be placed on an archives? shelf, and the description, once completed in the ILS, could be ingested via MARC XML ingest for example. After the resource is ingested, the ILS bibliographic record number could be searched in the containers to link the container to the resource. When an ILS system migrates, it is unlikely that the migration would maintain obsolte holding or item system numbers, but it is common to migrate with obsolete bibliographic system record numbers embedded into the new system. Should there be a need to re-migrate holdings or items from ArchivesSpace to a new ILS, bibliographic record numbers would ensure continuity. Thanks for reading! Kate From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Maureen Callahan Sent: Monday, December 17, 2018 2:09 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input A million thanks to folks from Harvard for showing leadership and investing to improve the experience of the software for all of us. I was having pleasant flashbacks to my days at Yale working through the original specifications for the container management functionality -- what it all means, what it should do, how this will improve the experience for archivists and patrons, and how to abstract all of this work to more general archival and data management principles. It's such fun, hard work! Generally speaking, it would be really helpful if user stories gave a better sense of what you want to accomplish instead of what you want to see on the screen. For some of this, I had a hard time understanding where you were coming from and I think it's possible that there are different ways of accomplishing what you've laid out. "As an W, I want to have X feature, so that Y behavior happens in Z way and lets me do my work in ABC fashion." I think that many of the goals behind this proposal are sound, but that perhaps there's too narrow an approach to solutions to meet these goals. Developers might find better ways to address the problems you've identified. 1. Hell YES there need to be easier ways to browse/sort/find locations!!!! 2. I agree that it would be useful to have the option to filter locations/container profiles by the repository they tend to belong to and that this should also be extensible so that it's easy to change this information after a move or administrative change. I sort of remember that folks at NYU talked about this as a possible outcome in the beginning of their location profile work, so it may be worth talking with them about the best way to think about it and any reasons they might have opted to not associate a repository with a location profile. 3. Lora did some nice work with search to make it possible to see the entire breadcrumb trail of where a search result comes from (the hierarchies of AOs within a resource). I'm thinking that perhaps you just want the same thing to happen when you look at the associated archival objects / accessions in a top container, rather than adding another column (resource) to the search result. 4. As someone who has had to do a lot of systems migrations that involved moving heterogenous data into more structured places, I get really nervous about a notes field for either the location or the top container. If there are common types of information that end up in this field, it may be worth considering adding more structured fields to either the location or the location profile or container or container profile so that it can be better managed, queried, and kept tidy & up-to-date. What's the scenario by which someone would actually look at this notes field? What do you want to go in there? 5. Soooooo tell me more about this inactive location idea. AFAIR, ArchivesSpace doesn't keep an audit trail of previous locations. What's the value of knowing that inactive locations exist when there aren't containers living in those locations and there's no way to see that those locations perviously held containers? 6. This may be implicit in your proposal, but it sounds like you want "repository" to be a multi-valued field in your location profiles and your container profiles. Paige boxes, for instance, will probably end up being associated with every repository. 7. I was initially a bit perplexed by the request to add additional fields for container indicators, but reading between the lines, my guess is that you want to be able to sort them properly in various circumstances. If, for instance, you have boxes 2, 2a, and 3, you want to be able to make sure that when you sort by indicator, they appear in this order. That's a great goal! But I think that you might want to state this goal instead of stating one possible outcome. I definitely DO NOT want a three-part container indicator because who knows what kind of crap people will put in those fields and they could potentially be a nightmare to clean up. Plus, it would have to account for every possible heterodox way that people design their container indicators -- or just default to Harvard's scheme, which... I mean, this is software for the whole community. Instead, I would suggest making the requirement that you want for alphanumeric characters to sort properly and clever developers can come up with the best way to do this. That seems like a more elegant solution than changing the data model. 8. YES BIBIDs!!!! But my read is that a BIBID is a control number for intellectual description, not for holdings. I know that folks are currently putting BIBIDs in user-defined fields in the resource record, and it would be great for those to have a canonical spot to help with systems integrations. I would much rather see the addition of a BIBID to the resource record, which can then be displayed with the top container by the system if desired (although why?). There's already a field for the ILS holdings ID to go with the top container. Thanks all, Maureen -- Maureen Callahan Sophia Smith Collection Archivist Smith College Special Collections Northampton, Massachusetts 01063 413 585 2981 mcallahan at smith.edu Pronouns: she/her/hers Smith College Special Collections is now housed at Young Library. Learn more about renovations to Neilson Library here. On Mon, Dec 17, 2018 at 12:42 PM Rackley, Marilyn > wrote: Dear all, Please remember to review the Harvard Library proposal for container management enhancements and submit feedback by Wednesday, December 19, 2018. See the email below for more information. In case people are not able to access the attachment, the proposal can also be accessed through this link: https://drive.google.com/open?id=14-6CFEAATfwYc1JZoAmCSD3CQVW7p3b3. We really appreciate all the comments provided so far. Best, Marilyn From: Rackley, Marilyn Sent: Monday, December 3, 2018 9:36 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Proposal for Container Management Enhancements - Call for Community Input Dear ArchivesSpace Community, The Harvard Library has been reviewing container and location management functionality in ArchivesSpace and we are proposing to make enhancements to this functionality that we would like to contribute to the core code. With these enhancements, we hope to make finding, viewing, and updating information related to containers and locations in the staff interface more efficient and effective. We have completed the draft proposal attached to this email and we are now asking for community review and feedback. The proposal includes the rationale for the changes, a list of database fields to be added, user stories describing the specific changes we are proposing, and mockups of the related updates to the staff interface. Please note that in the proposal, certain changes are designated as being a lower priority; it is possible that we may not be able to complete all the proposed changes at this time. If you have questions or feedback, please email me at marilyn_rackley at harvard.edu and/or Robin Wendler at robin_wendler at harvard.edu. We will be accepting comments through Wednesday, December 19, 2018. We look forward to receiving community input. Best, Marilyn Marilyn Rackley Aeon Project Manager and Digital Librarian Harvard Library | 617.496.4043 marilyn_rackley at harvard.edu _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltang5 at lib.msu.edu Wed Jan 16 13:18:27 2019 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Wed, 16 Jan 2019 18:18:27 +0000 Subject: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input In-Reply-To: <6dadc66b369c4033bff23b89dabce761@ESGMTWEX14.win.ad.jhu.edu> References: <6dadc66b369c4033bff23b89dabce761@ESGMTWEX14.win.ad.jhu.edu> Message-ID: I second the ability to merge containers! ? Lydia From: on behalf of Valerie Addonizio Reply-To: Archivesspace Users Group Date: Wednesday, January 16, 2019 at 1:17 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input I know that the comment period is closed, but this seemed like a logical place to ask whether the idea of container merging functionality was considered as part of this effort (I know it is not in the scope of work, but was it considered and not selected?) and whether other institutions are in need of such functionality? From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Thursday, December 20, 2018 4:16 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input Dear ArchivesSpace community: Apologies for the length of this. I?ll try to address a lot of comments, but not all! Please let me know if (as they may well do) my elaborations only elicit more questions! In general, most of these proposals are derived from facing problems of scale. Harvard has 30 repositories and over 200 users of ArchivesSpace. Others have to do with managing ?medium rare? materials? locations and containers in ArchivesSpace. (Medium-rare is a tongue-in-cheek term used to cover materials that might exist in multiple manifestations but that have archival or rare characteristics or treatment. Examples include entire libraries ingested into an archives, author?s own copies of their books, annotated books, or the record copy of serials or reports kept by institutional archives.) ? Multi-field top container indicators Some commenters wondered if the multiple fields were to accommodate child containers. To clarify, the suggestion was to facilitate parsing top container identifiers. As a few commenters have surmised, this is to cope with legacy numbers. These are especially common on medium-rare materials. One suggestion was to use a sort algorithm that would obviate the need for separated fields for data. However, because there would be is more than one algorithm necessary over the installation, such a solution would require an added field to identify the algorithm and probably a third field retain a value derived by the algorithm to be sorted alphanumerically. Thus, the direct 3-field solution seems simpler. (A 4-field suggestion was mooted in the committee as potentially more useful communally.) It does occur to me that there just might not be enough really old, really big repositories with lots of legacy identifiers in the ArchivesSpace community for the parsing of legacy numbers to be a common problem. I appreciate the recognition that a plug-in might be needed instead, but it would be worth hearing from any repositories with similar issues. ? Container and location profiles by repository We were envisioning a one-to-one profile-to-repository scenario. Due to the ArchivesSpace staff user interface requirement that one identify only a single repository at login, it is extremely easy for users to forget the impact they might have beyond their repository if they change or delete a shared record. We have already experienced mistaken mergers and deletions of agents due to the design of AS staff user interface that does not allow one to see where the record may be linked beyond their repository. For this reason, it is wise to be able to limit changes and deletions of location profiles and container profiles impact to the same chosen repository. ? Inactive As Maureen wisely intuited, inactive locations are necessary to recording a complete location history. However, there are additional use cases. When a repository is renovating, for example (as is happening now at the Schlesinger Library) the shelves in a location may be inactive for a time and become active again when the building re-opens. Other scenarios include water intrusion or other occasions when a smaller sub-set of shelves may have to become inactive until repairs are completed and tested before the shelving can again come into use. Because inactive locations are to be eliminated by default from search results, we can prevent them from overwhelming staff members? search results or sending staff to unusable locations. ? Notes in containers and locations Notes are for dedicated shelving or rehousing issues. Notes on containers may contain things like ?Label falling off? ?Acidic-needs replacing? ?Acid box replaced with acid-free box 2017-06-08? ?Not on shelf 2015-10-10?. Notes on locations may contain things like ?only use as last resort?overhead drip pan makes retrieval difficult? ?reserved for outgoing transfers until 2019-01-01?. In locations especially, we would expect the reason for a location becoming inactive might be noted. ?Made inactive because next to heating duct?do not reactivate?. ? Bibliographic record IDs in containers This data would allow for more sustainable interoperability between systems and more flexibility in workflows. Especially with medium-rare materials, the physical item?s location might need to be recorded before description is finalized, and if the description is to be created in foreign system and ingested to ArchivesSpace, hooking up the container and location will be problematic. In this scenario, a resource with initial description in a bibliographic system could be placed on an archives? shelf, and the description, once completed in the ILS, could be ingested via MARC XML ingest for example. After the resource is ingested, the ILS bibliographic record number could be searched in the containers to link the container to the resource. When an ILS system migrates, it is unlikely that the migration would maintain obsolte holding or item system numbers, but it is common to migrate with obsolete bibliographic system record numbers embedded into the new system. Should there be a need to re-migrate holdings or items from ArchivesSpace to a new ILS, bibliographic record numbers would ensure continuity. Thanks for reading! Kate From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Maureen Callahan Sent: Monday, December 17, 2018 2:09 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input A million thanks to folks from Harvard for showing leadership and investing to improve the experience of the software for all of us. I was having pleasant flashbacks to my days at Yale working through the original specifications for the container management functionality -- what it all means, what it should do, how this will improve the experience for archivists and patrons, and how to abstract all of this work to more general archival and data management principles. It's such fun, hard work! Generally speaking, it would be really helpful if user stories gave a better sense of what you want to accomplish instead of what you want to see on the screen. For some of this, I had a hard time understanding where you were coming from and I think it's possible that there are different ways of accomplishing what you've laid out. "As an W, I want to have X feature, so that Y behavior happens in Z way and lets me do my work in ABC fashion." I think that many of the goals behind this proposal are sound, but that perhaps there's too narrow an approach to solutions to meet these goals. Developers might find better ways to address the problems you've identified. 1. Hell YES there need to be easier ways to browse/sort/find locations!!!! 2. I agree that it would be useful to have the option to filter locations/container profiles by the repository they tend to belong to and that this should also be extensible so that it's easy to change this information after a move or administrative change. I sort of remember that folks at NYU talked about this as a possible outcome in the beginning of their location profile work, so it may be worth talking with them about the best way to think about it and any reasons they might have opted to not associate a repository with a location profile. 3. Lora did some nice work with search to make it possible to see the entire breadcrumb trail of where a search result comes from (the hierarchies of AOs within a resource). I'm thinking that perhaps you just want the same thing to happen when you look at the associated archival objects / accessions in a top container, rather than adding another column (resource) to the search result. 4. As someone who has had to do a lot of systems migrations that involved moving heterogenous data into more structured places, I get really nervous about a notes field for either the location or the top container. If there are common types of information that end up in this field, it may be worth considering adding more structured fields to either the location or the location profile or container or container profile so that it can be better managed, queried, and kept tidy & up-to-date. What's the scenario by which someone would actually look at this notes field? What do you want to go in there? 5. Soooooo tell me more about this inactive location idea. AFAIR, ArchivesSpace doesn't keep an audit trail of previous locations. What's the value of knowing that inactive locations exist when there aren't containers living in those locations and there's no way to see that those locations perviously held containers? 6. This may be implicit in your proposal, but it sounds like you want "repository" to be a multi-valued field in your location profiles and your container profiles. Paige boxes, for instance, will probably end up being associated with every repository. 7. I was initially a bit perplexed by the request to add additional fields for container indicators, but reading between the lines, my guess is that you want to be able to sort them properly in various circumstances. If, for instance, you have boxes 2, 2a, and 3, you want to be able to make sure that when you sort by indicator, they appear in this order. That's a great goal! But I think that you might want to state this goal instead of stating one possible outcome. I definitely DO NOT want a three-part container indicator because who knows what kind of crap people will put in those fields and they could potentially be a nightmare to clean up. Plus, it would have to account for every possible heterodox way that people design their container indicators -- or just default to Harvard's scheme, which... I mean, this is software for the whole community. Instead, I would suggest making the requirement that you want for alphanumeric characters to sort properly and clever developers can come up with the best way to do this. That seems like a more elegant solution than changing the data model. 8. YES BIBIDs!!!! But my read is that a BIBID is a control number for intellectual description, not for holdings. I know that folks are currently putting BIBIDs in user-defined fields in the resource record, and it would be great for those to have a canonical spot to help with systems integrations. I would much rather see the addition of a BIBID to the resource record, which can then be displayed with the top container by the system if desired (although why?). There's already a field for the ILS holdings ID to go with the top container. Thanks all, Maureen -- Maureen Callahan Sophia Smith Collection Archivist Smith College Special Collections Northampton, Massachusetts 01063 413 585 2981 mcallahan at smith.edu Pronouns: she/her/hers Smith College Special Collections is now housed at Young Library. Learn more about renovations to Neilson Library here. On Mon, Dec 17, 2018 at 12:42 PM Rackley, Marilyn > wrote: Dear all, Please remember to review the Harvard Library proposal for container management enhancements and submit feedback by Wednesday, December 19, 2018. See the email below for more information. In case people are not able to access the attachment, the proposal can also be accessed through this link: https://drive.google.com/open?id=14-6CFEAATfwYc1JZoAmCSD3CQVW7p3b3. We really appreciate all the comments provided so far. Best, Marilyn From: Rackley, Marilyn Sent: Monday, December 3, 2018 9:36 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Proposal for Container Management Enhancements - Call for Community Input Dear ArchivesSpace Community, The Harvard Library has been reviewing container and location management functionality in ArchivesSpace and we are proposing to make enhancements to this functionality that we would like to contribute to the core code. With these enhancements, we hope to make finding, viewing, and updating information related to containers and locations in the staff interface more efficient and effective. We have completed the draft proposal attached to this email and we are now asking for community review and feedback. The proposal includes the rationale for the changes, a list of database fields to be added, user stories describing the specific changes we are proposing, and mockups of the related updates to the staff interface. Please note that in the proposal, certain changes are designated as being a lower priority; it is possible that we may not be able to complete all the proposed changes at this time. If you have questions or feedback, please email me at marilyn_rackley at harvard.edu and/or Robin Wendler at robin_wendler at harvard.edu. We will be accepting comments through Wednesday, December 19, 2018. We look forward to receiving community input. Best, Marilyn Marilyn Rackley Aeon Project Manager and Digital Librarian Harvard Library | 617.496.4043 marilyn_rackley at harvard.edu _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From bobbi at bobbifox.net Fri Jan 18 11:04:01 2019 From: bobbi at bobbifox.net (Bobbi Fox) Date: Fri, 18 Jan 2019 11:04:01 -0500 (EST) Subject: [Archivesspace_Users_Group] New release of aspace-import-excel plugin Message-ID: This message may be of interest to those Windows users who wish to install the aspace-import-excel plugin (and possibly other plugins). The release of Bundler 2.0 (https://bundler.io/blog/2019/01/03/announcing-bundler-2.html) caused ArchivesSpace startup failure after scripts\initialize-plugins.bat aspace-import-excel was run, due to Bundler version collision. While a Pull Request has now been filed to the core ArchivesSpace repo, the new Release v2.1.18 (https://github.com/harvard-library/aspace-import-excel/releases/tag/v2.1.18) contains a temporary fix to this problem (read steps 3 and 4 of the Installation Instructions). As the problem with the initialization script is generic, installation of other plugins may also cause the same problem. If that is the case for your installation, please see https://github.com/harvard-library/aspace-import-excel/tree/master/extras for a potential solution. In all cases, if you are not starting from a clean download of the plugin, be sure to remove/delete Gemfile.lock before running the script. Cheers, Bobbi (No longer at Harvard, but still supporting aspace-import-excel) -- Bobbi Fox bobbi at bobbifox.net Database-driven and Web-enabled applications development http://www.bobbifox.net From dbutler at cals.org Sat Jan 19 15:17:50 2019 From: dbutler at cals.org (Danielle Butler) Date: Sat, 19 Jan 2019 20:17:50 +0000 Subject: [Archivesspace_Users_Group] Double Comma Dilemma Message-ID: After over a month of tweaking MySQL queries, we finally were able to get our duplicate commas eliminated. For anyone who was hoping to do the same with their legacy data, this is the query that finally worked for us UPDATE archival_object SET display_string = replace(display_string, ',,', ','); UPDATE archival_object SET title = TRIM(TRAILING ',' FROM title) where title like '%,'; Danielle Butler, CA | Archivist Butler Center for Arkansas Studies | Central Arkansas Library System www.butlercenter.org 100 Rock Street Little Rock, AR 72201 501-320-5724 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachel.searcy at nyu.edu Tue Jan 22 11:10:10 2019 From: rachel.searcy at nyu.edu (Rachel Aileen Searcy) Date: Tue, 22 Jan 2019 11:10:10 -0500 Subject: [Archivesspace_Users_Group] question about digitization work order plugin In-Reply-To: References: Message-ID: I'm so glad to hear things worked out. Best of luck using it, and please feel free to reach out if you run into any issues. Best wishes, Rachel On Tue, Jan 15, 2019 at 4:58 PM Steele, Henry wrote: > Thank you for your response and sorry for the delay in testing this. This > was the issue?I just didn?t know where to look for it. Much appreciated! > > > > Henry Steele > > Systems Librarian > > Tufts University Library Technology Services > > (617)627-5239 > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> *On Behalf Of *Rachel > Aileen Searcy > *Sent:* Wednesday, January 02, 2019 11:55 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] question about digitization > work order plugin > > > > Hello Henry, > > > > We are successfully using the Work Order plugin with v.2.5.1. I'm not sure > if this will solve your issue, but we have noticed that the plugin is only > an available option in the "More" button on the menubar when a resource > record is in view mode and not edit. We also have some instructions of > using the plugin in our local manual here > > . > > > > Hope this helps! > > Rachel > > > > On Wed, Jan 2, 2019 at 11:39 AM Steele, Henry > wrote: > > Good morning, > > > > Have any of you had trouble getting the digitization work order plugin to > work on ASpace 2.5.1? We are eager to use this plugin, but had trouble > installing it according to the directions on > https://github.com/hudmol/digitization_work_order > > When I installed the plugin using these directions, we still did not see > the work order button in the context in which it was supposed to appear. I > took the additional step of initializing the plugin, but still did not see > the button. I did notice after I initialized the plugin that the plugin > was continually trying to render in our log files. So I uninstalled it. > > > > Has anyone been able to successfully install the Digitization Work Order > plugin on ASpace 2.5.1? And has anyone else had issues with this, and be > willing to share the steps they took to address the issue? > > > > Thank you > > > > > > Henry Steele > > Systems Librarian > > Tufts University Library Technology Services > > (617)627-5239 > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=LUH5OUuzh27uN9_epyrWdNjJRct32BZp_0F1syFzJCg&s=YLuYmGj-1uqeFf2BUreRTOWoHmkho7NNHRSCUh29wdA&e= > > > > > -- > > Rachel Searcy > Accessioning Archivist, Archival Collections Management > > New York University Libraries > > 212.998.2539 | rachel.searcy at nyu.edu > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=fxq8DYcJAAmwV-7SOOT6fB-5RgegK0NIM2o_PYeu-8M&s=ZFwjj46864O953zz62Y2sE5ZPU40UKMAi1_g0AUMQZ4&e= > -- Rachel Searcy Accessioning Archivist, Archival Collections Management New York University Libraries 212.998.2539 | rachel.searcy at nyu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.custer at yale.edu Wed Jan 23 11:52:54 2019 From: mark.custer at yale.edu (Custer, Mark) Date: Wed, 23 Jan 2019 16:52:54 +0000 Subject: [Archivesspace_Users_Group] The ArchivesSpace PUI in 2019 Message-ID: Happy New Year, and happy Wednesday: I wanted to follow up on this blog post, https://archivesspace.org/archives/2534, now that Yale is using the ArchivesSpace Public Interface in production. Every once in a while, I run a few online searches to see who else is using the public interface. Back in November 2017, I had found 48 different sites (with about 9 of those sites that looked to be testing the waters). As of today, I have found ... drum roll... : * 153 total sites using the PUI * 133 using ArchivesSpace 2.1 or newer, with about 10 of those perhaps still in beta (but I've added any site that I could find with an online search) * 6 using Aeon for requesting * 4 outside of the U.S Here's a link to the document where I've been keeping track of the sites: https://docs.google.com/spreadsheets/d/1IVDp_tN6swURAZr0o-OG5pHwQiZP2oTwnp436WYaB9w/edit?usp=sharing I've updated that document so that anyone should be able to make edits, so feel free to correct any data that's there, add something, delete, etc. At Yale, in the next couple of months we are looking to make a few changes to the "Collection Organization" / single-scroll view. We'll write back to the list once we have more to share about that. I'm curious if there are any other institutions looking to make changes to general functionality in the public interface, whether in regards to searching, indexing, digital object integration, HTML or PDF displays, etc. I also just wanted to write back now that there are over 100 sites using ArchivesSpace as a public interface. That's really cool! All my best, and I look forward to seeing where folks take the PUI in the near future. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From VivianLea.Solek at Kofc.Org Thu Jan 24 08:16:45 2019 From: VivianLea.Solek at Kofc.Org (Solek, VivianLea) Date: Thu, 24 Jan 2019 13:16:45 +0000 Subject: [Archivesspace_Users_Group] I Feel the Need for Speed - Time Trials? Message-ID: Good morning all, I know our installations will all be different which will impact speed, but I'm very curious about the speed of processing that folks are experiencing. Even the most basic tasks (like clicking on a record group/collection record to open it, seems to take a bit to perform it. My system (v.2.4.1 in the process of updating to 2.5.1) is on a dedicated cloud server and I know it can be "ramped up" to generate more speed/power, I just need some stats/data to convince IT that the performance I'm seeing is "below par." Am I just being a big impatient or are other people seeing slow speeds as well? Has anyone done any "time trials" for basic processes? Has anyone done "time trials" for importing with the Harvard plug in? Many thanks for any and all insights and data shares! Best, VivianLea VivianLea Solek Archivist Knights of Columbus Supreme Council Archives Knights of Columbus Museum 1 State Street New Haven, CT 06511-6702 Phone 203 752-4578 Fax 203 865-0351 CONFIDENTIALITY NOTICE: This message and any attachments may contain confidential, proprietary or legally privileged information and is intended only for the use of the addressee or addressees named above for its intended purpose. If you are not the intended recipient of this message, this message constitutes notice that any review, retransmission, distribution, copying or other use or taking any action in reliance on the information in this message and its attachments, is prohibited. If you receive this communication in error, please immediately advise the sender by reply e-mail and delete this message and its attachments from your system without keeping a copy. Unless expressly stated in this e-mail, nothing in this message may be construed as a digital or electronic signature. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.dibella at lyrasis.org Thu Jan 24 09:40:07 2019 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Thu, 24 Jan 2019 14:40:07 +0000 Subject: [Archivesspace_Users_Group] FW: LYRASIS and DuraSpace Announce Intent to Merge Message-ID: Dear ArchivesSpace members, You may have already seen across your professional networks this morning that LYRASIS and Duraspace have announced an Intent to Merge. More information is in the press release below and in the FAQ linked from it. After a period of further investigation by the governing boards of the two organizations, the merger vote is expected to happen later this winter. While there are still a number of details to be worked out, I think the potential to have the community supported programs of LYRASIS, including ArchivesSpace, and the projects of Duraspace, including DSpace and Fedora, under one organizational umbrella is very exciting and potentially opens up a number of avenues for collaboration for our community and others. Also, please know that there are no changes imminent for ArchivesSpace itself. We?ll continue to be the strong community we?ve all built that?s guided first and foremost by your needs and interests. I hope this helps place this news in context. Though we likely won?t have all the answers at this time, please feel free to reach out if you have any questions or concerns. Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [ASpaceOrgHomeMedium] [https://mlsvc01-prod.s3.amazonaws.com/df76fc97001/ffab4da9-b360-4a2d-83f9-345b25dd09fb.jpg] [Divider Small] PRESS RELEASE Contact: Meg Blum Associate Director of Marketing & Communications 800.999.8558, ext. 2951 meg.blum at lyrasis.org LYRASIS and DuraSpace Announce Intent to Merge Atlanta, GA - January 24, 2019 - LYRASIS and DuraSpace announce their intent to merge, forming a robust new home for Community-Supported Programs and Services. LYRASIS, an innovative full-service technology and services nonprofit, and DuraSpace, which specializes in open source technologies, plan to join their world-class 501(c)(3) nonprofit teams in 2019. LYRASIS is a recognized leader in building and delivering solutions to academic and public libraries, museums, and archives. DuraSpace is a best of class team providing leadership and innovation for open technologies used by academic, scientific, cultural, technology and research communities. The combined organization will serve over 1,200 members and 3,500 organizational users across the globe. With a vision of leading community focused innovation, the increased scale and sustainability of a combined organization will provide better value and benefits to members of LYRASIS and DuraSpace. A new division of LYRASIS, the DuraSpace Community Supported Programs Division, will be formed to accelerate the pace of development for a combined 8 global open source technology communities, including DSpace, Fedora, VIVO, DuraCloud, ArchivesSpace, CollectionSpace, SimplyE public, and SimplyE academic. DuraSpace hosted services, DuraCloud, DSpaceDirect, and ArchivesDirect, will also transition to LYRASIS. In addition, a thought leadership division will be created that will combine the rich and diverse memberships of both organizations to collaboratively design and develop next generation solutions that include migration, integration, analytics, and hosting. Robert Miller, LYRASIS CEO says "The DuraSpace contribution and commitment to openness as it applies to academic communities has always stood out to me. They have built a phenomenal team, attracted a blue ribbon board, and earned the support and trust of their prestigious members. We are honored to join together with DuraSpace. Our collective memberships will benefit from increased economies of scale and having a bigger seat at the table as we work together to design and build better end-to-end solutions. We are eager to add DuraSpace's voice to ours." Erin Tripp, DuraSpace's Executive Director explains that "While DuraSpace is in its strongest financial position ever, the synergies of joining our two organizations will allow us to leverage a larger organization and member base to amplify our voice. Our missions and memberships are already converging. Taking this next step to merge our organizations will provide access to staff and investment dollars to accelerate the pace of global, community-supported open source software development. Together, we can steward viable alternatives to proprietary products." Following a brief period to complete due diligence, the Boards of the two non-profit organizations will hold a merger vote. If affirmed, the merger will proceed at a pace to ensure minimal disruption to members and customers. In the proposed merger between DuraSpace and LYRASIS, LYRASIS will remain the parent organization and legal entity. The DuraSpace brand, stewardship of DSpace, Fedora, and VIVO, and fiscal sponsorship supports will transition to the new DuraSpace Community Supported Programs Division of LYRASIS. DuraSpace hosted services (DuraCloud, DSpaceDirect, and ArchivesDirect) will also transition to LYRASIS. For more information, please see the Frequently Asked Questions documentation. About LYRASIS LYRASIS, a nonprofit membership organization of more than 1,000 libraries, museums, and archives supports enduring access to our shared academic, scientific and cultural heritage through leadership in open technologies, content services, digital solutions and collaboration with archives, libraries, museums and knowledge communities worldwide. STAY CONNECTED [Like us on Facebook] [Follow us on Twitter] [http://img.constantcontact.com/letters/images/1101116784221/PM_B2BC_BottomShadow.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 6608 bytes Desc: image003.jpg URL: From gordon_daines at byu.edu Thu Jan 24 10:35:56 2019 From: gordon_daines at byu.edu (Gordon Daines) Date: Thu, 24 Jan 2019 15:35:56 +0000 Subject: [Archivesspace_Users_Group] Nominations Requested for ArchivesSpace Technical Advisory Council Message-ID: <278df88fda074bde8ed6e2dfcc4ee23b@MB7.byu.local> Colleagues, The ArchivesSpace Governance Board is seeking nominations to fill three (3) vacancies on the ArchivesSpace Technical Advisory Council (TAC). Nominees should be presently employed at an ArchivesSpace member institution in any membership level (the vacancies being filled are from the very large and very small levels). They may also be employees of a current Registered Service Provider (see: http://archivesspace.org/registered-service-providers/current-rsps/). Nominations may be made only by ArchivesSpace member representatives. All other staff of ArchivesSpace member organizations may submit nominations through their Member Representative. Member representatives are encouraged to nominate persons from their institution or from other institutions who are experienced with some of the activities assigned to TAC and who are capable of participating on a regular basis throughout their term of service. Self-nominations are also welcome. Nominations must be received by 9:00 p.m. EDT Friday, April 19, 2019. The Nominations Committee will review all nominations and recommend appointments to the Governance Board for approval. TAC (http://www.archivesspace.org/technicaladvisory) is a critical part of the ArchivesSpace community, having responsibility for providing technical guidance to individuals or organizations contributing to application development, to the User Advisory Council, and to the ArchivesSpace Governance Board. TAC's current activities include: * developing a community of code committers, including helping to establish guidelines for contributing code and reviewing contributions, * reviewing enhancements and priorities and testing in collaboration with the User Advisory Council, * providing support for migrating data to ArchivesSpace from other systems and support for importing and exporting data such as EAD, MARCXML, CSV * documenting and assisting with resolving bugs identified in the application, * identifying integration points for ArchivesSpace with other systems (e.g. digital asset management systems, patron and request management systems, etc.), creating resources to assist the community with integration work and, for specific integrations, developing technical requirements, and * updating technical documentation. Sub-teams will be established within TAC to address the areas identified above, as well other activity areas identified subsequently. Nominees must have sufficient knowledge of application development methods, architectures and coding practices to participate in and lead some of the identified activities. Nominees with experience in open source projects, developing web applications (particularly using Ruby on Rails and Sinatra), software testing, or interest in those areas, are especially welcome. The anticipated time commitment for each appointee is expected to be two hours per week on average. The term of service for these appointments will be July 1, 2019-June 30, 2021. We expect making up to three (3) appointments, and each new appointee will be eligible to have her/his appointment renewed for an additional two-year term, i.e., July 1, 2021-June 30, 2023. To nominate a candidate for the ArchivesSpace Technical Advisory Council, please identify the person and her/his organization in the form below, indicate the areas of activity to which the nominee is prepared to contribute. Again, self-nominations are also welcome. Return the completed form via email to ArchivesSpace Program Manager (Christine DiBella at christine.dibella at lyrasis.org), who will collect nominations on behalf of the ArchivesSpace Nominating Committee. All nominations must be submitted by 9:00 p.m. EDT Friday, April 19, 2019. Thank you for your participation in this important process, which is an essential part of our identity and operations as a community-based software organization. Respectfully, Gordon Daines Brigham Young University Chair, Nominating Committee On behalf of Nominating Committee members: Gordon Daines, Brigham Young University, Chair, and Governance Board member Ashley Knox, University of North Carolina Wilmington,Chair of User Advisory Council Max Eckard, University of Michigan, Chair of Technical Advisory Council Caitlin Wells, University of Michigan, representing very large membership level Jay Trask, University of Northern Colorado, representing large membership level Carolyn Runyon, University of Tennessee Chattanooga, representing medium membership level Suzanne Stasiulitis, Pennsylvania State Archives, representing small membership level Jonathan Lawler, Southeastern Baptist Theological Seminary, representing very small membership level Christine DiBella, (ArchivesSpace Program Manager), ex officio ________________________________ Nominee's Name: ______________________________________________ Nominee's Organization: ______________________________________________ Indicate all areas to which the nominee might contribute: ___Managing/endorsing/eliciting code contributions ___Bug fixes ___Technical documentation ___Program architecture and integrations with other software ___Migration issues, including import/exports and API design and implementation ___Application testing _________________________ J. Gordon Daines III Supervisor of Reference Services Department Chair L. Tom Perry Special Collections Brigham Young University Provo, UT 84602 801-422-5821 gordon_daines at byu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon_daines at byu.edu Thu Jan 24 10:40:09 2019 From: gordon_daines at byu.edu (Gordon Daines) Date: Thu, 24 Jan 2019 15:40:09 +0000 Subject: [Archivesspace_Users_Group] Nominations Requested for ArchivesSpace User Advisory Council Message-ID: Colleagues, The ArchivesSpace Governance Board is seeking nominations to fill three (3) vacancies on the ArchivesSpace User Advisory Council (UAC). Nominees should be presently employed at an ArchivesSpace member institution in any membership category (the vacancies being filled were represented by the very large and medium levels) (please refer to the categorized member list at: http://archivesspace.org/community/whos-using-archivesspace/). Nominations may be made only by ArchivesSpace member representatives. All other staff of ArchivesSpace member organizations may submit nominations through their Member Representative. Member representatives are encouraged to nominate persons from their institution or from other institutions who are experienced with some of the activities projected for UAC and who are capable of participating on a regular basis throughout their term of service. Self-nominations are also welcome. Nominations must be received by 9:00 p.m. EDT Friday, April 19th, 2019. The Nominations Committee will review all nominations and recommend appointments to the Governance Board for approval. UAC (http://www.archivesspace.org/usersadvisory) is a critical part of the ArchivesSpace community, serving as a communication conduit between ArchivesSpace governance groups and ArchivesSpace users. It is also the group that implements and contributes to ArchivesSpace user services. Some of the activities UAC is currently engaged in are: * liaising with national and regional archives organizations; * soliciting, suggesting, gathering requirements for, and prioritizing enhancements to the ArchivesSpace application; * maintaining and updating user documentation, as needed, of the ArchivesSpace application; * developing and providing training to users; and * advising the Governance Board and LYRASIS on the design and delivery of user services, including but not limited to help desk support, training, and presentation of documentation. Sub-groups will be established within UAC to address the areas identified above, as well as other activities identified subsequently. Nominees will be appointed to UAC according to their ability to participate in and lead some of the activities mentioned above. The anticipated time commitment for each appointee is expected to be two hours per week on average. The term of service will be July 1, 2019-June 30, 2021. Each new appointee will be eligible to have her/his appointment renewed for an additional two-year term, i.e., July 1, 2021-June 30, 2023. To nominate a candidate for the ArchivesSpace Technical Advisory Council, please identify the person and her/his organization in the form below, indicate the areas of activity to which the nominee is prepared to contribute. Again, self nominations are welcome. Return the completed form via email to ArchivesSpace Program Manager (Christine DiBella at christine.dibella at lyrasis.org), who will collect nominations on behalf of the ArchivesSpace Nominating Committee. All nominations must be submitted by 9:00 p.m. EDT Friday, April 19th, 2019. Thank you for your participation in this important process, which is an essential part of our identity and operations as a community-based software organization. Respectfully, Gordon Daines Brigham Young University Chair, Nominating Committee On behalf of Nominating Committee members: Gordon Daines, Brigham Young University, Chair, and Governance Board member Ashley Knox, University of North Carolina Wilmington,Chair of User Advisory Council Max Eckard, University of Michigan, Chair of Technical Advisory Council Caitlin Wells, University of Michigan, representing very large membership level Jay Trask, University of Northern Colorado, representing large membership level Carolyn Runyon, University of Tennessee Chattanooga, representing medium membership level Suzanne Stasiulitis, Pennsylvania State Archives, representing small membership level Jonathan Lawler, Southeastern Baptist Theological Seminary, representing very small membership level Christine DiBella, (ArchivesSpace Program Manager), ex officio ________________________________ Nominee's Name: ______________________________________________ Nominee's Organization: ______________________________________________ Indicate all areas to which the nominee might contribute: ___Documentation ___Liaising with archives organizations. Please indicate the organizations: _____________________ ___New features, functional or technical specifications ___Training, design ___Training, provision ___ Usability testing ___User/Help support _________________________ J. Gordon Daines III Supervisor of Reference Services Department Chair L. Tom Perry Special Collections Brigham Young University Provo, UT 84602 801-422-5821 gordon_daines at byu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From buschedw at msu.edu Thu Jan 24 12:53:28 2019 From: buschedw at msu.edu (Busch, Edward) Date: Thu, 24 Jan 2019 17:53:28 +0000 Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF Message-ID: I'm not sure if there is an open ticket on this or not; a quick search didn't reveal anything directly. Agents with Thai names and diacritics look correct in ASpace but when generated into a PDF finding aid, do not. They end up like: Saph# K#ns#ks# h#ng Ch#t I can create a ticket if needed. Ed Busch, MLIS Electronic Records Archivist Michigan State University Archives Conrad Hall 943 Conrad Road, Room 101 East Lansing, MI 48824 517-884-6438 buschedw at msu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From PGalligan at rockarch.org Thu Jan 24 13:09:19 2019 From: PGalligan at rockarch.org (Galligan, Patrick) Date: Thu, 24 Jan 2019 18:09:19 +0000 Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF In-Reply-To: References: Message-ID: Ed, I believe there have been other issues regarding diacritics in general, but we can always merge tickets if you submit another. This is very bad. -Patrick Galligan Digital Archivist Rockefeller Archive Center From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Busch, Edward Sent: Thursday, January 24, 2019 12:53 PM To: 'archivesspace_users_group at lyralists.lyrasis.org' Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF I'm not sure if there is an open ticket on this or not; a quick search didn't reveal anything directly. Agents with Thai names and diacritics look correct in ASpace but when generated into a PDF finding aid, do not. They end up like: Saph# K#ns#ks# h#ng Ch#t I can create a ticket if needed. Ed Busch, MLIS Electronic Records Archivist Michigan State University Archives Conrad Hall 943 Conrad Road, Room 101 East Lansing, MI 48824 517-884-6438 buschedw at msu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltang5 at lib.msu.edu Thu Jan 24 13:14:37 2019 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Thu, 24 Jan 2019 18:14:37 +0000 Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF Message-ID: <813059FC-E3F0-4339-9429-06A42ABDEA1B@lib.msu.edu> Hi Ed, The related ticket that I see is here: https://archivesspace.atlassian.net/browse/ANW-294?jql=text%20~%20%22pdf%20diacritics%22 It is ?closed ? completed? It doesn?t look like Marcella?s ticket was ever created. Ed, please go ahead and create a new ticket! Thanks for pointing this out! Lydia ? on behalf of Dev. Pri. From: on behalf of "Busch, Edward" Reply-To: Archivesspace Users Group Date: Thursday, January 24, 2019 at 12:53 PM To: "'archivesspace_users_group at lyralists.lyrasis.org'" Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF I?m not sure if there is an open ticket on this or not; a quick search didn?t reveal anything directly. Agents with Thai names and diacritics look correct in ASpace but when generated into a PDF finding aid, do not. They end up like: Saph# K#ns#ks# h#ng Ch#t I can create a ticket if needed. Ed Busch, MLIS Electronic Records Archivist Michigan State University Archives Conrad Hall 943 Conrad Road, Room 101 East Lansing, MI 48824 517-884-6438 buschedw at msu.edu From jazairi at bc.edu Thu Jan 24 13:45:38 2019 From: jazairi at bc.edu (Adam Jazairi) Date: Thu, 24 Jan 2019 13:45:38 -0500 Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF In-Reply-To: <813059FC-E3F0-4339-9429-06A42ABDEA1B@lib.msu.edu> References: <813059FC-E3F0-4339-9429-06A42ABDEA1B@lib.msu.edu> Message-ID: Hi Ed, This is a problem with the fonts included in the version of Apache FOP that ASpace uses. There's an open ticket here: https://archivesspace.atlassian.net/browse/ANW-473 We've encountered the same issue when we attempt to generate a PDF finding aid containing Irish or Japanese diacritics. An interim solution we've been using is to export the EAD, then run Saxon on it to generate an FO file, then run FOP 1.0 with the appropriate font on the FO file to generate the PDF. It's a bit cumbersome, but it's worked for us so far. Here's the FOP conf file that we use: https://github.com/BCDigLib/bc-aspace/blob/master/fop/fop.xconf The only catch is that you'll need a font that supports the unicode characters you need. In your case, it looks like Arial v2.95 would work: https://en.wikipedia.org/wiki/Arial#TrueType/OpenType_version_history Hope this helps. Adam On Thu, Jan 24, 2019 at 1:14 PM Tang, Lydia wrote: > Hi Ed, > The related ticket that I see is here: > https://archivesspace.atlassian.net/browse/ANW-294?jql=text%20~%20%22pdf%20diacritics%22 > It is ?closed ? completed? It doesn?t look like Marcella?s ticket was ever > created. Ed, please go ahead and create a new ticket! Thanks for pointing > this out! > Lydia ? on behalf of Dev. Pri. > > From: on behalf > of "Busch, Edward" > Reply-To: Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > Date: Thursday, January 24, 2019 at 12:53 PM > To: "'archivesspace_users_group at lyralists.lyrasis.org'" < > archivesspace_users_group at lyralists.lyrasis.org> > Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF > > I?m not sure if there is an open ticket on this or not; a quick search > didn?t reveal anything directly. > > Agents with Thai names and diacritics look correct in ASpace but when > generated into a PDF finding aid, do not. They end up like: > Saph# K#ns#ks# h#ng Ch#t > > I can create a ticket if needed. > > Ed Busch, MLIS > Electronic Records Archivist > Michigan State University Archives > Conrad Hall > 943 Conrad Road, Room 101 > East Lansing, MI 48824 > 517-884-6438 > buschedw at msu.edu > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- Adam Jazairi Digital Repository Services Boston College Libraries (617) 552-1404 adam.jazairi at bc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.custer at yale.edu Thu Jan 24 14:45:41 2019 From: mark.custer at yale.edu (Custer, Mark) Date: Thu, 24 Jan 2019 19:45:41 +0000 Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF In-Reply-To: References: <813059FC-E3F0-4339-9429-06A42ABDEA1B@lib.msu.edu>, Message-ID: Exactly what Adam said! To add to that, there's no single font (or even font family) that has glyphs for every single Unicode character. The Noto font family has aims to do that "in the future," however, and it already includes a lot of fonts as part of its family (including Noto Sans Thai and Noto Serif Thai) that one would have to install. See https://www.google.com/get/noto/ In any event, ASpace should certainly be updated so that the staff-side PDFs have more coverage by default (but I also think there needs to be a decision about whether the platform supports both EAD to PDF transformations as well as HTML/CSS to PDF transformations), but the out-of-the-box approach is never going to cover everything. Perhaps a good next step would be to update Apache FOP (since the version used by ASpace is pretty out of date right now), package ASpace with a few of the Noto fonts so that those could be used in place of the base-14 fonts (e.g. Times is used by FOP for its "any" font), and update the transformation process. Even then, though, I believe that you would actually need to embed the fonts into the PDF file, since if you don't, there's no guarantee that whomever opens the PDF file has that font on their computer, so you might still wind up with character replacements. But the PDF standard allows you to do just that. Last, EAD3 added language and script data attributes for precisely this sort of reason (e.g. if you have one paragraph in English, and another in Arabic, you'd need some reliable method to determine when to switch fonts and the direction of the text). ASpace doesn't have that ability yet (although I'm pretty sure that AtoM does), but it would be a great addition (as well as a necessary one, for this sort of reason) addition. Here's a note from EAD3s tag library: "Support for multilingual description was addressed by adding @lang and @script attributes to all non-empty elements in EAD3, making it possible to explicitly state what language or script is used therein. Additionally, some elements were modified to allow them to repeat where previously they did not, thus enabling the inclusion of the same data in multiple languages." So, lots to do, but all worth doing. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Adam Jazairi Sent: Thursday, January 24, 2019 1:45:38 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Thai names in Finding Aid PDF Hi Ed, This is a problem with the fonts included in the version of Apache FOP that ASpace uses. There's an open ticket here: https://archivesspace.atlassian.net/browse/ANW-473 We've encountered the same issue when we attempt to generate a PDF finding aid containing Irish or Japanese diacritics. An interim solution we've been using is to export the EAD, then run Saxon on it to generate an FO file, then run FOP 1.0 with the appropriate font on the FO file to generate the PDF. It's a bit cumbersome, but it's worked for us so far. Here's the FOP conf file that we use: https://github.com/BCDigLib/bc-aspace/blob/master/fop/fop.xconf The only catch is that you'll need a font that supports the unicode characters you need. In your case, it looks like Arial v2.95 would work: https://en.wikipedia.org/wiki/Arial#TrueType/OpenType_version_history Hope this helps. Adam On Thu, Jan 24, 2019 at 1:14 PM Tang, Lydia > wrote: Hi Ed, The related ticket that I see is here: https://archivesspace.atlassian.net/browse/ANW-294?jql=text%20~%20%22pdf%20diacritics%22 It is ?closed ? completed? It doesn?t look like Marcella?s ticket was ever created. Ed, please go ahead and create a new ticket! Thanks for pointing this out! Lydia ? on behalf of Dev. Pri. From: > on behalf of "Busch, Edward" > Reply-To: Archivesspace Users Group > Date: Thursday, January 24, 2019 at 12:53 PM To: "'archivesspace_users_group at lyralists.lyrasis.org'" > Subject: [Archivesspace_Users_Group] Thai names in Finding Aid PDF I?m not sure if there is an open ticket on this or not; a quick search didn?t reveal anything directly. Agents with Thai names and diacritics look correct in ASpace but when generated into a PDF finding aid, do not. They end up like: Saph# K#ns#ks# h#ng Ch#t I can create a ticket if needed. Ed Busch, MLIS Electronic Records Archivist Michigan State University Archives Conrad Hall 943 Conrad Road, Room 101 East Lansing, MI 48824 517-884-6438 buschedw at msu.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Adam Jazairi Digital Repository Services Boston College Libraries (617) 552-1404 adam.jazairi at bc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurie.arp at lyrasis.org Fri Jan 25 08:33:17 2019 From: laurie.arp at lyrasis.org (Laurie Arp) Date: Fri, 25 Jan 2019 13:33:17 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace Community Discussion Invitation Message-ID: Greetings, The ArchivesSpace Governance Board would like to invite members to participate in a Community Discussion about strategic directions for ArchivesSpace! At the last ArchivesSpace Governance Board meeting, we discussed options for doing more tactical strategic planning that incorporates member feedback. We'd now like to gather input from the membership via a real-time discussion on strategic topics that are of interest to you. We'd love to have members from as many of our different membership levels and types of organizations as possible represented. This is not a presentation but a facilitated discussion designed to better understand the high-level interests and concerns of our members. Examples of areas to consider could include integrations, engagement strategies or future proofing. Board members Gordon Daines (Brigham Young University), Kat Stefko (Bowdoin College) and Robert Miller (LYRASIS) will join the discussion. Community Discussion When: Tuesday, February 26, 2019 Time: 3:00 p.m. - 4:00 p.m. EST (Noon. - 1:00 p.m. PST) Where: https://zoom.us/j/123795032 Dial by your location +1 646 876 9923 US (New York) +1 669 900 6833 US (San Jose) Meeting ID: 123 795 032 No registration is required, though the session is limited to the first 100 participants. Please feel free to bring together your colleagues to participate as a group. This discussion will be recorded and available for viewing at a later date. Please note: We are using Zoom Video Communications to host this discussion. If this is your first time using Zoom, please join this Test meeting to make sure you are all set up: https://zoom.us/test We hope to see you there! Laurie Gemmill Arp Director, Collections Services & Community Supported Software laurie.arp at lyrasis.org 800.999.8558 x 2908 laurie.gemmill1 Skype [cid:image002.png at 01D39036.091DD4A0] Applications for the 2019 Catalyst Fund opened January 7! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7845 bytes Desc: image001.png URL: From Chelsee.Boehm at ishs.idaho.gov Sat Jan 26 17:27:50 2019 From: Chelsee.Boehm at ishs.idaho.gov (Chelsee Boehm) Date: Sat, 26 Jan 2019 22:27:50 +0000 Subject: [Archivesspace_Users_Group] Resource records not showing up Message-ID: Hi all, I searched the List's Archives to see if I could find an answer to this question, and I didn't see anything, so I hope I am not asking pretty obvious or repeat question. I am currently working on linking related Accession and Resource records before we launch our public site. I was searching for a few specific Resource records, and could not find any of them. I checked back on my import jobs, and I can see where I successfully imported those records, but when I search for them they've done some sort of magic disappearing act! I managed to find one of the Resource records from the troubled batch, as it had earlier been linked to it to an Accession record. I can click into that Resource record, and everything looks fine, but when I search for it, it still does not show up. Does anyone have any ideas on what the problem might be? Thanks everyone! [cid:image001.png at 01D3C83A.88E20AD0] Chelsee Boehm, MA Archivist Technician (208) 514-2318 2205 Old Penitentiary Rd. Boise, ID 83712 HISTORY.IDAHO.GOV Preserving the past, enriching the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10797 bytes Desc: image001.png URL: From blake.carver at lyrasis.org Sun Jan 27 08:16:37 2019 From: blake.carver at lyrasis.org (Blake Carver) Date: Sun, 27 Jan 2019 13:16:37 +0000 Subject: [Archivesspace_Users_Group] Resource records not showing up In-Reply-To: References: Message-ID: Most likely a problem with your index. I would force a full reindex and see if that fixes things. Stop ArchivesSpace Delete everything in the /data/ directory. (yes, everything. no, you don't need anything inside there. yes, you need the actual directory.) Start ArchivesSpace Wait until it finishes up indexing and see if the records are back. That takes somewhere between 3 minutes and 3 days depending on how many records you have and how powerful of a server you're running on there. If they're not back, look at the file in /logs/ archivesspace.out and see if you can find any lines with ERROR or also FATAL, those lines should provide clues. This location assumes you're running on Linux, logs seem to end up different places on Windows sometimes. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Chelsee Boehm Sent: Saturday, January 26, 2019 5:27:50 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Resource records not showing up Hi all, I searched the List?s Archives to see if I could find an answer to this question, and I didn?t see anything, so I hope I am not asking pretty obvious or repeat question. I am currently working on linking related Accession and Resource records before we launch our public site. I was searching for a few specific Resource records, and could not find any of them. I checked back on my import jobs, and I can see where I successfully imported those records, but when I search for them they?ve done some sort of magic disappearing act! I managed to find one of the Resource records from the troubled batch, as it had earlier been linked to it to an Accession record. I can click into that Resource record, and everything looks fine, but when I search for it, it still does not show up. Does anyone have any ideas on what the problem might be? Thanks everyone! [cid:image001.png at 01D3C83A.88E20AD0] Chelsee Boehm, MA Archivist Technician (208) 514-2318 2205 Old Penitentiary Rd. Boise, ID 83712 HISTORY.IDAHO.GOV Preserving the past, enriching the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10797 bytes Desc: image001.png URL: From mark.custer at yale.edu Sun Jan 27 14:20:43 2019 From: mark.custer at yale.edu (Custer, Mark) Date: Sun, 27 Jan 2019 19:20:43 +0000 Subject: [Archivesspace_Users_Group] Resource records not showing up In-Reply-To: References: Message-ID: Chelsee, In case you don't have immediate access to the server to force a full re-index, check out the Background Job pages (or Import Job pages, depending on which version of ASpace you're using). Even though the job can have a status of "Completed," it's possible that no records were ingested. If records were ingested, though, then you should be able to click on any of the links directly on the background job page, under the New and Modified Records heading (e.g. http://test.archivesspace.org/staff/jobs/1992, log in with user=admin and password=admin, and scroll to the bottom of that page). After doing that, try editing the top-level Resource record and re-saving it (just a meaningless edit will do, like adding and then removing a space to the Resource's title). I don't know why, but we have at least one finding aid that generally requires us to edit it like this before it gets re-indexed. I think you'll need to follow Blake's advice to re-index everything, but you might also be able to get some of those newly-ingested finding aids to be indexed by opening them in the staff interface and re-saving them one at a time. I hope that helps, Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Blake Carver Sent: Sunday, 27 January, 2019 8:17 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Resource records not showing up Most likely a problem with your index. I would force a full reindex and see if that fixes things. Stop ArchivesSpace Delete everything in the /data/ directory. (yes, everything. no, you don't need anything inside there. yes, you need the actual directory.) Start ArchivesSpace Wait until it finishes up indexing and see if the records are back. That takes somewhere between 3 minutes and 3 days depending on how many records you have and how powerful of a server you're running on there. If they're not back, look at the file in /logs/ archivesspace.out and see if you can find any lines with ERROR or also FATAL, those lines should provide clues. This location assumes you're running on Linux, logs seem to end up different places on Windows sometimes. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Chelsee Boehm > Sent: Saturday, January 26, 2019 5:27:50 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Resource records not showing up Hi all, I searched the List's Archives to see if I could find an answer to this question, and I didn't see anything, so I hope I am not asking pretty obvious or repeat question. I am currently working on linking related Accession and Resource records before we launch our public site. I was searching for a few specific Resource records, and could not find any of them. I checked back on my import jobs, and I can see where I successfully imported those records, but when I search for them they've done some sort of magic disappearing act! I managed to find one of the Resource records from the troubled batch, as it had earlier been linked to it to an Accession record. I can click into that Resource record, and everything looks fine, but when I search for it, it still does not show up. Does anyone have any ideas on what the problem might be? Thanks everyone! [cid:image001.png at 01D3C83A.88E20AD0] Chelsee Boehm, MA Archivist Technician (208) 514-2318 2205 Old Penitentiary Rd. Boise, ID 83712 HISTORY.IDAHO.GOV Preserving the past, enriching the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10797 bytes Desc: image001.png URL: From blake.carver at lyrasis.org Sun Jan 27 16:34:39 2019 From: blake.carver at lyrasis.org (Blake Carver) Date: Sun, 27 Jan 2019 21:34:39 +0000 Subject: [Archivesspace_Users_Group] Resource records not showing up In-Reply-To: References: , Message-ID: >> but you might also be able to get some of those newly-ingested finding aids to be indexed by opening them in the staff interface and re-saving them one at a time. Oh yeah, that too! Which is good if there's only a few. One other thing that reminded me of, if you update all the mtimes on your records that kinda does the same thing. I've had to do it a few times that way for various reasons I made a copy and paste gist here that I use: https://gist.github.com/Blake-/538c8d7cc7ade39efc372a3e3e190873 This is one of those "nothing else seems to work" things though. Or maybe "I only have access to MySQL" things. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Custer, Mark Sent: Sunday, January 27, 2019 2:20:43 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Resource records not showing up Chelsee, In case you don?t have immediate access to the server to force a full re-index, check out the Background Job pages (or Import Job pages, depending on which version of ASpace you?re using). Even though the job can have a status of ?Completed,? it?s possible that no records were ingested. If records were ingested, though, then you should be able to click on any of the links directly on the background job page, under the New and Modified Records heading (e.g. http://test.archivesspace.org/staff/jobs/1992, log in with user=admin and password=admin, and scroll to the bottom of that page). After doing that, try editing the top-level Resource record and re-saving it (just a meaningless edit will do, like adding and then removing a space to the Resource?s title). I don?t know why, but we have at least one finding aid that generally requires us to edit it like this before it gets re-indexed. I think you?ll need to follow Blake?s advice to re-index everything, but you might also be able to get some of those newly-ingested finding aids to be indexed by opening them in the staff interface and re-saving them one at a time. I hope that helps, Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Blake Carver Sent: Sunday, 27 January, 2019 8:17 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Resource records not showing up Most likely a problem with your index. I would force a full reindex and see if that fixes things. Stop ArchivesSpace Delete everything in the /data/ directory. (yes, everything. no, you don't need anything inside there. yes, you need the actual directory.) Start ArchivesSpace Wait until it finishes up indexing and see if the records are back. That takes somewhere between 3 minutes and 3 days depending on how many records you have and how powerful of a server you're running on there. If they're not back, look at the file in /logs/ archivesspace.out and see if you can find any lines with ERROR or also FATAL, those lines should provide clues. This location assumes you're running on Linux, logs seem to end up different places on Windows sometimes. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Chelsee Boehm > Sent: Saturday, January 26, 2019 5:27:50 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Resource records not showing up Hi all, I searched the List?s Archives to see if I could find an answer to this question, and I didn?t see anything, so I hope I am not asking pretty obvious or repeat question. I am currently working on linking related Accession and Resource records before we launch our public site. I was searching for a few specific Resource records, and could not find any of them. I checked back on my import jobs, and I can see where I successfully imported those records, but when I search for them they?ve done some sort of magic disappearing act! I managed to find one of the Resource records from the troubled batch, as it had earlier been linked to it to an Accession record. I can click into that Resource record, and everything looks fine, but when I search for it, it still does not show up. Does anyone have any ideas on what the problem might be? Thanks everyone! [cid:image001.png at 01D3C83A.88E20AD0] Chelsee Boehm, MA Archivist Technician (208) 514-2318 2205 Old Penitentiary Rd. Boise, ID 83712 HISTORY.IDAHO.GOV Preserving the past, enriching the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10797 bytes Desc: image001.png URL: From lsaegert at tsl.texas.gov Mon Jan 28 12:53:26 2019 From: lsaegert at tsl.texas.gov (Laura Saegert) Date: Mon, 28 Jan 2019 17:53:26 +0000 Subject: [Archivesspace_Users_Group] transferring assessments Message-ID: I need to transfer an assessment from an accession record to a resource, within the same repository. I did not find instructions for that in the AS online manual, is there a way to do this? Thanks, Laura Saegert Assistant Director for Archives Archives and Information Services Division Texas State Library and Archives Commission P.O. Box 12927 Austin, Texas 78711-2927 lsaegert at tsl.texas.gov 512-463-5500 www.tsl.texas.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From RFLAHIVE at iaia.edu Tue Jan 29 12:16:36 2019 From: RFLAHIVE at iaia.edu (Ryan Flahive) Date: Tue, 29 Jan 2019 17:16:36 +0000 Subject: [Archivesspace_Users_Group] Import Data Errors Message-ID: <810777CE-C0BB-46AE-A07D-1CB207004FF4@iaia.edu> Morning Folks, I?m new to this group as my ArchiveSpace server was just set up a couple days ago. Due to circumstances too lengthy to describe here, I am manually building this database from exported EAD files from my Archivist?s Toolkit system. My first few imports were successful, but then a few failed due to these errors: Date: one or more required (or enter a Title) Title: must not be an empty string (or enter a Date) These records have titles and dates. Can anyone shed some light on how I resolve this issue? Feel free to email me with suggestions! Thanks! Ryan S. Flahive Archivist INSTITUTE OF AMERICAN INDIAN ARTS 83 Avan Nu Po Road, Santa Fe, NM 87508 P. 505-424-2392 E. rflahive at iaia.edu www.iaia.edu IAIA's Mission: To empower creativity and leadership in Native arts and cultures through higher education, lifelong learning, and outreach. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Tue Jan 29 12:36:21 2019 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 29 Jan 2019 17:36:21 +0000 Subject: [Archivesspace_Users_Group] Import Data Errors In-Reply-To: <810777CE-C0BB-46AE-A07D-1CB207004FF4@iaia.edu> References: <810777CE-C0BB-46AE-A07D-1CB207004FF4@iaia.edu> Message-ID: I believe all of the dsc components must have either a unittitle or unitdate. > On Jan 29, 2019, at 12:16 PM, Ryan Flahive wrote: > > Morning Folks, > > I?m new to this group as my ArchiveSpace server was just set up a couple days ago. > > Due to circumstances too lengthy to describe here, I am manually building this database from exported EAD files from my Archivist?s Toolkit system. My first few imports were successful, but then a few failed due to these errors: > > Date: one or more required (or enter a Title) > Title: must not be an empty string (or enter a Date) > > These records have titles and dates. Can anyone shed some light on how I resolve this issue? Feel free to email me with suggestions! > > Thanks! > > Ryan S. Flahive > Archivist > INSTITUTE OF AMERICAN INDIAN ARTS > 83 Avan Nu Po Road, Santa Fe, NM 87508 > P. 505-424-2392 > E. rflahive at iaia.edu > www.iaia.edu > > IAIA's Mission: To empower creativity and leadership in Native arts and cultures through higher education, lifelong learning, and outreach. > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3598 bytes Desc: not available URL: From kiddm at vcu.edu Tue Jan 29 13:33:41 2019 From: kiddm at vcu.edu (Margaret Kidd) Date: Tue, 29 Jan 2019 13:33:41 -0500 Subject: [Archivesspace_Users_Group] Import Data Errors In-Reply-To: <810777CE-C0BB-46AE-A07D-1CB207004FF4@iaia.edu> References: <810777CE-C0BB-46AE-A07D-1CB207004FF4@iaia.edu> Message-ID: It is probably an empty date tag in the components list. Check to see if it something like this: My stuff This is technically an empty tag since there isn't a date after "inclusive." AS does not like empty tags. So you will either need to add title, date, etc. or delete the empty tags. If you have a lot of finding aids you can do batch validation to see which ones need to be fixed (see the blog post Validation Scenarios by Yale for help). I did this with my finding aids and then manually fixed the problems I found. If I'd known how to write a script to do it for me I would have, but it wasn't so many that I couldn't do it manually. Others might have some suggestions on automating the process. Hope this helps! ------------------------------ Margaret Turman Kidd Access and Electronic Records Archivist, Special Collections & Archives VCU Libraries | Tompkins-McCaw Library for the Health Sciences Virginia Commonwealth University 509 N. 12th Street / Box 980582, Richmond, VA 23298-0582 (804) 828-3152 kiddm at vcu.edu Pronouns: she/her On Tue, Jan 29, 2019 at 12:16 PM Ryan Flahive wrote: > Morning Folks, > > > > I?m new to this group as my ArchiveSpace server was just set up a couple > days ago. > > > > Due to circumstances too lengthy to describe here, I am manually building > this database from exported EAD files from my Archivist?s Toolkit system. > My first few imports were successful, but then a few failed due to these > errors: > > > > Date: one or more required (or enter a Title) > > Title: must not be an empty string (or enter a Date) > > > > These records have titles and dates. Can anyone shed some light on how I > resolve this issue? Feel free to email me with suggestions! > > > > Thanks! > > > > *Ryan S. Flahive* > > Archivist > > *INSTITUTE OF AMERICAN INDIAN ARTS* > > 83 Avan Nu Po Road, Santa Fe, NM 87508 > > P. 505-424-2392 > > E. *rflahive at iaia.edu * > > *www.iaia.edu * > > > > IAIA's Mission: To empower creativity and leadership in Native arts and > cultures through higher education, lifelong learning, and outreach. > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chelsee.Boehm at ishs.idaho.gov Tue Jan 29 13:38:04 2019 From: Chelsee.Boehm at ishs.idaho.gov (Chelsee Boehm) Date: Tue, 29 Jan 2019 18:38:04 +0000 Subject: [Archivesspace_Users_Group] Resource records not showing up In-Reply-To: References: , Message-ID: Hi everyone, I don't have access to the server to do a full re-index, but I was able to access those troubled resource records through the Background Jobs page. Making edits does make them appear in the search. Thank you to everyone who helped me on this! I appreciate it very much! Chelsee From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Blake Carver Sent: Sunday, January 27, 2019 2:35 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Resource records not showing up >> but you might also be able to get some of those newly-ingested finding aids to be indexed by opening them in the staff interface and re-saving them one at a time. Oh yeah, that too! Which is good if there's only a few. One other thing that reminded me of, if you update all the mtimes on your records that kinda does the same thing. I've had to do it a few times that way for various reasons I made a copy and paste gist here that I use: https://gist.github.com/Blake-/538c8d7cc7ade39efc372a3e3e190873 This is one of those "nothing else seems to work" things though. Or maybe "I only have access to MySQL" things. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Custer, Mark Sent: Sunday, January 27, 2019 2:20:43 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Resource records not showing up Chelsee, In case you don't have immediate access to the server to force a full re-index, check out the Background Job pages (or Import Job pages, depending on which version of ASpace you're using). Even though the job can have a status of "Completed," it's possible that no records were ingested. If records were ingested, though, then you should be able to click on any of the links directly on the background job page, under the New and Modified Records heading (e.g. http://test.archivesspace.org/staff/jobs/1992, log in with user=admin and password=admin, and scroll to the bottom of that page). After doing that, try editing the top-level Resource record and re-saving it (just a meaningless edit will do, like adding and then removing a space to the Resource's title). I don't know why, but we have at least one finding aid that generally requires us to edit it like this before it gets re-indexed. I think you'll need to follow Blake's advice to re-index everything, but you might also be able to get some of those newly-ingested finding aids to be indexed by opening them in the staff interface and re-saving them one at a time. I hope that helps, Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Blake Carver Sent: Sunday, 27 January, 2019 8:17 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Resource records not showing up Most likely a problem with your index. I would force a full reindex and see if that fixes things. Stop ArchivesSpace Delete everything in the /data/ directory. (yes, everything. no, you don't need anything inside there. yes, you need the actual directory.) Start ArchivesSpace Wait until it finishes up indexing and see if the records are back. That takes somewhere between 3 minutes and 3 days depending on how many records you have and how powerful of a server you're running on there. If they're not back, look at the file in /logs/ archivesspace.out and see if you can find any lines with ERROR or also FATAL, those lines should provide clues. This location assumes you're running on Linux, logs seem to end up different places on Windows sometimes. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Chelsee Boehm > Sent: Saturday, January 26, 2019 5:27:50 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Resource records not showing up Hi all, I searched the List's Archives to see if I could find an answer to this question, and I didn't see anything, so I hope I am not asking pretty obvious or repeat question. I am currently working on linking related Accession and Resource records before we launch our public site. I was searching for a few specific Resource records, and could not find any of them. I checked back on my import jobs, and I can see where I successfully imported those records, but when I search for them they've done some sort of magic disappearing act! I managed to find one of the Resource records from the troubled batch, as it had earlier been linked to it to an Accession record. I can click into that Resource record, and everything looks fine, but when I search for it, it still does not show up. Does anyone have any ideas on what the problem might be? Thanks everyone! [cid:image001.png at 01D3C83A.88E20AD0] Chelsee Boehm, MA Archivist Technician (208) 514-2318 2205 Old Penitentiary Rd. Boise, ID 83712 HISTORY.IDAHO.GOV Preserving the past, enriching the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10797 bytes Desc: image001.png URL: From kate_bowers at harvard.edu Tue Jan 29 14:21:24 2019 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Tue, 29 Jan 2019 19:21:24 +0000 Subject: [Archivesspace_Users_Group] Import Data Errors In-Reply-To: <810777CE-C0BB-46AE-A07D-1CB207004FF4@iaia.edu> References: <810777CE-C0BB-46AE-A07D-1CB207004FF4@iaia.edu> Message-ID: EAD has fewer contraints than ArchivesSpace. Those error messages are not terribly helpful. At the very end of this article (before the end notes) is a list of the constraints in AS that will throw an error if your EAD does not comply: https://journal.code4lib.org/articles/12239 I think the messages are coming from what we have as number 26 on the list ?Absence of both unittitle and unitdate at a subordinate level causes import to fail?. Our solution was to grab data via a script from the parent . You may have few enough to do this by hand. So, for example, we had s that contained only or only or only . These were all valid EAD but not acceptable to ArchivesSpace. Below is a bit more digestible (but still Harvard-centric and definitely a working document) list of these issues and the practice that is needed going forward to ensure AS will ingest EAD. Your error messages are coming from the 3rd thing listed under . Element category Practice going forward Reason Reason category Schema Use the canonical EAD schema, not the Harvard modified schema AS expects data that conforms to the canonical schema. Schema Do not use frontmatter This will be added by EAD export from AS Former practice no longer needed Always include Required for saving in AS, will ingest, but annoying to users who edit resources. Do not use descgrp This will not load to AS Practice not supported by AS EAD ingest Do not embed within Roundtripped EAD from AS will be invalid Practice not supported by AS EAD export Always include an @level attribute value on all s. If using @level="otherlevel" always include an @otherlevel value. without a @level will ingest as "otherlevel" but lack @otherlevel value New attribute data required All components should have ; in cases where formerly archivsts might have used only , the parent 's unittitle is often a good choice The component-centered display in ArchivesSpace makes any component lacking a the context provided by text vague and cryptic, hampering recognition and interpretation of the component. New content strongly recommended All components must have either a or a EAD lacking this data will not load to AS New content required should stand alone, not be embedded within Will load twice into AS Practice not supported by AS EAD ingest must include type and label attributes, cannot describe multiple containers in one container element, and should not include type of container as part of content. AS accommodates container numbers and types, but does not accommodate note-like container information. In addition, AS creates "top container" records based on EAD ingest. These are linked records. Placing a range of boxes, for example, in a single container element creates incorrect data about containers. Data model in AS is different from EAD Do not encode in <controlaccess> Finding aid will load, but data will be lost. Use <subject> or other appropriate element Practice not supported by AS EAD ingest <corpname> @role ??? Disappears on ingest <creation> <creation> statement should include ingest information Include ingest to AS in your creation statement, e.g. "Created in Oxygen on 2016-11-18; ingested to AS on 2016-12-12" New content required <dao> One Digital Object per Archival Object Automated linking to objects in the DRS is based on the ref_id of the Archival Object, which is used as an owner supplied name in DRS. New limit <dao> Supply a title for digital archival objects; use <unittitle> of parent <c> xlink at title attribute is required by AS ingest New attribute data required <dao> <daodesc>??? Disappears on ingest? <dao> To achieve thumbnails, <daogrp> must be coded thus: ???? ? <extent> Collection-level <physdesc><extent> is required EAD lacking this data will not load to AS New content required <extent> Do not encode mixed content within <physdesc> Finding aid will ingest, but content will be lost. Specifically, if a <physdesc> has some child elements, any text that is not inside a child element will be left behind during ingest. An entirely plain-text <physdesc> is OK. New limit <extent> <extent> must begin with a number EAD with non-numerical extent will not load to AS New limit <extref> <extref> should be used more sparingly, consider using only if @href values link Harvard-managed links Link rot (has nothing to do with AS), except that during migration, links became noticeable and rot was there New recommendation <index> Do not encode nested indexes Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <index> Instead of creating <index>es, add controlaccess terms to components This allows search and retrieval of all components across the whole corpus rather than in one finding aid. Better data model for discovery and retrieval <indexentry> Do not encode nested indexentries Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <list> Do not encode nested lists Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <list> Do not use <defitem> or <list type="deflist"> Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <name> Avoid <name> Import may succeed, but data will be lacking from AS, use a more specific <persname>, <corpname>, or <geogname> Practice not supported by AS EAD ingest <namegrp> Do not encode namegrps Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <note> Do not use <note> anywhere; where legal, use <odd> preferably with <head> Import may succeed, but <note> will be lacking from AS; <head> in <odd> provides a better label than "generic note" New limit <origination> Do not encode origination as mixed content; all data must be within child elements Import may succeed, but data will be lacking from AS. Any content not within the child elements <corpname>, <famname>, or <persname> will not go into AS. It will not stop ingest, but data will be lost. Attribute values will also be lost. Practice not supported by AS EAD ingest; new constraint <persname> @role ??? Disappears on ingest? <processinfo> Finding aid must have a <processinfo> with <head>Aleph ID</head> and content containing the Aleph record number for the collection Indexing of finding aids in Primo and connecting them with bibliographic records depends on this exact specification being carried out successfully. New content required <ref> <ref>???? Internal refs lost on ingest <table> Do not use <table> Longstanding practice to be continued Existing limit <unitdate> Always supply value for @normal attribute in <unitdate> This had formerly been accomplished through OASIS loader New attribute data required <unitdate> Supply certainty="approximate" value for dates if approximate New attribute data required <unitdate> Do not use @startYear @endYear These were Harvard-specific attributes and will get lost in AS ingest New limit <unitdate> Do not nest <unitdate> within <unittitle> These are un-nested during AS ingest. Starting with nested <unitdate>s in EAD will give archivists an unrealistic idea of what the description will convey when un-nested. New limit <unitdate> Use separate <unitdate> elements for bulk and inclusive dates, and indicate these differences by setting the @type attribute accordingly AS cannot ingest two dates from one <unitdate> tag. New limit <unitdate> Indicate approximation in <unitdate>s by setting the attribute @certainty="approximate" Circa or approximate as part of the date expression are not machine-actionable New recommendation <unitdate> If there are no dates, do not use <unitdate> at all Older practice often resulted in the following, which cannot be ingested by AS <unitdate>undated</unitdate>. Consider whether "undated" belongs as part of the title. New limit <unitid> Collection-level <unitid> is required EAD lacking this data will not load to AS New content required <unitid> Use only one <unitid>. If more than one <unitid> is needed, either place them in separate <c> elements or concatenate all into a single <unitid> AS will ingest the finding aid, but content will be lost. All but one of the <unitid>s will be lacking. New limit <unittitle> Collection-level <unittitle> is required EAD lacking this data will not load to AS New content required <unittitle> Use only one <unittitle>. If more than one <unittitle> is needed, either place them in separate <c> elements or concatenate all into a single <unittitle> AS will ingest the finding aid, but content will be lost. All but one of the <unittitle>s will be lacking. New limit <extent> All <extent> measurement types must come from same list used in AS; if non-canonical measurements are needed, consider a separate <physdesc> Non-matches will have two results: calculations based on measurements will be inaccurrate, AS extent drop-down will become cluttered New limit <bibliography> Avoid <bibliography>? <ptrgrp> avoid <ptrgrp>??? From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Ryan Flahive Sent: Tuesday, January 29, 2019 12:17 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Import Data Errors Morning Folks, I?m new to this group as my ArchiveSpace server was just set up a couple days ago. Due to circumstances too lengthy to describe here, I am manually building this database from exported EAD files from my Archivist?s Toolkit system. My first few imports were successful, but then a few failed due to these errors: Date: one or more required (or enter a Title) Title: must not be an empty string (or enter a Date) These records have titles and dates. Can anyone shed some light on how I resolve this issue? Feel free to email me with suggestions! Thanks! Ryan S. Flahive Archivist INSTITUTE OF AMERICAN INDIAN ARTS 83 Avan Nu Po Road, Santa Fe, NM 87508 P. 505-424-2392 E. rflahive at iaia.edu<mailto:rflahive at iaia.edu> www.iaia.edu<http://www.iaia.edu> IAIA's Mission: To empower creativity and leadership in Native arts and cultures through higher education, lifelong learning, and outreach. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190129/746e8231/attachment.html> From dave_mayo at harvard.edu Tue Jan 29 14:56:46 2019 From: dave_mayo at harvard.edu (Mayo, Dave) Date: Tue, 29 Jan 2019 19:56:46 +0000 Subject: [Archivesspace_Users_Group] Import Data Errors Message-ID: <B367C2BD-8A44-428D-82B8-0FFB9489CC58@harvard.edu> What Kate said, and also: for anything that we figured out during our migration, you can check individual EAD files with somewhat better error reporting by putting them through https://eadchecker.lib.harvard.edu/ -- Dave Mayo (he/him) Senior Digital Library Software Engineer Harvard University > HUIT > LTS From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of "Bowers, Kate A." <kate_bowers at harvard.edu> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Date: Tuesday, January 29, 2019 at 2:21 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Import Data Errors EAD has fewer contraints than ArchivesSpace. Those error messages are not terribly helpful. At the very end of this article (before the end notes) is a list of the constraints in AS that will throw an error if your EAD does not comply: https://journal.code4lib.org/articles/12239 I think the messages are coming from what we have as number 26 on the list ?Absence of both unittitle and unitdate at a subordinate level causes import to fail?. Our solution was to grab data via a script from the parent <did>. You may have few enough to do this by hand. So, for example, we had <did>s that contained only <head> or only <note> or only <united>. These were all valid EAD but not acceptable to ArchivesSpace. Below is a bit more digestible (but still Harvard-centric and definitely a working document) list of these issues and the practice that is needed going forward to ensure AS will ingest EAD. Your error messages are coming from the 3rd thing listed under <c>. Element category Practice going forward Reason Reason category Schema Use the canonical EAD schema, not the Harvard modified schema AS expects data that conforms to the canonical schema. Schema <frontmatter> Do not use frontmatter This will be added by EAD export from AS Former practice no longer needed <language> Always include Required for saving in AS, will ingest, but annoying to users who edit resources. <descgrp> Do not use descgrp This will not load to AS Practice not supported by AS EAD ingest <arrangement> Do not embed <arrangement> within <scopecontent> Roundtripped EAD from AS will be invalid Practice not supported by AS EAD export <c> Always include an @level attribute value on all <c>s. If using @level="otherlevel" always include an @otherlevel value. <c> without a @level will ingest as "otherlevel" but lack @otherlevel value New attribute data required <c> All components should have <unittitle>; in cases where formerly archivsts might have used only <unitdate>, the parent <c>'s unittitle is often a good choice The component-centered display in ArchivesSpace makes any component lacking a the context provided by <unittitle> text vague and cryptic, hampering recognition and interpretation of the component. New content strongly recommended <c> All components must have either a <unitdate> or a <unittitle> EAD lacking this data will not load to AS New content required <chronlist> <chronlist> should stand alone, not be embedded within <bioghist> Will load twice into AS Practice not supported by AS EAD ingest <container> <container> must include type and label attributes, cannot describe multiple containers in one container element, and should not include type of container as part of content. AS accommodates container numbers and types, but does not accommodate note-like container information. In addition, AS creates "top container" records based on EAD ingest. These are linked records. Placing a range of boxes, for example, in a single container element creates incorrect data about containers. Data model in AS is different from EAD <controlaccess> Do not encode <title> in <controlaccess> Finding aid will load, but data will be lost. Use <subject> or other appropriate element Practice not supported by AS EAD ingest <corpname> @role ??? Disappears on ingest <creation> <creation> statement should include ingest information Include ingest to AS in your creation statement, e.g. "Created in Oxygen on 2016-11-18; ingested to AS on 2016-12-12" New content required <dao> One Digital Object per Archival Object Automated linking to objects in the DRS is based on the ref_id of the Archival Object, which is used as an owner supplied name in DRS. New limit <dao> Supply a title for digital archival objects; use <unittitle> of parent <c> xlink at title attribute is required by AS ingest New attribute data required <dao> <daodesc>??? Disappears on ingest? <dao> To achieve thumbnails, <daogrp> must be coded thus: ???? ? <extent> Collection-level <physdesc><extent> is required EAD lacking this data will not load to AS New content required <extent> Do not encode mixed content within <physdesc> Finding aid will ingest, but content will be lost. Specifically, if a <physdesc> has some child elements, any text that is not inside a child element will be left behind during ingest. An entirely plain-text <physdesc> is OK. New limit <extent> <extent> must begin with a number EAD with non-numerical extent will not load to AS New limit <extref> <extref> should be used more sparingly, consider using only if @href values link Harvard-managed links Link rot (has nothing to do with AS), except that during migration, links became noticeable and rot was there New recommendation <index> Do not encode nested indexes Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <index> Instead of creating <index>es, add controlaccess terms to components This allows search and retrieval of all components across the whole corpus rather than in one finding aid. Better data model for discovery and retrieval <indexentry> Do not encode nested indexentries Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <list> Do not encode nested lists Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <list> Do not use <defitem> or <list type="deflist"> Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <name> Avoid <name> Import may succeed, but data will be lacking from AS, use a more specific <persname>, <corpname>, or <geogname> Practice not supported by AS EAD ingest <namegrp> Do not encode namegrps Import may succeed, but data will be lacking from AS Practice not supported by AS EAD ingest <note> Do not use <note> anywhere; where legal, use <odd> preferably with <head> Import may succeed, but <note> will be lacking from AS; <head> in <odd> provides a better label than "generic note" New limit <origination> Do not encode origination as mixed content; all data must be within child elements Import may succeed, but data will be lacking from AS. Any content not within the child elements <corpname>, <famname>, or <persname> will not go into AS. It will not stop ingest, but data will be lost. Attribute values will also be lost. Practice not supported by AS EAD ingest; new constraint <persname> @role ??? Disappears on ingest? <processinfo> Finding aid must have a <processinfo> with <head>Aleph ID</head> and content containing the Aleph record number for the collection Indexing of finding aids in Primo and connecting them with bibliographic records depends on this exact specification being carried out successfully. New content required <ref> <ref>???? Internal refs lost on ingest <table> Do not use <table> Longstanding practice to be continued Existing limit <unitdate> Always supply value for @normal attribute in <unitdate> This had formerly been accomplished through OASIS loader New attribute data required <unitdate> Supply certainty="approximate" value for dates if approximate New attribute data required <unitdate> Do not use @startYear @endYear These were Harvard-specific attributes and will get lost in AS ingest New limit <unitdate> Do not nest <unitdate> within <unittitle> These are un-nested during AS ingest. Starting with nested <unitdate>s in EAD will give archivists an unrealistic idea of what the description will convey when un-nested. New limit <unitdate> Use separate <unitdate> elements for bulk and inclusive dates, and indicate these differences by setting the @type attribute accordingly AS cannot ingest two dates from one <unitdate> tag. New limit <unitdate> Indicate approximation in <unitdate>s by setting the attribute @certainty="approximate" Circa or approximate as part of the date expression are not machine-actionable New recommendation <unitdate> If there are no dates, do not use <unitdate> at all Older practice often resulted in the following, which cannot be ingested by AS <unitdate>undated</unitdate>. Consider whether "undated" belongs as part of the title. New limit <unitid> Collection-level <unitid> is required EAD lacking this data will not load to AS New content required <unitid> Use only one <unitid>. If more than one <unitid> is needed, either place them in separate <c> elements or concatenate all into a single <unitid> AS will ingest the finding aid, but content will be lost. All but one of the <unitid>s will be lacking. New limit <unittitle> Collection-level <unittitle> is required EAD lacking this data will not load to AS New content required <unittitle> Use only one <unittitle>. If more than one <unittitle> is needed, either place them in separate <c> elements or concatenate all into a single <unittitle> AS will ingest the finding aid, but content will be lost. All but one of the <unittitle>s will be lacking. New limit <extent> All <extent> measurement types must come from same list used in AS; if non-canonical measurements are needed, consider a separate <physdesc> Non-matches will have two results: calculations based on measurements will be inaccurrate, AS extent drop-down will become cluttered New limit <bibliography> Avoid <bibliography>? <ptrgrp> avoid <ptrgrp>??? From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Ryan Flahive Sent: Tuesday, January 29, 2019 12:17 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Import Data Errors Morning Folks, I?m new to this group as my ArchiveSpace server was just set up a couple days ago. Due to circumstances too lengthy to describe here, I am manually building this database from exported EAD files from my Archivist?s Toolkit system. My first few imports were successful, but then a few failed due to these errors: Date: one or more required (or enter a Title) Title: must not be an empty string (or enter a Date) These records have titles and dates. Can anyone shed some light on how I resolve this issue? Feel free to email me with suggestions! Thanks! Ryan S. Flahive Archivist INSTITUTE OF AMERICAN INDIAN ARTS 83 Avan Nu Po Road, Santa Fe, NM 87508 P. 505-424-2392 E. rflahive at iaia.edu<mailto:rflahive at iaia.edu> www.iaia.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iaia.edu&d=DwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=fH35Xl6mSv68OjLsoAwAZDlklqJhOwX-2PPeWpbhSC8&s=Z10mbeEMqOqFa159iOZ1PoaKVADFt6gU-1tqkD0jV3A&e=> IAIA's Mission: To empower creativity and leadership in Native arts and cultures through higher education, lifelong learning, and outreach. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190129/a253f23b/attachment.html> From harmeyna at purdue.edu Wed Jan 30 10:55:04 2019 From: harmeyna at purdue.edu (Harmeyer, Neal A) Date: Wed, 30 Jan 2019 15:55:04 +0000 Subject: [Archivesspace_Users_Group] Request Button and Spam Message-ID: <3938e65d178e4cb3bcc3c821672b1476@wppexc02.purdue.lcl> Hello all, We are experiencing an increase in spam messages sent through the Request feature on our ArchivesSpace instance. We set up the mail configuration according to the documentation. Has anyone else had this spam issue, and if so, is there a local solution that you are willing to share? Has anyone added a captcha to the Request form or anything along those lines? Thanks for any suggestions, Neal -- Neal Harmeyer Digital Archivist Purdue University Archives and Special Collections harmeyna at purdue.edu<mailto:harmeyna at purdue.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190130/011f62cf/attachment.html> From christine.dibella at lyrasis.org Wed Jan 30 13:36:54 2019 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Wed, 30 Jan 2019 18:36:54 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace Update - January 2019 Message-ID: <BN6PR2201MB118891F29C640CC8DD044518F1900@BN6PR2201MB1188.namprd22.prod.outlook.com> [ASpaceOrgHome.jpg] January 2019 Update Welcome to the first ArchivesSpace update of 2019! We're looking forward to another great year, and especially excited about our first ever Online Forum. Read on for more news! Development ArchivesSpace v2.5.2 was released earlier this month. You can download it at https://github.com/archivesspace/archivesspace/releases/tag/v2.5.2. This release contains program-led and community pull requests that provide feature enhancements, bug fixes, infrastructure improvements, and documentation updates. In addition to more accessibility improvements, the release fixes an issue that those with Windows servers were experiencing when producing a PDF from the staff interface. The release also includes an enhanced agent merge function and more options for configuring OAI-PMH harvesting. There is a short video demonstration of the new agent merging functionality on our YouTube channel at https://www.youtube.com/watch?v=MkOhCkUPJic. This release coincides with a substantial restructuring of the technical documentation, including an improved table of contents, led by our Technical Documentation sub-team. The site to find our static documentation is still the same: http://archivesspace.github.io/archivesspace/, but you can submit suggested edits or additions by visiting the tech-docs repository at https://github.com/archivesspace/tech-docs. Thanks very much to community members James Bullen, Blake Carver, Mark Cooper, Chris Fitzpatrick, Dave Mayo, Trevor Thornton, Mark Triggs, and Lora Woodford for their code contributions to this release. Thanks also to the contract developers we were able to hire through member funds, Alyx Rossetti and Manny Rodriguez (via LibraryHost). Thanks as always to LYRASIS Digital Technical Services for their technical support. And last, but certainly very far from least, we greatly appreciate the efforts of our Development Prioritization sub-team, Core Committers Group and Testing sub-team, as well as individual ArchivesSpace users like Miloche Kottman, Nancy Kennedy, and Cory Nimer, who identified and helped us work through particular bugs and new features that are addressed in this release. Information on upgrading to a new version of ArchivesSpace is available at http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/. If you have not yet upgraded to a recent version, we recommend going directly to 2.5.2. ArchivesSpace is always interested in more development help. Depending on your interest and availability, we have lots of suggestions for projects small and big that developers and tech-savvy archivists of all experience levels could help with to make ArchivesSpace better for everyone. If you're interested in writing code and helping with ArchivesSpace development, or if you know someone who might be, please contact Program Manager Christine Di Bella (christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>) or Tech Lead Laney McGlohon (laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org>) for more details. Community Discussion About Strategic Directions - February 26 At the last ArchivesSpace Governance Board meeting, we discussed options for doing more tactical strategic planning that incorporates member feedback. We'd now like to gather input from the membership via a real-time discussion on strategic topics that are of interest to you. We'd love to have members from as many of our different membership levels and types of organizations as possible represented. This is not a presentation but a facilitated discussion designed to better understand the high-level interests and concerns of our members. Examples of areas to consider could include integrations, engagement strategies or future proofing. Board members Gordon Daines (Brigham Young University), Kat Stefko (Bowdoin College) and Robert Miller (LYRASIS) will join the discussion, which will be moderated by Laurie Gemmill Arp, Director of Collections Services & Community Supported Software, at LYRASIS. When: Tuesday, February 26, 2019 Time: 3:00 p.m. - 4:00 p.m. EST (noon - 1:00 p.m. PST) Where: https://zoom.us/j/123795032 Dial by your location +1 646 876 9923 US (New York) +1 669 900 6833 US (San Jose) Meeting ID: 123 795 032 No registration is required, though the session is limited to the first 100 participants. Please feel free to bring together your colleagues to participate as a group. This discussion will be recorded and available for viewing at a later date. ArchivesSpace Online Forum - March 18 Mark your calendars for our first ever Online Forum, beginning at March 18 at 5:00 p.m. UTC*. Our first event to specifically aim to span the many time zones of our community, this 11-hour ArchivesSpace extravaganza will be divided into three blocks of 3 hours each, with a 1-hour break between each block. As with our in-person forums, our Online Forum will include a mix of opportunities to share and learn from each other about many different aspects of ArchivesSpace. As our first online forum, this event will be an experiment and a chance for us to try out some different ways for our community to engage and interact. We anticipate recording many parts of the forum, but for it to be a success we will also need as many live participants as possible. We encourage you to dip in and out of the live program as you much as you can. You will no doubt "meet" a different set of colleagues each time. We are now accepting both session proposals and ideas for topics via our online form at https://goo.gl/forms/olTRwsxOkGwkXJAs2. We highly encourage you to submit your proposals and ideas by February 18 so that we can get the program squared away as early as possible. Information about how to register for the event will be released closer to March. Anyone who uses ArchivesSpace or is interested in ArchivesSpace is welcome to attend. A special thanks to our international working group, featuring ArchivesSpace users from Brooklyn to Bangalore. Feel free to reach out to any of us with ideas and questions: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/802127927/ASpace+Online+Forum+2019. We're looking forward to a great event, with your help! * That means Honolulu 7 am | Los Angeles 10 am | Dallas noon | New York 1 pm | London 5 pm | Bangalore 10:30 pm | Auckland 6 am (following morning) - see https://goo.gl/sCKvA9 to find your local time LYRASIS and Duraspace announce Intent to Merge LYRASIS, the organizational home for ArchivesSpace, and Duraspace recently announced an Intent to Merge<http://lyrasisnow.org/press-release-lyrasis-and-duraspace-announce-intent-to-merge/>. After a period of further investigation by the governing boards of the two organizations, the merger vote is expected to happen later this winter. While there are still a number of details to be worked out, the potential to have the community supported programs of LYRASIS, including ArchivesSpace, and the projects of Duraspace, including DSpace and Fedora, under one organizational umbrella is very exciting and opens up a number of possibilities for collaboration for our community and others. There are no changes imminent for ArchivesSpace itself, but we look forward to participating in this process and the opportunities it brings. LYRASIS and Duraspace expect to hold some town hall-style webinars in February, but also feel free to reach out to Christine Di Bella (christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>) if you have comments or questions. Membership Update We are excited to welcome our newest members to our community! Our new members since December 20 include: * Alaska Division of Libraries, Archives and Museums * Davis County Clerk/Auditor (Farmington, Utah) * Interlochen Center for the Arts (Interlochen, Michigan) * New Mexico Military Institute * Queensland State Archives As of January 30, we have 371 General members, 19 Educational Program members, and 3 Registered Service Providers. If you are interested in your institution becoming a member of ArchivesSpace, please email us at ArchivesSpaceHome at lyrasis.org<mailto:ArchivesSpaceHome at lyrasis.org> for more information. ________________________________ ArchivesSpace monthly updates provide news about ArchivesSpace community and program activities and are sent to our member listservs, the ArchivesSpace Google Group, and SAA's Collection Management Tools Section listserv, as well as being posted on the ArchivesSpace website. Please feel free to share this update with people you know who have an interest in ArchivesSpace but may not be on one of these lists. Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> 800.999.8558 x2905 678-235-2905 cdibella13 (Skype) [ASpaceOrgHomeMedium] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190130/9f13d9d2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 20006 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190130/9f13d9d2/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 6608 bytes Desc: image004.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190130/9f13d9d2/attachment-0001.jpg>