We are migrating location data from legacy systems to ArchivesSpace and creating location records in the process.

We’re also implementing AS on a large scale - bringing data together for Cambridge University Library and 29 other local repositories.

In reviewing the migration of location information and planning ahead for location management it seems to us that it would be incredibly helpful if it were not possible to create duplicate location records in AS (as suggested in the spec here: https://archivesspace.org/wp-content/uploads/2017/01/Location-Specification-ReviewedVersion-20110911-acceptedchanges.pdf).

It would also be very helpful if location records for one repository were not visible to users working in other repositories.

This ticket was reviewed by the Usability Team- it was decided to move ahead with proposing a warning for duplicate Top Containers, and leave the other two types of records as is. New ticket is being created for Top Containers only.

Agree that it would be helpful to be given a warning prior to creating duplicate Top Containers attached to the same resource or accession record. Container type and indicator fields would have to match for top containers to be considered duplicates. I can see some scenarios where container numbering may be intentionally duplicated (restarting numbering at the start of each new series, restarting numbering based on container type), though generally I agree that institutions would want to move away from such practices, and I don’t anticipate them being widespread enough to require us to involve the Container Profile field as well for a match.

For Location Profiles, there is currently a hard stop when creating Location Profile names that are not unique. I think this would be sufficient.

For Container Profiles, there is also currently a hard stop when creating Container Profile names that are not unique. I think this would be sufficient, as beyond that it seems like it would become messy to try and determine what a valid duplicate is (for example, two different container profiles with the same dimensions (maybe one is a clamshell box and the other has a lid).

Sorry for lengthy comment but it crosses several tickets I think are related @Lydia Tang your last comment about creating multiple profiles to resolve orientation issue, relates to https://archivesspace.atlassian.net/browse/ANW-882 My comment to that is that there could be cases where the container is moved to a different location requiring the orientation to be changed, that would be tedious to have to select a new container profile rather than be able to simply change the orientation of the current container. Basically, extent should be tied to the top container record, not to the container profile. That would also reduce the number of profiles one must create because in theory you would have to create many different profiles per container depending upon how you “might” orient it, granted there are most likely only 2 but one never knows. Also, I think it may become very confusing to know which profiles already have a profile per their orientation options. But this brings up the issue of the fields in Profiles as well, which is addressed in https://archivesspace.atlassian.net/browse/ANW-878?jql=text%20~%20%22container%20profile%22%20order%20by%20created%20DESC And the information needs to be broken out into more than an added notes field. Something that can be filtered or faceted. BY adding more fields, this could assist on this ticket as well https://archivesspace.atlassian.net/browse/ANW-945?jql=text%20~%20%22top%20container%22%20order%20by%20created%20DESC And allow institutions to standardize this data.

Thanks for asking for clarification, Christine! These are just my person opinions--

A duplicate top container has exactly the same container type and indicator (box 1, for example). Note that some legacy practices might do a Series 1 Box 1 and Series 2 Box 2, but from personal experience I think this is not a good idea. But because of this practice it might be nice to have this be more of an alert that could be turned off than a hard stop prevention.

Location profiles (sorry, that wasn’t clear in the ticket): I don’t currently use locations very much, so I would recommend a literal duplication of all fields. Building, Floor, Room, Area, etc. This would just be to avoid obviously creating duplicate profiles, but I would want to make sure that we don’t flag false positives accidentally (Building A Floor B would not be a duplicate of Building A [by itself] or Building A Floor B Room C). Does this make sense?

Container profiles: It would need to be an exact match for each of the fields of Depth Height and Width. I thought about if it should be an exact match interchangeably within these three fields but wondered whether a repository would want to create multiple profiles depending on the orientation of the box for an accurate linear foot count.