<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">AH! Thanks <div class="">I hadn’t needed to drill down to deeper levels on what I was initially using this endpoint for, so I didn’t catch onto the use of /tree/node?node_uri= </div><div class="">Sounds right! </div><div class=""><br class=""></div><div class="">— Steve. </div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 23, 2019, at 2:22 PM, Trevor Thornton <<a href="mailto:trthorn2@ncsu.edu" class="">trthorn2@ncsu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="">First of all, great documentation (in the code, API documentation less so but we're working on that) 👍</div><div class=""><br class=""></div><div class="">To close the loop on this thread (for anyone still interested):</div>For what I'm doing I need the container info, which is included in the .../tree/... responses. Basically I'm re-creating a version of the AS resource tree to provide a browsable view of a resource hierarchy in another application. So the process will be something like this (for a resource with URI <b class="">/repositories/1/resources/123):</b><div class=""><ol class=""><li class="">Call <b class=""> /repositories/1/resources/123/tree/root</b> to get the resource-level data and its children (up to 200)</li><li class="">If the value for "waypoints" in the response is greater than 1, call <b class="">/repositories/1/resources/123/tree/waypoints&offset=n</b> for each additional waypoint (n = 1 through # of waypoints - 1) to get the rest of the children</li><li class="">Then for each child record with other children, I'll provide a link to see the next level, which will call<b class=""> /repositories/1/resources/123/tree/node&node_uri=[URI OF THE RECORD THAT WAS CLICKED]<br class=""></b><i class="">(NOTE: node_uri is a required parameter for this endpoint but that's not mentioned in API the documentation)</i><br class="">This provides a response similar to the <b class="">.../tree/root</b> endpoint but with data for the archival object record instead of the resource</li><li class="">Repeat step 2 if there is more than one waypoint at this level, including the current node URI as <b class="">parent_id</b> in the GET params</li><li class="">Repeat steps 3 & 4 until you get to the end</li></ol></div><div class="">I *think* this is close to right.</div><div class=""><br class=""></div><div class="">Thanks again for your help!</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019 at 12:51 PM Majewski, Steven Dennis (sdm7g) <<a href="mailto:sdm7g@virginia.edu" class="">sdm7g@virginia.edu</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div class=""><br class=""></div>I believe for the next level of archival_objects, you have to get /repositories/$REPO/archival_objects/$ID/children , but check the API docs.<div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Note that there is also a GET /repositories/$REPO/resources/$ID/ordered_records method that gives you the whole hierarchy, but minimal info about each resource: { ref: display_string:, depth:, level: } <br class=""><div class=""><br class=""></div><div class="">I don’t think I knew about that one the first time I was wrestling with this sort of task. </div><div class="">If you’re doing backend API and not worried about real time display update, it might make more sense to walk the output ordered_records </div><div class="">If you want more complete info on resource children. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">— Steve. </div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 23, 2019, at 12:11 PM, Trevor Thornton <<a href="mailto:trthorn2@ncsu.edu" target="_blank" class="">trthorn2@ncsu.edu</a>> wrote:</div><br class="gmail-m_3137259269223112502Apple-interchange-newline"><div class=""><div dir="ltr" class="">Just found that file in the repo before I saw your message and I think I understand now - thanks!<div class=""><br class=""></div><div class="">So, if you're looking at a node below the root (an ArchivalObject) that has >200 children, you would hit the ".../tree/waypoint" endpoint however many times and include "parent_node" in the GET params with the ArchivalObject URI, right?</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019 at 11:57 AM Majewski, Steven Dennis (sdm7g) <<a href="mailto:sdm7g@virginia.edu" target="_blank" class="">sdm7g@virginia.edu</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">So the next question is how do you make the subsequent calls to retrieve the next 200, etc.?</div></div></div></div></blockquote></div><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div></div></div></div></div><div class=""><br class=""></div>You call /repositories/$repo/resources/$id/tree/waypoint?offset=$N 23 times. <div class="">( You already got the first batch in .precomputed_waypoints in the call to /ress/root ) </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I found the documentation note in the source I was looking for: </div><div class=""><a href="https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/large_tree.rb" target="_blank" class="">https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/large_tree.rb</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># What's the big idea?</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># ArchivesSpace has some big trees in it, and sometimes they look a lot like big</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># sticks. Back in the dark ages, we used JSTree for our trees, which in general</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># is perfectly cromulent. We recognized the risk of having some very large</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># collections, so dutifully configured JSTree to lazily load subtrees as the</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># user expanded them (avoiding having to load the full tree into memory right</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># away).</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># However, time makes fools of us all. The JSTree approach works fine if your</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># tree is fairly well balanced, but that's not what things look like in the real</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># world. Some trees have a single root node and tens of thousands of records</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># directly underneath it. Lazy loading at the subtree level doesn't save you</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># here: as soon as you expand that (single) node, you're toast.</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># This "large tree" business is a way around all of this. It's effectively a</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># hybrid of trees and pagination, except we call the pages "waypoints" for</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># reasons known only to me. So here's the big idea:</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># * You want to show a tree. You ask the API to give you the root node.</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># * The root node tells you whether or not it has children, how many children,</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># and how many waypoints that works out to.</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># * Each waypoint is a fixed-size page of nodes. If the waypoint size is set</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># to 200, a node with 1,000 children would have 5 waypoints underneath it.</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># * So, to display the records underneath the root node, you fetch the root</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># node, then fetch the first waypoint to get the first N nodes. If you need</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># to show more nodes (i.e. if the user has scrolled down), you fetch the</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># second waypoint, and so on.</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># * The records underneath the root might have their own children, and they'll</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># have their own waypoints that you can fetch in the same way. It's nodes,</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># waypoints and turtles the whole way down.</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># All of this interacts with the largetree.js code in the staff and public</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># interfaces. You open a resource record, and largetree.js fetches the root</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># node and inserts placeholders for each waypoint underneath it. As the user</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># scrolls towards a placeholder, the code starts building tracks ahead of the</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># train, fetching that waypoint and rendering the records it contains. When a</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># user expands a node to view its children, that process repeats again (the node</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># is fetched, waypoint placeholders inserted, etc.).</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">#</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># The public interface runs the same code as the staff interface, but with a</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># small twist: it fetches its nodes and waypoints from Solr, rather than from</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># the live API. We hit the API endpoints at indexing time and store them as</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># Solr documents, effectively precomputing all of the bits of data we need when</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""># displaying trees.</span></div><div style="margin:0px;font-stretch:normal;font-size:16px;line-height:normal;font-family:Menlo;min-height:19px" class=""><span style="font-variant-ligatures:no-common-ligatures" class=""></span><br class=""></div><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 23, 2019, at 11:08 AM, Trevor Thornton <<a href="mailto:trthorn2@ncsu.edu" target="_blank" class="">trthorn2@ncsu.edu</a>> wrote:</div><br class="gmail-m_3137259269223112502gmail-m_7888520866059867121Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks, Steve. That makes sense, and I tested with a resource with >1000 top level children and I see that only 200 of them are included, which corresponds to the value for "waypoint_size" in the response:<div class=""><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="courier new, monospace" class="">{ <br class=""></font><font face="courier new, monospace" class=""> "child_count":4780,<br class=""></font><font face="courier new, monospace" class=""> "waypoints":24,<br class=""></font><font face="courier new, monospace" class=""> "waypoint_size":200<br class=""></font><font face="courier new, monospace" class="">...</font></blockquote><div class=""><div class=""><br class=""></div><div class="">So the next question is how do you make the subsequent calls to retrieve the next 200, etc.?</div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019 at 10:52 AM Majewski, Steven Dennis (sdm7g) <<a href="mailto:sdm7g@virginia.edu" target="_blank" class="">sdm7g@virginia.edu</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">I believe the rationale of the waypoints was that initially, it was expected that resource children/ archival objects would fall into a more balanced tree structure, but it turned out that there were many flat hierarchies with hundreds of top level children, and getting all of the children at once was not working very efficiently. So with they waypoint calls, you may only be getting some of the children, but the display can start populating the tree display while making additional calls for the rest. <div class=""><br class=""></div><div class="">I may have some postman examples and internal notes around somewhere: I’ll see what I can dig out. </div><div class=""><br class=""></div><div class="">— Steve. </div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 23, 2019, at 9:05 AM, Trevor Thornton <<a href="mailto:trthorn2@ncsu.edu" target="_blank" class="">trthorn2@ncsu.edu</a>> wrote:</div><br class="gmail-m_3137259269223112502gmail-m_7888520866059867121gmail-m_1019186690443663652Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi everybody-<div class=""><br class=""></div><div class="">I'm building a service using these API endpoints (or I think I am):</div><div class=""><a href="http://archivesspace.github.io/archivesspace/api/#fetch-tree-information-for-the-top-level-resource-record" target="_blank" class="">[:GET] /repositories/:repo_id/resources/:id/tree/root</a></div><div class=""><a href="http://archivesspace.github.io/archivesspace/api/#fetch-tree-information-for-an-archival-object-record-within-a-tree" target="_blank" class="">[:GET] /repositories/:repo_id/resources/:id/tree/node</a></div><div class=""><br class=""></div><div class="">These incorporate the concept of "waypoints", which I admit that I'm not familiar with in this context, and it isn't explained very well in the documentation. This is what I have to work with (these are elements included in the API response):</div><div class=""><ul class=""><li class="">child_count – the number of immediate children</li><li class="">waypoints – the number of “waypoints” those children are grouped into</li><li class="">waypoint_size – the number of children in each waypoint</li><li class="">precomputed_waypoints – a collection of arrays (keyed on child URI) in the same format as returned by the ’/waypoint’ endpoint. Since a fetch for a given node is almost always followed by a fetch of the first waypoint, using the information in this structure can save a backend call.<br class=""></li></ul></div><div class="">Can anyone explain what exactly waypoints are and how they are different from children? In the examples I've seen, the "precomputed_waypoints" element in the response looks like a convoluted way (an array value of the lone element in an object, which is itself the value of the lone element in another object) to provide the children nodes of the given node (or root). What's the difference?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Trevor<br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail-m_3137259269223112502gmail-m_7888520866059867121gmail-m_1019186690443663652gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Trevor Thornton</font><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Applications Developer, Digital Library Initiatives</font></div><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">North Carolina State University Libraries</font></div></div></div></div></div></div></div></div></div>
_______________________________________________<br class="">Archivesspace_Users_Group mailing list<br class=""><a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank" class="">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br class=""><a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" target="_blank" class="">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">
Archivesspace_Users_Group mailing list<br class="">
<a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank" class="">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br class="">
<a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" rel="noreferrer" target="_blank" class="">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail-m_3137259269223112502gmail-m_7888520866059867121gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Trevor Thornton</font><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Applications Developer, Digital Library Initiatives</font></div><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">North Carolina State University Libraries</font></div></div></div></div></div></div></div>
_______________________________________________<br class="">Archivesspace_Users_Group mailing list<br class=""><a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank" class="">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br class=""><a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" target="_blank" class="">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br class=""></div></blockquote></div><br class=""></div></div></div></div>_______________________________________________<br class="">
Archivesspace_Users_Group mailing list<br class="">
<a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank" class="">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br class="">
<a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" rel="noreferrer" target="_blank" class="">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail-m_3137259269223112502gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Trevor Thornton</font><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Applications Developer, Digital Library Initiatives</font></div><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">North Carolina State University Libraries</font></div></div></div></div></div></div></div>
_______________________________________________<br class="">Archivesspace_Users_Group mailing list<br class=""><a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank" class="">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br class=""><a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" target="_blank" class="">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br class=""></div></blockquote></div><br class=""></div></div></div></div>_______________________________________________<br class="">
Archivesspace_Users_Group mailing list<br class="">
<a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank" class="">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br class="">
<a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" rel="noreferrer" target="_blank" class="">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Trevor Thornton</font><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">Applications Developer, Digital Library Initiatives</font></div><div class=""><font size="2" style="background-color:rgb(255,255,255)" color="#666666" class="">North Carolina State University Libraries</font></div></div></div></div></div></div></div>
_______________________________________________<br class="">Archivesspace_Users_Group mailing list<br class=""><a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" class="">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br class="">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<br class=""></div></blockquote></div><br class=""></div></body></html>