From trthorn2 at ncsu.edu Tue Jan 2 11:48:58 2018 From: trthorn2 at ncsu.edu (Trevor Thornton) Date: Tue, 2 Jan 2018 11:48:58 -0500 Subject: [Archivesspace_Users_Group] Error when saving records in 2.2.2 Message-ID: Hi everybody- Since we updated to 2.2.2 we have had an inconsistently recurring issue when creating and editing records. When the user saves the record they are immediately given an error message indicating that the record did not save (sometimes the message is "Failed to save your changes", sometimes it's "Record not found"). But upon refreshing the page it turns out that the changes actually did save, and there are no errors logged on the backend, which makes me think it's just a frontend issue. This has happened so far with resource, archival object, subject and agent records. It doesn't happen every time, which is kind of good, but it makes it impossible to reliably reproduce the problem - the same set of actions that triggered the error once will not necessarily trigger it a second time. This makes it hard to diagnose what's going on or to report the issue in a helpful way. Has anyone else noticed anything like this? -Trevor -- Trevor Thornton Applications Developer, Digital Library Initiatives North Carolina State University Libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.custer at yale.edu Tue Jan 2 13:35:47 2018 From: mark.custer at yale.edu (Custer, Mark) Date: Tue, 2 Jan 2018 18:35:47 +0000 Subject: [Archivesspace_Users_Group] Error when saving records in 2.2.2 In-Reply-To: References: Message-ID: Hi, Trevor: I don?t think that we?ve seen this particular issue, but we did have another issue when upgrading from 1.5.x to 2.x which I?ll mention here in case it?s of any use in your circumstance. For us, the issue was simply a plugin. In our case, whenever we saved a record after upgrading, the user was forced to re-load the page in order for the entire page to refresh correctly so that the user could get on with their work. The problem was that the plugin overrode some new code in the 2.x version of the application, specifically the Enable Reorder Mode button that?s now part of the Edit mode, which resulted in a javascript error whenever a new archival object was added. Once we updated the plugin to be 2.x compliant, though, everything behaved as expected again with the plugin turned on. Do you have any plugins in your instance that could be causing this issue? Just based on that experience, I?d want to rule out that possibility first. Mark From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Trevor Thornton Sent: Tuesday, 02 January, 2018 11:49 AM To: Archivesspace Subject: [Archivesspace_Users_Group] Error when saving records in 2.2.2 Hi everybody- Since we updated to 2.2.2 we have had an inconsistently recurring issue when creating and editing records. When the user saves the record they are immediately given an error message indicating that the record did not save (sometimes the message is "Failed to save your changes", sometimes it's "Record not found"). But upon refreshing the page it turns out that the changes actually did save, and there are no errors logged on the backend, which makes me think it's just a frontend issue. This has happened so far with resource, archival object, subject and agent records. It doesn't happen every time, which is kind of good, but it makes it impossible to reliably reproduce the problem - the same set of actions that triggered the error once will not necessarily trigger it a second time. This makes it hard to diagnose what's going on or to report the issue in a helpful way. Has anyone else noticed anything like this? -Trevor -- Trevor Thornton Applications Developer, Digital Library Initiatives North Carolina State University Libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From trthorn2 at ncsu.edu Tue Jan 2 13:42:15 2018 From: trthorn2 at ncsu.edu (Trevor Thornton) Date: Tue, 2 Jan 2018 13:42:15 -0500 Subject: [Archivesspace_Users_Group] Error when saving records in 2.2.2 In-Reply-To: References: Message-ID: Thanks, Mark. I don't *think* any of the plugins we're using touch that part of the view, but it could be doing something similar in another include. I'll check it out. On Tue, Jan 2, 2018 at 1:35 PM, Custer, Mark wrote: > Hi, Trevor: > > > > I don?t think that we?ve seen this particular issue, but we did have > another issue when upgrading from 1.5.x to 2.x which I?ll mention here in > case it?s of any use in your circumstance. For us, the issue was simply a > plugin. In our case, whenever we saved a record after upgrading, the user > was forced to re-load the page in order for the entire page to refresh > correctly so that the user could get on with their work. The problem was > that the plugin overrode some new code in the 2.x version of the > application, specifically the Enable Reorder Mode button that?s now part of > the Edit mode, which resulted in a javascript error whenever a new archival > object was added. Once we updated the plugin to be 2.x compliant, though, > everything behaved as expected again with the plugin turned on. > > > > Do you have any plugins in your instance that could be causing this > issue? Just based on that experience, I?d want to rule out that > possibility first. > > > > Mark > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Trevor > Thornton > *Sent:* Tuesday, 02 January, 2018 11:49 AM > *To:* Archivesspace > *Subject:* [Archivesspace_Users_Group] Error when saving records in 2.2.2 > > > > Hi everybody- > > > > Since we updated to 2.2.2 we have had an inconsistently recurring issue > when creating and editing records. When the user saves the record they are > immediately given an error message indicating that the record did not save > (sometimes the message is "Failed to save your changes", sometimes it's > "Record not found"). But upon refreshing the page it turns out that the > changes actually did save, and there are no errors logged on the backend, > which makes me think it's just a frontend issue. This has happened so far > with resource, archival object, subject and agent records. > > > > It doesn't happen every time, which is kind of good, but it makes it > impossible to reliably reproduce the problem - the same set of actions that > triggered the error once will not necessarily trigger it a second time. > This makes it hard to diagnose what's going on or to report the issue in a > helpful way. > > > > Has anyone else noticed anything like this? > > > > -Trevor > > > > -- > > Trevor Thornton > > Applications Developer, Digital Library Initiatives > > North Carolina State University Libraries > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Trevor Thornton Applications Developer, Digital Library Initiatives North Carolina State University Libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpeterson at smith.edu Tue Jan 2 16:27:39 2018 From: cpeterson at smith.edu (Christie Peterson) Date: Tue, 02 Jan 2018 21:27:39 +0000 Subject: [Archivesspace_Users_Group] Processing notes Message-ID: Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Clair at du.edu Tue Jan 2 16:33:56 2018 From: Kevin.Clair at du.edu (Kevin Clair) Date: Tue, 2 Jan 2018 21:33:56 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: References: Message-ID: Hi Christie, At the University of Denver we use it in both Resource and Archival Object records as a note to other archivists indicating processing or cataloging tasks that were left unfinished for one reason or another, or other administrative things that we don?t want published in the PUI. The idea is that if the actions listed in the Repository Processing Note get taken, we remove the text that?s there. We have a report that pulls the information from that field for review that we run periodically when setting processing priorities: https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:28 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Processing notes Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpeterson at smith.edu Tue Jan 2 16:36:48 2018 From: cpeterson at smith.edu (Christie Peterson) Date: Tue, 02 Jan 2018 21:36:48 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: References: Message-ID: Thanks for the quick response, Kevin. Is there any particular reason why you use that note field, instead of the Collection Management subrecord, for that purpose? Christie On Tue, Jan 2, 2018 at 4:34 PM Kevin Clair wrote: > Hi Christie, > > > > At the University of Denver we use it in both Resource and Archival Object > records as a note to other archivists indicating processing or cataloging > tasks that were left unfinished for one reason or another, or other > administrative things that we don?t want published in the PUI. The idea is > that if the actions listed in the Repository Processing Note get taken, we > remove the text that?s there. > > > > We have a report that pulls the information from that field for review > that we run periodically when setting processing priorities: > https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report > > > > -k > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Christie > Peterson > *Sent:* Tuesday, January 02, 2018 2:28 PM > *To:* Archivesspace Users Group > *Subject:* [Archivesspace_Users_Group] Processing notes > > > > Hello, > > > > Can anyone on this list speak to what was intended to go in the > "Repository Processing Note" text field for Resources, which the tooltip > tells me does not appear in any exports or reports? > > > > Can anyone give me a use case for why they populate this field in addition > to (or instead of?) an unpublished "Processing Information" note? > > > > Thanks, > > > > Christie Peterson > > -- > > ?? ?? ?? ?? ?? ?? ?? ?? > > Christie S. Peterson > > Head of Technical Services for Special Collections > > Smith College > > Northampton, Mass. > > 413-585-2996 <(413)%20585-2996> > > cpeterson at smith.edu > > > > pronouns: she/her/hers > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Clair at du.edu Tue Jan 2 16:39:36 2018 From: Kevin.Clair at du.edu (Kevin Clair) Date: Tue, 2 Jan 2018 21:39:36 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: References: Message-ID: Three main reasons, in descending order of importance: 1. At the top of the record so easy to see at a glance 2. Easier to query in a report 3. More ephemeral, so less inclined to go to the trouble of navigating subforms to enter that information -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:37 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Processing notes Thanks for the quick response, Kevin. Is there any particular reason why you use that note field, instead of the Collection Management subrecord, for that purpose? Christie On Tue, Jan 2, 2018 at 4:34 PM Kevin Clair > wrote: Hi Christie, At the University of Denver we use it in both Resource and Archival Object records as a note to other archivists indicating processing or cataloging tasks that were left unfinished for one reason or another, or other administrative things that we don?t want published in the PUI. The idea is that if the actions listed in the Repository Processing Note get taken, we remove the text that?s there. We have a report that pulls the information from that field for review that we run periodically when setting processing priorities: https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:28 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Processing notes Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteele at jhu.edu Tue Jan 2 16:40:21 2018 From: jsteele at jhu.edu (Jordon Steele) Date: Tue, 2 Jan 2018 21:40:21 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: References: Message-ID: Christie, Like Kevin, we use this note to communicate administrative information that doesn?t need to be published but ought to be conveyed to staff, especially if it?s information that doesn?t neatly align with a specific note that could be unpublished. For example, I used it to explain to staff why we decided to change the identifier of a collection from one normally reserved for manuscript collections to one that we use for university records collections. The idea is that having information like this in the Repository Processing Note ensures that it?s more likely to be seen by staff than having it buried in, say, a more specific note that?s marked ?unpublished.? Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:34 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Processing notes Hi Christie, At the University of Denver we use it in both Resource and Archival Object records as a note to other archivists indicating processing or cataloging tasks that were left unfinished for one reason or another, or other administrative things that we don?t want published in the PUI. The idea is that if the actions listed in the Repository Processing Note get taken, we remove the text that?s there. We have a report that pulls the information from that field for review that we run periodically when setting processing priorities: https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:28 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Processing notes Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Clair at du.edu Tue Jan 2 16:52:13 2018 From: Kevin.Clair at du.edu (Kevin Clair) Date: Tue, 2 Jan 2018 21:52:13 +0000 Subject: [Archivesspace_Users_Group] Related Agents link strangeness Message-ID: Hello, We've noticed some peculiar behavior when adding Related Agent links to Corporate Entity records in ArchivesSpace. When typing the name of the Agent we wish to link in the Related Agents form, the typeahead drop-down list populates with unrelated terms. For example, if we were to try and enter a University of Denver constituent unit as the later form of a name for a different DU corporate entity, typing "university of denver" into the text field brings up a drop-down list of mostly Family records. This only happens when the search string contains spaces; searches on a single word bring up more or less the results we would expect. Two screenshots are attached: one with the results when "university" is the search, and one with the results when "university of denver" is the search (the drop-down results are the same whether or not the period is included). Has anyone else noticed anything like this? thanks! -k -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: university_of_denver.jpg Type: image/jpeg Size: 1081225 bytes Desc: university_of_denver.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: university.jpg Type: image/jpeg Size: 1598992 bytes Desc: university.jpg URL: From kate_bowers at harvard.edu Tue Jan 2 17:33:11 2018 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Tue, 2 Jan 2018 22:33:11 +0000 Subject: [Archivesspace_Users_Group] Related Agents link strangeness In-Reply-To: References: Message-ID: I think it is really searching: University OR of OR Denver Try keying in University AND Denver and see if you have better luck. (Annoying default OR operator is annoying.) Kate From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:52 PM To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org) Subject: [Archivesspace_Users_Group] Related Agents link strangeness Hello, We've noticed some peculiar behavior when adding Related Agent links to Corporate Entity records in ArchivesSpace. When typing the name of the Agent we wish to link in the Related Agents form, the typeahead drop-down list populates with unrelated terms. For example, if we were to try and enter a University of Denver constituent unit as the later form of a name for a different DU corporate entity, typing "university of denver" into the text field brings up a drop-down list of mostly Family records. This only happens when the search string contains spaces; searches on a single word bring up more or less the results we would expect. Two screenshots are attached: one with the results when "university" is the search, and one with the results when "university of denver" is the search (the drop-down results are the same whether or not the period is included). Has anyone else noticed anything like this? thanks! -k -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rush at yale.edu Wed Jan 3 08:56:49 2018 From: michael.rush at yale.edu (Rush, Michael) Date: Wed, 3 Jan 2018 13:56:49 +0000 Subject: [Archivesspace_Users_Group] Related Agents link strangeness In-Reply-To: References: Message-ID: All, The default OR operator in ASpace's Solr settings is pretty unbearable. To address it, Yale contracted with Hudson Molonglo to develop a plugin to change that behavior to a default AND operator. See https://github.com/hudmol/and_search. For the record I'm not certain if this plugin affects the PUI search. Mike 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: Tuesday, January 2, 2018 5:33 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Related Agents link strangeness I think it is really searching: University OR of OR Denver Try keying in University AND Denver and see if you have better luck. (Annoying default OR operator is annoying.) Kate From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:52 PM To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org) > Subject: [Archivesspace_Users_Group] Related Agents link strangeness Hello, We've noticed some peculiar behavior when adding Related Agent links to Corporate Entity records in ArchivesSpace. When typing the name of the Agent we wish to link in the Related Agents form, the typeahead drop-down list populates with unrelated terms. For example, if we were to try and enter a University of Denver constituent unit as the later form of a name for a different DU corporate entity, typing "university of denver" into the text field brings up a drop-down list of mostly Family records. This only happens when the search string contains spaces; searches on a single word bring up more or less the results we would expect. Two screenshots are attached: one with the results when "university" is the search, and one with the results when "university of denver" is the search (the drop-down results are the same whether or not the period is included). Has anyone else noticed anything like this? thanks! -k -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rush at yale.edu Wed Jan 3 09:02:31 2018 From: michael.rush at yale.edu (Rush, Michael) Date: Wed, 3 Jan 2018 14:02:31 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: References: Message-ID: I agree with everything Kevin and Jordan have said. I?d add one additional advantage to using the Repository Processing Note. When the PUI is implemented, as we are currently working through, it becomes crucial to manage the workflow around published vs. unpublished notes (and components). We anticipate relying heavily on the ?Publish All? button at the resource level. Using the Repository Processing Note means there is one less note that could be accidentally published with Publish All. Mike From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jordon Steele Sent: Tuesday, January 2, 2018 4:40 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Processing notes Christie, Like Kevin, we use this note to communicate administrative information that doesn?t need to be published but ought to be conveyed to staff, especially if it?s information that doesn?t neatly align with a specific note that could be unpublished. For example, I used it to explain to staff why we decided to change the identifier of a collection from one normally reserved for manuscript collections to one that we use for university records collections. The idea is that having information like this in the Repository Processing Note ensures that it?s more likely to be seen by staff than having it buried in, say, a more specific note that?s marked ?unpublished.? Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:34 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Processing notes Hi Christie, At the University of Denver we use it in both Resource and Archival Object records as a note to other archivists indicating processing or cataloging tasks that were left unfinished for one reason or another, or other administrative things that we don?t want published in the PUI. The idea is that if the actions listed in the Repository Processing Note get taken, we remove the text that?s there. We have a report that pulls the information from that field for review that we run periodically when setting processing priorities: https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:28 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Processing notes Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltang5 at lib.msu.edu Wed Jan 3 09:19:50 2018 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Wed, 3 Jan 2018 14:19:50 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: References: Message-ID: <1619E447-B6E4-4E74-9F07-1AC275BA4EF1@lib.msu.edu> Thanks for sharing your plug in, Kevin! That?s a really great feature! I?ve been wondering if the Repository Processing Note should be integrated into the Collection Management module, if a preview of the module was still viewable in the same prominent area? I?ve often copied the contents of the Repository Processing notes into that area, although I understand that the Collection Management module also has more specific functions. Would it also be nice if there was a way to view Repository Processing notes related to a particular collection (say, if there are several nested archival objects within a collection with unique Repository Processing notes ? currently it seems to only be possible to view this note if the individual record is opened)? Lydia From: on behalf of "Rush, Michael" Reply-To: Archivesspace Users Group Date: Wednesday, January 3, 2018 at 9:02 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Processing notes I agree with everything Kevin and Jordan have said. I?d add one additional advantage to using the Repository Processing Note. When the PUI is implemented, as we are currently working through, it becomes crucial to manage the workflow around published vs. unpublished notes (and components). We anticipate relying heavily on the ?Publish All? button at the resource level. Using the Repository Processing Note means there is one less note that could be accidentally published with Publish All. Mike From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jordon Steele Sent: Tuesday, January 2, 2018 4:40 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Processing notes Christie, Like Kevin, we use this note to communicate administrative information that doesn?t need to be published but ought to be conveyed to staff, especially if it?s information that doesn?t neatly align with a specific note that could be unpublished. For example, I used it to explain to staff why we decided to change the identifier of a collection from one normally reserved for manuscript collections to one that we use for university records collections. The idea is that having information like this in the Repository Processing Note ensures that it?s more likely to be seen by staff than having it buried in, say, a more specific note that?s marked ?unpublished.? Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:34 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Processing notes Hi Christie, At the University of Denver we use it in both Resource and Archival Object records as a note to other archivists indicating processing or cataloging tasks that were left unfinished for one reason or another, or other administrative things that we don?t want published in the PUI. The idea is that if the actions listed in the Repository Processing Note get taken, we remove the text that?s there. We have a report that pulls the information from that field for review that we run periodically when setting processing priorities: https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:28 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Processing notes Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers From KennedyN at si.edu Wed Jan 3 11:11:38 2018 From: KennedyN at si.edu (Kennedy, Nancy) Date: Wed, 3 Jan 2018 16:11:38 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: References: Message-ID: <4142170736420940ACB07EE9EECDC21F51BF9CE5@si-msedag04.US.SINET.SI.EDU> Mike ? Out of curiosity, do you have ?internal only? components or notes? How would you manage the Publish All feature in the context of occasional internal only notes? For example, in AT, we kept some notes set to ?internal only.? But, that AT model doesn?t map easily onto the ArchivesSpace publish checkboxes. Publish All sounds useful for flipping large sets of components to publish, but there wouldn?t be a way to distinguish the ?internal only? notes. You?d have to go back and uncheck the internal notes, I suppose? Which seems error prone. Has anyone else faced this scenario? How did you adapt your workflows? Or perhaps, how did you adjust your data entry (maybe you limit data entry so that anything ?internal? is only entered into the repo processing note, coll mgmt. or user defined fields?) Nancy From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rush, Michael Sent: Wednesday, January 03, 2018 9:03 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Processing notes I agree with everything Kevin and Jordan have said. I?d add one additional advantage to using the Repository Processing Note. When the PUI is implemented, as we are currently working through, it becomes crucial to manage the workflow around published vs. unpublished notes (and components). We anticipate relying heavily on the ?Publish All? button at the resource level. Using the Repository Processing Note means there is one less note that could be accidentally published with Publish All. Mike From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jordon Steele Sent: Tuesday, January 2, 2018 4:40 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Processing notes Christie, Like Kevin, we use this note to communicate administrative information that doesn?t need to be published but ought to be conveyed to staff, especially if it?s information that doesn?t neatly align with a specific note that could be unpublished. For example, I used it to explain to staff why we decided to change the identifier of a collection from one normally reserved for manuscript collections to one that we use for university records collections. The idea is that having information like this in the Repository Processing Note ensures that it?s more likely to be seen by staff than having it buried in, say, a more specific note that?s marked ?unpublished.? Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:34 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Processing notes Hi Christie, At the University of Denver we use it in both Resource and Archival Object records as a note to other archivists indicating processing or cataloging tasks that were left unfinished for one reason or another, or other administrative things that we don?t want published in the PUI. The idea is that if the actions listed in the Repository Processing Note get taken, we remove the text that?s there. We have a report that pulls the information from that field for review that we run periodically when setting processing priorities: https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:28 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Processing notes Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: From crluers at wm.edu Wed Jan 3 14:03:12 2018 From: crluers at wm.edu (Luers, Christina) Date: Wed, 3 Jan 2018 19:03:12 +0000 Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions Message-ID: Hello all, I am hoping to find out if some of you would be willing to share how you manage your top containers for collections that have description at the item level. We have quite a few legacy collections that were processed dozens of years ago and were done at the item level for most, if not all, of the collection. While we would not dream of processing collections to this level now, we also do not want to lose all of the metadata of some of those item level descriptions. In creating box and folder containers, we decided on a repository level that, since we pull at the box level, even for collections that share boxes, top containers would be box level only. The only exception to this are the folders that reside in map cabinets. Our problem is this, when describing at the item level, we are having trouble getting more than one item into a folder without the folder being the top container. This is something we certainly do not want to do. We can try to list the items in the folder scope and contents, but some of our legacy collections are in need of re-housing (ie One box has a total of four burrito type folders that each contain at least 40 or more items) but re-housing those collections is a far off task. We are looking for a much more easily accomplished task of fixing these legacy collections until we can devote the much needed time to them. Any suggestions on how to capture item level description for these legacy collections without making the folder the top container? Many thanks for your time and offers of assistance. Christina R. Luers Archives Collections Specialist College of William and Mary -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajz12 at psu.edu Wed Jan 3 14:23:36 2018 From: ajz12 at psu.edu (Alissa Zawoyski) Date: Wed, 3 Jan 2018 14:23:36 -0500 (EST) Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions In-Reply-To: References: Message-ID: <819352670.5784485.1515007416595.JavaMail.zimbra@psu.edu> Hi Christina, What if you make each map drawer its own top container, and assign the folders accordingly? We have tried various solutions for our share box(/drawer) problems and I would be interested to hear what other people are doing... Thanks, Ali Alissa Zawoyski Collection Management Specialist Eberly Family Special Collections Library Penn State University Libraries 814-867-0294 ajz12 at psu.edu From: "Luers, Christina" To: "Archivesspace Users Group" Sent: Wednesday, January 3, 2018 2:03:12 PM Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions Hello all, I am hoping to find out if some of you would be willing to share how you manage your top containers for collections that have description at the item level. We have quite a few legacy collections that were processed dozens of years ago and were done at the item level for most, if not all, of the collection. While we would not dream of processing collections to this level now, we also do not want to lose all of the metadata of some of those item level descriptions. In creating box and folder containers, we decided on a repository level that, since we pull at the box level, even for collections that share boxes, top containers would be box level only. The only exception to this are the folders that reside in map cabinets. Our problem is this, when describing at the item level, we are having trouble getting more than one item into a folder without the folder being the top container. This is something we certainly do not want to do. We can try to list the items in the folder scope and contents, but some of our legacy collections are in need of re-housing (ie One box has a total of four burrito type folders that each contain at least 40 or more items) but re-housing those collections is a far off task. We are looking for a much more easily accomplished task of fixing these legacy collections until we can devote the much needed time to them. Any suggestions on how to capture item level description for these legacy collections without making the folder the top container? Many thanks for your time and offers of assistance. Christina R. Luers Archives Collections Specialist College of William and Mary _______________________________________________ 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 akroeger at unomaha.edu Wed Jan 3 14:26:50 2018 From: akroeger at unomaha.edu (Angela Kroeger) Date: Wed, 3 Jan 2018 19:26:50 +0000 Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions In-Reply-To: References: Message-ID: Hi, Christina, You can link multiple item-level archival objects to the same top container. So your top container would be the box (not the folder). Within each item-level description, under Instances, add a container instance and link to that same box. Then select the child type of folder and enter a folder number (or potentially even a folder title, if your folders are unnumbered) as the child indicator. When you have item-level descriptions for multiple items within the same folder, then your top container should still be the box. The child type would still be folder, and the child indicator would be the same for all items within the same folder. Then for each individual item, you'd add a grandchild type of item and give it a grandchild indicator that describes that item's position within the folder. (If "item" is not one of the options in your grandchild type drop menu, then you can have someone with system administrator privileges add it under System/Manage Controlled Value Lists/Container Type.) This is, of course, not the only way you could handle the situation you describe. This is just how I would approach it. Someone else may suggest a better method. Hope that's useful! --Angela Angela Kroeger Archives and Special Collections Associate UNO Libraries | Criss Library 107 University of Nebraska at Omaha | unomaha.edu 402.554.4159 akroeger at unomaha.edu [Media:UniversityCommunications:Graphic Design:Brand tools:Logos- UNO:Vector files:Lock-up:Lockup-color on white backgrnd.eps] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5540 bytes Desc: image001.png URL: From crluers at wm.edu Wed Jan 3 14:49:27 2018 From: crluers at wm.edu (Luers, Christina) Date: Wed, 3 Jan 2018 19:49:27 +0000 Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions In-Reply-To: References: Message-ID: Thank you Angela, I think that our issue is more with the manner in which the items and folders display on the public side. And it looks like we may be able to reorder the way those box/ folders/ items are displayed from the back end. Thanks for your assistance- it was very helpful. Christina From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Angela Kroeger Sent: Wednesday, January 03, 2018 2:27 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions Hi, Christina, You can link multiple item-level archival objects to the same top container. So your top container would be the box (not the folder). Within each item-level description, under Instances, add a container instance and link to that same box. Then select the child type of folder and enter a folder number (or potentially even a folder title, if your folders are unnumbered) as the child indicator. When you have item-level descriptions for multiple items within the same folder, then your top container should still be the box. The child type would still be folder, and the child indicator would be the same for all items within the same folder. Then for each individual item, you'd add a grandchild type of item and give it a grandchild indicator that describes that item's position within the folder. (If "item" is not one of the options in your grandchild type drop menu, then you can have someone with system administrator privileges add it under System/Manage Controlled Value Lists/Container Type.) This is, of course, not the only way you could handle the situation you describe. This is just how I would approach it. Someone else may suggest a better method. Hope that's useful! --Angela Angela Kroeger Archives and Special Collections Associate UNO Libraries | Criss Library 107 University of Nebraska at Omaha | unomaha.edu 402.554.4159 akroeger at unomaha.edu [Media:UniversityCommunications:Graphic Design:Brand tools:Logos- UNO:Vector files:Lock-up:Lockup-color on white backgrnd.eps] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5540 bytes Desc: image001.png URL: From ltang5 at lib.msu.edu Wed Jan 3 15:11:39 2018 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Wed, 3 Jan 2018 20:11:39 +0000 Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions In-Reply-To: <819352670.5784485.1515007416595.JavaMail.zimbra@psu.edu> References: <819352670.5784485.1515007416595.JavaMail.zimbra@psu.edu> Message-ID: <933AE837-010A-48B7-A7FC-E632AC5F77F7@lib.msu.edu> On a slightly tangential question re: shared Top Containers, I would love to hear how institutions keep track of numbering their shared containers ? especially if some are stored offsite. I am hoping that if I create a Share Container X, by searching ?Shared Container? in Top Containers, it should pull all with those keywords together in order to see the last used box number, but I would love to hear how others have accomplished this. Thanks! Lydia From jsteele at jhu.edu Wed Jan 3 15:53:40 2018 From: jsteele at jhu.edu (Jordon Steele) Date: Wed, 3 Jan 2018 20:53:40 +0000 Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions In-Reply-To: References: Message-ID: <2da4e0a7c79f48deb1a610207e89032b@esgmtwex18.win.ad.jhu.edu> We do as Angela describes. Cristina, while I totally get your concerns about how the data looks to the public, you might want to consider the collection management implications of making your instance data ?look? a certain way. Our container information is presented in a frankly junky way, but we?ve deprioritized concerning ourselves with this since, ultimately, users don?t care what a container is called or how that data is presented, they want the stuff. (We?ve found they largely just send us direct links to the archival component level since we began using the PUI anyway, leaving staff to determine the physical location of what they want.) FWIW, we barcode folders in map drawers since the folder is the physical unit we deliver to the reading room, akin to barcoded boxes. Map drawers and the flat file itself are managed as locations, akin to shelves and ranges for traditional collections. Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Luers, Christina Sent: Wednesday, January 03, 2018 2:49 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions Thank you Angela, I think that our issue is more with the manner in which the items and folders display on the public side. And it looks like we may be able to reorder the way those box/ folders/ items are displayed from the back end. Thanks for your assistance- it was very helpful. Christina From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Angela Kroeger Sent: Wednesday, January 03, 2018 2:27 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions Hi, Christina, You can link multiple item-level archival objects to the same top container. So your top container would be the box (not the folder). Within each item-level description, under Instances, add a container instance and link to that same box. Then select the child type of folder and enter a folder number (or potentially even a folder title, if your folders are unnumbered) as the child indicator. When you have item-level descriptions for multiple items within the same folder, then your top container should still be the box. The child type would still be folder, and the child indicator would be the same for all items within the same folder. Then for each individual item, you'd add a grandchild type of item and give it a grandchild indicator that describes that item's position within the folder. (If "item" is not one of the options in your grandchild type drop menu, then you can have someone with system administrator privileges add it under System/Manage Controlled Value Lists/Container Type.) This is, of course, not the only way you could handle the situation you describe. This is just how I would approach it. Someone else may suggest a better method. Hope that's useful! --Angela Angela Kroeger Archives and Special Collections Associate UNO Libraries | Criss Library 107 University of Nebraska at Omaha | unomaha.edu 402.554.4159 akroeger at unomaha.edu [Media:UniversityCommunications:Graphic Design:Brand tools:Logos- UNO:Vector files:Lock-up:Lockup-color on white backgrnd.eps] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5540 bytes Desc: image001.png URL: From mcyzyk at jhu.edu Wed Jan 3 16:15:30 2018 From: mcyzyk at jhu.edu (Mark Cyzyk) Date: Wed, 3 Jan 2018 16:15:30 -0500 Subject: [Archivesspace_Users_Group] Archivesspace: Log run Amok In-Reply-To: References: Message-ID: <056cecde-a26d-85ca-daa1-80dfdf934f9c@jhu.edu> All, Yesterday our archivesspace.out log file ran amok and consumed our disk space.? (It grew to a whopping 11 GB.)? I took a peek at it and am seeing that it's logging at the "Info" level when my config says it should only be logging at "Fatal": > ## Log level for the backend, values: (everything) debug, info, warn, > error, fatal (severe only) > AppConfig[:backend_log_level] = "fatal" This is sounding like a bug to me. If anyone has ideas on how to force logging to only fatal events, I'd like to know.? MUCH appreciated. Mark <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Mark Cyzyk, M.A., M.L.S. Scholarly Communication Architect Library Applications Group The Sheridan Libraries The Johns Hopkins University mcyzyk at jhu.edu Verba volant, scripta manent. On 1/2/2018 4:52 PM, archivesspace_users_group-request at lyralists.lyrasis.org wrote: > Send Archivesspace_Users_Group mailing list submissions to > archivesspace_users_group at lyralists.lyrasis.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > or, via email, send a message with subject or body 'help' to > archivesspace_users_group-request at lyralists.lyrasis.org > > You can reach the person managing the list at > archivesspace_users_group-owner at lyralists.lyrasis.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Archivesspace_Users_Group digest..." > > > Today's Topics: > > 1. Re: ArchivesSpace user manual error page (Christine Kim) > 2. Re: ArchivesSpace user manual error page (Christine Kim) > 3. Re: Collections Browse Error in Public Interface, v2.2.1 > (Custer, Mark) > 4. Re: Collections Browse Error in Public Interface, v2.2.1 > (Leilani Dawson) > 5. truncation in PUI 2.2.1 (Maderik, Rachel A) > 6. Re: truncation in PUI 2.2.1 (Christine Di Bella) > 7. Merging Controlled Values (Stasiulatis, Suzanne) > 8. installing wildcard SSL cert, redirect http to https (Brian Slenk) > 9. digital object mapping to EAD in v.2.2.1 (Amanda Focke) > 10. Splitting off one repository into a new database > (Celia Caust-Ellenbogen) > 11. Position statement on multitenancy (Christie Peterson) > 12. Re: Merging Controlled Values (Michelson, Daniel) > 13. Re: Splitting off one repository into a new database > (Majewski, Steven Dennis (sdm7g)) > 14. Re: Webinar Announcement: Varying Approaches to Testing > ASpace Pre-Releases - Dec 14 (Christine Kim) > 15. Re: installing wildcard SSL cert, redirect http to https > (Jason Loeffler) > 16. Ideas for advanced training topics? (Christine Kim) > 17. Re: installing wildcard SSL cert, redirect http to https > (Cook, Robert) > 18. ArchivesSpace 2.2.2 now available (Christine Di Bella) > 19. Re: ArchivesSpace 2.2.2 now available (Christie Peterson) > 20. Re: ArchivesSpace 2.2.2 now available (Christine Di Bella) > 21. ASpace 2.1.2 issue with digital object links (Knox, Ashley M.) > 22. Creating staff entities for Assessments module? (Tang, Lydia) > 23. Trouble changing localhost:9081 to new URL (Walker, Scott) > 24. New version of aspace-import-excel, a plugin to support bulk > loading of Archival Objects (Fox, Bobbi) > 25. Re: New version of aspace-import-excel, a plugin to support > bulk loading of Archival Objects (Majewski, Steven Dennis (sdm7g)) > 26. reports (Steve Majewski) > 27. Re: DAO Notes in EAD (Christine Kim) > 28. Re: Creating staff entities for Assessments module? > (Pruitt, Adrienne) > 29. Re: Creating staff entities for Assessments module? (Tang, Lydia) > 30. reports (Majewski, Steven Dennis (sdm7g)) > 31. release of updated Archivists' Toolkit to ArchivesSpace > migration tool (Christine Di Bella) > 32. Re: reports (Christie Peterson) > 33. Happy Holidays from ArchivesSpace! (Christine Kim) > 34. Re: reports (Majewski, Steven Dennis (sdm7g)) > 35. Update on reports (Laney McGlohon) > 36. Re: Update on reports (Jordon Steele) > 37. release of updated Archon to ArchivesSpace migration tool > (Christine Di Bella) > 38. Overriding/Extending the new public interface in 2.2.0 > (Flanagan, Patrick) > 39. Re: Overriding/Extending the new public interface in 2.2.0 > (Fox, Bobbi) > 40. Re: Overriding/Extending the new public interface in 2.2.0 > (Flanagan, Patrick) > 41. Re: Overriding/Extending the new public interface in 2.2.0 > (Majewski, Steven Dennis (sdm7g)) > 42. ArchivesSpace Update - December 2017 (Christine Kim) > 43. latest version and format for the ArchivesSpace roadmap > (Christine Di Bella) > 44. Re: Overriding/Extending the new public interface in 2.2.0 > (Flanagan, Patrick) > 45. Error when saving records in 2.2.2 (Trevor Thornton) > 46. Re: Error when saving records in 2.2.2 (Custer, Mark) > 47. Re: Error when saving records in 2.2.2 (Trevor Thornton) > 48. Processing notes (Christie Peterson) > 49. Re: Processing notes (Kevin Clair) > 50. Re: Processing notes (Christie Peterson) > 51. Re: Processing notes (Kevin Clair) > 52. Re: Processing notes (Jordon Steele) > 53. Related Agents link strangeness (Kevin Clair) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 11 Dec 2017 15:18:11 +0000 > From: Christine Kim > To: Archivesspace Users Group > > Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual > error page > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > I?m receiving the same. I will submit a support ticket for this. Thanks for reporting! > > Christine Kim > ArchivesSpace Community Engagement Coordinator > christine.kim at lyrasis.org > 800.999.8558 x4820 > 404.592.4820 > Skype: ckim.lyrasis > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Mayo, Dave > Sent: Monday, December 11, 2017 7:15 AM > To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual error page > > I can confirm that I?m getting the same thing. > > - Dave Mayo > > From: > on behalf of Jasmine Jones > > Reply-To: Archivesspace Users Group > > Date: Monday, December 11, 2017 at 10:07 AM > To: "archivesspace_users_group at lyralists.lyrasis.org" > > Subject: [Archivesspace_Users_Group] ArchivesSpace user manual error page > > Hi all: > > I'm having trouble with the ArchivesSpace user manual this morning and get directed to an error page (http://docs.archivesspace.org/Default.htm and screenshot attached). Has anyone else had issues? > > Thank you, > > Jasmine Jones > > [nline image 1] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.png > Type: image/png > Size: 278340 bytes > Desc: image001.png > URL: > > ------------------------------ > > Message: 2 > Date: Mon, 11 Dec 2017 15:35:33 +0000 > From: Christine Kim > To: Archivesspace Users Group > > Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual > error page > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Hi all, > > The problem has been resolved. > > For the info curious ? it seems there was a problem with bad bots or something hitting it this morning. > > Thanks so much for reporting, and have a great Monday! > > Best wishes, > Kim > > Christine Kim > ArchivesSpace Community Engagement Coordinator > christine.kim at lyrasis.org > 800.999.8558 x4820 > 404.592.4820 > Skype: ckim.lyrasis > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Kim > Sent: Monday, December 11, 2017 7:18 AM > To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual error page > > I?m receiving the same. I will submit a support ticket for this. Thanks for reporting! > > Christine Kim > ArchivesSpace Community Engagement Coordinator > christine.kim at lyrasis.org > 800.999.8558 x4820 > 404.592.4820 > Skype: ckim.lyrasis > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Mayo, Dave > Sent: Monday, December 11, 2017 7:15 AM > To: Archivesspace Users Group > > Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual error page > > I can confirm that I?m getting the same thing. > > - Dave Mayo > > From: > on behalf of Jasmine Jones > > Reply-To: Archivesspace Users Group > > Date: Monday, December 11, 2017 at 10:07 AM > To: "archivesspace_users_group at lyralists.lyrasis.org" > > Subject: [Archivesspace_Users_Group] ArchivesSpace user manual error page > > Hi all: > > I'm having trouble with the ArchivesSpace user manual this morning and get directed to an error page (http://docs.archivesspace.org/Default.htm and screenshot attached). Has anyone else had issues? > > Thank you, > > Jasmine Jones > > [nline image 1] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.png > Type: image/png > Size: 278340 bytes > Desc: image001.png > URL: > > ------------------------------ > > Message: 3 > Date: Mon, 11 Dec 2017 15:58:06 +0000 > From: "Custer, Mark" > To: Archivesspace Users Group > > Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in > Public Interface, v2.2.1 > Message-ID: > > > Content-Type: text/plain; charset="windows-1252" > > Leilani, > > > Could you attach an example EAD file? I'm curious what happens when Unicode characters are used in place of the character entities. I'm wondering if the issue might simply be that the font used doesn't include italic characters for the character entities that are tagged as italic (as an aside, what fonts do you use outside of ArchivesSpace?). Either way, it would be nice to add these examples to some test scripts for ArchivesSpace. > > > Mark > > > ________________________________ > From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Leilani Dawson > Sent: Friday, December 8, 2017 3:45 PM > To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in Public Interface, v2.2.1 > > Yes, all of our accessibility-wrapped diacritics are in html tags. > > (Occasionally we have notes where words labeled with alternate text are nested within EAD elements such as or <persname> or the like, but those EAD elements are not as critical for us as the <span> with aria-label attribute.) > > I'll ask our IT folks to put together a 2.2 test instance so I can upload a finding aid with diacritics and see whether the new PUI handles it in a screen-reader-friendly manner. > > Thanks, > -Leilani > > On Fri, Dec 8, 2017 at 9:12 AM, Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>> wrote: > > Hi Leilani, > > > > Thanks for making me dig into this a bit more and for explaining one of the reasons tagging around a diacritic may be especially necessary. For your use case, is your tagging always like your example? If so, there?s sanitizer for HTML in the PUI that allows this kind of tagging to sail through just fine. It is XML tags like <emph> that we?re seeing this bug on. > > > > There was some accessibility work that went into the development of the new PUI, but it would be good to know that what makes this kind of tagging work in the PUI doesn?t also cause the same issue for screen readers that is the reason for you wrapping the text originally. Can you test this out locally or upload a finding aid to http://test.archivesspace.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__test.archivesspace.org&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=ojcyFCMoM3zS9hpwYf4E7AnqB96za3sLtX6PZ20VkFM&e=> and try it out? > > > > Christine > > > > Christine Di Bella > > ArchivesSpace Program Manager > > christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> > > 800.999.8558 x2905<tel:(800)%20999-8558> > > 678-235-2905<tel:(678)%20235-2905> > > cdibella13 (Skype) > > > > [ASpaceOrgHomeMedium] > > > > > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Leilani Dawson > Sent: Friday, December 8, 2017 1:13 PM > To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> > Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in Public Interface, v2.2.1 > > > > Hi Christine, > > I see this is listed in JIRA as a minor issue, but is there any guess for when it might be addressed? > > Certain Hawaiian-language diacritics "break" screen readers, so in order to satisfy both accessibility requirements and UH's mandate to be a Hawaiian place of learning, the Library has started wrapping these diacritics in <span> tags with aria-label attributes. (E.g.: <span aria-label="Hawaii">Hawaiʻi</span>) ArchivesSpace 2.1 and 2.2 not being able to handle wrapped diacritics might preclude us from going forward with using the public user interface and/or upgrading to 2.x. until the fix is in. > > -Leilani. > > - - > > Leilani Dawson > > Manuscript Collections Archivist > > University Archives & Manuscripts Department > > University of Hawaii at Manoa Library > > 2550 McCarthy Mall, Honolulu, HI 96822 > > ltdawson at hawaii.edu<mailto:ltdawson at hawaii.edu> > > > > On Fri, Dec 8, 2017 at 3:28 AM, Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>> wrote: > > Hi Neal, > > > > Do you by chance have a collection that has the circumstance described in this JIRA ticket: https://archivesspace.atlassian.net/browse/AR-1938<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1938&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=VMpZ3HzcFod2VlOa_Q5TAqIkbX5K9NFmJ-9RGxTgJRI&e=> (A diacritic wrapped in a tag.) Most likely it would be in the scope and contents note or abstract field if the error is happening from the collection browse. > > > > If so, and that record appears on the first page of your all collection browse, that may be what?s causing the issue. You would also get a ?We?re sorry something went wrong? when trying to view that particular record or on a search that includes that particular record. If you have multiple repositories, that would also explain why a collection browse that?s scoped to another repository would not yield that issue. > > > > This is a reported issue for all 2.1 and 2.2 versions. The workaround for now would be to remove either the tagging or the diacritic, but we hope to fix this issue for a future release. > > > > If you don?t have that circumstance, we?ll need to delve into this more deeply. > > > > Christine > > > > Christine Di Bella > > ArchivesSpace Program Manager > > christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> > > 800.999.8558 x2905<tel:(800)%20999-8558> > > 678-235-2905<tel:(678)%20235-2905> > > cdibella13 (Skype) > > > > [ASpaceOrgHomeMedium] > > > > > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Harmeyer, Neal A > Sent: Thursday, December 7, 2017 5:45 PM > To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> > Subject: [Archivesspace_Users_Group] Collections Browse Error in Public Interface, v2.2.1 > > > > Hello all, > > > > I wonder if anyone else has experienced this issue? > > > > When selecting the Collections browse (/repositories/resources) from the header in the public interface, version 2.2.1, the system throws an error message that reads 'Your request could not be completed due to an unexpected error'. This only occurs for Collections browse; all other areas continue to load without issue?so our systems administrator isn?t sure this could be cause by any web server configurations. I?ve been able to cause the failure on our dev site by repeatedly selecting the Collections browse over a short period of time. > > > > We didn?t experience this in any past versions. A restart of the server removes the issue for a period of time but then it re-appears; there is nothing in our logs to point to a cause of the problem. > > > > Any suggestions would be helpful! > > > > Thank you, > > Neal > > > > -- > > Neal Harmeyer > > Digital Archivist > > Purdue Univesity Archives and Special Collections > > Purdue University Libraries > > harmeyna at purdue.edu<mailto:harmeyna at purdue.edu> > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W-qI7NJvab5eSZgQuU&e=> > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W-qI7NJvab5eSZgQuU&e=> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/375fb341/attachment-0001.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image005.jpg > Type: image/jpeg > Size: 6608 bytes > Desc: image005.jpg > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/375fb341/attachment-0002.jpg> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image006.jpg > Type: image/jpeg > Size: 6608 bytes > Desc: image006.jpg > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/375fb341/attachment-0003.jpg> > > ------------------------------ > > Message: 4 > Date: Mon, 11 Dec 2017 09:02:37 -1000 > From: Leilani Dawson <ltdawson at hawaii.edu> > To: Archivesspace Users Group > <archivesspace_users_group at lyralists.lyrasis.org> > Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in > Public Interface, v2.2.1 > Message-ID: > <CADGuORE3ZJ84itYeHSmf-zduRHE-PPzPo545zj3T2F-3UiajCA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Sure, here's an export of a tiny collection showing a couple of wrapped > diacritics in the custodial history. > > We haven't yet done any testing of the PUI--or the staff interface, for > that matter--with screen readers; what we know of how the ?okina (the > glottal stop marker, ʻ) interacts with them comes mostly from > Library-wide testing of WordPress and LibGuides. (And from that testing > we know that vowels with macrons don't normally confuse screen readers, so > we haven't been coding words containing them, e.g. M?noa, with aria-label > attributes.) > > I'm not sure what fonts we're using in WordPress and LibGuides. I'd assume > they're pretty standard, but I'll ask. > > -Leilani. > > On Mon, Dec 11, 2017 at 5:58 AM, Custer, Mark <mark.custer at yale.edu> wrote: > >> Leilani, >> >> >> Could you attach an example EAD file? I'm curious what happens when >> Unicode characters are used in place of the character entities. I'm >> wondering if the issue might simply be that the font used doesn't include >> italic characters for the character entities that are tagged as italic (as >> an aside, what fonts do you use outside of ArchivesSpace?). Either way, >> it would be nice to add these examples to some test scripts for >> ArchivesSpace. >> >> >> Mark >> >> >> ------------------------------ >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < >> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of >> Leilani Dawson <ltdawson at hawaii.edu> >> *Sent:* Friday, December 8, 2017 3:45 PM >> *To:* Archivesspace Users Group >> *Subject:* Re: [Archivesspace_Users_Group] Collections Browse Error in >> Public Interface, v2.2.1 >> >> Yes, all of our accessibility-wrapped diacritics are in html tags. >> >> (Occasionally we have notes where words labeled with alternate text are >> nested within EAD elements such as <title> or <persname> or the like, but >> those EAD elements are not as critical for us as the <span> with aria-label >> attribute.) >> >> I'll ask our IT folks to put together a 2.2 test instance so I can upload >> a finding aid with diacritics and see whether the new PUI handles it in a >> screen-reader-friendly manner. >> >> Thanks, >> -Leilani >> >> On Fri, Dec 8, 2017 at 9:12 AM, Christine Di Bella < >> christine.dibella at lyrasis.org> wrote: >> >> Hi Leilani, >> >> >> >> Thanks for making me dig into this a bit more and for explaining one of >> the reasons tagging around a diacritic may be especially necessary. For >> your use case, is your tagging always like your example? If so, there?s >> sanitizer for HTML in the PUI that allows this kind of tagging to sail >> through just fine. It is XML tags like <emph> that we?re seeing this bug >> on. >> >> >> >> There was some accessibility work that went into the development of the >> new PUI, but it would be good to know that what makes this kind of tagging >> work in the PUI doesn?t also cause the same issue for screen readers that >> is the reason for you wrapping the text originally. Can you test this out >> locally or upload a finding aid to http://test.archivesspace.org >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__test.archivesspace.org&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=ojcyFCMoM3zS9hpwYf4E7AnqB96za3sLtX6PZ20VkFM&e=> >> and try it out? >> >> >> >> Christine >> >> >> >> Christine Di Bella >> >> ArchivesSpace Program Manager >> >> christine.dibella at lyrasis.org >> >> 800.999.8558 x2905 <(800)%20999-8558> >> >> 678-235-2905 <(678)%20235-2905> >> >> cdibella13 (Skype) >> >> >> >> [image: ASpaceOrgHomeMedium] >> >> >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Leilani >> Dawson >> *Sent:* Friday, December 8, 2017 1:13 PM >> *To:* Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org> >> *Subject:* Re: [Archivesspace_Users_Group] Collections Browse Error in >> Public Interface, v2.2.1 >> >> >> >> Hi Christine, >> >> I see this is listed in JIRA as a minor issue, but is there any guess for >> when it might be addressed? >> >> Certain Hawaiian-language diacritics "break" screen readers, so in order >> to satisfy both accessibility requirements and UH's mandate to be a >> Hawaiian place of learning, the Library has started wrapping these >> diacritics in <span> tags with aria-label attributes. (E.g.: <span >> aria-label="Hawaii">Hawaiʻi</span>) ArchivesSpace 2.1 and 2.2 not >> being able to handle wrapped diacritics might preclude us from going >> forward with using the public user interface and/or upgrading to 2.x. until >> the fix is in. >> >> >> -Leilani. >> >> - - >> >> Leilani Dawson >> >> Manuscript Collections Archivist >> >> University Archives & Manuscripts Department >> >> University of Hawaii at Manoa Library >> >> 2550 McCarthy Mall, Honolulu, HI 96822 >> >> ltdawson at hawaii.edu >> >> >> >> On Fri, Dec 8, 2017 at 3:28 AM, Christine Di Bella < >> christine.dibella at lyrasis.org> wrote: >> >> Hi Neal, >> >> >> >> Do you by chance have a collection that has the circumstance described in >> this JIRA ticket: https://archivesspace.atlassian.net/browse/AR-1938 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1938&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=VMpZ3HzcFod2VlOa_Q5TAqIkbX5K9NFmJ-9RGxTgJRI&e=> >> (A diacritic wrapped in a tag.) Most likely it would be in the scope and >> contents note or abstract field if the error is happening from the >> collection browse. >> >> >> >> If so, and that record appears on the first page of your all collection >> browse, that may be what?s causing the issue. You would also get a ?We?re >> sorry something went wrong? when trying to view that particular record or >> on a search that includes that particular record. If you have multiple >> repositories, that would also explain why a collection browse that?s scoped >> to another repository would not yield that issue. >> >> >> >> This is a reported issue for all 2.1 and 2.2 versions. The workaround for >> now would be to remove either the tagging or the diacritic, but we hope to >> fix this issue for a future release. >> >> >> >> If you don?t have that circumstance, we?ll need to delve into this more >> deeply. >> >> >> >> Christine >> >> >> >> Christine Di Bella >> >> ArchivesSpace Program Manager >> >> christine.dibella at lyrasis.org >> >> 800.999.8558 x2905 <(800)%20999-8558> >> >> 678-235-2905 <(678)%20235-2905> >> >> cdibella13 (Skype) >> >> >> >> [image: ASpaceOrgHomeMedium] >> >> >> >> >> >> >> >> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Harmeyer, >> Neal A >> *Sent:* Thursday, December 7, 2017 5:45 PM >> *To:* Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org> >> *Subject:* [Archivesspace_Users_Group] Collections Browse Error in Public >> Interface, v2.2.1 >> >> >> >> Hello all, >> >> >> >> I wonder if anyone else has experienced this issue? >> >> >> >> When selecting the Collections browse (/repositories/resources) from the >> header in the public interface, version 2.2.1, the system throws an error >> message that reads 'Your request could not be completed due to an >> unexpected error'. This only occurs for Collections browse; all other areas >> continue to load without issue?so our systems administrator isn?t sure this >> could be cause by any web server configurations. I?ve been able to cause >> the failure on our dev site by repeatedly selecting the Collections browse >> over a short period of time. >> >> >> >> We didn?t experience this in any past versions. A restart of the server >> removes the issue for a period of time but then it re-appears; there is >> nothing in our logs to point to a cause of the problem. >> >> >> >> Any suggestions would be helpful! >> >> >> >> Thank you, >> >> Neal >> >> >> >> -- >> >> Neal Harmeyer >> >> Digital Archivist >> >> Purdue Univesity Archives and Special Collections >> >> Purdue University Libraries >> >> harmeyna at purdue.edu >> >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W-qI7NJvab5eSZgQuU&e=> >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W-qI7NJvab5eSZgQuU&e=> >> >> >> >> _______________________________________________ >> 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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/2418fb0d/attachment-0001.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image005.jpg > Type: image/jpeg > Size: 6608 bytes > Desc: not available > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/2418fb0d/attachment-0002.jpg> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image006.jpg > Type: image/jpeg > Size: 6608 bytes > Desc: not available > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/2418fb0d/attachment-0003.jpg> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: MANUSCRIPT.M00060_20171211_184828_UTC__ead.xml > Type: text/xml > Size: 3409 bytes > Desc: not available > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/2418fb0d/attachment-0001.xml> > > ------------------------------ > > Message: 5 > Date: Mon, 11 Dec 2017 20:02:37 +0000 > From: "Maderik, Rachel A" <maderikra at vmi.edu> > To: "'Archivesspace_Users_Group at lyralists.lyrasis.org'" > <Archivesspace_Users_Group at lyralists.lyrasis.org> > Subject: [Archivesspace_Users_Group] truncation in PUI 2.2.1 > Message-ID: <be6834aa52ef42b38fa0691dd7e77eca at vmi.edu> > Content-Type: text/plain; charset="us-ascii" > > Has anyone else had problems with search term truncation not working in the PUI in v2.2.1? I can replicate the problem on the public sandbox: I created a record entitled "Test Record Morrill": http://public.archivesspace.org/repositories/3/resources/105, but searching for "morril*" brings back 0 results (it also inserts a backslash before the truncation character, which may be related to the problem): > > [cid:image003.jpg at 01D37291.14C1DCB0] > > Rachel Maderik > Systems and Technology Librarian > 501D Preston Library > Virginia Military Institute > Lexington, VA 24450 > 540-464-7572 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/79470ac7/attachment-0001.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image003.jpg > Type: image/jpeg > Size: 31259 bytes > Desc: image003.jpg > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/79470ac7/attachment-0001.jpg> > > ------------------------------ > > Message: 6 > Date: Mon, 11 Dec 2017 20:23:28 +0000 > From: Christine Di Bella <christine.dibella at lyrasis.org> > To: Archivesspace Users Group > <archivesspace_users_group at lyralists.lyrasis.org> > Subject: Re: [Archivesspace_Users_Group] truncation in PUI 2.2.1 > Message-ID: > <CY1PR08MB119796FBE72BA32B04E2B9ACF1370 at CY1PR08MB1197.namprd08.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Dear Rachel, > > This was a bug inadvertently introduced in 2.2.1 that will be resolved in 2.2.2, which we anticipate putting out before the holiday break. We overcorrected when we put in a fix to allow searching for another character that was previously causing errors. > > Apologies, > Christine > > 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] > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Maderik, Rachel A > Sent: Monday, December 11, 2017 3:03 PM > To: 'Archivesspace_Users_Group at lyralists.lyrasis.org' <Archivesspace_Users_Group at lyralists.lyrasis.org> > Subject: [Archivesspace_Users_Group] truncation in PUI 2.2.1 > > Has anyone else had problems with search term truncation not working in the PUI in v2.2.1? I can replicate the problem on the public sandbox: I created a record entitled "Test Record Morrill": http://public.archivesspace.org/repositories/3/resources/105, but searching for "morril*" brings back 0 results (it also inserts a backslash before the truncation character, which may be related to the problem): > > [cid:image002.jpg at 01D37293.FA1F2360] > > Rachel Maderik > Systems and Technology Librarian > 501D Preston Library > Virginia Military Institute > Lexington, VA 24450 > 540-464-7572 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/61d7e45a/attachment-0001.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.jpg > Type: image/jpeg > Size: 6608 bytes > Desc: image001.jpg > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/61d7e45a/attachment-0002.jpg> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image002.jpg > Type: image/jpeg > Size: 31259 bytes > Desc: image002.jpg > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171211/61d7e45a/attachment-0003.jpg> > > ------------------------------ > > Message: 7 > Date: Tue, 12 Dec 2017 19:57:42 +0000 > From: "Stasiulatis, Suzanne" <sustasiula at pa.gov> > To: Archivesspace Users Group > <archivesspace_users_group at lyralists.lyrasis.org> > Subject: [Archivesspace_Users_Group] Merging Controlled Values > Message-ID: <103c127cd54443c7b8e301e93f2fbb4c at ENCTCEXCH008.PA.LCL> > Content-Type: text/plain; charset="us-ascii" > > I remember a while back that people were having trouble merging controlled values. Is this a safe feature to use yet? Has anyone used it successfully in 2.2.x? > > Thanks, > > Suzanne > > Suzanne Stasiulatis | Archivist II > Pennsylvania Historical and Museum Commission | Pennsylvania State Archives > 350 North Street | Harrisburg, PA 17120-0090 > Phone: 717-787-5953 > http://www.PAStateArchives.com > sustasiula at pa.gov<mailto:sustasiula at pa.gov> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171212/91be7f7a/attachment-0001.html> > > ------------------------------ > > Message: 8 > Date: Tue, 12 Dec 2017 15:57:33 -0500 > From: Brian Slenk <slenkb at hope.edu> > To: archivesspace_users_group at lyralists.lyrasis.org > Subject: [Archivesspace_Users_Group] installing wildcard SSL cert, > redirect http to https > Message-ID: > <CAAK7xVSGJZF==PkKyY8E_2xkoqHLQYqaBZ0EC0=tERviJ+qs4A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I have a new installation of an archives space server. Is there a way > with the Apache Solr web server to add an SSL wildcard certificate, and > then redirect http to https for the the public interface ? I am not > finding documentation if this is possible. > > Brian > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20171212/efeb656c/attachment-0001.html> > > ------------------------------ > > Message: 9 > Date: Tue, 12 Dec 2017 15:14:01 -0600 > From: Amanda Focke <afocke at rice.edu> > To: archivesspace_users_group at lyralists.lyrasis.org > Subject: [Archivesspace_Users_Group] digital object mapping to EAD in > v.2.2.1 > Message-ID: <5A304699.8030907 at rice.edu> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello all - > > We have "nearline" digital objects which do not have a public URL, and > we describe them in ArchivesSpace. > They have a Title and an Identifier, but we don't use the File Version > field for them because there is no File URI. > > This is an example of what ArchivesSpace exports as EAD for a digital > object which has an Identifier of "ms0599aip_001" but has no "File > version / file URI". > <dao xlink:actuate="onRequest" *xlink:href="ms0599aip_001"* > xlink:show="new" xlink:title="Louis Albach Buffalo Bayou research > materials" xlink:type="simple"> > > So it is mapping the Identifier to an xlink:href attribute, and > therefore makes a dead link in the EAD. > > Has anyone successfully edited the mapping to make this stop? I would > want the Identifier to simply show as "Identifier" and not try to be a link. > > Thanks, > Amanda > From akroeger at unomaha.edu Wed Jan 3 16:15:54 2018 From: akroeger at unomaha.edu (Angela Kroeger) Date: Wed, 3 Jan 2018 21:15:54 +0000 Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions In-Reply-To: <933AE837-010A-48B7-A7FC-E632AC5F77F7@lib.msu.edu> References: <MWHPR05MB3423C696C57D74F217D49D1CD61E0@MWHPR05MB3423.namprd05.prod.outlook.com> <819352670.5784485.1515007416595.JavaMail.zimbra@psu.edu> <933AE837-010A-48B7-A7FC-E632AC5F77F7@lib.msu.edu> Message-ID: <MWHPR07MB345364C8A3C13353E9FACCE2D31E0@MWHPR07MB3453.namprd07.prod.outlook.com> Hi, Lydia, We do something like you describe. When we have multiple collections in the same container, then the container numbering follows the pattern MISC-01, MISC-02, MISC-03, etc. Searching by the MISC-XX number (with the number, in quotation marks) retrieves a list of all collections housed in that box. As for how to keep track of our last-used MISC-XX number, we don't have a good way of doing that within ArchivesSpace. We've got an external list. Not optimal, I know. However, I think your "Shared Container" nomenclature would completely fix that problem. A keyword search of "MISC" without an attached number brings up too many false hits in our system, but "Shared Container" is a sufficiently unique phrase that the keyword search would zero in on just the containers you're looking for. (Wish I'd thought of that before starting the MISC numbering. :-) --Angela Angela Kroeger Archives and Special Collections Associate UNO Libraries | Criss Library 107 University of Nebraska at Omaha | unomaha.edu 402.554.4159 akroeger at unomaha.edu From harmeyna at purdue.edu Wed Jan 3 16:48:01 2018 From: harmeyna at purdue.edu (Harmeyer, Neal A) Date: Wed, 3 Jan 2018 21:48:01 +0000 Subject: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions In-Reply-To: <MWHPR07MB345364C8A3C13353E9FACCE2D31E0@MWHPR07MB3453.namprd07.prod.outlook.com> References: <MWHPR05MB3423C696C57D74F217D49D1CD61E0@MWHPR05MB3423.namprd05.prod.outlook.com> <819352670.5784485.1515007416595.JavaMail.zimbra@psu.edu> <933AE837-010A-48B7-A7FC-E632AC5F77F7@lib.msu.edu> <MWHPR07MB345364C8A3C13353E9FACCE2D31E0@MWHPR07MB3453.namprd07.prod.outlook.com> Message-ID: <d2c1072b59a64f6faab8b72757f2fa19@wppexc09.purdue.lcl> Hi Lydia, We do something similar to what Angela has described and you noted in your message. We have numerous shared containers, and our solution to avoid any confusion is to place a "Communal" descriptor in the Indicator for the container AND its use designation, e.g. Communal Collections, Communal Accessions. We then assign a sequential number in the indicator field as well, so we end up with Communal Collections 1, Communal Collections 2, and so on. Using the Manage Top Containers, we keep track of the next available sequential number to be used for a communal container. A search in the Manage Top Containers keyword field with "Communal Collections" for example, only brings up those containers we've designated as communal containers for collections. We use a combination of the notes field in the Top Container and a specific location in our repository to keep track of those communal containers that still have space, are full, or are used only for restricted materials. We have also developed a system for tracking the placements of materials within communal containers. Thus far, it's all working quite nicely. Cheers, Neal -- Neal Harmeyer Digital Archivist Purdue University Archives and Special Collections Purdue University Libraries harmeyna at purdue.edu<mailto:harmeyna at purdue.edu> -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Angela Kroeger Sent: Wednesday, January 3, 2018 4:16 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Top Containers and Item Level Descriptions Hi, Lydia, We do something like you describe. When we have multiple collections in the same container, then the container numbering follows the pattern MISC-01, MISC-02, MISC-03, etc. Searching by the MISC-XX number (with the number, in quotation marks) retrieves a list of all collections housed in that box. As for how to keep track of our last-used MISC-XX number, we don't have a good way of doing that within ArchivesSpace. We've got an external list. Not optimal, I know. However, I think your "Shared Container" nomenclature would completely fix that problem. A keyword search of "MISC" without an attached number brings up too many false hits in our system, but "Shared Container" is a sufficiently unique phrase that the keyword search would zero in on just the containers you're looking for. (Wish I'd thought of that before starting the MISC numbering. :-) --Angela Angela Kroeger Archives and Special Collections Associate UNO Libraries | Criss Library 107 University of Nebraska at Omaha | unomaha.edu 402.554.4159 akroeger at unomaha.edu<mailto:akroeger at unomaha.edu> On a slightly tangential question re: shared Top Containers, I would love to hear how institutions keep track of numbering their shared containers - especially if some are stored offsite. I am hoping that if I create a Share Container X, by searching "Shared Container" in Top Containers, it should pull all with those keywords together in order to see the last used box number, but I would love to hear how others have accomplished this. Thanks! Lydia _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180103/99758697/attachment.html> From j at minorscience.com Wed Jan 3 17:35:16 2018 From: j at minorscience.com (Jason Loeffler) Date: Wed, 3 Jan 2018 17:35:16 -0500 Subject: [Archivesspace_Users_Group] Archivesspace: Log run Amok In-Reply-To: <056cecde-a26d-85ca-daa1-80dfdf934f9c@jhu.edu> References: <mailman.4716.1514929941.20855.archivesspace_users_group@lyralists.lyrasis.org> <056cecde-a26d-85ca-daa1-80dfdf934f9c@jhu.edu> Message-ID: <CAP4gJsU=HVuP_-nATcDZOEYLPByG8fO+R0aqrFzjFtw94X067g@mail.gmail.com> I am able to reproduce this issue on 2.2.2. I tried a few of the other log levels at config.rb and receive only info level output. I've opened a bug report here: https://archivesspace. atlassian.net/projects/ANW/issues/ANW-293 Jason Loeffler Technology Consultant | The American Academy in Rome Minor Science | Application Development & Metadata Strategy Brooklyn, New York jason at minorscience.com (347) 405-0826 minorscience (Skype) On Wed, Jan 3, 2018 at 4:15 PM, Mark Cyzyk <mcyzyk at jhu.edu> wrote: > > All, > > Yesterday our archivesspace.out log file ran amok and consumed our disk > space. (It grew to a whopping 11 GB.) I took a peek at it and am seeing > that it's logging at the "Info" level when my config says it should only be > logging at "Fatal": > > ## Log level for the backend, values: (everything) debug, info, warn, >> error, fatal (severe only) >> AppConfig[:backend_log_level] = "fatal" >> > > This is sounding like a bug to me. > > If anyone has ideas on how to force logging to only fatal events, I'd like > to know. MUCH appreciated. > > Mark > > <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> > Mark Cyzyk, M.A., M.L.S. > Scholarly Communication Architect > Library Applications Group > The Sheridan Libraries > The Johns Hopkins University > mcyzyk at jhu.edu > > Verba volant, scripta manent. > > > On 1/2/2018 4:52 PM, archivesspace_users_group-requ > est at lyralists.lyrasis.org wrote: > >> Send Archivesspace_Users_Group mailing list submissions to >> archivesspace_users_group at lyralists.lyrasis.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_ >> users_group >> >> or, via email, send a message with subject or body 'help' to >> archivesspace_users_group-request at lyralists.lyrasis.org >> >> You can reach the person managing the list at >> archivesspace_users_group-owner at lyralists.lyrasis.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Archivesspace_Users_Group digest..." >> >> >> Today's Topics: >> >> 1. Re: ArchivesSpace user manual error page (Christine Kim) >> 2. Re: ArchivesSpace user manual error page (Christine Kim) >> 3. Re: Collections Browse Error in Public Interface, v2.2.1 >> (Custer, Mark) >> 4. Re: Collections Browse Error in Public Interface, v2.2.1 >> (Leilani Dawson) >> 5. truncation in PUI 2.2.1 (Maderik, Rachel A) >> 6. Re: truncation in PUI 2.2.1 (Christine Di Bella) >> 7. Merging Controlled Values (Stasiulatis, Suzanne) >> 8. installing wildcard SSL cert, redirect http to https (Brian >> Slenk) >> 9. digital object mapping to EAD in v.2.2.1 (Amanda Focke) >> 10. Splitting off one repository into a new database >> (Celia Caust-Ellenbogen) >> 11. Position statement on multitenancy (Christie Peterson) >> 12. Re: Merging Controlled Values (Michelson, Daniel) >> 13. Re: Splitting off one repository into a new database >> (Majewski, Steven Dennis (sdm7g)) >> 14. Re: Webinar Announcement: Varying Approaches to Testing >> ASpace Pre-Releases - Dec 14 (Christine Kim) >> 15. Re: installing wildcard SSL cert, redirect http to https >> (Jason Loeffler) >> 16. Ideas for advanced training topics? (Christine Kim) >> 17. Re: installing wildcard SSL cert, redirect http to https >> (Cook, Robert) >> 18. ArchivesSpace 2.2.2 now available (Christine Di Bella) >> 19. Re: ArchivesSpace 2.2.2 now available (Christie Peterson) >> 20. Re: ArchivesSpace 2.2.2 now available (Christine Di Bella) >> 21. ASpace 2.1.2 issue with digital object links (Knox, Ashley M.) >> 22. Creating staff entities for Assessments module? (Tang, Lydia) >> 23. Trouble changing localhost:9081 to new URL (Walker, Scott) >> 24. New version of aspace-import-excel, a plugin to support bulk >> loading of Archival Objects (Fox, Bobbi) >> 25. Re: New version of aspace-import-excel, a plugin to support >> bulk loading of Archival Objects (Majewski, Steven Dennis (sdm7g)) >> 26. reports (Steve Majewski) >> 27. Re: DAO Notes in EAD (Christine Kim) >> 28. Re: Creating staff entities for Assessments module? >> (Pruitt, Adrienne) >> 29. Re: Creating staff entities for Assessments module? (Tang, Lydia) >> 30. reports (Majewski, Steven Dennis (sdm7g)) >> 31. release of updated Archivists' Toolkit to ArchivesSpace >> migration tool (Christine Di Bella) >> 32. Re: reports (Christie Peterson) >> 33. Happy Holidays from ArchivesSpace! (Christine Kim) >> 34. Re: reports (Majewski, Steven Dennis (sdm7g)) >> 35. Update on reports (Laney McGlohon) >> 36. Re: Update on reports (Jordon Steele) >> 37. release of updated Archon to ArchivesSpace migration tool >> (Christine Di Bella) >> 38. Overriding/Extending the new public interface in 2.2.0 >> (Flanagan, Patrick) >> 39. Re: Overriding/Extending the new public interface in 2.2.0 >> (Fox, Bobbi) >> 40. Re: Overriding/Extending the new public interface in 2.2.0 >> (Flanagan, Patrick) >> 41. Re: Overriding/Extending the new public interface in 2.2.0 >> (Majewski, Steven Dennis (sdm7g)) >> 42. ArchivesSpace Update - December 2017 (Christine Kim) >> 43. latest version and format for the ArchivesSpace roadmap >> (Christine Di Bella) >> 44. Re: Overriding/Extending the new public interface in 2.2.0 >> (Flanagan, Patrick) >> 45. Error when saving records in 2.2.2 (Trevor Thornton) >> 46. Re: Error when saving records in 2.2.2 (Custer, Mark) >> 47. Re: Error when saving records in 2.2.2 (Trevor Thornton) >> 48. Processing notes (Christie Peterson) >> 49. Re: Processing notes (Kevin Clair) >> 50. Re: Processing notes (Christie Peterson) >> 51. Re: Processing notes (Kevin Clair) >> 52. Re: Processing notes (Jordon Steele) >> 53. Related Agents link strangeness (Kevin Clair) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 11 Dec 2017 15:18:11 +0000 >> From: Christine Kim <Christine.Kim at lyrasis.org> >> To: Archivesspace Users Group >> <archivesspace_users_group at lyralists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual >> error page >> Message-ID: >> <MWHPR08MB24959E52E7B20C1D47239E65F5370 at MWHPR08MB2495.namprd >> 08.prod.outlook.com> >> >> Content-Type: text/plain; charset="utf-8" >> >> I?m receiving the same. I will submit a support ticket for this. Thanks >> for reporting! >> >> Christine Kim >> ArchivesSpace Community Engagement Coordinator >> christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> >> 800.999.8558 x4820 >> 404.592.4820 >> Skype: ckim.lyrasis >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of >> Mayo, Dave >> Sent: Monday, December 11, 2017 7:15 AM >> To: Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual error >> page >> >> I can confirm that I?m getting the same thing. >> >> - Dave Mayo >> >> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of >> Jasmine Jones <jjones at smith.edu<mailto:jjones at smith.edu>> >> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org >> >> >> Date: Monday, December 11, 2017 at 10:07 AM >> To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:arch >> ivesspace_users_group at lyralists.lyrasis.org>" < >> archivesspace_users_group at lyralists.lyrasis.org<mailto:arch >> ivesspace_users_group at lyralists.lyrasis.org>> >> Subject: [Archivesspace_Users_Group] ArchivesSpace user manual error page >> >> Hi all: >> >> I'm having trouble with the ArchivesSpace user manual this morning and >> get directed to an error page (http://docs.archivesspace.org/Default.htm< >> https://urldefense.proofpoint.com/v2/url?u=http >> -3A__docs.archivesspace.org_Default.htm&d=DwMFaQ&c=WO-RGve >> fibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYn >> E&m=Uwkulyf5Wv3_OV4RVr9ZeAak82IKUfn4c2nGpZ6RRy4&s=DmQELUqxVl >> saOSW0SYFX6TjQFAgffB6bXn_YmXU29m0&e=> and screenshot attached). Has >> anyone else had issues? >> >> Thank you, >> >> Jasmine Jones >> >> [nline image 1] >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/37c61133/attachment-0001.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image001.png >> Type: image/png >> Size: 278340 bytes >> Desc: image001.png >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/37c61133/attachment-0001.png> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 11 Dec 2017 15:35:33 +0000 >> From: Christine Kim <Christine.Kim at lyrasis.org> >> To: Archivesspace Users Group >> <archivesspace_users_group at lyralists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual >> error page >> Message-ID: >> <MWHPR08MB249578F47CA23D152809C1A3F5370 at MWHPR08MB2495.namprd >> 08.prod.outlook.com> >> >> Content-Type: text/plain; charset="utf-8" >> >> Hi all, >> >> The problem has been resolved. >> >> For the info curious ? it seems there was a problem with bad bots or >> something hitting it this morning. >> >> Thanks so much for reporting, and have a great Monday! >> >> Best wishes, >> Kim >> >> Christine Kim >> ArchivesSpace Community Engagement Coordinator >> christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> >> 800.999.8558 x4820 >> 404.592.4820 >> Skype: ckim.lyrasis >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of >> Christine Kim >> Sent: Monday, December 11, 2017 7:18 AM >> To: Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual error >> page >> >> I?m receiving the same. I will submit a support ticket for this. Thanks >> for reporting! >> >> Christine Kim >> ArchivesSpace Community Engagement Coordinator >> christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> >> 800.999.8558 x4820 >> 404.592.4820 >> Skype: ckim.lyrasis >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of >> Mayo, Dave >> Sent: Monday, December 11, 2017 7:15 AM >> To: Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org >> >> >> Subject: Re: [Archivesspace_Users_Group] ArchivesSpace user manual error >> page >> >> I can confirm that I?m getting the same thing. >> >> - Dave Mayo >> >> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of >> Jasmine Jones <jjones at smith.edu<mailto:jjones at smith.edu>> >> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org >> >> >> Date: Monday, December 11, 2017 at 10:07 AM >> To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:arch >> ivesspace_users_group at lyralists.lyrasis.org>" < >> archivesspace_users_group at lyralists.lyrasis.org<mailto:arch >> ivesspace_users_group at lyralists.lyrasis.org>> >> Subject: [Archivesspace_Users_Group] ArchivesSpace user manual error page >> >> Hi all: >> >> I'm having trouble with the ArchivesSpace user manual this morning and >> get directed to an error page (http://docs.archivesspace.org/Default.htm< >> https://urldefense.proofpoint.com/v2/url?u=http >> -3A__docs.archivesspace.org_Default.htm&d=DwMFaQ&c=WO-RGve >> fibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYn >> E&m=Uwkulyf5Wv3_OV4RVr9ZeAak82IKUfn4c2nGpZ6RRy4&s=DmQELUqxVl >> saOSW0SYFX6TjQFAgffB6bXn_YmXU29m0&e=> and screenshot attached). Has >> anyone else had issues? >> >> Thank you, >> >> Jasmine Jones >> >> [nline image 1] >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/9ccc17bf/attachment-0001.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image001.png >> Type: image/png >> Size: 278340 bytes >> Desc: image001.png >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/9ccc17bf/attachment-0001.png> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 11 Dec 2017 15:58:06 +0000 >> From: "Custer, Mark" <mark.custer at yale.edu> >> To: Archivesspace Users Group >> <archivesspace_users_group at lyralists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in >> Public Interface, v2.2.1 >> Message-ID: >> <BN3PR08MB1303914D77E761964B6D5E538C370 at BN3PR08MB1303.namprd >> 08.prod.outlook.com> >> >> Content-Type: text/plain; charset="windows-1252" >> >> Leilani, >> >> >> Could you attach an example EAD file? I'm curious what happens when >> Unicode characters are used in place of the character entities. I'm >> wondering if the issue might simply be that the font used doesn't include >> italic characters for the character entities that are tagged as italic (as >> an aside, what fonts do you use outside of ArchivesSpace?). Either way, it >> would be nice to add these examples to some test scripts for ArchivesSpace. >> >> >> Mark >> >> >> ________________________________ >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org < >> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of >> Leilani Dawson <ltdawson at hawaii.edu> >> Sent: Friday, December 8, 2017 3:45 PM >> To: Archivesspace Users Group >> Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in >> Public Interface, v2.2.1 >> >> Yes, all of our accessibility-wrapped diacritics are in html tags. >> >> (Occasionally we have notes where words labeled with alternate text are >> nested within EAD elements such as <title> or <persname> or the like, but >> those EAD elements are not as critical for us as the <span> with aria-label >> attribute.) >> >> I'll ask our IT folks to put together a 2.2 test instance so I can upload >> a finding aid with diacritics and see whether the new PUI handles it in a >> screen-reader-friendly manner. >> >> Thanks, >> -Leilani >> >> On Fri, Dec 8, 2017 at 9:12 AM, Christine Di Bella < >> christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>> >> wrote: >> >> Hi Leilani, >> >> >> >> Thanks for making me dig into this a bit more and for explaining one of >> the reasons tagging around a diacritic may be especially necessary. For >> your use case, is your tagging always like your example? If so, there?s >> sanitizer for HTML in the PUI that allows this kind of tagging to sail >> through just fine. It is XML tags like <emph> that we?re seeing this bug on. >> >> >> >> There was some accessibility work that went into the development of the >> new PUI, but it would be good to know that what makes this kind of tagging >> work in the PUI doesn?t also cause the same issue for screen readers that >> is the reason for you wrapping the text originally. Can you test this out >> locally or upload a finding aid to http://test.archivesspace.org< >> https://urldefense.proofpoint.com/v2/url?u=http-3A__test.arc >> hivesspace.org&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcr >> mRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_G >> vang7BVjr4txYuvjxyM8&s=ojcyFCMoM3zS9hpwYf4E7AnqB96za3sLtX6PZ20VkFM&e=> >> and try it out? >> >> >> >> Christine >> >> >> >> Christine Di Bella >> >> ArchivesSpace Program Manager >> >> christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> >> >> 800.999.8558 x2905<tel:(800)%20999-8558> >> >> 678-235-2905<tel:(678)%20235-2905> >> >> cdibella13 (Skype) >> >> >> >> [ASpaceOrgHomeMedium] >> >> >> >> >> >> >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of >> Leilani Dawson >> Sent: Friday, December 8, 2017 1:13 PM >> To: Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org >> >> >> Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in >> Public Interface, v2.2.1 >> >> >> >> Hi Christine, >> >> I see this is listed in JIRA as a minor issue, but is there any guess for >> when it might be addressed? >> >> Certain Hawaiian-language diacritics "break" screen readers, so in order >> to satisfy both accessibility requirements and UH's mandate to be a >> Hawaiian place of learning, the Library has started wrapping these >> diacritics in <span> tags with aria-label attributes. (E.g.: <span >> aria-label="Hawaii">Hawaiʻi</span>) ArchivesSpace 2.1 and 2.2 not >> being able to handle wrapped diacritics might preclude us from going >> forward with using the public user interface and/or upgrading to 2.x. until >> the fix is in. >> >> -Leilani. >> >> - - >> >> Leilani Dawson >> >> Manuscript Collections Archivist >> >> University Archives & Manuscripts Department >> >> University of Hawaii at Manoa Library >> >> 2550 McCarthy Mall, Honolulu, HI 96822 >> >> ltdawson at hawaii.edu<mailto:ltdawson at hawaii.edu> >> >> >> >> On Fri, Dec 8, 2017 at 3:28 AM, Christine Di Bella < >> christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>> >> wrote: >> >> Hi Neal, >> >> >> >> Do you by chance have a collection that has the circumstance described in >> this JIRA ticket: https://archivesspace.atlassian.net/browse/AR-1938< >> https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.at >> lassian.net_browse_AR-2D1938&d=DwMFaQ&c=cjytLXgP8ixuoHflwc- >> poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC >> 4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=VMpZ3HzcFod2VlOa_ >> Q5TAqIkbX5K9NFmJ-9RGxTgJRI&e=> (A diacritic wrapped in a tag.) Most >> likely it would be in the scope and contents note or abstract field if the >> error is happening from the collection browse. >> >> >> >> If so, and that record appears on the first page of your all collection >> browse, that may be what?s causing the issue. You would also get a ?We?re >> sorry something went wrong? when trying to view that particular record or >> on a search that includes that particular record. If you have multiple >> repositories, that would also explain why a collection browse that?s scoped >> to another repository would not yield that issue. >> >> >> >> This is a reported issue for all 2.1 and 2.2 versions. The workaround for >> now would be to remove either the tagging or the diacritic, but we hope to >> fix this issue for a future release. >> >> >> >> If you don?t have that circumstance, we?ll need to delve into this more >> deeply. >> >> >> >> Christine >> >> >> >> Christine Di Bella >> >> ArchivesSpace Program Manager >> >> christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org> >> >> 800.999.8558 x2905<tel:(800)%20999-8558> >> >> 678-235-2905<tel:(678)%20235-2905> >> >> cdibella13 (Skype) >> >> >> >> [ASpaceOrgHomeMedium] >> >> >> >> >> >> >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of >> Harmeyer, Neal A >> Sent: Thursday, December 7, 2017 5:45 PM >> To: Archivesspace Users Group <archivesspace_users_group at lyr >> alists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org >> >> >> Subject: [Archivesspace_Users_Group] Collections Browse Error in Public >> Interface, v2.2.1 >> >> >> >> Hello all, >> >> >> >> I wonder if anyone else has experienced this issue? >> >> >> >> When selecting the Collections browse (/repositories/resources) from the >> header in the public interface, version 2.2.1, the system throws an error >> message that reads 'Your request could not be completed due to an >> unexpected error'. This only occurs for Collections browse; all other areas >> continue to load without issue?so our systems administrator isn?t sure this >> could be cause by any web server configurations. I?ve been able to cause >> the failure on our dev site by repeatedly selecting the Collections browse >> over a short period of time. >> >> >> >> We didn?t experience this in any past versions. A restart of the server >> removes the issue for a period of time but then it re-appears; there is >> nothing in our logs to point to a cause of the problem. >> >> >> >> Any suggestions would be helpful! >> >> >> >> Thank you, >> >> Neal >> >> >> >> -- >> >> Neal Harmeyer >> >> Digital Archivist >> >> Purdue Univesity Archives and Special Collections >> >> Purdue University Libraries >> >> harmeyna at purdue.edu<mailto:harmeyna at purdue.edu> >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archi >> vesspace_Users_Group at lyralists.lyrasis.org> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group< >> https://urldefense.proofpoint.com/v2/url?u=http- >> 3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace >> -5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r= >> 7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzr >> pcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W- >> qI7NJvab5eSZgQuU&e=> >> >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archi >> vesspace_Users_Group at lyralists.lyrasis.org> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group< >> https://urldefense.proofpoint.com/v2/url?u=http- >> 3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace >> -5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r= >> 7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzr >> pcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W- >> qI7NJvab5eSZgQuU&e=> >> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/375fb341/attachment-0001.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image005.jpg >> Type: image/jpeg >> Size: 6608 bytes >> Desc: image005.jpg >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/375fb341/attachment-0002.jpg> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image006.jpg >> Type: image/jpeg >> Size: 6608 bytes >> Desc: image006.jpg >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/375fb341/attachment-0003.jpg> >> >> ------------------------------ >> >> Message: 4 >> Date: Mon, 11 Dec 2017 09:02:37 -1000 >> From: Leilani Dawson <ltdawson at hawaii.edu> >> To: Archivesspace Users Group >> <archivesspace_users_group at lyralists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] Collections Browse Error in >> Public Interface, v2.2.1 >> Message-ID: >> <CADGuORE3ZJ84itYeHSmf-zduRHE-PPzPo545zj3T2F-3UiajCA at mail.gm >> ail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Sure, here's an export of a tiny collection showing a couple of wrapped >> diacritics in the custodial history. >> >> We haven't yet done any testing of the PUI--or the staff interface, for >> that matter--with screen readers; what we know of how the ?okina (the >> glottal stop marker, ʻ) interacts with them comes mostly from >> Library-wide testing of WordPress and LibGuides. (And from that testing >> we know that vowels with macrons don't normally confuse screen readers, so >> we haven't been coding words containing them, e.g. M?noa, with aria-label >> attributes.) >> >> I'm not sure what fonts we're using in WordPress and LibGuides. I'd >> assume >> they're pretty standard, but I'll ask. >> >> -Leilani. >> >> On Mon, Dec 11, 2017 at 5:58 AM, Custer, Mark <mark.custer at yale.edu> >> wrote: >> >> Leilani, >>> >>> >>> Could you attach an example EAD file? I'm curious what happens when >>> Unicode characters are used in place of the character entities. I'm >>> wondering if the issue might simply be that the font used doesn't include >>> italic characters for the character entities that are tagged as italic >>> (as >>> an aside, what fonts do you use outside of ArchivesSpace?). Either way, >>> it would be nice to add these examples to some test scripts for >>> ArchivesSpace. >>> >>> >>> Mark >>> >>> >>> ------------------------------ >>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < >>> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of >>> Leilani Dawson <ltdawson at hawaii.edu> >>> *Sent:* Friday, December 8, 2017 3:45 PM >>> *To:* Archivesspace Users Group >>> *Subject:* Re: [Archivesspace_Users_Group] Collections Browse Error in >>> Public Interface, v2.2.1 >>> >>> Yes, all of our accessibility-wrapped diacritics are in html tags. >>> >>> (Occasionally we have notes where words labeled with alternate text are >>> nested within EAD elements such as <title> or <persname> or the like, but >>> those EAD elements are not as critical for us as the <span> with >>> aria-label >>> attribute.) >>> >>> I'll ask our IT folks to put together a 2.2 test instance so I can upload >>> a finding aid with diacritics and see whether the new PUI handles it in a >>> screen-reader-friendly manner. >>> >>> Thanks, >>> -Leilani >>> >>> On Fri, Dec 8, 2017 at 9:12 AM, Christine Di Bella < >>> christine.dibella at lyrasis.org> wrote: >>> >>> Hi Leilani, >>> >>> >>> >>> Thanks for making me dig into this a bit more and for explaining one of >>> the reasons tagging around a diacritic may be especially necessary. For >>> your use case, is your tagging always like your example? If so, there?s >>> sanitizer for HTML in the PUI that allows this kind of tagging to sail >>> through just fine. It is XML tags like <emph> that we?re seeing this bug >>> on. >>> >>> >>> >>> There was some accessibility work that went into the development of the >>> new PUI, but it would be good to know that what makes this kind of >>> tagging >>> work in the PUI doesn?t also cause the same issue for screen readers that >>> is the reason for you wrapping the text originally. Can you test this out >>> locally or upload a finding aid to http://test.archivesspace.org >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__test.ar >>> chivesspace.org&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVc >>> rmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_ >>> Gvang7BVjr4txYuvjxyM8&s=ojcyFCMoM3zS9hpwYf4E7AnqB96za3sLtX6PZ20VkFM&e=> >>> and try it out? >>> >>> >>> >>> Christine >>> >>> >>> >>> Christine Di Bella >>> >>> ArchivesSpace Program Manager >>> >>> christine.dibella at lyrasis.org >>> >>> 800.999.8558 x2905 <(800)%20999-8558> >>> >>> 678-235-2905 <(678)%20235-2905> >>> >>> cdibella13 (Skype) >>> >>> >>> >>> [image: ASpaceOrgHomeMedium] >>> >>> >>> >>> >>> >>> >>> >>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of >>> *Leilani >>> Dawson >>> *Sent:* Friday, December 8, 2017 1:13 PM >>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr >>> alists.lyrasis.org> >>> *Subject:* Re: [Archivesspace_Users_Group] Collections Browse Error in >>> Public Interface, v2.2.1 >>> >>> >>> >>> Hi Christine, >>> >>> I see this is listed in JIRA as a minor issue, but is there any guess for >>> when it might be addressed? >>> >>> Certain Hawaiian-language diacritics "break" screen readers, so in order >>> to satisfy both accessibility requirements and UH's mandate to be a >>> Hawaiian place of learning, the Library has started wrapping these >>> diacritics in <span> tags with aria-label attributes. (E.g.: <span >>> aria-label="Hawaii">Hawaiʻi</span>) ArchivesSpace 2.1 and 2.2 not >>> being able to handle wrapped diacritics might preclude us from going >>> forward with using the public user interface and/or upgrading to 2.x. >>> until >>> the fix is in. >>> >>> >>> -Leilani. >>> >>> - - >>> >>> Leilani Dawson >>> >>> Manuscript Collections Archivist >>> >>> University Archives & Manuscripts Department >>> >>> University of Hawaii at Manoa Library >>> >>> 2550 McCarthy Mall, Honolulu, HI 96822 >>> >>> ltdawson at hawaii.edu >>> >>> >>> >>> On Fri, Dec 8, 2017 at 3:28 AM, Christine Di Bella < >>> christine.dibella at lyrasis.org> wrote: >>> >>> Hi Neal, >>> >>> >>> >>> Do you by chance have a collection that has the circumstance described in >>> this JIRA ticket: https://archivesspace.atlassian.net/browse/AR-1938 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archiv >>> esspace.atlassian.net_browse_AR-2D1938&d=DwMFaQ&c=cjytLXgP8 >>> ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU& >>> m=3hrk0xcC4ZChzrpcCh0CQ_Gvang7BVjr4txYuvjxyM8&s=VMpZ3H >>> zcFod2VlOa_Q5TAqIkbX5K9NFmJ-9RGxTgJRI&e=> >>> (A diacritic wrapped in a tag.) Most likely it would be in the scope and >>> contents note or abstract field if the error is happening from the >>> collection browse. >>> >>> >>> >>> If so, and that record appears on the first page of your all collection >>> browse, that may be what?s causing the issue. You would also get a ?We?re >>> sorry something went wrong? when trying to view that particular record or >>> on a search that includes that particular record. If you have multiple >>> repositories, that would also explain why a collection browse that?s >>> scoped >>> to another repository would not yield that issue. >>> >>> >>> >>> This is a reported issue for all 2.1 and 2.2 versions. The workaround for >>> now would be to remove either the tagging or the diacritic, but we hope >>> to >>> fix this issue for a future release. >>> >>> >>> >>> If you don?t have that circumstance, we?ll need to delve into this more >>> deeply. >>> >>> >>> >>> Christine >>> >>> >>> >>> Christine Di Bella >>> >>> ArchivesSpace Program Manager >>> >>> christine.dibella at lyrasis.org >>> >>> 800.999.8558 x2905 <(800)%20999-8558> >>> >>> 678-235-2905 <(678)%20235-2905> >>> >>> cdibella13 (Skype) >>> >>> >>> >>> [image: ASpaceOrgHomeMedium] >>> >>> >>> >>> >>> >>> >>> >>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of >>> *Harmeyer, >>> Neal A >>> *Sent:* Thursday, December 7, 2017 5:45 PM >>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr >>> alists.lyrasis.org> >>> *Subject:* [Archivesspace_Users_Group] Collections Browse Error in Public >>> Interface, v2.2.1 >>> >>> >>> >>> Hello all, >>> >>> >>> >>> I wonder if anyone else has experienced this issue? >>> >>> >>> >>> When selecting the Collections browse (/repositories/resources) from the >>> header in the public interface, version 2.2.1, the system throws an error >>> message that reads 'Your request could not be completed due to an >>> unexpected error'. This only occurs for Collections browse; all other >>> areas >>> continue to load without issue?so our systems administrator isn?t sure >>> this >>> could be cause by any web server configurations. I?ve been able to cause >>> the failure on our dev site by repeatedly selecting the Collections >>> browse >>> over a short period of time. >>> >>> >>> >>> We didn?t experience this in any past versions. A restart of the server >>> removes the issue for a period of time but then it re-appears; there is >>> nothing in our logs to point to a cause of the problem. >>> >>> >>> >>> Any suggestions would be helpful! >>> >>> >>> >>> Thank you, >>> >>> Neal >>> >>> >>> >>> -- >>> >>> Neal Harmeyer >>> >>> Digital Archivist >>> >>> Purdue Univesity Archives and Special Collections >>> >>> Purdue University Libraries >>> >>> harmeyna at purdue.edu >>> >>> >>> >>> >>> _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> Archivesspace_Users_Group at lyralists.lyrasis.org >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralis >>> ts.lyrasis.org_mailman_listinfo_archivesspace-5Fusers- >>> 5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1 >>> FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_ >>> Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W-qI7NJvab5eSZgQuU&e=> >>> >>> >>> >>> _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> Archivesspace_Users_Group at lyralists.lyrasis.org >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralis >>> ts.lyrasis.org_mailman_listinfo_archivesspace-5Fusers- >>> 5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1 >>> FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=3hrk0xcC4ZChzrpcCh0CQ_ >>> Gvang7BVjr4txYuvjxyM8&s=mcku_27mMAV6rVbPS8IwL0Tx_W-qI7NJvab5eSZgQuU&e=> >>> >>> >>> >>> _______________________________________________ >>> 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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/2418fb0d/attachment-0001.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image005.jpg >> Type: image/jpeg >> Size: 6608 bytes >> Desc: not available >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/2418fb0d/attachment-0002.jpg> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image006.jpg >> Type: image/jpeg >> Size: 6608 bytes >> Desc: not available >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/2418fb0d/attachment-0003.jpg> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: MANUSCRIPT.M00060_20171211_184828_UTC__ead.xml >> Type: text/xml >> Size: 3409 bytes >> Desc: not available >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/2418fb0d/attachment-0001.xml> >> >> ------------------------------ >> >> Message: 5 >> Date: Mon, 11 Dec 2017 20:02:37 +0000 >> From: "Maderik, Rachel A" <maderikra at vmi.edu> >> To: "'Archivesspace_Users_Group at lyralists.lyrasis.org'" >> <Archivesspace_Users_Group at lyralists.lyrasis.org> >> Subject: [Archivesspace_Users_Group] truncation in PUI 2.2.1 >> Message-ID: <be6834aa52ef42b38fa0691dd7e77eca at vmi.edu> >> Content-Type: text/plain; charset="us-ascii" >> >> Has anyone else had problems with search term truncation not working in >> the PUI in v2.2.1? I can replicate the problem on the public sandbox: I >> created a record entitled "Test Record Morrill": >> http://public.archivesspace.org/repositories/3/resources/105, but >> searching for "morril*" brings back 0 results (it also inserts a backslash >> before the truncation character, which may be related to the problem): >> >> [cid:image003.jpg at 01D37291.14C1DCB0] >> >> Rachel Maderik >> Systems and Technology Librarian >> 501D Preston Library >> Virginia Military Institute >> Lexington, VA 24450 >> 540-464-7572 >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/79470ac7/attachment-0001.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image003.jpg >> Type: image/jpeg >> Size: 31259 bytes >> Desc: image003.jpg >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/79470ac7/attachment-0001.jpg> >> >> ------------------------------ >> >> Message: 6 >> Date: Mon, 11 Dec 2017 20:23:28 +0000 >> From: Christine Di Bella <christine.dibella at lyrasis.org> >> To: Archivesspace Users Group >> <archivesspace_users_group at lyralists.lyrasis.org> >> Subject: Re: [Archivesspace_Users_Group] truncation in PUI 2.2.1 >> Message-ID: >> <CY1PR08MB119796FBE72BA32B04E2B9ACF1370 at CY1PR08MB1197.namprd >> 08.prod.outlook.com> >> >> Content-Type: text/plain; charset="us-ascii" >> >> Dear Rachel, >> >> This was a bug inadvertently introduced in 2.2.1 that will be resolved in >> 2.2.2, which we anticipate putting out before the holiday break. We >> overcorrected when we put in a fix to allow searching for another character >> that was previously causing errors. >> >> Apologies, >> Christine >> >> 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] >> >> >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: >> archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of >> Maderik, Rachel A >> Sent: Monday, December 11, 2017 3:03 PM >> To: 'Archivesspace_Users_Group at lyralists.lyrasis.org' < >> Archivesspace_Users_Group at lyralists.lyrasis.org> >> Subject: [Archivesspace_Users_Group] truncation in PUI 2.2.1 >> >> Has anyone else had problems with search term truncation not working in >> the PUI in v2.2.1? I can replicate the problem on the public sandbox: I >> created a record entitled "Test Record Morrill": >> http://public.archivesspace.org/repositories/3/resources/105, but >> searching for "morril*" brings back 0 results (it also inserts a backslash >> before the truncation character, which may be related to the problem): >> >> [cid:image002.jpg at 01D37293.FA1F2360] >> >> Rachel Maderik >> Systems and Technology Librarian >> 501D Preston Library >> Virginia Military Institute >> Lexington, VA 24450 >> 540-464-7572 >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/61d7e45a/attachment-0001.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image001.jpg >> Type: image/jpeg >> Size: 6608 bytes >> Desc: image001.jpg >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/61d7e45a/attachment-0002.jpg> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image002.jpg >> Type: image/jpeg >> Size: 31259 bytes >> Desc: image002.jpg >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171211/61d7e45a/attachment-0003.jpg> >> >> ------------------------------ >> >> Message: 7 >> Date: Tue, 12 Dec 2017 19:57:42 +0000 >> From: "Stasiulatis, Suzanne" <sustasiula at pa.gov> >> To: Archivesspace Users Group >> <archivesspace_users_group at lyralists.lyrasis.org> >> Subject: [Archivesspace_Users_Group] Merging Controlled Values >> Message-ID: <103c127cd54443c7b8e301e93f2fbb4c at ENCTCEXCH008.PA.LCL> >> Content-Type: text/plain; charset="us-ascii" >> >> I remember a while back that people were having trouble merging >> controlled values. Is this a safe feature to use yet? Has anyone used it >> successfully in 2.2.x? >> >> Thanks, >> >> Suzanne >> >> Suzanne Stasiulatis | Archivist II >> Pennsylvania Historical and Museum Commission | Pennsylvania State >> Archives >> 350 North Street | Harrisburg, PA 17120-0090 >> Phone: 717-787-5953 >> http://www.PAStateArchives.com >> sustasiula at pa.gov<mailto:sustasiula at pa.gov> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171212/91be7f7a/attachment-0001.html> >> >> ------------------------------ >> >> Message: 8 >> Date: Tue, 12 Dec 2017 15:57:33 -0500 >> From: Brian Slenk <slenkb at hope.edu> >> To: archivesspace_users_group at lyralists.lyrasis.org >> Subject: [Archivesspace_Users_Group] installing wildcard SSL cert, >> redirect http to https >> Message-ID: >> <CAAK7xVSGJZF==PkKyY8E_2xkoqHLQYqaBZ0EC0=tERviJ+qs4A at mail.gm >> ail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> >> I have a new installation of an archives space server. Is there a way >> with the Apache Solr web server to add an SSL wildcard certificate, and >> then redirect http to https for the the public interface ? I am not >> finding documentation if this is possible. >> >> Brian >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_ >> group/attachments/20171212/efeb656c/attachment-0001.html> >> >> ------------------------------ >> >> Message: 9 >> Date: Tue, 12 Dec 2017 15:14:01 -0600 >> From: Amanda Focke <afocke at rice.edu> >> To: archivesspace_users_group at lyralists.lyrasis.org >> Subject: [Archivesspace_Users_Group] digital object mapping to EAD in >> v.2.2.1 >> Message-ID: <5A304699.8030907 at rice.edu> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> Hello all - >> >> We have "nearline" digital objects which do not have a public URL, and >> we describe them in ArchivesSpace. >> They have a Title and an Identifier, but we don't use the File Version >> field for them because there is no File URI. >> >> This is an example of what ArchivesSpace exports as EAD for a digital >> object which has an Identifier of "ms0599aip_001" but has no "File >> version / file URI". >> <dao xlink:actuate="onRequest" *xlink:href="ms0599aip_001"* >> xlink:show="new" xlink:title="Louis Albach Buffalo Bayou research >> materials" xlink:type="simple"> >> >> So it is mapping the Identifier to an xlink:href attribute, and >> therefore makes a dead link in the EAD. >> >> Has anyone successfully edited the mapping to make this stop? I would >> want the Identifier to simply show as "Identifier" and not try to be a >> link. >> >> Thanks, >> Amanda >> >> > _______________________________________________ > 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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180103/97076481/attachment.html> From maderikra at vmi.edu Thu Jan 4 09:23:22 2018 From: maderikra at vmi.edu (Maderik, Rachel A) Date: Thu, 4 Jan 2018 14:23:22 +0000 Subject: [Archivesspace_Users_Group] Related Agents link strangeness In-Reply-To: <DF4SPR00MB01282D3367819E34F11F307E41E0@DF4SPR00MB012.namprd08.prod.outlook.com> References: <DM5PR11MB1449BF17FC001143CD72E32095190@DM5PR11MB1449.namprd11.prod.outlook.com> <BL2PR07MB2340CE43887B811299CF947F80190@BL2PR07MB2340.namprd07.prod.outlook.com> <DF4SPR00MB01282D3367819E34F11F307E41E0@DF4SPR00MB012.namprd08.prod.outlook.com> Message-ID: <e33780a128ed48d8a2119614d63a5e17@vmi.edu> I just tested this plugin on 2.2.2, and it works on the staff interface but not the PUI. The inability to change the default operator is one of the reasons we haven't migrated to the new PUI yet, so hopefully someone out there has figured out how to do this. Rachel Maderik Systems and Technology Librarian 501D Preston Library Virginia Military Institute Lexington, VA 24450 540-464-7572 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rush, Michael Sent: Wednesday, January 03, 2018 8:57 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Related Agents link strangeness All, The default OR operator in ASpace's Solr settings is pretty unbearable. To address it, Yale contracted with Hudson Molonglo to develop a plugin to change that behavior to a default AND operator. See https://github.com/hudmol/and_search. For the record I'm not certain if this plugin affects the PUI search. Mike From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A. Sent: Tuesday, January 2, 2018 5:33 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Related Agents link strangeness I think it is really searching: University OR of OR Denver Try keying in University AND Denver and see if you have better luck. (Annoying default OR operator is annoying.) Kate From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:52 PM To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>) <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] Related Agents link strangeness Hello, We've noticed some peculiar behavior when adding Related Agent links to Corporate Entity records in ArchivesSpace. When typing the name of the Agent we wish to link in the Related Agents form, the typeahead drop-down list populates with unrelated terms. For example, if we were to try and enter a University of Denver constituent unit as the later form of a name for a different DU corporate entity, typing "university of denver" into the text field brings up a drop-down list of mostly Family records. This only happens when the search string contains spaces; searches on a single word bring up more or less the results we would expect. Two screenshots are attached: one with the results when "university" is the search, and one with the results when "university of denver" is the search (the drop-down results are the same whether or not the period is included). Has anyone else noticed anything like this? thanks! -k -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/4fddf588/attachment.html> From trthorn2 at ncsu.edu Thu Jan 4 09:45:21 2018 From: trthorn2 at ncsu.edu (Trevor Thornton) Date: Thu, 4 Jan 2018 09:45:21 -0500 Subject: [Archivesspace_Users_Group] Related Agents link strangeness In-Reply-To: <DM5PR11MB1449BF17FC001143CD72E32095190@DM5PR11MB1449.namprd11.prod.outlook.com> References: <DM5PR11MB1449BF17FC001143CD72E32095190@DM5PR11MB1449.namprd11.prod.outlook.com> Message-ID: <CA+SdyS3xPnECMJ8k71Dv7puuqouqDH=1uMAQfLhxGov=sZGCfQ@mail.gmail.com> We've had this problem in the staff interface. The typeahead functionality is basically useless in a lot of cases, but searching with the 'browse' modal generally works better. If you're searching for a phrase it always works better to wrap it in double quotes to avoid the default OR issue. On Tue, Jan 2, 2018 at 4:52 PM, Kevin Clair <Kevin.Clair at du.edu> wrote: > Hello, > > > > We?ve noticed some peculiar behavior when adding Related Agent links to > Corporate Entity records in ArchivesSpace. When typing the name of the > Agent we wish to link in the Related Agents form, the typeahead drop-down > list populates with unrelated terms. For example, if we were to try and > enter a University of Denver constituent unit as the later form of a name > for a different DU corporate entity, typing ?university of denver? into the > text field brings up a drop-down list of mostly Family records. This only > happens when the search string contains spaces; searches on a single word > bring up more or less the results we would expect. > > > > Two screenshots are attached: one with the results when ?university? is > the search, and one with the results when ?university of denver? is the > search (the drop-down results are the same whether or not the period is > included). > > > > Has anyone else noticed anything like this? > > > > thanks! -k > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Trevor Thornton Applications Developer, Digital Library Initiatives North Carolina State University Libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/63152142/attachment.html> From christine.dibella at lyrasis.org Thu Jan 4 13:11:25 2018 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Thu, 4 Jan 2018 18:11:25 +0000 Subject: [Archivesspace_Users_Group] next steps for Staff Interface Enhancement Group recommendations Message-ID: <CY1PR08MB1197C268A826DF9CB1B6D843F11F0@CY1PR08MB1197.namprd08.prod.outlook.com> Dear ArchivesSpace members, The Staff Interface Enhancement Group delivered its final recommendations at the end of December. You can view them at https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/369557505/SIEWG+Final+Recommendations. This was an incredibly large task and we want to thank the group's fearless leader, Lydia Tang, as well as all of the individual group members for their substantial work in examining, discussing, considering, gathering feedback, and writing up a vision for an improved staff interface for ArchivesSpace. Now and in the coming months the ArchivesSpace program team is reviewing the recommendations and putting them together into a series of development projects. Once that's done we'll be working with the Development Prioritization subteam to assign them priority levels. In addition there are a number of items that the group has recommended be put forth to the larger base of ArchivesSpace users or to outside consultants for further consideration before a development plan is made. In the coming months, these will be put before you as well, in ways appropriate to the kind of issue to be considered. We are also very thankful that a number of members of the original group have agreed to stay on to help as questions arise or clarifications of approach are needed. As we have a sense of priorities and capacities we'll assign projects to developers and begin getting work into the application. We expect that improvements based on the group's recommendations will be included in every major release of ArchivesSpace this year after our next anticipated release, in late January. Some projects or individual features/fixes will be especially appropriate for community developers, or for financial support from individual or groups of institutions. We'll be posting more information on these in the months to come, but if you see something in the recommendations that you know your institution would like to be particularly involved in making happen, please let me know. Thanks again to the Staff Interface Enhancement Group for all its work, and to the community overall for participating in this important effort. We look forward to working with you on the many good things that will come out of it. Christine 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/20180104/82b7936e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6608 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/82b7936e/attachment.jpg> From livsolis at utexas.edu Thu Jan 4 15:04:39 2018 From: livsolis at utexas.edu (Olivia S Solis) Date: Thu, 4 Jan 2018 14:04:39 -0600 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Message-ID: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> Hello all, I was wondering if some of you have a situation we have. Occasionally, some of our staff will appear as subjects/creators in resources and accessions. We have some staff members who are published scholars and appear in name authority files. In such cases, we'd want to use the URIs for those names (no such field in user records). We also have specific rules we follow for local names for subjects/creators. How do you/do you distinguish between staff members when they are acting in their capacity as staff (e.g. as the recipient of the agreement received event) vs. as subject/creator? Staff users appear to be agents that are selectable in any kind of record type. Our current strategy is to include a "(staff)" addition to "Full name" for users. For instance, mine would be "Olivia Solis (staff)", the reason being to make it absolutely clear this is not the non-existent "Solis, Olivia" in VIAF who is also an agent, but not a user. I don't like including information that is not part of a name in the name field, but otherwise, I think people would accidentally select the user agent in instances where they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. Is there a better solution to "staff" for disambiguation purposes? Somehow display the person's title in the type-ahead list that appears when you start typing in a linked agent name? I'm not sure how difficult that would be. We plan to retire (change passwords for), but not delete staff user accounts when the staff members no longer work here so we don't get rid of their data trail. But in 20 years it would be nice for staff to know that the retired "Olivia Solis (staff)" is also the same person as creator of one of our collections. Or maybe a donor, in which case I would not want to use the user account. Thanks, Olivia -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/d2321038/attachment.html> From jsteele at jhu.edu Thu Jan 4 16:13:12 2018 From: jsteele at jhu.edu (Jordon Steele) Date: Thu, 4 Jan 2018 21:13:12 +0000 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators In-Reply-To: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> References: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> Message-ID: <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> Hi Olivia, We have one agent record and assign different roles or relator terms based on the context. So for a given collection, Person X may have the role ?Source? and relator ?Curator? if that person was involved in acquiring a collection. If the person was the subject of the collection, we?d re-use the existing agent record and assign the role ?Subject.? If we ended up getting that person?s papers, in that scenario, we?d assign the same agent record but with role ?Creator.? We think of the agent one entity who may have different roles depending on the collection/event/context. Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis Sent: Thursday, January 04, 2018 3:05 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hello all, I was wondering if some of you have a situation we have. Occasionally, some of our staff will appear as subjects/creators in resources and accessions. We have some staff members who are published scholars and appear in name authority files. In such cases, we'd want to use the URIs for those names (no such field in user records). We also have specific rules we follow for local names for subjects/creators. How do you/do you distinguish between staff members when they are acting in their capacity as staff (e.g. as the recipient of the agreement received event) vs. as subject/creator? Staff users appear to be agents that are selectable in any kind of record type. Our current strategy is to include a "(staff)" addition to "Full name" for users. For instance, mine would be "Olivia Solis (staff)", the reason being to make it absolutely clear this is not the non-existent "Solis, Olivia" in VIAF who is also an agent, but not a user. I don't like including information that is not part of a name in the name field, but otherwise, I think people would accidentally select the user agent in instances where they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. Is there a better solution to "staff" for disambiguation purposes? Somehow display the person's title in the type-ahead list that appears when you start typing in a linked agent name? I'm not sure how difficult that would be. We plan to retire (change passwords for), but not delete staff user accounts when the staff members no longer work here so we don't get rid of their data trail. But in 20 years it would be nice for staff to know that the retired "Olivia Solis (staff)" is also the same person as creator of one of our collections. Or maybe a donor, in which case I would not want to use the user account. Thanks, Olivia -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/fa4064d0/attachment.html> From livsolis at utexas.edu Thu Jan 4 16:28:58 2018 From: livsolis at utexas.edu (Olivia S Solis) Date: Thu, 4 Jan 2018 15:28:58 -0600 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators In-Reply-To: <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> References: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> Message-ID: <CAKu+i=0Xys8gyqMF7nVbC0yJ7DRLXoG8Dj4wb1ua-CZ4QEUQ=Q@mail.gmail.com> Hi Jordon, Thanks for the response! Do you use URIs for your terms? Forgive me if this was not clear before (or if it was that I am being repetitive). We've been doing a lot of work to clean up normalize data set ourselves up for a linked data universe where we reference all of our names with URIs and we specify the name authorities we are using. In particular, we've chosen VIAF. So say Celine Dion is our Registrar who uses ArchivesSpace daily to create and search for records. She also donated her papers to us. She needs a user account, but we want to refer to her by her URI: https://viaf.org/viaf/12491209 in her papers, in particular to anything we publish. If she has a user account, there is no field for the URI or the authority. If I'm not mistaken, all users who get "Local" rules, but we would want to specify "VIAF" as the source of the term. Thanks, and again, sorry if I am over-explaining! -Olivia [image: Inline image 1] On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <jsteele at jhu.edu> wrote: > Hi Olivia, > > > > We have one agent record and assign different roles or relator terms based > on the context. So for a given collection, Person X may have the role > ?Source? and relator ?Curator? if that person was involved in acquiring a > collection. If the person was the subject of the collection, we?d re-use > the existing agent record and assign the role ?Subject.? If we ended up > getting that person?s papers, in that scenario, we?d assign the same agent > record but with role ?Creator.? We think of the agent one entity who may > have different roles depending on the collection/event/context. > > > > Best, > > > > Jordon > > > > Jordon Steele > > Hodson Curator of the University Archives > > Special Collections > > The Sheridan Libraries > > Johns Hopkins University > > 3400 N Charles St > > Baltimore, MD 21218 > > 410-516-5493 <(410)%20516-5493> > > jsteele at jhu.edu > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia > S Solis > *Sent:* Thursday, January 04, 2018 3:05 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] Staff users/agents as > subjects/creators > > > > Hello all, > > > > I was wondering if some of you have a situation we have. Occasionally, > some of our staff will appear as subjects/creators in resources and > accessions. We have some staff members who are published scholars and > appear in name authority files. In such cases, we'd want to use the URIs > for those names (no such field in user records). We also have specific > rules we follow for local names for subjects/creators. > > > > How do you/do you distinguish between staff members when they are acting > in their capacity as staff (e.g. as the recipient of the agreement received > event) vs. as subject/creator? Staff users appear to be agents that are > selectable in any kind of record type. > > > > Our current strategy is to include a "(staff)" addition to "Full name" for > users. For instance, mine would be "Olivia Solis (staff)", the reason being > to make it absolutely clear this is not the non-existent "Solis, Olivia" in > VIAF who is also an agent, but not a user. I don't like including > information that is not part of a name in the name field, but otherwise, I > think people would accidentally select the user agent in instances where > they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. > Is there a better solution to "staff" for disambiguation purposes? Somehow > display the person's title in the type-ahead list that appears when you > start typing in a linked agent name? I'm not sure how difficult that would > be. > > > > We plan to retire (change passwords for), but not delete staff user > accounts when the staff members no longer work here so we don't get rid of > their data trail. But in 20 years it would be nice for staff to know that > the retired "Olivia Solis (staff)" is also the same person as creator of > one of our collections. Or maybe a donor, in which case I would not want to > use the user account. > > > > Thanks, > > Olivia > > > > -- > > Olivia Solis, MSIS > > Metadata Coordinator > > Dolph Briscoe Center for American History > > The University of Texas at Austin > > 2300 Red River St. Stop D1100 > > Austin TX, 78712-1426 > > (512) 232-8013 <(512)%20232-8013> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/476637ab/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-01-04 at 3.18.49 PM.png Type: image/png Size: 54537 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/476637ab/attachment.png> From jsteele at jhu.edu Thu Jan 4 20:18:21 2018 From: jsteele at jhu.edu (Jordon Steele) Date: Fri, 5 Jan 2018 01:18:21 +0000 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators In-Reply-To: <CAKu+i=0Xys8gyqMF7nVbC0yJ7DRLXoG8Dj4wb1ua-CZ4QEUQ=Q@mail.gmail.com> References: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> <CAKu+i=0Xys8gyqMF7nVbC0yJ7DRLXoG8Dj4wb1ua-CZ4QEUQ=Q@mail.gmail.com> Message-ID: <26fc860b95b448d28387de3b1a127f2c@esgmtwex18.win.ad.jhu.edu> Olivia, Yes, we do use URIs for our agent records, and, like you, they are sourced from VIAF. We separate user accounts from agent records. A user account is for someone to edit or view ASpace data. An agent record is reserved to document creators or subjects of collections or staff involved in collection-related activities. We?ve discussed and decided not to create and manage agent records for roles related to collection management activities such as processing or updating records; those names just appear as free text in processing notes (or in the audit trail of the ASpace record, which shows the last username to edit a given record). We generally only create agent records for staff to document curatorial activities like acquisition and deaccessioning. So there could indeed be a scenario where we have an agent record for a staff member and a separate user account for that staff member, which we?ve decided we can live with, especially because agent records are managed in a module separate from user accounts. It?s a similar situation to a library catalog?s authority file, where a staff member may be listed because he or she happened to, like, author a book that the library owns, but that staff member may also have logins managed separately to access library applications. But I understand the gray area?we?ve just decided to accept it. Hope that helps! Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis Sent: Thursday, January 04, 2018 4:29 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hi Jordon, Thanks for the response! Do you use URIs for your terms? Forgive me if this was not clear before (or if it was that I am being repetitive). We've been doing a lot of work to clean up normalize data set ourselves up for a linked data universe where we reference all of our names with URIs and we specify the name authorities we are using. In particular, we've chosen VIAF. So say Celine Dion is our Registrar who uses ArchivesSpace daily to create and search for records. She also donated her papers to us. She needs a user account, but we want to refer to her by her URI: https://viaf.org/viaf/12491209 in her papers, in particular to anything we publish. If she has a user account, there is no field for the URI or the authority. If I'm not mistaken, all users who get "Local" rules, but we would want to specify "VIAF" as the source of the term. Thanks, and again, sorry if I am over-explaining! -Olivia [Inline image 1] On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote: Hi Olivia, We have one agent record and assign different roles or relator terms based on the context. So for a given collection, Person X may have the role ?Source? and relator ?Curator? if that person was involved in acquiring a collection. If the person was the subject of the collection, we?d re-use the existing agent record and assign the role ?Subject.? If we ended up getting that person?s papers, in that scenario, we?d assign the same agent record but with role ?Creator.? We think of the agent one entity who may have different roles depending on the collection/event/context. Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493<tel:(410)%20516-5493> jsteele at jhu.edu<mailto:jsteele at jhu.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis Sent: Thursday, January 04, 2018 3:05 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hello all, I was wondering if some of you have a situation we have. Occasionally, some of our staff will appear as subjects/creators in resources and accessions. We have some staff members who are published scholars and appear in name authority files. In such cases, we'd want to use the URIs for those names (no such field in user records). We also have specific rules we follow for local names for subjects/creators. How do you/do you distinguish between staff members when they are acting in their capacity as staff (e.g. as the recipient of the agreement received event) vs. as subject/creator? Staff users appear to be agents that are selectable in any kind of record type. Our current strategy is to include a "(staff)" addition to "Full name" for users. For instance, mine would be "Olivia Solis (staff)", the reason being to make it absolutely clear this is not the non-existent "Solis, Olivia" in VIAF who is also an agent, but not a user. I don't like including information that is not part of a name in the name field, but otherwise, I think people would accidentally select the user agent in instances where they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. Is there a better solution to "staff" for disambiguation purposes? Somehow display the person's title in the type-ahead list that appears when you start typing in a linked agent name? I'm not sure how difficult that would be. We plan to retire (change passwords for), but not delete staff user accounts when the staff members no longer work here so we don't get rid of their data trail. But in 20 years it would be nice for staff to know that the retired "Olivia Solis (staff)" is also the same person as creator of one of our collections. Or maybe a donor, in which case I would not want to use the user account. Thanks, Olivia -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013<tel:(512)%20232-8013> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/972ae7ff/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 42455 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/972ae7ff/attachment.png> From livsolis at utexas.edu Fri Jan 5 00:42:58 2018 From: livsolis at utexas.edu (Olivia S Solis) Date: Thu, 4 Jan 2018 23:42:58 -0600 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators In-Reply-To: <26fc860b95b448d28387de3b1a127f2c@esgmtwex18.win.ad.jhu.edu> References: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> <CAKu+i=0Xys8gyqMF7nVbC0yJ7DRLXoG8Dj4wb1ua-CZ4QEUQ=Q@mail.gmail.com> <26fc860b95b448d28387de3b1a127f2c@esgmtwex18.win.ad.jhu.edu> Message-ID: <CAKu+i=2UTqZEc1PVVT9jBixNgOvYef8wJRwOAXQs=WheGH0gGg@mail.gmail.com> Hi Jordon, Thank you!! Your response is indeed very helpful and I totally understand the logic behind your decision. Just a little background, we are almost ASpace live. We are about to set up all of our user accounts. At some point along the way, I read ASpace documentation advising not to use users as linked agents. I can't at the moment remember exactly where, but I can see that as useful advice. We ignored it for a couple reasons cited below. We, in contrast to y'all, have decided to use staff agents for human-initiated collection management activities that may need to be documented in major record types. In particular, events. I think there were a couple of things throwing us off here. For one, events require some kind of linked agent, and we are using events for various stages of accessioning and the ultimate stages of processing, as you have chosen not to do in all cases (at least through events records which do not use relators). For something like a processing step completed in an event, how would the required linked agent not be some kind of staff user? We also wanted it very clearly documented that certain staff played certain roles in events. The second is that all users are included in the list of possible candidates when one starts typing in a linked agent in accessions, resources, and archival objects. So below, my record is pulled up because I started typing in my name (in this case in a new accession record) in a new linked agent sub-record: [image: Inline image 1] I was created as simply a user in ASpace, not an agent. Anyone could add me to a record as a creator or subject regardless of an institutional policy not to add users as linked agents. Relooking at ASpace, apparently being a user also makes me an agent in ASpace, with all the functionality ASpace endows to agents. I could edit my agent record's URI or create relationships with other agents, etc. I'm seeing a lot of pros and cons here. I can give myself as a user a VIAF URI in my agent (not user) record. (It also appears that editing my user "Full name" doesn't automatically update the equivalent "Primary name" field in my agent record). But if you go with a policy that users are not agents and should not be used as linked agents, how do you get staff creating and editing records not to add the users that appear as candidates when they start typing in the linked agent fields as linked agents? Users are options here. Our solution was that "staff" addition. In terms of authority control, it seems very precarious to allow any user to be added as a linked agent to any record, particularly to a published record. If it's possible to add any user as a linked agent, despite institutional policy not to, someone will. (Months of cleaning up legacy data has made me a skeptic.) Even if that same user has a sanctioned, legit, separate agent record. Has this been a problem for anyone else? Do you have ambiguous relationships between agents and users? And Jordon, given your library's policy, has this ever been an issue for you... staff accidentally adding users as linked agents? Again, we've got staff members who are regularly creators, subjects, donors, etc. I'm also curious about the relationship between users and their correlated agent records and how/if various interrelated/common fields are reciprocally updated. Thanks, and if there is documentation that exists about this apologies! -Olivia On Thu, Jan 4, 2018 at 7:18 PM, Jordon Steele <jsteele at jhu.edu> wrote: > Olivia, > > > > Yes, we do use URIs for our agent records, and, like you, they are sourced > from VIAF. > > > > We separate user accounts from agent records. A user account is for > someone to edit or view ASpace data. An agent record is reserved to > document creators or subjects of collections or staff involved in > collection-related activities. We?ve discussed and decided not to create > and manage agent records for roles related to collection management > activities such as processing or updating records; those names just appear > as free text in processing notes (or in the audit trail of the ASpace > record, which shows the last username to edit a given record). We generally > only create agent records for staff to document curatorial activities like > acquisition and deaccessioning. > > > > So there could indeed be a scenario where we have an agent record for a > staff member and a separate user account for that staff member, which we?ve > decided we can live with, especially because agent records are managed in a > module separate from user accounts. It?s a similar situation to a library > catalog?s authority file, where a staff member may be listed because he or > she happened to, like, author a book that the library owns, but that staff > member may also have logins managed separately to access library > applications. But I understand the gray area?we?ve just decided to accept > it. > > > > Hope that helps! > > > > Best, > > > > Jordon > > > > Jordon Steele > > Hodson Curator of the University Archives > > Special Collections > > The Sheridan Libraries > > Johns Hopkins University > > 3400 N Charles St > > Baltimore, MD 21218 > > 410-516-5493 <(410)%20516-5493> > > jsteele at jhu.edu > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia > S Solis > *Sent:* Thursday, January 04, 2018 4:29 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Staff users/agents as > subjects/creators > > > > Hi Jordon, > > > > Thanks for the response! Do you use URIs for your terms? Forgive me if > this was not clear before (or if it was that I am being repetitive). We've > been doing a lot of work to clean up normalize data set ourselves up for a > linked data universe where we reference all of our names with URIs and we > specify the name authorities we are using. In particular, we've chosen > VIAF. So say Celine Dion is our Registrar who uses ArchivesSpace daily to > create and search for records. She also donated her papers to us. She needs > a user account, but we want to refer to her by her URI: > > https://viaf.org/viaf/12491209 > > in her papers, in particular to anything we publish. If she has a user > account, there is no field for the URI or the authority. If I'm not > mistaken, all users who get "Local" rules, but we would want to specify > "VIAF" as the source of the term. > > > > Thanks, and again, sorry if I am over-explaining! > > > > -Olivia > > > > [image: Inline image 1] > > > > On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <jsteele at jhu.edu> wrote: > > Hi Olivia, > > > > We have one agent record and assign different roles or relator terms based > on the context. So for a given collection, Person X may have the role > ?Source? and relator ?Curator? if that person was involved in acquiring a > collection. If the person was the subject of the collection, we?d re-use > the existing agent record and assign the role ?Subject.? If we ended up > getting that person?s papers, in that scenario, we?d assign the same agent > record but with role ?Creator.? We think of the agent one entity who may > have different roles depending on the collection/event/context. > > > > Best, > > > > Jordon > > > > Jordon Steele > > Hodson Curator of the University Archives > > Special Collections > > The Sheridan Libraries > > Johns Hopkins University > > 3400 N Charles St > > Baltimore, MD 21218 > > 410-516-5493 <(410)%20516-5493> > > jsteele at jhu.edu > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia > S Solis > *Sent:* Thursday, January 04, 2018 3:05 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] Staff users/agents as > subjects/creators > > > > Hello all, > > > > I was wondering if some of you have a situation we have. Occasionally, > some of our staff will appear as subjects/creators in resources and > accessions. We have some staff members who are published scholars and > appear in name authority files. In such cases, we'd want to use the URIs > for those names (no such field in user records). We also have specific > rules we follow for local names for subjects/creators. > > > > How do you/do you distinguish between staff members when they are acting > in their capacity as staff (e.g. as the recipient of the agreement received > event) vs. as subject/creator? Staff users appear to be agents that are > selectable in any kind of record type. > > > > Our current strategy is to include a "(staff)" addition to "Full name" for > users. For instance, mine would be "Olivia Solis (staff)", the reason being > to make it absolutely clear this is not the non-existent "Solis, Olivia" in > VIAF who is also an agent, but not a user. I don't like including > information that is not part of a name in the name field, but otherwise, I > think people would accidentally select the user agent in instances where > they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. > Is there a better solution to "staff" for disambiguation purposes? Somehow > display the person's title in the type-ahead list that appears when you > start typing in a linked agent name? I'm not sure how difficult that would > be. > > > > We plan to retire (change passwords for), but not delete staff user > accounts when the staff members no longer work here so we don't get rid of > their data trail. But in 20 years it would be nice for staff to know that > the retired "Olivia Solis (staff)" is also the same person as creator of > one of our collections. Or maybe a donor, in which case I would not want to > use the user account. > > > > Thanks, > > Olivia > > > > -- > > Olivia Solis, MSIS > > Metadata Coordinator > > Dolph Briscoe Center for American History > > The University of Texas at Austin > > 2300 Red River St. Stop D1100 > > Austin TX, 78712-1426 > > (512) 232-8013 <(512)%20232-8013> > > > _______________________________________________ > 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 <(512)%20232-8013> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/49e08f20/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 42455 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/49e08f20/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23873 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180104/49e08f20/attachment-0001.png> From mark.custer at yale.edu Fri Jan 5 09:49:41 2018 From: mark.custer at yale.edu (Custer, Mark) Date: Fri, 5 Jan 2018 14:49:41 +0000 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators In-Reply-To: <CAKu+i=2UTqZEc1PVVT9jBixNgOvYef8wJRwOAXQs=WheGH0gGg@mail.gmail.com> References: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> <CAKu+i=0Xys8gyqMF7nVbC0yJ7DRLXoG8Dj4wb1ua-CZ4QEUQ=Q@mail.gmail.com> <26fc860b95b448d28387de3b1a127f2c@esgmtwex18.win.ad.jhu.edu> <CAKu+i=2UTqZEc1PVVT9jBixNgOvYef8wJRwOAXQs=WheGH0gGg@mail.gmail.com> Message-ID: <BN3PR08MB13030FF18AB2E1AC43E211E38C1C0@BN3PR08MB1303.namprd08.prod.outlook.com> Olivia, all: I?m not sure what documentation suggested to not use users are linked agents, but as far as I?m aware, that?s impossible. You can only link agents in that respect. That said, whenever a user record is created, an agent record is also created. Those records are linked in the database, but they are *not* synched at all in the application. Here?s an example: * I just created a user record in http://test.archivesspace.org/ * The username (a required field) = username * The full name (also required, since it?s used for the corresponding Agent record) = User Nam? * This action created user 65 in the database; you can edit that record, if you?re logged in as a system administrator, by going to http://test.archivesspace.org/users/65/edit * This action also created agent_person 1153 in the database: http://test.archivesspace.org/agents/agent_person/1153 The name used for this Agent is copied over from the corresponding user record?s ?full name? field. This is just a one-time convenience, though. I later changed the full name in the user record, but as you?ll see, that has no effect on the Agent record. And so, that also means that you can edit the Agent record with whatever additional details that you want, including the Authority ID, whatever. * And so, those two records are linked (from the context of the user record in the database), but they will never be synched from here on out. * Lastly, and importantly, if you delete that user record, it will delete the Agent record. * I assumed this would *not* happen if the Agent was linked to another record in the system, but it looks like that?s not the case (I was able to do it just now, so I?d say that?s a bug that needs to be addressed!). In any event, we have a policy currently of never deleting user records right now, so we?ll definitely need to keep up with that policy ?. Maybe the documentation that you read was suggesting not linking user-based Agent records for this very reason. Regardless, I?d love to check out that documentation if you remember where it came from. * However, if you try to delete an Agent record that?s linked to a User record, you won?t be able to do so until the User record is no longer in the system. So that works as I?d expect! All that said, we definitely link Agents who have corresponding user records, just like Jordon suggested. Once ASpace has the ability to synch with external systems such as id.loc.gov and/or SNAC, as detailed in the expanded agent module specifications, we may have to rethink how we do that currently, since we also have a practice of updating our local Agent records with their Yale NetID in one of the Agent?s bioghist notes, but I don?t think that will be too problematic for us since those records are still linked in the database. I?d also want to make sure that deleting the User record would not use that Agent record, especially if it?s linked to an external system, but that?s another matter altogether. We also link those Agents to other record types like Events. For just one example, when our Digital Accessioning Archivist runs scripts during the course of her work, it?s her Agent record in ASpace that is linked to those Events in ArchivesSpace (e.g. a PII scan is conducted on a disk image). There?s no way to link the user record here. If she were to edit the description of that archival component, however, then it would be her ?username? that is listed as the last user to edit that archival component. Hopefully that helps, Mark p.s. whenever you create a Repository record in ArchivesSpace, an agent_corporate_entity is similarly created, automatically. See http://test.archivesspace.org/agents/agent_corporate_entity/1 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis Sent: Friday, 05 January, 2018 12:43 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hi Jordon, Thank you!! Your response is indeed very helpful and I totally understand the logic behind your decision. Just a little background, we are almost ASpace live. We are about to set up all of our user accounts. At some point along the way, I read ASpace documentation advising not to use users as linked agents. I can't at the moment remember exactly where, but I can see that as useful advice. We ignored it for a couple reasons cited below. We, in contrast to y'all, have decided to use staff agents for human-initiated collection management activities that may need to be documented in major record types. In particular, events. I think there were a couple of things throwing us off here. For one, events require some kind of linked agent, and we are using events for various stages of accessioning and the ultimate stages of processing, as you have chosen not to do in all cases (at least through events records which do not use relators). For something like a processing step completed in an event, how would the required linked agent not be some kind of staff user? We also wanted it very clearly documented that certain staff played certain roles in events. The second is that all users are included in the list of possible candidates when one starts typing in a linked agent in accessions, resources, and archival objects. So below, my record is pulled up because I started typing in my name (in this case in a new accession record) in a new linked agent sub-record: [Inline image 1] I was created as simply a user in ASpace, not an agent. Anyone could add me to a record as a creator or subject regardless of an institutional policy not to add users as linked agents. Relooking at ASpace, apparently being a user also makes me an agent in ASpace, with all the functionality ASpace endows to agents. I could edit my agent record's URI or create relationships with other agents, etc. I'm seeing a lot of pros and cons here. I can give myself as a user a VIAF URI in my agent (not user) record. (It also appears that editing my user "Full name" doesn't automatically update the equivalent "Primary name" field in my agent record). But if you go with a policy that users are not agents and should not be used as linked agents, how do you get staff creating and editing records not to add the users that appear as candidates when they start typing in the linked agent fields as linked agents? Users are options here. Our solution was that "staff" addition. In terms of authority control, it seems very precarious to allow any user to be added as a linked agent to any record, particularly to a published record. If it's possible to add any user as a linked agent, despite institutional policy not to, someone will. (Months of cleaning up legacy data has made me a skeptic.) Even if that same user has a sanctioned, legit, separate agent record. Has this been a problem for anyone else? Do you have ambiguous relationships between agents and users? And Jordon, given your library's policy, has this ever been an issue for you... staff accidentally adding users as linked agents? Again, we've got staff members who are regularly creators, subjects, donors, etc. I'm also curious about the relationship between users and their correlated agent records and how/if various interrelated/common fields are reciprocally updated. Thanks, and if there is documentation that exists about this apologies! -Olivia On Thu, Jan 4, 2018 at 7:18 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote: Olivia, Yes, we do use URIs for our agent records, and, like you, they are sourced from VIAF. We separate user accounts from agent records. A user account is for someone to edit or view ASpace data. An agent record is reserved to document creators or subjects of collections or staff involved in collection-related activities. We?ve discussed and decided not to create and manage agent records for roles related to collection management activities such as processing or updating records; those names just appear as free text in processing notes (or in the audit trail of the ASpace record, which shows the last username to edit a given record). We generally only create agent records for staff to document curatorial activities like acquisition and deaccessioning. So there could indeed be a scenario where we have an agent record for a staff member and a separate user account for that staff member, which we?ve decided we can live with, especially because agent records are managed in a module separate from user accounts. It?s a similar situation to a library catalog?s authority file, where a staff member may be listed because he or she happened to, like, author a book that the library owns, but that staff member may also have logins managed separately to access library applications. But I understand the gray area?we?ve just decided to accept it. Hope that helps! Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493<tel:(410)%20516-5493> jsteele at jhu.edu<mailto:jsteele at jhu.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis Sent: Thursday, January 04, 2018 4:29 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hi Jordon, Thanks for the response! Do you use URIs for your terms? Forgive me if this was not clear before (or if it was that I am being repetitive). We've been doing a lot of work to clean up normalize data set ourselves up for a linked data universe where we reference all of our names with URIs and we specify the name authorities we are using. In particular, we've chosen VIAF. So say Celine Dion is our Registrar who uses ArchivesSpace daily to create and search for records. She also donated her papers to us. She needs a user account, but we want to refer to her by her URI: https://viaf.org/viaf/12491209<https://urldefense.proofpoint.com/v2/url?u=https-3A__viaf.org_viaf_12491209&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=JraIp2y8Vq0z_c_1MJ0B9dQv3SQe9zXGwhqxXr-qw-0&e=> in her papers, in particular to anything we publish. If she has a user account, there is no field for the URI or the authority. If I'm not mistaken, all users who get "Local" rules, but we would want to specify "VIAF" as the source of the term. Thanks, and again, sorry if I am over-explaining! -Olivia [Inline image 1] On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote: Hi Olivia, We have one agent record and assign different roles or relator terms based on the context. So for a given collection, Person X may have the role ?Source? and relator ?Curator? if that person was involved in acquiring a collection. If the person was the subject of the collection, we?d re-use the existing agent record and assign the role ?Subject.? If we ended up getting that person?s papers, in that scenario, we?d assign the same agent record but with role ?Creator.? We think of the agent one entity who may have different roles depending on the collection/event/context. Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493<tel:(410)%20516-5493> jsteele at jhu.edu<mailto:jsteele at jhu.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis Sent: Thursday, January 04, 2018 3:05 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hello all, I was wondering if some of you have a situation we have. Occasionally, some of our staff will appear as subjects/creators in resources and accessions. We have some staff members who are published scholars and appear in name authority files. In such cases, we'd want to use the URIs for those names (no such field in user records). We also have specific rules we follow for local names for subjects/creators. How do you/do you distinguish between staff members when they are acting in their capacity as staff (e.g. as the recipient of the agreement received event) vs. as subject/creator? Staff users appear to be agents that are selectable in any kind of record type. Our current strategy is to include a "(staff)" addition to "Full name" for users. For instance, mine would be "Olivia Solis (staff)", the reason being to make it absolutely clear this is not the non-existent "Solis, Olivia" in VIAF who is also an agent, but not a user. I don't like including information that is not part of a name in the name field, but otherwise, I think people would accidentally select the user agent in instances where they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. Is there a better solution to "staff" for disambiguation purposes? Somehow display the person's title in the type-ahead list that appears when you start typing in a linked agent name? I'm not sure how difficult that would be. We plan to retire (change passwords for), but not delete staff user accounts when the staff members no longer work here so we don't get rid of their data trail. But in 20 years it would be nice for staff to know that the retired "Olivia Solis (staff)" is also the same person as creator of one of our collections. Or maybe a donor, in which case I would not want to use the user account. Thanks, Olivia -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013<tel:(512)%20232-8013> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=> -- 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<tel:(512)%20232-8013> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=> -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/630406e7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 42455 bytes Desc: image004.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/630406e7/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 24761 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/630406e7/attachment-0001.png> From jsteele at jhu.edu Fri Jan 5 11:52:12 2018 From: jsteele at jhu.edu (Jordon Steele) Date: Fri, 5 Jan 2018 16:52:12 +0000 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators In-Reply-To: <BN3PR08MB13030FF18AB2E1AC43E211E38C1C0@BN3PR08MB1303.namprd08.prod.outlook.com> References: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> <CAKu+i=0Xys8gyqMF7nVbC0yJ7DRLXoG8Dj4wb1ua-CZ4QEUQ=Q@mail.gmail.com> <26fc860b95b448d28387de3b1a127f2c@esgmtwex18.win.ad.jhu.edu> <CAKu+i=2UTqZEc1PVVT9jBixNgOvYef8wJRwOAXQs=WheGH0gGg@mail.gmail.com> <BN3PR08MB13030FF18AB2E1AC43E211E38C1C0@BN3PR08MB1303.namprd08.prod.outlook.com> Message-ID: <5ecdd3c6de29433b84ee36cae5cfecfd@esgmtwex18.win.ad.jhu.edu> You guys are right: if you create user records, they show up as agent records, too. My bad, sorry to confuse matters. To the best of my knowledge we?ve never had staff add users as linked agents when they weren?t supposed to. No accounting for one-off lapses, of course, but it?s not a systemic problem. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark Sent: Friday, January 05, 2018 9:50 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Olivia, all: I?m not sure what documentation suggested to not use users are linked agents, but as far as I?m aware, that?s impossible. You can only link agents in that respect. That said, whenever a user record is created, an agent record is also created. Those records are linked in the database, but they are *not* synched at all in the application. Here?s an example: ? I just created a user record in http://test.archivesspace.org/ ? The username (a required field) = username ? The full name (also required, since it?s used for the corresponding Agent record) = User Nam? ? This action created user 65 in the database; you can edit that record, if you?re logged in as a system administrator, by going to http://test.archivesspace.org/users/65/edit ? This action also created agent_person 1153 in the database: http://test.archivesspace.org/agents/agent_person/1153 The name used for this Agent is copied over from the corresponding user record?s ?full name? field. This is just a one-time convenience, though. I later changed the full name in the user record, but as you?ll see, that has no effect on the Agent record. And so, that also means that you can edit the Agent record with whatever additional details that you want, including the Authority ID, whatever. ? And so, those two records are linked (from the context of the user record in the database), but they will never be synched from here on out. ? Lastly, and importantly, if you delete that user record, it will delete the Agent record. o I assumed this would *not* happen if the Agent was linked to another record in the system, but it looks like that?s not the case (I was able to do it just now, so I?d say that?s a bug that needs to be addressed!). In any event, we have a policy currently of never deleting user records right now, so we?ll definitely need to keep up with that policy ?. Maybe the documentation that you read was suggesting not linking user-based Agent records for this very reason. Regardless, I?d love to check out that documentation if you remember where it came from. ? However, if you try to delete an Agent record that?s linked to a User record, you won?t be able to do so until the User record is no longer in the system. So that works as I?d expect! All that said, we definitely link Agents who have corresponding user records, just like Jordon suggested. Once ASpace has the ability to synch with external systems such as id.loc.gov and/or SNAC, as detailed in the expanded agent module specifications, we may have to rethink how we do that currently, since we also have a practice of updating our local Agent records with their Yale NetID in one of the Agent?s bioghist notes, but I don?t think that will be too problematic for us since those records are still linked in the database. I?d also want to make sure that deleting the User record would not use that Agent record, especially if it?s linked to an external system, but that?s another matter altogether. We also link those Agents to other record types like Events. For just one example, when our Digital Accessioning Archivist runs scripts during the course of her work, it?s her Agent record in ASpace that is linked to those Events in ArchivesSpace (e.g. a PII scan is conducted on a disk image). There?s no way to link the user record here. If she were to edit the description of that archival component, however, then it would be her ?username? that is listed as the last user to edit that archival component. Hopefully that helps, Mark p.s. whenever you create a Repository record in ArchivesSpace, an agent_corporate_entity is similarly created, automatically. See http://test.archivesspace.org/agents/agent_corporate_entity/1 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis Sent: Friday, 05 January, 2018 12:43 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hi Jordon, Thank you!! Your response is indeed very helpful and I totally understand the logic behind your decision. Just a little background, we are almost ASpace live. We are about to set up all of our user accounts. At some point along the way, I read ASpace documentation advising not to use users as linked agents. I can't at the moment remember exactly where, but I can see that as useful advice. We ignored it for a couple reasons cited below. We, in contrast to y'all, have decided to use staff agents for human-initiated collection management activities that may need to be documented in major record types. In particular, events. I think there were a couple of things throwing us off here. For one, events require some kind of linked agent, and we are using events for various stages of accessioning and the ultimate stages of processing, as you have chosen not to do in all cases (at least through events records which do not use relators). For something like a processing step completed in an event, how would the required linked agent not be some kind of staff user? We also wanted it very clearly documented that certain staff played certain roles in events. The second is that all users are included in the list of possible candidates when one starts typing in a linked agent in accessions, resources, and archival objects. So below, my record is pulled up because I started typing in my name (in this case in a new accession record) in a new linked agent sub-record: [Inline image 1] I was created as simply a user in ASpace, not an agent. Anyone could add me to a record as a creator or subject regardless of an institutional policy not to add users as linked agents. Relooking at ASpace, apparently being a user also makes me an agent in ASpace, with all the functionality ASpace endows to agents. I could edit my agent record's URI or create relationships with other agents, etc. I'm seeing a lot of pros and cons here. I can give myself as a user a VIAF URI in my agent (not user) record. (It also appears that editing my user "Full name" doesn't automatically update the equivalent "Primary name" field in my agent record). But if you go with a policy that users are not agents and should not be used as linked agents, how do you get staff creating and editing records not to add the users that appear as candidates when they start typing in the linked agent fields as linked agents? Users are options here. Our solution was that "staff" addition. In terms of authority control, it seems very precarious to allow any user to be added as a linked agent to any record, particularly to a published record. If it's possible to add any user as a linked agent, despite institutional policy not to, someone will. (Months of cleaning up legacy data has made me a skeptic.) Even if that same user has a sanctioned, legit, separate agent record. Has this been a problem for anyone else? Do you have ambiguous relationships between agents and users? And Jordon, given your library's policy, has this ever been an issue for you... staff accidentally adding users as linked agents? Again, we've got staff members who are regularly creators, subjects, donors, etc. I'm also curious about the relationship between users and their correlated agent records and how/if various interrelated/common fields are reciprocally updated. Thanks, and if there is documentation that exists about this apologies! -Olivia On Thu, Jan 4, 2018 at 7:18 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote: Olivia, Yes, we do use URIs for our agent records, and, like you, they are sourced from VIAF. We separate user accounts from agent records. A user account is for someone to edit or view ASpace data. An agent record is reserved to document creators or subjects of collections or staff involved in collection-related activities. We?ve discussed and decided not to create and manage agent records for roles related to collection management activities such as processing or updating records; those names just appear as free text in processing notes (or in the audit trail of the ASpace record, which shows the last username to edit a given record). We generally only create agent records for staff to document curatorial activities like acquisition and deaccessioning. So there could indeed be a scenario where we have an agent record for a staff member and a separate user account for that staff member, which we?ve decided we can live with, especially because agent records are managed in a module separate from user accounts. It?s a similar situation to a library catalog?s authority file, where a staff member may be listed because he or she happened to, like, author a book that the library owns, but that staff member may also have logins managed separately to access library applications. But I understand the gray area?we?ve just decided to accept it. Hope that helps! Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493<tel:(410)%20516-5493> jsteele at jhu.edu<mailto:jsteele at jhu.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis Sent: Thursday, January 04, 2018 4:29 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hi Jordon, Thanks for the response! Do you use URIs for your terms? Forgive me if this was not clear before (or if it was that I am being repetitive). We've been doing a lot of work to clean up normalize data set ourselves up for a linked data universe where we reference all of our names with URIs and we specify the name authorities we are using. In particular, we've chosen VIAF. So say Celine Dion is our Registrar who uses ArchivesSpace daily to create and search for records. She also donated her papers to us. She needs a user account, but we want to refer to her by her URI: https://viaf.org/viaf/12491209<https://urldefense.proofpoint.com/v2/url?u=https-3A__viaf.org_viaf_12491209&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=JraIp2y8Vq0z_c_1MJ0B9dQv3SQe9zXGwhqxXr-qw-0&e=> in her papers, in particular to anything we publish. If she has a user account, there is no field for the URI or the authority. If I'm not mistaken, all users who get "Local" rules, but we would want to specify "VIAF" as the source of the term. Thanks, and again, sorry if I am over-explaining! -Olivia [Inline image 1] On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote: Hi Olivia, We have one agent record and assign different roles or relator terms based on the context. So for a given collection, Person X may have the role ?Source? and relator ?Curator? if that person was involved in acquiring a collection. If the person was the subject of the collection, we?d re-use the existing agent record and assign the role ?Subject.? If we ended up getting that person?s papers, in that scenario, we?d assign the same agent record but with role ?Creator.? We think of the agent one entity who may have different roles depending on the collection/event/context. Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493<tel:(410)%20516-5493> jsteele at jhu.edu<mailto:jsteele at jhu.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis Sent: Thursday, January 04, 2018 3:05 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators Hello all, I was wondering if some of you have a situation we have. Occasionally, some of our staff will appear as subjects/creators in resources and accessions. We have some staff members who are published scholars and appear in name authority files. In such cases, we'd want to use the URIs for those names (no such field in user records). We also have specific rules we follow for local names for subjects/creators. How do you/do you distinguish between staff members when they are acting in their capacity as staff (e.g. as the recipient of the agreement received event) vs. as subject/creator? Staff users appear to be agents that are selectable in any kind of record type. Our current strategy is to include a "(staff)" addition to "Full name" for users. For instance, mine would be "Olivia Solis (staff)", the reason being to make it absolutely clear this is not the non-existent "Solis, Olivia" in VIAF who is also an agent, but not a user. I don't like including information that is not part of a name in the name field, but otherwise, I think people would accidentally select the user agent in instances where they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. Is there a better solution to "staff" for disambiguation purposes? Somehow display the person's title in the type-ahead list that appears when you start typing in a linked agent name? I'm not sure how difficult that would be. We plan to retire (change passwords for), but not delete staff user accounts when the staff members no longer work here so we don't get rid of their data trail. But in 20 years it would be nice for staff to know that the retired "Olivia Solis (staff)" is also the same person as creator of one of our collections. Or maybe a donor, in which case I would not want to use the user account. Thanks, Olivia -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013<tel:(512)%20232-8013> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=> -- 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<tel:(512)%20232-8013> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=> -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/9faef7c7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 24761 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/9faef7c7/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 42455 bytes Desc: image002.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/9faef7c7/attachment-0001.png> From benn.joseph at northwestern.edu Fri Jan 5 11:59:26 2018 From: benn.joseph at northwestern.edu (Benn Joseph) Date: Fri, 5 Jan 2018 16:59:26 +0000 Subject: [Archivesspace_Users_Group] temporarily removing Digital Object from public view Message-ID: <b7f57ebdd8fd427a9fa331d0ef775fd2@evcspmbx04.ads.northwestern.edu> Hi all, We have a collection that contains a number of item-level Digital Objects (containing links to records in our repository) that are connected to Archival Objects, and I recently discovered that somewhere between v1.5 and v2.1.2 that the functionality of Digital Objects changed somewhat. As a result, these Digital Objects aren't functioning as they should. We'd like to hide them for a while until we're able to make some changes to our repository, but those changes won't take place for several months. In the meantime, we don't want to confuse researchers who might happen upon these non-functional Digital Objects. We're using the ArchivesSpace public interface. If I unpublish a Digital Object that is connected to an Archival Object, the preview image goes away in the public view (the red badge icon thing), but there's still a section down below for "Digital Material" that now contains a broken link (since the actual link is now unpublished!). If I instead suppress the Digital Object, the opposite happens-now the "Digital Material" section is gone but the preview image/red badge icon thing is still viewable in the Archival Object record, and is still functioning normally. I don't want to delete these Digital Objects since they contain information we want to keep-it's just the File URI links that are bad. Other than completely disassociating the Digital Objects from the Archival Objects AND suppressing the Digital Objects, (or maybe suppressing and unpublishing) I don't see a way to temporarily remove them from public view. Is there another way to achieve this that I'm not seeing? Hopefully this description makes sense! Best, --Benn Benn Joseph Head of Archival Processing Northwestern University Libraries Northwestern University www.library.northwestern.edu benn.joseph at northwestern.edu<mailto:benn.joseph at northwestern.edu%0d> 847.467.6581 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/87c305b0/attachment.html> From michael.rush at yale.edu Fri Jan 5 13:46:21 2018 From: michael.rush at yale.edu (Rush, Michael) Date: Fri, 5 Jan 2018 18:46:21 +0000 Subject: [Archivesspace_Users_Group] Processing notes In-Reply-To: <4142170736420940ACB07EE9EECDC21F51BF9CE5@si-msedag04.US.SINET.SI.EDU> References: <CAFy-AYLy1SxvyYBm=a_kiRrVXrBWHR0xGrXA5Ki1zT018Kyw+g@mail.gmail.com> <DM5PR11MB1449F5A299495C218207808295190@DM5PR11MB1449.namprd11.prod.outlook.com> <ed8d37d1b0bf415c946a12c0fead3d1e@esgmtwex18.win.ad.jhu.edu> <DF4SPR00MB0122879667ACE0D78B36393E41E0@DF4SPR00MB012.namprd08.prod.outlook.com> <4142170736420940ACB07EE9EECDC21F51BF9CE5@si-msedag04.US.SINET.SI.EDU> Message-ID: <DF4SPR00MB012FF01E3A5700FF2A5763FE41C0@DF4SPR00MB012.namprd08.prod.outlook.com> Hi Nancy, There are two scenarios where we have components or notes that remain unpublished. We have a few collections that have been fully processed, but which have series that are restricted and for which we don?t want to publish the description below the series level. For those records we don?t want to publish the components below the series level. Because of the difficulty of managing publication status, we intend to keep those components in a separate, suppressed resource. When the restriction is lifted we?ll unsuppress that dummy resource and merge the affected components into the correct resource. This is somewhere on Mark Custer?s to-do list, but we haven?t gotten to it yet. Because our ASpace has API-level integrations with Preservica, we also have some notes in archival components that are created by Preservica and not intended for public consumption. In this case it wouldn?t violate any agreements to publish those notes, it would only be confusing for researchers. I believe Mark has it on his to-do list either to develop a process to unpublish those notes on a regular schedule via the API or modify the behavior of Publish All to ignore those notes. Not sure which approach he?ll take. Either way we?ll continue to use Publish All. Best, Mike From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kennedy, Nancy Sent: Wednesday, January 3, 2018 11:12 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Processing notes Mike ? Out of curiosity, do you have ?internal only? components or notes? How would you manage the Publish All feature in the context of occasional internal only notes? For example, in AT, we kept some notes set to ?internal only.? But, that AT model doesn?t map easily onto the ArchivesSpace publish checkboxes. Publish All sounds useful for flipping large sets of components to publish, but there wouldn?t be a way to distinguish the ?internal only? notes. You?d have to go back and uncheck the internal notes, I suppose? Which seems error prone. Has anyone else faced this scenario? How did you adapt your workflows? Or perhaps, how did you adjust your data entry (maybe you limit data entry so that anything ?internal? is only entered into the repo processing note, coll mgmt. or user defined fields?) Nancy From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rush, Michael Sent: Wednesday, January 03, 2018 9:03 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Processing notes I agree with everything Kevin and Jordan have said. I?d add one additional advantage to using the Repository Processing Note. When the PUI is implemented, as we are currently working through, it becomes crucial to manage the workflow around published vs. unpublished notes (and components). We anticipate relying heavily on the ?Publish All? button at the resource level. Using the Repository Processing Note means there is one less note that could be accidentally published with Publish All. Mike From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jordon Steele Sent: Tuesday, January 2, 2018 4:40 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Processing notes Christie, Like Kevin, we use this note to communicate administrative information that doesn?t need to be published but ought to be conveyed to staff, especially if it?s information that doesn?t neatly align with a specific note that could be unpublished. For example, I used it to explain to staff why we decided to change the identifier of a collection from one normally reserved for manuscript collections to one that we use for university records collections. The idea is that having information like this in the Repository Processing Note ensures that it?s more likely to be seen by staff than having it buried in, say, a more specific note that?s marked ?unpublished.? Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu<mailto:jsteele at jhu.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kevin Clair Sent: Tuesday, January 02, 2018 4:34 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Processing notes Hi Christie, At the University of Denver we use it in both Resource and Archival Object records as a note to other archivists indicating processing or cataloging tasks that were left unfinished for one reason or another, or other administrative things that we don?t want published in the PUI. The idea is that if the actions listed in the Repository Processing Note get taken, we remove the text that?s there. We have a report that pulls the information from that field for review that we run periodically when setting processing priorities: https://github.com/duspeccoll/archivesspace_reports/tree/master/resources/resource_processing_notes_report<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_duspeccoll_archivesspace-5Freports_tree_master_resources_resource-5Fprocessing-5Fnotes-5Freport&d=DwMGaQ&c=cjytLXgP8ixuoHflwc-poQ&r=fWPDMLxJ1Hpw4R8oN7OV0U6P4Nt_f5o8aUkXaby3nOY&m=gMxspNQHg5oFkrzgTER6dpY45b3cCvyB6tUrmXEoENI&s=f01SKcBsrjNU9f_FAo957_JSQzctEcXpMYANZNg3H6Q&e=> -k From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christie Peterson Sent: Tuesday, January 02, 2018 2:28 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Processing notes Hello, Can anyone on this list speak to what was intended to go in the "Repository Processing Note" text field for Resources, which the tooltip tells me does not appear in any exports or reports? Can anyone give me a use case for why they populate this field in addition to (or instead of?) an unpublished "Processing Information" note? Thanks, Christie Peterson -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu<mailto:cpeterson at smith.edu> pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/04f80b1d/attachment.html> From christine.dibella at lyrasis.org Mon Jan 8 12:30:18 2018 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Mon, 8 Jan 2018 17:30:18 +0000 Subject: [Archivesspace_Users_Group] new policies and documents related to contributing to ArchivesSpace development Message-ID: <CY1PR08MB1197A08B8FDB598341299059F1130@CY1PR08MB1197.namprd08.prod.outlook.com> Hello ArchivesSpace members, As an open source application, development for ArchivesSpace comes from many sources. As our community and application grow and mature, we're fortunate that more and more people want to get involved and make development contributions that make the ArchivesSpace application better for everyone. To make our processes for evaluating potential contributions more transparent, and to help people have a better idea of ways to get involved in development, we've put together some documents and policies that we hope will be helpful: * ArchivesSpace Process for Evaluating Potential Feature Contributions to the Core Code<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/360546309/ArchivesSpace+Process+for+Evaluating+Potential+Feature+Contributions+to+the+Core+Code> * applies to larger contributions such as new modules or significant changes or additions to existing features * Getting Involved in Developing Features for ArchivesSpace<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/348094572/Getting+Involved+in+Developing+Features+for+ArchivesSpace> * explains the options when developing features for ArchivesSpace * Turning an ArchivesSpace Plugin into Core Code<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/349995159/Turning+an+ArchivesSpace+Plugin+into+Core+Code> * provides some guidance and suggestions when considering turning a plugin into something more * Pull Request Review Process<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/125861898/Pull+Request+Process> * explains how big and small community pull requests are evaluated We've also set deadlines for submitting pull requests to be considered for a particular release. In general, the pull request deadline is the third Friday of a month, with occasional exceptions when a release is intended to come out earlier in the month. For example, the deadline by which a pull request needs to be submitted for consideration for our January release is January 19. Submitting a pull request by the deadline does not guarantee that it will go into the next release, but it will help ensure that we have adequate time to review and test it before potentially putting it into a release. We've noted these deadlines on the annual overview view of our roadmap and will be sending various reminders via email and Github when a particular deadline approaches to help contributors with their planning. We'll be promoting these links inside and outside the member community in various ways in the coming months, as well as adding information about particular JIRA issues and projects for which we're seeking community developers, but please also feel free to forward them to anyone you think might be interested. We very much encourage you to get in touch with me, Laney, or with members of the Core Committers group<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/102893918/Core+Committers+Group> if you want to get involved in development, either by developing something yourself or working with a developer to do so. We look forward to many contributions and the participation of many contributors in 2018! Christine 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/20180108/6555587f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 6608 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/6555587f/attachment.jpg> From francis.lapka at yale.edu Mon Jan 8 11:29:43 2018 From: francis.lapka at yale.edu (Lapka, Francis) Date: Mon, 8 Jan 2018 16:29:43 +0000 Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name Message-ID: <DM5PR08MB2748D47639BDA61977FE74198A130@DM5PR08MB2748.namprd08.prod.outlook.com> In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712 instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1322&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=eLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ&e=>, https://archivesspace.atlassian.net/browse/AR-1339<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1339&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=hgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo&e=>, and https://archivesspace.atlassian.net/browse/AR-1344<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1344&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=D823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA&e=>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [cid:image002.jpg at 01D3886F.845FE1E0] On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.library.northwestern.edu&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=xq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI&e=> k-miller3 at northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=lAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4&e=> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=lAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4&e=> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=lAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4&e=>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: 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=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=lAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4&e=> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0 There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=lAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4&e=><mailto:francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=lAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4&e=>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=gQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg&m=VE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE&s=lAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/0f6b12b4/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4144 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/0f6b12b4/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1497 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/0f6b12b4/attachment-0001.jpg> From bthomas at tsl.texas.gov Mon Jan 8 13:02:23 2018 From: bthomas at tsl.texas.gov (Brian Thomas) Date: Mon, 8 Jan 2018 18:02:23 +0000 Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In-Reply-To: <DM5PR08MB2748D47639BDA61977FE74198A130@DM5PR08MB2748.namprd08.prod.outlook.com> References: <DM5PR08MB2748D47639BDA61977FE74198A130@DM5PR08MB2748.namprd08.prod.outlook.com> Message-ID: <CY4PR1601MB13497774B1DF11B14E30D5D5FA130@CY4PR1601MB1349.namprd16.prod.outlook.com> Thank you for your continued work with this plug-in. I like the sort name idea. But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. Just my two cents. Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<http://tsl.texas.gov/> [cid:image001.jpg at 01D029A2.37194C70] From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lapka, Francis Sent: Monday, January 8, 2018 10:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2013064755.html&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=skTEFgQb%2BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE%3D&reserved=0>) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1322%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DeLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=g9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0%3D&reserved=0>, https://archivesspace.atlassian.net/browse/AR-1339<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1339%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=DcFJ3kNa%2F5NMvtWszm7E4vRXo7UCVDSElhmnZK%2FrLBY%3D&reserved=0>, and https://archivesspace.atlassian.net/browse/AR-1344<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1344%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=Gl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ%2B6eS0tN3Dk%3D&reserved=0>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [cid:image002.jpg at 01D38877.22DDBFC0] On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.library.northwestern.edu%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=FWKc1KosVLA%2FahElAqAlH%2BrbyhlbI%2FfkDqiB%2FJUm06M%3D&reserved=0> k-miller3 at northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: archivesspace_users_group at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA%2Fedit%23gid%3D0&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=7PV4BHcWcacj8jRf%2BoPDJldC6%2FR5IaP1RVXwhGDaw9U%3D&reserved=0> There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0><mailto:francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/ebe98dbd/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4144 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/ebe98dbd/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1497 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/ebe98dbd/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 5314 bytes Desc: image003.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/ebe98dbd/attachment.png> From reesj at mail.nlm.nih.gov Mon Jan 8 16:11:02 2018 From: reesj at mail.nlm.nih.gov (Rees, John (NIH/NLM) [E]) Date: Mon, 8 Jan 2018 21:11:02 +0000 Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In-Reply-To: <CY4PR1601MB13497774B1DF11B14E30D5D5FA130@CY4PR1601MB1349.namprd16.prod.outlook.com> References: <DM5PR08MB2748D47639BDA61977FE74198A130@DM5PR08MB2748.namprd08.prod.outlook.com> <CY4PR1601MB13497774B1DF11B14E30D5D5FA130@CY4PR1601MB1349.namprd16.prod.outlook.com> Message-ID: <SN1PR09MB08142CBF5A16D8B0B0B6F61AC8130@SN1PR09MB0814.namprd09.prod.outlook.com> How about adding to the core a separate URI field for the full string? John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 From: Brian Thomas [mailto:bthomas at tsl.texas.gov] Sent: Monday, January 08, 2018 1:02 PM To: 'Archivesspace Users Group' <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name Thank you for your continued work with this plug-in. I like the sort name idea. But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. Just my two cents. Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<http://tsl.texas.gov/> [cid:image001.jpg at 01D029A2.37194C70] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lapka, Francis Sent: Monday, January 8, 2018 10:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2013064755.html&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=skTEFgQb%2BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE%3D&reserved=0>) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1322%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DeLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=g9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0%3D&reserved=0>, https://archivesspace.atlassian.net/browse/AR-1339<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1339%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=DcFJ3kNa%2F5NMvtWszm7E4vRXo7UCVDSElhmnZK%2FrLBY%3D&reserved=0>, and https://archivesspace.atlassian.net/browse/AR-1344<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1344%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=Gl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ%2B6eS0tN3Dk%3D&reserved=0>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [cid:image005.jpg at 01D3889B.45B45170] On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.library.northwestern.edu%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=FWKc1KosVLA%2FahElAqAlH%2BrbyhlbI%2FfkDqiB%2FJUm06M%3D&reserved=0> k-miller3 at northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: archivesspace_users_group at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA%2Fedit%23gid%3D0&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=7PV4BHcWcacj8jRf%2BoPDJldC6%2FR5IaP1RVXwhGDaw9U%3D&reserved=0> There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0><mailto:francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/13f7598c/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 5314 bytes Desc: image003.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/13f7598c/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 4144 bytes Desc: image004.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/13f7598c/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 1497 bytes Desc: image005.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180108/13f7598c/attachment-0001.jpg> From rneal at richmond.edu Tue Jan 9 08:25:33 2018 From: rneal at richmond.edu (Neal, Rick) Date: Tue, 9 Jan 2018 13:25:33 +0000 Subject: [Archivesspace_Users_Group] Archivesspace installation question Message-ID: <f5dff2bf22a54145bb56a9dfd44ec4a1@alderaan.richmond.edu> Good morning, I am trying to find the installation instructions for Archivesspace for linux. I found this one: http://archivesspace.github.io/archivesspace/user/getting-started/ The issue is that it only mentions that I need java 1.7 or 1.8. For instance, it doesn?t describe setting up the mysql part or even initially setting up an archivesspace user. Does anyone have a link to more detailed installation instructions? Thanks! Rick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rick Neal Library Applications and Systems Administrator Boatwright Memorial Library University of Richmond, VA 23173 rneal at richmond.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rees, John (NIH/NLM) [E] Sent: Monday, January 8, 2018 4:11 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name How about adding to the core a separate URI field for the full string? John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 From: Brian Thomas [mailto:bthomas at tsl.texas.gov] Sent: Monday, January 08, 2018 1:02 PM To: 'Archivesspace Users Group' <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name Thank you for your continued work with this plug-in. I like the sort name idea. But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. Just my two cents. Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<http://tsl.texas.gov/> [cid:image001.jpg at 01D029A2.37194C70] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lapka, Francis Sent: Monday, January 8, 2018 10:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2013064755.html&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=skTEFgQb%2BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE%3D&reserved=0>) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1322%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DeLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=g9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0%3D&reserved=0>, https://archivesspace.atlassian.net/browse/AR-1339<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1339%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=DcFJ3kNa%2F5NMvtWszm7E4vRXo7UCVDSElhmnZK%2FrLBY%3D&reserved=0>, and https://archivesspace.atlassian.net/browse/AR-1344<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1344%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=Gl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ%2B6eS0tN3Dk%3D&reserved=0>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [cid:image003.jpg at 01D38923.2F90B630] On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.library.northwestern.edu%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=FWKc1KosVLA%2FahElAqAlH%2BrbyhlbI%2FfkDqiB%2FJUm06M%3D&reserved=0> k-miller3 at northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: archivesspace_users_group at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA%2Fedit%23gid%3D0&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=7PV4BHcWcacj8jRf%2BoPDJldC6%2FR5IaP1RVXwhGDaw9U%3D&reserved=0> There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0><mailto:francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/16830c65/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5314 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/16830c65/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4144 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/16830c65/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1497 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/16830c65/attachment-0001.jpg> From buschedw at msu.edu Tue Jan 9 08:30:03 2018 From: buschedw at msu.edu (Busch, Ed) Date: Tue, 9 Jan 2018 13:30:03 +0000 Subject: [Archivesspace_Users_Group] Archivesspace installation question In-Reply-To: <f5dff2bf22a54145bb56a9dfd44ec4a1@alderaan.richmond.edu> References: <f5dff2bf22a54145bb56a9dfd44ec4a1@alderaan.richmond.edu> Message-ID: <35E2A8E8997F6C48A5D5FC21602BDEB60125CE5331@CAD-EX01.campusad.msu.edu> Have you looked here? https://github.com/archivesspace/tech-docs Ed Busch MSU Archives From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Neal, Rick Sent: Tuesday, January 9, 2018 8:26 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Archivesspace installation question Good morning, I am trying to find the installation instructions for Archivesspace for linux. I found this one: http://archivesspace.github.io/archivesspace/user/getting-started/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_getting-2Dstarted_&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=f62c1KiC5eZIbBBAI6-KwWRJx_QWIAE-V-xFh7bsUVI&e=> The issue is that it only mentions that I need java 1.7 or 1.8. For instance, it doesn?t describe setting up the mysql part or even initially setting up an archivesspace user. Does anyone have a link to more detailed installation instructions? Thanks! Rick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rick Neal Library Applications and Systems Administrator Boatwright Memorial Library University of Richmond, VA 23173 rneal at richmond.edu<mailto:rneal at richmond.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rees, John (NIH/NLM) [E] Sent: Monday, January 8, 2018 4:11 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name How about adding to the core a separate URI field for the full string? John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 From: Brian Thomas [mailto:bthomas at tsl.texas.gov] Sent: Monday, January 08, 2018 1:02 PM To: 'Archivesspace Users Group' <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name Thank you for your continued work with this plug-in. I like the sort name idea. But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. Just my two cents. Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<https://urldefense.proofpoint.com/v2/url?u=http-3A__tsl.texas.gov_&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=zikby1nJwhgOU7kNeMUuL_Iy7_l6jVJblN3iE1RF7W4&e=> [cid:image001.jpg at 01D029A2.37194C70] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lapka, Francis Sent: Monday, January 8, 2018 10:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fid.loc.gov-252Fauthorities-252Fnames-252Fn79060712-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3D5-252BTrWSz-252B-252B8JceUh7XeSFRiGJFvxFmTU-252BLjkfdAS0ocg-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=mzF_CzbEF9i677O2U1S9W6z0OvyPQX9eBUODYI-WGG8&e=> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fid.loc.gov-252Fauthorities-252Fnames-252Fno2013064755.html-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DskTEFgQb-252BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=o3PZeZpKbPOY7Ge_eNeUC_sEwzWn06ULWMI4F0_8aZ8&e=>) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1322-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DeLenPqaNOmyv-2DCi-5FujGLdGYiGv1GTOBwiTmo7ikbtCQ-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3Dg9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=zbeNvjoH1Ydi4mfvSV5e9EuUW39iqE74M9zr-15pXz0&e=>, https://archivesspace.atlassian.net/browse/AR-1339<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1339-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-2DXo-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DDcFJ3kNa-252F5NMvtWszm7E4vRXo7UCVDSElhmnZK-252FrLBY-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=WhlskgCSWNiQH6DoV8opwck5t-LISt_jij22oLfWFUs&e=>, and https://archivesspace.atlassian.net/browse/AR-1344<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1344-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-2DYooJY-2Dn-2DlMLA-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DGl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ-252B6eS0tN3Dk-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=WWLWbC39DgugDOU2OzOS_MJ2iwa3ken2YYW1JtzRD7A&e=>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [cid:image003.jpg at 01D38924.0B2E5490] On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fwww.library.northwestern.edu-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DFWKc1KosVLA-252FahElAqAlH-252BrbyhlbI-252FfkDqiB-252FJUm06M-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=H3Y70sSFRcEi0Z4o0G5elseMXTa5GRYiPRPEjQMkkKk&e=> k-miller3 at northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: archivesspace_users_group at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fspreadsheets-252Fd-252F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL-5FjoWbA-252Fedit-2523gid-253D0-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3D7PV4BHcWcacj8jRf-252BoPDJldC6-252FR5IaP1RVXwhGDaw9U-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=SCPJMEBxFTwbTnw-7AY4nzwEe8D7D7twCvfmy13Biok&e=> There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=><mailto:francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/0113dd7e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5314 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/0113dd7e/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4144 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/0113dd7e/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1497 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/0113dd7e/attachment-0001.jpg> From rneal at richmond.edu Tue Jan 9 08:34:42 2018 From: rneal at richmond.edu (Neal, Rick) Date: Tue, 9 Jan 2018 13:34:42 +0000 Subject: [Archivesspace_Users_Group] Archivesspace installation question In-Reply-To: <35E2A8E8997F6C48A5D5FC21602BDEB60125CE5331@CAD-EX01.campusad.msu.edu> References: <f5dff2bf22a54145bb56a9dfd44ec4a1@alderaan.richmond.edu> <35E2A8E8997F6C48A5D5FC21602BDEB60125CE5331@CAD-EX01.campusad.msu.edu> Message-ID: <040ddb59717d4bf2ba675f4e7c37a177@alderaan.richmond.edu> Good morning Ed, Thanks for replying. That link led me to the link I posted below. I was unable to find anything specific to a detailed installation. Rick From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Busch, Ed Sent: Tuesday, January 9, 2018 8:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Archivesspace installation question Have you looked here? https://github.com/archivesspace/tech-docs Ed Busch MSU Archives From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Neal, Rick Sent: Tuesday, January 9, 2018 8:26 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] Archivesspace installation question Good morning, I am trying to find the installation instructions for Archivesspace for linux. I found this one: http://archivesspace.github.io/archivesspace/user/getting-started/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_getting-2Dstarted_&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=f62c1KiC5eZIbBBAI6-KwWRJx_QWIAE-V-xFh7bsUVI&e=> The issue is that it only mentions that I need java 1.7 or 1.8. For instance, it doesn?t describe setting up the mysql part or even initially setting up an archivesspace user. Does anyone have a link to more detailed installation instructions? Thanks! Rick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rick Neal Library Applications and Systems Administrator Boatwright Memorial Library University of Richmond, VA 23173 rneal at richmond.edu<mailto:rneal at richmond.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rees, John (NIH/NLM) [E] Sent: Monday, January 8, 2018 4:11 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name How about adding to the core a separate URI field for the full string? John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 From: Brian Thomas [mailto:bthomas at tsl.texas.gov] Sent: Monday, January 08, 2018 1:02 PM To: 'Archivesspace Users Group' <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name Thank you for your continued work with this plug-in. I like the sort name idea. But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. Just my two cents. Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<https://urldefense.proofpoint.com/v2/url?u=http-3A__tsl.texas.gov_&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=zikby1nJwhgOU7kNeMUuL_Iy7_l6jVJblN3iE1RF7W4&e=> [cid:image001.jpg at 01D029A2.37194C70] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lapka, Francis Sent: Monday, January 8, 2018 10:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fid.loc.gov-252Fauthorities-252Fnames-252Fn79060712-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3D5-252BTrWSz-252B-252B8JceUh7XeSFRiGJFvxFmTU-252BLjkfdAS0ocg-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=mzF_CzbEF9i677O2U1S9W6z0OvyPQX9eBUODYI-WGG8&e=> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fid.loc.gov-252Fauthorities-252Fnames-252Fno2013064755.html-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DskTEFgQb-252BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=o3PZeZpKbPOY7Ge_eNeUC_sEwzWn06ULWMI4F0_8aZ8&e=>) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1322-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DeLenPqaNOmyv-2DCi-5FujGLdGYiGv1GTOBwiTmo7ikbtCQ-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3Dg9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=zbeNvjoH1Ydi4mfvSV5e9EuUW39iqE74M9zr-15pXz0&e=>, https://archivesspace.atlassian.net/browse/AR-1339<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1339-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-2DXo-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DDcFJ3kNa-252F5NMvtWszm7E4vRXo7UCVDSElhmnZK-252FrLBY-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=WhlskgCSWNiQH6DoV8opwck5t-LISt_jij22oLfWFUs&e=>, and https://archivesspace.atlassian.net/browse/AR-1344<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1344-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-2DYooJY-2Dn-2DlMLA-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DGl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ-252B6eS0tN3Dk-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=WWLWbC39DgugDOU2OzOS_MJ2iwa3ken2YYW1JtzRD7A&e=>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [cid:image003.jpg at 01D38924.B14874A0] On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fwww.library.northwestern.edu-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DFWKc1KosVLA-252FahElAqAlH-252BrbyhlbI-252FfkDqiB-252FJUm06M-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=H3Y70sSFRcEi0Z4o0G5elseMXTa5GRYiPRPEjQMkkKk&e=> k-miller3 at northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: archivesspace_users_group at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fspreadsheets-252Fd-252F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL-5FjoWbA-252Fedit-2523gid-253D0-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3D7PV4BHcWcacj8jRf-252BoPDJldC6-252FR5IaP1RVXwhGDaw9U-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=SCPJMEBxFTwbTnw-7AY4nzwEe8D7D7twCvfmy13Biok&e=> There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=><mailto:francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/18f36d2b/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5314 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/18f36d2b/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4144 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/18f36d2b/attachment-0002.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1497 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/18f36d2b/attachment-0003.jpg> From rneal at richmond.edu Tue Jan 9 08:54:14 2018 From: rneal at richmond.edu (Neal, Rick) Date: Tue, 9 Jan 2018 13:54:14 +0000 Subject: [Archivesspace_Users_Group] Archivesspace installation question In-Reply-To: <040ddb59717d4bf2ba675f4e7c37a177@alderaan.richmond.edu> References: <f5dff2bf22a54145bb56a9dfd44ec4a1@alderaan.richmond.edu> <35E2A8E8997F6C48A5D5FC21602BDEB60125CE5331@CAD-EX01.campusad.msu.edu> <040ddb59717d4bf2ba675f4e7c37a177@alderaan.richmond.edu> Message-ID: <4ef7729ac8ae45f0a1f39e64a4423898@alderaan.richmond.edu> Good morning, I am good to go now. I ?think? I have it figured out. Rick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rick Neal Library Applications and Systems Administrator Boatwright Memorial Library University of Richmond, VA 23173 rneal at richmond.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Neal, Rick Sent: Tuesday, January 9, 2018 8:35 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Archivesspace installation question Good morning Ed, Thanks for replying. That link led me to the link I posted below. I was unable to find anything specific to a detailed installation. Rick From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Busch, Ed Sent: Tuesday, January 9, 2018 8:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Archivesspace installation question Have you looked here? https://github.com/archivesspace/tech-docs Ed Busch MSU Archives From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Neal, Rick Sent: Tuesday, January 9, 2018 8:26 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] Archivesspace installation question Good morning, I am trying to find the installation instructions for Archivesspace for linux. I found this one: http://archivesspace.github.io/archivesspace/user/getting-started/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_getting-2Dstarted_&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=f62c1KiC5eZIbBBAI6-KwWRJx_QWIAE-V-xFh7bsUVI&e=> The issue is that it only mentions that I need java 1.7 or 1.8. For instance, it doesn?t describe setting up the mysql part or even initially setting up an archivesspace user. Does anyone have a link to more detailed installation instructions? Thanks! Rick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rick Neal Library Applications and Systems Administrator Boatwright Memorial Library University of Richmond, VA 23173 rneal at richmond.edu<mailto:rneal at richmond.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rees, John (NIH/NLM) [E] Sent: Monday, January 8, 2018 4:11 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name How about adding to the core a separate URI field for the full string? John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 From: Brian Thomas [mailto:bthomas at tsl.texas.gov] Sent: Monday, January 08, 2018 1:02 PM To: 'Archivesspace Users Group' <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name Thank you for your continued work with this plug-in. I like the sort name idea. But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. Just my two cents. Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<https://urldefense.proofpoint.com/v2/url?u=http-3A__tsl.texas.gov_&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=zikby1nJwhgOU7kNeMUuL_Iy7_l6jVJblN3iE1RF7W4&e=> [cid:image001.jpg at 01D029A2.37194C70] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lapka, Francis Sent: Monday, January 8, 2018 10:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fid.loc.gov-252Fauthorities-252Fnames-252Fn79060712-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3D5-252BTrWSz-252B-252B8JceUh7XeSFRiGJFvxFmTU-252BLjkfdAS0ocg-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=mzF_CzbEF9i677O2U1S9W6z0OvyPQX9eBUODYI-WGG8&e=> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fid.loc.gov-252Fauthorities-252Fnames-252Fno2013064755.html-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DskTEFgQb-252BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=o3PZeZpKbPOY7Ge_eNeUC_sEwzWn06ULWMI4F0_8aZ8&e=>) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1322-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DeLenPqaNOmyv-2DCi-5FujGLdGYiGv1GTOBwiTmo7ikbtCQ-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3Dg9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=zbeNvjoH1Ydi4mfvSV5e9EuUW39iqE74M9zr-15pXz0&e=>, https://archivesspace.atlassian.net/browse/AR-1339<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1339-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-2DXo-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DDcFJ3kNa-252F5NMvtWszm7E4vRXo7UCVDSElhmnZK-252FrLBY-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=WhlskgCSWNiQH6DoV8opwck5t-LISt_jij22oLfWFUs&e=>, and https://archivesspace.atlassian.net/browse/AR-1344<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Farchivesspace.atlassian.net-5Fbrowse-5FAR-2D2D1344-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-2DYooJY-2Dn-2DlMLA-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DGl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ-252B6eS0tN3Dk-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=WWLWbC39DgugDOU2OzOS_MJ2iwa3ken2YYW1JtzRD7A&e=>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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] From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 [cid:image003.jpg at 01D38927.6BCB45D0] On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fwww.library.northwestern.edu-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DFWKc1KosVLA-252FahElAqAlH-252BrbyhlbI-252FfkDqiB-252FJUm06M-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=H3Y70sSFRcEi0Z4o0G5elseMXTa5GRYiPRPEjQMkkKk&e=> k-miller3 at northwestern.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: archivesspace_users_group at lyralists.lyrasis.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.google.com-252Fspreadsheets-252Fd-252F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL-5FjoWbA-252Fedit-2523gid-253D0-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3D7PV4BHcWcacj8jRf-252BoPDJldC6-252FR5IaP1RVXwhGDaw9U-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=SCPJMEBxFTwbTnw-7AY4nzwEe8D7D7twCvfmy13Biok&e=> There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=><mailto:francis.lapka at yale.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Flyralists.lyrasis.org-5Fmailman-5Flistinfo-5Farchivesspace-2D5Fusers-2D5Fgroup-2526d-253DDwMGaQ-2526c-253D-2Ddg2m7zWuuDZ0MUcV7Sdqw-2526r-253DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-2D5gZnWGg-2526m-253DVE7vahQV409oFeyMJzrm8qL-2DEAABs1a2EeqCYbbA0kE-2526s-253DlAXcHM1BDjQuDu-5FS4suuqwrJDlJ1mwQdvARy-5Fy0ZYk4-2526e-253D-26data-3D02-257C01-257Cbthomas-2540tsl.texas.gov-257Cb84af399b80144a8bfa408d556bf780a-257Ca4597bff9f384145a0334a2168399a5e-257C0-257C0-257C636510302741242703-26sdata-3DsjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA-253D-26reserved-3D0&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=nzQRpzss_AwHOHAKVWRsNQ&m=SoR4y109Ne-3fkSry6OnKZXUKtZ7q2zxYTRxJsNg39w&s=MpGUQm_Y2_HU0iH8sLZIOy0m3tWOFD-JZA0GXD2G7L4&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/5a029624/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5314 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/5a029624/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4144 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/5a029624/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1497 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/5a029624/attachment-0001.jpg> From sdm7g at virginia.edu Tue Jan 9 14:07:16 2018 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 9 Jan 2018 19:07:16 +0000 Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In-Reply-To: <SN1PR09MB08142CBF5A16D8B0B0B6F61AC8130@SN1PR09MB0814.namprd09.prod.outlook.com> References: <DM5PR08MB2748D47639BDA61977FE74198A130@DM5PR08MB2748.namprd08.prod.outlook.com> <CY4PR1601MB13497774B1DF11B14E30D5D5FA130@CY4PR1601MB1349.namprd16.prod.outlook.com> <SN1PR09MB08142CBF5A16D8B0B0B6F61AC8130@SN1PR09MB0814.namprd09.prod.outlook.com> Message-ID: <DDBCD566-D22D-4BD5-A0D4-98614471ADD2@virginia.edu> I don?t think the URI should be stored as a separate field in the DB ( in names_* tables ). Presumably, the resolver URL part of the string is linked to the source, so it should probably be linked to the source and concatenated with UUID to make a URI for display. If the resolver for a source changes, then it?s going to change for all names from that source. name_source is an enumeration value. So probably add an AppConfig array for resolvers, indexed by name_source value. Probably want to do the same thing for subject resolvers. Concatenation could be done when building JSON model so this would be a display field, but not editable. Not clear in those plugin mappings if Source value was meant to be ?naf? or the string ?Library of Congress Name Authority File? , but this value should be reconciled with name_source enums, which would mean value = ?naf? , and change current translation to ?Library of Congress Name Authority File? from ?NACO Authority File? . ? Steve Majewski > On Jan 8, 2018, at 4:11 PM, Rees, John (NIH/NLM) [E] <reesj at mail.nlm.nih.gov> wrote: > > How about adding to the core a separate URI field for the full string? > > > John P. Rees > Archivist and Digital Resources Manager > History of Medicine Division > National Library of Medicine > 301-827-4510 > > > > From: Brian Thomas [mailto:bthomas at tsl.texas.gov <mailto:bthomas at tsl.texas.gov>] > Sent: Monday, January 08, 2018 1:02 PM > To: 'Archivesspace Users Group' <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>> > Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name > > Thank you for your continued work with this plug-in. I like the sort name idea. > > But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. > > My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. > > Just my two cents. > > Brian Thomas > Electronic Records Specialist > Texas State Library and Archives Commission > 1201 Brazos Street > Austin, TX 78701 > PH: (512) 475-3374 > e-mail: bthomas at tsl.texas.gov <x-msg://4/bthomas at tsl.texas.gov> > tsl.texas.gov <http://tsl.texas.gov/> > <image003.png> > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Lapka, Francis > Sent: Monday, January 8, 2018 10:30 AM > To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>> > Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name > > In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). > > We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. > > For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. > > AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. > > Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2013064755.html&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=skTEFgQb%2BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE%3D&reserved=0>) > > I?d appreciate your thoughts on these two issues. > > > Thanks, > Francis > (on behalf of a Yale working group) > > > > Francis Lapka ? Catalog Librarian > Dept. of Rare Books and Manuscripts > Yale Center for British Art > 203.432.9672 ? francis.lapka at yale.edu <mailto:francis.lapka at yale.edu> > > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Christine Di Bella > Sent: Wednesday, April 12, 2017 3:31 PM > To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>> > Subject: Re: [Archivesspace_Users_Group] LCNAF plugin > > This is really wonderful work and discussion. Thank you all for these efforts! > > I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. > > There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1322%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DeLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=g9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0%3D&reserved=0>, https://archivesspace.atlassian.net/browse/AR-1339 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1339%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=DcFJ3kNa%2F5NMvtWszm7E4vRXo7UCVDSElhmnZK%2FrLBY%3D&reserved=0>, and https://archivesspace.atlassian.net/browse/AR-1344 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1344%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=Gl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ%2B6eS0tN3Dk%3D&reserved=0>. > The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. > As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. > > Christine > > 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) > > <image004.jpg> > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Cyndi Shein > Sent: Wednesday, April 12, 2017 2:12 PM > To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>> > Subject: Re: [Archivesspace_Users_Group] LCNAF plugin > > Hello all, > > Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: > Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. > > ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. > > ?We're excited about all the developments!? > > Cyndi Shein > Head, Special Collections Technical Services > University Libraries, University of Nevada, Las Vegas > cyndi.shein at unlv.edu <mailto:cyndi.shein at unlv.edu> (702) 895-2223 > <image005.jpg> > > On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu <mailto:francis.lapka at yale.edu>> wrote: > Thanks Karen. My comments are below. > > Francis > > > -- > > Karen Miller k-miller3 at northwestern.edu? <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> > Tue Apr 11 12:57:21 EDT 2017 > > Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. > - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. > > I only have two comments on the mappings. > > > 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. > - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. > > > 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. > - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. > > Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! > - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. > > FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. > > > > > Best regards, > Karen > > Karen D. Miller > Monographic Cataloger/Metadata Specialist > Northwestern University Libraries > Northwestern University > 1970 Campus Drive > Evanston, IL 60208 > www.library.northwestern.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.library.northwestern.edu%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=FWKc1KosVLA%2FahElAqAlH%2BrbyhlbI%2FfkDqiB%2FJUm06M%3D&reserved=0> > k-miller3 at northwestern.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> > 874.467.3462 > > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>] On Behalf Of Lapka, Francis > Sent: Thursday, April 06, 2017 3:23 PM > To: archivesspace_users_group at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> > Subject: [Archivesspace_Users_Group] LCNAF plugin > > As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: > > https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA%2Fedit%23gid%3D0&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=7PV4BHcWcacj8jRf%2BoPDJldC6%2FR5IaP1RVXwhGDaw9U%3D&reserved=0> > > There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). > > Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). > > We welcome your corrections, suggestions, or other thoughts. > > Thanks, > Francis > > > Francis Lapka * Catalog Librarian > Dept. of Rare Books and Manuscripts > Yale Center for British Art > 203.432.9672 <tel:%28203%29%20432-9672> * francis.lapka at yale.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0><mailto:francis.lapka at yale.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>> > > > Francis Lapka ? Catalog Librarian > Dept. of Rare Books and Manuscripts > Yale Center for British Art > 203.432.9672 <tel:%28203%29%20432-9672> ? francis.lapka at yale.edu <mailto:francis.lapka at yale.edu> > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/400faa3e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4943 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/400faa3e/attachment.bin> From Christine.Kim at lyrasis.org Tue Jan 9 14:45:37 2018 From: Christine.Kim at lyrasis.org (Christine Kim) Date: Tue, 9 Jan 2018 19:45:37 +0000 Subject: [Archivesspace_Users_Group] Webinar Announcement: ArchivesSpace Technology & Development Roadmap - Jan. 17 Message-ID: <MWHPR08MB2495A4AEFC18A671ED9F2AE5F5100@MWHPR08MB2495.namprd08.prod.outlook.com> ArchivesSpace Technology & Development Roadmap When: Thursday, January 17, 2018 Time: 2:00 p.m. - 2:30 p.m. EST (11:00 a.m. - 11:30 a.m. PST) Where: Webinar at http://lyrasis.adobeconnect.com/r1232xs0ku9h/ Dial-in only option: 888-354-0094 - Access code is 731627 No registration required. The session is limited to the first 100 participants. Please feel free to host a webinar viewing group. The webinar will be recorded and available for viewing at a later date. Webinar description: The ArchivesSpace Technology and Development roadmap is a planning and communication tool to help our community know what to expect in terms of future development work and aid in planning for upcoming releases. Distributed at the end of 2017, the latest version of our roadmap has many content and format updates, and now provides a series of views targeted at the needs of different kinds of ArchivesSpace stakeholders. The roadmap announcement can be found here: http://archivesspace.org/roadmap/. In this webinar, Program Manager Christine Di Bella will walk through the new roadmap format and also take questions and comments on the development planning process. Please feel free to bring any questions you have. Presenter: Christine Di Bella (Program Manager, ArchivesSpace) plays a key role working closely and collaboratively with the ArchivesSpace community, advisory groups, and Governance Board to set the strategy and goals for ArchivesSpace. With over 16 years of experience as an archivist in a number of academic and non-profit settings, Christine is involved in all aspects of the program, and serves as a key spokesperson and advocate for the program. Who should attend: Everyone interested in seeing the new roadmap and learning about updates and releases forthcoming in ArchivesSpace this year. Questions? Please contact Kim at christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/2f0b2b2d/attachment.html> From Kevin.Clair at du.edu Tue Jan 9 14:48:35 2018 From: Kevin.Clair at du.edu (Kevin Clair) Date: Tue, 9 Jan 2018 19:48:35 +0000 Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In-Reply-To: <DDBCD566-D22D-4BD5-A0D4-98614471ADD2@virginia.edu> References: <DM5PR08MB2748D47639BDA61977FE74198A130@DM5PR08MB2748.namprd08.prod.outlook.com> <CY4PR1601MB13497774B1DF11B14E30D5D5FA130@CY4PR1601MB1349.namprd16.prod.outlook.com> <SN1PR09MB08142CBF5A16D8B0B0B6F61AC8130@SN1PR09MB0814.namprd09.prod.outlook.com> <DDBCD566-D22D-4BD5-A0D4-98614471ADD2@virginia.edu> Message-ID: <DM5PR11MB14495C68634646E61E63DB9595100@DM5PR11MB1449.namprd11.prod.outlook.com> We have a plugin that verifies that an authority ID assigned to an Agent exists (though not yet necessarily that they represent the same Agent); it works on this principle: https://github.com/duspeccoll/verify_agent -k 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: Tuesday, January 09, 2018 12:07 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name I don?t think the URI should be stored as a separate field in the DB ( in names_* tables ). Presumably, the resolver URL part of the string is linked to the source, so it should probably be linked to the source and concatenated with UUID to make a URI for display. If the resolver for a source changes, then it?s going to change for all names from that source. name_source is an enumeration value. So probably add an AppConfig array for resolvers, indexed by name_source value. Probably want to do the same thing for subject resolvers. Concatenation could be done when building JSON model so this would be a display field, but not editable. Not clear in those plugin mappings if Source value was meant to be ?naf? or the string ?Library of Congress Name Authority File? , but this value should be reconciled with name_source enums, which would mean value = ?naf? , and change current translation to ?Library of Congress Name Authority File? from ?NACO Authority File? . ? Steve Majewski On Jan 8, 2018, at 4:11 PM, Rees, John (NIH/NLM) [E] <reesj at mail.nlm.nih.gov<mailto:reesj at mail.nlm.nih.gov>> wrote: How about adding to the core a separate URI field for the full string? John P. Rees Archivist and Digital Resources Manager History of Medicine Division National Library of Medicine 301-827-4510 From: Brian Thomas [mailto:bthomas at tsl.texas.gov] Sent: Monday, January 08, 2018 1:02 PM To: 'Archivesspace Users Group' <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name Thank you for your continued work with this plug-in. I like the sort name idea. But?I am concerned about directly embedding a URI when we have the authority number as the UUID. I doubt the authority id will change, but it is always possible that the URI information preceding or trailing the authority ID will be modified for some reason. I used to think URIs were persistent, but lately I?ve come across systematic changes with websites that invalidate good urls and require manual intervention to get working. My thought process is that: if we just key off the authority UUID, with the appropriate source specified from the drop-down menu, the underlying code can compile and potentially create the authority URL from the latest known URI structure for synchronization/ead export. That way, if a change becomes necessary, one part of the application gets changed instead having to batch alter potentially thousands of cells in a database. Just my two cents. Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov<x-msg://4/bthomas at tsl.texas.gov> tsl.texas.gov<http://tsl.texas.gov/> <image003.png> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Lapka, Francis Sent: Monday, January 8, 2018 10:30 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In April 2017, I asked for thoughts on changes that Yale would like to see in the AS LCNAF plugin (see below). We are now working with Lyrasis to implement some of these changes. Where appropriate, some changes may be made in the AS core code for MARC mapping (e.g., in mapping dates of existence). Other changes that Yale would like to see may be implemented in a local variation of the LCNAF plugin. For two of Yale?s desired changes, it?s unclear whether the modification should be made to the core code or as a local modification of the plugin. 1. AuthorityID: For imports from LC, Yale would like to populate the AuthorityID field with the URI for the entity rather than the MARC 010 value. For example, http://id.loc.gov/authorities/names/n79060712<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0> instead of n79060712. We assume the URI will be more useful, lending itself to LD applications and enabling the synchronization feature that is envisioned in the specification for the AS expanded agent model. 1. Sort Name: For imports from LC, do not automatically generate a sort name. Instead, map to Sort Name by taking the authorized form exactly as it appears in the MARC 1xx field, minus the MARC subfield syntax. We think this is the most straight-forward way to always get the exact LC authorized form, properly ordered and properly punctuated (auto generate has trouble with order/punctuation in some of the more complex headings, e.g.: http://id.loc.gov/authorities/names/no2013064755.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2013064755.html&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=skTEFgQb%2BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE%3D&reserved=0>) I?d appreciate your thoughts on these two issues. Thanks, Francis (on behalf of a Yale working group) Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672 ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella Sent: Wednesday, April 12, 2017 3:31 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin This is really wonderful work and discussion. Thank you all for these efforts! I wanted to mention a few things related to ongoing ArchivesSpace development and a few of the points in the discussion. * There are several related JIRA issues related to the Dates/Dates of Existence issue specifically: https://archivesspace.atlassian.net/browse/AR-1322<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1322%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DeLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=g9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0%3D&reserved=0>, https://archivesspace.atlassian.net/browse/AR-1339<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1339%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=DcFJ3kNa%2F5NMvtWszm7E4vRXo7UCVDSElhmnZK%2FrLBY%3D&reserved=0>, and https://archivesspace.atlassian.net/browse/AR-1344<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1344%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=Gl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ%2B6eS0tN3Dk%3D&reserved=0>. * The Dates field is the Agent record is no longer deprecated. This decision was made awhile back, but the tooltip and documentation are just catching up with the 2.0.0 version. The short version of why this is the case is that in the current application, the Dates field is needed for alignment with MARC while the Dates of Existence fields align better with EAC-CPF and allow for more precise use of dates. Currently what is in the Dates field is also what is put into the display string for an Agent, on both the staff interface and the public interface. While it is certainly not the most satisfying answer, the current solution is to either use both sets of dates, or to choose the one that most reflects your intended output. * As Francis suggests, a more robust Agents module is in the planning stages. Cory Nimer and Brad Westbrook have been working on specification for a substantial reworking of the Agents module, along with fuller support for EAC-CPF. I believe this specification will be ready for wider community review soon. In addition to providing the potential for recording additional types of information about people, families, and corporate bodies, reworking the Agents module could potentially come up with a solution for this date redundancy problem, though from this discussion it sounds like there are use cases for maintaining both ways to record dates. Christine 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) <image004.jpg> From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cyndi Shein Sent: Wednesday, April 12, 2017 2:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] LCNAF plugin Hello all, Just to weigh in on this conversation, local practice here at UNLV supports Francis' statement: Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. ?We find that the dates of existence field permits us to include information absent from the authorized heading?... not all headings have dates, and death dates are not often added in a timely manner. ?We're excited about all the developments!? Cyndi Shein Head, Special Collections Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu<mailto:cyndi.shein at unlv.edu> (702) 895-2223 <image005.jpg> On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>> wrote: Thanks Karen. My comments are below. Francis -- Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> Tue Apr 11 12:57:21 EDT 2017 Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. I only have two comments on the mappings. 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. Best regards, Karen Karen D. Miller Monographic Cataloger/Metadata Specialist Northwestern University Libraries Northwestern University 1970 Campus Drive Evanston, IL 60208 www.library.northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.library.northwestern.edu%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=FWKc1KosVLA%2FahElAqAlH%2BrbyhlbI%2FfkDqiB%2FJUm06M%3D&reserved=0> k-miller3 at northwestern.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> 874.467.3462 From: archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>] On Behalf Of Lapka, Francis Sent: Thursday, April 06, 2017 3:23 PM To: archivesspace_users_group at lyralists.lyrasis.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> Subject: [Archivesspace_Users_Group] LCNAF plugin As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA%2Fedit%23gid%3D0&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=7PV4BHcWcacj8jRf%2BoPDJldC6%2FR5IaP1RVXwhGDaw9U%3D&reserved=0> There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). We welcome your corrections, suggestions, or other thoughts. Thanks, Francis Francis Lapka * Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> * francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0><mailto:francis.lapka at yale.edu<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>> Francis Lapka ? Catalog Librarian Dept. of Rare Books and Manuscripts Yale Center for British Art 203.432.9672<tel:%28203%29%20432-9672> ? francis.lapka at yale.edu<mailto:francis.lapka at yale.edu> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/ecc50c51/attachment.html> From livsolis at utexas.edu Tue Jan 9 14:50:03 2018 From: livsolis at utexas.edu (Olivia S Solis) Date: Tue, 9 Jan 2018 13:50:03 -0600 Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators In-Reply-To: <BN3PR08MB13030FF18AB2E1AC43E211E38C1C0@BN3PR08MB1303.namprd08.prod.outlook.com> References: <CAKu+i=3X-O3nHV=ex_ikpCaQBqrgvAy2GM+fhsT3y7ic_0-ncg@mail.gmail.com> <43fa6d30f97c4be6af1153ce814e589a@esgmtwex18.win.ad.jhu.edu> <CAKu+i=0Xys8gyqMF7nVbC0yJ7DRLXoG8Dj4wb1ua-CZ4QEUQ=Q@mail.gmail.com> <26fc860b95b448d28387de3b1a127f2c@esgmtwex18.win.ad.jhu.edu> <CAKu+i=2UTqZEc1PVVT9jBixNgOvYef8wJRwOAXQs=WheGH0gGg@mail.gmail.com> <BN3PR08MB13030FF18AB2E1AC43E211E38C1C0@BN3PR08MB1303.namprd08.prod.outlook.com> Message-ID: <CAKu+i=3DF6sXv_C0PpJBspP_X0R5JsBgGpxz=st57RegRUECJA@mail.gmail.com> Thank you, Jordon and Mark, for your detailed response. Mark your detailed explanation is *extremely *informative and will help us determine how to handle staff records ? both user and agent ? particularly ones that appear as creators and subjects. I have some testing to do to see how merging affects the linkage in the database. Apologies for responding so late, Mark, but I wanted to locate where I read the information about not linking staff to records. I remembered reading it somewhere, but it took me a while to locate. When we embarked on our adoption/migration many moons ago, we were not paying Lyrasis members and so did not have access to all the documentation. I was looking for information anywhere I could get it. I remember reading a lot of the specs clearly labeled "DRAFT", which is apparently where I got this idea, the Agent Specifications from 2012: http://archivesspace.org/wp-content/uploads/2017/01/Agent-Specification-20120323.pdf In the "Linking to Other Records" section, it states: "Repositories or staff users cannot be linked to archival object records as the creator, source, or subject of that archival object." And: "Agent records of type ?person?, ?family?, or ?corporate entity? to an accession record as either ?creator?, ?source,? or ?subject? (except if the record is also a staff user or repository);" Obviously this is a draft and things have since changed. And technically, the staff user cannot be linked. The associated agent record is. Again, I really appreciate your feedback. On Fri, Jan 5, 2018 at 8:49 AM, Custer, Mark <mark.custer at yale.edu> wrote: > Olivia, all: > > > > I?m not sure what documentation suggested to not use users are linked > agents, but as far as I?m aware, that?s impossible. You can only link > agents in that respect. That said, whenever a user record is created, an > agent record is *also* created. Those records are linked in the > database, but they are **not** synched at all in the application. Here?s > an example: > > > > - I just created a user record in http://test.archivesspace.org/ > - The username (a required field) = username > - The full name (also required, since it?s used for the corresponding > Agent record) = User Nam? > - This action created user 65 in the database; you can edit that > record, if you?re logged in as a system administrator, by going to > http://test.archivesspace.org/users/65/edit > <http://test.archivesspace.org/users/65/edit> > - This action also created agent_person 1153 in the database: > http://test.archivesspace.org/agents/agent_person/1153 > <http://test.archivesspace.org/agents/agent_person/1153> The name > used for this Agent is copied over from the corresponding user record?s > ?full name? field. This is just a one-time convenience, though. I later > changed the full name in the user record, but as you?ll see, that has no > effect on the Agent record. And so, that also means that you can edit the > Agent record with whatever additional details that you want, including the > Authority ID, whatever. > - And so, those two records are linked (from the context of the user > record in the database), but they will never be synched from here on out. > - Lastly, and importantly, if you delete that user record, it will > delete the Agent record. > - I assumed this would **not** happen if the Agent was linked to > another record in the system, but it looks like that?s not the case (I was > able to do it just now, so I?d say that?s a bug that needs to be > addressed!). In any event, we have a policy currently of never deleting > user records right now, so we?ll definitely need to keep up with that > policy ?. Maybe the documentation that you read was suggesting > not linking user-based Agent records for this very reason. Regardless, I?d > love to check out that documentation if you remember where it came from. > - However, if you try to delete an Agent record that?s linked to a > User record, you won?t be able to do so until the User record is no longer > in the system. So that works as I?d expect! > > > > All that said, we definitely link Agents who have corresponding user > records, just like Jordon suggested. Once ASpace has the ability to synch > with external systems such as id.loc.gov and/or SNAC, as detailed in the > expanded agent module specifications, we may have to rethink how we do that > currently, since we also have a practice of updating our local Agent > records with their Yale NetID in one of the Agent?s bioghist notes, but I > don?t think that will be too problematic for us since those records are > still linked in the database. I?d also want to make sure that deleting the > User record would not use that Agent record, especially if it?s linked to > an external system, but that?s another matter altogether. > > > > We also link those Agents to other record types like Events. For just one > example, when our Digital Accessioning Archivist runs scripts during the > course of her work, it?s her Agent record in ASpace that is linked to those > Events in ArchivesSpace (e.g. a PII scan is conducted on a disk image). > There?s no way to link the user record here. If she were to edit the > description of that archival component, however, then it would be her > ?username? that is listed as the last user to edit that archival component. > > > > Hopefully that helps, > > > > Mark > > > > p.s. whenever you create a Repository record in ArchivesSpace, an > agent_corporate_entity is similarly created, automatically. See > http://test.archivesspace.org/agents/agent_corporate_entity/1 > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia > S Solis > *Sent:* Friday, 05 January, 2018 12:43 AM > > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Staff users/agents as > subjects/creators > > > > Hi Jordon, > > > > Thank you!! Your response is indeed very helpful and I totally understand > the logic behind your decision. Just a little background, we are almost > ASpace live. We are about to set up all of our user accounts. At some point > along the way, I read ASpace documentation advising not to use users as > linked agents. I can't at the moment remember exactly where, but I can see > that as useful advice. We ignored it for a couple reasons cited below. > > > > We, in contrast to y'all, have decided to use staff agents for > human-initiated collection management activities that may need to be > documented in major record types. In particular, events. > > > > I think there were a couple of things throwing us off here. For one, > events require some kind of linked agent, and we are using events for > various stages of accessioning and the ultimate stages of processing, as > you have chosen not to do in all cases (at least through events records > which do not use relators). For something like a processing step completed > in an event, how would the required linked agent not be some kind of staff > user? We also wanted it very clearly documented that certain staff played > certain roles in events. > > > > The second is that all users are included in the list of possible > candidates when one starts typing in a linked agent in accessions, > resources, and archival objects. So below, my record is pulled up because I > started typing in my name (in this case in a new accession record) in a new > linked agent sub-record: > > [image: Inline image 1] > > I was created as simply a user in ASpace, not an agent. Anyone could add > me to a record as a creator or subject regardless of an institutional > policy not to add users as linked agents. Relooking at ASpace, apparently > being a user also makes me an agent in ASpace, with all the functionality > ASpace endows to agents. I could edit my agent record's URI or create > relationships with other agents, etc. > > > > I'm seeing a lot of pros and cons here. I can give myself as a user a VIAF > URI in my agent (not user) record. (It also appears that editing my user > "Full name" doesn't automatically update the equivalent "Primary name" > field in my agent record). But if you go with a policy that users are not > agents and should not be used as linked agents, how do you get staff > creating and editing records not to add the users that appear as candidates > when they start typing in the linked agent fields as linked agents? Users > are options here. Our solution was that "staff" addition. > > > > In terms of authority control, it seems very precarious to allow any user > to be added as a linked agent to any record, particularly to a published > record. If it's possible to add any user as a linked agent, despite > institutional policy not to, someone will. (Months of cleaning up legacy > data has made me a skeptic.) Even if that same user has a sanctioned, > legit, separate agent record. > > > > Has this been a problem for anyone else? Do you have ambiguous > relationships between agents and users? And Jordon, given your library's > policy, has this ever been an issue for you... staff accidentally adding > users as linked agents? Again, we've got staff members who are regularly > creators, subjects, donors, etc. > > > > I'm also curious about the relationship between users and their correlated > agent records and how/if various interrelated/common fields are > reciprocally updated. > > > > Thanks, and if there is documentation that exists about this apologies! > > > > -Olivia > > > > On Thu, Jan 4, 2018 at 7:18 PM, Jordon Steele <jsteele at jhu.edu> wrote: > > Olivia, > > > > Yes, we do use URIs for our agent records, and, like you, they are sourced > from VIAF. > > > > We separate user accounts from agent records. A user account is for > someone to edit or view ASpace data. An agent record is reserved to > document creators or subjects of collections or staff involved in > collection-related activities. We?ve discussed and decided not to create > and manage agent records for roles related to collection management > activities such as processing or updating records; those names just appear > as free text in processing notes (or in the audit trail of the ASpace > record, which shows the last username to edit a given record). We generally > only create agent records for staff to document curatorial activities like > acquisition and deaccessioning. > > > > So there could indeed be a scenario where we have an agent record for a > staff member and a separate user account for that staff member, which we?ve > decided we can live with, especially because agent records are managed in a > module separate from user accounts. It?s a similar situation to a library > catalog?s authority file, where a staff member may be listed because he or > she happened to, like, author a book that the library owns, but that staff > member may also have logins managed separately to access library > applications. But I understand the gray area?we?ve just decided to accept > it. > > > > Hope that helps! > > > > Best, > > > > Jordon > > > > Jordon Steele > > Hodson Curator of the University Archives > > Special Collections > > The Sheridan Libraries > > Johns Hopkins University > > 3400 N Charles St > > Baltimore, MD 21218 > > 410-516-5493 <(410)%20516-5493> > > jsteele at jhu.edu > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia > S Solis > *Sent:* Thursday, January 04, 2018 4:29 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] Staff users/agents as > subjects/creators > > > > Hi Jordon, > > > > Thanks for the response! Do you use URIs for your terms? Forgive me if > this was not clear before (or if it was that I am being repetitive). We've > been doing a lot of work to clean up normalize data set ourselves up for a > linked data universe where we reference all of our names with URIs and we > specify the name authorities we are using. In particular, we've chosen > VIAF. So say Celine Dion is our Registrar who uses ArchivesSpace daily to > create and search for records. She also donated her papers to us. She needs > a user account, but we want to refer to her by her URI: > > https://viaf.org/viaf/12491209 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__viaf.org_viaf_12491209&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=JraIp2y8Vq0z_c_1MJ0B9dQv3SQe9zXGwhqxXr-qw-0&e=> > > > in her papers, in particular to anything we publish. If she has a user > account, there is no field for the URI or the authority. If I'm not > mistaken, all users who get "Local" rules, but we would want to specify > "VIAF" as the source of the term. > > > > Thanks, and again, sorry if I am over-explaining! > > > > -Olivia > > > > [image: Inline image 1] > > > > On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <jsteele at jhu.edu> wrote: > > Hi Olivia, > > > > We have one agent record and assign different roles or relator terms based > on the context. So for a given collection, Person X may have the role > ?Source? and relator ?Curator? if that person was involved in acquiring a > collection. If the person was the subject of the collection, we?d re-use > the existing agent record and assign the role ?Subject.? If we ended up > getting that person?s papers, in that scenario, we?d assign the same agent > record but with role ?Creator.? We think of the agent one entity who may > have different roles depending on the collection/event/context. > > > > Best, > > > > Jordon > > > > Jordon Steele > > Hodson Curator of the University Archives > > Special Collections > > The Sheridan Libraries > > Johns Hopkins University > > 3400 N Charles St > > Baltimore, MD 21218 > > 410-516-5493 <(410)%20516-5493> > > jsteele at jhu.edu > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Olivia > S Solis > *Sent:* Thursday, January 04, 2018 3:05 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] Staff users/agents as > subjects/creators > > > > Hello all, > > > > I was wondering if some of you have a situation we have. Occasionally, > some of our staff will appear as subjects/creators in resources and > accessions. We have some staff members who are published scholars and > appear in name authority files. In such cases, we'd want to use the URIs > for those names (no such field in user records). We also have specific > rules we follow for local names for subjects/creators. > > > > How do you/do you distinguish between staff members when they are acting > in their capacity as staff (e.g. as the recipient of the agreement received > event) vs. as subject/creator? Staff users appear to be agents that are > selectable in any kind of record type. > > > > Our current strategy is to include a "(staff)" addition to "Full name" for > users. For instance, mine would be "Olivia Solis (staff)", the reason being > to make it absolutely clear this is not the non-existent "Solis, Olivia" in > VIAF who is also an agent, but not a user. I don't like including > information that is not part of a name in the name field, but otherwise, I > think people would accidentally select the user agent in instances where > they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. > Is there a better solution to "staff" for disambiguation purposes? Somehow > display the person's title in the type-ahead list that appears when you > start typing in a linked agent name? I'm not sure how difficult that would > be. > > > > We plan to retire (change passwords for), but not delete staff user > accounts when the staff members no longer work here so we don't get rid of > their data trail. But in 20 years it would be nice for staff to know that > the retired "Olivia Solis (staff)" is also the same person as creator of > one of our collections. Or maybe a donor, in which case I would not want to > use the user account. > > > > Thanks, > > Olivia > > > > -- > > Olivia Solis, MSIS > > Metadata Coordinator > > Dolph Briscoe Center for American History > > The University of Texas at Austin > > 2300 Red River St. Stop D1100 > > Austin TX, 78712-1426 > > (512) 232-8013 <(512)%20232-8013> > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=> > > > > > > -- > > Olivia Solis, MSIS > > Metadata Coordinator > > Dolph Briscoe Center for American History > > The University of Texas at Austin > > 2300 Red River St. Stop D1100 > > Austin TX, 78712-1426 > > (512) 232-8013 <(512)%20232-8013> > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=> > > > > > > -- > > Olivia Solis, MSIS > > Metadata Coordinator > > Dolph Briscoe Center for American History > > The University of Texas at Austin > > 2300 Red River St. Stop D1100 > > Austin TX, 78712-1426 > > (512) 232-8013 <(512)%20232-8013> > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Olivia Solis, MSIS Metadata Coordinator Dolph Briscoe Center for American History The University of Texas at Austin 2300 Red River St. Stop D1100 Austin TX, 78712-1426 (512) 232-8013 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/b970b2de/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 42455 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/b970b2de/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 24761 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/b970b2de/attachment-0001.png> From cyndi.shein at unlv.edu Tue Jan 9 15:10:38 2018 From: cyndi.shein at unlv.edu (Cyndi Shein) Date: Tue, 9 Jan 2018 12:10:38 -0800 Subject: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name In-Reply-To: <SN1PR09MB08142CBF5A16D8B0B0B6F61AC8130@SN1PR09MB0814.namprd09.prod.outlook.com> References: <DM5PR08MB2748D47639BDA61977FE74198A130@DM5PR08MB2748.namprd08.prod.outlook.com> <CY4PR1601MB13497774B1DF11B14E30D5D5FA130@CY4PR1601MB1349.namprd16.prod.outlook.com> <SN1PR09MB08142CBF5A16D8B0B0B6F61AC8130@SN1PR09MB0814.namprd09.prod.outlook.com> Message-ID: <CAHYOJB8LnQXBAN3jyj3fZAP-a2rsypLgNUOJwyV8idpht4Jm8Q@mail.gmail.com> Hi Francis and all, We're delighted to have direction for these agent fields. Thank you to all who have been thinking about this and moving things forward. After some discussion, UNLV would like to voice support for the suggested changes to the sort field and the Authority ID, advocating for their addition to the core code. At UNLV we have been entering the full string (actionable link) for URIs. We made this decision three years ago when no one on the listserv or at ASpace was able to provide direction. At the time, it occurred to us that we could enter just the ID and let the drop-down for the source of the ID (NACO, AAT, ULAN, etc) trigger automated generation of that source's prefix for an actionable link. We opted to go with the full string, knowing we can do a global find and replace behind the scenes in the event that a source body changes its prefix. Brian's point is, however, something to consider. Times change. Sample EAC records (from 2010) on EAC's official website <http://eac.staatsbibliothek-berlin.de/examples-for-the-eac-cpf-schema-2010/> point to http://lccn.loc.gov/ rather than to http://id.loc.gov/authorities/ names/ <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0> Again, updates of this type could be made behind the scenes with a global find and replace. Will John's suggestion to have two fields for IDs (one truncated and one full/actionable) align with EAC-CPF's future direction? The simple ID number and the full string are both included and tagged separately in some (ancient) sample EAC records. It is a little more work to enter the data twice... ?As the options for sources of Authority ID URIs expand the options in ArchivesSpace's future (thinking of SNAC and other (as yet undreamed of) specialized sources that may develop in the world of linked data) is there potential for the IDs across different sources to be duplicates? For example, in ULAN, the full string for Ansel Adams is http://vocab.getty.edu/ulan/500026108 . Obviously, that number alone is not a unique identifier outside the ULAN system. I realize LC name IDs are preceded by an "n" and that the number of digits in LC and ULAN IDs differ, etc... but potential duplication is something to be wary of. By including the URI's full string, we stand a better chance of getting a truly unique ID as more sources ?for LD authorities become available. Finally, at UNLV we do map the dates in the Names Form field directly to the LC/NACO heading (even if the LC date is incorrect). We also use the Dates of Existence field, where we enter more complete dates when known. Both date fields are very useful for different reasons. We are in favor of retaining both. Cyndi Shein Head, Special Collections and Archives Technical Services. On Mon, Jan 8, 2018 at 1:11 PM, Rees, John (NIH/NLM) [E] < reesj at mail.nlm.nih.gov> wrote: > How about adding to the core a separate URI field for the full string? > > > > > > John P. Rees > > Archivist and Digital Resources Manager > > History of Medicine Division > > National Library of Medicine > > 301-827-4510 <(301)%20827-4510> > > > > > > > > *From:* Brian Thomas [mailto:bthomas at tsl.texas.gov] > *Sent:* Monday, January 08, 2018 1:02 PM > *To:* 'Archivesspace Users Group' <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & > Sort Name > > > > Thank you for your continued work with this plug-in. I like the sort name > idea. > > > > But?I am concerned about directly embedding a URI when we have the > authority number as the UUID. I doubt the authority id will change, but it > is always possible that the URI information preceding or trailing the > authority ID will be modified for some reason. I used to think URIs were > persistent, but lately I?ve come across systematic changes with websites > that invalidate good urls and require manual intervention to get working. > > > > My thought process is that: if we just key off the authority UUID, with > the appropriate source specified from the drop-down menu, the underlying > code can compile and potentially create the authority URL from the latest > known URI structure for synchronization/ead export. That way, if a change > becomes necessary, one part of the application gets changed instead having > to batch alter potentially thousands of cells in a database. > > > > Just my two cents. > > > > Brian Thomas > > Electronic Records Specialist > > Texas State Library and Archives Commission > > 1201 Brazos Street > > Austin, TX 78701 > > PH: (512) 475-3374 > > e-mail: bthomas at tsl.texas.gov > > tsl.texas.gov > > [image: cid:image001.jpg at 01D029A2.37194C70] > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Lapka, > Francis > *Sent:* Monday, January 8, 2018 10:30 AM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & > Sort Name > > > > In April 2017, I asked for thoughts on changes that Yale would like to see > in the AS LCNAF plugin (see below). > > > > We are now working with Lyrasis to implement some of these changes. Where > appropriate, some changes may be made in the AS core code for MARC mapping > (e.g., in mapping dates of existence). Other changes that Yale would like > to see may be implemented in a local variation of the LCNAF plugin. > > > > For two of Yale?s desired changes, it?s unclear whether the modification > should be made to the core code or as a local modification of the plugin. > > > > 1. *AuthorityID*: For imports from LC, Yale would like to populate the > AuthorityID field with the URI for the entity rather than the MARC 010 > value. For example, http://id.loc.gov/authorities/names/n79060712 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0> > instead of *n79060712*. We assume the URI will be more useful, lending > itself to LD applications *and* enabling the synchronization feature > that is envisioned in the specification for the AS expanded agent model. > > > > 1. *Sort Name*: For imports from LC, *do not* automatically generate a > sort name. Instead, map to Sort Name by taking the authorized form exactly > as it appears in the MARC 1xx field, minus the MARC subfield syntax. We > think this is the most straight-forward way to always get the exact LC > authorized form, properly ordered and properly punctuated (auto generate > has trouble with order/punctuation in some of the more complex headings, > e.g.: http://id.loc.gov/authorities/names/no2013064755.html > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2013064755.html&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=skTEFgQb%2BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE%3D&reserved=0> > ) > > > > I?d appreciate your thoughts on these two issues. > > > > > > Thanks, > > Francis > > (on behalf of a Yale working group) > > > > > > > > Francis Lapka ? Catalog Librarian > > Dept. of Rare Books and Manuscripts > > Yale Center for British Art > > 203.432.9672 <(203)%20432-9672> ? francis.lapka at yale.edu > > > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Christine > Di Bella > *Sent:* Wednesday, April 12, 2017 3:31 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] LCNAF plugin > > > > This is really wonderful work and discussion. Thank you all for these > efforts! > > > > I wanted to mention a few things related to ongoing ArchivesSpace > development and a few of the points in the discussion. > > > > - There are several related JIRA issues related to the Dates/Dates of > Existence issue specifically: https://archivesspace. > atlassian.net/browse/AR-1322 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1322%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DeLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=g9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0%3D&reserved=0>, > https://archivesspace.atlassian.net/browse/AR-1339 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1339%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=DcFJ3kNa%2F5NMvtWszm7E4vRXo7UCVDSElhmnZK%2FrLBY%3D&reserved=0>, > and https://archivesspace.atlassian.net/browse/AR-1344 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1344%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=Gl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ%2B6eS0tN3Dk%3D&reserved=0> > . > - The Dates field is the Agent record is no longer deprecated. This > decision was made awhile back, but the tooltip and documentation are just > catching up with the 2.0.0 version. The short version of why this is the > case is that in the current application, the Dates field is needed for > alignment with MARC while the Dates of Existence fields align better with > EAC-CPF and allow for more precise use of dates. Currently what is in the > Dates field is also what is put into the display string for an Agent, on > both the staff interface and the public interface. While it is certainly > not the most satisfying answer, the current solution is to either use both > sets of dates, or to choose the one that most reflects your intended output. > - As Francis suggests, a more robust Agents module is in the planning > stages. Cory Nimer and Brad Westbrook have been working on specification > for a substantial reworking of the Agents module, along with fuller support > for EAC-CPF. I believe this specification will be ready for wider community > review soon. In addition to providing the potential for recording > additional types of information about people, families, and corporate > bodies, reworking the Agents module could potentially come up with a > solution for this date redundancy problem, though from this discussion it > sounds like there are use cases for maintaining both ways to record dates. > > > > Christine > > > > Christine Di Bella > > ArchivesSpace Program Manager > > christine.dibella at lyrasis.org > > 800.999.8558 x2905 <(800)%20999-8558> > > 678-235-2905 <(678)%20235-2905> > > cdibella13 (Skype) > > > > [image: ASpaceOrgHomeMedium] > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [ > mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org > <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Cyndi > Shein > *Sent:* Wednesday, April 12, 2017 2:12 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] LCNAF plugin > > > > Hello all, > > Just to weigh in on this conversation, local practice here at UNLV > supports Francis' statement: > Dates that appear in the name form (and part of the access point) aren?t > necessarily the same as those that represent dates of existence. We may > sometimes want to record dates of existence even if dates are not included > in the access point. So we need both data elements. > > > ?We find that the dates of existence field permits us to include > information absent from the authorized heading?... not all headings have > dates, and death dates are not often added in a timely manner. > > > > ?We're excited about all the developments!? > > > Cyndi Shein > > Head, Special Collections Technical Services > > University Libraries, University of Nevada, Las Vegas > > cyndi.shein at unlv.edu (702) 895-2223 > > > > On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu> > wrote: > > Thanks Karen. My comments are below. > > > > Francis > > > > > > *--* > > > > *Karen Miller* k-miller3 at northwestern.edu > <archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E> > *Tue Apr 11 12:57:21 EDT 2017* > > > > Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern. > > - FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import. > > > > I only have two comments on the mappings. > > > > > > 1. I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest. > > - FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn?t the correct approach. Here?s our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren?t necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 ? because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option. > > > > > > 2. I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained. > > - FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as ?$a Seuss, $c Dr.? We?ll review this. > > > > Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes! > > - FL: I agree! It?s my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention. > > > > FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I?d like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles *without an author *can be mapped well enough to AS Subject, of type ?preferred title? ? though the AS subdivisions for subjects don?t work particularly well for titles. For related works that do have an author, I?m not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type ?preferred title?)? by which practice we lose benefits of treating the whole name/title as a related entity/authority. > > > > > > > > > > Best regards, > > Karen > > > > Karen D. Miller > > Monographic Cataloger/Metadata Specialist > > Northwestern University Libraries > > Northwestern University > > 1970 Campus Drive > > Evanston, IL 60208 > > www.library.northwestern.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.library.northwestern.edu%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=FWKc1KosVLA%2FahElAqAlH%2BrbyhlbI%2FfkDqiB%2FJUm06M%3D&reserved=0> > > k-miller3 at northwestern.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> > > 874.467.3462 > > > > > > > > > > From: archivesspace_users_group-bounces at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>] On Behalf Of Lapka, Francis > > Sent: Thursday, April 06, 2017 3:23 PM > > To: archivesspace_users_group at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> > > Subject: [Archivesspace_Users_Group] LCNAF plugin > > > > As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here: > > > > https://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA%2Fedit%23gid%3D0&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=7PV4BHcWcacj8jRf%2BoPDJldC6%2FR5IaP1RVXwhGDaw9U%3D&reserved=0> > > > > There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft). > > > > Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record). > > > > We welcome your corrections, suggestions, or other thoughts. > > > > Thanks, > > Francis > > > > > > Francis Lapka * Catalog Librarian > > Dept. of Rare Books and Manuscripts > > Yale Center for British Art > > 203.432.9672 <%28203%29%20432-9672> * francis.lapka at yale.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0><mailto:francis.lapka at yale.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>> > > > > > > Francis Lapka ? Catalog Librarian > > Dept. of Rare Books and Manuscripts > > Yale Center for British Art > > 203.432.9672 <%28203%29%20432-9672> ? francis.lapka at yale.edu > > > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Cyndi Shein Head, Special Collections & Archives Technical Services University Libraries, University of Nevada, Las Vegas cyndi.shein at unlv.edu (702) 895-2223 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 5314 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 4144 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 1497 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11771 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.jpe> From Christine.Kim at lyrasis.org Tue Jan 9 15:25:18 2018 From: Christine.Kim at lyrasis.org (Christine Kim) Date: Tue, 9 Jan 2018 20:25:18 +0000 Subject: [Archivesspace_Users_Group] Webinar Announcement: ArchivesSpace Technology & Development Roadmap - Jan. 17 In-Reply-To: <MWHPR08MB2495A4AEFC18A671ED9F2AE5F5100@MWHPR08MB2495.namprd08.prod.outlook.com> References: <MWHPR08MB2495A4AEFC18A671ED9F2AE5F5100@MWHPR08MB2495.namprd08.prod.outlook.com> Message-ID: <MWHPR08MB24957A4580994B1DFA030D96F5100@MWHPR08MB2495.namprd08.prod.outlook.com> Correction: The webinar is on *Wednesday* January 17th. Thank you! From: archivesspace_tac-bounces at lyralists.lyrasis.org [mailto:archivesspace_tac-bounces at lyralists.lyrasis.org] On Behalf Of Christine Kim Sent: Tuesday, January 9, 2018 11:46 AM Subject: [Archivesspace_tac] Webinar Announcement: ArchivesSpace Technology & Development Roadmap - Jan. 17 ArchivesSpace Technology & Development Roadmap When: Wednesday, January 17, 2018 Time: 2:00 p.m. - 2:30 p.m. EST (11:00 a.m. - 11:30 a.m. PST) Where: Webinar at http://lyrasis.adobeconnect.com/r1232xs0ku9h/ Dial-in only option: 888-354-0094 - Access code is 731627 No registration required. The session is limited to the first 100 participants. Please feel free to host a webinar viewing group. The webinar will be recorded and available for viewing at a later date. Webinar description: The ArchivesSpace Technology and Development roadmap is a planning and communication tool to help our community know what to expect in terms of future development work and aid in planning for upcoming releases. Distributed at the end of 2017, the latest version of our roadmap has many content and format updates, and now provides a series of views targeted at the needs of different kinds of ArchivesSpace stakeholders. The roadmap announcement can be found here: http://archivesspace.org/roadmap/. In this webinar, Program Manager Christine Di Bella will walk through the new roadmap format and also take questions and comments on the development planning process. Please feel free to bring any questions you have. Presenter: Christine Di Bella (Program Manager, ArchivesSpace) plays a key role working closely and collaboratively with the ArchivesSpace community, advisory groups, and Governance Board to set the strategy and goals for ArchivesSpace. With over 16 years of experience as an archivist in a number of academic and non-profit settings, Christine is involved in all aspects of the program, and serves as a key spokesperson and advocate for the program. Who should attend: Everyone interested in seeing the new roadmap and learning about updates and releases forthcoming in ArchivesSpace this year. Questions? Please contact Kim at christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/c0329931/attachment.html> From bthomas at tsl.texas.gov Wed Jan 10 09:29:27 2018 From: bthomas at tsl.texas.gov (Brian Thomas) Date: Wed, 10 Jan 2018 14:29:27 +0000 Subject: [Archivesspace_Users_Group] Agents biographical note to EAD export Message-ID: <CY4PR1601MB134967741F013D3D3C8D0C42FA110@CY4PR1601MB1349.namprd16.prod.outlook.com> I am curious if anyone has a plug-in that will pair a linked agent biographical/historical note in their agent record to an EAD and/or PDF export of a Resource? The idea being that if we use the agent biographical note as a hub for this data, we can just update that once and publish/export many resources. In lieu of copying out from the agent authority directly into the EAD post-export. We have a lot of shared agents. Thanks, Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<http://tsl.texas.gov/> [cid:image001.jpg at 01D029A2.37194C70] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180110/20a033e3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5314 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180110/20a033e3/attachment.png> From Lisa_Crane at cuc.claremont.edu Tue Jan 9 20:37:43 2018 From: Lisa_Crane at cuc.claremont.edu (Lisa Crane) Date: Wed, 10 Jan 2018 01:37:43 +0000 Subject: [Archivesspace_Users_Group] Bilingual finding aids and agents Message-ID: <B5178A29DAAF9940B0E1B2E90938FB09034D4DB8D8@Birch.cucore.cuc.claremont.edu> Hello! I am in the process of putting together my first bi-lingual finding aid ?C Chinese and English. I am interested in hearing how anyone in the group working with bi-lingual finding aids might create their Agents in ASpace? I had thought about creating two agents ?C one in English and one in Chinese ?C and linking both to the resource. I also thought about creating a single agent (using both English and Chinese) and somehow try to ??force?? the formatting as follows: Creator (personal name): Shen, Jialin = ?????? (artist) Creator (corporate name): Shanghai People's Fine Arts Publishing House (SPFAPH) = ?????????????????? (publisher) Of course, each of the creator??s above would be a single agent, but display both English and Chinese. Does anyone have any experience with this? Do you have any ideas/suggestions/best practices? I look forward to hearing from you! All the best, Lisa Lisa L. Crane | Western Americana Manuscripts Librarian | The Claremont Colleges Library 800 North Dartmouth Ave. | Claremont, CA 91711-5053 Phone (909) 607-0862 | lisa.crane at claremont.edu<mailto:lisa.crane at claremont.edu> [Description: cid:image003.png at 01D3849E.3A199290] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180110/90036b2a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10371 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180110/90036b2a/attachment.png> From Christine.Kim at lyrasis.org Wed Jan 10 10:50:41 2018 From: Christine.Kim at lyrasis.org (Christine Kim) Date: Wed, 10 Jan 2018 15:50:41 +0000 Subject: [Archivesspace_Users_Group] Advanced ArchiveSpace skills workshop content Message-ID: <MWHPR08MB249541CC987C97A68DAA9243F5110@MWHPR08MB2495.namprd08.prod.outlook.com> Hi everyone, The ArchivesSpace Training Corps is developing an advanced skills workshop and requests your help to explore potential topics to include. When you have a moment, please share your ideas through this survey: https://goo.gl/forms/Lsx9xAG3CBQQzg5J3 Open ended questions are included. Please feel free to include any type of content you feel would benefit someone who would like to get more out of ArchivesSpace, or any type of training or skills you would like to expand on yourself. Training topics currently available are listed on our website: http://archivesspace.org/using-archivesspace/training-and-consultations/ If you prefer, open discussion on this thread is also encouraged. Thanks so much for your help! Best wishes, Kim Christine Kim ArchivesSpace Community Engagement Coordinator christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> 800.999.8558 x4820 404.592.4820 Skype: ckim.lyrasis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180110/ed8c8bee/attachment.html> From ltang5 at lib.msu.edu Wed Jan 10 16:37:35 2018 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Wed, 10 Jan 2018 21:37:35 +0000 Subject: [Archivesspace_Users_Group] Agents biographical note to EAD export Message-ID: <E443059B-E8B1-42D7-98F7-F9A077FCCBAF@lib.msu.edu> That sounds like a really helpful tool! Identifying ways to reduce the need to copy and paste data as well as automatically update multiple linked records would be very helpful in many areas of the program. I often wished for a capability similar to LibGuides to either automatically copy the data (not linked), which could be customized for that specific use, as well as an option to import and link fields like that which could be batch updated. Creating that capability would be so helpful! Lydia From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Brian Thomas <bthomas at tsl.texas.gov> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Date: Wednesday, January 10, 2018 at 9:29 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Agents biographical note to EAD export I am curious if anyone has a plug-in that will pair a linked agent biographical/historical note in their agent record to an EAD and/or PDF export of a Resource? The idea being that if we use the agent biographical note as a hub for this data, we can just update that once and publish/export many resources. In lieu of copying out from the agent authority directly into the EAD post-export. We have a lot of shared agents. Thanks, Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov<http://tsl.texas.gov/> [id:image001.jpg at 01D029A2.37194C70] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5315 bytes Desc: image001.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180110/0ef5bdaa/attachment.png> From cpeterson at smith.edu Wed Jan 10 17:04:14 2018 From: cpeterson at smith.edu (Christie Peterson) Date: Wed, 10 Jan 2018 22:04:14 +0000 Subject: [Archivesspace_Users_Group] Agents biographical note to EAD export In-Reply-To: <E443059B-E8B1-42D7-98F7-F9A077FCCBAF@lib.msu.edu> References: <E443059B-E8B1-42D7-98F7-F9A077FCCBAF@lib.msu.edu> Message-ID: <CAFy-AYJiwMhsxnbUqbvG=F46cRDdPQ3F=3QhsuG+f9K-MOdWMQ@mail.gmail.com> I would love to see ASpace move toward this type of an integration, so that the PUI or exports could pull biog/hist data directly from Agent records. It feels like this would be a natural extension of the Agents and Authority Integration work on the roadmap for this year. Has anyone been talking about it? Christie > > > -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu pronouns: she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180110/b518fb0c/attachment.html> From ltang5 at lib.msu.edu Wed Jan 10 17:20:58 2018 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Wed, 10 Jan 2018 22:20:58 +0000 Subject: [Archivesspace_Users_Group] Agents biographical note to EAD export In-Reply-To: <CAFy-AYJiwMhsxnbUqbvG=F46cRDdPQ3F=3QhsuG+f9K-MOdWMQ@mail.gmail.com> References: <E443059B-E8B1-42D7-98F7-F9A077FCCBAF@lib.msu.edu> <CAFy-AYJiwMhsxnbUqbvG=F46cRDdPQ3F=3QhsuG+f9K-MOdWMQ@mail.gmail.com> Message-ID: <7BC59395-C3AA-4F5E-8A38-3E28F8758198@lib.msu.edu> This was briefly mentioned in the SIEWG recommendations under Data Entry IIF<https://docs.google.com/document/d/1poanmnYaVfU4kUoxyMa6r0GQwA74byvZdduc7smQuYQ/edit?usp=sharing>: F. Copy/clone elements 2. For the Biography note field, the ability to select a biography found in one or more agent records and import into the Resource/Digital Object record. This will provide a base text that can be tweaked to suit the collection being described. Suggested workflow: a. User opens a biography note. b. Clicks on a button to import note if desired (i.e. user can still just type a note if they would rather) c. Autopopulate screen uses typeahead search similar to when you link an existing agent record where you type in the heading for the record with the biography information you want to pull in. d. Biography note(s) from agent record (if there is one) pops into the biography note BUT just like resource records spawned from accession records, you can edit the information any way you want without it affecting the information in the agent record. Note: Some users may also want the option to link a biography note to the master Agent record, which then automatically updates to all linked records. We defer to the determination of the Agent refactoring group and/or future projects. Because of the Agent work already in progress, we were cautious about encroaching on their turf! Lydia From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Christie Peterson <cpeterson at smith.edu> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Date: Wednesday, January 10, 2018 at 5:04 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Agents biographical note to EAD export I would love to see ASpace move toward this type of an integration, so that the PUI or exports could pull biog/hist data directly from Agent records. It feels like this would be a natural extension of the Agents and Authority Integration work on the roadmap for this year. Has anyone been talking about it? Christie -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu<mailto:cpeterson at smith.edu> pronouns: she/her/hers From jsteele at jhu.edu Thu Jan 11 10:02:33 2018 From: jsteele at jhu.edu (Jordon Steele) Date: Thu, 11 Jan 2018 15:02:33 +0000 Subject: [Archivesspace_Users_Group] Agents biographical note to EAD export In-Reply-To: <7BC59395-C3AA-4F5E-8A38-3E28F8758198@lib.msu.edu> References: <E443059B-E8B1-42D7-98F7-F9A077FCCBAF@lib.msu.edu> <CAFy-AYJiwMhsxnbUqbvG=F46cRDdPQ3F=3QhsuG+f9K-MOdWMQ@mail.gmail.com> <7BC59395-C3AA-4F5E-8A38-3E28F8758198@lib.msu.edu> Message-ID: <760dcc0508634286bff05052f4436a74@esgmtwex18.win.ad.jhu.edu> I second (third?) everybody's interest in such a feature. It would also reflect growing consensus in the archives community that one should manage creator metadata separate from collection metadata. Looking at the specs below, I think more conversation would want to happen around the ability to edit/customize the note sourced from the general agent record note. One could argue that no copying/duplication of data would or should happen--rather, the bioghist note that's part of the agent record would be displayed on the fly. I recognize, though, that a possible downside to this is that it would be difficult, if not impossible, to customize a bioghist note derived from a generic agent record bioghist note if it made sense for the collection to do so. Granted I have not been privy to such a debate (i.e should we customize bioghist notes, what are the implications of having variants of a bioghist note for the same agent) if it has already happened. Might be a conversation that's bigger than ASpace. Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Wednesday, January 10, 2018 5:21 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Agents biographical note to EAD export This was briefly mentioned in the SIEWG recommendations under Data Entry IIF<https://docs.google.com/document/d/1poanmnYaVfU4kUoxyMa6r0GQwA74byvZdduc7smQuYQ/edit?usp=sharing>: F. Copy/clone elements 2. For the Biography note field, the ability to select a biography found in one or more agent records and import into the Resource/Digital Object record. This will provide a base text that can be tweaked to suit the collection being described. Suggested workflow: a. User opens a biography note. b. Clicks on a button to import note if desired (i.e. user can still just type a note if they would rather) c. Autopopulate screen uses typeahead search similar to when you link an existing agent record where you type in the heading for the record with the biography information you want to pull in. d. Biography note(s) from agent record (if there is one) pops into the biography note BUT just like resource records spawned from accession records, you can edit the information any way you want without it affecting the information in the agent record. Note: Some users may also want the option to link a biography note to the master Agent record, which then automatically updates to all linked records. We defer to the determination of the Agent refactoring group and/or future projects. Because of the Agent work already in progress, we were cautious about encroaching on their turf! Lydia From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Christie Peterson <cpeterson at smith.edu> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Date: Wednesday, January 10, 2018 at 5:04 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Agents biographical note to EAD export I would love to see ASpace move toward this type of an integration, so that the PUI or exports could pull biog/hist data directly from Agent records. It feels like this would be a natural extension of the Agents and Authority Integration work on the roadmap for this year. Has anyone been talking about it? Christie -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu<mailto:cpeterson at smith.edu> pronouns: she/her/hers _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group From bthomas at tsl.texas.gov Thu Jan 11 10:34:24 2018 From: bthomas at tsl.texas.gov (Brian Thomas) Date: Thu, 11 Jan 2018 15:34:24 +0000 Subject: [Archivesspace_Users_Group] Agents biographical note to EAD export In-Reply-To: <760dcc0508634286bff05052f4436a74@esgmtwex18.win.ad.jhu.edu> References: <E443059B-E8B1-42D7-98F7-F9A077FCCBAF@lib.msu.edu> <CAFy-AYJiwMhsxnbUqbvG=F46cRDdPQ3F=3QhsuG+f9K-MOdWMQ@mail.gmail.com> <7BC59395-C3AA-4F5E-8A38-3E28F8758198@lib.msu.edu> <760dcc0508634286bff05052f4436a74@esgmtwex18.win.ad.jhu.edu> Message-ID: <CY4PR1601MB1349DB36B8791912A7C024AAFA160@CY4PR1601MB1349.namprd16.prod.outlook.com> I cannot claim credit for this because someone else mentioned it to me. Might the compromise to have an on/off button in the agents section of a Resource to designate whether sync between the two parts of the system should happen? Perhaps even to the point of turning on initially to populate base information, then turning off to allow further refinements specific to that Resource? Basically a tweak to f.2.d. That would allow initial population or even update in a Resource if need be. I look forward to whatever the refactoring group is able to accomplish. Cheers, Brian Thomas Electronic Records Specialist Texas State Library and Archives Commission 1201 Brazos Street Austin, TX 78701 PH: (512) 475-3374 e-mail: bthomas at tsl.texas.gov tsl.texas.gov -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Jordon Steele Sent: Thursday, January 11, 2018 9:03 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Agents biographical note to EAD export I second (third?) everybody's interest in such a feature. It would also reflect growing consensus in the archives community that one should manage creator metadata separate from collection metadata. Looking at the specs below, I think more conversation would want to happen around the ability to edit/customize the note sourced from the general agent record note. One could argue that no copying/duplication of data would or should happen--rather, the bioghist note that's part of the agent record would be displayed on the fly. I recognize, though, that a possible downside to this is that it would be difficult, if not impossible, to customize a bioghist note derived from a generic agent record bioghist note if it made sense for the collection to do so. Granted I have not been privy to such a debate (i.e should we customize bioghist notes, what are the implications of having variants of a bioghist note for the same agent) if it has already happened. Might be a conversation that's bigger than ASpace. Best, Jordon Jordon Steele Hodson Curator of the University Archives Special Collections The Sheridan Libraries Johns Hopkins University 3400 N Charles St Baltimore, MD 21218 410-516-5493 jsteele at jhu.edu -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Wednesday, January 10, 2018 5:21 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Agents biographical note to EAD export This was briefly mentioned in the SIEWG recommendations under Data Entry IIF<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1poanmnYaVfU4kUoxyMa6r0GQwA74byvZdduc7smQuYQ%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Cbthomas%40tsl.texas.gov%7C5a82aa8b2e60421f536608d559046c87%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636512797899575944&sdata=ZaaItwzAI%2F4H8e%2FU5xApYrbz7A6U1l5OJRQ8wraz%2Fnc%3D&reserved=0>: F. Copy/clone elements 2. For the Biography note field, the ability to select a biography found in one or more agent records and import into the Resource/Digital Object record. This will provide a base text that can be tweaked to suit the collection being described. Suggested workflow: a. User opens a biography note. b. Clicks on a button to import note if desired (i.e. user can still just type a note if they would rather) c. Autopopulate screen uses typeahead search similar to when you link an existing agent record where you type in the heading for the record with the biography information you want to pull in. d. Biography note(s) from agent record (if there is one) pops into the biography note BUT just like resource records spawned from accession records, you can edit the information any way you want without it affecting the information in the agent record. Note: Some users may also want the option to link a biography note to the master Agent record, which then automatically updates to all linked records. We defer to the determination of the Agent refactoring group and/or future projects. Because of the Agent work already in progress, we were cautious about encroaching on their turf! Lydia From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Christie Peterson <cpeterson at smith.edu> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Date: Wednesday, January 10, 2018 at 5:04 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Agents biographical note to EAD export I would love to see ASpace move toward this type of an integration, so that the PUI or exports could pull biog/hist data directly from Agent records. It feels like this would be a natural extension of the Agents and Authority Integration work on the roadmap for this year. Has anyone been talking about it? Christie -- ?? ?? ?? ?? ?? ?? ?? ?? Christie S. Peterson Head of Technical Services for Special Collections Smith College Northampton, Mass. 413-585-2996 cpeterson at smith.edu<mailto:cpeterson at smith.edu> pronouns: she/her/hers _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flyralists.lyrasis.org%2Fmailman%2Flistinfo%2Farchivesspace_users_group&data=02%7C01%7Cbthomas%40tsl.texas.gov%7C5a82aa8b2e60421f536608d559046c87%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636512797899575944&sdata=H8rPx3eMUqL9odaFaobkCdSWa586Tvb26vS7kHWE9bc%3D&reserved=0 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flyralists.lyrasis.org%2Fmailman%2Flistinfo%2Farchivesspace_users_group&data=02%7C01%7Cbthomas%40tsl.texas.gov%7C5a82aa8b2e60421f536608d559046c87%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636512797899575944&sdata=H8rPx3eMUqL9odaFaobkCdSWa586Tvb26vS7kHWE9bc%3D&reserved=0 From kyle.fortney at okstate.edu Thu Jan 11 10:35:11 2018 From: kyle.fortney at okstate.edu (Fortney, Kyle) Date: Thu, 11 Jan 2018 15:35:11 +0000 Subject: [Archivesspace_Users_Group] SSL Redirect Message-ID: <DM5PR03MB2779310D8D26D7F9DC2E29C59B160@DM5PR03MB2779.namprd03.prod.outlook.com> I am working on installing our SSL for our ArchivesSpace server. Unfortunately I cannot get the 8080 and 8081 redirects to work. I have followed the information in Step 2 at https://github.com/archivesspace/archivesspace/blob/master/README_HTTPS.md. Not sure how Step 1 is related. Our SSL is installed correctly as I can resolve the domain URL but using the domain name with the ports on the end fails. We are using Ubuntu 14.04 and Apache 2.4.7. Our AS instance is 1.5.1. Any insight would be appreciated. Kyle Fortney Computer Specialist 405-744-7924 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180111/7bdc11b4/attachment.html> From trthorn2 at ncsu.edu Thu Jan 11 12:53:00 2018 From: trthorn2 at ncsu.edu (Trevor Thornton) Date: Thu, 11 Jan 2018 12:53:00 -0500 Subject: [Archivesspace_Users_Group] SSL Redirect In-Reply-To: <DM5PR03MB2779310D8D26D7F9DC2E29C59B160@DM5PR03MB2779.namprd03.prod.outlook.com> References: <DM5PR03MB2779310D8D26D7F9DC2E29C59B160@DM5PR03MB2779.namprd03.prod.outlook.com> Message-ID: <CA+SdyS1bGK908E5Q0Fe8Q_G4RpA1wz_f-AgeuTcNG9Owhej_ng@mail.gmail.com> If you're following the example you shouldn't add the port numbers to the URL - staff.myarchive.org and research.myarchive.org (or whatever subdomains you're using) should serve the frontend (staff UI) and public UI respectively. SSL connections all happen over port 443, which is why you have to use the subdomain redirects instead of using the standard port numbers. I think the point of Step 1 is to restrict non-SSL connections to the default ports, which would otherwise be open by default. I struggled with this myself but I had a sysadmin to help me get everything configured correctly. Maybe somebody who is more well-versed in Apache configuration will chime in with more info. On Thu, Jan 11, 2018 at 10:35 AM, Fortney, Kyle <kyle.fortney at okstate.edu> wrote: > I am working on installing our SSL for our ArchivesSpace server. > Unfortunately I cannot get the 8080 and 8081 redirects to work. I have > followed the information in Step 2 at https://github.com/ > archivesspace/archivesspace/blob/master/README_HTTPS.md. Not sure how > Step 1 is related. Our SSL is installed correctly as I can resolve the > domain URL but using the domain name with the ports on the end fails. We > are using Ubuntu 14.04 and Apache 2.4.7. Our AS instance is 1.5.1. Any > insight would be appreciated. > > > > Kyle Fortney > > Computer Specialist > > 405-744-7924 <(405)%20744-7924> > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Trevor Thornton Applications Developer, Digital Library Initiatives North Carolina State University Libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180111/76e9d7ff/attachment.html> From kyle.fortney at okstate.edu Thu Jan 11 14:14:05 2018 From: kyle.fortney at okstate.edu (Fortney, Kyle) Date: Thu, 11 Jan 2018 19:14:05 +0000 Subject: [Archivesspace_Users_Group] SSL Redirect In-Reply-To: <CA+SdyS1bGK908E5Q0Fe8Q_G4RpA1wz_f-AgeuTcNG9Owhej_ng@mail.gmail.com> References: <DM5PR03MB2779310D8D26D7F9DC2E29C59B160@DM5PR03MB2779.namprd03.prod.outlook.com> <CA+SdyS1bGK908E5Q0Fe8Q_G4RpA1wz_f-AgeuTcNG9Owhej_ng@mail.gmail.com> Message-ID: <DM5PR03MB27794E61131E4BAF3C3891739B160@DM5PR03MB2779.namprd03.prod.outlook.com> I think therein lies my problem: we are not using subdomains. I kept looking that part over and worrying that that was the issue. I?ll get on that. Thank you for the reply. Kyle Fortney Computer Specialist 405-744-7924 From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Trevor Thornton Sent: Thursday, January 11, 2018 11:53 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] SSL Redirect If you're following the example you shouldn't add the port numbers to the URL - staff.myarchive.org<http://staff.myarchive.org> and research.myarchive.org<http://research.myarchive.org> (or whatever subdomains you're using) should serve the frontend (staff UI) and public UI respectively. SSL connections all happen over port 443, which is why you have to use the subdomain redirects instead of using the standard port numbers. I think the point of Step 1 is to restrict non-SSL connections to the default ports, which would otherwise be open by default. I struggled with this myself but I had a sysadmin to help me get everything configured correctly. Maybe somebody who is more well-versed in Apache configuration will chime in with more info. On Thu, Jan 11, 2018 at 10:35 AM, Fortney, Kyle <kyle.fortney at okstate.edu<mailto:kyle.fortney at okstate.edu>> wrote: I am working on installing our SSL for our ArchivesSpace server. Unfortunately I cannot get the 8080 and 8081 redirects to work. I have followed the information in Step 2 at https://github.com/archivesspace/archivesspace/blob/master/README_HTTPS.md. Not sure how Step 1 is related. Our SSL is installed correctly as I can resolve the domain URL but using the domain name with the ports on the end fails. We are using Ubuntu 14.04 and Apache 2.4.7. Our AS instance is 1.5.1. Any insight would be appreciated. Kyle Fortney Computer Specialist 405-744-7924<tel:(405)%20744-7924> _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Trevor Thornton Applications Developer, Digital Library Initiatives North Carolina State University Libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180111/990a6adc/attachment.html> From dale.poulter at Vanderbilt.Edu Sun Jan 14 10:55:57 2018 From: dale.poulter at Vanderbilt.Edu (Poulter, Dale) Date: Sun, 14 Jan 2018 15:55:57 +0000 Subject: [Archivesspace_Users_Group] public_url behind mod_proxy Message-ID: <4B55C1D28471794C811F425520B7B22566DBF08D@ITS-HCWNEM104.ds.vanderbilt.edu> Good morning, We are using ArchivesSpace behind the apache mod_proxy module. The system seems to work great except for the citation. The citation includes the localhost uri and not the correct uri. The config.rb has AppConfig[:public_proxy_url] = https://collections.library.vanderbilt.edu and we have also tried defining the :public_url the same way without any change to the citation. Has anyone else experience this issue? Thanks. --Dale --------------------------------------- Dale Poulter Director Library Technology and Digital Services Vanderbilt University 419 21st Avenue South, Room 812 Nashville, TN 37203-2427 (615)343-5388 (615)207-9705 (cell) dale.poulter at vanderbilt.edu<mailto:dale.poulter at vanderbilt.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180114/69c96102/attachment.html> From christine.dibella at lyrasis.org Tue Jan 16 08:54:51 2018 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Tue, 16 Jan 2018 13:54:51 +0000 Subject: [Archivesspace_Users_Group] New DevOps Specialist working with ArchivesSpace: Lora Woodford Message-ID: <CY1PR08MB11974D764E21401B8B8A0424F1EA0@CY1PR08MB1197.namprd08.prod.outlook.com> LYRASIS, the organizational home for ArchivesSpace, is pleased to announce that Lora Woodford will be joining us as our DevOps Specialist, working closely with the ArchivesSpace team on activities to better support ArchivesSpace users and improve the application. Lora knows ArchivesSpace well and is well-known in the ArchivesSpace community, having helped lead ArchivesSpace implementations at Johns Hopkins University and Colgate University. She is also an inaugural member of our Core Committers group. Lora has most recently been the Digital Archivist in the Special Collections department of Sheridan Libraries at Johns Hopkins University where she has created, documented, and managed workflows for acquiring, describing, processing, preserving, and providing access to born-digital materials. She participates in a wide range of activities related to improving processes for analog and digital records, as well as the University's records management program. She serves on the Libraries' IT Infrastructure Team and is a frequent collaborator on technological projects. In her three years prior at Colgate, she led a wide range of technical services and public services activities, and was an early adopter of ArchivesSpace, having co-written a successful proposal to fund their ArchivesSpace implementation in 2013. Having taught herself much about the technologies that the archival profession relies upon, Lora is passionate about building technological literacy in the archival community and getting archivists comfortable with tech tools that can make their lives easier. Partnered with her colleague Valerie Addonizio, Lora has developed and taught a workshop titled "There's an API for That!" that has been attended by dozens since its inception in 2017. She has served as a mentor and advisor to newer colleagues, interns, and a National Digital Stewardship Resident. She has long been an informal technical resource to people throughout the archival community, and we are delighted that she will take up this role more formally as our DevOps Specialist. As DevOps Specialist, Lora will be based in LYRASIS' Digital Technology Services department and participate in a range of technical support and development activities for ArchivesSpace, including responding to support tickets and writing code to fix bugs in the application. Through June 2018, her focus will be exclusively on ArchivesSpace. Beginning in July she will continue to be heavily involved with ArchivesSpace, but will also provide assistance with other closely aligned programs and services supported by Digital Technology Services, including Islandora and CollectionSpace. LYRASIS serves as the organizational home for ArchivesSpace, providing resources and services to help grow, support and amplify the community contributions. These include staff, technology, financial services and logistics support. Lora's first day will be January 29. She will continue to be based in Baltimore, but will become an even more active presence in the ArchivesSpace community as she represents ArchivesSpace and LYRASIS in various online and in person venues. Please join us in welcoming Lora Woodford to the LYRASIS team! Christine 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/20180116/b93a1ee1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 6608 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/b93a1ee1/attachment.jpg> From laurie.arp at lyrasis.org Tue Jan 16 10:45:39 2018 From: laurie.arp at lyrasis.org (Laurie Arp) Date: Tue, 16 Jan 2018 15:45:39 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace board update Message-ID: <BN6PR08MB2865EDEA25754FDA9B45F1648AEA0@BN6PR08MB2865.namprd08.prod.outlook.com> Distributing for Carol Mandel... Dear ArchivesSpace members, I am writing to report on the ArchivesSpace Governance Board 2nd Quarter meeting, a 2 hour call which was conducted December 4th. We reviewed the continued dedicated work of the Technical Advisory Council and User Advisory Council and thank the members for their strong participation. The operations update highlighted progress in development, especially the contributions from several ArchivesSpace member institutions that sponsored or contributed important functionality. The board is also encouraged by the creation of and continued progress by the core committers group. Gordon Daines graciously agree to chair the Nominating Committee this year. We appreciate him taking on this pivotal responsibility. The board is making progress on several important foundation documents. Work continues on the bylaws review, the organizational home agreement and updating a mission statement. A Budget Reserve Fund policy was approved. The board briefly discussed futureproofing ArchivesSpace, and will work with the LYRASIS organizational home over the next year to research and consider a number of key areas for potential needs and growth. In closing, I am very happy to report that the ArchivesSpace membership organization continues to be vital and growing, with members making contributions to all facets of the program. The Board welcomes your communications and comments. Thank you for your continuing support and ongoing participation in the community we have created together. Respectfully, Carol A. Mandel Chair, ArchivesSpace Governance Board Dean, Division of Libraries, New York University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/eef37a98/attachment.html> From Christine.Kim at lyrasis.org Tue Jan 16 11:49:49 2018 From: Christine.Kim at lyrasis.org (Christine Kim) Date: Tue, 16 Jan 2018 16:49:49 +0000 Subject: [Archivesspace_Users_Group] Webinar Announcement: ArchivesSpace Technology & Development Roadmap - Jan. 17 In-Reply-To: <MWHPR08MB24957A4580994B1DFA030D96F5100@MWHPR08MB2495.namprd08.prod.outlook.com> References: <MWHPR08MB2495A4AEFC18A671ED9F2AE5F5100@MWHPR08MB2495.namprd08.prod.outlook.com> <MWHPR08MB24957A4580994B1DFA030D96F5100@MWHPR08MB2495.namprd08.prod.outlook.com> Message-ID: <MWHPR08MB2495F727343A02619C6CBA5FF5EA0@MWHPR08MB2495.namprd08.prod.outlook.com> Reminder - Join us for the ArchivesSpace Technology & Development Roadmap webinar tomorrow, January 17! Details: http://archivesspace.org/webinar-roadmap/ Sent: Tuesday, January 9, 2018 11:46 AM Subject: [Archivesspace_tac] Webinar Announcement: ArchivesSpace Technology & Development Roadmap - Jan. 17 ArchivesSpace Technology & Development Roadmap When: Wednesday, January 17, 2018 Time: 2:00 p.m. - 2:30 p.m. EST (11:00 a.m. - 11:30 a.m. PST) Where: Webinar at http://lyrasis.adobeconnect.com/r1232xs0ku9h/ Dial-in only option: 888-354-0094 - Access code is 731627 No registration required. The session is limited to the first 100 participants. Please feel free to host a webinar viewing group. The webinar will be recorded and available for viewing at a later date. Webinar description: The ArchivesSpace Technology and Development roadmap is a planning and communication tool to help our community know what to expect in terms of future development work and aid in planning for upcoming releases. Distributed at the end of 2017, the latest version of our roadmap has many content and format updates, and now provides a series of views targeted at the needs of different kinds of ArchivesSpace stakeholders. The roadmap announcement can be found here: http://archivesspace.org/roadmap/. In this webinar, Program Manager Christine Di Bella will walk through the new roadmap format and also take questions and comments on the development planning process. Please feel free to bring any questions you have. Presenter: Christine Di Bella (Program Manager, ArchivesSpace) plays a key role working closely and collaboratively with the ArchivesSpace community, advisory groups, and Governance Board to set the strategy and goals for ArchivesSpace. With over 16 years of experience as an archivist in a number of academic and non-profit settings, Christine is involved in all aspects of the program, and serves as a key spokesperson and advocate for the program. Who should attend: Everyone interested in seeing the new roadmap and learning about updates and releases forthcoming in ArchivesSpace this year. Questions? Please contact Kim at christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/c7dc8f44/attachment.html> From FPitaro at ap.org Tue Jan 16 13:06:37 2018 From: FPitaro at ap.org (Pitaro, Francesca) Date: Tue, 16 Jan 2018 18:06:37 +0000 Subject: [Archivesspace_Users_Group] Extent field for Archival objects Message-ID: <BY1PR16MB005486112A3AFADF62371BBDC8EA0@BY1PR16MB0054.namprd16.prod.outlook.com> Hello, I'm hoping someone on the list can help with a fix for this problem. We have hundreds of archival objects that were migrated from Archivist's Toolkit with the extent field listed as "0". This did not display when we created PDF finding aids using toolkit, but it's very evident when creating finding aids in ArchivesSpace. The field shows up as "Physical Description: 0 item(s). We'd love to be able to delete any extent fields where the value is 0. Our ArchivesSpace application is hosted by Lyrasis as we don't have technical support for this type of work. Thanks, Francesca [cid:image005.jpg at 01D38ECA.D650E4C0] [cid:image001.jpg at 01D20F6D.9B388470] [signature-96] Francesca Pitaro Archivist AP Corporate Archives fpitaro at ap.org<mailto:fpitaro at ap.org> www.ap.org<http://www.ap.org/> 200 Liberty Street New York, NY 10281 T 212-621-7446 The information contained in this communication is intended for the use of the designated recipients named above. If the reader of this communication is not the intended recipient, you are hereby notified that you have received this communication in error, and that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify The Associated Press immediately by telephone at +1-212-621-1500 and delete this email. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/f1319f4d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 16409 bytes Desc: image005.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/f1319f4d/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 1112 bytes Desc: image006.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/f1319f4d/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 1001 bytes Desc: image007.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/f1319f4d/attachment-0002.jpg> From PGalligan at rockarch.org Tue Jan 16 13:11:46 2018 From: PGalligan at rockarch.org (Galligan, Patrick) Date: Tue, 16 Jan 2018 18:11:46 +0000 Subject: [Archivesspace_Users_Group] ArchivesSnake Needs Your Help! In-Reply-To: <1D6EEB51-7D91-45DB-BD1E-4A894DBFB318@rockarch.org> References: <1D6EEB51-7D91-45DB-BD1E-4A894DBFB318@rockarch.org> Message-ID: <15375D50-04DD-4A8D-BF90-FA102BC39A3C@rockarch.org> Just a reminder that ArchivesSnake is still looking for contributions to Github. We have about 2 weeks until our information gathering stage ends. Please email if you have any questions at all. -Patrick From: "Galligan, Patrick" <PGalligan at rockarch.org> Date: Thursday, December 7, 2017 at 2:13 PM To: Archivesspace Users Group <Archivesspace_Users_Group at lyralists.lyrasis.org> Subject: ArchivesSnake Needs Your Help! Hi all, I?m heading up a collaborative project that we?re calling ArchivesSnake. ArchivesSnake is attempting to create a Python Library of scripts for working with the ArchivesSpace API. We?ve got a great team going, and we?re currently in the information gathering stage. If you?ve written a Python script to work with the AS API, we want to hear about it! We have a Github page: https://github.com/archivesspace-labs/ArchivesSnake, but you?ll need access to write to it. We?re currently taking the approach of adding links to scripts in github repos, and you can use the RAC (https://github.com/archivesspace-labs/ArchivesSnake/blob/master/RAC_links.md) or U of Albany (https://github.com/archivesspace-labs/ArchivesSnake/blob/master/ualbanyExample.md) links for examples. If your code is not in Github yet, but you?re willing to share it, we?ll put it up on ArchivesSnake. If you want to add links yourself, please email me and I?ll add you as a Github collaborator. If you lack the time to add links yourself, or you?re just baffled by Github, email me links to your code, and I can put them up myself. We?re closing the information-gathering stage on January 31st, 2018. Please contact us before then. After we?ve gathered sufficient examples, we?ll start grouping like functions and try to find the best way to do everything. After which point we?ll start work on creating the open Python library for all your needs. Let me know if you have any questions! Best, Patrick Galligan Rockefeller Archive Center Digital Archivist pgalligan at rockarch.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/9bd1d218/attachment.html> From Christine.Kim at lyrasis.org Tue Jan 16 13:47:54 2018 From: Christine.Kim at lyrasis.org (Christine Kim) Date: Tue, 16 Jan 2018 18:47:54 +0000 Subject: [Archivesspace_Users_Group] DAO Notes in EAD In-Reply-To: <MWHPR08MB2495AC892971D1A5BAF52C90F50B0@MWHPR08MB2495.namprd08.prod.outlook.com> References: <BF7377CBEE38FD468371B36C139A68CB020FFC06@NY345EX10.na.GUGGENHEIM.ORG> <MWHPR08MB2495AC892971D1A5BAF52C90F50B0@MWHPR08MB2495.namprd08.prod.outlook.com> Message-ID: <MWHPR08MB249504DF60A35E50814D23FAF5EA0@MWHPR08MB2495.namprd08.prod.outlook.com> Hi everyone, Does anyone have recommendations on customizing the exports? Tali from the Guggenheim would like to have her notes exported in digital objects EAD. There seem to be a number of plugins as well. What is everyone using? Best wishes, Kim Christine Kim ArchivesSpace Community Engagement Coordinator christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> 800.999.8558 x4820 404.592.4820 Skype: ckim.lyrasis From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Kim Sent: Friday, December 15, 2017 1:12 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] DAO Notes in EAD Hi Tali, The EAD for the finding aid exports the DAO info that's in the resource record, but doesn't pull additional notes from the actual digital object record. The digital object record itself would need to be exported. Has anyone found a workaround for this? Is this something that should be submitted to JIRA? Best wishes, Kim Christine Kim ArchivesSpace Community Engagement Coordinator christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> 800.999.8558 x4820 404.592.4820 Skype: ckim.lyrasis From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tali Han Sent: Thursday, December 7, 2017 9:00 AM To: 'Archivesspace_Users_Group at lyralists.lyrasis.org' <Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] DAO Notes in EAD Hello everyone, I'm having trouble with note tags in DAO records when downloading EAD finding aids. During our migration to ArchivesSpace a few years ago, the copyright notes in <daodesc> were mapped as "General Notes" in ArchivesSpace DAO records. However, I noticed that "General Notes" or any other note fields in the DAO record do not export as part of the EAD from ArchivesSpace. I saw the following ticket but I believe this is about the PUI not the EAD export: https://archivesspace.atlassian.net/browse/AR-1807 It is crucial that the "General Note" (or any other appropriate field you can recommend) show up in our EAD XML document-we do not use the PUI but instead download the EAD and map it directly onto our online finding aid on the museum website<http://www.guggenheim.org/library-archives/archives-collections>. We are using ArchivesSpace version 2.2.0 in Google Chrome browser. Also, in the future, can I map DAO fields to export as <descriptivenote> in EAD3? Is this a setting we can tweak in the backend? I would really appreciate it if I can get any input or suggestions! Thank you! Best, Tali Tali (Chiyong) Han Archivist and Manager, Library and Archives Solomon R. Guggenheim Museum One Liberty Plaza, 24th Floor New York, NY 10006 Phone 212 360 4232 than at guggenheim.org<mailto:than at guggenheim.org> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/fc40ef95/attachment.html> From jgd1 at williams.edu Tue Jan 16 16:00:25 2018 From: jgd1 at williams.edu (Drmacich, Jessika) Date: Tue, 16 Jan 2018 16:00:25 -0500 Subject: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin Message-ID: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> Dear all, Has anyone experienced losing functionality with ArchivesSpace spreadsheet import plugin <https://github.com/harvard-library/aspace-import-excel> with the most current update? Simply, has anyone installed it and has it running on the latest ArchivesSpace CentOS 7? My very best, Jessika Jessika Drmacich Records Manager & Digital Resources Archivist Williams College Libraries Special Collections 413-597-4725 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/c56ff463/attachment.html> From sdm7g at virginia.edu Tue Jan 16 16:22:02 2018 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 16 Jan 2018 21:22:02 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin In-Reply-To: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> References: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> Message-ID: <34DF6413-2E18-438F-BD6E-4DAB2E905117@virginia.edu> Using it with v2.2.2 with CentOS 6.9. But I had to manually fix the Gemfile dependency issue by removing the version number for ?pry? : https://github.com/harvard-library/aspace-import-excel/issues/18 <https://github.com/harvard-library/aspace-import-excel/issues/18> But if GEM incompatibility is the problem, I don?t think ArchivesSpace will start up at all. But I could be wrong. What sort of loss of functionality are you seeing ? ( BTW: Is there any reason for pry to be packaged in production for this plugin instead of being wrapped in ?group :development do? block ? ) ? Steve M. > On Jan 16, 2018, at 4:00 PM, Drmacich, Jessika <jgd1 at williams.edu> wrote: > > Dear all, > > Has anyone experienced losing functionality with ArchivesSpace spreadsheet import plugin <https://github.com/harvard-library/aspace-import-excel> with the most current update? Simply, has anyone installed it and has it running on the latest ArchivesSpace CentOS 7? > > My very best, > > Jessika > > Jessika Drmacich > Records Manager & Digital Resources Archivist > Williams College Libraries > Special Collections > 413-597-4725 > _______________________________________________ > 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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/20acb631/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4943 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/20acb631/attachment.bin> From bobbi_fox at harvard.edu Tue Jan 16 16:28:36 2018 From: bobbi_fox at harvard.edu (Fox, Bobbi) Date: Tue, 16 Jan 2018 21:28:36 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin In-Reply-To: <34DF6413-2E18-438F-BD6E-4DAB2E905117@virginia.edu> References: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> <34DF6413-2E18-438F-BD6E-4DAB2E905117@virginia.edu> Message-ID: <CY1PR0701MB120940B5604018CF376BCB9E90EA0@CY1PR0701MB1209.namprd07.prod.outlook.com> Hi! As the developer: I don?t wrap the pry in the group development block, because when one of you kind remote users of this plugin has a problem, it might be helpful to refer to the log where unexpected errors get dumped via Pry::ColorPrinter In terms of the gemfile dependency issues, I thought I had them fixed in version v2.0.1 (https://github.com/harvard-library/aspace-import-excel/releases/tag/v2.0.1) (although I just noticed that I hadn?t closed the issue; Steve: are you still having the problem with v2.0.1?) We aren?t using CentOS, so I can?t speak to Jessika?s problems. Feel free to reach out to me directly to pursue either of these issues. Cheers, Bobbi 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: Tuesday, January 16, 2018 4:22 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin Using it with v2.2.2 with CentOS 6.9. But I had to manually fix the Gemfile dependency issue by removing the version number for ?pry? : https://github.com/harvard-library/aspace-import-excel/issues/18 But if GEM incompatibility is the problem, I don?t think ArchivesSpace will start up at all. But I could be wrong. What sort of loss of functionality are you seeing ? ( BTW: Is there any reason for pry to be packaged in production for this plugin instead of being wrapped in ?group :development do? block ? ) ? Steve M. On Jan 16, 2018, at 4:00 PM, Drmacich, Jessika <jgd1 at williams.edu<mailto:jgd1 at williams.edu>> wrote: Dear all, Has anyone experienced losing functionality with ArchivesSpace spreadsheet import plugin<https://github.com/harvard-library/aspace-import-excel> with the most current update? Simply, has anyone installed it and has it running on the latest ArchivesSpace CentOS 7? My very best, Jessika Jessika Drmacich Records Manager & Digital Resources Archivist Williams College Libraries Special Collections 413-597-4725 _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/2646c697/attachment.html> From sdm7g at virginia.edu Tue Jan 16 16:40:13 2018 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 16 Jan 2018 21:40:13 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin In-Reply-To: <CY1PR0701MB120940B5604018CF376BCB9E90EA0@CY1PR0701MB1209.namprd07.prod.outlook.com> References: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> <34DF6413-2E18-438F-BD6E-4DAB2E905117@virginia.edu> <CY1PR0701MB120940B5604018CF376BCB9E90EA0@CY1PR0701MB1209.namprd07.prod.outlook.com> Message-ID: <E7D74AAC-AB9A-4B10-92B4-F097D77F1AA1@virginia.edu> > On Jan 16, 2018, at 4:28 PM, Fox, Bobbi <bobbi_fox at harvard.edu> wrote: > > Hi! > > As the developer: > I don?t wrap the pry in the group development block, because when one of you kind remote users of this plugin has a problem, it might be helpful to refer to the log where unexpected errors get dumped via Pry::ColorPrinter I see: I was searching (case sensitive) for ?pry? in the source to find usage. Missed ?Pry? . ( Only method I ever use is binding.pry or binding.remote_pry. Never tried it for pretty printing. Sometimes used awesome_print to make log output more readable. ) > > In terms of the gemfile dependency issues, I thought I had them fixed in version v2.0.1 (https://github.com/harvard-library/aspace-import-excel/releases/tag/v2.0.1 <https://github.com/harvard-library/aspace-import-excel/releases/tag/v2.0.1>) (although I just noticed that I hadn?t closed the issue; Steve: are you still having the problem with v2.0.1?) Not using 2.0.1. Just 2.2.2 ( on both production and test now ). I had to do the manual fix at the time I installed it. I hadn?t checked back if a new release fixed that. > > We aren?t using CentOS, so I can?t speak to Jessika?s problems. > > Feel free to reach out to me directly to pursue either of these issues. > > Cheers, > Bobbi > > 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: Tuesday, January 16, 2018 4:22 PM > To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> > Subject: Re: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin > > > Using it with v2.2.2 with CentOS 6.9. But I had to manually fix the Gemfile dependency issue by removing the version number for ?pry? : > > https://github.com/harvard-library/aspace-import-excel/issues/18 <https://github.com/harvard-library/aspace-import-excel/issues/18> > > But if GEM incompatibility is the problem, I don?t think ArchivesSpace will start up at all. But I could be wrong. > > What sort of loss of functionality are you seeing ? > > > ( BTW: Is there any reason for pry to be packaged in production for this plugin instead of being wrapped in ?group :development do? block ? ) > > > ? Steve M. > > > On Jan 16, 2018, at 4:00 PM, Drmacich, Jessika <jgd1 at williams.edu <mailto:jgd1 at williams.edu>> wrote: > > Dear all, > > Has anyone experienced losing functionality with ArchivesSpace spreadsheet import plugin <https://github.com/harvard-library/aspace-import-excel> with the most current update? Simply, has anyone installed it and has it running on the latest ArchivesSpace CentOS 7? > > My very best, > > Jessika > > Jessika Drmacich > Records Manager & Digital Resources Archivist > Williams College Libraries > Special Collections > 413-597-4725 > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/c8766fe2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4943 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180116/c8766fe2/attachment.bin> From Kevin.Clair at du.edu Thu Jan 18 12:52:53 2018 From: Kevin.Clair at du.edu (Kevin Clair) Date: Thu, 18 Jan 2018 17:52:53 +0000 Subject: [Archivesspace_Users_Group] incompatible encodings error on the v2.2.2 public site Message-ID: <DM5PR11MB1449F37671EDA7BF6B95951F95E80@DM5PR11MB1449.namprd11.prod.outlook.com> Hello, We upgraded to version 2.2.2 last night, and since then we've received the following error message when attempting to view some collections in the PUI: Jan 18, 2018 9:25:21 AM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: F, [2018-01-18T09:25:21.858975 #8903] FATAL -- : [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] ActionView::Template::Error (incompat ible encodings: UTF-8 and ASCII-8BIT): Jan 18, 2018 9:25:21 AM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: F, [2018-01-18T09:25:21.859788 #8903] FATAL -- : [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 38: <section id="content" class ="container-fluid"> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 39: <a name="maincontent" id="maincontent"></a> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 40: <%= flash_messages %> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 41: <%= yield %> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 42: </section> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 43: [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 44: <script type="text/javascript" > I wrote a quick script to get the HTTP status codes for all of our collections in the PUI, and only 25 (out of 995) returned code 500, so this affects a small percentage of our collections and makes me think it might be an issue with our metadata or with the default character set in our database. I can confirm it's not an issue if I roll back to the previous release. I think we'll have to go back to 2.2.1 while we resolve this, but I was curious if anyone else had encountered it and if they had taken any steps to resolve it that I should be aware of. thanks! -k -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180118/52940d12/attachment.html> From mark.cooper at lyrasis.org Thu Jan 18 16:04:33 2018 From: mark.cooper at lyrasis.org (Mark Cooper) Date: Thu, 18 Jan 2018 21:04:33 +0000 Subject: [Archivesspace_Users_Group] incompatible encodings error on the v2.2.2 public site In-Reply-To: <DM5PR11MB1449F37671EDA7BF6B95951F95E80@DM5PR11MB1449.namprd11.prod.outlook.com> References: <DM5PR11MB1449F37671EDA7BF6B95951F95E80@DM5PR11MB1449.namprd11.prod.outlook.com> Message-ID: <3E98ACBF-9402-42D9-851D-2A802CACBEF4@lyrasis.org> Hi Kevin, That was fixed for v2.2.3 here: https://github.com/archivesspace/archivesspace/commit/3aa600169e2a78f9068195980ef2c83edcb228a5 Best, Mark LYRASIS On Jan 18, 2018, at 9:52 AM, Kevin Clair <Kevin.Clair at du.edu<mailto:Kevin.Clair at du.edu>> wrote: Hello, We upgraded to version 2.2.2 last night, and since then we?ve received the following error message when attempting to view some collections in the PUI: Jan 18, 2018 9:25:21 AM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: F, [2018-01-18T09:25:21.858975 #8903] FATAL -- : [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] ActionView::Template::Error (incompat ible encodings: UTF-8 and ASCII-8BIT): Jan 18, 2018 9:25:21 AM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: F, [2018-01-18T09:25:21.859788 #8903] FATAL -- : [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 38: <section id="content" class ="container-fluid"> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 39: <a name="maincontent" id="maincontent"></a> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 40: <%= flash_messages %> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 41: <%= yield %> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 42: </section> [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 43: [d38ccd85-ec57-45c7-a749-aed7fd4f64d5] 44: <script type="text/javascript" > I wrote a quick script to get the HTTP status codes for all of our collections in the PUI, and only 25 (out of 995) returned code 500, so this affects a small percentage of our collections and makes me think it might be an issue with our metadata or with the default character set in our database. I can confirm it?s not an issue if I roll back to the previous release. I think we?ll have to go back to 2.2.1 while we resolve this, but I was curious if anyone else had encountered it and if they had taken any steps to resolve it that I should be aware of. thanks! -k _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180118/44c1b680/attachment.html> From jgd1 at williams.edu Fri Jan 19 09:37:17 2018 From: jgd1 at williams.edu (Drmacich, Jessika) Date: Fri, 19 Jan 2018 09:37:17 -0500 Subject: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin In-Reply-To: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> References: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> Message-ID: <CAJ3o66xS_Jki0RK5bsCUrM4OdX8N2_TSqr1wAm9t7EjZJxy+3A@mail.gmail.com> Dear all, Thanks everyone (especially Steve) for the suggestions about editing the gem file to remove the version requirement for pry but, pardon my Ruby ignorance, can someone explain exactly which file to edit and what I need to change exactly? I've looked around in archivesspace/plugins/ aspace-import-excel/gems/gems/pry-0.11.3-java but i'm not sure what to edit there (or is it somewhere else? As always, thank you! My best, Jessika Jessika Drmacich Records Manager & Digital Resources Archivist Williams College Libraries Special Collections 413-597-4725 On Tue, Jan 16, 2018 at 4:00 PM, Drmacich, Jessika <jgd1 at williams.edu> wrote: > Dear all, > > Has anyone experienced losing functionality with ArchivesSpace spreadsheet > import plugin <https://github.com/harvard-library/aspace-import-excel> with > the most current update? Simply, has anyone installed it and has it > running on the latest ArchivesSpace CentOS 7? > > My very best, > > Jessika > > Jessika Drmacich > Records Manager & Digital Resources Archivist > Williams College Libraries > Special Collections > 413-597-4725 <(413)%20597-4725> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180119/119fddd3/attachment.html> From dave_mayo at harvard.edu Fri Jan 19 10:42:37 2018 From: dave_mayo at harvard.edu (Mayo, Dave) Date: Fri, 19 Jan 2018 15:42:37 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin In-Reply-To: <CAJ3o66xS_Jki0RK5bsCUrM4OdX8N2_TSqr1wAm9t7EjZJxy+3A@mail.gmail.com> References: <CAJ3o66zoomqKEsrGQWXcYRfgEYQ+NXwEReTprFnHdXF06j83EA@mail.gmail.com> <CAJ3o66xS_Jki0RK5bsCUrM4OdX8N2_TSqr1wAm9t7EjZJxy+3A@mail.gmail.com> Message-ID: <62A2658C-6ADE-45CD-8279-B8B99D9B9DD7@harvard.edu> Hi Jessika, The file you?d want to edit is the Gemfile file in the top directory of the plugin ? contents look like this: https://github.com/harvard-library/aspace-import-excel/blob/master/Gemfile On line 6, you?d remove the comma and everything after. - Dave From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of "Drmacich, Jessika" <jgd1 at williams.edu> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Date: Friday, January 19, 2018 at 9:37 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] ArchivesSpace spreadsheet import plugin Dear all, Thanks everyone (especially Steve) for the suggestions about editing the gem file to remove the version requirement for pry but, pardon my Ruby ignorance, can someone explain exactly which file to edit and what I need to change exactly? I've looked around in archivesspace/plugins/aspace-import-excel/gems/gems/pry-0.11.3-java but i'm not sure what to edit there (or is it somewhere else? As always, thank you! My best, Jessika Jessika Drmacich Records Manager & Digital Resources Archivist Williams College Libraries Special Collections 413-597-4725 On Tue, Jan 16, 2018 at 4:00 PM, Drmacich, Jessika <jgd1 at williams.edu<mailto:jgd1 at williams.edu>> wrote: Dear all, Has anyone experienced losing functionality with ArchivesSpace spreadsheet import plugin<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_harvard-2Dlibrary_aspace-2Dimport-2Dexcel&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=wwR60EiYxC-_PEetqPTubx4871iRoiu5OUQpkSi5JLg&s=EH7apbnHM2HqjiNJeXQd2BHSqZj9JSsYMxQvzZgtov4&e=> with the most current update? Simply, has anyone installed it and has it running on the latest ArchivesSpace CentOS 7? My very best, Jessika Jessika Drmacich Records Manager & Digital Resources Archivist Williams College Libraries Special Collections 413-597-4725<tel:(413)%20597-4725> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180119/d17cbd9f/attachment.html> From Christine.Kim at lyrasis.org Fri Jan 19 11:33:23 2018 From: Christine.Kim at lyrasis.org (Christine Kim) Date: Fri, 19 Jan 2018 16:33:23 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace Update - January 2018 Message-ID: <MWHPR08MB2495716E8D387CF235136405F5EF0@MWHPR08MB2495.namprd08.prod.outlook.com> [ASpaceOrgHome.jpg] January 2018 Update Happy New Year! We're excited to launch off the year with a warm welcome to our new DevOps Specialist! And mark your calendars -- we have a queue of webinars coming up early this year. New stories are up on the blog, and our demo videos are now updated to ArchivesSpace v2.2.2! Read on for more news! Development: Deadline for Pull Requests ArchivesSpace recently announced that starting with the January 2018 release we've set deadlines for submitting pull requests to be considered for the next release. Submitting a pull request by the deadline does not guarantee that it will go into the next release, but it will help ensure that we have adequate time to review and test it before potentially putting it into a release. In general, the pull request deadline is the third Friday of a month in which a release is scheduled, with occasional exceptions when a release is intended to come out earlier in the month. Just a reminder that the deadline by which a pull request needs to be submitted for consideration for the January 2018 release is January 19. Please submit any pull requests no later than the end of your day on January 19. Pull requests submitted after January 19 will be considered for a future release. If you have any questions, please get in touch. Thanks so much for your contributions and your help in making ArchivesSpace better! Upcoming Releases Curious about what's to come in future releases? Check out the roadmap: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/18710568/Roadmap Welcome, LYRASIS's DevOps Specialist, Lora Woodford! LYRASIS, the organizational home for ArchivesSpace, is pleased to announce that Lora Woodford will be joining us as our DevOps Specialist, working closely with the ArchivesSpace team on activities to better support ArchivesSpace users and improve the application. As DevOps Specialist, Lora will be based in LYRASIS' Digital Technology Services department and participate in a range of technical support and development activities for ArchivesSpace, including responding to support tickets and writing code to fix bugs in the application. Through June 2018, her focus will be exclusively on ArchivesSpace. Beginning in July she will continue to be heavily involved with ArchivesSpace, but will also provide assistance with other closely aligned programs and services supported by Digital Technology Services, including Islandora and CollectionSpace. LYRASIS serves as the organizational home for ArchivesSpace, providing resources and services to help grow, support and amplify the community contributions. These include staff, technology, financial services and logistics support. Lora's first day will be January 29. She will continue to be based in Baltimore, but will become an even more active presence in the ArchivesSpace community as she represents ArchivesSpace and LYRASIS in various online and in person venues. The full announcement is available here: http://archivesspace.org/welcome-lyrasis-new-devops-specialist-lora-woodford/. Please join us in welcoming Lora Woodford to the LYRASIS team! Demo Videos A guided tour of ArchivesSpace version 2.2.2 is available through a new series of demo videos. These videos provide an overview of the major features and functions of the application: <https://goo.gl/Y7dKA9> http://archivesspace.org/application/demo/ This series of videos shows all the major functionalities for the staff and public interfaces. The demo videos may be watched in the order presented, or select the video most relevant to your user perspective: * Overview of Features in ArchivesSpace * Staff Interface Demo: Managing the Application * Staff Interface Demo: Managing & Describing Records * ArchivesSpace Public User Interface Demo Please feel free to share these with anyone who is interested in learning more about ArchivesSpace. Open Members Call on Zoom! February 21, 2-3pm ET (11-noon PT) Please save the date for our next informal community Zoom call coming up on February 21 at 2-3pm ET (11-noon PT). This is an opportunity to hear updates from each other and encourage group discussion. You will be able to join by either computer or phone. This is a space surface news, ideas, and challenges. This might be an especially good chance to talk about non-technical questions or ideas that you weren't quite sure about posting on the Users Group listserv but really would like help with from us or your peers. An announcement with call in details will be sent out shortly. It will include a pre-survey to generate discussion topics prior to the call. Please email Kim at christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> if you have any questions. We look forward to "seeing" you there! Webinar on the ArchivesSpace Technology & Development Roadmap: Recording Available Thanks to all who joined our webinar on the ArchivesSpace Technology & Development Roadmap. For those who were unable to make it, the webinar has been recorded and is available here: http://archivesspace.org/recording-and-slides-for-aspace-roadmap-webinar/ Special thanks to our presenter, Christine Di Bella (Program Manager, ArchivesSpace). Save the date for upcoming web events! Formal announcements to follow. * Open Members Call on Zoom! [February 21, 2-3pm ET / 11-noon PT] * Webinar: Assessments Module Overview & Implementation [March 2, 1-2pm ET / 10-11am PT] * Webinar: A Bug's Life: From JIRA to Fix [April 11, 1-2pm ET / 10-11am PT] * Webinar: A History of the Finding Aid [May 16, 1-2pm ET, 10-11am PT] ArchivesSpace Advanced Skills Workshop Development Survey The ArchivesSpace Training Corps is developing advanced skills workshops and requests your help to explore potential topics to include. When you have a moment, please share your ideas through this survey: https://goo.gl/forms/Lsx9xAG3CBQQzg5J3 Open ended questions are included. Please feel free to include any type of content you feel would benefit someone who would like to get more out of ArchivesSpace, or any type of training or skills you would like to expand on yourself. Training topics currently available are listed on our website: http://archivesspace.org/using-archivesspace/training-and-consultations/ We are accepting responses until January 31st. Please email Kim at christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> if you have any questions. Boston Regional Forum: Call for Working Group Volunteers We are happy to announce the first regional forum will be coming to the Boston area on May 3, 2018 at Tufts University. We have been looking forward to offering regional forums for the ArchivesSpace community. We envision these forums as opportunities for our diverse ArchivesSpace members to meet up more locally to share and learn from each other through workshops, focused discussion sessions, and presentations. We would love for the content to be shaped by the community. This working group will focus on identifying program content, connecting with presenters, and suggesting local arrangements. Additionally, other potential tasks will include hands-on assistance during the forum such as running the registration table and taking notes. The program team will take care of any details concerning cost and logistics. If you (or you know someone interested) would like to join the working group to plan the ArchivesSpace Regional Forum in Boston, feel free to email Kim at christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org> by January 31st. Please let me know if you have any questions, and thank you for considering. New Stories on the Blog We have new stories posted on the blog! In User Insights, Amber J. D'Ambrosio (Processing Archivist & Records Manager, Willamette University) shares on her experience migrating and cleaning up data. In All About Community, Lydia Tang (Special Collections Archivist-Librarian, Michigan State University) reflects on her recent experience leading a large team of volunteers focused on drafting recommendations for the Staff Interface Enhancement Working Group. User Insights is a blog series that highlights diverse perspectives and experiences of ArchivesSpace users to enrich our entire community through shared stories, strategies, and lessons learned. http://archivesspace.org/category/user-insights/ All About Community is a blog series that highlights the many teams and groups that contribute to the growth and development of ArchivesSpace. http://archivesspace.org/category/all-about-community/ We would love to include your ArchivesSpace stories on the blog! If you would like to contribute, please email Kim at christine.kim at lyrasis.org<mailto:christine.kim at lyrasis.org>. Membership Update We are excited to welcome our newest members to our community! Our new members since December 21 include: * Wheaton College (IL) or Wheaton College, Buswell Library * Maryland Institute College of Art * Institute of American Indian Arts Archives * Richard Diebenkorn Foundation As of January 19, we have 349 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 roundtable 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180119/ce28942b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 20006 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180119/ce28942b/attachment.jpg> From mark.custer at yale.edu Fri Jan 19 11:37:26 2018 From: mark.custer at yale.edu (Custer, Mark) Date: Fri, 19 Jan 2018 16:37:26 +0000 Subject: [Archivesspace_Users_Group] public_url behind mod_proxy In-Reply-To: <4B55C1D28471794C811F425520B7B22566DBF08D@ITS-HCWNEM104.ds.vanderbilt.edu> References: <4B55C1D28471794C811F425520B7B22566DBF08D@ITS-HCWNEM104.ds.vanderbilt.edu> Message-ID: <BN3PR08MB1303B78E4575A6372DFC6A588CEF0@BN3PR08MB1303.namprd08.prod.outlook.com> Dale, Which version of ArchivesSpace are you using? I think that this issue was fixed in the 2.2.0 release. Here's the JIRA ticket: https://archivesspace.atlassian.net/browse/ANW-209 Not only does the citation link show up incorrectly in earlier versions, but the "home" link also doesn't work due to that bug, which is even worse, I think. Mark p.s. I can't believe it's been about 2.5 years since the XQuery Summer Institute. You and everyone else at Vanderbilt were amazing hosts! ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Poulter, Dale <dale.poulter at Vanderbilt.Edu> Sent: Sunday, January 14, 2018 10:55 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] public_url behind mod_proxy Good morning, We are using ArchivesSpace behind the apache mod_proxy module. The system seems to work great except for the citation. The citation includes the localhost uri and not the correct uri. The config.rb has AppConfig[:public_proxy_url] = https://collections.library.vanderbilt.edu<https://urldefense.proofpoint.com/v2/url?u=https-3A__collections.library.vanderbilt.edu&d=DwMFAg&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=ogDu02-XqwaCdeNf7aBgNUi9-PiaVDg33MfBIJToVO4&s=qHh3vnXq6j7N5NscIdgKQC9Rg_bnhTPObckRN-ZlVeA&e=> and we have also tried defining the :public_url the same way without any change to the citation. Has anyone else experience this issue? Thanks. --Dale --------------------------------------- Dale Poulter Director Library Technology and Digital Services Vanderbilt University 419 21st Avenue South, Room 812 Nashville, TN 37203-2427 (615)343-5388 (615)207-9705 (cell) dale.poulter at vanderbilt.edu<mailto:dale.poulter at vanderbilt.edu> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180119/61b6af63/attachment.html> From rstanonik at ucsd.edu Mon Jan 22 12:00:45 2018 From: rstanonik at ucsd.edu (Stanonik, Ronald) Date: Mon, 22 Jan 2018 17:00:45 +0000 Subject: [Archivesspace_Users_Group] logs lost on restart Message-ID: <CO2PR04MB2134E48AB904006F968DE9CFD8EC0@CO2PR04MB2134.namprd04.prod.outlook.com> We notice that when Archivesspace is restarted, the current day's logs are overwritten. >From the init script $startup_cmd &> \"$ARCHIVESSPACE_LOGS\" It would be helpful if the logs were instead appended on restart. Thanks, Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180122/fc3f077c/attachment.html> From christine.dibella at lyrasis.org Mon Jan 22 13:00:20 2018 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Mon, 22 Jan 2018 18:00:20 +0000 Subject: [Archivesspace_Users_Group] archives-knowledgeable web design consultant suggestions? Message-ID: <CY1PR08MB1197500B3086985B8219F699F1EC0@CY1PR08MB1197.namprd08.prod.outlook.com> Hello ArchivesSpace members, Following on the Staff Interface Enhancement Group's recommendations, we are looking into contracting for a small consulting project to provide guidance on ways to optimize the accessibility, usability, and attractiveness of ArchivesSpace's staff interface. The group has done a tremendous job in analyzing and conveying what is wanted from a functionality and efficiency standpoint, which will provide a substantial leg up in thinking about how to best to improve the look and layout of the interface. We have some web design firms in mind based on past work, but we'd love to hear from you if your library or archives has worked with someone and been really impressed with the process and the results. Given that this is a project focused on the staff interface, ideally we're looking for individuals or firms that already have some understanding of what an archives is, how if differs from a library, and what archivists do, but we're open to all suggestions. Thanks in advance for your thoughts, and please do let me know if you have questions. As we're hoping for the project to start this winter, I'd love to hear from you by February 5 if you do have suggestions. Christine 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] [cid:image002.png at 01D39036.091DD4A0] Applications are now open for the 2018 Catalyst Fund<https://www.lyrasis.org/Leadership/Pages/Catalyst-Fund.aspx> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180122/fd0b2a76/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 7845 bytes Desc: image004.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180122/fd0b2a76/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 6608 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180122/fd0b2a76/attachment.jpg> From shorowitz at haverford.edu Tue Jan 23 11:45:43 2018 From: shorowitz at haverford.edu (Sarah Horowitz) Date: Tue, 23 Jan 2018 11:45:43 -0500 Subject: [Archivesspace_Users_Group] MARC export issues Message-ID: <CAE9kY79Uxm_1G0141radN7OfN+A64DaJEZEhgR_BZ357N=v=Jw@mail.gmail.com> Hello everyone, We are doing bulk exports of MARC records from our collections, and have run across some issues with the date field. If we use date expression and just numbers, we seem to be fine. However, if we use the begin and end fields, we end up with extra spaces in the date field. If we use date expression and it has "and undated" or some other text in it, it doesn't seem to be exporting. Has anyone else experience this problem. It seems that anything coded as bulk dates is not exporting. Is this true for others? Many thanks for any help you can provide! All best wishes, Sarah -- Sarah Horowitz Curator of Rare Books and Manuscripts Head of Quaker & Special Collections Haverford College Libraries Haverford College 370 Lancaster Ave. Haverford, PA 19041 (610) 896-2948 shorowitz at haverford.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180123/c994cd85/attachment.html> From clobdel1 at swarthmore.edu Tue Jan 23 15:45:54 2018 From: clobdel1 at swarthmore.edu (Chelsea Lobdell) Date: Tue, 23 Jan 2018 15:45:54 -0500 Subject: [Archivesspace_Users_Group] error on v2.2.0 PUI print PDF: InvalidAuthenticityToken Message-ID: <CANoeXEb88NJO51PYbnoK06H=oPvsoE8X21sHgK4B1fL4mGV87g@mail.gmail.com> Hi Aspace! I saw this post on the user group but was not able to find the thread in my email so I apologize for replying off thread. We are seeing this same error and we are running v.2.2.2 However, the error seems to be browser specific as it only happens in Chrome. Here's the log output: Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: W, [2018-01-23T15:32:31.474750 #21127] WARN -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Can't verify CSRF token authenticity. Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: I, [2018-01-23T15:32:31.478068 #21127] INFO -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Completed 422 Unprocessable Entity in 6ms Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: F, [2018-01-23T15:32:31.485699 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: F, [2018-01-23T15:32:31.486567 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: F, [2018-01-23T15:32:31.487220 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Steve, were you ever able to find a solution for this? Has anybody else encountered this error when trying to print a PDF of a collection in Chrome? Thanks, Chelsea *---------------* *Chelsea Lobdell* *Library Web Developer/ Swarthmore College* *clobdel1 at swarthmore.edu <clobdel1 at swarthmore.edu> / (610)690-6818* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180123/0dfac850/attachment.html> From clobdel1 at swarthmore.edu Tue Jan 23 16:25:28 2018 From: clobdel1 at swarthmore.edu (Chelsea Lobdell) Date: Tue, 23 Jan 2018 16:25:28 -0500 Subject: [Archivesspace_Users_Group] error on v2.2.0 PUI print PDF: InvalidAuthenticityToken In-Reply-To: <CANoeXEb88NJO51PYbnoK06H=oPvsoE8X21sHgK4B1fL4mGV87g@mail.gmail.com> References: <CANoeXEb88NJO51PYbnoK06H=oPvsoE8X21sHgK4B1fL4mGV87g@mail.gmail.com> Message-ID: <CANoeXEbTuJNjVqMutioBvrxEsJ-f4uR_vEYACCTkB67XQ_=TtQ@mail.gmail.com> Update: we were able to identify that this error was happening only when running the application over SSL. Accessing the site over non-SSL allowed the print function to work. - Chelsea *---------------* *Chelsea Lobdell* *Library Web Developer/ Swarthmore College* *clobdel1 at swarthmore.edu <clobdel1 at swarthmore.edu> / (610)690-6818* On Tue, Jan 23, 2018 at 3:45 PM, Chelsea Lobdell <clobdel1 at swarthmore.edu> wrote: > Hi Aspace! > > I saw this post on the user group but was not able to find the thread in > my email so I apologize for replying off thread. > > We are seeing this same error and we are running v.2.2.2 However, the > error seems to be browser specific as it only happens in Chrome. Here's the > log output: > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context > log > INFO: W, [2018-01-23T15:32:31.474750 #21127] WARN -- : > [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Can't verify CSRF token > authenticity. > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context > log > INFO: I, [2018-01-23T15:32:31.478068 #21127] INFO -- : > [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Completed 422 Unprocessable Entity > in 6ms > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context > log > INFO: F, [2018-01-23T15:32:31.485699 #21127] FATAL -- : > [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context > log > INFO: F, [2018-01-23T15:32:31.486567 #21127] FATAL -- : > [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] ActionController::InvalidAuthenticityToken > (ActionController::InvalidAuthenticityToken): > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context > log > INFO: F, [2018-01-23T15:32:31.487220 #21127] FATAL -- : > [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] > > Steve, were you ever able to find a solution for this? Has anybody else > encountered this error when trying to print a PDF of a collection in > Chrome? > > Thanks, > Chelsea > *---------------* > *Chelsea Lobdell* > *Library Web Developer/ Swarthmore College* > *clobdel1 at swarthmore.edu <clobdel1 at swarthmore.edu> / (610)690-6818 > <(610)%20690-6818>* > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180123/f673bcce/attachment.html> From sdm7g at virginia.edu Tue Jan 23 17:15:47 2018 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 23 Jan 2018 22:15:47 +0000 Subject: [Archivesspace_Users_Group] error on v2.2.0 PUI print PDF: InvalidAuthenticityToken In-Reply-To: <CANoeXEbTuJNjVqMutioBvrxEsJ-f4uR_vEYACCTkB67XQ_=TtQ@mail.gmail.com> References: <CANoeXEb88NJO51PYbnoK06H=oPvsoE8X21sHgK4B1fL4mGV87g@mail.gmail.com> <CANoeXEbTuJNjVqMutioBvrxEsJ-f4uR_vEYACCTkB67XQ_=TtQ@mail.gmail.com> Message-ID: <7D1A71F6-77CD-47A2-9D98-070DDA6E8065@virginia.edu> Thanks. Yes: I?m still seeing the problem. No: no solution so far. The fact that I was only seeing it on production limited my ability to debug. Now that you?ve found it?s linked to SSL proxy, I will try to set up test machines to reproduce the problem. ? Steve. > On Jan 23, 2018, at 4:25 PM, Chelsea Lobdell <clobdel1 at swarthmore.edu> wrote: > > Update: we were able to identify that this error was happening only when running the application over SSL. Accessing the site over non-SSL allowed the print function to work. > > - Chelsea > > --------------- > Chelsea Lobdell > Library Web Developer/ Swarthmore College > clobdel1 at swarthmore.edu <mailto:clobdel1 at swarthmore.edu> / (610)690-6818 > > On Tue, Jan 23, 2018 at 3:45 PM, Chelsea Lobdell <clobdel1 at swarthmore.edu <mailto:clobdel1 at swarthmore.edu>> wrote: > Hi Aspace! > > I saw this post on the user group but was not able to find the thread in my email so I apologize for replying off thread. > > We are seeing this same error and we are running v.2.2.2 However, the error seems to be browser specific as it only happens in Chrome. Here's the log output: > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log > INFO: W, [2018-01-23T15:32:31.474750 #21127] WARN -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Can't verify CSRF token authenticity. > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log > INFO: I, [2018-01-23T15:32:31.478068 #21127] INFO -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Completed 422 Unprocessable Entity in 6ms > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log > INFO: F, [2018-01-23T15:32:31.485699 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log > INFO: F, [2018-01-23T15:32:31.486567 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): > > Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log > INFO: F, [2018-01-23T15:32:31.487220 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] > > Steve, were you ever able to find a solution for this? Has anybody else encountered this error when trying to print a PDF of a collection in Chrome? > > Thanks, > Chelsea > --------------- > Chelsea Lobdell > Library Web Developer/ Swarthmore College > clobdel1 at swarthmore.edu <mailto:clobdel1 at swarthmore.edu> / (610)690-6818 <tel:(610)%20690-6818> > _______________________________________________ > 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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180123/a06f5333/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4943 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180123/a06f5333/attachment.bin> From sdm7g at virginia.edu Tue Jan 23 17:46:15 2018 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 23 Jan 2018 22:46:15 +0000 Subject: [Archivesspace_Users_Group] error on v2.2.0 PUI print PDF: InvalidAuthenticityToken In-Reply-To: <7D1A71F6-77CD-47A2-9D98-070DDA6E8065@virginia.edu> References: <CANoeXEb88NJO51PYbnoK06H=oPvsoE8X21sHgK4B1fL4mGV87g@mail.gmail.com> <CANoeXEbTuJNjVqMutioBvrxEsJ-f4uR_vEYACCTkB67XQ_=TtQ@mail.gmail.com> <7D1A71F6-77CD-47A2-9D98-070DDA6E8065@virginia.edu> Message-ID: <B036A0FB-19D1-410D-B463-65B01438418C@virginia.edu> Also discovered that PDF print thru SSL proxy does work in Firefox after googling ?authenticity token proxy ssl? and seeing title of this Rails issue: CSRF protection prevents some webkit users from submitting forms ? Issue #21948 ? rails/rails <https://github.com/rails/rails/issues/21948> I?ve been seeing the bug in Safari, and you?ve been seeing it in Chrome. Both, I believe, are webkit based. Long discussion thread that I haven?t digested yet, so I?m not sure if that is the problem here. That same google search brings up some other issues that may be related to not passing all of the headers thru proxy. https://github.com/rails/rails/issues/22965 <https://github.com/rails/rails/issues/22965> ? Steve M. > On Jan 23, 2018, at 5:15 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu> wrote: > > > Thanks. Yes: I?m still seeing the problem. No: no solution so far. > The fact that I was only seeing it on production limited my ability to debug. > Now that you?ve found it?s linked to SSL proxy, I will try to set up test machines to reproduce the problem. > > ? Steve. > > > >> On Jan 23, 2018, at 4:25 PM, Chelsea Lobdell <clobdel1 at swarthmore.edu <mailto:clobdel1 at swarthmore.edu>> wrote: >> >> Update: we were able to identify that this error was happening only when running the application over SSL. Accessing the site over non-SSL allowed the print function to work. >> >> - Chelsea >> >> --------------- >> Chelsea Lobdell >> Library Web Developer/ Swarthmore College >> clobdel1 at swarthmore.edu <mailto:clobdel1 at swarthmore.edu> / (610)690-6818 >> >> On Tue, Jan 23, 2018 at 3:45 PM, Chelsea Lobdell <clobdel1 at swarthmore.edu <mailto:clobdel1 at swarthmore.edu>> wrote: >> Hi Aspace! >> >> I saw this post on the user group but was not able to find the thread in my email so I apologize for replying off thread. >> >> We are seeing this same error and we are running v.2.2.2 However, the error seems to be browser specific as it only happens in Chrome. Here's the log output: >> >> Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log >> INFO: W, [2018-01-23T15:32:31.474750 #21127] WARN -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Can't verify CSRF token authenticity. >> >> Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log >> INFO: I, [2018-01-23T15:32:31.478068 #21127] INFO -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] Completed 422 Unprocessable Entity in 6ms >> >> Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log >> INFO: F, [2018-01-23T15:32:31.485699 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] >> >> Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log >> INFO: F, [2018-01-23T15:32:31.486567 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): >> >> Jan 23, 2018 3:32:31 PM org.eclipse.jetty.server.handler.ContextHandler$Context log >> INFO: F, [2018-01-23T15:32:31.487220 #21127] FATAL -- : [e1415e7e-47c5-4776-893f-cb5a7b33a4d9] >> >> Steve, were you ever able to find a solution for this? Has anybody else encountered this error when trying to print a PDF of a collection in Chrome? >> >> Thanks, >> Chelsea >> --------------- >> Chelsea Lobdell >> Library Web Developer/ Swarthmore College >> clobdel1 at swarthmore.edu <mailto:clobdel1 at swarthmore.edu> / (610)690-6818 <tel:(610)%20690-6818> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > 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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180123/1ba3c6bf/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4943 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180123/1ba3c6bf/attachment.bin> From clobdel1 at swarthmore.edu Wed Jan 24 10:39:30 2018 From: clobdel1 at swarthmore.edu (Chelsea Lobdell) Date: Wed, 24 Jan 2018 10:39:30 -0500 Subject: [Archivesspace_Users_Group] Repository Branding Image not displaying in print to PDF Message-ID: <CANoeXEZq-Kwt+=e3+HpB1SiiFsW+ov72dD1kKLjmoMaOqEKrFQ@mail.gmail.com> The repository branding image is not displaying for one of our repositories when you try to print a collection to PDF. The space where the branding image would go on the PDF is just blank. The image comes through for our other repositories so not sure what's going on with this one. I've tried using an images from one of the other repositories that does work and it still fails in this repository. I've restarted the application and compared the repository of the problematic one to one where the branding image comes through in both the aspace admin interface and the DB and I can discern no difference. Any suggestions? Thanks, Chelsea *---------------* *Chelsea Lobdell* *Library Web Developer/ Swarthmore College* *clobdel1 at swarthmore.edu <clobdel1 at swarthmore.edu> / (610)690-6818* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180124/5b0e6cd2/attachment.html> From christine.dibella at lyrasis.org Wed Jan 24 11:07:05 2018 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Wed, 24 Jan 2018 16:07:05 +0000 Subject: [Archivesspace_Users_Group] release candidate available - ArchivesSpace v2.3.0-RC1 Message-ID: <CY1PR08MB11976F5D50D948FE74615CF7F1E20@CY1PR08MB1197.namprd08.prod.outlook.com> The ArchivesSpace team is pleased to announce a release candidate, v2.3.0-RC1. You can download it at https://github.com/archivesspace/archivesspace/releases/tag/v2.3.0-RC1 or test it out without downloading at http://test.archivesspace.org (username admin /password admin). This release candidate contains a number of community pull requests along with a few bug fixes, some reports updates, and the start of the enhancement of the Agents Module (JIRA with the full specification available at https://archivesspace.atlassian.net/browse/AR-1779). The most notable bug fixes are: * repairing component scrambling that can happen when exporting EAD after re-ordering tree nodes * enabling the use of a proxy prefix * correcting digital object linking problems in the public interface The first work on the enhanced Agents Module is included in this release, namely a new feature that allows systems administrators and repository managers to add fields to the required field list in the Agents Record for all four types of agents. Additional agents specification work will be included in upcoming releases. Thanks to community members Mark Cooper, Chris Fitzpatrick, Bobbi Fox, and Blake Carver for their contributions. We are also very appreciative of the work of our Development Prioritization subteam, Testing subteam, and Core Committers Group in helping prioritize, test, and do code review for issues for this release. Please test this release candidate as you are able over the next few days and report any issues you find to me at christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>. Barring significant issues, we hope to make the production release available sometime next week. Christine 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] [cid:image002.png at 01D39036.091DD4A0] Applications are now open for the 2018 Catalyst Fund<https://www.lyrasis.org/Leadership/Pages/Catalyst-Fund.aspx> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180124/ee03ac5f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 7845 bytes Desc: image003.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180124/ee03ac5f/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6608 bytes Desc: image002.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180124/ee03ac5f/attachment.jpg> From nmargulis at astate.edu Wed Jan 24 13:02:11 2018 From: nmargulis at astate.edu (Natasha Margulis) Date: Wed, 24 Jan 2018 18:02:11 +0000 Subject: [Archivesspace_Users_Group] struggling to get ArchivesSpace exported PDF to look properly Message-ID: <b29dea4d8ccc4868a3f6ce759cfaa911@MBX13-02.astate.edu> Hello ArchivesSpace Users I am not sure wherein the problem lies, but I when I export my Finding Aid (resource) to PDF, it crams all the information for the title together without any spaces between the collection name and the identifier. All advice is appreciated! For example, the collection name is KAIT-8 TV 16mm Newsfilm Collection but the title of the finding aid looks like this. KAIT-8 TV 16mm Newsfilm CollectionASTATEFA.1998.01.01 Best, Natasha R. Margulis ________________________________ [http://area51.astate.edu/e-footer/astatelogo-email.jpg]<http://www.astate.edu/> Natasha R. Margulis Political Collections and Access Management Archivist Archives & Special Collections 7th Floor, Dean B. Ellis Library P.O. Box 2040 | State University, AR 72467 p: (870) 972-3128 | f: (870) 972-3199 Arkansas State educates leaders, enhances intellectual growth, and enriches lives. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180124/e9afb74d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 7937 bytes Desc: image003.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180124/e9afb74d/attachment.jpg> From clobdel1 at swarthmore.edu Thu Jan 25 14:45:02 2018 From: clobdel1 at swarthmore.edu (Chelsea Lobdell) Date: Thu, 25 Jan 2018 14:45:02 -0500 Subject: [Archivesspace_Users_Group] Repository Branding Image not displaying in print to PDF In-Reply-To: <CANoeXEZq-Kwt+=e3+HpB1SiiFsW+ov72dD1kKLjmoMaOqEKrFQ@mail.gmail.com> References: <CANoeXEZq-Kwt+=e3+HpB1SiiFsW+ov72dD1kKLjmoMaOqEKrFQ@mail.gmail.com> Message-ID: <CANoeXEY8rponV=SkMih6VKALDx0fBrR5ZoE25CF_yTethZuqdw@mail.gmail.com> Update: We were able to resolve this issue by forcing a re-index. Thanks all! - Chelsea *---------------* *Chelsea Lobdell* *Library Web Developer/ Swarthmore College* *clobdel1 at swarthmore.edu <clobdel1 at swarthmore.edu> / (610)690-6818* On Wed, Jan 24, 2018 at 10:39 AM, Chelsea Lobdell <clobdel1 at swarthmore.edu> wrote: > The repository branding image is not displaying for one of our > repositories when you try to print a collection to PDF. The space where the > branding image would go on the PDF is just blank. The image comes through > for our other repositories so not sure what's going on with this one. > > I've tried using an images from one of the other repositories that does > work and it still fails in this repository. I've restarted the application > and compared the repository of the problematic one to one where the > branding image comes through in both the aspace admin interface and the DB > and I can discern no difference. > > Any suggestions? > > Thanks, > Chelsea > *---------------* > *Chelsea Lobdell* > *Library Web Developer/ Swarthmore College* > *clobdel1 at swarthmore.edu <clobdel1 at swarthmore.edu> / (610)690-6818 > <(610)%20690-6818>* > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180125/e09098a6/attachment.html> From blake.carver at lyrasis.org Fri Jan 26 13:49:02 2018 From: blake.carver at lyrasis.org (Blake Carver) Date: Fri, 26 Jan 2018 18:49:02 +0000 Subject: [Archivesspace_Users_Group] Running archivesspace from systemd In-Reply-To: <CAJ2fXCPVXPrRJwM=i812ouFQ70n1WsWSfP=LPAr=PoNomZRQsA@mail.gmail.com> References: <CAJ2fXCPVXPrRJwM=i812ouFQ70n1WsWSfP=LPAr=PoNomZRQsA@mail.gmail.com> Message-ID: <CY1PR08MB1248879F76F47FA574C3EE929FE00@CY1PR08MB1248.namprd08.prod.outlook.com> Has anyone had any luck with systemd yet? ________________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Flannon Jackson <flannon at nyu.edu> Sent: Monday, August 7, 2017 2:01:15 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Running archivesspace from systemd Hi All, I'm trying to run the archivesspace daemon from a systemd unit file but I'm getting an odd delay. If I start archivesspace manually by running "$ sudo archivesspace.sh start" things run normally, but when I start archivesspace from systemctl then any operation on port 8080 delays from 10 to 20 seconds before it returns results. If anyone is running archivesspace from systemctl and can offer any advice it would be appreciated. The details of my deployment are as follow, OS : Centos 7.3.10 Java: OpenJDK 1.8.0_141 archivesspace: 2.0.0 | 2.0.1 | 2.1.0 (i've tried all three with the same results) My unit file is as follows, [Unit] Description=Archivesspace Service After=syslog.target network.target [Service] Type=forking ExecStart=/opt/archivesspace/archivesspace.sh start PIDFile=/opt/archivesspace/data/.archivesspace.pid User=aspace Group=aspace TimeoutStopSec=10 Restart=on-failure [Install] WantedBy=multi-user.target Initially I tried running it as user aspace. When that didn't work I also tried as root, but that didn't change anything. Currently I'm running archivesspace 1.5.2 on Centos 6 and the archivesspace daemon gets started from a wrapper script in init.d, so I thought that if I replicated that structure and had a wrapper script to run from the unit fil,e and set the type to either simple, or oneshot or idle, that that might do it. So I tried it like this, [Unit] Description=Archivesspace Service After=syslog.target network.target [Service] Type=simple ExecStart=/opt/archivesspace/aspace-start.sh PIDFile=/opt/archivesspace/data/.archivesspace.pid User=root Group=root [Install] WantedBy=multi-user.target But basically nothing changed -- archivesspace started fine but I still had the crazy delay. I'm thinking at this point that rather than having a unit file that calls archivesspace.sh that I need to write a unit file that replaces the functionality of archivesspace.sh and calls archivesspace directly. As you've probably noticed, archivesspace.sh is not exactly a trivial shell script, so before I get started I wanted to see if anyone else has had any luck getting archivesspace running on systemd. Thanks, Flannon From flannon at nyu.edu Fri Jan 26 17:16:26 2018 From: flannon at nyu.edu (Flannon Jackson) Date: Fri, 26 Jan 2018 17:16:26 -0500 Subject: [Archivesspace_Users_Group] Running archivesspace from systemd In-Reply-To: <CY1PR08MB1248879F76F47FA574C3EE929FE00@CY1PR08MB1248.namprd08.prod.outlook.com> References: <CAJ2fXCPVXPrRJwM=i812ouFQ70n1WsWSfP=LPAr=PoNomZRQsA@mail.gmail.com> <CY1PR08MB1248879F76F47FA574C3EE929FE00@CY1PR08MB1248.namprd08.prod.outlook.com> Message-ID: <CAJ2fXCOQSXULDCQjSo6G6Ffe84V5FJp6v-9q6qr3mcppEN1=1Q@mail.gmail.com> Hi Blake, I was able to get my issues sorted out and I've now got archivesspace 2.2.2 running on Centos 7. I've got it set up in a vagrant box if you want to have a look. If you've got virtualbox and vagrant set up on your local machine then you can get it running like this, * $ git clone git at github.com:NYULibraries/vagrant-archivesspace.git* * $ cd vagrant-archivesspace* * $ vagrant up* * $ vagrant ssh* * $ sudo systemctl start archivesspace.service* It'll install archivesspace in /opt/archviesspace, and the unit file will be at /ets/systemd/system/archivesspace.service. All the config details, usernames, passwords and such, can be found in /etc/puppetlabs/code/environments/development/data/archivesspace.yaml Once archivesspace is up and running you'll be able to connect via your browser at localhost:8080. If you've already got something running on your local machine on any of the archivesspace ports you'll need to change the port mappings in the Vagrantfile before you run `vagrant up`. -f On Fri, Jan 26, 2018 at 1:49 PM, Blake Carver <blake.carver at lyrasis.org> wrote: > Has anyone had any luck with systemd yet? > > > > ________________________________________ > From: archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of > Flannon Jackson <flannon at nyu.edu> > Sent: Monday, August 7, 2017 2:01:15 PM > To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] Running archivesspace from systemd > > Hi All, > > I'm trying to run the archivesspace daemon from a systemd unit file but > I'm getting an odd delay. If I start archivesspace manually by running "$ > sudo archivesspace.sh start" things run normally, but when I start > archivesspace from systemctl then any operation on port 8080 delays from 10 > to 20 seconds before it returns results. > > If anyone is running archivesspace from systemctl and can offer any advice > it would be appreciated. > > The details of my deployment are as follow, > > OS : Centos 7.3.10 > Java: OpenJDK 1.8.0_141 > archivesspace: 2.0.0 | 2.0.1 | 2.1.0 (i've tried all three with the same > results) > > My unit file is as follows, > > [Unit] > Description=Archivesspace Service > After=syslog.target network.target > > [Service] > Type=forking > ExecStart=/opt/archivesspace/archivesspace.sh start > PIDFile=/opt/archivesspace/data/.archivesspace.pid > User=aspace > Group=aspace > TimeoutStopSec=10 > Restart=on-failure > > [Install] > WantedBy=multi-user.target > > Initially I tried running it as user aspace. When that didn't work I also > tried as root, but that didn't change anything. > > Currently I'm running archivesspace 1.5.2 on Centos 6 and the > archivesspace daemon gets started from a wrapper script in init.d, so I > thought that if I replicated that structure and had a wrapper script to run > from the unit fil,e and set the type to either simple, or oneshot or idle, > that that might do it. So I tried it like this, > > [Unit] > Description=Archivesspace Service > After=syslog.target network.target > > [Service] > Type=simple > ExecStart=/opt/archivesspace/aspace-start.sh > PIDFile=/opt/archivesspace/data/.archivesspace.pid > User=root > Group=root > > [Install] > WantedBy=multi-user.target > > But basically nothing changed -- archivesspace started fine but I still > had the crazy delay. I'm thinking at this point that rather than having a > unit file that calls archivesspace.sh that I need to write a unit file that > replaces the functionality of archivesspace.sh and calls archivesspace > directly. As you've probably noticed, archivesspace.sh is not exactly a > trivial shell script, so before I get started I wanted to see if anyone > else has had any luck getting archivesspace running on systemd. > > Thanks, > > Flannon > _______________________________________________ > 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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180126/09fef6f2/attachment.html> From ltang5 at lib.msu.edu Sat Jan 27 11:28:57 2018 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Sat, 27 Jan 2018 16:28:57 +0000 Subject: [Archivesspace_Users_Group] data clean up of Top Container "titles" Message-ID: <AC54F06E-2A13-4059-AB13-0ADFE1B2F995@lib.msu.edu> Good morning, all! I am trying to clean up some of our data goofiness. As you can see in the attached screen shot, I have a ?Box 56: Series Series 1; Series Series 2.? Opening the Top Container itself in edit mode only allows me to potentially change the container type (box) and number, but I can?t figure out how to kill off these series listings! After digging around, I realized that the earlier processor that put Series 1 and Series 2 labels in the Component Unique Identifier (CUI) field for their respective series, which aligns with the tool tip suggestions, but is part of this problem. It seems like the program automatically adds the extra ?series? label, even if the tooltip seems to suggest flexibility about whether it indicates a series, subseries, or accession. It also seems like this label is inherited to nested Top Containers under this series, so even if the actual records that are linked to this Top Container may have blank CUIs, but it actually inherits this information from wherever it?s nested. Weirdly, for some of the most recent data entry, the Top Container has ?Series Series 1? AND ?Series Series 2? even though the record is only nested under the existing Series 2. To remove these labels, I have to remove the CUI for each series. At any rate, this is strange and obviously doesn?t seem to be working as intended. My sample finding aid is in http://test.archivesspace.org/ Gerber papers, if anyone wants to check. I confirmed this behavior still persists in the latest release candidate, at least for my collection. Anyone else notice this issue? Thanks! Lydia -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-01-26 at 8.54.05 AM.png Type: image/png Size: 97232 bytes Desc: Screen Shot 2018-01-26 at 8.54.05 AM.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180127/a80dab56/attachment.png> From ccauste1 at swarthmore.edu Sat Jan 27 12:31:49 2018 From: ccauste1 at swarthmore.edu (Celia Caust-Ellenbogen) Date: Sat, 27 Jan 2018 12:31:49 -0500 Subject: [Archivesspace_Users_Group] Do you agree it's important to be able to customize URLs/create PURLs in the PUI? Message-ID: <CAFvko3tnTxA=2XVy25LpjE29Vcu+ripLZfaQWbe4GbEQeGBGnQ@mail.gmail.com> Hi everyone, As part of migrating to the ArchivesSpace public interface, we have to update a lot of links to old EAD finding aids. This has me thinking about the persistence of URLs and not only the trouble of updating old links but what will happen when (hopefully never!) we move out of ArchivesSpace. That the URLs in the public interface are arbitrary poses a problem. My sysadmin tells me that if we were able to customize some portion of the URL, it would be possible to create a URL redirect map. In the absence of that, she doesn't want to create a million (or, more precisely, about 4,000) individual redirects. If we could customize some portion of the URL, that would let us set up redirects from the old system, and it would also position us to anticipate being able to set up redirects going into a new system and therefore have somewhat persistent URLs. That's my understanding, at least. I don't have a firm grasp of these issues so I might be making false assumptions. I'm wondering if other folks have been thinking about this issue. How are you approaching the problem? Do you have a strategy for this? Can anyone with a better understanding of ASpace's code and/or development priorities speculate on the likelihood that the option to customize the URL for the public interface might be added to a future release? AR-1558 <https://archivesspace.atlassian.net/browse/AR-1558> seems the most relevant ticket, and it's pretty old (v.1.4.2). If other people agree this is important, would you please upvote it, and hopefully increase the chances it'll get on the development roadmap? Thanks! Celia -- Celia Caust-Ellenbogen Friends Historical Library of Swarthmore College <http://swarthmore.edu/friends-historical-library> 610-328-8496 ccauste1 at swarthmore.edu she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180127/701843b3/attachment.html> From mark.custer at yale.edu Sat Jan 27 14:44:47 2018 From: mark.custer at yale.edu (Custer, Mark) Date: Sat, 27 Jan 2018 19:44:47 +0000 Subject: [Archivesspace_Users_Group] data clean up of Top Container "titles" In-Reply-To: <AC54F06E-2A13-4059-AB13-0ADFE1B2F995@lib.msu.edu> References: <AC54F06E-2A13-4059-AB13-0ADFE1B2F995@lib.msu.edu> Message-ID: <BN3PR08MB1303DA2ECD00D722942C58118CE70@BN3PR08MB1303.namprd08.prod.outlook.com> Lydia, See the very last section, Identifier Encoding, at the bottom of this page: https://guides.library.yale.edu/archivesspace/ASpaceContainerManagement This is documentation from the original top container plugin, but the same holds true now in the core code. Things will look much looker cleaner in the staff interface after that, as seen in the attached image, which shows the first 11 boxes in that collection. I hope that helps, Mark p.s. I'd say that the tooltips should be updated in the core code, as well. -----Original Message----- From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Saturday, 27 January, 2018 11:29 AM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] data clean up of Top Container "titles" Good morning, all! I am trying to clean up some of our data goofiness. As you can see in the attached screen shot, I have a ?Box 56: Series Series 1; Series Series 2.? Opening the Top Container itself in edit mode only allows me to potentially change the container type (box) and number, but I can?t figure out how to kill off these series listings! After digging around, I realized that the earlier processor that put Series 1 and Series 2 labels in the Component Unique Identifier (CUI) field for their respective series, which aligns with the tool tip suggestions, but is part of this problem. It seems like the program automatically adds the extra ?series? label, even if the tooltip seems to suggest flexibility about whether it indicates a series, subseries, or accession. It also seems like this label is inherited to nested Top Containers under this series, so even if the actual records that are linked to this Top Container may have blank CUIs, but it actually inherits this information from wherever it?s nested. Weirdly, for some of the most recent data entry, the Top Container has ?Series Series 1? AND ?Series Series 2? even though the record is only nested under the existing Series 2. To remove these labels, I have to remove the CUI for each series. At any rate, this is strange and obviously doesn?t seem to be working as intended. My sample finding aid is in https://urldefense.proofpoint.com/v2/url?u=http-3A__test.archivesspace.org_&d=DwIGaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=UCFvXxOgNsnpX1yK3bZYd3xVgh9CVlx6s0llS8v23Uk&s=-2dad9vFRw6d0YNK_VQSTnW1oQMAxi2nZFQagvlApK4&e= Gerber papers, if anyone wants to check. I confirmed this behavior still persists in the latest release candidate, at least for my collection. Anyone else notice this issue? Thanks! Lydia -------------- next part -------------- A non-text attachment was scrubbed... Name: gerber-first-11-boxes.png Type: image/png Size: 42420 bytes Desc: gerber-first-11-boxes.png URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180127/f91d286b/attachment.png> From mark.custer at yale.edu Sat Jan 27 15:11:00 2018 From: mark.custer at yale.edu (Custer, Mark) Date: Sat, 27 Jan 2018 20:11:00 +0000 Subject: [Archivesspace_Users_Group] Do you agree it's important to be able to customize URLs/create PURLs in the PUI? In-Reply-To: <CAFvko3tnTxA=2XVy25LpjE29Vcu+ripLZfaQWbe4GbEQeGBGnQ@mail.gmail.com> References: <CAFvko3tnTxA=2XVy25LpjE29Vcu+ripLZfaQWbe4GbEQeGBGnQ@mail.gmail.com> Message-ID: <BN3PR08MB1303D075311F138FE5D3770A8CE70@BN3PR08MB1303.namprd08.prod.outlook.com> Celia, I wish that this could?ve been accomplished with the initial release of the PUI, but there were a number of issues that didn?t allow that to happen (and I?m not sure of all of the technical issues, to be quite honest). However, at Yale, we will be setting up re-directs from our current system, which uses the data that we include in ASpace?s EAD ID field as part of the permanent link, to the ArchivesSpace PUI. For example, we?re using a simple table that maps our EAD IDs to our ArchivesSpace Resource database IDs. So, I would still recommend pursuing that option since you can only update the links on your own website, and not links elsewhere, user?s bookmarks, etc. But I agree with Cory and you that this should, ideally, use a value that?s not an ArchivesSpace value (like a database ID), but instead a value that will live on after ArchivesSpace. That?s what Cool URIs are all about, after all: https://www.w3.org/TR/cooluris/ My preference would be to use what?s currently labelled the EAD ID field in ASpace, in combination with the Repository short name. The reason: the EAD ID (or recordid in EAD3) is a requirement in the EAD schemas (although, yes, it can be empty in those schemas, technically ?). And fortunately ArchivesSpace already ensures that those values are unique in the database. However, ArchivesSpace does not require that field. ArchivesSpace does require the Identifier field, but that maps to a field in EAD (archdesc/did/unitid) which is *not* required in the EAD schemas. I also would not favor using that field for a URI due to the weirdness of how that field is parsed into 4 fields total (id0 ? id3) in ArchivesSpace. All that said, one reason why I imagine that ArchivesSpace does not require the EAD ID field is that it wants to be flexible enough to allow users to use the Resource records for anything -- even, say, a piece of papyri, which should not have an EAD ID. But there?s no reason that ArchivesSpace couldn?t take a tip from EAD3 and just re-imagine that field as a Record ID field instead. That way, you?ve got an identifier (the record ID) that pertains to the record, which you could use as part of the URI (as long as it was made mandatory in ASpace), as well as an identifier that pertains to the material being described (e.g. a call number). All my best , Mark p.s. I?m one of the 4 people (currently ) who have already voted for this ticket. I?d vote again if I could, since I really do think that Cool URIs are important. From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Celia Caust-Ellenbogen Sent: Saturday, 27 January, 2018 12:32 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Do you agree it's important to be able to customize URLs/create PURLs in the PUI? Hi everyone, As part of migrating to the ArchivesSpace public interface, we have to update a lot of links to old EAD finding aids. This has me thinking about the persistence of URLs and not only the trouble of updating old links but what will happen when (hopefully never!) we move out of ArchivesSpace. That the URLs in the public interface are arbitrary poses a problem. My sysadmin tells me that if we were able to customize some portion of the URL, it would be possible to create a URL redirect map. In the absence of that, she doesn't want to create a million (or, more precisely, about 4,000) individual redirects. If we could customize some portion of the URL, that would let us set up redirects from the old system, and it would also position us to anticipate being able to set up redirects going into a new system and therefore have somewhat persistent URLs. That's my understanding, at least. I don't have a firm grasp of these issues so I might be making false assumptions. I'm wondering if other folks have been thinking about this issue. How are you approaching the problem? Do you have a strategy for this? Can anyone with a better understanding of ASpace's code and/or development priorities speculate on the likelihood that the option to customize the URL for the public interface might be added to a future release? AR-1558<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1558&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=-TroesUwSJgDpj8nwiZaURNx7lT3loiWGu3LQcass9U&s=BASqaraHnwFq1U7hS8HnMtHQKQFJLdh8eHiFVLznZqs&e=> seems the most relevant ticket, and it's pretty old (v.1.4.2). If other people agree this is important, would you please upvote it, and hopefully increase the chances it'll get on the development roadmap? Thanks! Celia -- Celia Caust-Ellenbogen Friends Historical Library of Swarthmore College<https://urldefense.proofpoint.com/v2/url?u=http-3A__swarthmore.edu_friends-2Dhistorical-2Dlibrary&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=-TroesUwSJgDpj8nwiZaURNx7lT3loiWGu3LQcass9U&s=p00oDbiV7Q47LGIKqsh76wZP_Vo0i8JS-YLkabbk4kc&e=> 610-328-8496 ccauste1 at swarthmore.edu<mailto:ccauste1 at swarthmore.edu> she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180127/29748ab9/attachment.html> From ltang5 at lib.msu.edu Mon Jan 29 09:50:20 2018 From: ltang5 at lib.msu.edu (Tang, Lydia) Date: Mon, 29 Jan 2018 14:50:20 +0000 Subject: [Archivesspace_Users_Group] seeking input on copying/linking data Message-ID: <2DE3B341-F12E-4E3F-B8C9-D646EB24E6FF@lib.msu.edu> Thanks, Mark, for responding to my earlier question! I?m looking forward to investigating this further. Also, I created a ticket in response to the list discussions earlier this month about copying/linking data, especially for situations such as the Biog-Hist note for Agents into Resources, etc. It would be great if people interested in this topic could chime in on what this functionality would look like and accomplish! https://archivesspace.atlassian.net/browse/ANW-309 Thanks! Lydia From amadkins at cpp.edu Mon Jan 29 12:58:42 2018 From: amadkins at cpp.edu (Alexis Adkins) Date: Mon, 29 Jan 2018 17:58:42 +0000 Subject: [Archivesspace_Users_Group] Repository phone number not exporting in EAD Message-ID: <MW2PR0102MB3356C5EE70120F40CF9AFC3DD5E50@MW2PR0102MB3356.prod.exchangelabs.com> Hello, I've tried adding our repository phone number to the repository profile (?) both in the optional Telephone Number field and in the Contact Notes field under the E-mail field, but in neither case will the phone number be included in the EAD as an <addressline> tag. I can add the tag in an EAD editor before uploading it to the Online Archive of California, but would prefer not to. Here's a screenshot of what I've tried for reference. [cid:image001.jpg at 01D398E3.0AE711B0] Any advice? Thanks in advance, Alexis Alexis Adkins Archivist Special Collections and Archives University Library California State Polytechnic University, Pomona amadkins at cpp.edu<mailto:amadkins at cpp.edu> 909-869-3092 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180129/00b05255/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 11413 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180129/00b05255/attachment.jpg> From ccauste1 at swarthmore.edu Mon Jan 29 12:59:03 2018 From: ccauste1 at swarthmore.edu (Celia Caust-Ellenbogen) Date: Mon, 29 Jan 2018 12:59:03 -0500 Subject: [Archivesspace_Users_Group] Do you agree it's important to be able to customize URLs/create PURLs in the PUI? In-Reply-To: <BN3PR08MB1303D075311F138FE5D3770A8CE70@BN3PR08MB1303.namprd08.prod.outlook.com> References: <CAFvko3tnTxA=2XVy25LpjE29Vcu+ripLZfaQWbe4GbEQeGBGnQ@mail.gmail.com> <BN3PR08MB1303D075311F138FE5D3770A8CE70@BN3PR08MB1303.namprd08.prod.outlook.com> Message-ID: <CAFvko3sn_TsJahv1jcogsPK65KyvwR+0ZZjLVRUY2CKAkzLpMQ@mail.gmail.com> Hello again, Christine commented on the original ticket that to move forward there needs to be a specification for how this would function. If anyone wants to work on this with me, let me know! Celia On Sat, Jan 27, 2018 at 3:11 PM, Custer, Mark <mark.custer at yale.edu> wrote: > Celia, > > > > I wish that this could?ve been accomplished with the initial release of > the PUI, but there were a number of issues that didn?t allow that to happen > (and I?m not sure of all of the technical issues, to be quite honest). > > > > However, at Yale, we will be setting up re-directs from our current > system, which uses the data that we include in ASpace?s EAD ID field as > part of the permanent link, to the ArchivesSpace PUI. For example, we?re > using a simple table that maps our EAD IDs to our ArchivesSpace Resource > database IDs. So, I would still recommend pursuing that option since you > can only update the links on your own website, and not links elsewhere, > user?s bookmarks, etc. > > > > But I agree with Cory and you that this should, ideally, use a value > that?s not an ArchivesSpace value (like a database ID), but instead a value > that will live on after ArchivesSpace. That?s what Cool URIs are all > about, after all: https://www.w3.org/TR/cooluris/ > > > > My preference would be to use what?s currently labelled the EAD ID field > in ASpace, in combination with the Repository short name. The reason: the > EAD ID (or recordid in EAD3) is a requirement in the EAD schemas (although, > yes, it can be empty in those schemas, technically ?). And fortunately > ArchivesSpace already ensures that those values are unique in the > database. However, ArchivesSpace does not require that field. > ArchivesSpace does require the Identifier field, but that maps to a field > in EAD (archdesc/did/unitid) which is **not** required in the EAD > schemas. I also would not favor using that field for a URI due to the > weirdness of how that field is parsed into 4 fields total (id0 ? id3) in > ArchivesSpace. All that said, one reason why I imagine that ArchivesSpace > does not require the EAD ID field is that it wants to be flexible enough to > allow users to use the Resource records for anything -- even, say, a piece > of papyri, which should not have an EAD ID. But there?s no reason that > ArchivesSpace couldn?t take a tip from EAD3 and just re-imagine that field > as a Record ID field instead. That way, you?ve got an identifier (the > record ID) that pertains to the record, which you could use as part of the > URI (as long as it was made mandatory in ASpace), as well as an identifier > that pertains to the material being described (e.g. a call number). > > > > All my best , > > > > Mark > > > > p.s. I?m one of the 4 people (currently ) who have already voted for this > ticket. I?d vote again if I could, since I really do think that Cool URIs > are important. > > > > > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Celia > Caust-Ellenbogen > *Sent:* Saturday, 27 January, 2018 12:32 PM > *To:* Archivesspace Users Group <archivesspace_users_group@ > lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] Do you agree it's important to be > able to customize URLs/create PURLs in the PUI? > > > > Hi everyone, > > > > As part of migrating to the ArchivesSpace public interface, we have to > update a lot of links to old EAD finding aids. This has me thinking about > the persistence of URLs and not only the trouble of updating old links but > what will happen when (hopefully never!) we move out of ArchivesSpace. That > the URLs in the public interface are arbitrary poses a problem. My sysadmin > tells me that if we were able to customize some portion of the URL, it > would be possible to create a URL redirect map. In the absence of that, she > doesn't want to create a million (or, more precisely, about 4,000) > individual redirects. If we could customize some portion of the URL, that > would let us set up redirects from the old system, and it would also > position us to anticipate being able to set up redirects going into a new > system and therefore have somewhat persistent URLs. > > > > That's my understanding, at least. I don't have a firm grasp of these > issues so I might be making false assumptions. > > > > I'm wondering if other folks have been thinking about this issue. How are > you approaching the problem? Do you have a strategy for this? Can anyone > with a better understanding of ASpace's code and/or development priorities > speculate on the likelihood that the option to customize the URL for the > public interface might be added to a future release? > > > > AR-1558 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1558&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=-TroesUwSJgDpj8nwiZaURNx7lT3loiWGu3LQcass9U&s=BASqaraHnwFq1U7hS8HnMtHQKQFJLdh8eHiFVLznZqs&e=> > seems the most relevant ticket, and it's pretty old (v.1.4.2). If other > people agree this is important, would you please upvote it, and hopefully > increase the chances it'll get on the development roadmap? > > > > Thanks! > Celia > > > > -- > > Celia Caust-Ellenbogen > > Friends Historical Library of Swarthmore College > <https://urldefense.proofpoint.com/v2/url?u=http-3A__swarthmore.edu_friends-2Dhistorical-2Dlibrary&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=-TroesUwSJgDpj8nwiZaURNx7lT3loiWGu3LQcass9U&s=p00oDbiV7Q47LGIKqsh76wZP_Vo0i8JS-YLkabbk4kc&e=> > > 610-328-8496 <(610)%20328-8496> > > ccauste1 at swarthmore.edu > > she/her/hers > > > > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > -- Celia Caust-Ellenbogen Friends Historical Library of Swarthmore College <http://swarthmore.edu/friends-historical-library> 610-328-8496 ccauste1 at swarthmore.edu she/her/hers -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180129/f868c213/attachment.html> From mabace at ua.edu Mon Jan 29 15:52:09 2018 From: mabace at ua.edu (Bace, Martha) Date: Mon, 29 Jan 2018 20:52:09 +0000 Subject: [Archivesspace_Users_Group] SAA 2018 C.F.W. Coker Award nominations Message-ID: <9aeb8977986648259a3172a434791010@ua.edu> Please excuse any cross-posting! Martha A. Bace Processing Archivist, Special Collections University Libraries The University of Alabama<https://www.ua.edu/> 203 Mary Harmon Bryant Hall Box 870266 Tuscaloosa, AL 35487 Office 205-348-6388<tel:205-348-6388> | Fax 205-348-1699<tel:205-348-1699> mabace at ua.edu<mailto:mabace at ua.edu> | http://www.lib.ua.edu/ [The University of Alabama]<https://www.ua.edu/> Call for Nominations - 2018 C.F.W. Coker Award Greetings colleagues! It is that time of the year where we ask for your to help us identify archivists and groups of archivists who have made valuable contributions to our profession! As a part of these efforts, we are looking for nominations for the C.F.W. Coker Award, which is awarded annually to an individual or group who have performed outstanding and innovative archival descriptive work. This descriptive work can take many forms, including: 1. Finding aids, including, among others, multi-institutional guides, record surveys, repository guides, special subject lists, finding aids to individual collections or records groups, and narrative descriptions of holdings. 2. Finding aid systems, including, among others, manual or automatic indexing systems, computer databases, or current awareness systems for notifying users of holdings. 3. Descriptive tools that enable archivists to produce more effective finding aids, including, among others, subject thesauri, authority files, data element dictionaries, manuals establishing descriptive standards, and such reference works as atlases and administrative histories. 4. Projects that involve innovative developments in archival description, including, among others, cooperative ventures that result in the exchange of finding aid information among repositories, efforts at building national information systems, and survey projects. If you are aware of innovative work in any of these areas we ask that you please consider submitting a nomination (self-nominations are welcome!) via our nomination form<https://app.smarterselect.com/programs/45800-Society-Of-American-Archivists>: by February 28, 2018. For more information about the C.F.W. Coker Award please visit: https://www2.archivists.org/governance/handbook/section12-coker. Thank you everyone for your consideration and time. The C.F.W. Coker Award Subcommittee: Rebecca Hirsch (chair) Martha Bace Shannon Lausch Linda Sellars -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180129/27b8b313/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 6052 bytes Desc: image001.gif URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180129/27b8b313/attachment.gif> From jteitelbaum at pabmc.net Mon Jan 29 15:54:39 2018 From: jteitelbaum at pabmc.net (Teitelbaum, Jesse) Date: Mon, 29 Jan 2018 15:54:39 -0500 Subject: [Archivesspace_Users_Group] spell check Message-ID: <C6AAE365E91EEC43876ABA64C804C6E4214486EBBB@bmcmail2.PABMC.NET> Maybe a basic question? Is there a way to spell check a finding aid prior to creating a pdf? Jesse Teitelbaum | Associate Archivist Pennsylvania House of Representatives | Archives 469 Forum Building | Harrisburg PA 17120 Phone: 717.783.3866 | Fax: 717.772.1233 Email: jteitelbaum at pabmc.net<mailto:jteitelbaum at pabmc.net> www.house.state.pa.us/BMC/archives<http://www.house.state.pa.us/BMC/archives> [cid:image001.jpg at 01D39919.78335AE0]<https://www.facebook.com/Pennsylvania-House-of-Representatives-Archives-2681280988549449/?fref=nf> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180129/6b8ae05e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1067 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180129/6b8ae05e/attachment.jpg> From sdm7g at virginia.edu Mon Jan 29 23:25:24 2018 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 30 Jan 2018 04:25:24 +0000 Subject: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 In-Reply-To: <c8e3e306a42a4bc08227c241b677fa6d@ship.edu> References: <1cd6941edab84b1d9c97ac7527543366@ship.edu> <BN6PR07MB3492B4BA65ACAB6FED8BD8DF900D0@BN6PR07MB3492.namprd07.prod.outlook.com> <207241878cdb49c385b9351d3735c3f1@ship.edu> <FDFEB843-68A5-4CD2-B29B-EA5C65C56A78@virginia.edu> <c8e3e306a42a4bc08227c241b677fa6d@ship.edu> Message-ID: <D16C02C6-C2E8-478A-9CF5-DF2477ACAFE8@virginia.edu> I had a need to look into this issue of overriding existing routes or controllers again. I was trying to make repositories#index be the default landing page instead of welcome#show . Adding this to plugins/local/public/routes.rb and loading those routes from plugin_init.rb appended the new route to the end of the routes. This was visible when I ran ?rake routes? on the public rails app. However routing takes the first match from the route table, so the default ?welcome at show? was what was run. I haven?t yet figured out if there is any way to add a new route to the start of the routes table rather than at the end. I unsuccessfully tried several different methods of overriding welcome#show. During that process, I also stuck in a binding.pry breakpoint in plugins/local/public/plugin_init.rb and verified that ApplicationController is not in scope. In fact, I suspect that since it is being loaded as an initializer, the controllers may not have been loaded and defined at that point. What finally worked for me was: plugins/local/public/controllers/my_controller.rb: class WelcomeController def show redirect_to :controller => 'repositories' , :action => 'index' end end This did successfully override welcome#show so that going to http://localhost:3001/ <http://localhost:3001/> redirects to http://localhost:3001/repositories <http://localhost:3001/repositories> and show the list of repositories. ( In this case, I?ve also overridden views/repositories/index.html.erb in the the plugin so that it also includes the search form above the repository list. ) What I don?t completely understand is that if the same file is named plugins/local/public/controllers/welcome_controller.rb, it does not seem to work. Other arbitrary names, like ?x_controller.rb? for example, do work. Just not ?welcome_controller.rb? . It would appear that the existing application welcome controller may keep this file from loading. I just added a binding.pry breakpoint and renamed that file and verified that it never executes when named ?welcome_controller.rb? . So you might try something similar. Routes or plugin_init are probably not required if you?re just extending existing controller. Add a file to the plugin controller directory that redefines resource controller, but give it a name that doesn?t duplicate any existing controller file. If you try to inherit from and extend an existing controller, you may be able to add a new route pointing to it, but I don?t know a way to change the existing route to point to a the new class. Let us know if you find something that works! ? Steve Majewski > On Dec 22, 2017, at 3:07 PM, Flanagan, Patrick <PJFlanagan at ship.edu> wrote: > > I think I just encountered that sort of issue. From public/plugin_init.rb both ResourcesController and ApplicationController don't appear to be in scope; so I can't even replace it let alone extend it. That, or I'm supposed to use require to get at the specific classes - but I haven't been able to do so. I think it's one of the intricacies of Rails that is escaping me. > > Ideally, for an identifier of A/B/C/D on a given resource, I wanted the breadcrumb to link back to A - B - C - D - This Resource, a behavior that's more similar to Archon, and more useful than the default behavior of simply linking to the repository top itself, I think. > > ~Patrick Flanagan > KLN Applications Administrator > Keystone Library Network Hub > From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu> > Sent: Thursday, December 21, 2017 4:40:29 PM > To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 > > > I remember running into something like this where the problem was Rails lazy loading of classes. > The base classes were not actually defined when the plugins were loaded, so what was supposed to be additional methods extending an existing class became the entire replacement class definition. I had to add a reference to the class to force lazy loading before trying to extend the class. > This might be what you are running into. > I will look and see if I still have any notes with more details from that experiment. > > ? Steve. > > > > >> On Dec 21, 2017, at 4:18 PM, Flanagan, Patrick <PJFlanagan at ship.edu <mailto:PJFlanagan at ship.edu>> wrote: >> >> Hi Bobbi, >> >> Thank you for this! I'll give it a try this way and see if I can make some progress. >> >> ~Patrick Flanagan >> KLN Applications Administrator >> Keystone Library Network Hub >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Fox, Bobbi <bobbi_fox at harvard.edu <mailto:bobbi_fox at harvard.edu>> >> Sent: Thursday, December 21, 2017 3:47:18 PM >> To: Archivesspace Users Group >> Subject: Re: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 >> >> Hi, Patrick, >> >> I?m having to do a lot of extending/overriding of controllers & methods in our new public interface. >> >> You are correct; you can?t just override by placing your modified controller in the path location; instead, what *I?m* doing (and I know there?s a more elegant way of doing it); is put the changes in the plugin/plugin_init.rb ,using the [class|module]_eval method on something. >> >> For instance, I?m changing what gets faceted in the Searchable concern this way in plugin_init.rb: >> Searchable.module_eval do >> def set_up_and_run_search(default_types = [],default_facets=[],default_search_opts={}, params={}) >> ~ my stuff here ~~ >> end >> end >> >> >> I?m adding methods to controllers in a somewhat similar way, for instance, in plugin_init.rb, I?ve got: >> >> # add a digital only action to the resources controller >> class ResourcesController >> def digital_only >> uri = "/repositories/#{params[:rid]}/resources/#{params[:id]}" >> begin >> ~ etc. ~ >> end >> end >> >> Hope this helps, >> Bobbi >> >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Flanagan, Patrick >> Sent: Thursday, December 21, 2017 3:27 PM >> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>> >> Subject: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 >> >> Hello, >> >> I'm attempting to write a plugin that will modify the way the breadcrumb trail (shown in the new public UI) is generated to include more detail. I decided to try and override one of the files in the controller part of the architecture: resources_controller.rb, since I can see the :crumb being defined there. However, either my path is wrong, or the new UI isn't utilizing it. Following the instructions here:http://archivesspace.github.io/archivesspace/user/archivesspace-plug-ins-readme/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_archivesspace-2Dplug-2Dins-2Dreadme_&d=DwMFAw&c=WO-RGvefibhHBZq3fL85hQ&r=5xWUzLrZrVLeTqs3CDoeRpPtLv1fRM04CCu4TDULrSY&m=3DmZ4KyjSuOHTC-7rfq8Dv2MTeEFEBci91sKzca-4YQ&s=is5OAKKChee55MtdTuQYDj2OwuvI8f0Y6lBLS8-ast8&e=> I've placed the file in the following directory: >> >> as220/plugins/local/public/controllers/resources_controller.rb >> ( source location: /public/app/controllers/resources_controller.rb ) >> Plugin Config: AppConfig[:plugins] = ['local', 'lcnaf', 'aspace-public-formats'] >> >> >> If I'm not mistaken that document indicates that this is something that can be overridden, but I'm suspecting I can't actually override something in the controller from a plugin. >> >> The version is 2.2.0, running on Linux x64, openjdk version "1.8.0_151". Any advice would be appreciated! >> >> Thank you, >> >> ~Patrick Flanagan >> KLN Applications Administrator >> Keystone Library Network Hub >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180130/2458ec87/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4943 bytes Desc: not available URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180130/2458ec87/attachment.bin> From timmo at jhu.edu Mon Jan 29 23:51:05 2018 From: timmo at jhu.edu (Timothy Dilauro) Date: Tue, 30 Jan 2018 04:51:05 +0000 Subject: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 In-Reply-To: <D16C02C6-C2E8-478A-9CF5-DF2477ACAFE8@virginia.edu> References: <1cd6941edab84b1d9c97ac7527543366@ship.edu> <BN6PR07MB3492B4BA65ACAB6FED8BD8DF900D0@BN6PR07MB3492.namprd07.prod.outlook.com> <207241878cdb49c385b9351d3735c3f1@ship.edu> <FDFEB843-68A5-4CD2-B29B-EA5C65C56A78@virginia.edu> <c8e3e306a42a4bc08227c241b677fa6d@ship.edu> <D16C02C6-C2E8-478A-9CF5-DF2477ACAFE8@virginia.edu> Message-ID: <5D278454-71F9-4617-BFA3-8B66863D335A@jhu.edu> You can control the timing of the loading of your extensions by placing them in an "config.after_initialize" block in plugin_init.rb. For the 1.5.4 PUI, I used the following block: ArchivesSpacePublic::Application.config.after_initialize do end In addition, you can ensure that each needed module/class is loaded by mentioning it before you attempt to extend it: RecordsController class RecordsController ... end See https://github.com/jhu-archives-and-manuscripts/aspace_plugin-jhu_public/blob/master/public/plugin_init.rb <https://github.com/jhu-archives-and-manuscripts/aspace_plugin-jhu_public/blob/master/public/plugin_init.rb> Cheers, ~Tim > On Jan 29, 2018, at 11:25 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu> wrote: > > > I had a need to look into this issue of overriding existing routes or controllers again. > I was trying to make repositories#index be the default landing page instead of welcome#show . > > Adding this to plugins/local/public/routes.rb and loading those routes from plugin_init.rb appended the new route to the end of the routes. This was visible when I ran ?rake routes? on the public rails app. However routing takes the first match from the route table, so the default ?welcome at show? was what was run. > > I haven?t yet figured out if there is any way to add a new route to the start of the routes table rather than at the end. > > I unsuccessfully tried several different methods of overriding welcome#show. > During that process, I also stuck in a binding.pry breakpoint in plugins/local/public/plugin_init.rb and verified that ApplicationController is not in scope. In fact, I suspect that since it is being loaded as an initializer, the controllers may not have been loaded and defined at that point. > > What finally worked for me was: > > plugins/local/public/controllers/my_controller.rb: > > class WelcomeController > def show > redirect_to :controller => 'repositories' , :action => 'index' > end > end > > > This did successfully override welcome#show so that going to http://localhost:3001/ <http://localhost:3001/> redirects to http://localhost:3001/repositories <http://localhost:3001/repositories> and show the list of repositories. > > ( In this case, I?ve also overridden views/repositories/index.html.erb in the the plugin so that it also includes the search form above the repository list. ) > > > What I don?t completely understand is that if the same file is named plugins/local/public/controllers/welcome_controller.rb, it does not seem to work. Other arbitrary names, like ?x_controller.rb? for example, do work. Just not ?welcome_controller.rb? . It would appear that the existing application welcome controller may keep this file from loading. I just added a binding.pry breakpoint and renamed that file and verified that it never executes when named ?welcome_controller.rb? . > > > So you might try something similar. Routes or plugin_init are probably not required if you?re just extending existing controller. > Add a file to the plugin controller directory that redefines resource controller, but give it a name that doesn?t duplicate any existing controller file. > > If you try to inherit from and extend an existing controller, you may be able to add a new route pointing to it, but I don?t know a way to change the existing route to point to a the new class. > > Let us know if you find something that works! > > > ? Steve Majewski > > > > >> On Dec 22, 2017, at 3:07 PM, Flanagan, Patrick <PJFlanagan at ship.edu <mailto:PJFlanagan at ship.edu>> wrote: >> >> I think I just encountered that sort of issue. From public/plugin_init.rb both ResourcesController and ApplicationController don't appear to be in scope; so I can't even replace it let alone extend it. That, or I'm supposed to use require to get at the specific classes - but I haven't been able to do so. I think it's one of the intricacies of Rails that is escaping me. >> >> Ideally, for an identifier of A/B/C/D on a given resource, I wanted the breadcrumb to link back to A - B - C - D - This Resource, a behavior that's more similar to Archon, and more useful than the default behavior of simply linking to the repository top itself, I think. >> >> ~Patrick Flanagan >> KLN Applications Administrator >> Keystone Library Network Hub >> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu <mailto:sdm7g at virginia.edu>> >> Sent: Thursday, December 21, 2017 4:40:29 PM >> To: Archivesspace Users Group >> Subject: Re: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 >> >> >> I remember running into something like this where the problem was Rails lazy loading of classes. >> The base classes were not actually defined when the plugins were loaded, so what was supposed to be additional methods extending an existing class became the entire replacement class definition. I had to add a reference to the class to force lazy loading before trying to extend the class. >> This might be what you are running into. >> I will look and see if I still have any notes with more details from that experiment. >> >> ? Steve. >> >> >> >> >>> On Dec 21, 2017, at 4:18 PM, Flanagan, Patrick <PJFlanagan at ship.edu <mailto:PJFlanagan at ship.edu>> wrote: >>> >>> Hi Bobbi, >>> >>> Thank you for this! I'll give it a try this way and see if I can make some progress. >>> >>> ~Patrick Flanagan >>> KLN Applications Administrator >>> Keystone Library Network Hub >>> >>> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Fox, Bobbi <bobbi_fox at harvard.edu <mailto:bobbi_fox at harvard.edu>> >>> Sent: Thursday, December 21, 2017 3:47:18 PM >>> To: Archivesspace Users Group >>> Subject: Re: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 >>> >>> Hi, Patrick, >>> >>> I?m having to do a lot of extending/overriding of controllers & methods in our new public interface. >>> >>> You are correct; you can?t just override by placing your modified controller in the path location; instead, what *I?m* doing (and I know there?s a more elegant way of doing it); is put the changes in the plugin/plugin_init.rb ,using the [class|module]_eval method on something. >>> >>> For instance, I?m changing what gets faceted in the Searchable concern this way in plugin_init.rb: >>> Searchable.module_eval do >>> def set_up_and_run_search(default_types = [],default_facets=[],default_search_opts={}, params={}) >>> ~ my stuff here ~~ >>> end >>> end >>> >>> >>> I?m adding methods to controllers in a somewhat similar way, for instance, in plugin_init.rb, I?ve got: >>> >>> # add a digital only action to the resources controller >>> class ResourcesController >>> def digital_only >>> uri = "/repositories/#{params[:rid]}/resources/#{params[:id]}" >>> begin >>> ~ etc. ~ >>> end >>> end >>> >>> Hope this helps, >>> Bobbi >>> >>> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Flanagan, Patrick >>> Sent: Thursday, December 21, 2017 3:27 PM >>> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>> >>> Subject: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 >>> >>> Hello, >>> >>> I'm attempting to write a plugin that will modify the way the breadcrumb trail (shown in the new public UI) is generated to include more detail. I decided to try and override one of the files in the controller part of the architecture: resources_controller.rb, since I can see the :crumb being defined there. However, either my path is wrong, or the new UI isn't utilizing it. Following the instructions here:http://archivesspace.github.io/archivesspace/user/archivesspace-plug-ins-readme/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_archivesspace-2Dplug-2Dins-2Dreadme_&d=DwMFAw&c=WO-RGvefibhHBZq3fL85hQ&r=5xWUzLrZrVLeTqs3CDoeRpPtLv1fRM04CCu4TDULrSY&m=3DmZ4KyjSuOHTC-7rfq8Dv2MTeEFEBci91sKzca-4YQ&s=is5OAKKChee55MtdTuQYDj2OwuvI8f0Y6lBLS8-ast8&e=> I've placed the file in the following directory: >>> >>> as220/plugins/local/public/controllers/resources_controller.rb >>> ( source location: /public/app/controllers/resources_controller.rb ) >>> Plugin Config: AppConfig[:plugins] = ['local', 'lcnaf', 'aspace-public-formats'] >>> >>> >>> If I'm not mistaken that document indicates that this is something that can be overridden, but I'm suspecting I can't actually override something in the controller from a plugin. >>> >>> The version is 2.2.0, running on Linux x64, openjdk version "1.8.0_151". Any advice would be appreciated! >>> >>> Thank you, >>> >>> ~Patrick Flanagan >>> KLN Applications Administrator >>> Keystone Library Network Hub >>> _______________________________________________ >>> Archivesspace_Users_Group mailing list >>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <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: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180130/1e2a920b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180130/1e2a920b/attachment.sig> From bobbi_fox at harvard.edu Tue Jan 30 09:24:26 2018 From: bobbi_fox at harvard.edu (Fox, Bobbi) Date: Tue, 30 Jan 2018 14:24:26 +0000 Subject: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 In-Reply-To: <5D278454-71F9-4617-BFA3-8B66863D335A@jhu.edu> References: <1cd6941edab84b1d9c97ac7527543366@ship.edu> <BN6PR07MB3492B4BA65ACAB6FED8BD8DF900D0@BN6PR07MB3492.namprd07.prod.outlook.com> <207241878cdb49c385b9351d3735c3f1@ship.edu> <FDFEB843-68A5-4CD2-B29B-EA5C65C56A78@virginia.edu> <c8e3e306a42a4bc08227c241b677fa6d@ship.edu> <D16C02C6-C2E8-478A-9CF5-DF2477ACAFE8@virginia.edu> <5D278454-71F9-4617-BFA3-8B66863D335A@jhu.edu> Message-ID: <CY1PR0701MB12092CFF41EAB3B0482003D190E40@CY1PR0701MB1209.namprd07.prod.outlook.com> Steve and Tim, Thank you for your clear explanations. As it happens, as a member of the TAC, I?m working on improving the plugins documentation; be sure I?ll be incorporating this! Cheers, Bobbi From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Timothy Dilauro Sent: Monday, January 29, 2018 11:51 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 You can control the timing of the loading of your extensions by placing them in an "config.after_initialize" block in plugin_init.rb. For the 1.5.4 PUI, I used the following block: ArchivesSpacePublic::Application.config.after_initialize do end In addition, you can ensure that each needed module/class is loaded by mentioning it before you attempt to extend it: RecordsController class RecordsController ... end See https://github.com/jhu-archives-and-manuscripts/aspace_plugin-jhu_public/blob/master/public/plugin_init.rb Cheers, ~Tim On Jan 29, 2018, at 11:25 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu<mailto:sdm7g at virginia.edu>> wrote: I had a need to look into this issue of overriding existing routes or controllers again. I was trying to make repositories#index be the default landing page instead of welcome#show . Adding this to plugins/local/public/routes.rb and loading those routes from plugin_init.rb appended the new route to the end of the routes. This was visible when I ran ?rake routes? on the public rails app. However routing takes the first match from the route table, so the default ?welcome at show? was what was run. I haven?t yet figured out if there is any way to add a new route to the start of the routes table rather than at the end. I unsuccessfully tried several different methods of overriding welcome#show. During that process, I also stuck in a binding.pry breakpoint in plugins/local/public/plugin_init.rb and verified that ApplicationController is not in scope. In fact, I suspect that since it is being loaded as an initializer, the controllers may not have been loaded and defined at that point. What finally worked for me was: plugins/local/public/controllers/my_controller.rb: class WelcomeController def show redirect_to :controller => 'repositories' , :action => 'index' end end This did successfully override welcome#show so that going to http://localhost:3001/ redirects to http://localhost:3001/repositories and show the list of repositories. ( In this case, I?ve also overridden views/repositories/index.html.erb in the the plugin so that it also includes the search form above the repository list. ) What I don?t completely understand is that if the same file is named plugins/local/public/controllers/welcome_controller.rb, it does not seem to work. Other arbitrary names, like ?x_controller.rb? for example, do work. Just not ?welcome_controller.rb? . It would appear that the existing application welcome controller may keep this file from loading. I just added a binding.pry breakpoint and renamed that file and verified that it never executes when named ?welcome_controller.rb? . So you might try something similar. Routes or plugin_init are probably not required if you?re just extending existing controller. Add a file to the plugin controller directory that redefines resource controller, but give it a name that doesn?t duplicate any existing controller file. If you try to inherit from and extend an existing controller, you may be able to add a new route pointing to it, but I don?t know a way to change the existing route to point to a the new class. Let us know if you find something that works! ? Steve Majewski On Dec 22, 2017, at 3:07 PM, Flanagan, Patrick <PJFlanagan at ship.edu<mailto:PJFlanagan at ship.edu>> wrote: I think I just encountered that sort of issue. From public/plugin_init.rb both ResourcesController and ApplicationController don't appear to be in scope; so I can't even replace it let alone extend it. That, or I'm supposed to use require to get at the specific classes - but I haven't been able to do so. I think it's one of the intricacies of Rails that is escaping me. Ideally, for an identifier of A/B/C/D on a given resource, I wanted the breadcrumb to link back to A - B - C - D - This Resource, a behavior that's more similar to Archon, and more useful than the default behavior of simply linking to the repository top itself, I think. ~Patrick Flanagan KLN Applications Administrator Keystone Library Network Hub ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu<mailto:sdm7g at virginia.edu>> Sent: Thursday, December 21, 2017 4:40:29 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 I remember running into something like this where the problem was Rails lazy loading of classes. The base classes were not actually defined when the plugins were loaded, so what was supposed to be additional methods extending an existing class became the entire replacement class definition. I had to add a reference to the class to force lazy loading before trying to extend the class. This might be what you are running into. I will look and see if I still have any notes with more details from that experiment. ? Steve. On Dec 21, 2017, at 4:18 PM, Flanagan, Patrick <PJFlanagan at ship.edu<mailto:PJFlanagan at ship.edu>> wrote: Hi Bobbi, Thank you for this! I'll give it a try this way and see if I can make some progress. ~Patrick Flanagan KLN Applications Administrator Keystone Library Network Hub ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Fox, Bobbi <bobbi_fox at harvard.edu<mailto:bobbi_fox at harvard.edu>> Sent: Thursday, December 21, 2017 3:47:18 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 Hi, Patrick, I?m having to do a lot of extending/overriding of controllers & methods in our new public interface. You are correct; you can?t just override by placing your modified controller in the path location; instead, what *I?m* doing (and I know there?s a more elegant way of doing it); is put the changes in the plugin/plugin_init.rb ,using the [class|module]_eval method on something. For instance, I?m changing what gets faceted in the Searchable concern this way in plugin_init.rb: Searchable.module_eval do def set_up_and_run_search(default_types = [],default_facets=[],default_search_opts={}, params={}) ~ my stuff here ~~ end end I?m adding methods to controllers in a somewhat similar way, for instance, in plugin_init.rb, I?ve got: # add a digital only action to the resources controller class ResourcesController def digital_only uri = "/repositories/#{params[:rid]}/resources/#{params[:id]}" begin ~ etc. ~ end end Hope this helps, Bobbi From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Flanagan, Patrick Sent: Thursday, December 21, 2017 3:27 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>> Subject: [Archivesspace_Users_Group] Overriding/Extending the new public interface in 2.2.0 Hello, I'm attempting to write a plugin that will modify the way the breadcrumb trail (shown in the new public UI) is generated to include more detail. I decided to try and override one of the files in the controller part of the architecture: resources_controller.rb, since I can see the :crumb being defined there. However, either my path is wrong, or the new UI isn't utilizing it. Following the instructions here:http://archivesspace.github.io/archivesspace/user/archivesspace-plug-ins-readme/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_archivesspace-2Dplug-2Dins-2Dreadme_&d=DwMFAw&c=WO-RGvefibhHBZq3fL85hQ&r=5xWUzLrZrVLeTqs3CDoeRpPtLv1fRM04CCu4TDULrSY&m=3DmZ4KyjSuOHTC-7rfq8Dv2MTeEFEBci91sKzca-4YQ&s=is5OAKKChee55MtdTuQYDj2OwuvI8f0Y6lBLS8-ast8&e=> I've placed the file in the following directory: as220/plugins/local/public/controllers/resources_controller.rb ( source location: /public/app/controllers/resources_controller.rb ) Plugin Config: AppConfig[:plugins] = ['local', 'lcnaf', 'aspace-public-formats'] If I'm not mistaken that document indicates that this is something that can be overridden, but I'm suspecting I can't actually override something in the controller from a plugin. The version is 2.2.0, running on Linux x64, openjdk version "1.8.0_151". Any advice would be appreciated! Thank you, ~Patrick Flanagan KLN Applications Administrator Keystone Library Network Hub _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180130/66515013/attachment.html> From laney.mcglohon at lyrasis.org Wed Jan 31 10:33:08 2018 From: laney.mcglohon at lyrasis.org (Laney McGlohon) Date: Wed, 31 Jan 2018 15:33:08 +0000 Subject: [Archivesspace_Users_Group] available now: beta version of ArchivesSpace Data Dictionary Message-ID: <01702D2A-1792-433E-8F48-1E9CEDE0CA65@lyrasis.org> Following on from a discussion on the Users Group in late November, we?re pleased to announce the availability of a beta version of a data dictionary for ArchivesSpace. You can access it at https://desolate-tundra-60608.herokuapp.com/. (Once it?s formally released it will move to a more permanent location and URL.) The ArchivesSpace Data Dictionary provides a simple mechanism to browse or search for information about the data elements in the ArchivesSpace database schema. It can be used to determine where data is stored in the ArchivesSpace database along with how the data is displayed in the staff and public user interfaces. We expect it will be helpful for a variety of purposes, including writing reports, working with the ArchivesSpace API, and writing code for the ArchivesSpace application. We?ve started simply, but anticipate adding additional data points and functionality over time, including: * Adding crosswalk information for the following metadata standards: * EAD * MARC * MODS * DC * Highlighting results in context * Sort capability from column headings * Ability to search specific fields * Exporting of search results This data dictionary would not have been possible without the efforts of the User Advisory Council?s Reports sub-team (https://archivesspace.atlassian.net/wiki/spaces/AC/pages/103258126/Reports+2017-2018), especially past member Nancy Enneking, who worked closely with me to gather the content and guide the design. This is a beta release and we welcome feedback and ideas or pull requests for improvements. You can get in touch by emailing me (laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org>) or submitting an issue or pull request to the GitHub repository (https://github.com/lmcglohon/data-dictionary). Best, Laney Laney McGlohon ArchivesSpace Tech Lead laney.mcglohon at lyrasis.org<mailto:laney.mcglohon at lyrasis.org> laneymcglohon Skype [cid:image001.jpg at 01D39034.63178020] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180131/a2ab9077/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6701 bytes Desc: image001.jpg URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180131/a2ab9077/attachment.jpg> From chris.helms at library.gatech.edu Wed Jan 31 12:29:12 2018 From: chris.helms at library.gatech.edu (Helms, Christopher J) Date: Wed, 31 Jan 2018 17:29:12 +0000 Subject: [Archivesspace_Users_Group] Running archivesspace from systemd In-Reply-To: <CAJ2fXCOQSXULDCQjSo6G6Ffe84V5FJp6v-9q6qr3mcppEN1=1Q@mail.gmail.com> References: <CAJ2fXCPVXPrRJwM=i812ouFQ70n1WsWSfP=LPAr=PoNomZRQsA@mail.gmail.com> <CY1PR08MB1248879F76F47FA574C3EE929FE00@CY1PR08MB1248.namprd08.prod.outlook.com> <CAJ2fXCOQSXULDCQjSo6G6Ffe84V5FJp6v-9q6qr3mcppEN1=1Q@mail.gmail.com> Message-ID: <564FA43E-4DAD-48A5-86AD-341BABF63331@gatech.edu> At Georgia Tech I have had success with the following recipe under RHEL 7. It runs with the default ArchiesSpace ports, proxied via Apache to the outside world. Create the file /etc/systemd/system/archivesspace.service # Systemd unit file for ArchivesSpace # [Unit] Description=ArchivesSpace Application After=syslog.target network.target [Service] Type=forking ExecStart=/var/www/archivesspace/v2.2.2/archivesspace.sh start ExecStop=/var/www/archivesspace/v2.2.2/archivesspace.sh stop PIDFile=/var/www/archivesspace/v2.2.2/data/.archivesspace.pid User=aspace Group=aspace [Install] WantedBy=multi-user.target Then reload systemd. $ sudo systemctl daemon-reload After an upgrade I can stop the application, update version numbers, reload the daemon, then start the newly deployed version. # systemctl status archivesspace ? archivesspace.service - ArchivesSpace Application Loaded: loaded (/etc/systemd/system/archivesspace.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2018-01-31 09:54:26 EST; 2h 28min ago Main PID: 115350 (java) CGroup: /system.slice/archivesspace.service ??115350 java -Darchivesspace-daemon=yes -Djava.security.egd=file:/dev/./urandom -Xmx1024m -Xss2m -XX:MaxPermSize=256m -Dfile.encoding=UTF-8 -cp l... Jan 31 09:54:26 archivesspace-stage.library.gatech.edu systemd[1]: Starting ArchivesSpace Application... Jan 31 09:54:26 archivesspace-stage.library.gatech.edu archivesspace.sh[115326]: ArchivesSpace base directory: /var/www/archivesspace/v2.2.2 Jan 31 09:54:26 archivesspace-stage.library.gatech.edu systemd[1]: Started ArchivesSpace Application. -- Christopher J. Helms Application Developer Mgr | Library IT&D Georgia Institute of Technology Phone: (404) 385-6277 From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Flannon Jackson <flannon at nyu.edu> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Date: Friday, January 26, 2018 at 5:16 PM To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org> Subject: Re: [Archivesspace_Users_Group] Running archivesspace from systemd Hi Blake, I was able to get my issues sorted out and I've now got archivesspace 2.2.2 running on Centos 7. I've got it set up in a vagrant box if you want to have a look. If you've got virtualbox and vagrant set up on your local machine then you can get it running like this, $ git clone git at github.com:NYULibraries/vagrant-archivesspace.git $ cd vagrant-archivesspace $ vagrant up $ vagrant ssh $ sudo systemctl start archivesspace.service It'll install archivesspace in /opt/archviesspace, and the unit file will be at /ets/systemd/system/archivesspace.service. All the config details, usernames, passwords and such, can be found in /etc/puppetlabs/code/environments/development/data/archivesspace.yaml Once archivesspace is up and running you'll be able to connect via your browser at localhost:8080. If you've already got something running on your local machine on any of the archivesspace ports you'll need to change the port mappings in the Vagrantfile before you run `vagrant up`. -f On Fri, Jan 26, 2018 at 1:49 PM, Blake Carver <blake.carver at lyrasis.org<mailto:blake.carver at lyrasis.org>> wrote: Has anyone had any luck with systemd yet? ________________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Flannon Jackson <flannon at nyu.edu<mailto:flannon at nyu.edu>> Sent: Monday, August 7, 2017 2:01:15 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Running archivesspace from systemd Hi All, I'm trying to run the archivesspace daemon from a systemd unit file but I'm getting an odd delay. If I start archivesspace manually by running "$ sudo archivesspace.sh start" things run normally, but when I start archivesspace from systemctl then any operation on port 8080 delays from 10 to 20 seconds before it returns results. If anyone is running archivesspace from systemctl and can offer any advice it would be appreciated. The details of my deployment are as follow, OS : Centos 7.3.10 Java: OpenJDK 1.8.0_141 archivesspace: 2.0.0 | 2.0.1 | 2.1.0 (i've tried all three with the same results) My unit file is as follows, [Unit] Description=Archivesspace Service After=syslog.target network.target [Service] Type=forking ExecStart=/opt/archivesspace/archivesspace.sh start PIDFile=/opt/archivesspace/data/.archivesspace.pid User=aspace Group=aspace TimeoutStopSec=10 Restart=on-failure [Install] WantedBy=multi-user.target Initially I tried running it as user aspace. When that didn't work I also tried as root, but that didn't change anything. Currently I'm running archivesspace 1.5.2 on Centos 6 and the archivesspace daemon gets started from a wrapper script in init.d, so I thought that if I replicated that structure and had a wrapper script to run from the unit fil,e and set the type to either simple, or oneshot or idle, that that might do it. So I tried it like this, [Unit] Description=Archivesspace Service After=syslog.target network.target [Service] Type=simple ExecStart=/opt/archivesspace/aspace-start.sh PIDFile=/opt/archivesspace/data/.archivesspace.pid User=root Group=root [Install] WantedBy=multi-user.target But basically nothing changed -- archivesspace started fine but I still had the crazy delay. I'm thinking at this point that rather than having a unit file that calls archivesspace.sh that I need to write a unit file that replaces the functionality of archivesspace.sh and calls archivesspace directly. As you've probably noticed, archivesspace.sh is not exactly a trivial shell script, so before I get started I wanted to see if anyone else has had any luck getting archivesspace running on systemd. Thanks, Flannon _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180131/de5f05fa/attachment-0001.html>