[Archivesspace_Users_Group] reordering from merge

Wed Mar 11 08:59:39 EDT 2015

In case this provides any additional insight into the reordering problem, here’s a new one we’ve been seeing the past few weeks (this is after entering the components individually, closing the record, and reopening later to add more components; also: this is a resource where numerical sequence of boxes/folders is equivalent to intellectual order and should thus be maintained):

[cid:image001.png at 01D05BD9.22A2F480]

Further down in the same resource record, we now have this:

[cid:image002.png at 01D05BD9.22A2F480]

Cate

[The Ohio State University]
Cate Putirskis Special Collections Processing Coordinator
University Libraries – Special Collections Description & Access
016 Thompson Library | 1858 Neil Ave Mall, Columbus, OH 43210
614-292-8114
putirskis.1 at osu.edu<mailto:putirskis.1 at osu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Tuesday, March 10, 2015 5:46 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] reordering from merge

Component soup does not sound very appetizing, I must admit ☺

We have yet to go live with ArchivesSpace as a staff tool, but we will do so within the next couple of months.  I definitely want to ensure that components cannot reorder at the system’s whim before we make the switch…   and thanks to all the first adopters who have been discovering and reporting these and other issues!!!!

So, two questions:

1.       Can someone explain exactly how the system assigns and retains sibling order?  In the AT, this was pretty simple:  resource components, notes, etc., basically just had a “sequenceNumber” data attribute as part of their database table.  You move a component/note/etc., then the sequence numbers change (I’m sure that I’m over simplifying the process, but that seemed to be the gist of it).  In ArchivesSpace, I see that “sequence values” are assigned to components or resources that have children.  After a few double takes, it looks to me like this value is really just a count of the number of children that a node has (if so, and I can’t think what else these numbers correspond to, then being labelled sequence.value seems very confusing to me).  It also looks like the sibling-order sequence number of an object is assigned in the archival_object table (archival_object.position), similar to how they AT did this.  If both of these things are correct, I’m still left wondering how things are getting out of order.  I suppose that only the affected archival_object.position values are being updated during this process, so perhaps the logic isn’t holding for all of the different possibilities of movement (like when two different resources are combined)?

2.       Are the re-ordering issues primarily worked out, aside from the record merging process that was highlighted in this thread?  If not, can someone let me know what needs to be tested?  I’d be happy to throw a bunch of data and scenarios at this, but I’m unsure where to start since I don’t know what’s been fixed.

Mark

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 Lora Davis
Sent: Monday, March 09, 2015 7:02 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] reordering from merge

No advice to offer, but to express a simple "you are not alone."

I've recently begun doing the same - merging detailed collection-level records created during a collection inventory with existing container lists ead-ified from Excel thanks to the new ASpace-friendly update to Steady.  The first (small) collection merged beautifully with all components remaining in desired order; following the exact same procedures a second, much larger (of course!) collection came out as what I've taken to lovingly calling "component soup."

I've stopped with this work for the time-being in the hopes that the upcoming patch might help.  Fingers firmly crossed.

Lora

On Mon, Mar 9, 2015 at 1:46 PM, MATTHEW R FRANCIS <mrf22 at psu.edu<mailto:mrf22 at psu.edu>> wrote:
All,

I recently encountered a "new for us" reordering problem while working in ASpace v.1.1.2.

This time the reordering occurred when you used the merge function to merge together two resources records (was attempting to merge a resource record with an inventory and minimum collection level data into a resource record with rich collection level inventory but no inventory) .  Once the merge was complete the series were reordered in a random fashion (e.g. it went series 9, 11, 2, 1, 6, etc.), but the original order for all the archival objects under each series was maintained.

Not sure if anyone else has encountered this issue, but thought it was worth reporting.

-Matt

Matt Francis
Archivist for Collection Management
Special Collections Library
Penn State University

Twitter: @archivingmatt
http://www.archivingmatt.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.archivingmatt.com&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=6hNqwZmB-Q8h8boOYZLr9JSxpMg4Hs80mHn92ipNN44&s=KrZ44Q94LxZpIi6qS1WXzD7JnE_nvU6jx9N0vlsmbhU&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=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=6hNqwZmB-Q8h8boOYZLr9JSxpMg4Hs80mHn92ipNN44&s=3_ShDMWTJGI6imLVCz0dHaWJ45TPpUAUdIvna1x8ugw&e=>

--
Lora J. Davis
Collections Archivist
Colgate University Libraries
13 Oak Drive
Hamilton, NY 13346
Tel:  (315) 228-6376
Fax: (315) 228-7934
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20150311/cc459861/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 135387 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20150311/cc459861/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 111309 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20150311/cc459861/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3605 bytes
Desc: image003.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20150311/cc459861/attachment-0002.png>