[Archivesspace_Users_Group] Bulk updater plug-in community survey

[Cory Nimer]

The ArchivesSpace Usability Sub-team is seeking community input about 
potentially integrating the bulk updater plug-in developed by Hudson Molonglo 
on behalf of The New School into the main application (see 
https://github.com/hudmol/as_spreadsheet_bulk_updater/blob/main/README.md). 
This includes assessing interest in this functionality and gathering feedback 
about previous institutional use of the existing plug-in. Your participation in 
the survey is optional, and completing the survey should take approximately 
5-10 minutes.

The survey is available at 
https://docs.google.com/forms/d/e/1FAIpQLSfnYGiQKlCHiQ6RtOH9D3Rk0cH89hta03Lp3q6ZUOO1Er6GWQ/viewform?usp=sf_link

The link will be available for responses until June 23, 2023.

We appreciate the work that has been done by the plug-in developers and look 
forward to learning more about the community's experience and interest in this 
functionality.

Sincerely,

Cory Nimer
Usability Sub-team Lead


University Archivist
Brigham Young University
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Viewing CUI in Resource record hierarchy view

[Cory Nimer]

There is a JIRA feature request for this functionality in the system (ANW-971; 
https://archivesspace.atlassian.net/browse/ANW-971), which is listed as Ready 
for Implementation. It does not appear to have been assigned or scheduled for 
development yet. If this is work that the community would like to see 
completed, or if you would like changes to the proposed changes, it may be 
helpful to comment on the ticket.

Best,

Cory Nimer
University Archivist
Brigham Young University

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Paige 
Monlux
Sent: Monday, May 15, 2023 12:22 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Viewing CUI in Resource record hierarchy 
view

Hello,

Is there a way to view an archival object's component unique identifier when 
navigating in the Resource record? I know how to set it as a column in the 
Browse view, but would like to see it in the hierarchy view.

[cid:image001.png@01D987D4.D2791F30]

Paige

Paige Monlux (she/her)
Digital Archivist
Records Management & Archives<https://multco.us/records>
Department of County Assets | Multnomah County
503.988.3741 | interoffice: 425/Archives

Hours: Mon-Thu 6:30a-4p, Fri 6:30a-3p
Note: I am out of the office every other Friday.

Explore Multnomah County's Digital 
Archives<https://multco.access.preservica.com/>!

[https://multco.us/sites/default/files/styles/small/public/AllAreWelcome_email-signature_PRIDE_ENGLISH.jpg]

[https://multco.access.preservica.com/wp-content/uploads/sites/3/2021/06/2021-06-11_6-36-08.png]
 <https://multco.access.preservica.com/>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace

[Cory Nimer]

Ron,

I would agree that it would be preferable to have a more EAD3-friendly 
configuration for related materials notes, at least in order to reduce/remove 
the need for mixed content within these notes. I don't know if there is 
widespread interest in moving implementing something more like the Agents 
module's Sources subrecord or the Metadata Rights Declarations with their 
fields for recording a descriptive note and a URL separately. It looks like the 
project has already rejected the idea of being allowing linking between 
different records within the database, though (ANW-763; 
https://archivesspace.atlassian.net/browse/ANW-763).

Best,

Cory Nimer
University Archivist
Brigham Young University

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Ron Van 
den Branden
Sent: Wednesday, May 25, 2022 10:05 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Hi Corey,

Many thanks for your helpful reply! In our current data, these structured links 
are indeed connected to a field that maps to  in 
ArchivesSpace, so that’s indeed the destination we had in mind.

Your example for embedding ArchivesSpace-internal links via the ArchivesSpace 
ID for a @href attribute was really helpful and finally made me get it working 
in the test instance, great! That’s a useful mechanism, though I fully agree 
the manual input process is brittle, even with the (limited) “mixed content” 
completion help. In order to make the most semantic sense, as you exemplified 
with the  example, our colleagues and volunteers describing the 
archives would have to be knowledgeable of XML syntax rules, and the suitable 
EAD structures for the information they’d want to enter. Yet, even if a new 
structured resource-to-resource link field would be too far off the 
implementation horizon, perhaps a general improvement for adding such internal 
cross-links in text fields in a more guided way could be of interest. I’ll 
think about it!

Finally, your data audit remark sounds intriguing and -considering the amount 
of data cleanup this data migration project has confronted us with- a vital 
part of best practice. Would you mind elaborating on that, or pointing me to 
any available documentation?

Best,

Ron

Van: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 Namens Corey Schmidt
Verzonden: woensdag 25 mei 2022 14:57
Aan: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / 
Archival Objects in ArchivesSpace

Hey Ron,

Glad to see you reaching out! I’m not sure if others have emailed you regarding 
this, so I’ll put in my 2 cents worth.

  *   From what I understand, there is no mechanism within ArchivesSpace that 
provides a structured “Agents/Related Accessions” type link from one resource 
to another, nor one archival object to another.
  *   Have you considered using the “Related Materials” note 
(<https://www.loc.gov/ead/tglib/elements/relatedmaterial.html>)?
 The advantage with this is the note is made specifically for related materials 
either within the repository or without and you don’t need a full URL, just the 
ArchivesSpace ID if you’re using the PUI, like so: Related Collection title. The 
problem with this is you have to enter the info by hand, which is error prone 
(we’ve scheduled a yearly “data audit” to help us catch errors like these).
  *   I don’t know of any institution that has developed a 
plugin<https://github.com/archivesspace/awesome-archivesspace>, nor is this on 
the roadmap I think. Nevertheless, you can submit a JIRA 
ticket<https://archivesspace.atlassian.net/jira/software/c/projects/ANW/issues/ANW-1334>
 for this feature (how to do that linked 
here<https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/19202060/How+to+Request+a+New+Feature>)
 – explaining how you want it to work with as much detail as possible. The 
Development Priority Team will then determine if the ArchivesSpace development 
team or community can/should prioritize it in future releases. The more 
attention a ticket gets (comments, clarifications, etc.) the more likely it is 
to be implemented (great YouTube video here about the 
process<https://www.youtube.com/watch?v=jlquifRXwmA>).

I hope this is helpful, but if you’d like to talk more about it, feel free to 
email me: corey.schm...@uga.edu<mailto:corey.schm...@uga.edu>. To everyone on 
the listserv, please feel free to correct any of this info if it’s 
incorrect/misleading.

Sincerely,

Corey
Corey Schmidt
Special Collections Libraries | Project Management Librarian/Archivist
300 S Hull St | Athens, GA 30605
corey.schm...@uga.edu<mailto:corey.schm...@uga.edu>
Fr

[Archivesspace_Users_Group] PUI barcodes display in AS 3.1.1

[Cory Nimer]

Colleagues,

We are currently testing the migration from AS 2.8.1 to 3.1.1, and following 
migration we discovered that the public interface was displaying container 
barcodes by default in both search results and in the Physical Storage 
Information section of the record display. For example:

[cid:image002.png@01D83DD2.9DB60D50]

[cid:image001.png@01D83DD2.0D09EB50]

This was not the case in version 2.8.1, where containers were listed but the 
barcode was not displayed. Is there any documentation about this change in the 
display, or is does anyone know if this is a configurable option for the 
application? Checking this on the ArchivesSpace test instance 
(test.archivesspace.org) this value does not appear to be displayed in either 
the search results or the record display.

Best,

Cory Nimer
University Archivist
Brigham Young University

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Approach to describing single items

[Cory Nimer]

Amy,

We use the Option 1 here, though we also have had some concerns with the PUI 
thumbnail display at this level. Looking ahead, we are hoping that the display 
issues will be fixed with the 3.2.0 release--the release candidate notes 
reference ANW-810 (https://archivesspace.atlassian.net/browse/ANW-810), which 
seems to cover this use case. There are also some proposed fixes for this issue 
in the draft specification for ANW-1209 
(https://archivesspace.atlassian.net/browse/ANW-1209), which was under 
discussion by the Development Prioritization Subteam in their meeting on 
Tuesday 
(https://archivesspace.atlassian.net/wiki/spaces/AC/pages/3022716936/2022-02-01+Meeting+notes).

Best,

Cory Nimer
University Archivist
Brigham Young University

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Amy 
Braitsch
Sent: Thursday, February 3, 2022 8:20 AM
To: Archivesspace_Users_Group@lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Approach to describing single items


Hey there ASpace list,


At BC we're working toward implementing the PUI. To get there we've remediated 
a lot of legacy data and data practice. An area we haven't handled yet is what 
to do with single item resources (e.g. a diary). We've been inconsistent and 
need to settle on one approach. I'd like to know what you've found to be the 
best approach and why.


Here are the two approaches we’ve taken. I see pluses and minuses:


Option 1: Resource without archival objects, with instances/digital objects 
associated at the collection level. This makes logical sense, but the PUI 
displays these containers/digital objects differently than on collections with 
instances on the archival objects. The biggest difference in the PUI is that 
thumbnails are omitted from the digital objects when they’re at this level. On 
the staff side, the collection-level resource lacks the ref ID and CUI field, 
which we use as part of our digital object file naming convention.


[https://lh3.googleusercontent.com/h1gOnm4gLUMsOkM7ShuPikZJMpY8ZwsQAj-gVGJws5K6m75MIa8qjzUyHfMiGRvcAX4ELJg0GE2T5Zk1lPIUTrkuRkTkc96fU47C0ONY87t2XoRh3K48xQ1ieyjZ_jBOEf8TShj9]


Option 2: Resource with a child archival object (repeating the title of the 
parent), with instances/digital objects associated with the AO. This seems like 
redundant record-keeping. It requires more researcher clicks in the PUI, but 
the display of the instances are consistent with other collections. On the 
staff side, the ref ID and CUI are available for use in our digital object 
workflows.


[https://lh6.googleusercontent.com/4lxCTd6c0IIlfWYIXOjWgGv38DLlzakRsLwBQjjyso6KB6yTm3YaydBDG8Ask6SX1Zsu39SiVua3y0TTEce0zGURxlfT1hrJhKaYt8tAfjljaATqQR2BsgcgB7SEffpYIFIuGlBr]


We rely on ASpace for collection management and description. As we move into 
using it for discovery as well, I want to be sure that we're following 
road-tested best practices.


Thanks for your help!

Amy


Amy Braitsch (pronouns: she/her/hers)
Head of Archives, Burns Library, Boston College, 
amy.brait...@bc.edu<mailto:amy.brait...@bc.edu>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Duplicated agent dates in migration to 3.0.1

[Cory Nimer]

Patrick,

We found the same thing in our test migration to 3.0.1. In cases where an Agent 
date entry included both a date expression and normalized dates, the 
application had split up the 2.8 date entry into two separate entries--one for 
the date expression (without normalized dates) and one for the normalized dates 
(without date expressions). Our impression was that the application was not 
parsing the date expression at all.

This is a significant issue for us moving forward, and we would be interested 
in learning more about what approaches other institutions have been considering 
to address this issue.

Best,

Cory Nimer
University Archivist
Brigham Young University

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of 
Galligan, Patrick
Sent: Monday, June 21, 2021 12:10 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Duplicated agent dates in migration to 
3.0.1

Hi all,

We've noticed that in our test migration from ArchivesSpace version 2.8.0 to 
3.0.1 that the agent migration was sometimes creating two separate structured 
dates based on whether there was an existing date expression or not in the 
dates of existence section.

Here is the JSON before migration:

"dates_of_existence": [
{
"lock_version": 0,
"expression": "1915-2017",
"begin": "1915",
"end": "2017",
"created_by": "pgalligan",
"last_modified_by": "pgalligan",
"create_time": "2019-12-04T14:24:11Z",
"system_mtime": "2019-12-04T14:24:11Z",
"user_mtime": "2019-12-04T14:24:11Z",
"date_type": "range",
"label": "existence",
"jsonmodel_type": "date"
}
],


Here is the JSON post-migration:

"dates_of_existence": [
{
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"date_label": "existence",
"date_type_structured": "single",
"jsonmodel_type": "structured_date_label",
"structured_date_single": {
"date_expression": "1915-2017",
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"date_role": "begin",
"date_standardized_type": "standard",
"jsonmodel_type": "structured_date_single"
}
},
{
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"date_label": "existence",
"date_type_structured": "range",
"jsonmodel_type": "structured_date_label",
"structured_date_range": {
"begin_date_standardized": "1915",
"end_date_standardized": "2017",
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"begin_date_standardized_type": "standard",
"end_date_standardized_type": "standard",
"jsonmodel_type": "structured_date_range"
}
}
],

It also seems to be creating a structured singular date instead of a date 
range. It's parsing the expression correctly into separate dates, but it's 
entirely unnecessary and creates and incorrect duplication.

This seems like a bug and would stop us from updating because it'd be a hassle 
to go in and remove these.

Is this intended behavior for this migration? There may be something I'm not 
understanding about MARC or EAC-CPF that makes this desirable, but it seems 
like a bug to me.

Thanks,
Patrick Galligan
Rockefeller Archive Center
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate available - ArchivesSpace v3.0.0-RC2

[Cory Nimer]

itories\/14\/top_containers\/44615")+OR+id:("\/repositories\/14\/top_containers\/44616")+OR+id:("\/repositories\/14\/top_containers\/44617")+OR+id:("\/repositories\/14\/top_containers\/51251")+OR+id:("\/repositories\/14\/top_containers\/35186")+OR+id:("\/repositories\/14\/top_containers\/35187"))"*=(id:("\/repositories\/14\/top_containers\/49935")+OR+id:("\/repositories\/14\/top_containers\/45298")+OR+id:("\/repositories\/14\/top_containers\/53845")+OR+id:("\/repositories\/14\/top_containers\/37492")+OR+id:("\/repositories\/14\/top_containers\/37493")+OR+id:("\/repositories\/14\/top_containers\/44614")+OR+id:("\/repositories\/14\/top_containers\/44615")+OR+id:("\/repositories\/14\/top_containers\/44616")+OR+id:("\/repositories\/14\/top_containers\/44617")+OR+id:("\/repositories\/14\/top_containers\/51251")+OR+id:("\/repositories\/14\/top_containers\/35186")+OR+id:("\/repositories\/14\/top_containers\/35187"))=title^10=true="=json=true}
 hits=12 status=0 QTime=2
F, [2021-04-28T15:00:44.665477 #738968] FATAL -- : 
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402]
F, [2021-04-28T15:00:44.670725 #738968] FATAL -- : 
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] ActionView::Template::Error (undefined 
method `any?' for nil:NilClass):
F, [2021-04-28T15:00:44.670997 #738968] FATAL -- : 
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] 1: <% names_with_primarys = 
result.json['names'].select{ |n| n['parallel_names'].any? } %>
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] 2:
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] 3: <% if names_with_primarys.any? %>
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] 4:   <%= 
I18n.t('pui_agent.parallel') %>
F, [2021-04-28T15:00:44.671254 #738968] FATAL -- : 
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402]
F, [2021-04-28T15:00:44.671413 #738968] FATAL -- : 
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] 
app/views/agents/_parallel_names.html.erb:1:in `block in 
_app_views_agents__parallel_names_html_erb___1405336289_3580'
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] 
app/views/agents/_parallel_names.html.erb:1:in 
`_app_views_agents__parallel_names_html_erb___1405336289_3580'
[0fddf9ca-48ff-42b6-9eff-bfd42e0e8402] app/views/agents/show.html.erb:18:in 
`_app_views_agents_show_html_erb__937450912_3568'
We would be glad for any suggestions you might have.

Thanks,

Cory

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of 
Christine Di Bella
Sent: Tuesday, April 27, 2021 11:34 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2

Hello Cory (and anyone else following this thread),

There’s a new zip file posted for v3.0.0-RC2 on the releases 
page<https://github.com/archivesspace/archivesspace/releases> that we think 
remedies this issue. If you can, would you please ask your IT staff to try with 
this file and let us know how it goes?

Thanks for your help,
Christine

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Cory Nimer
Sent: Friday, April 23, 2021 7:03 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2

Brian,

We are currently running the following plugins:

AppConfig[:plugins] = ['local', 'byu-branding', 'user_defined_in_basic', 
'contentdm-get-metadata', 'archivesspace_export_service', 'tree_component_id', 
'aspace_sitemap']

Our IT staff did try running the release candidate without the plugins, though, 
and they reported that this did not change the errors they were receiving. At 
this point they have decided to stop testing on our end until the next release 
candidate, given the current installation issues.

Thanks for your help,

Cory

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Brian Hoffman
Sent: Friday, April 23, 2021 1:52 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2

Hi Cory,

It might be possible to eliminate the issue with the staff interface by setting 
an environment variable. For example:

BUNDLE_WITH="default" ./archivesspace.sh start

I think the issue with the public app is different and is going to require a 
follow-up release next week.

I am also curious to know what plugins you are using? Did you copy them 

Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate available - ArchivesSpace v3.0.0-RC2

[Cory Nimer]

Brian,

We are currently running the following plugins:

AppConfig[:plugins] = ['local', 'byu-branding', 'user_defined_in_basic', 
'contentdm-get-metadata', 'archivesspace_export_service', 'tree_component_id', 
'aspace_sitemap']

Our IT staff did try running the release candidate without the plugins, though, 
and they reported that this did not change the errors they were receiving. At 
this point they have decided to stop testing on our end until the next release 
candidate, given the current installation issues.

Thanks for your help,

Cory

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Brian 
Hoffman
Sent: Friday, April 23, 2021 1:52 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2

Hi Cory,

It might be possible to eliminate the issue with the staff interface by setting 
an environment variable. For example:

BUNDLE_WITH="default" ./archivesspace.sh start

I think the issue with the public app is different and is going to require a 
follow-up release next week.

I am also curious to know what plugins you are using? Did you copy them over 
from your production install?

Brian


From: 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Cory Nimer mailto:cory_ni...@byu.edu>>
Reply-To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Date: Friday, April 23, 2021 at 3:04 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2

We are currently running Java 1.8.0_282.

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Blake Carver
Sent: Friday, April 23, 2021 10:53 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2

What's the JAVA version on there?

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Cory Nimer mailto:cory_ni...@byu.edu>>
Sent: Friday, April 23, 2021 12:42 PM
To: Christine Di Bella 
mailto:christine.dibe...@lyrasis.org>>; 
Archivesspace Users Group 
(archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>)
 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2


Christine,



Here are the basic specs for our testing server according to our IT staff:



RHEL 8.3

4 procs

5GB RAM



For what it's worth, the error I posted that says there is a missing ruby gem 
is what I see if I go to the staff interface. If I go to the PUI, it will show 
a different missing ruby gem (sassc-2.4.0). Not sure if other pages might 
reveal other missing gems. Christine mentioned that others had seen a similar 
issue but the gem mentioned was different, so maybe they were looking at a 
different page. In any case it seems that somehow this build of ArchivesSpace 
is missing some required ruby gems.



If you need other information about the server, please let me know.



Best,



Cory



From: Christine Di Bella 
mailto:christine.dibe...@lyrasis.org>>
Sent: Friday, April 23, 2021 9:17 AM
To: Cory Nimer mailto:cory_ni...@byu.edu>>; Archivesspace 
Users Group 
(archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>)
 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_uac] release candidate available - ArchivesSpace 
v3.0.0-RC2



Hello Cory,



We're investigating a gem-related issue where the second release candidate is 
not running correctly on some kinds of servers. (We encountered something 
similar on a Windows server yesterday, though the gem mentioned was different.) 
Would you please post the specs of your server here or email them to me 
directly?



There was an issue that affected all Rails applications between the release of 
our first release candidate and our second one that required us to do some 
unplanned upgrades, though we were hopeful that the impact would be limited for 
3.0 since Rails came out with a fix for their issue during that timeframe. We 
definitely want to hear from people if they are experiencing issues installing 
RC2.



Thanks for your help,

Christine

Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate available - ArchivesSpace v3.0.0-RC2

[Cory Nimer]

We are currently running Java 1.8.0_282.

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Blake 
Carver
Sent: Friday, April 23, 2021 10:53 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2

What's the JAVA version on there?

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Cory Nimer mailto:cory_ni...@byu.edu>>
Sent: Friday, April 23, 2021 12:42 PM
To: Christine Di Bella 
mailto:christine.dibe...@lyrasis.org>>; 
Archivesspace Users Group 
(archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>)
 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate 
available - ArchivesSpace v3.0.0-RC2


Christine,



Here are the basic specs for our testing server according to our IT staff:



RHEL 8.3

4 procs

5GB RAM



For what it's worth, the error I posted that says there is a missing ruby gem 
is what I see if I go to the staff interface. If I go to the PUI, it will show 
a different missing ruby gem (sassc-2.4.0). Not sure if other pages might 
reveal other missing gems. Christine mentioned that others had seen a similar 
issue but the gem mentioned was different, so maybe they were looking at a 
different page. In any case it seems that somehow this build of ArchivesSpace 
is missing some required ruby gems.



If you need other information about the server, please let me know.



Best,



Cory



From: Christine Di Bella 
mailto:christine.dibe...@lyrasis.org>>
Sent: Friday, April 23, 2021 9:17 AM
To: Cory Nimer mailto:cory_ni...@byu.edu>>; Archivesspace 
Users Group 
(archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>)
 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_uac] release candidate available - ArchivesSpace 
v3.0.0-RC2



Hello Cory,



We're investigating a gem-related issue where the second release candidate is 
not running correctly on some kinds of servers. (We encountered something 
similar on a Windows server yesterday, though the gem mentioned was different.) 
Would you please post the specs of your server here or email them to me 
directly?



There was an issue that affected all Rails applications between the release of 
our first release candidate and our second one that required us to do some 
unplanned upgrades, though we were hopeful that the impact would be limited for 
3.0 since Rails came out with a fix for their issue during that timeframe. We 
definitely want to hear from people if they are experiencing issues installing 
RC2.



Thanks for your help,

Christine





From: Cory Nimer mailto:cory_ni...@byu.edu>>
Sent: Friday, April 23, 2021 10:18 AM
To: Archivesspace Users Group 
(archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>)
 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>;
 Christine Di Bella 
mailto:christine.dibe...@lyrasis.org>>
Subject: RE: [Archivesspace_uac] release candidate available - ArchivesSpace 
v3.0.0-RC2



Christine,



When installing the release candidate our IT staff reports that they are 
encountering an error, as described below:



I'm trying to get archivesspace v 3.0.0-RC2 running on our staging server. 
Everything seemed to install ok, and the server seems to start up ok (based on 
the log output), but when I try to bring up the public or staff website I get 
an error. I'm wondering if you could post something on the listserv or point me 
in the right direction to do it.



I upgraded from v2.8.1 and followed the upgrade directions here: 
https://archivesspace.github.io/tech-docs/administration/upgrading.html



Here's the error I get when I try to bring up the staff website 
(https://asadminstg.lib.byu.edu<https://asadminstg.lib.byu.edu/>):



Internal Server Error (500)
Request Method: GET
Request URL: http://asadminstg.lib.byu.edu/
Could not find rubyntlm-0.6.3 in any of the sources from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:86:in
 `block in materialize' from org/jruby/RubyArray.java:2609:in `map!' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:80:in
 `materialize' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:170:in
 `specs' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:237:in
 `specs_for' from 
/srv/a

Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate available - ArchivesSpace v3.0.0-RC2

[Cory Nimer]

Christine,

Here are the basic specs for our testing server according to our IT staff:

RHEL 8.3
4 procs
5GB RAM

For what it's worth, the error I posted that says there is a missing ruby gem 
is what I see if I go to the staff interface. If I go to the PUI, it will show 
a different missing ruby gem (sassc-2.4.0). Not sure if other pages might 
reveal other missing gems. Christine mentioned that others had seen a similar 
issue but the gem mentioned was different, so maybe they were looking at a 
different page. In any case it seems that somehow this build of ArchivesSpace 
is missing some required ruby gems.

If you need other information about the server, please let me know.

Best,

Cory

From: Christine Di Bella 
Sent: Friday, April 23, 2021 9:17 AM
To: Cory Nimer ; Archivesspace Users Group 
(archivesspace_users_group@lyralists.lyrasis.org) 

Subject: Re: [Archivesspace_uac] release candidate available - ArchivesSpace 
v3.0.0-RC2

Hello Cory,

We're investigating a gem-related issue where the second release candidate is 
not running correctly on some kinds of servers. (We encountered something 
similar on a Windows server yesterday, though the gem mentioned was different.) 
Would you please post the specs of your server here or email them to me 
directly?

There was an issue that affected all Rails applications between the release of 
our first release candidate and our second one that required us to do some 
unplanned upgrades, though we were hopeful that the impact would be limited for 
3.0 since Rails came out with a fix for their issue during that timeframe. We 
definitely want to hear from people if they are experiencing issues installing 
RC2.

Thanks for your help,
Christine


From: Cory Nimer mailto:cory_ni...@byu.edu>>
Sent: Friday, April 23, 2021 10:18 AM
To: Archivesspace Users Group 
(archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>)
 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>;
 Christine Di Bella 
mailto:christine.dibe...@lyrasis.org>>
Subject: RE: [Archivesspace_uac] release candidate available - ArchivesSpace 
v3.0.0-RC2


Christine,



When installing the release candidate our IT staff reports that they are 
encountering an error, as described below:



I'm trying to get archivesspace v 3.0.0-RC2 running on our staging server. 
Everything seemed to install ok, and the server seems to start up ok (based on 
the log output), but when I try to bring up the public or staff website I get 
an error. I'm wondering if you could post something on the listserv or point me 
in the right direction to do it.



I upgraded from v2.8.1 and followed the upgrade directions here: 
https://archivesspace.github.io/tech-docs/administration/upgrading.html



Here's the error I get when I try to bring up the staff website 
(https://asadminstg.lib.byu.edu<https://asadminstg.lib.byu.edu/>):



Internal Server Error (500)
Request Method: GET
Request URL: http://asadminstg.lib.byu.edu/
Could not find rubyntlm-0.6.3 in any of the sources from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:86:in
 `block in materialize' from org/jruby/RubyArray.java:2609:in `map!' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:80:in
 `materialize' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:170:in
 `specs' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:237:in
 `specs_for' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:226:in
 `requested_specs' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/runtime.rb:101:in
 `block in requested_specs' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/runtime.rb:20:in
 `setup' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler.rb:149:in
 `setup' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/setup.rb:20:in
 `block in ' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/ui/shell.rb:136:in
 `with_level' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/ui/shell.rb:88:in
 `silence' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/setup.rb:20:in
 `' from org/jruby/RubyKernel.java:974:in `require' from 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:130:in
 `require' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/data/tmp/jetty-0.0.0.0-10080-frontend.war-_-any-/webapp/WEB-INF/config/boot.rb:10:in
 `' from org/jruby/RubyKernel.java:974:in `require' from 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems

Re: [Archivesspace_Users_Group] [Archivesspace_uac] release candidate available - ArchivesSpace v3.0.0-RC2

[Cory Nimer]

Christine,

When installing the release candidate our IT staff reports that they are 
encountering an error, as described below:

I'm trying to get archivesspace v 3.0.0-RC2 running on our staging server. 
Everything seemed to install ok, and the server seems to start up ok (based on 
the log output), but when I try to bring up the public or staff website I get 
an error. I'm wondering if you could post something on the listserv or point me 
in the right direction to do it.

I upgraded from v2.8.1 and followed the upgrade directions here: 
https://archivesspace.github.io/tech-docs/administration/upgrading.html

Here's the error I get when I try to bring up the staff website 
(https://asadminstg.lib.byu.edu):

Internal Server Error (500)
Request Method: GET
Request URL: http://asadminstg.lib.byu.edu/
Could not find rubyntlm-0.6.3 in any of the sources from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:86:in
 `block in materialize' from org/jruby/RubyArray.java:2609:in `map!' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:80:in
 `materialize' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:170:in
 `specs' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:237:in
 `specs_for' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:226:in
 `requested_specs' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/runtime.rb:101:in
 `block in requested_specs' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/runtime.rb:20:in
 `setup' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler.rb:149:in
 `setup' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/setup.rb:20:in
 `block in ' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/ui/shell.rb:136:in
 `with_level' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/ui/shell.rb:88:in
 `silence' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/setup.rb:20:in
 `' from org/jruby/RubyKernel.java:974:in `require' from 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:130:in
 `require' from 
/srv/archivesspace-3.0.0-rc2/archivesspace/data/tmp/jetty-0.0.0.0-10080-frontend.war-_-any-/webapp/WEB-INF/config/boot.rb:10:in
 `' from org/jruby/RubyKernel.java:974:in `require' from 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:54:in
 `require' from uri:classloader:/jruby/rack/rails/environment3.rb:23:in 
`load_environment' from uri:classloader:/jruby/rack/rails_booter.rb:83:in 
`load_environment' from 

[Archivesspace_Users_Group] Request for input on visibility of digital content

[Cory Nimer]

Colleagues,

Working with representatives from Yale University and the Smithsonian 
Institution, we have been working to develop a draft specification for 
improving the visibility of linked digital content in the ArchivesSpace staff 
interface and public front-end. This has been added to JIRA as ANW-1209 
(https://archivesspace.atlassian.net/browse/ANW-1209), and the specification is 
available at 
https://docs.google.com/document/d/1-fi-1jpE7GqWc0zWxWsRO9zgRmR1vFFygp6jGnKh23k/edit?usp=sharing.

We are very interested in getting feedback from the community about recommended 
features. The specification document linked above is open for comments, or 
notes may be added to the JIRA ticket. We would ask that interested parties 
submit their comments by March 19, 2021.

Sincerely,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Database connection error in ArchivesSpace 2.8 PUI

[Cory Nimer]

Looking at the record, there are 604 top containers associated with the 
resource record. Overall, the collection has 632 top container records.

Cory

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Joshua 
D. Shaw
Sent: Wednesday, September 30, 2020 11:18 AM
To: Archivesspace Users Group (archivesspace_users_group@lyralists.lyrasis.org) 

Subject: Re: [Archivesspace_Users_Group] Database connection error in 
ArchivesSpace 2.8 PUI

Just a guess, but are there more than 1024 top containers that you are trying 
to retrieve? The maxBooleanClauses setting in 
https://github.com/archivesspace/archivesspace/blob/master/solr/solrconfig.xml#L69
 limits the max number of booleans to 1024.


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Cory Nimer mailto:cory_ni...@byu.edu>>
Sent: Wednesday, September 30, 2020 12:09 PM
To: Archivesspace Users Group 
(archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>)
 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Database connection error in ArchivesSpace 
2.8 PUI


Colleagues,



While testing ArchivesSpace 2.8, we have run into occasional problems loading 
some records in the PUI, receiving the message "Unable to Connect to Database". 
Looking at the log files, it reports that the Solr search failed, caused by 
"too many boolean clauses". A copy of the relevant portion of the log file is 
attached.



We had experienced similar issues in 2.5.1 as well, but hoped that this would 
be resolved by the 2.8 release. Reviewing GitHub, the only similar references 
that we found were pull requests 1155 
(https://github.com/archivesspace/archivesspace/pull/1155<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fpull%2F1155=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7Cb964b77d8c734c505dac08d8655b4804%7C995b093648d640e5a31ebf689ec9446f%7C0%7C1%7C637370790074461570=luMVoRgj245fXpohvHhuuUYglynRRPUIjaTG2pxqEqI%3D=0>)
 and 1257 
(https://github.com/archivesspace/archivesspace/issues/1257<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fissues%2F1257=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7Cb964b77d8c734c505dac08d8655b4804%7C995b093648d640e5a31ebf689ec9446f%7C0%7C1%7C637370790074471523=2%2BGYq9uEXpPP%2FtTLlhJ0zFhHlFxLKlYHPhj4sSQNxG4%3D=0>),
 though these were back in the 2.3.1 release.



Have others encountered similar issues, and if so how were they resolved?



Thank you for your help,



Cory Nimer

University Archivist

Brigham Young University

801-422-6091


___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] Conflict between inheritance rules and oai_dc response

[Cory Nimer]

Dear ArchivesSpace community,

In working toward a migration from AS 2.5.1 to 2.8, we have encountered an 
error in the OAI ListRecords response for metadata formats other than EAD 
(i.e., oai_dc, oai_dcterms, oai_marc, and oai_mods). When trying requests such 
as https://asoaistg.lib.byu.edu/oai?verb=ListRecords=oai_dc 
(sorry, not a public link), the response returned is:

{"error":"undefined method `[]' for nil:NilClass"}

Checking the log file, we found that it referenced a line in our configuration 
file dealing with element inheritance:

E, [2020-09-22T15:58:46.797712 #333] ERROR -- : Thread-2300: Unhandled 
exception!
E, [2020-09-22T15:58:46.807963 #333] ERROR -- :
undefined method `[]' for nil:NilClass
/srv/asstg/config/config.rb:491:in `block in (root)'
org/jruby/RubyArray.java:2566:in `select'
/srv/asstg/config/config.rb:491:in `block in (root)'
uri:classloader:/record_inheritance.rb:133:in `block in merge_record'
org/jruby/RubyArray.java:1735:in `each'
uri:classloader:/record_inheritance.rb:125:in `merge_record'
uri:classloader:/record_inheritance.rb:104:in `block in merge'
org/jruby/RubyArray.java:2487:in `map'
uri:classloader:/record_inheritance.rb:103:in `merge'
uri:classloader:/record_inheritance.rb:4:in `merge'

The portion of the configuration file referred to in the log file reads as 
follows:

{
:property => "subjects",
:inherit_if => proc {|json| json.select {|j| ! 
j['_resolved']['terms'].select { |t| t['term_type'] == 'genre_form'}.empty? } },
:inherit_directly => true
},
{
:property => 'subjects',
:skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
:inherit_if => proc {|json| json.select {|j| ! 
j['_resolved']['terms'].select { |t| t['term_type'] == 'topical'}.empty? } },
:inherit_directly => true
},
{
:property => 'subjects',
:skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
:inherit_if => proc {|json| json.select {|j| ! 
j['_resolved']['terms'].select { |t| t['term_type'] == 'geographic'}.empty? } },
:inherit_directly => true
},
{
:property => 'subjects',
:skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
:inherit_if => proc {|json| json.select {|j| ! 
j['_resolved']['terms'].select { |t| t['term_type'] == 'uniform_title'}.empty? 
} },
:inherit_directly => true
},

These inheritance configuration statements work well in our PUI display, but it 
appears to upset our ListRecords request. It does not cause issues with OAI 
GetRecord requests, which will produce the record in Dublin Core or MARC for 
Resource records without issues, but generates the same error for Archival 
Object records that would include inherited information.

Is this something that others have encountered? Reading the OAI-PMH 
documentation on GitHub, we had not expected this to be an issue.

Best,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] Technical Subcommittee on Encoded Archival Standards annual meeting

[Cory Nimer]

The Technical Subcommittee on Encoded Archival Standards is holding an open 
working meeting on Thursday, August 13, 2020 at 9 AM PDT / 10 AM MDT / 11 AM 
CDT / 12 PM EDT / 5 PM BST / 6 PM CEST/ 2 AM Friday AEST 
(https://sched.co/dQd6).

The meeting is open for all to attend, and will cover our new outreach work, 
the on-going revision of Encoded Archival Context--Corporate bodies, Persons, 
and Families (EAC-CPF), and an update on current Encoded Archival Description 
(EAD) work. We will provide updates on ongoing initiatives and will answer 
questions from attendees.

The agenda for the meeting is as follows:

  *   Welcome
  *   Administrative updates
  *   Standard models
  *   EAC-CPF revision updates
  *   Upcoming EAD revisions
  *   Outreach and communications

For security reasons, attendees must register in advance to attend. Please 
complete the SAA registration form at 
https://zoom.us/meeting/register/tJEsd-Cupz8pHdfjGcIf9XNholrPhQ9rogbB.

We look forward to sharing more about the current efforts of the subcommittee.
Cory Nimer
University Archivist
Brigham Young University
Provo, UT
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Extreme sluggishness with classifications

[Cory Nimer]

Olivia,

We had reported this problem back in release 1.5.4 
(https://archivesspace.atlassian.net/browse/ANW-652), and some work was done. 
However, performance did not improve significantly and we were forced to 
abandon classifications. We would have preferred to use classifications, 
though, and would love to hear about what others have done to deal with the 
slow load times.

Best,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Olivia S 
Solis
Sent: Thursday, April 2, 2020 1:03 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Extreme sluggishness with classifications

Hi all,

Has anyone else experienced extreme sluggishness with loading and displaying 
classifications/ classification terms? We are experiencing sometimes 
minutes-long lag time for search results, autocomplete functionality when you 
are trying add a classification/term in a resource or accession record, and in 
saving a new classifications/terms.

In our case, we are using classifications for 2 main buckets: collection 
strengths and subunits — administrative divisions or umbrella collections we 
have at the Briscoe Center. Each has about 15 children. Some of the children 
have a few hundred associated records. So two main tiers. The classifications 
and, one level down, their children.

[Screen Shot 2020-04-02 at 1.54.15 PM.png]

We are using version 2.4.1. Why might we be experiencing such sluggishness?

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
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] PUI inheritance configuration

[Cory Nimer]

Mark,

Thanks for your help with this--I will pass it along to our IT staff for 
update. Other than the examples in the configuration file, is there any public 
documentation of the full range of elements that can be included in the 
inheritance file?

Thanks again,

Cory

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Custer, 
Mark
Sent: Friday, February 21, 2020 2:13 PM
To: James Bullen ; Archivesspace Users Group 

Subject: Re: [Archivesspace_Users_Group] PUI inheritance configuration

Cory,

I just tested this out with a new build of ASpace, since I knew this worked 
before!  At first I didn't get it to work either, but that was because I just 
copied over one of your examples as is.  When I looked at the ASpace JSON 
records, though, I realized that your genreform example just needed to be 
changed slightly so that the type match was looking for "genre_form" instead, 
i.e.:

{
  :property => "subjects",
  :inherit_if => proc {|json| json.select {|j| ! 
j['_resolved']['terms'].select { |t| t['term_type'] == 'genre_form'}.empty? } },
  :inherit_directly => true
}

I didn't test any of the other mappings (or the "skip_if" parameters), so I 
can't say if all of those term types are accurate or not, but I definitely got 
this one to inherit once I added the underscore to the term type.

I hope that helps,

Mark





From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of James Bullen mailto:ja...@hudmol.com>>
Sent: Wednesday, February 19, 2020 10:14 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] PUI inheritance configuration


Hi Cory,

It's been some years since this was in my head, but it looks good.

The :inherit_if on the first rule should be selecting all subjects that have at 
least one term with a 'genreform' type.


Cheers,
James



On Feb 20, 2020, at 1:37 AM, Cory Nimer 
mailto:cory_ni...@byu.edu>> wrote:

James,

To my knowledge, a complete reindex was done following the changes (other 
changes in note inheritance did appear as anticipated). However, the subject 
inheritance did not seem to work. Are the inheritance statements below 
structured correctly, or are there other reasons that these elements would not 
be visible in the interface?

Best,

Cory

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of James Bullen
Sent: Tuesday, February 18, 2020 6:49 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] PUI inheritance configuration


Hi Cory,

Have you reindexed?

The PUI runs exclusively from the PUI index so these changes won't take effect 
until the relevant records have been reindexed.


Cheers,
James


On Feb 19, 2020, at 2:26 AM, Cory Nimer 
mailto:cory_ni...@byu.edu>> wrote:

We are continuing to tweak our PUI configuration, and are interested in testing 
inclusion of subject terms. Based on the configuration template, our IT staff 
have attempted to add the code below but it does not appear to be working after 
a restart and reindex:

{
  :property => 'subjects',
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'genreform'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'topical'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'title'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'geogname'}.empty? } },
  :inherit_directly => true
},

Has anyone else successfully included subject terms in their PUI inheritance 
configuration, or have suggestions for what might be wrong? We are currently 
running version 2.5.1.

Thanks,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org<

Re: [Archivesspace_Users_Group] PUI inheritance configuration

[Cory Nimer]

James,

To my knowledge, a complete reindex was done following the changes (other 
changes in note inheritance did appear as anticipated). However, the subject 
inheritance did not seem to work. Are the inheritance statements below 
structured correctly, or are there other reasons that these elements would not 
be visible in the interface?

Best,

Cory

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of James 
Bullen
Sent: Tuesday, February 18, 2020 6:49 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] PUI inheritance configuration


Hi Cory,

Have you reindexed?

The PUI runs exclusively from the PUI index so these changes won’t take effect 
until the relevant records have been reindexed.


Cheers,
James



On Feb 19, 2020, at 2:26 AM, Cory Nimer 
mailto:cory_ni...@byu.edu>> wrote:

We are continuing to tweak our PUI configuration, and are interested in testing 
inclusion of subject terms. Based on the configuration template, our IT staff 
have attempted to add the code below but it does not appear to be working after 
a restart and reindex:

{
  :property => 'subjects',
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'genreform'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'topical'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'title'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'geogname'}.empty? } },
  :inherit_directly => true
},

Has anyone else successfully included subject terms in their PUI inheritance 
configuration, or have suggestions for what might be wrong? We are currently 
running version 2.5.1.

Thanks,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

!DSPAM:5e4c053f111932459259872! ___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org<mailto:Archivesspace_Users_Group@lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group


!DSPAM:5e4c053f111932459259872!

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] PUI inheritance configuration

[Cory Nimer]

We are continuing to tweak our PUI configuration, and are interested in testing 
inclusion of subject terms. Based on the configuration template, our IT staff 
have attempted to add the code below but it does not appear to be working after 
a restart and reindex:

{
  :property => 'subjects',
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'genreform'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'topical'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'title'}.empty? } },
  :inherit_directly => true
},
{
  :property => 'subjects',
  :skip_if => proc {|json| ['file', 'item'].include?(json['level']) },
  :inherit_if => proc {|json| json.select {|j| ! j['_resolved']['terms'].select 
{ |t| t['term_type'] == 'geogname'}.empty? } },
  :inherit_directly => true
},

Has anyone else successfully included subject terms in their PUI inheritance 
configuration, or have suggestions for what might be wrong? We are currently 
running version 2.5.1.

Thanks,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Adding identifiers to resource trees and record entries in assessments

[Cory Nimer]

Nick,

It appears that the second of your requests below was previously proposed as 
part of ANW-780 (https://archivesspace.atlassian.net/browse/ANW-780). The 
comments there suggest that there is some interest in replacing the Instance 
Type in the resource tree with the component unique identifier (CUI), but the 
Development Prioritization Team felt the data being recorded in the CUI field 
was not consistent enough yet to merit a change in the base code. However, the 
ticket does include a link to a plug-in from the University of Denver that 
appears to replace the instance number column in the resource tree with the 
CUI--if that would meet your need.

Best,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Nick 
Butler
Sent: Thursday, June 27, 2019 9:21 AM
To: archivesspace_users_group@lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Adding identifiers to resource trees and 
record entries in assessments

Good afternoon,

Our archivists are wondering if it's possible to add record identifiers to the 
following areas:

* The record(s) in Assessments (i.e. each entry in div class="input-group 
linker-wrapper multiplicity-many sortable" in the edit or new Assessments 
screen). Currently it just has the object title, we'd like it to have the 
identifier concatenated too.
* The entries in resource trees (i.e. each entry in div 
class="largetree-container ui-resizable" in the edit Resources screen). Again 
it currently only has the object title (or display_string, for archival 
objects).

Might anyone know if there's any way to achieve this with a plugin? Has anyone 
done something like this before?

Many thanks for any suggestions!

Best wishes,
Nick

--
Nick Butler
Software Developer
Digital Services
Cambridge University Library
West Road
Cambridge CB3 9DR, UK

np...@cam.ac.uk<mailto:np...@cam.ac.uk>

Internal tel: 33067
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] Call for community input--Proposal for controlled value list enhancement

[Cory Nimer]

ArchivesSpace community members,

The Development Prioritization Team has requested public comment on a 
specification for a proposed expansion of ArchivesSpace's controlled value 
lists to include URI values. The addition of these values would enhance EAD3 
and EAC-CPF exports, and improve compatibility with linked data formats. The 
draft specification is available at 
https://docs.google.com/document/d/1plu1M-hBT9Q0YfKwwi7i8KhU-iLqhE_G8PpMeaVy1Uo/edit?usp=sharing,
 and open for commenting.

We would be interested in gathering comments and finalizing the document to 
facilitate the Development Prioritization Team's review. If you could please 
add comments by June 21, 2019, that would be very helpful. Any questions can 
also be send to me directly at cory_ni...@byu.edu<mailto:cory_ni...@byu.edu>.

Sincerely,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] External identifiers in agents

[Cory Nimer]

?Patrick,


According to the development roadmap published last month, the Agents updates 
are scheduled to be completed by June--though perhaps someone from the program 
staff could say where that work is at currently. As for ANW-355, I don't think 
it has been prioritized yet.


Cory


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Galligan, Patrick 
Sent: Wednesday, April 10, 2019 1:29 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] External identifiers in agents

Corey,

Looks like the record ids in the model have basically the same model as 
external ids. Do you know if there's a timeline for this development?

-Patrick

From:  on behalf of 
Cory Nimer 
Reply-To: Archivesspace Users Group 

Date: Wednesday, April 10, 2019 at 3:16 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] External identifiers in agents


Patrick,



The upcoming Agents module revision 
(https://archivesspace.atlassian.net/browse/ANW-429) includes an Alternative 
Set section that allow links to other authority records, which might be useful 
when it is finished. If you are just interested in a simple link, though, the 
External Documents section does allow recording a link that is currently 
available in the PUI display. Do either of these approaches meet your need, or 
what else might be needed?



When you mentioned that there is a place for recording external identifiers for 
terms, was this in the Subjects module? There is a pending ticket to allow URIs 
to be recorded for controlled terms 
(https://archivesspace.atlassian.net/browse/ANW-355?), but I hadn't heard that 
there had been any progress in this area.



Best,



Cory Nimer

University Archivist

Brigham Young University

801-422-6091


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Galligan, Patrick 
Sent: Wednesday, April 10, 2019 8:28 AM
To: Archivesspace Users Group
Subject: [Archivesspace_Users_Group] External identifiers in agents

Hey all,

We were just looking at the models in AS and noticed that the backend models 
for Terms, Resources, Objects, etc. supported external identifiers (even if the 
GUI doesn't), and we found it kind of weird that the Agents module doesn't.

We'd love to have the ability to link out to a DBPedia or Wikidata entry for an 
agent without having to add an extraneous Name Form and Source just for that 
information. It doesn't feel like a good way to go about doing that. Can anyone 
foresee any issues with something like this? Would you be in support of this 
being added to the Agents model? It appears to be a fairly easy change, even if 
it is a database change.

Thoughts?

-Patrick

--
Patrick Galligan
Digital Archivist
Rockefeller Archive Center
(914) 366-6386
He/Him/His
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] External identifiers in agents

[Cory Nimer]

Patrick,


The upcoming Agents module revision 
(https://archivesspace.atlassian.net/browse/ANW-429) includes an Alternative 
Set section that allow links to other authority records, which might be useful 
when it is finished. If you are just interested in a simple link, though, the 
External Documents section does allow recording a link that is currently 
available in the PUI display. Do either of these approaches meet your need, or 
what else might be needed?


When you mentioned that there is a place for recording external identifiers for 
terms, was this in the Subjects module? There is a pending ticket to allow URIs 
to be recorded for controlled terms 
(https://archivesspace.atlassian.net/browse/ANW-355?), but I hadn't heard that 
there had been any progress in this area.


Best,


Cory Nimer

University Archivist

Brigham Young University

801-422-6091


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Galligan, Patrick 
Sent: Wednesday, April 10, 2019 8:28 AM
To: Archivesspace Users Group
Subject: [Archivesspace_Users_Group] External identifiers in agents

Hey all,

We were just looking at the models in AS and noticed that the backend models 
for Terms, Resources, Objects, etc. supported external identifiers (even if the 
GUI doesn't), and we found it kind of weird that the Agents module doesn't.

We'd love to have the ability to link out to a DBPedia or Wikidata entry for an 
agent without having to add an extraneous Name Form and Source just for that 
information. It doesn't feel like a good way to go about doing that. Can anyone 
foresee any issues with something like this? Would you be in support of this 
being added to the Agents model? It appears to be a fairly easy change, even if 
it is a database change.

Thoughts?

-Patrick

--
Patrick Galligan
Digital Archivist
Rockefeller Archive Center
(914) 366-6386
He/Him/His
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Discontinuing use of "levels of description" labels?

[Cory Nimer]

Jordon,


Another case similar to Steve's Aeon example is that the level value can be 
used in establishing inheritance rules for element display. If you are using 
the PUI, you can limit the inheritance of specific elements to prevent them 
from being included in archival object displays based on their level of 
description value. An example of this is provided at the end of the record 
inheritance section of the configuration documentation 
(http://archivesspace.github.io/archivesspace/user/configuring-archivesspace/?).


Best,


Cory Nimer

University Archivist

Brigham Young University

801-422-6091



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Majewski, Steven Dennis (sdm7g) 
Sent: Friday, March 8, 2019 12:51 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Discontinuing use of "levels of 
description" labels?

In EAD, the hierarchy is fixed, but one of the advantages of linked data is 
that the elements are movable and reusable in other contexts. We're not really 
taking advantage of that currently in ArchivesSpace, but for the future I think 
it makes sense to think about those use cases and whether level-of-description 
might be useful if the archival object is removed from its context.  ( For 
example, organizing artificial or virtual collections from subsets or multiple 
archival collections for exhibits or other display purposes - whether that's 
done in ArchivesSpace or by another tool importing info from ArchivesSpace. )

I will also note that we are currently integrating Aeon with ArchivesSpace - 
currently in testing and not yet in production here, so we don't have a lot of 
experience yet, but I think it may be useful to have level-of-description 
included in those requests (another instance where you are seeing the info 
removed from it's context) and we are considering filtering request so that 
only the lowest level items are units that can be requested ( although this can 
be perhaps better implemented just by looking at whether the item has children. 
)


- Steve.


On Mar 8, 2019, at 2:29 PM, Jordon Steele 
mailto:jste...@jhu.edu>> wrote:

Hi all,

This is more of an archival description question, but I'm not a member of that 
listserv, so I figured it would be easier to ping some of you about this for 
advice since I wager there's a lot of overlap.

We have not-infrequent discussions around here about what "level of 
description" label to assign to an archival component at a given level, i.e. 
collection, series, file, item, etc. But because our data is already structured 
in hierarchical relationships via EAD/JSON, there's no real need to "tell the 
computer" what level this is since these labels aren't the way computers 
understand context and hierarchy, the nesting of data is.

Once I realized this, I often made the case that these level-of-description 
labels are useful for stylesheets, i.e. tell a stylesheet with level=series to 
make it all caps and bold, level=file should be red, etc. But the ASpace PUI 
doesn't/doesn't need to style levels in this manner for the hierarchy to be 
easily understood.

So we're considering discontinuing use of the "level of description" field in 
ASpace. But am I missing an important value of this field? Thanks!

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
jste...@jhu.edu<mailto:jste...@jhu.edu>
410-516-5493
he/him/his

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org<mailto:Archivesspace_Users_Group@lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Cory Nimer]

Linda,

We are still working on our PUI implementation locally, but I believe it should 
be possible to set your ArchivesSpace configuration options to display a 
composite identifier rather than just the immediate CUI level/value. This would 
prevent having to reenter data for each component, while providing a public 
view of the whole string. With the composite identifier option enabled, rather 
than displaying "Item 1" in the linked example, it should appear as "2012-07-0 
Series 1 Sub-Series 1 Item 1" at that item level. The delimiter between the 
different levels' CUIs and the optional inclusion of the level of description 
is also configurable. Instructions are available in the roll-out documentation 
at 
https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/103209762/Public+Interface+Documentation+for+staff#PublicInterfaceDocumentation(forstaff)-CompositeIdentifierInheritance,
 and in the configuration documentation 
(http://archivesspace.github.io/archivesspace/user/configuring-archivesspace/).

Information on the duplication of the level of description and the CUI value 
from the top container feature's development is available on the Yale 
ArchivesSpace guide 
(https://guides.library.yale.edu/archivesspace/ASpaceContainerManagement, at 
the bottom of the page). Their recommendation at the time seemed to be to 
remove the level information from your CUI value. Perhaps someone from Yale or 
elsewhere could weigh in about your options regarding this functionality.

Thanks,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Linda Hocking
Sent: Thursday, September 20, 2018 12:06 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions


Maggie-



This is what I see when looking at a finding aid in the public interface after 
having selected a particular item from the pull down "Collection Organization" 
list-


Balance book, 1795-1796
Item 1
Item   Identifier: Item 1
Litchfield Historical Society  Elijah Boardman Papers  Elijah Boardman Business 
Papers, 1794-1824  Balance books Balance book, 1795-1796


Here's the link if you want to look at it- 
http://archives.litchfieldhistoricalsociety.org:8081/repositories/2/archival_objects/14454
So I can tell that it's Item 1, and if I clicked up to "Elijah Boardman 
Business Papers" it would show me the series number, but it won't show them 
together. I'm wary of manually entering the whole string in the CUI, but maybe 
that's the only way to get it to display. On the other hand, if I do that, and 
the system is changed to show the whole hierarchy, it will be redundant.

Anyway, for us, this is an issue of having to go through multiple steps to 
figure out where something is within the order of the collection more so than 
anything to do with the search.

Thanks,
Linda

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Hughes, Margaret 
mailto:mhug...@library.ucla.edu>>
Sent: Thursday, September 20, 2018 12:54 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions


Larry-Thank you for sharing how you're (not) working with the CUI. Regarding 
the other ASpace example for the field,  accession number, we also track that 
information via linked accessions or an Immediate Source of Acquisition note.



Linda and Neal - I'm glad you brought up the PUI as that's not something we're 
using right now, and so I wasn't familiar with how the CUI is utilized in the 
PUI. Do I understand correctly that not being able to see where an archival 
object belongs in the overall hierarchy is only an issue when discovering 
archival objects (files, items, etc) via search? And this is because the CUI 
does not display in the PUI at all currently?



Lydia-I agree that a JIRA ticket about this issue is needed. I would also 
support having the CUI default to a public audience, have it appear before the 
, and not be visually associated with a top container.  Could it 
continue to be located in the same place as it is now in the staff interface's 
edit mode? And we could make the CUI visible in the same place in the staff 
interface in view mode, as well?  I agree with the reasons you stated (working 
filing system, file id, etc) that the CUI should be a free-text field which 
*wouldn't* autopopulate the level of description.



Maggie



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf

[Archivesspace_Users_Group] Request for comments: Language entry revisions

[Cory Nimer]

Colleagues,


In reviewing a series of bug reports and feature requests related to language 
entry in ArchivesSpace, the Development Prioritization Team has developed a 
comprehensive specification for potential updates to this functionality within 
the application. This document is available at 
https://docs.google.com/document/d/17arZyO-APS4o5RznSO251Bql4sPDW7Kg_BddkTZDJCs/edit?usp=sharing.
 Open issues addressed in the  specification include:


  *
?ANW-144: MarcXML export is generating duplicate 040 field 
(https://archivesspace.atlassian.net/browse/ANW-144)
  *
ANW-382: As an archivist, I would like to record finding aid Language of 
Description using controlled values 
(https://archivesspace.atlassian.net/browse/ANW-382)
  *
ANW-697: As an archivist, I would like to record multiple Language entries 
using controlled terms (https://archivesspace.atlassian.net/browse/ANW-697)

Comments related to the specification can be submitted through the Google Doc, 
or using the comment feature in the tickets in JIRA. Interested parties should 
also consider becoming a Watcher of the above issues. Questions about the 
specification document can also be directed to Cory Nimer 
(cory_ni...@byu.edu?<mailto:cory_ni...@byu.edu>).

We would request that comments be submitted by May 31, 2018.

Thank you,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Problem with Classifications: searching/adding to records

[Cory Nimer]

Carrie,

We are currently looking at transitioning away from repositories in 
ArchivesSpace, and using classifications in a similar manner to what you 
described. In testing this, however, we are seeing similar delays in loading 
times in our 1.5.4 installation.

I recently reported this as a bug in JIRA 
(https://archivesspace.atlassian.net/projects/ANW/issues/ANW-652), but wondered 
if you were ever able to get this addressed or resolved?

Best,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
carrie.dani...@louisville.edu
Sent: Monday, July 17, 2017 7:27 AM
To: Archivesspace_Users_Group@lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Problem with Classifications: 
searching/adding to records

We have been having a problem with Classifications for quite some time - we are 
currently in version 1.5.2, but I think the issue actually predates our move to 
1.5.2 and it's just finally gotten exasperating. And we did some testing on 
2.1.0-RC1, and it persists.

In our workflow, every Accession and Resource record is assigned a 
Classification. When adding a Classification to the Accession/Resource record, 
AS takes a long time to search/find Classifications, particularly the one with 
(by far) the most records associated with it (about 3300). Saving is also very 
slow (slow enough that the browser can tell us as the percentage uploaded 
increases). We've monitored the system while going through these processes, and 
Java is working overtime during the search process.

Has anyone else seen this? And/or have ideas as to how we can fix it?

Thanks!
Carrie

Carrie Daniels
University Archivist and
Director, Archives and Special Collections
University of Louisville

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group