From mark.custer at yale.edu  Sun Oct  2 12:26:18 2016
From: mark.custer at yale.edu (Custer, Mark)
Date: Sun, 2 Oct 2016 16:26:18 +0000
Subject: [Archivesspace_Users_Group] Archivesspace_Users_Group Digest,
 Vol 38, Issue 7
In-Reply-To: <CAGmhTeMygP1QHT0ibMoxaTKDrRt8WRU7GQK=xP0nc+se81c+Xg@mail.gmail.com>
References: <mailman.111.1475236959.37245.archivesspace_users_group@lyralists.lyrasis.org>
 <CAGmhTeMygP1QHT0ibMoxaTKDrRt8WRU7GQK=xP0nc+se81c+Xg@mail.gmail.com>
Message-ID: <BN3PR08MB13181882A2728E2EB1440B608CC30@BN3PR08MB1318.namprd08.prod.outlook.com>

Cheri,

Based on that second line in the error log, it looks like there?s at least one hand-encoded ?emph? element in that resource record that hasn?t been terminated.  In other words, you might have a note or a title that looks something like this, ?this is some <emph>text<emph> with two opening tags, but no closing tags?, when it has to look something like this, instead, ?this is some <emph>text</emph> with the proper ratio of opening and closing tags?.

ASpace will still be able to export this file into EAD, but the resulting XML file will not be well formed.  Because of that, any transformations (such as converting the file into PDF) will fail.  Since the log won?t tell you exactly where the problem resides in ASpace, I find it easiest to validate the file outside of ASpace after using the export EAD function and then opening the file in an XML editor, like oXygen.

Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Cheri Crist
Sent: Friday, 30 September, 2016 9:24 AM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: Re: [Archivesspace_Users_Group] Archivesspace_Users_Group Digest, Vol 38, Issue 7

Hi all, I'm having issues exporting to PDF, but it's only happening with one record, and it's a record I've exported successfully before. Maybe I messed something up yesterday when I tweaked it. Here's the error log I've been getting; I know the one line refers to a missing end element but the rest is a mystery to me:

Generating PDF for Photographic Society of Philadelphia Records, Louis Walton Sipley/American Museum of Photography Collection
org.xml.sax.SAXParseException; lineNumber: 218; columnNumber: 126; The element type "emph" must be terminated by the matching end-tag "</emph>".
net.sf.saxon.s9api.DocumentBuilder.build(net/sf/saxon/s9api/DocumentBuilder.java:374)
java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:497)
Saxon::XML::Document.parse(/home/as/archivesspace-1.5.1/gems/gems/saxon-xslt-0.7.2-java/lib/saxon/xml.rb:26)
Saxon::XML::Document.parse(/home/as/archivesspace-1.5.1/gems/gems/saxon-xslt-0.7.2-java/lib/saxon/xml.rb:26)
Saxon::Processor.XML(/home/as/archivesspace-1.5.1/gems/gems/saxon-xslt-0.7.2-java/lib/saxon/processor.rb:57)
Saxon::Processor.XML(/home/as/archivesspace-1.5.1/gems/gems/saxon-xslt-0.7.2-java/lib/saxon/processor.rb:57)
RUBY.XML(/home/as/archivesspace-1.5.1/gems/gems/saxon-xslt-0.7.2-java/lib/saxon/xml.rb:11)
RUBY.to_fo(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/AS_fop.rb:32)
RUBY.to_pdf(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/AS_fop.rb:38)
RUBY.run(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/print_to_pdf_runner.rb:45)
RequestContext.open(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24)
RequestContext.open(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24)
RequestContext.open(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23)
RequestContext.open(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:23)
RUBY.run(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/print_to_pdf_runner.rb:23)
BackgroundJobQueue.run_pending_job(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/background_job_queue.rb:113)
BackgroundJobQueue.run_pending_job(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/background_job_queue.rb:113)
RUBY.start_background_thread(/home/as/archivesspace-1.5.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/background_job_queue.rb:153)
java.lang.Thread.run(java/lang/Thread.java:745)

Any help is appreciated!

Cheri





Cheri Crist
Project Archivist
Richard and Ronay Menschel Library
George Eastman Museum
900 East Ave.
Rochester, NY 14607
ccrist at eastman.org<mailto:ccrist at eastman.org>
(585)271-3361 ext. 280

On Fri, Sep 30, 2016 at 8:02 AM, <archivesspace_users_group-request at lyralists.lyrasis.org<mailto:archivesspace_users_group-request at lyralists.lyrasis.org>> wrote:
Send Archivesspace_Users_Group mailing list submissions to
        archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>

To subscribe or unsubscribe via the World Wide Web, visit
        http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>

or, via email, send a message with subject or body 'help' to
        archivesspace_users_group-request at lyralists.lyrasis.org<mailto:archivesspace_users_group-request at lyralists.lyrasis.org>

You can reach the person managing the list at
        archivesspace_users_group-owner at lyralists.lyrasis.org<mailto:archivesspace_users_group-owner at lyralists.lyrasis.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Archivesspace_Users_Group digest..."


Today's Topics:

   1. Re: ?An error occurred loading this record" and merging Top
      Container questions (Christine Di Bella)
   2. moved ArchivesSpace to a different        server, no longer able to
      access (Morelli, Shannon)
   3. importing Finding Aids with DO links (Jessica Wagner Webster)
   4. Re: importing Finding Aids with DO links (Kennedy, Nancy)
   5. Re: importing Finding Aids with DO links
      (Majewski, Steven Dennis (sdm7g))
   6. LDAP credentials stored at plaintext? (Zachary L Pelli)
   7. Re: importing Finding Aids with DO links
      (Majewski, Steven Dennis (sdm7g))
   8. Re: importing Finding Aids with DO links (Mayo, Dave)
   9. Re: moved ArchivesSpace to a different server, no longer able
      to access (Christine Di Bella)
  10. Using the Rights sub-records instead of Conditions Governing
      Access/Use notes? (Jordon Steele)
  11. Re: moved ArchivesSpace to a different server, no longer able
      to access (Christine Di Bella)
  12. Jetty tweaking? (Mark Cyzyk)
  13. tracking media formats in ASpace? (Tang, Lydia)
  14. Re: Using the Rights sub-records instead of Conditions
      Governing Access/Use notes? (Maureen Callahan)
  15. Re: Using the Rights sub-records instead of Conditions
      Governing Access/Use notes? (Caldera, Mary)
  16. ArchivesSpace listservs delivery outage (Christine Di Bella)
  17. Re: Using the Rights sub-records instead of Conditions
      Governing Access/Use notes? (Arnold, Hillel)
  18. bulk export of MARCXML for use in EBSCO   or other discovery
      service? (Christine Di Bella)
  19. Re: bulk export of MARCXML for use in EBSCO or other
      discovery service? (Jason Loeffler)
  20. Re: bulk export of MARCXML for use in EBSCO or other
      discovery service? (Dean DeBolt)
  21. Preferred Citation edits sometimes fail   to save (Jane LaBarbara)
  22. Re: Preferred Citation edits sometimes fail       to save (Custer, Mark)
  23. Re: moved ArchivesSpace to a      different       server, no longer able
      to access (Benedett, Barbara)
  24. duplicate <head>'s in EAD export (Majewski, Steven Dennis (sdm7g))
  25. Re: duplicate <head>'s in EAD export (Lara Friedman-Shedlov)
  26. Re: duplicate <head>'s in EAD export
      (Majewski, Steven Dennis (sdm7g))
  27. ArchivesSpace Technical Lead Position     Announcement (Laurie Arp)


----------------------------------------------------------------------

Message: 1
Date: Mon, 26 Sep 2016 16:25:46 +0000
From: Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] ?An error occurred loading
        this record" and merging Top Container questions
Message-ID:
        <CY1PR0801MB0842CC239D1D41D54C50463BF1CD0 at CY1PR0801MB0842.namprd08.prod.outlook.com<mailto:CY1PR0801MB0842CC239D1D41D54C50463BF1CD0 at CY1PR0801MB0842.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="utf-8"

I wonder if the issue has to do with your indexing. That the records display in the tree and PDF indicate that they're there. If you didn't have permission to edit them, they would still load, you just wouldn't get an edit button. And if they were still suppressed and you didn't have permission to view them, they just wouldn't appear in the tree. Can you ask your system administrator to reindex and see if that resolves the issue? (And since you've mentioned suppression a few times, I take it these were suppressed, then unsuppressed? Is there anything else different/unusual about how this particular set of components was created or edited? Just trying to understand what the sequence of events may have been.)

As for merging top containers, this is not currently possible. There is a feature request at https://archivesspace.atlassian.net/browse/AR-1436<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1436&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=EZdQGNoA5ImRGcWDNeByznOi90_cES-INmFroffj8eQ&e=>.

Christine



-----Original Message-----
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Tang, Lydia
Sent: Monday, September 26, 2016 10:25 AM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] ?An error occurred loading this record" and merging Top Container questions

Hi Christine,
Thanks for getting back to me.  I do have system permissions to edit/unsupress records, but I am concerned that there is a lingering bug in the middle of everything.  Attached is the screen shot, although I am not sure how helpful it will be.  There seems to be no way to load or edit this section, which appears to be currently unsupressed, since it shows up in the PDF export.
Another question that recently cropped up (sorry guys, lots of questions?) is if it?s possible to merge Top Containers?  From entering data in RDE and entering data in the conventional way, there somehow developed two duplicate top containers ?Box X.?  Is there a simple way to merge these two?  Just curious!
Thanks, everyone, for putting up with my questions and for any help you could provide!
Lydia

------------------------------

Message: 2
Date: Mon, 26 Sep 2016 17:24:49 +0000
From: "Morelli, Shannon" <morelli at frick.org<mailto:morelli at frick.org>>
To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>"
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] moved ArchivesSpace to a
        different       server, no longer able to access
Message-ID: <1a538af1e8654853a58bc845404670f8 at Mail03.frick.org<mailto:1a538af1e8654853a58bc845404670f8 at Mail03.frick.org>>
Content-Type: text/plain; charset="us-ascii"

We hired a consultant to set up ArchivesSpace for our institution and migrate our data from Archivists' Toolkit.  Recently, as part of an effort to synchronize ArchivesSpace with Preservica (our digital preservation system), our IT department moved the ArchivesSpace server off the Frick domain and moved it to the DMZ, it now has a new IP address.  After the move, I'm not able to access ArchivesSpace through the same browser address.  Can anyone help me out with what our IT staff can do to resolve this issue, anything specific they can reconfigure on the server? Since they did not set up the server, they do not know how to proceed.

Thanks!

Shannon

Shannon Yule Morelli
Associate Archivist and Lead Digital Archivist
The Frick Collection and Frick Art Reference Library
10 E. 71st Street
New York, NY 10021
(212) 547 - 0717<tel:%28212%29%20547%20-%200717>

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160926/2cf9fd04/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160926_2cf9fd04_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=taSmx1Mf58l0bbQQW6UUAN79NiaykriZ3sSBCulA7IQ&e=>>

------------------------------

Message: 3
Date: Mon, 26 Sep 2016 19:54:25 +0000
From: Jessica Wagner Webster <Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] importing Finding Aids with DO
        links
Message-ID:
        <C33EF018A658844D84A572728684CA930176D15B39 at mbox02.baruch.local<mailto:C33EF018A658844D84A572728684CA930176D15B39 at mbox02.baruch.local>>
Content-Type: text/plain; charset="us-ascii"

Hi all,

Has anyone had success importing EAD finding aids which contain DO links? Would anyone be able to send along a sample for me to follow? I'm having formatting issues.

Also, for those that have done this: when you include digital object links, are digital object records created and linked to resource records upon import into ASpace?

Thanks,
Jessica

Jessica Wagner Webster
Digital Initiatives Librarian, Assistant Professor
Baruch College, Newman Library
151 East 25th Street, Room 523
New York, NY 10010
(646) 312-1672<tel:%28646%29%20312-1672>
Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160926/7d78f596/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160926_7d78f596_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=Gjp47EcJSJD5KUDb05zt11BRhkFfyEmdki3cWF5IrQs&e=>>

------------------------------

Message: 4
Date: Mon, 26 Sep 2016 20:15:06 +0000
From: "Kennedy, Nancy" <KennedyN at si.edu<mailto:KennedyN at si.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] importing Finding Aids with
        DO links
Message-ID:
        <4142170736420940ACB07EE9EECDC21F34D087D9 at si-msedag04.US.SINET.SI.EDU<mailto:4142170736420940ACB07EE9EECDC21F34D087D9 at si-msedag04.US.SINET.SI.EDU>>
Content-Type: text/plain; charset="us-ascii"

Jennifer -
Yes, you can import EAD with dao.  This snippet below would create the DO on the "Account Book" archival object.  Did you include the title attribute?  If you'd like to share your EAD, I'd be happy to help.

<c level="file">
                <did>
                    <unittitle>Account Book</unittitle>
                </did>
                <dao ns2:title="title" ns2:role="Image-Service" ns2:href="http://ids.si.edu/ids/dynamic?id=NMAH-AC0040-0000001-01<https://urldefense.proofpoint.com/v2/url?u=http-3A__ids.si.edu_ids_dynamic-3Fid-3DNMAH-2DAC0040-2D0000001-2D01&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=c4ExaQETIXp07vHZm5xJDj9M1cjTnXp43vw6_k2r_hk&e=>"/>

            </c>

Nancy

Nancy Kennedy
EAD Coordinator
Smithsonian Institution
kennedyn at si.edu<mailto:kennedyn at si.edu>



From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Jessica Wagner Webster
Sent: Monday, September 26, 2016 3:55 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] importing Finding Aids with DO links

Hi all,

Has anyone had success importing EAD finding aids which contain DO links? Would anyone be able to send along a sample for me to follow? I'm having formatting issues.

Also, for those that have done this: when you include digital object links, are digital object records created and linked to resource records upon import into ASpace?

Thanks,
Jessica

Jessica Wagner Webster
Digital Initiatives Librarian, Assistant Professor
Baruch College, Newman Library
151 East 25th Street, Room 523
New York, NY 10010
(646) 312-1672<tel:%28646%29%20312-1672>
Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160926/8c741bfb/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160926_8c741bfb_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=oKINRrnJAOD4kwfUdslFlqGCff4SZOXuh6Bd6D577sM&e=>>

------------------------------

Message: 5
Date: Mon, 26 Sep 2016 20:23:19 +0000
From: "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] importing Finding Aids with
        DO links
Message-ID:
        <58321E73-65D3-4D8B-AE24-409C275C0FF6 at eservices.virginia.edu<mailto:58321E73-65D3-4D8B-AE24-409C275C0FF6 at eservices.virginia.edu>>
Content-Type: text/plain; charset="utf-8"


We?ve normalized and reprocessed to pull out text transcription into separate <dao>?s and leave page images in a <daogrp>
as this imports into ArchivesSpace as two separate digital objects, one with multiple file versions:

        <c02 level="item" id="d1e625">
          <did>
            <unittitle>Alexander Hamilton, New York, New York, to Angelica Schuyler Church, with
              note from E[lizabeth Schuyler] Hamilton.</unittitle>
            <unitdate era="ce" calendar="gregorian">1789 November 8</unitdate>
            <physdesc> ALS, 2 p. </physdesc>
            <daogrp xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xlink:type="extended" id="d1e639">
              <daoloc xlink:type="locator" xlink:title="Page 1" id="d1e640"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118891.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118891.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=PFWJvoTp1EMmN-RKSHCmJK_FjT_SynmLWwkV6Myfn3E&e=>"/>
              <daoloc xlink:type="locator" xlink:title="Page 2" id="d1e641"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118892.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118892.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=oSmmCAp5XcejogUmKfX2GetA5Wtqw1sORr1ELaecYd4&e=>"/>
              <daoloc xlink:type="locator" xlink:title="Page 3" id="d1e642"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118893.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118893.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=XGAp6zGJ4MbJbbhIBdCsiqTFdZ4tx1_f1zbhoiViEZE&e=>"/>
            </daogrp>
            <dao xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xlink:type="simple" xlink:title="Text"
              id="d1e643"
              xlink:href="http://xtf.lib.virginia.edu/xtf/view?docId=legacy_mss/uvaBook/tei/hamilton_letters/Ham1108.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__xtf.lib.virginia.edu_xtf_view-3FdocId-3Dlegacy-5Fmss_uvaBook_tei_hamilton-5Fletters_Ham1108.xml&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=6JonImzH-PMotjqcvoMKMkRwVjbyj9IhjpksmGay8wI&e=>"
            />
          </did>
          <scopecontent>
            <p>Heartfelt feelings of affection and friendship and loss in the absence of both John
              and Angelica Church following the sailing of their vessel to England.</p>
          </scopecontent>
        </c02>


We?re currently processing further before ArchivesSpace import to merge updated images using IIIF image service, and using @xlink:role attribute to mark as transcriptions, legacy-images, image-service, etc. similar to what Noah posted.


? Steve Majewski



On Sep 26, 2016, at 3:54 PM, Jessica Wagner Webster <Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>> wrote:

Hi all,

Has anyone had success importing EAD finding aids which contain DO links? Would anyone be able to send along a sample for me to follow? I?m having formatting issues.

Also, for those that have done this: when you include digital object links, are digital object records created and linked to resource records upon import into ASpace?

Thanks,
Jessica

Jessica Wagner Webster
Digital Initiatives Librarian, Assistant Professor
Baruch College, Newman Library
151 East 25th Street, Room 523
New York, NY 10010
(646) 312-1672<tel:%28646%29%20312-1672>
Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto: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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160926/f3da3ca9/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160926_f3da3ca9_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=rKv0Ra-Gi45fWlsJXZ9b9AjyBfVcDyBq8Sku8cEr-HE&e=>>

------------------------------

Message: 6
Date: Mon, 26 Sep 2016 20:30:29 +0000
From: Zachary L Pelli <zachary.pelli at shu.edu<mailto:zachary.pelli at shu.edu>>
To: "ArchivesSpace List
        (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>)"
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] LDAP credentials stored at
        plaintext?
Message-ID:
        <DM2PR0101MB1022FD22508CA0510CCB8E79E6CD0 at DM2PR0101MB1022.prod.exchangelabs.com<mailto:DM2PR0101MB1022FD22508CA0510CCB8E79E6CD0 at DM2PR0101MB1022.prod.exchangelabs.com>>

Content-Type: text/plain; charset="us-ascii"

Hello,

We're working on getting ArchivesSpace configured and our IT department has some concerns. They wish to use LDAP (probably Active Directory) for user authentication. To do this, we would have to have valid bind credentials stored in the config file. The problem they see is that this file is stored with those credentials unencrypted, which is a safety concern.

Have others considered this when setting up their LDAP implementations? What have you done to alleviate this risk?

Thank you,

Zach Pelli
Digital Collections Developer
Seton Hall University Library
zachary.pelli at shu.edu<mailto:zachary.pelli at shu.edu><mailto:zachary.pelli at shu.edu<mailto:zachary.pelli at shu.edu>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160926/81236c82/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160926_81236c82_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=FfovCrkHcsVM8-MW6kg5Sn2QBWeI9U4-j3XdHdV6pss&e=>>

------------------------------

Message: 7
Date: Mon, 26 Sep 2016 20:30:53 +0000
From: "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] importing Finding Aids with
        DO links
Message-ID:
        <434AFC70-2F05-46F1-9715-1E73C5223783 at eservices.virginia.edu<mailto:434AFC70-2F05-46F1-9715-1E73C5223783 at eservices.virginia.edu>>
Content-Type: text/plain; charset="utf-8"


I will also note that the fact that they don?t export in the same structure as they import has been a problem.
i.e. <daoloc> elements within a <daogrp> import as a single digital object with multiple file versions, but DO with multiple file versions export as multiple <dao> elements.

? Steve Majewski


On Sep 26, 2016, at 4:23 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu><mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>> wrote:


We?ve normalized and reprocessed to pull out text transcription into separate <dao>?s and leave page images in a <daogrp>
as this imports into ArchivesSpace as two separate digital objects, one with multiple file versions:

        <c02 level="item" id="d1e625">
          <did>
            <unittitle>Alexander Hamilton, New York, New York, to Angelica Schuyler Church, with
              note from E[lizabeth Schuyler] Hamilton.</unittitle>
            <unitdate era="ce" calendar="gregorian">1789 November 8</unitdate>
            <physdesc> ALS, 2 p. </physdesc>
            <daogrp xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xlink:type="extended" id="d1e639">
              <daoloc xlink:type="locator" xlink:title="Page 1" id="d1e640"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118891.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118891.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=PFWJvoTp1EMmN-RKSHCmJK_FjT_SynmLWwkV6Myfn3E&e=>"/>
              <daoloc xlink:type="locator" xlink:title="Page 2" id="d1e641"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118892.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118892.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=oSmmCAp5XcejogUmKfX2GetA5Wtqw1sORr1ELaecYd4&e=>"/>
              <daoloc xlink:type="locator" xlink:title="Page 3" id="d1e642"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118893.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118893.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=XGAp6zGJ4MbJbbhIBdCsiqTFdZ4tx1_f1zbhoiViEZE&e=>"/>
            </daogrp>
            <dao xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xlink:type="simple" xlink:title="Text"
              id="d1e643"
              xlink:href="http://xtf.lib.virginia.edu/xtf/view?docId=legacy_mss/uvaBook/tei/hamilton_letters/Ham1108.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__xtf.lib.virginia.edu_xtf_view-3FdocId-3Dlegacy-5Fmss_uvaBook_tei_hamilton-5Fletters_Ham1108.xml&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=6JonImzH-PMotjqcvoMKMkRwVjbyj9IhjpksmGay8wI&e=>"
            />
          </did>
          <scopecontent>
            <p>Heartfelt feelings of affection and friendship and loss in the absence of both John
              and Angelica Church following the sailing of their vessel to England.</p>
          </scopecontent>
        </c02>


We?re currently processing further before ArchivesSpace import to merge updated images using IIIF image service, and using @xlink:role attribute to mark as transcriptions, legacy-images, image-service, etc. similar to what Noah posted.


? Steve Majewski



On Sep 26, 2016, at 3:54 PM, Jessica Wagner Webster <Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>> wrote:

Hi all,

Has anyone had success importing EAD finding aids which contain DO links? Would anyone be able to send along a sample for me to follow? I?m having formatting issues.

Also, for those that have done this: when you include digital object links, are digital object records created and linked to resource records upon import into ASpace?

Thanks,
Jessica

Jessica Wagner Webster
Digital Initiatives Librarian, Assistant Professor
Baruch College, Newman Library
151 East 25th Street, Room 523
New York, NY 10010
(646) 312-1672<tel:%28646%29%20312-1672>
Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto: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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto: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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160926/09a9d387/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160926_09a9d387_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=HuykA3LFkHsICpg6dj0biHJfMqF5Tbaq0nZ1cq4x9-E&e=>>

------------------------------

Message: 8
Date: Mon, 26 Sep 2016 21:05:16 +0000
From: "Mayo, Dave" <dave_mayo at harvard.edu<mailto:dave_mayo at harvard.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] importing Finding Aids with
        DO links
Message-ID: <D40F026B.1509C%dave_mayo at harvard.edu<mailto:D40F026B.1509C%25dave_mayo at harvard.edu>>
Content-Type: text/plain; charset="iso-8859-1"

Additionally (although I'm working on this as we speak), xlink:show and xlink:actuate attributes on <arc> elements within <daogrp> are completely unhandled.

- Dave

From: <Majewski>, "Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu><mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org><mailto:archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>>
Date: Monday, September 26, 2016 at 4:30 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org><mailto:archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>>
Subject: Re: [Archivesspace_Users_Group] importing Finding Aids with DO links


I will also note that the fact that they don't export in the same structure as they import has been a problem.
i.e. <daoloc> elements within a <daogrp> import as a single digital object with multiple file versions, but DO with multiple file versions export as multiple <dao> elements.

- Steve Majewski


On Sep 26, 2016, at 4:23 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu><mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>> wrote:


We've normalized and reprocessed to pull out text transcription into separate <dao>'s and leave page images in a <daogrp>
as this imports into ArchivesSpace as two separate digital objects, one with multiple file versions:

        <c02 level="item" id="d1e625">
          <did>
            <unittitle>Alexander Hamilton, New York, New York, to Angelica Schuyler Church, with
              note from E[lizabeth Schuyler] Hamilton.</unittitle>
            <unitdate era="ce" calendar="gregorian">1789 November 8</unitdate>
            <physdesc> ALS, 2 p. </physdesc>
            <daogrpxmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=TkoCYi4IQa48ByPjeKAcxF30BBn-ksNFkxyqHVaMVDw&s=k5hWc0ctT2KjIRLvJGbl1XmfoT3hmijjqjNMhrVDaLY&e=>" xlink:type="extended" id="d1e639">
              <daoloc xlink:type="locator" xlink:title="Page 1" id="d1e640"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118891.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118891.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=PFWJvoTp1EMmN-RKSHCmJK_FjT_SynmLWwkV6Myfn3E&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118891.jpg&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=TkoCYi4IQa48ByPjeKAcxF30BBn-ksNFkxyqHVaMVDw&s=CIkDFS4GxvfbMWMpulJLhSurqkrThKbWDsffZ2_iLSs&e=>"/>
              <daoloc xlink:type="locator" xlink:title="Page 2" id="d1e641"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118892.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118892.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=oSmmCAp5XcejogUmKfX2GetA5Wtqw1sORr1ELaecYd4&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118892.jpg&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=TkoCYi4IQa48ByPjeKAcxF30BBn-ksNFkxyqHVaMVDw&s=nOoBlXCRF2i1rR588vFw4AwsKFAa-fRoy7McNF0qFOc&e=>"/>
              <daoloc xlink:type="locator" xlink:title="Page 3" id="d1e642"
                xlink:href="http://static.lib.virginia.edu/exhibits/church/images/AH118893.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118893.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=XGAp6zGJ4MbJbbhIBdCsiqTFdZ4tx1_f1zbhoiViEZE&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__static.lib.virginia.edu_exhibits_church_images_AH118893.jpg&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=TkoCYi4IQa48ByPjeKAcxF30BBn-ksNFkxyqHVaMVDw&s=gjiqJ54343oUWlIw19C2V_G5npprHq3LxQvlhqQWIZE&e=>"/>
            </daogrp>
            <daoxmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=TkoCYi4IQa48ByPjeKAcxF30BBn-ksNFkxyqHVaMVDw&s=k5hWc0ctT2KjIRLvJGbl1XmfoT3hmijjqjNMhrVDaLY&e=>" xlink:type="simple" xlink:title="Text"
              id="d1e643"
              xlink:href="http://xtf.lib.virginia.edu/xtf/view?docId=legacy_mss/uvaBook/tei/hamilton_letters/Ham1108.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__xtf.lib.virginia.edu_xtf_view-3FdocId-3Dlegacy-5Fmss_uvaBook_tei_hamilton-5Fletters_Ham1108.xml&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=6JonImzH-PMotjqcvoMKMkRwVjbyj9IhjpksmGay8wI&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__xtf.lib.virginia.edu_xtf_view-3FdocId-3Dlegacy-5Fmss_uvaBook_tei_hamilton-5Fletters_Ham1108.xml&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=TkoCYi4IQa48ByPjeKAcxF30BBn-ksNFkxyqHVaMVDw&s=tWHBGhLc2v2nZXfu9ztWChPl-pMgA5aVur36GO0nYTA&e=>"
            />
          </did>
          <scopecontent>
            <p>Heartfelt feelings of affection and friendship and loss in the absence of both John
              and Angelica Church following the sailing of their vessel to England.</p>
          </scopecontent>
        </c02>


We're currently processing further before ArchivesSpace import to merge updated images using IIIF image service, and using @xlink:role attribute to mark as transcriptions, legacy-images, image-service, etc. similar to what Noah posted.


- Steve Majewski



On Sep 26, 2016, at 3:54 PM, Jessica Wagner Webster <Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>> wrote:

Hi all,

Has anyone had success importing EAD finding aids which contain DO links? Would anyone be able to send along a sample for me to follow? I'm having formatting issues.

Also, for those that have done this: when you include digital object links, are digital object records created and linked to resource records upon import into ASpace?

Thanks,
Jessica

Jessica Wagner Webster
Digital Initiatives Librarian, Assistant Professor
Baruch College, Newman Library
151 East 25th Street, Room 523
New York, NY 10010
(646) 312-1672<tel:%28646%29%20312-1672>
Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu><mailto:Jessica.WagnerWebster at baruch.cuny.edu<mailto:Jessica.WagnerWebster at baruch.cuny.edu>>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto: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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=TkoCYi4IQa48ByPjeKAcxF30BBn-ksNFkxyqHVaMVDw&s=ivMUYJgEaWcbYn9szDUSBlGV8DkPOnqN_Kz4ZCN44iQ&e=>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto: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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160926/7e3d6096/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160926_7e3d6096_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=oasvBvPmiNc__8e9JSvySaNFL_mGyslA6wjvcn1QImQ&e=>>

------------------------------

Message: 9
Date: Tue, 27 Sep 2016 14:17:33 +0000
From: Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] moved ArchivesSpace to a
        different server, no longer able to access
Message-ID:
        <CY1PR0801MB08423A2A72166069BE991702F1CC0 at CY1PR0801MB0842.namprd08.prod.outlook.com<mailto:CY1PR0801MB08423A2A72166069BE991702F1CC0 at CY1PR0801MB0842.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Hi Shannon,

If they haven't already looked at it, your IT people should definitely take a look at the technical documentation about installing and running ArchivesSpace at http://archivesspace.github.io/archivesspace/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=j1EUVRg-LwpFblKdQk2Dcy3qOG2evO7Xs6UOi2YjdGM&e=>. Depending on the platform of the server and how it was set up originally, different things may be going on. Most of the settings are governed by the config file, which is in the archivesspace/config directory on the server where ArchivesSpace is installed. There's information about this file and configuring ArchivesSpace at http://archivesspace.github.io/archivesspace/user/configuring-archivesspace/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_configuring-2Darchivesspace_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=Mo9tOnEEHiunoMzWmvb2c6Hw8axRjHom3b0V88Z78Jg&e=>.

(If ArchivesSpace was set up at its own new domain, they'll need to make sure to update the DNS record with the new IP address, but that would be outside of ArchivesSpace itself.)

Christine

Christine Di Bella
Community Outreach Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org><mailto:christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
800.999.8558 x2905<tel:800.999.8558%20x2905>
678-235-2905<tel:678-235-2905>
cdibella13 (Skype)
[cid:image003.png at 01CE734E.FD759D30]


From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Morelli, Shannon
Sent: Monday, September 26, 2016 1:25 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] moved ArchivesSpace to a different server, no longer able to access

We hired a consultant to set up ArchivesSpace for our institution and migrate our data from Archivists' Toolkit.  Recently, as part of an effort to synchronize ArchivesSpace with Preservica (our digital preservation system), our IT department moved the ArchivesSpace server off the Frick domain and moved it to the DMZ, it now has a new IP address.  After the move, I'm not able to access ArchivesSpace through the same browser address.  Can anyone help me out with what our IT staff can do to resolve this issue, anything specific they can reconfigure on the server? Since they did not set up the server, they do not know how to proceed.

Thanks!

Shannon

Shannon Yule Morelli
Associate Archivist and Lead Digital Archivist
The Frick Collection and Frick Art Reference Library
10 E. 71st Street
New York, NY 10021
(212) 547 - 0717<tel:%28212%29%20547%20-%200717>

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160927/5d515d60/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160927_5d515d60_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=Dxs5VC6YoCszAVVw-TewgJocBvhtL-eC7fkU3NLEBoQ&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7645 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160927/5d515d60/attachment-0001.png<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160927_5d515d60_attachment-2D0001.png&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=o4fRHw_sHjYuBXfc2zd4y3c6qVE7j-KEbSr9P8yYCGw&e=>>

------------------------------

Message: 10
Date: Tue, 27 Sep 2016 15:18:41 +0000
From: Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>>
To: "'Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>'"
        <Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Using the Rights sub-records
        instead of Conditions Governing Access/Use notes?
Message-ID:
        <f1ee9590d8304072adbcd55e246f9568 at ESGMTWEX6.win.ad.jhu.edu<mailto:f1ee9590d8304072adbcd55e246f9568 at ESGMTWEX6.win.ad.jhu.edu>>
Content-Type: text/plain; charset="us-ascii"

Hi all,

I know most of the conversation around the Rights sub-records has been limited to digital records, but our analysis suggests that conceptually rights sub-records are simply more granular, machine-actionable forms of conditions governing access and use notes that apply to both analog and digital collections. So we're considering doing away completely with our use of the more general conditions governing access and use notes in favor of these more precise rights sub-records. Has anyone else considered or done this, or considered it and chose not to? Are we missing something?

Thanks!

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160927/2b66e43a/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160927_2b66e43a_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=-2QdZjTyDCDeARWa7F4YXG7tbXbkt_jXSbuWb2wjKZ8&e=>>

------------------------------

Message: 11
Date: Tue, 27 Sep 2016 15:23:44 +0000
From: Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] moved ArchivesSpace to a
        different server, no longer able to access
Message-ID:
        <CY1PR0801MB0842C8C335050FEA3CBCF7D3F1CC0 at CY1PR0801MB0842.namprd08.prod.outlook.com<mailto:CY1PR0801MB0842C8C335050FEA3CBCF7D3F1CC0 at CY1PR0801MB0842.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Hi Shannon,

If they haven't already looked at it, your IT people should definitely take a look at the technical documentation about installing and running ArchivesSpace at http://archivesspace.github.io/archivesspace/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=j1EUVRg-LwpFblKdQk2Dcy3qOG2evO7Xs6UOi2YjdGM&e=>. Depending on the platform of the server and how it was set up originally, different things may be going on. Most of the settings are governed by the config file, which is in the archivesspace/config directory on the server where ArchivesSpace is installed. There's information about this file and configuring ArchivesSpace at http://archivesspace.github.io/archivesspace/user/configuring-archivesspace/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archivesspace.github.io_archivesspace_user_configuring-2Darchivesspace_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=Mo9tOnEEHiunoMzWmvb2c6Hw8axRjHom3b0V88Z78Jg&e=>.

(If ArchivesSpace was set up at its own new domain, they'll need to make sure to update the DNS record with the new IP address, but that would be outside of ArchivesSpace itself.)

Christine

Christine Di Bella
Community Outreach Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org><mailto:christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
800.999.8558 x2905<tel:800.999.8558%20x2905>
678-235-2905<tel:678-235-2905>
cdibella13 (Skype)
[cid:image003.png at 01CE734E.FD759D30]


From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Morelli, Shannon
Sent: Monday, September 26, 2016 1:25 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] moved ArchivesSpace to a different server, no longer able to access

We hired a consultant to set up ArchivesSpace for our institution and migrate our data from Archivists' Toolkit.  Recently, as part of an effort to synchronize ArchivesSpace with Preservica (our digital preservation system), our IT department moved the ArchivesSpace server off the Frick domain and moved it to the DMZ, it now has a new IP address.  After the move, I'm not able to access ArchivesSpace through the same browser address.  Can anyone help me out with what our IT staff can do to resolve this issue, anything specific they can reconfigure on the server? Since they did not set up the server, they do not know how to proceed.

Thanks!

Shannon

Shannon Yule Morelli
Associate Archivist and Lead Digital Archivist
The Frick Collection and Frick Art Reference Library
10 E. 71st Street
New York, NY 10021
(212) 547 - 0717

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160927/2b6495bd/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160927_2b6495bd_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=rHcgMEAdBnHEWdQ4IMm802Na71TINR6sYeE4SfpqHXI&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7645 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160927/2b6495bd/attachment-0001.png<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160927_2b6495bd_attachment-2D0001.png&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=8igS46SYkJl8_XgwnmzAIJjqjWQMC99kAGFmhFmbp60&e=>>

------------------------------

Message: 12
Date: Tue, 27 Sep 2016 15:45:16 -0400
From: Mark Cyzyk <mcyzyk at jhu.edu<mailto:mcyzyk at jhu.edu>>
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Jetty tweaking?
Message-ID: <8ed0fa82-2215-9b3d-2a1a-2363fe5b27d9 at jhu.edu<mailto:8ed0fa82-2215-9b3d-2a1a-2363fe5b27d9 at jhu.edu>>
Content-Type: text/plain; charset=utf-8; format=flowed


Dear ArchivesSpace List,

Quick question:  If I wanted to Up the number of simultaneous
connections in the underlying Jetty, where is that config?

Best regards,

Mark

--

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Mark Cyzyk, M.A., M.L.S.
Scholarly Communication Architect
Library Applications Group
The Sheridan Libraries
The Johns Hopkins University
mcyzyk at jhu.edu<mailto:mcyzyk at jhu.edu>

Verba volant, scripta manent.




------------------------------

Message: 13
Date: Wed, 28 Sep 2016 16:24:38 +0000
From: "Tang, Lydia" <ltang5 at mail.lib.msu.edu<mailto:ltang5 at mail.lib.msu.edu>>
To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>"
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] tracking media formats in ASpace?
Message-ID: <97A3A320-2631-45A8-ABC6-E206AD85DA08 at mail.lib.msu.edu<mailto:97A3A320-2631-45A8-ABC6-E206AD85DA08 at mail.lib.msu.edu>>
Content-Type: text/plain; charset="utf-8"

Hello everyone,
I was wondering if any institution has expanded the list of Instances to include more specific media formats to track for preservation concerns?  Or do you use another area?  I am thinking it would be really great to be able to indicate and search somehow for materials in delicate media formats: audio reels, Umatic, microcassettes, floppy disks, etc and was just curious how other institutions are keeping track of it.  Thanks!
Lydia

------------------------------

Message: 14
Date: Thu, 29 Sep 2016 08:43:59 -0400
From: Maureen Callahan <mcallahan at smith.edu<mailto:mcallahan at smith.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Using the Rights sub-records
        instead of Conditions Governing Access/Use notes?
Message-ID:
        <CAH0VKbC+CdAT=yiU_XTq3SLiOYOKvg0_ed0EpKM5QeYmDQ=SrA at mail.gmail.com<mailto:SrA at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Hi Jordon,

What version are you all up to? The work that was done by HM and Yale last
year made it possible to encode machine-actionable conditions governing use
and conditions governing access statements, which will then be associated
with containers. A circulation system would be able to tell you, once those
restrictions are encoded, whether a container is restricted. I made a video
about it here: https://www.youtube.com/watch?v=biCDhkbBSng<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DbiCDhkbBSng&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=t61VhaGDoRH2pSbycZdG8wvQkwB2GyGDvSmJiHeE0WA&e=> (things may be
slightly different in 1.5.x, but not by much).

MC

On Tue, Sep 27, 2016 at 11:18 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:

> Hi all,
>
>
>
> I know most of the conversation around the Rights sub-records has been
> limited to digital records, but our analysis suggests that conceptually
> rights sub-records are simply more granular, machine-actionable forms of
> conditions governing access and use notes that apply to both analog and
> digital collections. So we?re considering doing away completely with our
> use of the more general conditions governing access and use notes in favor
> of these more precise rights sub-records. Has anyone else considered or
> done this, or considered it and chose not to? Are we missing something?
>
>
>
> Thanks!
>
>
>
> Best,
>
>
>
> Jordon
>
>
>
> Jordon Steele
>
> Hodson Curator of the University Archives
>
> The Sheridan Libraries
>
> Johns Hopkins University
>
> 3400 N Charles St
>
> Baltimore, MD 21218
>
> 410-516-5493
>
> jsteele at jhu.edu<mailto:jsteele at jhu.edu>
>
>
>
> _______________________________________________
> 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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>
>
>


--
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981 C. 215.863.1860
mcallahan at smith.edu<mailto:mcallahan at smith.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/7493a4fa/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_7493a4fa_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=p42WdDrse2vcT7FujVLZY5w1MKKBuTOZJQ1UqfJ9Jb0&e=>>

------------------------------

Message: 15
Date: Thu, 29 Sep 2016 12:55:06 +0000
From: "Caldera, Mary" <mary.caldera at yale.edu<mailto:mary.caldera at yale.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Using the Rights sub-records
        instead of Conditions Governing Access/Use notes?
Message-ID:
        <CY1PR08MB13112162D86671EC33A57324E4CE0 at CY1PR08MB1311.namprd08.prod.outlook.com<mailto:CY1PR08MB13112162D86671EC33A57324E4CE0 at CY1PR08MB1311.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Hi, Jordan,

The Yale ArchivesSpace Committee considered using the rights records before we proceeded with developing the machine actionable conditions governing access and use note. Here is a link to the topic discussion in the AS Google Group list (https://groups.google.com/forum/#!topic/archivesspace/EGdXp7_l-XQ<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21topic_archivesspace_EGdXp7-5Fl-2DXQ&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=aMTuePErzzZO7XKEus27Bacgio7ESoymFutXgyWsX-I&e=>). A search on the list might bring up some of the pros and cons. - Best, Mary

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Jordon Steele
Sent: Tuesday, September 27, 2016 11:19 AM
To: 'Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>' <Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Using the Rights sub-records instead of Conditions Governing Access/Use notes?

Hi all,

I know most of the conversation around the Rights sub-records has been limited to digital records, but our analysis suggests that conceptually rights sub-records are simply more granular, machine-actionable forms of conditions governing access and use notes that apply to both analog and digital collections. So we're considering doing away completely with our use of the more general conditions governing access and use notes in favor of these more precise rights sub-records. Has anyone else considered or done this, or considered it and chose not to? Are we missing something?

Thanks!

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493
jsteele at jhu.edu<mailto:jsteele at jhu.edu><mailto:jsteele at jhu.edu<mailto:jsteele at jhu.edu>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/7384d717/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_7384d717_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=FohwaLnZ5fR7mt8TueisiuqQMZ1PdyB5N5JVOsmRNvQ&e=>>

------------------------------

Message: 16
Date: Thu, 29 Sep 2016 13:01:08 +0000
From: Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Cc: "archivesspace_bot_members at lyralists.lyrasis.org<mailto:archivesspace_bot_members at lyralists.lyrasis.org>"
        <archivesspace_bot_members at lyralists.lyrasis.org<mailto:archivesspace_bot_members at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] ArchivesSpace listservs delivery
        outage
Message-ID:
        <CY1PR0801MB0842089EE793FDF56C7BFD62F1CE0 at CY1PR0801MB0842.namprd08.prod.outlook.com<mailto:CY1PR0801MB0842089EE793FDF56C7BFD62F1CE0 at CY1PR0801MB0842.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Hello ArchivesSpace members,

The ArchivesSpace listservs appear to have experienced a delivery outage beginning Monday evening. The issue was resolved by LYRASIS IT this morning and all messages sent during the outage period have now been delivered and are also in the listserv archives. If you notice anything still amiss, please just let me know.

Christine

Christine Di Bella
Community Outreach Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org><mailto:christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)
[cid:image003.png at 01CE734E.FD759D30]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/edbbe698/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_edbbe698_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=2GJ8euGj71oprEdSnrt7RXszVaehzh_T7SwCsichd10&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7645 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/edbbe698/attachment-0001.png<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_edbbe698_attachment-2D0001.png&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=htqXVzxnpkvyxib5PaLe7jZGXbShuBrcGK9MXEDGGC4&e=>>

------------------------------

Message: 17
Date: Thu, 29 Sep 2016 09:47:13 -0400
From: "Arnold, Hillel" <harnold at rockarch.org<mailto:harnold at rockarch.org>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Using the Rights sub-records
        instead of Conditions Governing Access/Use notes?
Message-ID: <D412928C.4A13D%harnold at rockarch.org<mailto:D412928C.4A13D%25harnold at rockarch.org>>
Content-Type: text/plain; charset="windows-1252"

I?ll also add that we here at the Rockefeller Archive Center along with some of our colleagues at the Bentley Library, Artefactual and the ArchivesSpace team have been working on putting together a specification for building out the structured rights statements functionality in ArchivesSpace. I think we?re pretty close to having something that we can circulate on this list, so stay tuned for that if you?re interested in recording machine-actionable rights statements!

Hillel
-----------
Hillel Arnold
Assistant Director, Head of Digital Programs
Rockefeller Archive Center
914.366.6382

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org><mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>>> on behalf of "Caldera, Mary" <mary.caldera at yale.edu<mailto:mary.caldera at yale.edu><mailto:mary.caldera at yale.edu<mailto:mary.caldera at yale.edu>>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org><mailto:archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>>
Date: Thursday, September 29, 2016 at 8:55 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org><mailto:archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>>
Subject: Re: [Archivesspace_Users_Group] Using the Rights sub-records instead of Conditions Governing Access/Use notes?

Hi, Jordan,

The Yale ArchivesSpace Committee considered using the rights records before we proceeded with developing the machine actionable conditions governing access and use note. Here is a link to the topic discussion in the AS Google Group list (https://groups.google.com/forum/#!topic/archivesspace/EGdXp7_l-XQ<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21topic_archivesspace_EGdXp7-5Fl-2DXQ&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=aMTuePErzzZO7XKEus27Bacgio7ESoymFutXgyWsX-I&e=>). A search on the list might bring up some of the pros and cons. ? Best, Mary

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org><mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Jordon Steele
Sent: Tuesday, September 27, 2016 11:19 AM
To: 'Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto:'Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>' <Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto:Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>>>
Subject: [Archivesspace_Users_Group] Using the Rights sub-records instead of Conditions Governing Access/Use notes?

Hi all,

I know most of the conversation around the Rights sub-records has been limited to digital records, but our analysis suggests that conceptually rights sub-records are simply more granular, machine-actionable forms of conditions governing access and use notes that apply to both analog and digital collections. So we?re considering doing away completely with our use of the more general conditions governing access and use notes in favor of these more precise rights sub-records. Has anyone else considered or done this, or considered it and chose not to? Are we missing something?

Thanks!

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493
jsteele at jhu.edu<mailto:jsteele at jhu.edu><mailto:jsteele at jhu.edu<mailto:jsteele at jhu.edu>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/b22f56d4/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_b22f56d4_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=zIP7snSRcpd17W9r9l_-ivWrQnjCbhppEnK2xVMRFVU&e=>>

------------------------------

Message: 18
Date: Thu, 29 Sep 2016 14:52:47 +0000
From: Christine Di Bella <christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] bulk export of MARCXML for use in
        EBSCO   or other discovery service?
Message-ID:
        <CY1PR0801MB0842202AC8CAFD29BFC9780CF1CE0 at CY1PR0801MB0842.namprd08.prod.outlook.com<mailto:CY1PR0801MB0842202AC8CAFD29BFC9780CF1CE0 at CY1PR0801MB0842.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

I've gotten a question from a user about how to get their data out in bulk in MARC or MARCXML to use in their library's EBSCO discovery service. Would people who've done this share their workflows and/or strategies? (They wouldn't necessarily have to be for EBSCO specifically. Any thoughts on what you might be doing with MARC data derived from ArchivesSpace records would be appreciated.)

Christine

Christine Di Bella
Community Outreach Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org><mailto:christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)
[cid:image003.png at 01CE734E.FD759D30]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/7c60246b/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_7c60246b_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=H3RFOhZN3zgwL0gwzpM28lRt6W8CFJUM9M1TdZ2maEs&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7645 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/7c60246b/attachment-0001.png<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_7c60246b_attachment-2D0001.png&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=AC0si_fquFkH4pIQaKCR7h0UJ97yFJs2InkVPwznXvI&e=>>

------------------------------

Message: 19
Date: Thu, 29 Sep 2016 11:37:58 -0400
From: Jason Loeffler <j at minorscience.com<mailto:j at minorscience.com>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] bulk export of MARCXML for
        use in EBSCO or other discovery service?
Message-ID:
        <CAP4gJsWgtBosVOFwES10pDonVHvQ3mzBoogRO-AZ8yxzh8wEZw at mail.gmail.com<mailto:CAP4gJsWgtBosVOFwES10pDonVHvQ3mzBoogRO-AZ8yxzh8wEZw at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Meaning exporting resources or archival objects or both? There is a
post-processing download option at /download_marc, though it only emits the
top level resource. This could probably be extended to include archival
objects.

Alternately, I would direct the member user to the work being done on the
OAI-PMH specification, partially documented here
<https://archivesspace.atlassian.net/browse/AR-803<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D803&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=s9_1bwKQq0v8Dw_KH2hIDhxCmZmYWIg27D3ELRgH14U&e=>> and currently under
revision. If this is implemented, and I hope it is, it would include a
machine-accessible MARC responder, among other formats.

Does that help?

Best, Jason

On Thu, Sep 29, 2016 at 10:52 AM, Christine Di Bella <
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>> wrote:

> I?ve gotten a question from a user about how to get their data out in bulk
> in MARC or MARCXML to use in their library?s EBSCO discovery service. Would
> people who?ve done this share their workflows and/or strategies? (They
> wouldn?t necessarily have to be for EBSCO specifically. Any thoughts on
> what you might be doing with MARC data derived from ArchivesSpace records
> would be appreciated.)
>
>
>
> Christine
>
>
>
> Christine Di Bella
>
> Community Outreach Manager
>
> christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
>
> 800.999.8558 x2905
>
> 678-235-2905
>
> cdibella13 (Skype)
>
> [image: cid:image003.png at 01CE734E.FD759D30]
>
>
>
> _______________________________________________
> 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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/83fbb2de/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_83fbb2de_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=2J8KXUH3t5PSnK2tM29hKys0bPmI30c3D5ReQaTRrKY&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7645 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/83fbb2de/attachment-0001.png<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_83fbb2de_attachment-2D0001.png&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=a6DLGfDsJ-GX16S6ThyvZ7rwPY4g1xIXbOI7VeCudko&e=>>

------------------------------

Message: 20
Date: Thu, 29 Sep 2016 11:07:56 -0500
From: Dean DeBolt <ddebolt at uwf.edu<mailto:ddebolt at uwf.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] bulk export of MARCXML for
        use in EBSCO or other discovery service?
Message-ID:
        <CAOnYSS+A1yn7vPS2WzjLq0CRGqsfNfMHi3ZECLMQaFhshDqnGg at mail.gmail.com<mailto:CAOnYSS%2BA1yn7vPS2WzjLq0CRGqsfNfMHi3ZECLMQaFhshDqnGg at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

To clarify on the MARC exporting, our library uses EBSCO discovery as its
main search box into the library collections, and I would like to include
the archives data that is presently in Archon and ArchivesSpace.   Since
Archon can export as a MARC record, EBSCO can use that ... but we need to
be able to produce a file of MARC data, not just print each record's MARC
data.    I'm assuming that the MARC is also in ArchivesSpace and we have
that running with the data exported in from Archon, too.

It's the MARC data that we want to export into one file as a .mrc file.

Dean



Dean DeBolt, University Librarian (Professor)/University Archivist
University Archives and West Florida History Center
University of West Florida Library
11000 University Parkway
Pensacola, FL  32514-5750
ddebolt at uwf.edu<mailto:ddebolt at uwf.edu>;   850-474-2213

West Florida History Center is the largest and most comprehensive
history collection about Pensacola and the West Florida region.
http://libguides.uwf.edu/universityarchives<https://urldefense.proofpoint.com/v2/url?u=http-3A__libguides.uwf.edu_universityarchives&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=aK2DvtL44cLB8qDteTaJqusB48tCMIKGrELwd2agcOQ&e=>

Digital collections can be found at:  http://archives.uwf.edu/Archon/<https://urldefense.proofpoint.com/v2/url?u=http-3A__archives.uwf.edu_Archon_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=0paaZtKp868lcLWp89J9aJGQcxCKvuK4H7b_7smAMeM&e=>
<http://143.88.66.76/Archon/<https://urldefense.proofpoint.com/v2/url?u=http-3A__143.88.66.76_Archon_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=iElhtz3WJnahMJYfG2qBHfUURVbzcgN0tikU07isGNc&e=>>

>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/632795eb/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_632795eb_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=QDfY13O5qH69pfez_S9owT0UU1Eog6lY2PyAKQj7o6k&e=>>

------------------------------

Message: 21
Date: Thu, 29 Sep 2016 17:19:01 +0000
From: Jane LaBarbara <jane.labarbara at mail.wvu.edu<mailto:jane.labarbara at mail.wvu.edu>>
To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>"
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Preferred Citation edits
        sometimes fail  to save
Message-ID:
        <CY4PR03MB26487D256637F47A9EEEF23AB1CE0 at CY4PR03MB2648.namprd03.prod.outlook.com<mailto:CY4PR03MB26487D256637F47A9EEEF23AB1CE0 at CY4PR03MB2648.namprd03.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Good afternoon,

We are running version 1.4.2, and we've just started our post-EAD import resource record cleanup.  We've noticed a problem where our edits sometimes fail to save in one specific field-the Preferred Citation Note.  We're editing titles. We make an edit in the Resource Record's title field, then make the same edit in the finding aid title field, and then in the Preferred Citation Field in the Notes section.  Then we save the record.  Sometimes, our change in the Preferred Citation field actually saves, but sometimes we check after saving and find that the text in that field has reverted back to its pre-edited state.  We aren't sure if there is a specific sequence of steps that triggers the problem--it seems to be random. Once we see that our edit has been lost, we try to re-edit and save again-sometimes it works on the second save, once I had to try four times to get the edit I made to stick.

Has anyone else had this problem or can suggest a possible cause/fix?  It's not a huge issue, but it is slowing down our cleanup work, and if it's not isolated to this field, it could cause failed saving of more important notes, like the scope and content note, which would be a big problem.

Thank you,
Jane

/ Jane Metters LaBarbara
Assistant Curator, West Virginia & Regional History Center<https://wvrhc.lib.wvu.edu/<https://urldefense.proofpoint.com/v2/url?u=https-3A__wvrhc.lib.wvu.edu_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=AeHo0b_KDOQBIX--JJwXtIjL3nBpuwCBo8hb9nRn2Qk&e=>>
West Virginia University Libraries
(304) 293-0352 office
jane.labarbara at mail.wvu.edu<mailto:jane.labarbara at mail.wvu.edu><mailto:jane.labarbara at mail.wvu.edu<mailto:jane.labarbara at mail.wvu.edu>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/530a0bf5/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_530a0bf5_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=zK_k-QAPuIlX4zjT8dJpQX-oXYTgpRsn20EizwO05DA&e=>>

------------------------------

Message: 22
Date: Thu, 29 Sep 2016 17:39:38 +0000
From: "Custer, Mark" <mark.custer at yale.edu<mailto:mark.custer at yale.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Preferred Citation edits
        sometimes fail  to save
Message-ID:
        <BN3PR08MB1318418B081EE67DE2F5A2E68CCE0 at BN3PR08MB1318.namprd08.prod.outlook.com<mailto:BN3PR08MB1318418B081EE67DE2F5A2E68CCE0 at BN3PR08MB1318.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Jane,

Is it possible that what you've noticed is related to this ticket?:

https://archivesspace.atlassian.net/browse/AR-1521<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1521&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=x2mgI6rQiTe2YHOhNzNdBl0yM6Uof46YAs5nxPUN1Lc&e=>

This bug affects editing of any note type, and it's particularly problematic.  I believe that we've just alerted staff not to use the "Delete" key because of this when editing notes, but that's not a great solution.

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<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Jane LaBarbara
Sent: Thursday, 29 September, 2016 1:19 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Preferred Citation edits sometimes fail to save

Good afternoon,

We are running version 1.4.2, and we've just started our post-EAD import resource record cleanup.  We've noticed a problem where our edits sometimes fail to save in one specific field-the Preferred Citation Note.  We're editing titles. We make an edit in the Resource Record's title field, then make the same edit in the finding aid title field, and then in the Preferred Citation Field in the Notes section.  Then we save the record.  Sometimes, our change in the Preferred Citation field actually saves, but sometimes we check after saving and find that the text in that field has reverted back to its pre-edited state.  We aren't sure if there is a specific sequence of steps that triggers the problem--it seems to be random. Once we see that our edit has been lost, we try to re-edit and save again-sometimes it works on the second save, once I had to try four times to get the edit I made to stick.

Has anyone else had this problem or can suggest a possible cause/fix?  It's not a huge issue, but it is slowing down our cleanup work, and if it's not isolated to this field, it could cause failed saving of more important notes, like the scope and content note, which would be a big problem.

Thank you,
Jane

/ Jane Metters LaBarbara
Assistant Curator, West Virginia & Regional History Center<https://urldefense.proofpoint.com/v2/url?u=https-3A__wvrhc.lib.wvu.edu_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=gfUWReFXsj-bdBChxikA4ICfWyKIv6GHVSnPmNZBWOs&s=vXSXM0D3eVY81K6-3OZnzqFog44j7lSdv5BEZyEIiu4&e=>
West Virginia University Libraries
(304) 293-0352 office
jane.labarbara at mail.wvu.edu<mailto:jane.labarbara at mail.wvu.edu><mailto:jane.labarbara at mail.wvu.edu<mailto:jane.labarbara at mail.wvu.edu>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/897090a1/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_897090a1_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=l4TsrFaARYSY1KdNrKlGBLTQoS10iJH9rFgb8X8VS0E&e=>>

------------------------------

Message: 23
Date: Thu, 29 Sep 2016 19:40:09 +0000
From: "Benedett, Barbara" <barbara.benedett at curtis.edu<mailto:barbara.benedett at curtis.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] moved ArchivesSpace to a
        different       server, no longer able to access
Message-ID:
        <DM5PR12MB12734B9AA3D7A4ADB88280F5E8CE0 at DM5PR12MB1273.namprd12.prod.outlook.com<mailto:DM5PR12MB12734B9AA3D7A4ADB88280F5E8CE0 at DM5PR12MB1273.namprd12.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Hi Shannon,

We are in the midst of this as well.   Our IT is currently trying to move us from the ASpace default setup to an Apache environment (also so we can sync with Preservica).  It hasn't been easy as they haven't found any instructions on how to move ASpace over. I can only share the steps I know we've had to go through so far.  If your IT hasn't yet, they will need to register with a service like godaddy or Windstream so you can get an external IP and internet DNS record.  For example we added a subdomain to our Curtis.edu website, archspace.curtis.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__archspace.curtis.edu&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=sIa1BaLhwEwesDFjbU0hkMvBsgFGv-QE6uWc2fFYUqA&e=> through Windstream.  After you are migrated, your original ports: staff, API, and public either need to be added to the URL or proxied via httpd.

I'll be keeping the basic archspace.curtis.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__archspace.curtis.edu&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=sIa1BaLhwEwesDFjbU0hkMvBsgFGv-QE6uWc2fFYUqA&e=> for the public and changing the URIs for the staff and admin logins.

Let me know how it goes!

Barbara


Barbara J. Benedett, CA
Digital Archivist | Rock Resource Center
1720 Locust Street, Philadelphia, PA 19103
(215) 717-3139 Phone  |  (215) 893-9065 Fax  |  barbara.benedett at curtis.edu<mailto:barbara.benedett at curtis.edu><mailto:barbara.benedett at curtis.edu<mailto:barbara.benedett at curtis.edu>>


[logo gif not for paper (horizontal)]<http://www.curtis.edu/html/10000.shtml<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.curtis.edu_html_10000.shtml&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=C5rLazgQ_6OMJsqwdx5bQ7av1bo3w4pNFUBFAxTRKuc&e=>>










From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Morelli, Shannon
Sent: Monday, September 26, 2016 1:25 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] moved ArchivesSpace to a different server, no longer able to access

We hired a consultant to set up ArchivesSpace for our institution and migrate our data from Archivists' Toolkit.  Recently, as part of an effort to synchronize ArchivesSpace with Preservica (our digital preservation system), our IT department moved the ArchivesSpace server off the Frick domain and moved it to the DMZ, it now has a new IP address.  After the move, I'm not able to access ArchivesSpace through the same browser address.  Can anyone help me out with what our IT staff can do to resolve this issue, anything specific they can reconfigure on the server? Since they did not set up the server, they do not know how to proceed.

Thanks!

Shannon

Shannon Yule Morelli
Associate Archivist and Lead Digital Archivist
The Frick Collection and Frick Art Reference Library
10 E. 71st Street
New York, NY 10021
(212) 547 - 0717

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/1838b0f2/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_1838b0f2_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=jkqUh5tds9Mp8PvVvmD1lOsKjUPYH9Oj_cl_ISn4g2A&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2545 bytes
Desc: image001.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/1838b0f2/attachment-0001.jpg<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_1838b0f2_attachment-2D0001.jpg&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=uNrYZK8ShMPnxxbKySm885ficekCp9O5H2irZNjvY2E&e=>>

------------------------------

Message: 24
Date: Thu, 29 Sep 2016 21:20:48 +0000
From: "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] duplicate <head>'s in EAD export
Message-ID:
        <F9E8F195-B908-4F71-8979-D7EA71C39F9D at eservices.virginia.edu<mailto:F9E8F195-B908-4F71-8979-D7EA71C39F9D at eservices.virginia.edu>>
Content-Type: text/plain; charset="utf-8"


I noticed that importing EAD with this accessrestrict element:

  <accessrestrict>
         <head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>">Access Restrictions</head>
         <p>The collection is without restrictions.</p>
  </accessrestrict>



Produces this in ArchivesSpace (1.5.1):


  *
Conditions Governing Access
Persistent ID
ec37b6585f7b376a84ab03fdf54022fd
Label
Access Restrictions
Type
Conditions Governing Access
Publish?
True
Local Access Restriction Type
Sub Notes
     *
Text
<head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>">Access Restrictions</head> The collection is without restrictions.
        *   Raw<http://localhost:8080/resources/191#resource_notes__3__subnotes__0__content__raw<https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_resources_191-23resource-5Fnotes-5F-5F3-5F-5Fsubnotes-5F-5F0-5F-5Fcontent-5F-5Fraw&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=qxfO-PvMnVrjT7L4aC4r-5dbPVMx9X0Sk40tFAlROcs&e=>>
        *   Formatted<http://localhost:8080/resources/191#resource_notes__3__subnotes__0__content__parsed<https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_resources_191-23resource-5Fnotes-5F-5F3-5F-5Fsubnotes-5F-5F0-5F-5Fcontent-5F-5Fparsed&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=zr3F7F9k6HtULPDgE8JxXxFnRxZDmbe-D84sIPBoTPE&e=>>




Which on export produces this:

<accessrestrict id="aspace_ec37b6585f7b376a84ab03fdf54022fd">
      <head>Access Restrictions</head>
      <p><head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>" >Access
          Restrictions</head> The collection is without restrictions.</p>
    </accessrestrict>



Which does not validate due to the nested: <head><p><head>
Two problems: duplicate head  and  head wrapped in <p> tag.

Indiscriminate wrapping of content in <p> tags has been a commonly  seen problem.
I?m guessing it?s likely this duplicate <head> issue may occur in other types of notes as well. ( I will look for examples. )

Not sure of the best fix: The duplicate head issue should probably be caught on import. The paragraph wrapping would seem to be an output/serialization problem.


? Steve Majewski




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/b991ea18/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_b991ea18_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=g78xUTgi5LGvfGyZXVtqCsLN9Skv2IgpsKbMqZahCWQ&e=>>

------------------------------

Message: 25
Date: Thu, 29 Sep 2016 16:24:37 -0500
From: Lara Friedman-Shedlov <ldfs at umn.edu<mailto:ldfs at umn.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] duplicate <head>'s in EAD
        export
Message-ID:
        <CAKWpb_a3=nHz2jdibP4GP_GMVuMLaNOBPCiVy-mTDQ8tBZ7=xw at mail.gmail.com<mailto:xw at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

We definitely had lots of duplicate <head>s appear when we imported our
EADs here at the University of Minnesota Libraries.  The pattern seemed to
be that it only happened if there was any attributes inside the <head> tag.




On Thu, Sep 29, 2016 at 4:20 PM, Majewski, Steven Dennis (sdm7g) <
sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>> wrote:

>
> I noticed that importing EAD with this accessrestrict element:
>
>   <accessrestrict>
>          <head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="
> http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>">Access Restrictions</head>
>          <p>The collection is without restrictions.</p>
>   </accessrestrict>
>
>
>
> Produces this in ArchivesSpace (1.5.1):
>
>
>    - Conditions Governing Access
>    Persistent ID
>    ec37b6585f7b376a84ab03fdf54022fd
>    Label
>    Access Restrictions
>    Type
>    Conditions Governing Access
>    Publish?
>    True
>    Local Access Restriction Type
>    Sub Notes
>    - Text
>       <head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="
>       http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=> <http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>>">Access
>       Restrictions</head> The collection is without restrictions.
>       - Raw
>          <http://localhost:8080/resources/191#resource_notes__3__subnotes__0__content__raw<https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_resources_191-23resource-5Fnotes-5F-5F3-5F-5Fsubnotes-5F-5F0-5F-5Fcontent-5F-5Fraw&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=qxfO-PvMnVrjT7L4aC4r-5dbPVMx9X0Sk40tFAlROcs&e=>>
>          - Formatted
>          <http://localhost:8080/resources/191#resource_notes__3__subnotes__0__content__parsed<https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_resources_191-23resource-5Fnotes-5F-5F3-5F-5Fsubnotes-5F-5F0-5F-5Fcontent-5F-5Fparsed&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=zr3F7F9k6HtULPDgE8JxXxFnRxZDmbe-D84sIPBoTPE&e=>>
>
>
>
>
>
> Which on export produces this:
>
> <accessrestrict id="aspace_ec37b6585f7b376a84ab03fdf54022fd">
>       <head>Access Restrictions</head>
>       <p><head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="
> http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>" >Access
>           Restrictions</head> The collection is without restrictions.</p>
>     </accessrestrict>
>
>
>
> Which does not validate due to the nested: <head><p><head>
> Two problems: duplicate head  and  head wrapped in <p> tag.
>
> Indiscriminate wrapping of content in <p> tags has been a commonly  seen
> problem.
> I?m guessing it?s likely this duplicate <head> issue may occur in other
> types of notes as well. ( I will look for examples. )
>
> Not sure of the best fix: The duplicate head issue should probably be
> caught on import. The paragraph wrapping would seem to be an
> output/serialization problem.
>
>
> ? Steve Majewski
>
>
>
>
>
> _______________________________________________
> 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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>
>
>


--
_________________________________

Lara D. Friedman-Shedlov
Kautz Family YMCA Archives | University of Minnesota Libraries
ldfs at umn.edu<mailto:ldfs at umn.edu> |  612.626.7972 | www.lib.umn.edu/ymca<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lib.umn.edu_ymca&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=tpz2ZmD-PVxE6mOHaOLzp5P70-JFf59mWiRZwKR6Rc0&e=> | @yarchives
__________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/3e02c78f/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_3e02c78f_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=S8yv9VmA8CVs_oIZ6pzegawsDyQl_4_i_3NXzGT1I6Q&e=>>

------------------------------

Message: 26
Date: Thu, 29 Sep 2016 21:31:45 +0000
From: "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>
To: Archivesspace Users Group
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] duplicate <head>'s in EAD
        export
Message-ID:
        <D3336C3B-D9B5-42E1-B0B1-793A551B34F7 at eservices.virginia.edu<mailto:D3336C3B-D9B5-42E1-B0B1-793A551B34F7 at eservices.virginia.edu>>
Content-Type: text/plain; charset="utf-8"


Thanks:  No attributes in that example, but namespace pseudo-attributes may be causing the same problem.
( My pre-flight stylesheet removes empty attributes but appears to leave the namespace declarations. )

? Steve Majewski



On Sep 29, 2016, at 5:25 PM, Lara Friedman-Shedlov <ldfs at umn.edu<mailto:ldfs at umn.edu><mailto:ldfs at umn.edu<mailto:ldfs at umn.edu>>> wrote:

We definitely had lots of duplicate <head>s appear when we imported our EADs here at the University of Minnesota Libraries.  The pattern seemed to be that it only happened if there was any attributes inside the <head> tag.



On Thu, Sep 29, 2016 at 4:20 PM, Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu><mailto:sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>> wrote:

I noticed that importing EAD with this accessrestrict element:

  <accessrestrict>
         <head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>">Access Restrictions</head>
         <p>The collection is without restrictions.</p>
  </accessrestrict>



Produces this in ArchivesSpace (1.5.1):


  *
Conditions Governing Access
Persistent ID
ec37b6585f7b376a84ab03fdf54022fd
Label
Access Restrictions
Type
Conditions Governing Access
Publish?
True
Local Access Restriction Type
Sub Notes
     *
Text
<head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>">Access Restrictions</head> The collection is without restrictions.
        *   Raw<http://localhost:8080/resources/191#resource_notes__3__subnotes__0__content__raw<https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_resources_191-23resource-5Fnotes-5F-5F3-5F-5Fsubnotes-5F-5F0-5F-5Fcontent-5F-5Fraw&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=qxfO-PvMnVrjT7L4aC4r-5dbPVMx9X0Sk40tFAlROcs&e=>>
        *   Formatted<http://localhost:8080/resources/191#resource_notes__3__subnotes__0__content__parsed<https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_resources_191-23resource-5Fnotes-5F-5F3-5F-5Fsubnotes-5F-5F0-5F-5Fcontent-5F-5Fparsed&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=zr3F7F9k6HtULPDgE8JxXxFnRxZDmbe-D84sIPBoTPE&e=>>




Which on export produces this:

<accessrestrict id="aspace_ec37b6585f7b376a84ab03fdf54022fd">
      <head>Access Restrictions</head>
      <p><head xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=CAHQbAEVKuIjPjCfBgNk-cl6YZ4ZvAPE6p-PoENK96s&e=>" xmlns:xtf="http://cdlib.org/xtf<https://urldefense.proofpoint.com/v2/url?u=http-3A__cdlib.org_xtf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=k64OQG4ByQxKTM7H_tC--bmyCX04gi9yLwRbgzfJkDw&e=>" >Access
          Restrictions</head> The collection is without restrictions.</p>
    </accessrestrict>



Which does not validate due to the nested: <head><p><head>
Two problems: duplicate head  and  head wrapped in <p> tag.

Indiscriminate wrapping of content in <p> tags has been a commonly  seen problem.
I?m guessing it?s likely this duplicate <head> issue may occur in other types of notes as well. ( I will look for examples. )

Not sure of the best fix: The duplicate head issue should probably be caught on import. The paragraph wrapping would seem to be an output/serialization problem.


? Steve Majewski





_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto: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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>




--
_________________________________

Lara D. Friedman-Shedlov
Kautz Family YMCA Archives | University of Minnesota Libraries
ldfs at umn.edu<mailto:ldfs at umn.edu><mailto:ldfs at umn.edu<mailto:ldfs at umn.edu>> |  612.626.7972 | www.lib.umn.edu/ymca<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lib.umn.edu_ymca&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=tpz2ZmD-PVxE6mOHaOLzp5P70-JFf59mWiRZwKR6Rc0&e=><http://www.lib.umn.edu/ymca<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lib.umn.edu_ymca&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=tpz2ZmD-PVxE6mOHaOLzp5P70-JFf59mWiRZwKR6Rc0&e=>> | @yarchives
__________________________________
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org><mailto: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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160929/29f85093/attachment-0001.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160929_29f85093_attachment-2D0001.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=USG4Evq-2YDNHF0P6H2fosRYoibWGxSZlG7Exqod46Q&e=>>

------------------------------

Message: 27
Date: Fri, 30 Sep 2016 12:02:35 +0000
From: Laurie Arp <laurie.arp at lyrasis.org<mailto:laurie.arp at lyrasis.org>>
To: "archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>"
        <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>,
        "archivesspace_member_reps at lyralists.lyrasis.org<mailto:archivesspace_member_reps at lyralists.lyrasis.org>"
        <archivesspace_member_reps at lyralists.lyrasis.org<mailto:archivesspace_member_reps at lyralists.lyrasis.org>>,
        "archivesspace_tac_uac at lyralists.lyrasis.org<mailto:archivesspace_tac_uac at lyralists.lyrasis.org>"
        <archivesspace_tac_uac at lyralists.lyrasis.org<mailto:archivesspace_tac_uac at lyralists.lyrasis.org>>
Cc: "archivesspace_bot_members at lyralists.lyrasis.org<mailto:archivesspace_bot_members at lyralists.lyrasis.org>"
        <archivesspace_bot_members at lyralists.lyrasis.org<mailto:archivesspace_bot_members at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] ArchivesSpace Technical Lead
        Position        Announcement
Message-ID:
        <BN3PR0801MB091688FD247DD6469FB35DD68AC10 at BN3PR0801MB0916.namprd08.prod.outlook.com<mailto:BN3PR0801MB091688FD247DD6469FB35DD68AC10 at BN3PR0801MB0916.namprd08.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

ArchivesSpace Technical Lead Position Announcement

The Organizational Home, with ArchivesSpace board support, has decided to upgrade the current open ArchivesSpace Developer position to an ArchivesSpace Technical Lead position.

Why this upgrade now? After a more in depth review of the current ArchivesSpace technical development needs coupled with the longer term goal of building more code contributions by the community, it is clear that a Technical Lead position can do this best.

This new position will be responsible for the overall development of the software, establishing a technical roadmap and management of a community-based code contribution process. The Technical Lead will work with the community to engage a broader set of developers to participate in the program, providing technical guidance, support and leadership to create a robust developer community.  The position will also contribute code.  In addition, we will be contracting for additional development support, both to accomplish desired work while the technical lead position is open and to address additional high priority development needs.

Attached is the position description. To repeat, the Developer position is being replaced by the Technical Lead position.

Applications accepted until the position is filled, but review of applications will begin 10/15.


Laurie Gemmill Arp
Director, Collections Services & Community Supported Software
laurie.arp at lyrasis.org<mailto:laurie.arp at lyrasis.org><mailto:laurie.arp at lyrasis.org<mailto:laurie.arp at lyrasis.org>>
800.999.8558 x 2908
Fax: 404.592.4804
laurie.gemmill1 Skype

[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]
Check lyrasisnow.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyrasisnow.org&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=2w7kE1a5rxdF1LfBOtQjNcS1SRsRmKjiLRFZK4outKE&e=><http://www.lyrasisnow.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lyrasisnow.org_&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=5YHboGuHzoZwq2AMDDQY5LTkHvDgGYQN7349vdkvxjI&e=>> for up-to-date news and feature articles.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160930/98683a3b/attachment.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160930_98683a3b_attachment.html&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=lVmNucIPEuZJ2-pAeYUm8idKgWRUqo6pRUh31qdG3_c&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4483 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160930/98683a3b/attachment.png<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160930_98683a3b_attachment.png&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=A-NgJNZmrx7LUMMTc7D2zn4jolzTHGFIEWQWV489QmA&e=>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tech leadASpace2016.pdf
Type: application/pdf
Size: 231769 bytes
Desc: tech leadASpace2016.pdf
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160930/98683a3b/attachment.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_pipermail_archivesspace-5Fusers-5Fgroup_attachments_20160930_98683a3b_attachment.pdf&d=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=4ByAh4QIGrALRW1ZsMkaK7D1uD5xvkmNcxalwboG5GI&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=CwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=aybAhE7VVKDiXQSJufCGF-1nxcptVXKecLl1JPZSWSc&s=N5yLs0DX_O-hNYZeI4ddJ9NaO21_WJufeYVUESP_rQU&e=>


End of Archivesspace_Users_Group Digest, Vol 38, Issue 7
********************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161002/7671ee2a/attachment.html>

From eckardm at umich.edu  Mon Oct  3 14:49:19 2016
From: eckardm at umich.edu (Max Eckard)
Date: Mon, 3 Oct 2016 14:49:19 -0400
Subject: [Archivesspace_Users_Group] Community review of Rights Management
	Enhancements specification
Message-ID: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>

Good morning ArchivesSpace community,

You may already be aware that representatives from the ArchivesSpace
membership, the ArchivesSpace program team and Artefactual, Inc. have been
working on a specification for enhancing the rights module in
ArchivesSpace.

The primary aim of this specification is to enable the expression of
standards-based rights statements that are atomic and actionable and that
support data transfers with other applications using rights statements,
such as Archivematica.

We have completed a draft specification, and are now asking for community
review and feedback.

The attached packet includes:

   - a summary of the enhancements requested in the specification and their
   purpose;
   - a spreadsheet containing:
   - 1) the data model being proposed for the rights management module in
      ArchivesSpace,
      - 2) the data migrations necessary for moving data in the current
      data model to the new data model,
      - 3) a chart indicating the data elements to be migrated from
      Archivematica to ArchivesSpace, and
      - 4) a data map illustrating how PREMIS rights elements are supported
      in Archivematica and ArchivesSpace; and
      - ten wire frames illustrating how the proposed data model should be
   reflected in the ArchivesSpace staff interface.

If you need some orientation to the way that PREMIS Rights Statements are
used (regardless of whether these are authored in ArchivesSpace), see the
attached PDF.

Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org), Hillel
Arnold (harnold at rockarch.org) and/or myself (eckardm at umich.edu) are happy
to answer any questions that you may have and to receive feedback on the
specification by *Friday, October 21, 2016*.
Regards,
Max Eckard

-- 
*Max Eckard*
*Assistant Archivist for Digital Curation*


Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518
http://bentley.umich.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161003/e25bf33c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PREMIS_Rights_Statement_example.pdf
Type: application/pdf
Size: 249049 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161003/e25bf33c/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ArchivesSpace Rights Enhancements.zip
Type: application/zip
Size: 279185 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161003/e25bf33c/attachment-0001.zip>

From christine.dibella at lyrasis.org  Mon Oct  3 16:32:42 2016
From: christine.dibella at lyrasis.org (Christine Di Bella)
Date: Mon, 3 Oct 2016 20:32:42 +0000
Subject: [Archivesspace_Users_Group] ArchivesSpace Update - October 2016
Message-ID: <CY1PR0801MB084280BD935DD116F02A6420F1C20@CY1PR0801MB0842.namprd08.prod.outlook.com>

[ArchivesSpace Logo5.png]
October 2016 Update


Development

The prioritization survey closed on September 16. Thanks to all Member Representatives who responded on behalf of their institutions! The Prioritization subteam is analyzing this data and will be using it to complete the development roadmap for the remainder of FY 2016-17.

ArchivesSpace is hiring for a Technical Lead. The Technical Lead will be responsible for the overall development of the software, establishing a technical roadmap and management of a community-based code contribution process. The Technical Lead will work with the community to engage a broader set of developers to participate in the program, providing technical guidance, support and leadership to create a robust developer community.  The person in the position will also contribute code.  This position will replace the previously posted Developer position. If you are interested, or know of people who are interested, more information and a link to the full description is available on the LYRASIS Open Positions page at https://www.lyrasis.org/job/Pages/LYRASIS-Positions.aspx.

In addition, we will be contracting for additional development support, both to accomplish desired work while the technical lead position is open and to address additional high priority development needs. We hope to make an announcement with specifics about this very soon.

Rights Management Specification Available for Review

As previously announced, representatives from the ArchivesSpace member community, program team, and Artefactual, Inc., have been working on a specification for an enhanced rights management module in ArchivesSpace. They would now like to present this work for wider community review and recently made available via the ArchivesSpace Users Group a set of files including a summary description of the proposed enhancements; a delineation of the data model; some information on migration and mapping between Archivematica and ArchivesSpace, as well as mapping to PREMIS; and wireframes illustrating how the proposed changes would be reflected in the ArchivesSpace staff interface. Please contact Brad Westbrook (brad.westbrook at lyrasis.org<http://lyrasis.org>), Hillel Arnold (harnold at rockarch.org<http://rockarch.org>) and/or Max Eckard (eckardm at umich.edu<mailto:eckardm at umich.edu>) for more information. The group would like to receive feedback on the draft specification by Friday, October 21, 2016.


Membership Update

Our new members since September 1 include:

*         Archives of the Archdiocese of San Francisco

*         California State Polytechnic University, Pomona

*         Idaho State Archives

*         Seton Hall University

*         Texas Wesleyan University

*         University of Cincinnati

*         Western Michigan University

As of October 3, we have 305 General members, 10 Educational Program members, and 3 Registered Service Providers. If you are interested in your institution becoming a member of ArchivesSpace, please email us at ArchivesSpaceHome at lyrasis.org<mailto:ArchivesSpaceHome at lyrasis.org> for more information.


ArchivesSpace Training

We have a full calendar of face-to-face workshops for October and November. You can visit http://archivesspace.org/trainingconsultations for the most current listing. If your institution or local archives group is interested in possibly hosting a face-to-face training, please get in touch with Christine (christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>) for more details.

For those who can't get to a face-to-face training or would like to brush up on various aspects of the ArchivesSpace application, more videos have been posted in the Members Area at http://docs.archivesspace.org/screencasts. We very much welcome contributions from the ArchivesSpace community to this page and to the User Screencast Series, so let Christine know if you have a link or a video to contribute.


Connect with ArchivesSpace in Person

Brad will be at the Association of Tribal Archives, Libraries and Museums (ATLAM) conference in Phoenix, Arizona, from October 11-12, and Christine will be at the joint meeting of the Society of Georgia Archivists and Society of Florida Archivists in Savannah, Georgia, from October 13-14. Looking a little further ahead, Brad will be at the Mid-Atlantic Regional Archives Conference (MARAC) fall meeting in Annapolis, Maryland, from November 4-5. Stop by the exhibit table or catch us at other conference events if you have any questions, want to chat in person, or just want to pick up some ArchivesSpace swag.


ArchivesSpace monthly updates provide news about ArchivesSpace community and program activities and are sent to our member listservs, the ArchivesSpace Google Group, and SAA's Collection Management Tools roundtable listserv, as well as being posted on the ArchivesSpace website. Please feel free to share this update with people you know who have an interest in ArchivesSpace but may not be on one of these lists.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161003/dfa304a3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 34143 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161003/dfa304a3/attachment.png>

From eckardm at umich.edu  Mon Oct  3 16:35:07 2016
From: eckardm at umich.edu (Max Eckard)
Date: Mon, 3 Oct 2016 16:35:07 -0400
Subject: [Archivesspace_Users_Group] Integration of AS with BePress
In-Reply-To: <CAM7Q6ozesh9N1fW8-N9VUi-KSYw9y0x5Dv-GqQUQ=Po1cjzYMg@mail.gmail.com>
References: <CAM7Q6oxFdSRR6krwxn0PSpoLj5k1QM=QC85NVY9=EW0coaKqJA@mail.gmail.com>
 <CAOEoOqWBfZxgGt-B7ZFjQQEmOtCSsw6nbT=EpFaEAL_BkPm7WQ@mail.gmail.com>
 <CAM7Q6ozWFTPu58JP+kUKZUHS=UDFH_oRUducLNfFkXMDwL_DGA@mail.gmail.com>
 <CAOEoOqV36NK+1YnKYyzXFJ7cYRcRtCTH=E4KNZbCZF6ZdqPK0w@mail.gmail.com>
 <CAM7Q6ozesh9N1fW8-N9VUi-KSYw9y0x5Dv-GqQUQ=Po1cjzYMg@mail.gmail.com>
Message-ID: <CAOEoOqX-x4ON3rirACak7F-_b6m=tZMO-pceCx1iWgs79EijKg@mail.gmail.com>

Hi Martin,

We discussed this a bit at our last Integration sub-team
<https://archivesspace.atlassian.net/wiki/display/AC/2016-09-30+Meeting+notes>
meeting. We'd recommend finding a digital asset management system that
you're happy with (e.g., BePress, or a couple of our members suggested
Islandora, but really any will do--some better than others, of course) and
looking into that. As to your concern about having digital objects and
metadata "separated," I'm sure there's others on this list who would
disagree, but we've at least taken the approach that ArchivesSpace is our
system of record for administrative and descriptive metadata while DSpace
is our system of record for preserving/providing access to digital
objects/packages. While the metadata/objects then are technically
"separated" in different systems, all that really means is that we have two
systems that specialize in different things (and do each of those different
things better than either one of them could do both) that function together
in a coordinated whole. Unique identifiers end up playing a big role in
linking systems together.

One of the best things about ArchivesSpace is the API
<http://archivesspace.github.io/archivesspace/api/>, which allows you to
easily get data in and out and share it with other systems, so I'd also
look into that.

Hope that helps,
Max

On Fri, Sep 23, 2016 at 3:38 PM, Martin Cohen <mjcohen at stmarys-ca.edu>
wrote:

> Max,
>
> Thank you!
>
> It does seem that most places have created separate sites for their
> digital objects
> using a variety of systems (ContentDM, etc) while using the archives
> system just as
> a finding aid (as with Archivists Toolkit). Archon does provide the
> capacity for
> creating digital libraries within it and populating these with both
> metadata and associated
> JPEGs, so we built on that. Since AS does not provide that functionality,
> we would be looking
> to put the JPEGs etc in BePress, but haven't sorted out how that would
> work -- just linking
> to JPEGs would seem to separate the object from its metadata: not a good
> idea! Maybe
> we would have to rebuild the digital library in BePress, which seems a lot
> of duplicated
> work.... Even if we do build a reduced digital library in BePress
> (hundreds rather than
> thousands of images) , I would be sorry to lose when we've built in Archon
> when we
> migrate to AS.
>
> Duke University has done something similar as reported in Noah Huffman's
> "The Tao of
> the DAO: Embedding digital objects in finding aids" (July 6, 2015), using
> custom EAD
> coding. I'm not sure we could undertake that kind of project here and am
> looking for
> a "ready made" solution, if that's possible.
>
> My problem is that I'm not familiar using either AS or BePress.... so
> starting with
> questions at both ends. Plus, we don't have the resources of a Duke
> University to
> implement a large-scale project like they did.
>
> -Martin
>
> On Fri, Sep 23, 2016 at 12:12 PM, Max Eckard <eckardm at umich.edu> wrote:
>
>> Hi Martin,
>>
>> I apologize for the delay in getting back with you. I've added this as an
>> agenda item to the Integrations sub-team meeting next Tuesday so we'll
>> definitely discuss it then. Unless I'm missing something it sounds like
>> what you're talking about may be possible (as long as you have a link to
>> the object online somewhere--not a metadata/download screen, unless you
>> just wanted a link). I also assume you're talking about the public
>> interface here?
>>
>> I also wonder if anyone from the migrations sub-team would have any ideas
>> about the retaining data structures from Archon to ArchivesSpace part.
>>
>> Max
>>
>>
>>
>> On Tue, Sep 20, 2016 at 3:51 PM, Martin Cohen <mjcohen at stmarys-ca.edu>
>> wrote:
>>
>>> Max,
>>>
>>> Thanks for responding so quickly.
>>> I don't see in the Integrations and Comunity Projects page a reference
>>> to what we
>>> have in mind.
>>>
>>> We have been using Archon and have built within in it an integrated
>>> digital library of images
>>> of the history of the College. Each image is contained within a "digital
>>> library" which includes
>>> descriptive metadata (title, physical description, content description,
>>> creator, date, copyright
>>> and publisher data, location of the physical source of the digital
>>> object, etc).
>>> These individual digital libraries are each associated with the
>>> collection to which they pertain,
>>> such that a given collection may contain physical boxes, folders,
>>> audiotapes, video, photographs
>>> and digital objects as well.
>>>
>>> What we want is to make the digital object (JPEG, PDF, etc) viewable
>>> together with its
>>> metadata via AS. The digital objects themselves would be contained
>>> within BePress, while
>>> the physical objects would be referenced in AS. We hope not to have to
>>> reconstruct our
>>> whole catalog separately in BePress but to retain the data structures
>>> from Archon as we
>>> migrate to AS -- hence considering that we would in some fashion
>>> be integrating BePress with AS.
>>>
>>> At this point I don't know whether what I'm asking is trivially obvious
>>> or basically un-doable.
>>> Thanks for pointing me in a good direction.
>>>
>>> -Martin
>>>
>>> On Tue, Sep 20, 2016 at 12:25 PM, Max Eckard <eckardm at umich.edu> wrote:
>>>
>>>> Hi Marten,
>>>>
>>>> I believe you're the first (at least that I'm aware of from our work on
>>>> the Technical Advisory Committee Integrations sub-team) to be interested in
>>>> an integration with BePress (although not the first to be interested in
>>>> integration with an access system). I'd suggest taking a look at the Integrations
>>>> and Other Community Projects
>>>> <https://archivesspace.atlassian.net/wiki/display/ADC/Integrations+and+Other+Community+Projects>
>>>> page on the wiki to see if any of those integrations work in similar ways
>>>> to the one you have in mind. If you find one, I'd reach out to that
>>>> institution for more information.
>>>>
>>>> If you don't see what you're looking for, perhaps you could reply with
>>>> a little more detail about exactly what you're after. After that, I'm sure
>>>> one of us on the Integrations subteam or someone in the community would
>>>> have some suggestions for first steps.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>> On Tue, Sep 20, 2016 at 3:01 PM, Martin Cohen <mjcohen at stmarys-ca.edu>
>>>> wrote:
>>>>
>>>>> Related to the query about Preservica, we are looking to integrate
>>>>> AS with BePress and would like to learn what's involved.
>>>>>
>>>>> --
>>>>> Martin J. Cohen
>>>>> Librarian / Archivist
>>>>> Saint Mary's College of California
>>>>> mjcohen at stmarys-ca.edu
>>>>> 925-631-4231
>>>>>
>>>>> _______________________________________________
>>>>> Archivesspace_Users_Group mailing list
>>>>> Archivesspace_Users_Group at lyralists.lyrasis.org
>>>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_
>>>>> users_group
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Max Eckard*
>>>> *Assistant Archivist for Digital Curation*
>>>>
>>>>
>>>> Bentley Historical Library
>>>> 1150 Beal Ave.
>>>> Ann Arbor, MI 48109-2113
>>>> (734) 763-7518
>>>> http://bentley.umich.edu/
>>>>
>>>> _______________________________________________
>>>> Archivesspace_Users_Group mailing list
>>>> Archivesspace_Users_Group at lyralists.lyrasis.org
>>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>>>
>>>>
>>>
>>>
>>> --
>>> Martin J. Cohen
>>> Librarian / Archivist
>>> Saint Mary's College of California
>>> mjcohen at stmarys-ca.edu
>>> 925-631-4231
>>>
>>> _______________________________________________
>>> Archivesspace_Users_Group mailing list
>>> Archivesspace_Users_Group at lyralists.lyrasis.org
>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>>
>>>
>>
>>
>> --
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>> Bentley Historical Library
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>> http://bentley.umich.edu/
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
>
> --
> Martin J. Cohen
> Librarian / Archivist
> Saint Mary's College of California
> mjcohen at stmarys-ca.edu
> 925-631-4231
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
*Max Eckard*
*Assistant Archivist for Digital Curation*


Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518
http://bentley.umich.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161003/e124b8c0/attachment.html>

From jsteele at jhu.edu  Tue Oct  4 11:59:46 2016
From: jsteele at jhu.edu (Jordon Steele)
Date: Tue, 4 Oct 2016 15:59:46 +0000
Subject: [Archivesspace_Users_Group] Community review of Rights
	Management	Enhancements specification
In-Reply-To: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
Message-ID: <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>

Max,

These enhancements look good to us, thanks for your efforts.

We?ve been discussing at JHU the overlap and, frankly, similarity between what sort of information the Rights Management module is trying to capture and the Conditions Governing Access/Use notes are used for, and we?re not seeing a difference in concept between the two.  ?Archivists have always used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT hold-over? may be factually accurate but they are not strong cases for continuing use.

So for the sake of not over-complicating the ASpace data model--where equally valid locations for putting the same type of information proliferate and, therefore, confuse?my main feedback is that you/the community/whoever take a good look at integration between the access/use notes and the rights management module. (After review of the responses I received from the ASpace listserv and internal discussion, JHU has decide to stop using the Access/Use notes and begin to use the Rights sub-records to manage information about what people are allowed and not allowed to do with all of our collections?analog and digital.) Your work presents a good opportunity for us all to try to get on the same page.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493
jsteele at jhu.edu

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Max Eckard
Sent: Monday, October 03, 2016 2:49 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Good morning ArchivesSpace community,
You may already be aware that representatives from the ArchivesSpace membership, the ArchivesSpace program team and Artefactual, Inc. have been working on a specification for enhancing the rights module in ArchivesSpace.

The primary aim of this specification is to enable the expression of standards-based rights statements that are atomic and actionable and that support data transfers with other applications using rights statements, such as Archivematica.
We have completed a draft specification, and are now asking for community review and feedback.

The attached packet includes:

  *   a summary of the enhancements requested in the specification and their purpose;
  *   a spreadsheet containing:

     *   1) the data model being proposed for the rights management module in ArchivesSpace,
     *   2) the data migrations necessary for moving data in the current data model to the new data model,
     *   3) a chart indicating the data elements to be migrated from Archivematica to ArchivesSpace, and
     *   4) a data map illustrating how PREMIS rights elements are supported in Archivematica and ArchivesSpace; and

  *   ten wire frames illustrating how the proposed data model should be reflected in the ArchivesSpace staff interface.

If you need some orientation to the way that PREMIS Rights Statements are used (regardless of whether these are authored in ArchivesSpace), see the attached PDF.

Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org<http://lyrasis.org>), Hillel Arnold (harnold at rockarch.org<http://rockarch.org>) and/or myself (eckardm at umich.edu<mailto:eckardm at umich.edu>) are happy to answer any questions that you may have and to receive feedback on the specification by Friday, October 21, 2016.
Regards,
Max Eckard

--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518
http://bentley.umich.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161004/619d48ed/attachment.html>

From sally.vermaaten at nyu.edu  Wed Oct  5 08:43:27 2016
From: sally.vermaaten at nyu.edu (Sally Vermaaten)
Date: Wed, 5 Oct 2016 08:43:27 -0400
Subject: [Archivesspace_Users_Group] [archivesspace] Cannot write to
	config directory . . . archivesspace/data/solr_home
In-Reply-To: <6665a55f-7505-4ab0-8f03-b3b47a5ec9e3@googlegroups.com>
References: <6665a55f-7505-4ab0-8f03-b3b47a5ec9e3@googlegroups.com>
Message-ID: <CALt9ybvR_05ub2M-svaMawgHKB-eumKJXs+DAX_gCZrfYg5LYw@mail.gmail.com>

Hi Heather,

We're running 1.5.1 and we've also noticed the "Cannot write to config
directory /opt/archivesspace/data/solr_home/collection1/conf; switching to
use InMemory storage instead"  error message in our Solr logging.

So we'd also be eager to hear if anyone has encountered this before and/or
knows how to fix it?

Thanks,
Sally


On Tue, Aug 9, 2016 at 9:42 AM, Heather Klish <heather.klish at gmail.com>
wrote:

>
> We just migrated a dev instance of ArchivesSpace 1.4.2 to 1.5.1.  We're
> getting the error messages below in Solr logging when we start the ASpace
> service.  We don't have an  archivesspace/data/solr_home directory.  I
> didn't see one in 1.4.2 either.  Any ideas as to what I should do to fix
> these?
>
>
>
> 8/9/2016, 6:16:28 AM
>
> WARNING
>
> RequestHandlers
>
> Multiple requestHandler registered to the same name: /update ignoring:
> org.apache.solr.handler.UpdateRequestHandler
>
> 8/9/2016, 6:16:31 AM
>
> WARNING
>
> ManagedResourceStorage
>
> Cannot write to config directory .../archivesspace/data/solr_home/collection1/conf;
> switching to use InMemory storage instead.
>
> 8/9/2016, 6:16:31 AM
>
> WARNING
>
> ManagedResource
>
> No stored data found for /rest/managed
>
>
> Thanks,
> Heather Klish
> Tufts University
>
> --
> You received this message because you are subscribed to the Google Groups
> "ArchivesSpace" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to archivesspace+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/bd49cbb6/attachment.html>

From eckardm at umich.edu  Wed Oct  5 09:07:45 2016
From: eckardm at umich.edu (Max Eckard)
Date: Wed, 5 Oct 2016 09:07:45 -0400
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
Message-ID: <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>

Hi Jordan,

Thanks for the feedback! This issue about the pairing of Conditions
Governing Access/Use notes and the Rights module has definitely come up in
our conversations.

Borrowing some language from these conversations, at least for the moment
we see the statements in the ArchivesSpace Rights module being used in
conjunction with rights/access statements supported in the Conditions
Governing Access and Conditions Governing Use notes. The Rights module
statements are for granular, actionable statements, whereas the Conditions
Governing Access/Use notes are for summary, non-actionable statements, and
instructions, where appropriate, for contacting rights holders. That may
turn out to be an unnecessary redundancy, and clearly there are folks like
you that make a good case for that in theory and in practice, but that's at
least our thinking for now.

Thanks again for your input! It really is very much appreciated!
Max

On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu> wrote:

> Max,
>
>
>
> These enhancements look good to us, thanks for your efforts.
>
>
>
> We?ve been discussing at JHU the overlap and, frankly, similarity between
> what sort of information the Rights Management module is trying to capture
> and the Conditions Governing Access/Use notes are used for, and we?re not
> seeing a difference in concept between the two.  ?Archivists have always
> used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT
> hold-over? may be factually accurate but they are not strong cases for
> continuing use.
>
>
>
> So for the sake of not over-complicating the ASpace data model--where
> equally valid locations for putting the same type of information
> proliferate and, therefore, confuse?my main feedback is that you/the
> community/whoever take a good look at integration between the access/use
> notes and the rights management module. (After review of the responses I
> received from the ASpace listserv and internal discussion, JHU has decide
> to stop using the Access/Use notes and begin to use the Rights sub-records
> to manage information about what people are allowed and not allowed to do
> with all of our collections?analog and digital.) Your work presents a good
> opportunity for us all to try to get on the same page.
>
>
>
> Best,
>
>
>
> Jordon
>
>
>
> Jordon Steele
>
> Hodson Curator of the University Archives
>
> The Sheridan Libraries
>
> Johns Hopkins University
>
> 3400 N Charles St
>
> Baltimore, MD 21218
>
> 410-516-5493
>
> jsteele at jhu.edu
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
> Eckard
> *Sent:* Monday, October 03, 2016 2:49 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Community review of Rights
> Management Enhancements specification
>
>
>
> Good morning ArchivesSpace community,
>
> You may already be aware that representatives from the ArchivesSpace
> membership, the ArchivesSpace program team and Artefactual, Inc. have been
> working on a specification for enhancing the rights module in
> ArchivesSpace.
>
> The primary aim of this specification is to enable the expression of
> standards-based rights statements that are atomic and actionable and that
> support data transfers with other applications using rights statements,
> such as Archivematica.
>
> We have completed a draft specification, and are now asking for community
> review and feedback.
>
> The attached packet includes:
>
>    - a summary of the enhancements requested in the specification and
>    their purpose;
>    - a spreadsheet containing:
>
>
>    - 1) the data model being proposed for the rights management module in
>       ArchivesSpace,
>       - 2) the data migrations necessary for moving data in the current
>       data model to the new data model,
>       - 3) a chart indicating the data elements to be migrated from
>       Archivematica to ArchivesSpace, and
>       - 4) a data map illustrating how PREMIS rights elements are
>       supported in Archivematica and ArchivesSpace; and
>
>
>    - ten wire frames illustrating how the proposed data model should be
>    reflected in the ArchivesSpace staff interface.
>
> If you need some orientation to the way that PREMIS Rights Statements are
> used (regardless of whether these are authored in ArchivesSpace), see the
> attached PDF.
>
> Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org), Hillel
> Arnold (harnold at rockarch.org) and/or myself (eckardm at umich.edu) are happy
> to answer any questions that you may have and to receive feedback on the
> specification by *Friday, October 21, 2016*.
>
> Regards,
>
> Max Eckard
>
>
> --
>
> *Max Eckard*
> *Assistant Archivist for Digital Curation*
>
>
>
> Bentley Historical Library
>
> 1150 Beal Ave.
> Ann Arbor, MI 48109-2113
> (734) 763-7518
>
> http://bentley.umich.edu/
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
*Max Eckard*
*Assistant Archivist for Digital Curation*


Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518
http://bentley.umich.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/98d59b87/attachment.html>

From jsteele at jhu.edu  Wed Oct  5 09:35:28 2016
From: jsteele at jhu.edu (Jordon Steele)
Date: Wed, 5 Oct 2016 13:35:28 +0000
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
Message-ID: <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>

Thanks for your response, Max. When you say ?we,? do you mean the Technical Advisory Council? And please forgive my limited understanding about the functions of the ASpace groups, but should the decision about the pros and cons of integration and redundancy rest with the TAC or the User Advisory Council?or Governance? My cursory understanding is that the UAC advises the TAC on what feature enhancements the TAC should implement. Maybe UAC and TAC have discussed this?

To your point that the Rights module only should be used to manage machine-actionable rights information, unless you plan to change something in the enhancements, currently a user is not required to use the Rights module only for this purpose?there are notes fields that one can use to put rights statements that could easily live in access/use notes, too, and the machine-actionable features are not required to create a rights record.

Also, an important implication that one of my staff mentioned yesterday is that it?s possible the public user interface development going on does not account for institutions that choose to put their access/use information in the rights module. Have there been discussions with the PUI group about this?

Speaking of granularity, I have a more granular request: your attachments are useful, but it appears you have not provided a list of elements that would be eliminated if these enhancements were adopted. For instance, looking at your wireframes, it would appear that the free-text fields of ?permissions? and ?restrictions? would go away. I don?t really have an opinion right now on whether that?s a good idea or not, but it would be helpful if you could provide us with a list of fields you?re proposing to remove.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493
jsteele at jhu.edu

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Max Eckard
Sent: Wednesday, October 05, 2016 9:08 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Hi Jordan,
Thanks for the feedback! This issue about the pairing of Conditions Governing Access/Use notes and the Rights module has definitely come up in our conversations.

Borrowing some language from these conversations, at least for the moment we see the statements in the ArchivesSpace Rights module being used in conjunction with rights/access statements supported in the Conditions Governing Access and Conditions Governing Use notes. The Rights module statements are for granular, actionable statements, whereas the Conditions Governing Access/Use notes are for summary, non-actionable statements, and instructions, where appropriate, for contacting rights holders. That may turn out to be an unnecessary redundancy, and clearly there are folks like you that make a good case for that in theory and in practice, but that's at least our thinking for now.
Thanks again for your input! It really is very much appreciated!
Max

On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Max,

These enhancements look good to us, thanks for your efforts.

We?ve been discussing at JHU the overlap and, frankly, similarity between what sort of information the Rights Management module is trying to capture and the Conditions Governing Access/Use notes are used for, and we?re not seeing a difference in concept between the two.  ?Archivists have always used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT hold-over? may be factually accurate but they are not strong cases for continuing use.

So for the sake of not over-complicating the ASpace data model--where equally valid locations for putting the same type of information proliferate and, therefore, confuse?my main feedback is that you/the community/whoever take a good look at integration between the access/use notes and the rights management module. (After review of the responses I received from the ASpace listserv and internal discussion, JHU has decide to stop using the Access/Use notes and begin to use the Rights sub-records to manage information about what people are allowed and not allowed to do with all of our collections?analog and digital.) Your work presents a good opportunity for us all to try to get on the same page.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Max Eckard
Sent: Monday, October 03, 2016 2:49 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Good morning ArchivesSpace community,
You may already be aware that representatives from the ArchivesSpace membership, the ArchivesSpace program team and Artefactual, Inc. have been working on a specification for enhancing the rights module in ArchivesSpace.

The primary aim of this specification is to enable the expression of standards-based rights statements that are atomic and actionable and that support data transfers with other applications using rights statements, such as Archivematica.
We have completed a draft specification, and are now asking for community review and feedback.

The attached packet includes:

  *   a summary of the enhancements requested in the specification and their purpose;
  *   a spreadsheet containing:

     *   1) the data model being proposed for the rights management module in ArchivesSpace,
     *   2) the data migrations necessary for moving data in the current data model to the new data model,
     *   3) a chart indicating the data elements to be migrated from Archivematica to ArchivesSpace, and
     *   4) a data map illustrating how PREMIS rights elements are supported in Archivematica and ArchivesSpace; and

  *   ten wire frames illustrating how the proposed data model should be reflected in the ArchivesSpace staff interface.

If you need some orientation to the way that PREMIS Rights Statements are used (regardless of whether these are authored in ArchivesSpace), see the attached PDF.

Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org<http://lyrasis.org>), Hillel Arnold (harnold at rockarch.org<http://rockarch.org>) and/or myself (eckardm at umich.edu<mailto:eckardm at umich.edu>) are happy to answer any questions that you may have and to receive feedback on the specification by Friday, October 21, 2016.
Regards,
Max Eckard

--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518
http://bentley.umich.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/c37929e7/attachment.html>

From jared.lor at wels.net  Wed Oct  5 12:05:48 2016
From: jared.lor at wels.net (Jared Lor)
Date: Wed, 5 Oct 2016 16:05:48 +0000
Subject: [Archivesspace_Users_Group] SSL Cert for AS
Message-ID: <SN1PR04MB1870D67461A4A573FCCC526581C40@SN1PR04MB1870.namprd04.prod.outlook.com>

I have installed AS on a Windows Server2012 but would like to add SSL to it.  Has anyone done this and how?  Thx.

________________________________

This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/a0e8b304/attachment.html>

From eckardm at umich.edu  Wed Oct  5 12:27:10 2016
From: eckardm at umich.edu (Max Eckard)
Date: Wed, 5 Oct 2016 12:27:10 -0400
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
 <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
Message-ID: <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>

Hi Jordon,

The purpose of the community review just started is to surface pros and
cons and to adjust or augment the specification for a modification to the
Rights module in ArchivesSpace accordingly.

The primary reasoning behind this specification is to support atomic and
thus machine-actionable rights statements in ArchivesSpace. However, these
statements, like you said, can also be used as descriptive elements, and
could display in ArchivesSpace public displays (in ArchivesSpace or in
other discovery systems). At the end of this process, if/when this
specification is implemented, users will have at least three basic options:

   1. Use only Conditions Governing Access/Use notes.
   2. Use only the Rights module.
   3. Use the Conditions Governing Access/Use notes in conjunction with the
   Rights module in the way I described above or in some other way (the "we" I
   was referring to earlier was just the group of us that did some research
   and wrote up the rights module).

This approach accommodates the various ways institutions already use and
want to use rights statements. Users recording rights data in the Rights
module should have the ability to publish (or not publish) to the PUI. I
talked with Brad briefly about this; sounds like it will need to be
reflected in the specification and the PUI group will need to be informed
to account for this change in its work. The specifics of that (what
displays, what doesn't, etc.) seem like they'd still need to be worked out.

Finally, this enhancement work should not result in any data being lost.
While some current fields (like the ones you mentioned--these and others
are written out in the "Removals" section of the "Data Migrations" table)
are being transferred to others that support atomic statements. Actually,
the current Permissions/Restrictions field is a good case in point. The
migration scenarios provided in the specification indicate these changes
and what is to happen to current data, in this case being transferred to an
"Act" note with an appropriate label.

Hope this helps and thanks again for the feedback!
Max

On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu> wrote:

> Thanks for your response, Max. When you say ?we,? do you mean the
> Technical Advisory Council? And please forgive my limited understanding
> about the functions of the ASpace groups, but should the decision about the
> pros and cons of integration and redundancy rest with the TAC or the User
> Advisory Council?or Governance? My cursory understanding is that the UAC
> advises the TAC on what feature enhancements the TAC should implement.
> Maybe UAC and TAC have discussed this?
>
>
>
> To your point that the Rights module only should be used to manage
> machine-actionable rights information, unless you plan to change something
> in the enhancements, currently a user is not required to use the Rights
> module only for this purpose?there are notes fields that one can use to put
> rights statements that could easily live in access/use notes, too, and the
> machine-actionable features are not required to create a rights record.
>
>
>
> Also, an important implication that one of my staff mentioned yesterday is
> that it?s possible the public user interface development going on does not
> account for institutions that choose to put their access/use information in
> the rights module. Have there been discussions with the PUI group about
> this?
>
>
>
> Speaking of granularity, I have a more granular request: your attachments
> are useful, but it appears you have not provided a list of elements that
> would be eliminated if these enhancements were adopted. For instance,
> looking at your wireframes, it would appear that the free-text fields of
> ?permissions? and ?restrictions? would go away. I don?t really have an
> opinion right now on whether that?s a good idea or not, but it would be
> helpful if you could provide us with a list of fields you?re proposing to
> remove.
>
>
>
> Best,
>
>
>
> Jordon
>
>
>
> Jordon Steele
>
> Hodson Curator of the University Archives
>
> The Sheridan Libraries
>
> Johns Hopkins University
>
> 3400 N Charles St
>
> Baltimore, MD 21218
>
> 410-516-5493
>
> jsteele at jhu.edu
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
> Eckard
> *Sent:* Wednesday, October 05, 2016 9:08 AM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
> Management Enhancements specification
>
>
>
> Hi Jordan,
>
> Thanks for the feedback! This issue about the pairing of Conditions
> Governing Access/Use notes and the Rights module has definitely come up in
> our conversations.
>
> Borrowing some language from these conversations, at least for the moment
> we see the statements in the ArchivesSpace Rights module being used in
> conjunction with rights/access statements supported in the Conditions
> Governing Access and Conditions Governing Use notes. The Rights module
> statements are for granular, actionable statements, whereas the Conditions
> Governing Access/Use notes are for summary, non-actionable statements, and
> instructions, where appropriate, for contacting rights holders. That may
> turn out to be an unnecessary redundancy, and clearly there are folks like
> you that make a good case for that in theory and in practice, but that's at
> least our thinking for now.
>
> Thanks again for your input! It really is very much appreciated!
>
> Max
>
>
>
> On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>
> Max,
>
>
>
> These enhancements look good to us, thanks for your efforts.
>
>
>
> We?ve been discussing at JHU the overlap and, frankly, similarity between
> what sort of information the Rights Management module is trying to capture
> and the Conditions Governing Access/Use notes are used for, and we?re not
> seeing a difference in concept between the two.  ?Archivists have always
> used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT
> hold-over? may be factually accurate but they are not strong cases for
> continuing use.
>
>
>
> So for the sake of not over-complicating the ASpace data model--where
> equally valid locations for putting the same type of information
> proliferate and, therefore, confuse?my main feedback is that you/the
> community/whoever take a good look at integration between the access/use
> notes and the rights management module. (After review of the responses I
> received from the ASpace listserv and internal discussion, JHU has decide
> to stop using the Access/Use notes and begin to use the Rights sub-records
> to manage information about what people are allowed and not allowed to do
> with all of our collections?analog and digital.) Your work presents a good
> opportunity for us all to try to get on the same page.
>
>
>
> Best,
>
>
>
> Jordon
>
>
>
> Jordon Steele
>
> Hodson Curator of the University Archives
>
> The Sheridan Libraries
>
> Johns Hopkins University
>
> 3400 N Charles St
>
> Baltimore, MD 21218
>
> 410-516-5493
>
> jsteele at jhu.edu
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
> Eckard
> *Sent:* Monday, October 03, 2016 2:49 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Community review of Rights
> Management Enhancements specification
>
>
>
> Good morning ArchivesSpace community,
>
> You may already be aware that representatives from the ArchivesSpace
> membership, the ArchivesSpace program team and Artefactual, Inc. have been
> working on a specification for enhancing the rights module in
> ArchivesSpace.
>
> The primary aim of this specification is to enable the expression of
> standards-based rights statements that are atomic and actionable and that
> support data transfers with other applications using rights statements,
> such as Archivematica.
>
> We have completed a draft specification, and are now asking for community
> review and feedback.
>
> The attached packet includes:
>
>    - a summary of the enhancements requested in the specification and
>    their purpose;
>    - a spreadsheet containing:
>
>
>    - 1) the data model being proposed for the rights management module in
>       ArchivesSpace,
>       - 2) the data migrations necessary for moving data in the current
>       data model to the new data model,
>       - 3) a chart indicating the data elements to be migrated from
>       Archivematica to ArchivesSpace, and
>       - 4) a data map illustrating how PREMIS rights elements are
>       supported in Archivematica and ArchivesSpace; and
>
>
>    - ten wire frames illustrating how the proposed data model should be
>    reflected in the ArchivesSpace staff interface.
>
> If you need some orientation to the way that PREMIS Rights Statements are
> used (regardless of whether these are authored in ArchivesSpace), see the
> attached PDF.
>
> Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org), Hillel
> Arnold (harnold at rockarch.org) and/or myself (eckardm at umich.edu) are happy
> to answer any questions that you may have and to receive feedback on the
> specification by *Friday, October 21, 2016*.
>
> Regards,
>
> Max Eckard
>
>
> --
>
> *Max Eckard*
> *Assistant Archivist for Digital Curation*
>
>
>
> Bentley Historical Library
>
> 1150 Beal Ave.
> Ann Arbor, MI 48109-2113
> (734) 763-7518
>
> http://bentley.umich.edu/
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
>
> --
>
> *Max Eckard*
> *Assistant Archivist for Digital Curation*
>
>
>
> Bentley Historical Library
>
> 1150 Beal Ave.
> Ann Arbor, MI 48109-2113
> (734) 763-7518
>
> http://bentley.umich.edu/
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
*Max Eckard*
*Assistant Archivist for Digital Curation*


Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518
http://bentley.umich.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/be348786/attachment.html>

From sally.vermaaten at nyu.edu  Wed Oct  5 15:47:28 2016
From: sally.vermaaten at nyu.edu (Sally Vermaaten)
Date: Wed, 5 Oct 2016 15:47:28 -0400
Subject: [Archivesspace_Users_Group] Indexing issue - Solr data directory
	and default storage configuration?
Message-ID: <CALt9ybtFc6is-kS=Sh8V8YGnQNZOrpEZ6g4OwCHxb1rMS1_+Nw@mail.gmail.com>

Hello,

We have a problem where some edits to records are saving but don't appear
to be updating in the index - e.g. you can see the correct info when
looking at the particular record but not in the summary info about a record
in a browse list.

In troubleshooting this problem, we noticed in the ArchivesSpace config
there is an option to set up a Solr data storage directory. However you
aren't forced to do so. If the Solr data storage directory isn't explicitly
set up, it looks like Solr tries to put data to config directory in
$SOLR_HOME/[core name]/config. Here is the relevant code block:
https://github.com/apache/lucene-solr/blob/master/solr/
core/src/java/org/apache/solr/rest/ManagedResourceStorage.java#L119

If the config directory is not writable or doesn't exist (e.g. we don't
seem to have a SOLR_HOME directory by default) Solr sends a "cannot write
to config directory ... switching to InMemory storage instead" warning
(discussed in an earlier listserv thread
<http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2016-October/004116.html>)
and then put data into memory.

Does anyone know if this (storage InMemory) is desired behavior (e.g. for
performance reasons)? Or is this an error in the default Solr config?

Thank you!
Sally


-- 
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/9e156671/attachment.html>

From mcallahan at smith.edu  Wed Oct  5 16:31:43 2016
From: mcallahan at smith.edu (Maureen Callahan)
Date: Wed, 5 Oct 2016 16:31:43 -0400
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
 <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>
Message-ID: <CAH0VKbAocZ8U-OunGU_qYsZwRmxezVG63_haTKAR39R6Yn4XEw@mail.gmail.com>

Dear Max and others,

I'm so happy to see these proposed enhancements to the rights subrecord to
bring it in better alignment with PREMIS. This looks dope, and it looks
like it will make integration with digital preservation systems much easier.

Thanks too for laying out the options for recording rights information,
Max. There are a couple of things that I would add from my perspective of
having worked on the requirements for enhanced conditions governing access
and conditions governing use notes that I would want folks to think about
before making description and usage decisions, especially since I know
there are a lot of new adopters of 1.5.x who may not have fully explored
this functionality.

Looking at the underlying standards that govern a record in ArchivesSpace
is important, and part of the reason that we decided to work on conditions
governing access/use was because we were interested in using DACS guidance
for aggregated materials. Doing description outside of the content standard
-- rather, in lieu of the content standard used for all other records --
seems pretty iffy to me. If it were me, I would use DACS elements for
archival description and PREMIS elements for digital preservation
activities.

As you say, the rights module will be very good for recording atomic rights
information on a PREMIS model. But if you're looking at an aggregation of
materials that may have children records, ArchivesSpace won't know that the
rights subrecord applies to the physical, lower-level objects that
circulate in boxes the same way that it knows about access/use notes -- as
is appropriate! I haven't yet seen a full articulation of the difference
between rights and conditions governing access/use, beyond what we had
created at Yale and Mary had circulated, but it seems like conditions
governing access/use are now very good with DACS principle 7, in a way that
there's no expectation for PREMIS rights statements to be.

Indeed, the enhancements to access/use notes in 1.5.x use the archival
principles of inheritance in a way that the rights subrecord does not plan
to. In 1.5.x, if a series is marked as being available for research use in
2027, ArchivesSpace knows that all of the top containers in that series are
not open until 2027. It won't know this about containers if rights
subrecords are used (because rights subrecords are based on PREMIS, which
is about electronic records -- although there's a role for aggregation in
describing electronic records too, of course).

Finally, a big part of the migration from Archivists' Toolkit to
ArchivesSpace at Yale had to do with reconciling non-standard usage of AT.
There had been good reasons, I know, for using fields and records in
non-standard ways in AT at Yale, but the result was 80% of my time and 80%
of another colleague's time for six months (and thousands of dollars toward
contract programmers) to put the data back where it was expected so that it
could go into ArchivesSpace smoothly. You don't want to go through that if
you can avoid it. Plus, beyond the PUI, your EAD won't have the relevant
access/use information you need, which may be fine eventually but for now
won't work for inclusion in ArchiveGrid and a number of other projects that
rely on EAD.

Since I'm away from Yale and this work now
<http://4.bp.blogspot.com/-hjyKJqD6Gz0/VEW1DU_xHzI/AAAAAAAAGFM/kjQLzEDFOOU/s1600/pullmebackin.gif>,
I'd love to hear what others who are using 1.5.x think about this.

All best,
Maureen

On Wed, Oct 5, 2016 at 12:27 PM, Max Eckard <eckardm at umich.edu> wrote:

> Hi Jordon,
>
> The purpose of the community review just started is to surface pros and
> cons and to adjust or augment the specification for a modification to the
> Rights module in ArchivesSpace accordingly.
>
> The primary reasoning behind this specification is to support atomic and
> thus machine-actionable rights statements in ArchivesSpace. However, these
> statements, like you said, can also be used as descriptive elements, and
> could display in ArchivesSpace public displays (in ArchivesSpace or in
> other discovery systems). At the end of this process, if/when this
> specification is implemented, users will have at least three basic options:
>
>    1. Use only Conditions Governing Access/Use notes.
>    2. Use only the Rights module.
>    3. Use the Conditions Governing Access/Use notes in conjunction with
>    the Rights module in the way I described above or in some other way (the
>    "we" I was referring to earlier was just the group of us that did some
>    research and wrote up the rights module).
>
> This approach accommodates the various ways institutions already use and
> want to use rights statements. Users recording rights data in the Rights
> module should have the ability to publish (or not publish) to the PUI. I
> talked with Brad briefly about this; sounds like it will need to be
> reflected in the specification and the PUI group will need to be informed
> to account for this change in its work. The specifics of that (what
> displays, what doesn't, etc.) seem like they'd still need to be worked out.
>
> Finally, this enhancement work should not result in any data being lost.
> While some current fields (like the ones you mentioned--these and others
> are written out in the "Removals" section of the "Data Migrations" table)
> are being transferred to others that support atomic statements. Actually,
> the current Permissions/Restrictions field is a good case in point. The
> migration scenarios provided in the specification indicate these changes
> and what is to happen to current data, in this case being transferred to an
> "Act" note with an appropriate label.
>
> Hope this helps and thanks again for the feedback!
> Max
>
> On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>
>> Thanks for your response, Max. When you say ?we,? do you mean the
>> Technical Advisory Council? And please forgive my limited understanding
>> about the functions of the ASpace groups, but should the decision about the
>> pros and cons of integration and redundancy rest with the TAC or the User
>> Advisory Council?or Governance? My cursory understanding is that the UAC
>> advises the TAC on what feature enhancements the TAC should implement.
>> Maybe UAC and TAC have discussed this?
>>
>>
>>
>> To your point that the Rights module only should be used to manage
>> machine-actionable rights information, unless you plan to change something
>> in the enhancements, currently a user is not required to use the Rights
>> module only for this purpose?there are notes fields that one can use to put
>> rights statements that could easily live in access/use notes, too, and the
>> machine-actionable features are not required to create a rights record.
>>
>>
>>
>> Also, an important implication that one of my staff mentioned yesterday
>> is that it?s possible the public user interface development going on does
>> not account for institutions that choose to put their access/use
>> information in the rights module. Have there been discussions with the PUI
>> group about this?
>>
>>
>>
>> Speaking of granularity, I have a more granular request: your attachments
>> are useful, but it appears you have not provided a list of elements that
>> would be eliminated if these enhancements were adopted. For instance,
>> looking at your wireframes, it would appear that the free-text fields of
>> ?permissions? and ?restrictions? would go away. I don?t really have an
>> opinion right now on whether that?s a good idea or not, but it would be
>> helpful if you could provide us with a list of fields you?re proposing to
>> remove.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
>> Eckard
>> *Sent:* Wednesday, October 05, 2016 9:08 AM
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Hi Jordan,
>>
>> Thanks for the feedback! This issue about the pairing of Conditions
>> Governing Access/Use notes and the Rights module has definitely come up in
>> our conversations.
>>
>> Borrowing some language from these conversations, at least for the moment
>> we see the statements in the ArchivesSpace Rights module being used in
>> conjunction with rights/access statements supported in the Conditions
>> Governing Access and Conditions Governing Use notes. The Rights module
>> statements are for granular, actionable statements, whereas the Conditions
>> Governing Access/Use notes are for summary, non-actionable statements, and
>> instructions, where appropriate, for contacting rights holders. That may
>> turn out to be an unnecessary redundancy, and clearly there are folks like
>> you that make a good case for that in theory and in practice, but that's at
>> least our thinking for now.
>>
>> Thanks again for your input! It really is very much appreciated!
>>
>> Max
>>
>>
>>
>> On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>>
>> Max,
>>
>>
>>
>> These enhancements look good to us, thanks for your efforts.
>>
>>
>>
>> We?ve been discussing at JHU the overlap and, frankly, similarity between
>> what sort of information the Rights Management module is trying to capture
>> and the Conditions Governing Access/Use notes are used for, and we?re not
>> seeing a difference in concept between the two.  ?Archivists have always
>> used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT
>> hold-over? may be factually accurate but they are not strong cases for
>> continuing use.
>>
>>
>>
>> So for the sake of not over-complicating the ASpace data model--where
>> equally valid locations for putting the same type of information
>> proliferate and, therefore, confuse?my main feedback is that you/the
>> community/whoever take a good look at integration between the access/use
>> notes and the rights management module. (After review of the responses I
>> received from the ASpace listserv and internal discussion, JHU has decide
>> to stop using the Access/Use notes and begin to use the Rights sub-records
>> to manage information about what people are allowed and not allowed to do
>> with all of our collections?analog and digital.) Your work presents a good
>> opportunity for us all to try to get on the same page.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
>> Eckard
>> *Sent:* Monday, October 03, 2016 2:49 PM
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Good morning ArchivesSpace community,
>>
>> You may already be aware that representatives from the ArchivesSpace
>> membership, the ArchivesSpace program team and Artefactual, Inc. have been
>> working on a specification for enhancing the rights module in
>> ArchivesSpace.
>>
>> The primary aim of this specification is to enable the expression of
>> standards-based rights statements that are atomic and actionable and that
>> support data transfers with other applications using rights statements,
>> such as Archivematica.
>>
>> We have completed a draft specification, and are now asking for community
>> review and feedback.
>>
>> The attached packet includes:
>>
>>    - a summary of the enhancements requested in the specification and
>>    their purpose;
>>    - a spreadsheet containing:
>>
>>
>>    - 1) the data model being proposed for the rights management module
>>       in ArchivesSpace,
>>       - 2) the data migrations necessary for moving data in the current
>>       data model to the new data model,
>>       - 3) a chart indicating the data elements to be migrated from
>>       Archivematica to ArchivesSpace, and
>>       - 4) a data map illustrating how PREMIS rights elements are
>>       supported in Archivematica and ArchivesSpace; and
>>
>>
>>    - ten wire frames illustrating how the proposed data model should be
>>    reflected in the ArchivesSpace staff interface.
>>
>> If you need some orientation to the way that PREMIS Rights Statements are
>> used (regardless of whether these are authored in ArchivesSpace), see the
>> attached PDF.
>>
>> Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org), Hillel
>> Arnold (harnold at rockarch.org) and/or myself (eckardm at umich.edu) are
>> happy to answer any questions that you may have and to receive feedback on
>> the specification by *Friday, October 21, 2016*.
>>
>> Regards,
>>
>> Max Eckard
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
>
> --
> *Max Eckard*
> *Assistant Archivist for Digital Curation*
>
>
> Bentley Historical Library
> 1150 Beal Ave.
> Ann Arbor, MI 48109-2113
> (734) 763-7518
> http://bentley.umich.edu/
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981 C. 215.863.1860
mcallahan at smith.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/e47d6ee9/attachment.html>

From harnold at rockarch.org  Wed Oct  5 17:50:50 2016
From: harnold at rockarch.org (Arnold, Hillel)
Date: Wed, 5 Oct 2016 17:50:50 -0400
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <CAH0VKbAocZ8U-OunGU_qYsZwRmxezVG63_haTKAR39R6Yn4XEw@mail.gmail.com>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
 <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>
 <CAH0VKbAocZ8U-OunGU_qYsZwRmxezVG63_haTKAR39R6Yn4XEw@mail.gmail.com>
Message-ID: <D41AE6E2.4A83A%harnold@rockarch.org>

Hi all,
I just wanted to jump in to thank all of you who?ve provided feedback on the proposal thus far, and to encourage others to chime in. I also wanted to echo Max?s point that this specification is really addressed at machine-interoperability and improving compliance with community standards (in this case PREMIS).
While those of use who pulled together this specification have use cases in mind, and concrete ways in which we intend to use the proposed functionality, I don?t think any of us want to prescribe how data should be recorded in the application for all institutions and all use cases. The community may be able to agree on approaches to recording this data (and I think that conversation is useful and worthwhile), but it seems well outside of the scope of this proposal.
I?d also like to point out that the three options for recording rights information that Max laid out exist in the current version of the application (and probably earlier versions as well). This specification doesn?t change that; in essence all it proposes is to make those structured rights statements PREMIS-compliant.
In any event, let?s keep the feedback coming!

Hillel
-----------
Hillel Arnold
Assistant Director, Head of Digital Programs
Rockefeller Archive Center
914.366.6382

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Maureen Callahan <mcallahan at smith.edu<mailto:mcallahan at smith.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Wednesday, October 5, 2016 at 4:31 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Dear Max and others,

I'm so happy to see these proposed enhancements to the rights subrecord to bring it in better alignment with PREMIS. This looks dope, and it looks like it will make integration with digital preservation systems much easier.

Thanks too for laying out the options for recording rights information, Max. There are a couple of things that I would add from my perspective of having worked on the requirements for enhanced conditions governing access and conditions governing use notes that I would want folks to think about before making description and usage decisions, especially since I know there are a lot of new adopters of 1.5.x who may not have fully explored this functionality.

Looking at the underlying standards that govern a record in ArchivesSpace is important, and part of the reason that we decided to work on conditions governing access/use was because we were interested in using DACS guidance for aggregated materials. Doing description outside of the content standard -- rather, in lieu of the content standard used for all other records -- seems pretty iffy to me. If it were me, I would use DACS elements for archival description and PREMIS elements for digital preservation activities.

As you say, the rights module will be very good for recording atomic rights information on a PREMIS model. But if you're looking at an aggregation of materials that may have children records, ArchivesSpace won't know that the rights subrecord applies to the physical, lower-level objects that circulate in boxes the same way that it knows about access/use notes -- as is appropriate! I haven't yet seen a full articulation of the difference between rights and conditions governing access/use, beyond what we had created at Yale and Mary had circulated, but it seems like conditions governing access/use are now very good with DACS principle 7, in a way that there's no expectation for PREMIS rights statements to be.

Indeed, the enhancements to access/use notes in 1.5.x use the archival principles of inheritance in a way that the rights subrecord does not plan to. In 1.5.x, if a series is marked as being available for research use in 2027, ArchivesSpace knows that all of the top containers in that series are not open until 2027. It won't know this about containers if rights subrecords are used (because rights subrecords are based on PREMIS, which is about electronic records -- although there's a role for aggregation in describing electronic records too, of course).

Finally, a big part of the migration from Archivists' Toolkit to ArchivesSpace at Yale had to do with reconciling non-standard usage of AT. There had been good reasons, I know, for using fields and records in non-standard ways in AT at Yale, but the result was 80% of my time and 80% of another colleague's time for six months (and thousands of dollars toward contract programmers) to put the data back where it was expected so that it could go into ArchivesSpace smoothly. You don't want to go through that if you can avoid it. Plus, beyond the PUI, your EAD won't have the relevant access/use information you need, which may be fine eventually but for now won't work for inclusion in ArchiveGrid and a number of other projects that rely on EAD.

Since I'm away from Yale and this work now<http://4.bp.blogspot.com/-hjyKJqD6Gz0/VEW1DU_xHzI/AAAAAAAAGFM/kjQLzEDFOOU/s1600/pullmebackin.gif>, I'd love to hear what others who are using 1.5.x think about this.

All best,
Maureen

On Wed, Oct 5, 2016 at 12:27 PM, Max Eckard <eckardm at umich.edu<mailto:eckardm at umich.edu>> wrote:
Hi Jordon,

The purpose of the community review just started is to surface pros and cons and to adjust or augment the specification for a modification to the Rights module in ArchivesSpace accordingly.

The primary reasoning behind this specification is to support atomic and thus machine-actionable rights statements in ArchivesSpace. However, these statements, like you said, can also be used as descriptive elements, and could display in ArchivesSpace public displays (in ArchivesSpace or in other discovery systems). At the end of this process, if/when this specification is implemented, users will have at least three basic options:

 1.  Use only Conditions Governing Access/Use notes.
 2.  Use only the Rights module.
 3.  Use the Conditions Governing Access/Use notes in conjunction with the Rights module in the way I described above or in some other way (the "we" I was referring to earlier was just the group of us that did some research and wrote up the rights module).

This approach accommodates the various ways institutions already use and want to use rights statements. Users recording rights data in the Rights module should have the ability to publish (or not publish) to the PUI. I talked with Brad briefly about this; sounds like it will need to be reflected in the specification and the PUI group will need to be informed to account for this change in its work. The specifics of that (what displays, what doesn't, etc.) seem like they'd still need to be worked out.

Finally, this enhancement work should not result in any data being lost. While some current fields (like the ones you mentioned--these and others are written out in the "Removals" section of the "Data Migrations" table) are being transferred to others that support atomic statements. Actually, the current Permissions/Restrictions field is a good case in point. The migration scenarios provided in the specification indicate these changes and what is to happen to current data, in this case being transferred to an "Act" note with an appropriate label.

Hope this helps and thanks again for the feedback!
Max

On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Thanks for your response, Max. When you say ?we,? do you mean the Technical Advisory Council? And please forgive my limited understanding about the functions of the ASpace groups, but should the decision about the pros and cons of integration and redundancy rest with the TAC or the User Advisory Council?or Governance? My cursory understanding is that the UAC advises the TAC on what feature enhancements the TAC should implement. Maybe UAC and TAC have discussed this?

To your point that the Rights module only should be used to manage machine-actionable rights information, unless you plan to change something in the enhancements, currently a user is not required to use the Rights module only for this purpose?there are notes fields that one can use to put rights statements that could easily live in access/use notes, too, and the machine-actionable features are not required to create a rights record.

Also, an important implication that one of my staff mentioned yesterday is that it?s possible the public user interface development going on does not account for institutions that choose to put their access/use information in the rights module. Have there been discussions with the PUI group about this?

Speaking of granularity, I have a more granular request: your attachments are useful, but it appears you have not provided a list of elements that would be eliminated if these enhancements were adopted. For instance, looking at your wireframes, it would appear that the free-text fields of ?permissions? and ?restrictions? would go away. I don?t really have an opinion right now on whether that?s a good idea or not, but it would be helpful if you could provide us with a list of fields you?re proposing to remove.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Max Eckard
Sent: Wednesday, October 05, 2016 9:08 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Hi Jordan,
Thanks for the feedback! This issue about the pairing of Conditions Governing Access/Use notes and the Rights module has definitely come up in our conversations.

Borrowing some language from these conversations, at least for the moment we see the statements in the ArchivesSpace Rights module being used in conjunction with rights/access statements supported in the Conditions Governing Access and Conditions Governing Use notes. The Rights module statements are for granular, actionable statements, whereas the Conditions Governing Access/Use notes are for summary, non-actionable statements, and instructions, where appropriate, for contacting rights holders. That may turn out to be an unnecessary redundancy, and clearly there are folks like you that make a good case for that in theory and in practice, but that's at least our thinking for now.
Thanks again for your input! It really is very much appreciated!
Max

On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Max,

These enhancements look good to us, thanks for your efforts.

We?ve been discussing at JHU the overlap and, frankly, similarity between what sort of information the Rights Management module is trying to capture and the Conditions Governing Access/Use notes are used for, and we?re not seeing a difference in concept between the two.  ?Archivists have always used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT hold-over? may be factually accurate but they are not strong cases for continuing use.

So for the sake of not over-complicating the ASpace data model--where equally valid locations for putting the same type of information proliferate and, therefore, confuse?my main feedback is that you/the community/whoever take a good look at integration between the access/use notes and the rights management module. (After review of the responses I received from the ASpace listserv and internal discussion, JHU has decide to stop using the Access/Use notes and begin to use the Rights sub-records to manage information about what people are allowed and not allowed to do with all of our collections?analog and digital.) Your work presents a good opportunity for us all to try to get on the same page.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Max Eckard
Sent: Monday, October 03, 2016 2:49 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Good morning ArchivesSpace community,
You may already be aware that representatives from the ArchivesSpace membership, the ArchivesSpace program team and Artefactual, Inc. have been working on a specification for enhancing the rights module in ArchivesSpace.

The primary aim of this specification is to enable the expression of standards-based rights statements that are atomic and actionable and that support data transfers with other applications using rights statements, such as Archivematica.
We have completed a draft specification, and are now asking for community review and feedback.

The attached packet includes:

 *   a summary of the enhancements requested in the specification and their purpose;
 *   a spreadsheet containing:

    *   1) the data model being proposed for the rights management module in ArchivesSpace,
    *   2) the data migrations necessary for moving data in the current data model to the new data model,
    *   3) a chart indicating the data elements to be migrated from Archivematica to ArchivesSpace, and
    *   4) a data map illustrating how PREMIS rights elements are supported in Archivematica and ArchivesSpace; and

 *   ten wire frames illustrating how the proposed data model should be reflected in the ArchivesSpace staff interface.

If you need some orientation to the way that PREMIS Rights Statements are used (regardless of whether these are authored in ArchivesSpace), see the attached PDF.

Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org<http://lyrasis.org>), Hillel Arnold (harnold at rockarch.org<http://rockarch.org>) and/or myself (eckardm at umich.edu<mailto:eckardm at umich.edu>) are happy to answer any questions that you may have and to receive feedback on the specification by Friday, October 21, 2016.
Regards,
Max Eckard

--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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




--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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




--
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981 C. 215.863.1860
mcallahan at smith.edu<mailto:mcallahan at smith.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161005/edaea215/attachment.html>

From jsteele at jhu.edu  Thu Oct  6 16:52:07 2016
From: jsteele at jhu.edu (Jordon Steele)
Date: Thu, 6 Oct 2016 20:52:07 +0000
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <D41AE6E2.4A83A%harnold@rockarch.org>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
 <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>
 <CAH0VKbAocZ8U-OunGU_qYsZwRmxezVG63_haTKAR39R6Yn4XEw@mail.gmail.com>
 <D41AE6E2.4A83A%harnold@rockarch.org>
Message-ID: <9e569d29bf414f72932637c78a0cb9ea@ESGMTWEX6.win.ad.jhu.edu>

Thanks, everyone.

Maureen, I was not aware that the Rights module would not follow the principle of inheritance. Seems like it should, if the rights information being assigned exists in context of a hierarchy.  Setting aside the intricacies of what PREMIS or DACS set out to accomplish, any user would logically look at a field in ASpace called "Rights Statements" and think, "Oh, that's where I put information about what people can and can't do with my stuff."

You also raise a good point that rights information may not map properly to discovery tools like ArchiveGrid if entered in the Rights module. The implication, then, is that those of us that want to manage our rights with more granularity, and consolidate the locations where that rights information exists, are left with some pretty serious trade-offs.

I'll say that I would be more comfortable managing my rights information in the access/use notes coming from an archives/DACS tradition, but the big weakness for us is that you can't record atomic rights information in these elements in the accessions module, and according to one offline response I received access/use notes don't transfer over when you spawn a resource record (which sounds like a bug, can't believe that was intentional, but I digress).

Here's an idea: should we instead be focusing on moving some of the rights statement functionality to access/use notes and sunsetting the rights module altogether, rather than having parallel places to put the same information?

Which leads me to my main point. Hillel, I think you hit the nail on the head: thanks to Max's helpful replies I now realize that it is beyond the scope of this project to consider how best to manage rights information in ASpace; rather, this project is limited to making some informed improvements to one place a user can manage rights information. So you guys are off the hook! But what about the rest of us thinking about how this bundle of features that add up to ASpace-are we missing a greater opportunity here? I would argue that giving people more than one place to put the same information is questionable product design, and now might be good time to fix that. I think the argument that giving people options is a collegial gesture, but I just don't buy it.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493
jsteele at jhu.edu

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Arnold, Hillel
Sent: Wednesday, October 05, 2016 5:51 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Hi all,
I just wanted to jump in to thank all of you who've provided feedback on the proposal thus far, and to encourage others to chime in. I also wanted to echo Max's point that this specification is really addressed at machine-interoperability and improving compliance with community standards (in this case PREMIS).
While those of use who pulled together this specification have use cases in mind, and concrete ways in which we intend to use the proposed functionality, I don't think any of us want to prescribe how data should be recorded in the application for all institutions and all use cases. The community may be able to agree on approaches to recording this data (and I think that conversation is useful and worthwhile), but it seems well outside of the scope of this proposal.
I'd also like to point out that the three options for recording rights information that Max laid out exist in the current version of the application (and probably earlier versions as well). This specification doesn't change that; in essence all it proposes is to make those structured rights statements PREMIS-compliant.
In any event, let's keep the feedback coming!

Hillel
-----------
Hillel Arnold
Assistant Director, Head of Digital Programs
Rockefeller Archive Center
914.366.6382

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Maureen Callahan <mcallahan at smith.edu<mailto:mcallahan at smith.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Wednesday, October 5, 2016 at 4:31 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Dear Max and others,

I'm so happy to see these proposed enhancements to the rights subrecord to bring it in better alignment with PREMIS. This looks dope, and it looks like it will make integration with digital preservation systems much easier.

Thanks too for laying out the options for recording rights information, Max. There are a couple of things that I would add from my perspective of having worked on the requirements for enhanced conditions governing access and conditions governing use notes that I would want folks to think about before making description and usage decisions, especially since I know there are a lot of new adopters of 1.5.x who may not have fully explored this functionality.

Looking at the underlying standards that govern a record in ArchivesSpace is important, and part of the reason that we decided to work on conditions governing access/use was because we were interested in using DACS guidance for aggregated materials. Doing description outside of the content standard -- rather, in lieu of the content standard used for all other records -- seems pretty iffy to me. If it were me, I would use DACS elements for archival description and PREMIS elements for digital preservation activities.

As you say, the rights module will be very good for recording atomic rights information on a PREMIS model. But if you're looking at an aggregation of materials that may have children records, ArchivesSpace won't know that the rights subrecord applies to the physical, lower-level objects that circulate in boxes the same way that it knows about access/use notes -- as is appropriate! I haven't yet seen a full articulation of the difference between rights and conditions governing access/use, beyond what we had created at Yale and Mary had circulated, but it seems like conditions governing access/use are now very good with DACS principle 7, in a way that there's no expectation for PREMIS rights statements to be.

Indeed, the enhancements to access/use notes in 1.5.x use the archival principles of inheritance in a way that the rights subrecord does not plan to. In 1.5.x, if a series is marked as being available for research use in 2027, ArchivesSpace knows that all of the top containers in that series are not open until 2027. It won't know this about containers if rights subrecords are used (because rights subrecords are based on PREMIS, which is about electronic records -- although there's a role for aggregation in describing electronic records too, of course).

Finally, a big part of the migration from Archivists' Toolkit to ArchivesSpace at Yale had to do with reconciling non-standard usage of AT. There had been good reasons, I know, for using fields and records in non-standard ways in AT at Yale, but the result was 80% of my time and 80% of another colleague's time for six months (and thousands of dollars toward contract programmers) to put the data back where it was expected so that it could go into ArchivesSpace smoothly. You don't want to go through that if you can avoid it. Plus, beyond the PUI, your EAD won't have the relevant access/use information you need, which may be fine eventually but for now won't work for inclusion in ArchiveGrid and a number of other projects that rely on EAD.

Since I'm away from Yale and this work now<http://4.bp.blogspot.com/-hjyKJqD6Gz0/VEW1DU_xHzI/AAAAAAAAGFM/kjQLzEDFOOU/s1600/pullmebackin.gif>, I'd love to hear what others who are using 1.5.x think about this.

All best,
Maureen

On Wed, Oct 5, 2016 at 12:27 PM, Max Eckard <eckardm at umich.edu<mailto:eckardm at umich.edu>> wrote:
Hi Jordon,
The purpose of the community review just started is to surface pros and cons and to adjust or augment the specification for a modification to the Rights module in ArchivesSpace accordingly.

The primary reasoning behind this specification is to support atomic and thus machine-actionable rights statements in ArchivesSpace. However, these statements, like you said, can also be used as descriptive elements, and could display in ArchivesSpace public displays (in ArchivesSpace or in other discovery systems). At the end of this process, if/when this specification is implemented, users will have at least three basic options:

  1.  Use only Conditions Governing Access/Use notes.
  2.  Use only the Rights module.
  3.  Use the Conditions Governing Access/Use notes in conjunction with the Rights module in the way I described above or in some other way (the "we" I was referring to earlier was just the group of us that did some research and wrote up the rights module).
This approach accommodates the various ways institutions already use and want to use rights statements. Users recording rights data in the Rights module should have the ability to publish (or not publish) to the PUI. I talked with Brad briefly about this; sounds like it will need to be reflected in the specification and the PUI group will need to be informed to account for this change in its work. The specifics of that (what displays, what doesn't, etc.) seem like they'd still need to be worked out.
Finally, this enhancement work should not result in any data being lost. While some current fields (like the ones you mentioned--these and others are written out in the "Removals" section of the "Data Migrations" table) are being transferred to others that support atomic statements. Actually, the current Permissions/Restrictions field is a good case in point. The migration scenarios provided in the specification indicate these changes and what is to happen to current data, in this case being transferred to an "Act" note with an appropriate label.

Hope this helps and thanks again for the feedback!
Max

On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Thanks for your response, Max. When you say "we," do you mean the Technical Advisory Council? And please forgive my limited understanding about the functions of the ASpace groups, but should the decision about the pros and cons of integration and redundancy rest with the TAC or the User Advisory Council-or Governance? My cursory understanding is that the UAC advises the TAC on what feature enhancements the TAC should implement. Maybe UAC and TAC have discussed this?

To your point that the Rights module only should be used to manage machine-actionable rights information, unless you plan to change something in the enhancements, currently a user is not required to use the Rights module only for this purpose-there are notes fields that one can use to put rights statements that could easily live in access/use notes, too, and the machine-actionable features are not required to create a rights record.

Also, an important implication that one of my staff mentioned yesterday is that it's possible the public user interface development going on does not account for institutions that choose to put their access/use information in the rights module. Have there been discussions with the PUI group about this?

Speaking of granularity, I have a more granular request: your attachments are useful, but it appears you have not provided a list of elements that would be eliminated if these enhancements were adopted. For instance, looking at your wireframes, it would appear that the free-text fields of "permissions" and "restrictions" would go away. I don't really have an opinion right now on whether that's a good idea or not, but it would be helpful if you could provide us with a list of fields you're proposing to remove.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Max Eckard
Sent: Wednesday, October 05, 2016 9:08 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Hi Jordan,
Thanks for the feedback! This issue about the pairing of Conditions Governing Access/Use notes and the Rights module has definitely come up in our conversations.

Borrowing some language from these conversations, at least for the moment we see the statements in the ArchivesSpace Rights module being used in conjunction with rights/access statements supported in the Conditions Governing Access and Conditions Governing Use notes. The Rights module statements are for granular, actionable statements, whereas the Conditions Governing Access/Use notes are for summary, non-actionable statements, and instructions, where appropriate, for contacting rights holders. That may turn out to be an unnecessary redundancy, and clearly there are folks like you that make a good case for that in theory and in practice, but that's at least our thinking for now.
Thanks again for your input! It really is very much appreciated!
Max

On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Max,

These enhancements look good to us, thanks for your efforts.

We've been discussing at JHU the overlap and, frankly, similarity between what sort of information the Rights Management module is trying to capture and the Conditions Governing Access/Use notes are used for, and we're not seeing a difference in concept between the two.  "Archivists have always used the Access/Use notes" or "Access/Use notes are an EAD/DACS/AT hold-over" may be factually accurate but they are not strong cases for continuing use.

So for the sake of not over-complicating the ASpace data model--where equally valid locations for putting the same type of information proliferate and, therefore, confuse-my main feedback is that you/the community/whoever take a good look at integration between the access/use notes and the rights management module. (After review of the responses I received from the ASpace listserv and internal discussion, JHU has decide to stop using the Access/Use notes and begin to use the Rights sub-records to manage information about what people are allowed and not allowed to do with all of our collections-analog and digital.) Your work presents a good opportunity for us all to try to get on the same page.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Max Eckard
Sent: Monday, October 03, 2016 2:49 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Good morning ArchivesSpace community,
You may already be aware that representatives from the ArchivesSpace membership, the ArchivesSpace program team and Artefactual, Inc. have been working on a specification for enhancing the rights module in ArchivesSpace.

The primary aim of this specification is to enable the expression of standards-based rights statements that are atomic and actionable and that support data transfers with other applications using rights statements, such as Archivematica.
We have completed a draft specification, and are now asking for community review and feedback.

The attached packet includes:

  *   a summary of the enhancements requested in the specification and their purpose;
  *   a spreadsheet containing:

     *   1) the data model being proposed for the rights management module in ArchivesSpace,
     *   2) the data migrations necessary for moving data in the current data model to the new data model,
     *   3) a chart indicating the data elements to be migrated from Archivematica to ArchivesSpace, and
     *   4) a data map illustrating how PREMIS rights elements are supported in Archivematica and ArchivesSpace; and

  *   ten wire frames illustrating how the proposed data model should be reflected in the ArchivesSpace staff interface.

If you need some orientation to the way that PREMIS Rights Statements are used (regardless of whether these are authored in ArchivesSpace), see the attached PDF.

Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org<http://lyrasis.org>), Hillel Arnold (harnold at rockarch.org<http://rockarch.org>) and/or myself (eckardm at umich.edu<mailto:eckardm at umich.edu>) are happy to answer any questions that you may have and to receive feedback on the specification by Friday, October 21, 2016.
Regards,
Max Eckard

--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981 C. 215.863.1860
mcallahan at smith.edu<mailto:mcallahan at smith.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161006/69dc6969/attachment.html>

From carlos.lemus at unlv.edu  Thu Oct  6 19:47:13 2016
From: carlos.lemus at unlv.edu (Carlos Lemus)
Date: Thu, 6 Oct 2016 16:47:13 -0700
Subject: [Archivesspace_Users_Group] searchable archives now available for
	ArchivesSpace listservs
Message-ID: <CAPsSwYp=YQ=VF2fob9MgygLxW2fq8pNEUqqRabcpg4sois-O6A@mail.gmail.com>

Hello,

I just want to say thank you for hearing us out and doing something about
the searchability in the listserver. We appreciate it!

Thank you!
Carlos Lemus
Application Programmer, Special Collections Technical Services
University Libraries, University of Nevada, Las Vegas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161006/6ae17bb1/attachment.html>

From mcallahan at smith.edu  Fri Oct  7 08:48:06 2016
From: mcallahan at smith.edu (Maureen Callahan)
Date: Fri, 7 Oct 2016 08:48:06 -0400
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <9e569d29bf414f72932637c78a0cb9ea@ESGMTWEX6.win.ad.jhu.edu>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
 <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>
 <CAH0VKbAocZ8U-OunGU_qYsZwRmxezVG63_haTKAR39R6Yn4XEw@mail.gmail.com>
 <D41AE6E2.4A83A%harnold@rockarch.org>
 <9e569d29bf414f72932637c78a0cb9ea@ESGMTWEX6.win.ad.jhu.edu>
Message-ID: <CAH0VKbDEVHOc1nUN_ezM5QGEKmj+1zpuen71wdepMV8j9xSDsg@mail.gmail.com>

Hi Jordon,

I guess it all depends on what you mean by both inheritance and
machine-actionable. A rights statement will belong to a hierarchy in the
same way that a higher-level scope and content note will -- it sits higher
in the tree and we have all agreed that higher-level elements implicitly
apply to lower-level elements. All of this data can be accessed through a
number of means (the API, the GUI, the database) and you could set up
systems so that machines can do actions with the data -- to look higher in
the tree to see which rights statements apply. But ArchivesSpace itself
won't do the work of associating a condition governing access or use (as
expressed in rights, rather than access/use subrecords) with containers
that are associated lower down in the hierarchy in a way that would let a
system know whether or not a container should circulate. Here, I'm really
strictly talking about associating machine-actionable restrictions with top
containers. The granular restriction types and restriction begin/end dates
in conditions governing access/use DO let you do this.

It's an extremely rare occasion that I disagree with Hillel, but I do think
that generally, it's important to remember that these systems are a way to
make standards actionable and description manageable, but that even when
systems go away, standards persist. My guess is that the folks who wrote
this specification have very well-defined boundaries about the appropriate
way to leverage PREMIS rights statements. I also think that this proposal
is good, because PREMIS rights are meant to do different things than DACS
conditions governing access or use statements, and there may be good use
cases for linking this information across both ArchivesSpace and a digital
preservation repository. But I'm also going to guess that not every
archivist is familiar or comfortable with those distinctions, and it might
be helpful to see an explanation of "As an archivist managing electronic
records in a digital preservation repository, I want for the rights module
to be in better alignment with PREMIS rights so that I may _______."
Similarly, there's a lot baked into ArchivesSpace about how to write
DACS-compliant description in ArchivesSpace, but I think that much goes
unsaid there too.

Thanks!
MC

On Thu, Oct 6, 2016 at 4:52 PM, Jordon Steele <jsteele at jhu.edu> wrote:

> Thanks, everyone.
>
>
>
> Maureen, I was not aware that the Rights module would not follow the
> principle of inheritance. Seems like it should, if the rights information
> being assigned exists in context of a hierarchy.  Setting aside the
> intricacies of what PREMIS or DACS set out to accomplish, any user would
> logically look at a field in ASpace called ?Rights Statements? and think,
> ?Oh, that?s where I put information about what people can and can?t do with
> my stuff.?
>
>
>
> You also raise a good point that rights information may not map properly
> to discovery tools like ArchiveGrid if entered in the Rights module. The
> implication, then, is that those of us that want to manage our rights with
> more granularity, and consolidate the locations where that rights
> information exists, are left with some pretty serious trade-offs.
>
>
>
> I?ll say that I would be more comfortable managing my rights information
> in the access/use notes coming from an archives/DACS tradition, but the big
> weakness for us is that you can?t record atomic rights information in these
> elements in the accessions module, and according to one offline response I
> received access/use notes don?t transfer over when you spawn a resource
> record (which sounds like a bug, can?t believe that was intentional, but I
> digress).
>
>
>
> Here?s an idea: should we instead be focusing on moving some of the rights
> statement functionality to access/use notes and sunsetting the rights
> module altogether, rather than having parallel places to put the same
> information?
>
>
>
> Which leads me to my main point. Hillel, I think you hit the nail on the
> head: thanks to Max?s helpful replies I now realize that it is beyond the
> scope of this project to consider how best to manage rights information in
> ASpace; rather, this project is limited to making some informed
> improvements to one place a user can manage rights information. So you guys
> are off the hook! But what about the rest of us thinking about how this
> bundle of features that add up to ASpace?are we missing a greater
> opportunity here? I would argue that giving people more than one place to
> put the same information is questionable product design, and now might be
> good time to fix that. I think the argument that giving people options is a
> collegial gesture, but I just don?t buy it.
>
>
>
> Best,
>
>
>
> Jordon
>
>
>
> Jordon Steele
>
> Hodson Curator of the University Archives
>
> The Sheridan Libraries
>
> Johns Hopkins University
>
> 3400 N Charles St
>
> Baltimore, MD 21218
>
> 410-516-5493
>
> jsteele at jhu.edu
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Arnold,
> Hillel
> *Sent:* Wednesday, October 05, 2016 5:51 PM
>
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
> Management Enhancements specification
>
>
>
> Hi all,
>
> I just wanted to jump in to thank all of you who?ve provided feedback on
> the proposal thus far, and to encourage others to chime in. I also wanted
> to echo Max?s point that this specification is really addressed at
> machine-interoperability and improving compliance with community standards
> (in this case PREMIS).
>
> While those of use who pulled together this specification have use cases
> in mind, and concrete ways in which we intend to use the proposed
> functionality, I don?t think any of us want to prescribe how data should be
> recorded in the application for all institutions and all use cases. The
> community may be able to agree on approaches to recording this data (and I
> think that conversation is useful and worthwhile), but it seems well
> outside of the scope of this proposal.
>
> I?d also like to point out that the three options for recording rights
> information that Max laid out exist in the current version of the
> application (and probably earlier versions as well). This specification
> doesn?t change that; in essence all it proposes is to make those structured
> rights statements PREMIS-compliant.
>
> In any event, let?s keep the feedback coming!
>
>
>
> Hillel
>
> -----------
>
> Hillel Arnold
>
> Assistant Director, Head of Digital Programs
>
> Rockefeller Archive Center
>
> 914.366.6382
>
>
>
> *From: *<archivesspace_users_group-bounces at lyralists.lyrasis.org> on
> behalf of Maureen Callahan <mcallahan at smith.edu>
> *Reply-To: *Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Date: *Wednesday, October 5, 2016 at 4:31 PM
> *To: *Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject: *Re: [Archivesspace_Users_Group] Community review of Rights
> Management Enhancements specification
>
>
>
> Dear Max and others,
>
>
>
> I'm so happy to see these proposed enhancements to the rights subrecord to
> bring it in better alignment with PREMIS. This looks dope, and it looks
> like it will make integration with digital preservation systems much easier.
>
>
>
> Thanks too for laying out the options for recording rights information,
> Max. There are a couple of things that I would add from my perspective of
> having worked on the requirements for enhanced conditions governing access
> and conditions governing use notes that I would want folks to think about
> before making description and usage decisions, especially since I know
> there are a lot of new adopters of 1.5.x who may not have fully explored
> this functionality.
>
>
>
> Looking at the underlying standards that govern a record in ArchivesSpace
> is important, and part of the reason that we decided to work on conditions
> governing access/use was because we were interested in using DACS guidance
> for aggregated materials. Doing description outside of the content standard
> -- rather, in lieu of the content standard used for all other records --
> seems pretty iffy to me. If it were me, I would use DACS elements for
> archival description and PREMIS elements for digital preservation
> activities.
>
>
>
> As you say, the rights module will be very good for recording atomic
> rights information on a PREMIS model. But if you're looking at an
> aggregation of materials that may have children records, ArchivesSpace
> won't know that the rights subrecord applies to the physical, lower-level
> objects that circulate in boxes the same way that it knows about access/use
> notes -- as is appropriate! I haven't yet seen a full articulation of the
> difference between rights and conditions governing access/use, beyond what
> we had created at Yale and Mary had circulated, but it seems like
> conditions governing access/use are now very good with DACS principle 7, in
> a way that there's no expectation for PREMIS rights statements to be.
>
>
>
> Indeed, the enhancements to access/use notes in 1.5.x use the archival
> principles of inheritance in a way that the rights subrecord does not plan
> to. In 1.5.x, if a series is marked as being available for research use in
> 2027, ArchivesSpace knows that all of the top containers in that series are
> not open until 2027. It won't know this about containers if rights
> subrecords are used (because rights subrecords are based on PREMIS, which
> is about electronic records -- although there's a role for aggregation in
> describing electronic records too, of course).
>
>
>
> Finally, a big part of the migration from Archivists' Toolkit to
> ArchivesSpace at Yale had to do with reconciling non-standard usage of AT.
> There had been good reasons, I know, for using fields and records in
> non-standard ways in AT at Yale, but the result was 80% of my time and 80%
> of another colleague's time for six months (and thousands of dollars toward
> contract programmers) to put the data back where it was expected so that it
> could go into ArchivesSpace smoothly. You don't want to go through that if
> you can avoid it. Plus, beyond the PUI, your EAD won't have the relevant
> access/use information you need, which may be fine eventually but for now
> won't work for inclusion in ArchiveGrid and a number of other projects that
> rely on EAD.
>
>
>
> Since I'm away from Yale and this work now
> <http://4.bp.blogspot.com/-hjyKJqD6Gz0/VEW1DU_xHzI/AAAAAAAAGFM/kjQLzEDFOOU/s1600/pullmebackin.gif>,
> I'd love to hear what others who are using 1.5.x think about this.
>
>
>
> All best,
>
> Maureen
>
>
>
> On Wed, Oct 5, 2016 at 12:27 PM, Max Eckard <eckardm at umich.edu> wrote:
>
> Hi Jordon,
>
> The purpose of the community review just started is to surface pros and
> cons and to adjust or augment the specification for a modification to the
> Rights module in ArchivesSpace accordingly.
>
> The primary reasoning behind this specification is to support atomic and
> thus machine-actionable rights statements in ArchivesSpace. However, these
> statements, like you said, can also be used as descriptive elements, and
> could display in ArchivesSpace public displays (in ArchivesSpace or in
> other discovery systems). At the end of this process, if/when this
> specification is implemented, users will have at least three basic options:
>
>    1. Use only Conditions Governing Access/Use notes.
>    2. Use only the Rights module.
>    3. Use the Conditions Governing Access/Use notes in conjunction with
>    the Rights module in the way I described above or in some other way (the
>    "we" I was referring to earlier was just the group of us that did some
>    research and wrote up the rights module).
>
> This approach accommodates the various ways institutions already use and
> want to use rights statements. Users recording rights data in the Rights
> module should have the ability to publish (or not publish) to the PUI. I
> talked with Brad briefly about this; sounds like it will need to be
> reflected in the specification and the PUI group will need to be informed
> to account for this change in its work. The specifics of that (what
> displays, what doesn't, etc.) seem like they'd still need to be worked out.
>
> Finally, this enhancement work should not result in any data being lost.
> While some current fields (like the ones you mentioned--these and others
> are written out in the "Removals" section of the "Data Migrations" table)
> are being transferred to others that support atomic statements. Actually,
> the current Permissions/Restrictions field is a good case in point. The
> migration scenarios provided in the specification indicate these changes
> and what is to happen to current data, in this case being transferred to an
> "Act" note with an appropriate label.
>
>
>
> Hope this helps and thanks again for the feedback!
>
> Max
>
>
>
> On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>
> Thanks for your response, Max. When you say ?we,? do you mean the
> Technical Advisory Council? And please forgive my limited understanding
> about the functions of the ASpace groups, but should the decision about the
> pros and cons of integration and redundancy rest with the TAC or the User
> Advisory Council?or Governance? My cursory understanding is that the UAC
> advises the TAC on what feature enhancements the TAC should implement.
> Maybe UAC and TAC have discussed this?
>
>
>
> To your point that the Rights module only should be used to manage
> machine-actionable rights information, unless you plan to change something
> in the enhancements, currently a user is not required to use the Rights
> module only for this purpose?there are notes fields that one can use to put
> rights statements that could easily live in access/use notes, too, and the
> machine-actionable features are not required to create a rights record.
>
>
>
> Also, an important implication that one of my staff mentioned yesterday is
> that it?s possible the public user interface development going on does not
> account for institutions that choose to put their access/use information in
> the rights module. Have there been discussions with the PUI group about
> this?
>
>
>
> Speaking of granularity, I have a more granular request: your attachments
> are useful, but it appears you have not provided a list of elements that
> would be eliminated if these enhancements were adopted. For instance,
> looking at your wireframes, it would appear that the free-text fields of
> ?permissions? and ?restrictions? would go away. I don?t really have an
> opinion right now on whether that?s a good idea or not, but it would be
> helpful if you could provide us with a list of fields you?re proposing to
> remove.
>
>
>
> Best,
>
>
>
> Jordon
>
>
>
> Jordon Steele
>
> Hodson Curator of the University Archives
>
> The Sheridan Libraries
>
> Johns Hopkins University
>
> 3400 N Charles St
>
> Baltimore, MD 21218
>
> 410-516-5493
>
> jsteele at jhu.edu
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
> Eckard
> *Sent:* Wednesday, October 05, 2016 9:08 AM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
> Management Enhancements specification
>
>
>
> Hi Jordan,
>
> Thanks for the feedback! This issue about the pairing of Conditions
> Governing Access/Use notes and the Rights module has definitely come up in
> our conversations.
>
> Borrowing some language from these conversations, at least for the moment
> we see the statements in the ArchivesSpace Rights module being used in
> conjunction with rights/access statements supported in the Conditions
> Governing Access and Conditions Governing Use notes. The Rights module
> statements are for granular, actionable statements, whereas the Conditions
> Governing Access/Use notes are for summary, non-actionable statements, and
> instructions, where appropriate, for contacting rights holders. That may
> turn out to be an unnecessary redundancy, and clearly there are folks like
> you that make a good case for that in theory and in practice, but that's at
> least our thinking for now.
>
> Thanks again for your input! It really is very much appreciated!
>
> Max
>
>
>
> On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>
> Max,
>
>
>
> These enhancements look good to us, thanks for your efforts.
>
>
>
> We?ve been discussing at JHU the overlap and, frankly, similarity between
> what sort of information the Rights Management module is trying to capture
> and the Conditions Governing Access/Use notes are used for, and we?re not
> seeing a difference in concept between the two.  ?Archivists have always
> used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT
> hold-over? may be factually accurate but they are not strong cases for
> continuing use.
>
>
>
> So for the sake of not over-complicating the ASpace data model--where
> equally valid locations for putting the same type of information
> proliferate and, therefore, confuse?my main feedback is that you/the
> community/whoever take a good look at integration between the access/use
> notes and the rights management module. (After review of the responses I
> received from the ASpace listserv and internal discussion, JHU has decide
> to stop using the Access/Use notes and begin to use the Rights sub-records
> to manage information about what people are allowed and not allowed to do
> with all of our collections?analog and digital.) Your work presents a good
> opportunity for us all to try to get on the same page.
>
>
>
> Best,
>
>
>
> Jordon
>
>
>
> Jordon Steele
>
> Hodson Curator of the University Archives
>
> The Sheridan Libraries
>
> Johns Hopkins University
>
> 3400 N Charles St
>
> Baltimore, MD 21218
>
> 410-516-5493
>
> jsteele at jhu.edu
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
> Eckard
> *Sent:* Monday, October 03, 2016 2:49 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Community review of Rights
> Management Enhancements specification
>
>
>
> Good morning ArchivesSpace community,
>
> You may already be aware that representatives from the ArchivesSpace
> membership, the ArchivesSpace program team and Artefactual, Inc. have been
> working on a specification for enhancing the rights module in
> ArchivesSpace.
>
> The primary aim of this specification is to enable the expression of
> standards-based rights statements that are atomic and actionable and that
> support data transfers with other applications using rights statements,
> such as Archivematica.
>
> We have completed a draft specification, and are now asking for community
> review and feedback.
>
> The attached packet includes:
>
>    - a summary of the enhancements requested in the specification and
>    their purpose;
>    - a spreadsheet containing:
>
>
>    - 1) the data model being proposed for the rights management module in
>       ArchivesSpace,
>       - 2) the data migrations necessary for moving data in the current
>       data model to the new data model,
>       - 3) a chart indicating the data elements to be migrated from
>       Archivematica to ArchivesSpace, and
>       - 4) a data map illustrating how PREMIS rights elements are
>       supported in Archivematica and ArchivesSpace; and
>
>
>    - ten wire frames illustrating how the proposed data model should be
>    reflected in the ArchivesSpace staff interface.
>
> If you need some orientation to the way that PREMIS Rights Statements are
> used (regardless of whether these are authored in ArchivesSpace), see the
> attached PDF.
>
> Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org), Hillel
> Arnold (harnold at rockarch.org) and/or myself (eckardm at umich.edu) are happy
> to answer any questions that you may have and to receive feedback on the
> specification by *Friday, October 21, 2016*.
>
> Regards,
>
> Max Eckard
>
>
> --
>
> *Max Eckard*
> *Assistant Archivist for Digital Curation*
>
>
>
> Bentley Historical Library
>
> 1150 Beal Ave.
> Ann Arbor, MI 48109-2113
> (734) 763-7518
>
> http://bentley.umich.edu/
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
>
> --
>
> *Max Eckard*
> *Assistant Archivist for Digital Curation*
>
>
>
> Bentley Historical Library
>
> 1150 Beal Ave.
> Ann Arbor, MI 48109-2113
> (734) 763-7518
>
> http://bentley.umich.edu/
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
>
> --
>
> *Max Eckard*
> *Assistant Archivist for Digital Curation*
>
>
>
> Bentley Historical Library
>
> 1150 Beal Ave.
> Ann Arbor, MI 48109-2113
> (734) 763-7518
>
> http://bentley.umich.edu/
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
>
>
> --
>
> Maureen Callahan
>
> Sophia Smith Collection Archivist
>
> Smith College Special Collections
>
> Northampton, Massachusetts 01063
>
> T. 413 585 2981 C. 215.863.1860
>
> mcallahan at smith.edu
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981 C. 215.863.1860
mcallahan at smith.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161007/4517ae8a/attachment.html>

From shallcro at umich.edu  Fri Oct  7 09:19:59 2016
From: shallcro at umich.edu (Michael Shallcross)
Date: Fri, 7 Oct 2016 09:19:59 -0400
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <CAH0VKbDEVHOc1nUN_ezM5QGEKmj+1zpuen71wdepMV8j9xSDsg@mail.gmail.com>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
 <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>
 <CAH0VKbAocZ8U-OunGU_qYsZwRmxezVG63_haTKAR39R6Yn4XEw@mail.gmail.com>
 <D41AE6E2.4A83A%harnold@rockarch.org>
 <9e569d29bf414f72932637c78a0cb9ea@ESGMTWEX6.win.ad.jhu.edu>
 <CAH0VKbDEVHOc1nUN_ezM5QGEKmj+1zpuen71wdepMV8j9xSDsg@mail.gmail.com>
Message-ID: <CAAPYHTBWGq+0K7nLRXyL93=3YWwkfFrOjR2Y7o+BGA3RBPDedA@mail.gmail.com>

Thanks for bringing up the question of just *how *PREMIS might be used to
express rights, Maureen.  We here at the Bentley (OK...Max) shared some
thoughts on how/why PREMIS rights could be useful in conjunction with more
human-readable conditions governing access/use statements:

http://archival-integration.blogspot.com/2016/02/a-primer-on-premis-and-premis-rights.html

Cheers,

Mike

--
*Michael Shallcross, CA*
*Assistant Director for Curation*

Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
734.936.1344
http://bentley.umich.edu/
@UmichBentley
http://archival-integration.blogspot.com/
@umbhlcuration



On Fri, Oct 7, 2016 at 8:48 AM, Maureen Callahan <mcallahan at smith.edu>
wrote:

> Hi Jordon,
>
> I guess it all depends on what you mean by both inheritance and
> machine-actionable. A rights statement will belong to a hierarchy in the
> same way that a higher-level scope and content note will -- it sits higher
> in the tree and we have all agreed that higher-level elements implicitly
> apply to lower-level elements. All of this data can be accessed through a
> number of means (the API, the GUI, the database) and you could set up
> systems so that machines can do actions with the data -- to look higher in
> the tree to see which rights statements apply. But ArchivesSpace itself
> won't do the work of associating a condition governing access or use (as
> expressed in rights, rather than access/use subrecords) with containers
> that are associated lower down in the hierarchy in a way that would let a
> system know whether or not a container should circulate. Here, I'm really
> strictly talking about associating machine-actionable restrictions with top
> containers. The granular restriction types and restriction begin/end dates
> in conditions governing access/use DO let you do this.
>
> It's an extremely rare occasion that I disagree with Hillel, but I do
> think that generally, it's important to remember that these systems are a
> way to make standards actionable and description manageable, but that even
> when systems go away, standards persist. My guess is that the folks who
> wrote this specification have very well-defined boundaries about the
> appropriate way to leverage PREMIS rights statements. I also think that
> this proposal is good, because PREMIS rights are meant to do different
> things than DACS conditions governing access or use statements, and there
> may be good use cases for linking this information across both
> ArchivesSpace and a digital preservation repository. But I'm also going to
> guess that not every archivist is familiar or comfortable with those
> distinctions, and it might be helpful to see an explanation of "As an
> archivist managing electronic records in a digital preservation repository,
> I want for the rights module to be in better alignment with PREMIS rights
> so that I may _______." Similarly, there's a lot baked into ArchivesSpace
> about how to write DACS-compliant description in ArchivesSpace, but I think
> that much goes unsaid there too.
>
> Thanks!
> MC
>
> On Thu, Oct 6, 2016 at 4:52 PM, Jordon Steele <jsteele at jhu.edu> wrote:
>
>> Thanks, everyone.
>>
>>
>>
>> Maureen, I was not aware that the Rights module would not follow the
>> principle of inheritance. Seems like it should, if the rights information
>> being assigned exists in context of a hierarchy.  Setting aside the
>> intricacies of what PREMIS or DACS set out to accomplish, any user would
>> logically look at a field in ASpace called ?Rights Statements? and think,
>> ?Oh, that?s where I put information about what people can and can?t do with
>> my stuff.?
>>
>>
>>
>> You also raise a good point that rights information may not map properly
>> to discovery tools like ArchiveGrid if entered in the Rights module. The
>> implication, then, is that those of us that want to manage our rights with
>> more granularity, and consolidate the locations where that rights
>> information exists, are left with some pretty serious trade-offs.
>>
>>
>>
>> I?ll say that I would be more comfortable managing my rights information
>> in the access/use notes coming from an archives/DACS tradition, but the big
>> weakness for us is that you can?t record atomic rights information in these
>> elements in the accessions module, and according to one offline response I
>> received access/use notes don?t transfer over when you spawn a resource
>> record (which sounds like a bug, can?t believe that was intentional, but I
>> digress).
>>
>>
>>
>> Here?s an idea: should we instead be focusing on moving some of the
>> rights statement functionality to access/use notes and sunsetting the
>> rights module altogether, rather than having parallel places to put the
>> same information?
>>
>>
>>
>> Which leads me to my main point. Hillel, I think you hit the nail on the
>> head: thanks to Max?s helpful replies I now realize that it is beyond the
>> scope of this project to consider how best to manage rights information in
>> ASpace; rather, this project is limited to making some informed
>> improvements to one place a user can manage rights information. So you guys
>> are off the hook! But what about the rest of us thinking about how this
>> bundle of features that add up to ASpace?are we missing a greater
>> opportunity here? I would argue that giving people more than one place to
>> put the same information is questionable product design, and now might be
>> good time to fix that. I think the argument that giving people options is a
>> collegial gesture, but I just don?t buy it.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Arnold,
>> Hillel
>> *Sent:* Wednesday, October 05, 2016 5:51 PM
>>
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Hi all,
>>
>> I just wanted to jump in to thank all of you who?ve provided feedback on
>> the proposal thus far, and to encourage others to chime in. I also wanted
>> to echo Max?s point that this specification is really addressed at
>> machine-interoperability and improving compliance with community standards
>> (in this case PREMIS).
>>
>> While those of use who pulled together this specification have use cases
>> in mind, and concrete ways in which we intend to use the proposed
>> functionality, I don?t think any of us want to prescribe how data should be
>> recorded in the application for all institutions and all use cases. The
>> community may be able to agree on approaches to recording this data (and I
>> think that conversation is useful and worthwhile), but it seems well
>> outside of the scope of this proposal.
>>
>> I?d also like to point out that the three options for recording rights
>> information that Max laid out exist in the current version of the
>> application (and probably earlier versions as well). This specification
>> doesn?t change that; in essence all it proposes is to make those structured
>> rights statements PREMIS-compliant.
>>
>> In any event, let?s keep the feedback coming!
>>
>>
>>
>> Hillel
>>
>> -----------
>>
>> Hillel Arnold
>>
>> Assistant Director, Head of Digital Programs
>>
>> Rockefeller Archive Center
>>
>> 914.366.6382
>>
>>
>>
>> *From: *<archivesspace_users_group-bounces at lyralists.lyrasis.org> on
>> behalf of Maureen Callahan <mcallahan at smith.edu>
>> *Reply-To: *Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Date: *Wednesday, October 5, 2016 at 4:31 PM
>> *To: *Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject: *Re: [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Dear Max and others,
>>
>>
>>
>> I'm so happy to see these proposed enhancements to the rights subrecord
>> to bring it in better alignment with PREMIS. This looks dope, and it looks
>> like it will make integration with digital preservation systems much easier.
>>
>>
>>
>> Thanks too for laying out the options for recording rights information,
>> Max. There are a couple of things that I would add from my perspective of
>> having worked on the requirements for enhanced conditions governing access
>> and conditions governing use notes that I would want folks to think about
>> before making description and usage decisions, especially since I know
>> there are a lot of new adopters of 1.5.x who may not have fully explored
>> this functionality.
>>
>>
>>
>> Looking at the underlying standards that govern a record in ArchivesSpace
>> is important, and part of the reason that we decided to work on conditions
>> governing access/use was because we were interested in using DACS guidance
>> for aggregated materials. Doing description outside of the content standard
>> -- rather, in lieu of the content standard used for all other records --
>> seems pretty iffy to me. If it were me, I would use DACS elements for
>> archival description and PREMIS elements for digital preservation
>> activities.
>>
>>
>>
>> As you say, the rights module will be very good for recording atomic
>> rights information on a PREMIS model. But if you're looking at an
>> aggregation of materials that may have children records, ArchivesSpace
>> won't know that the rights subrecord applies to the physical, lower-level
>> objects that circulate in boxes the same way that it knows about access/use
>> notes -- as is appropriate! I haven't yet seen a full articulation of the
>> difference between rights and conditions governing access/use, beyond what
>> we had created at Yale and Mary had circulated, but it seems like
>> conditions governing access/use are now very good with DACS principle 7, in
>> a way that there's no expectation for PREMIS rights statements to be.
>>
>>
>>
>> Indeed, the enhancements to access/use notes in 1.5.x use the archival
>> principles of inheritance in a way that the rights subrecord does not plan
>> to. In 1.5.x, if a series is marked as being available for research use in
>> 2027, ArchivesSpace knows that all of the top containers in that series are
>> not open until 2027. It won't know this about containers if rights
>> subrecords are used (because rights subrecords are based on PREMIS, which
>> is about electronic records -- although there's a role for aggregation in
>> describing electronic records too, of course).
>>
>>
>>
>> Finally, a big part of the migration from Archivists' Toolkit to
>> ArchivesSpace at Yale had to do with reconciling non-standard usage of AT.
>> There had been good reasons, I know, for using fields and records in
>> non-standard ways in AT at Yale, but the result was 80% of my time and 80%
>> of another colleague's time for six months (and thousands of dollars toward
>> contract programmers) to put the data back where it was expected so that it
>> could go into ArchivesSpace smoothly. You don't want to go through that if
>> you can avoid it. Plus, beyond the PUI, your EAD won't have the relevant
>> access/use information you need, which may be fine eventually but for now
>> won't work for inclusion in ArchiveGrid and a number of other projects that
>> rely on EAD.
>>
>>
>>
>> Since I'm away from Yale and this work now
>> <http://4.bp.blogspot.com/-hjyKJqD6Gz0/VEW1DU_xHzI/AAAAAAAAGFM/kjQLzEDFOOU/s1600/pullmebackin.gif>,
>> I'd love to hear what others who are using 1.5.x think about this.
>>
>>
>>
>> All best,
>>
>> Maureen
>>
>>
>>
>> On Wed, Oct 5, 2016 at 12:27 PM, Max Eckard <eckardm at umich.edu> wrote:
>>
>> Hi Jordon,
>>
>> The purpose of the community review just started is to surface pros and
>> cons and to adjust or augment the specification for a modification to the
>> Rights module in ArchivesSpace accordingly.
>>
>> The primary reasoning behind this specification is to support atomic and
>> thus machine-actionable rights statements in ArchivesSpace. However, these
>> statements, like you said, can also be used as descriptive elements, and
>> could display in ArchivesSpace public displays (in ArchivesSpace or in
>> other discovery systems). At the end of this process, if/when this
>> specification is implemented, users will have at least three basic options:
>>
>>    1. Use only Conditions Governing Access/Use notes.
>>    2. Use only the Rights module.
>>    3. Use the Conditions Governing Access/Use notes in conjunction with
>>    the Rights module in the way I described above or in some other way (the
>>    "we" I was referring to earlier was just the group of us that did some
>>    research and wrote up the rights module).
>>
>> This approach accommodates the various ways institutions already use and
>> want to use rights statements. Users recording rights data in the Rights
>> module should have the ability to publish (or not publish) to the PUI. I
>> talked with Brad briefly about this; sounds like it will need to be
>> reflected in the specification and the PUI group will need to be informed
>> to account for this change in its work. The specifics of that (what
>> displays, what doesn't, etc.) seem like they'd still need to be worked out.
>>
>> Finally, this enhancement work should not result in any data being lost.
>> While some current fields (like the ones you mentioned--these and others
>> are written out in the "Removals" section of the "Data Migrations" table)
>> are being transferred to others that support atomic statements. Actually,
>> the current Permissions/Restrictions field is a good case in point. The
>> migration scenarios provided in the specification indicate these changes
>> and what is to happen to current data, in this case being transferred to an
>> "Act" note with an appropriate label.
>>
>>
>>
>> Hope this helps and thanks again for the feedback!
>>
>> Max
>>
>>
>>
>> On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>>
>> Thanks for your response, Max. When you say ?we,? do you mean the
>> Technical Advisory Council? And please forgive my limited understanding
>> about the functions of the ASpace groups, but should the decision about the
>> pros and cons of integration and redundancy rest with the TAC or the User
>> Advisory Council?or Governance? My cursory understanding is that the UAC
>> advises the TAC on what feature enhancements the TAC should implement.
>> Maybe UAC and TAC have discussed this?
>>
>>
>>
>> To your point that the Rights module only should be used to manage
>> machine-actionable rights information, unless you plan to change something
>> in the enhancements, currently a user is not required to use the Rights
>> module only for this purpose?there are notes fields that one can use to put
>> rights statements that could easily live in access/use notes, too, and the
>> machine-actionable features are not required to create a rights record.
>>
>>
>>
>> Also, an important implication that one of my staff mentioned yesterday
>> is that it?s possible the public user interface development going on does
>> not account for institutions that choose to put their access/use
>> information in the rights module. Have there been discussions with the PUI
>> group about this?
>>
>>
>>
>> Speaking of granularity, I have a more granular request: your attachments
>> are useful, but it appears you have not provided a list of elements that
>> would be eliminated if these enhancements were adopted. For instance,
>> looking at your wireframes, it would appear that the free-text fields of
>> ?permissions? and ?restrictions? would go away. I don?t really have an
>> opinion right now on whether that?s a good idea or not, but it would be
>> helpful if you could provide us with a list of fields you?re proposing to
>> remove.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
>> Eckard
>> *Sent:* Wednesday, October 05, 2016 9:08 AM
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Hi Jordan,
>>
>> Thanks for the feedback! This issue about the pairing of Conditions
>> Governing Access/Use notes and the Rights module has definitely come up in
>> our conversations.
>>
>> Borrowing some language from these conversations, at least for the moment
>> we see the statements in the ArchivesSpace Rights module being used in
>> conjunction with rights/access statements supported in the Conditions
>> Governing Access and Conditions Governing Use notes. The Rights module
>> statements are for granular, actionable statements, whereas the Conditions
>> Governing Access/Use notes are for summary, non-actionable statements, and
>> instructions, where appropriate, for contacting rights holders. That may
>> turn out to be an unnecessary redundancy, and clearly there are folks like
>> you that make a good case for that in theory and in practice, but that's at
>> least our thinking for now.
>>
>> Thanks again for your input! It really is very much appreciated!
>>
>> Max
>>
>>
>>
>> On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>>
>> Max,
>>
>>
>>
>> These enhancements look good to us, thanks for your efforts.
>>
>>
>>
>> We?ve been discussing at JHU the overlap and, frankly, similarity between
>> what sort of information the Rights Management module is trying to capture
>> and the Conditions Governing Access/Use notes are used for, and we?re not
>> seeing a difference in concept between the two.  ?Archivists have always
>> used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT
>> hold-over? may be factually accurate but they are not strong cases for
>> continuing use.
>>
>>
>>
>> So for the sake of not over-complicating the ASpace data model--where
>> equally valid locations for putting the same type of information
>> proliferate and, therefore, confuse?my main feedback is that you/the
>> community/whoever take a good look at integration between the access/use
>> notes and the rights management module. (After review of the responses I
>> received from the ASpace listserv and internal discussion, JHU has decide
>> to stop using the Access/Use notes and begin to use the Rights sub-records
>> to manage information about what people are allowed and not allowed to do
>> with all of our collections?analog and digital.) Your work presents a good
>> opportunity for us all to try to get on the same page.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
>> Eckard
>> *Sent:* Monday, October 03, 2016 2:49 PM
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Good morning ArchivesSpace community,
>>
>> You may already be aware that representatives from the ArchivesSpace
>> membership, the ArchivesSpace program team and Artefactual, Inc. have been
>> working on a specification for enhancing the rights module in
>> ArchivesSpace.
>>
>> The primary aim of this specification is to enable the expression of
>> standards-based rights statements that are atomic and actionable and that
>> support data transfers with other applications using rights statements,
>> such as Archivematica.
>>
>> We have completed a draft specification, and are now asking for community
>> review and feedback.
>>
>> The attached packet includes:
>>
>>    - a summary of the enhancements requested in the specification and
>>    their purpose;
>>    - a spreadsheet containing:
>>
>>
>>    - 1) the data model being proposed for the rights management module
>>       in ArchivesSpace,
>>       - 2) the data migrations necessary for moving data in the current
>>       data model to the new data model,
>>       - 3) a chart indicating the data elements to be migrated from
>>       Archivematica to ArchivesSpace, and
>>       - 4) a data map illustrating how PREMIS rights elements are
>>       supported in Archivematica and ArchivesSpace; and
>>
>>
>>    - ten wire frames illustrating how the proposed data model should be
>>    reflected in the ArchivesSpace staff interface.
>>
>> If you need some orientation to the way that PREMIS Rights Statements are
>> used (regardless of whether these are authored in ArchivesSpace), see the
>> attached PDF.
>>
>> Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org), Hillel
>> Arnold (harnold at rockarch.org) and/or myself (eckardm at umich.edu) are
>> happy to answer any questions that you may have and to receive feedback on
>> the specification by *Friday, October 21, 2016*.
>>
>> Regards,
>>
>> Max Eckard
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>>
>> --
>>
>> Maureen Callahan
>>
>> Sophia Smith Collection Archivist
>>
>> Smith College Special Collections
>>
>> Northampton, Massachusetts 01063
>>
>> T. 413 585 2981 C. 215.863.1860
>>
>> mcallahan at smith.edu
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
>
> --
> Maureen Callahan
> Sophia Smith Collection Archivist
> Smith College Special Collections
> Northampton, Massachusetts 01063
> T. 413 585 2981 C. 215.863.1860
> mcallahan at smith.edu
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161007/46846601/attachment.html>

From jsteele at jhu.edu  Fri Oct  7 17:20:34 2016
From: jsteele at jhu.edu (Jordon Steele)
Date: Fri, 7 Oct 2016 21:20:34 +0000
Subject: [Archivesspace_Users_Group] Community review of Rights
 Management Enhancements specification
In-Reply-To: <CAAPYHTBWGq+0K7nLRXyL93=3YWwkfFrOjR2Y7o+BGA3RBPDedA@mail.gmail.com>
References: <CAOEoOqW9KkAP3a57BqQ0p70SFBf7DJAxs=ryQfxxgrmZSEVjvw@mail.gmail.com>
 <b0afc7cc1c93429d856537d4acc5d995@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqXn5KphZLgo+Q9CX+9MnSY2eXknXvmsMd3WaxEEx9kccg@mail.gmail.com>
 <75194457a82541d3980ab068d5c56e97@ESGMTWEX6.win.ad.jhu.edu>
 <CAOEoOqUSMeeCXYB28WgpLC_AdmsPQUpuROyb8Z5pr-RTNwV0Lw@mail.gmail.com>
 <CAH0VKbAocZ8U-OunGU_qYsZwRmxezVG63_haTKAR39R6Yn4XEw@mail.gmail.com>
 <D41AE6E2.4A83A%harnold@rockarch.org>
 <9e569d29bf414f72932637c78a0cb9ea@ESGMTWEX6.win.ad.jhu.edu>
 <CAH0VKbDEVHOc1nUN_ezM5QGEKmj+1zpuen71wdepMV8j9xSDsg@mail.gmail.com>
 <CAAPYHTBWGq+0K7nLRXyL93=3YWwkfFrOjR2Y7o+BGA3RBPDedA@mail.gmail.com>
Message-ID: <9437113422f04682830862d6616f99fd@ESGMTWEX6.win.ad.jhu.edu>

Mike,

Thanks! The ?Other Considerations? section is basically what I?m proposing. I am a PREMIS novice, but it strikes me as a superior solution for managing rights information than DACS notes, which is why the rights management module appeals to me.

But based on Maureen?s helpful warnings, I?m starting to doubt whether we?ll implement it, not really because of PREMIS or the rights module but because ASpace doesn?t seem to be designed well to use it in this (in my opnion, superior) manner. All the more reason to pump the breaks a bit and have a bigger conversation about how the rights statements and the access/use notes can be used in conjunction in a more direct way than just a human being knowing that this feature over here kinda relates to that feature over there.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493
jsteele at jhu.edu

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Michael Shallcross
Sent: Friday, October 07, 2016 9:20 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Thanks for bringing up the question of just how PREMIS might be used to express rights, Maureen.  We here at the Bentley (OK...Max) shared some thoughts on how/why PREMIS rights could be useful in conjunction with more human-readable conditions governing access/use statements:

http://archival-integration.blogspot.com/2016/02/a-primer-on-premis-and-premis-rights.html

Cheers,

Mike

--
Michael Shallcross, CA
Assistant Director for Curation
[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
734.936.1344
http://bentley.umich.edu/
@UmichBentley
http://archival-integration.blogspot.com/
@umbhlcuration



On Fri, Oct 7, 2016 at 8:48 AM, Maureen Callahan <mcallahan at smith.edu<mailto:mcallahan at smith.edu>> wrote:
Hi Jordon,

I guess it all depends on what you mean by both inheritance and machine-actionable. A rights statement will belong to a hierarchy in the same way that a higher-level scope and content note will -- it sits higher in the tree and we have all agreed that higher-level elements implicitly apply to lower-level elements. All of this data can be accessed through a number of means (the API, the GUI, the database) and you could set up systems so that machines can do actions with the data -- to look higher in the tree to see which rights statements apply. But ArchivesSpace itself won't do the work of associating a condition governing access or use (as expressed in rights, rather than access/use subrecords) with containers that are associated lower down in the hierarchy in a way that would let a system know whether or not a container should circulate. Here, I'm really strictly talking about associating machine-actionable restrictions with top containers. The granular restriction types and restriction begin/end dates in conditions governing access/use DO let you do this.

It's an extremely rare occasion that I disagree with Hillel, but I do think that generally, it's important to remember that these systems are a way to make standards actionable and description manageable, but that even when systems go away, standards persist. My guess is that the folks who wrote this specification have very well-defined boundaries about the appropriate way to leverage PREMIS rights statements. I also think that this proposal is good, because PREMIS rights are meant to do different things than DACS conditions governing access or use statements, and there may be good use cases for linking this information across both ArchivesSpace and a digital preservation repository. But I'm also going to guess that not every archivist is familiar or comfortable with those distinctions, and it might be helpful to see an explanation of "As an archivist managing electronic records in a digital preservation repository, I want for the rights module to be in better alignment with PREMIS rights so that I may _______." Similarly, there's a lot baked into ArchivesSpace about how to write DACS-compliant description in ArchivesSpace, but I think that much goes unsaid there too.

Thanks!
MC

On Thu, Oct 6, 2016 at 4:52 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Thanks, everyone.

Maureen, I was not aware that the Rights module would not follow the principle of inheritance. Seems like it should, if the rights information being assigned exists in context of a hierarchy.  Setting aside the intricacies of what PREMIS or DACS set out to accomplish, any user would logically look at a field in ASpace called ?Rights Statements? and think, ?Oh, that?s where I put information about what people can and can?t do with my stuff.?

You also raise a good point that rights information may not map properly to discovery tools like ArchiveGrid if entered in the Rights module. The implication, then, is that those of us that want to manage our rights with more granularity, and consolidate the locations where that rights information exists, are left with some pretty serious trade-offs.

I?ll say that I would be more comfortable managing my rights information in the access/use notes coming from an archives/DACS tradition, but the big weakness for us is that you can?t record atomic rights information in these elements in the accessions module, and according to one offline response I received access/use notes don?t transfer over when you spawn a resource record (which sounds like a bug, can?t believe that was intentional, but I digress).

Here?s an idea: should we instead be focusing on moving some of the rights statement functionality to access/use notes and sunsetting the rights module altogether, rather than having parallel places to put the same information?

Which leads me to my main point. Hillel, I think you hit the nail on the head: thanks to Max?s helpful replies I now realize that it is beyond the scope of this project to consider how best to manage rights information in ASpace; rather, this project is limited to making some informed improvements to one place a user can manage rights information. So you guys are off the hook! But what about the rest of us thinking about how this bundle of features that add up to ASpace?are we missing a greater opportunity here? I would argue that giving people more than one place to put the same information is questionable product design, and now might be good time to fix that. I think the argument that giving people options is a collegial gesture, but I just don?t buy it.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Arnold, Hillel
Sent: Wednesday, October 05, 2016 5:51 PM

To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Hi all,
I just wanted to jump in to thank all of you who?ve provided feedback on the proposal thus far, and to encourage others to chime in. I also wanted to echo Max?s point that this specification is really addressed at machine-interoperability and improving compliance with community standards (in this case PREMIS).
While those of use who pulled together this specification have use cases in mind, and concrete ways in which we intend to use the proposed functionality, I don?t think any of us want to prescribe how data should be recorded in the application for all institutions and all use cases. The community may be able to agree on approaches to recording this data (and I think that conversation is useful and worthwhile), but it seems well outside of the scope of this proposal.
I?d also like to point out that the three options for recording rights information that Max laid out exist in the current version of the application (and probably earlier versions as well). This specification doesn?t change that; in essence all it proposes is to make those structured rights statements PREMIS-compliant.
In any event, let?s keep the feedback coming!

Hillel
-----------
Hillel Arnold
Assistant Director, Head of Digital Programs
Rockefeller Archive Center
914.366.6382<tel:914.366.6382>

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Maureen Callahan <mcallahan at smith.edu<mailto:mcallahan at smith.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Wednesday, October 5, 2016 at 4:31 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Dear Max and others,

I'm so happy to see these proposed enhancements to the rights subrecord to bring it in better alignment with PREMIS. This looks dope, and it looks like it will make integration with digital preservation systems much easier.

Thanks too for laying out the options for recording rights information, Max. There are a couple of things that I would add from my perspective of having worked on the requirements for enhanced conditions governing access and conditions governing use notes that I would want folks to think about before making description and usage decisions, especially since I know there are a lot of new adopters of 1.5.x who may not have fully explored this functionality.

Looking at the underlying standards that govern a record in ArchivesSpace is important, and part of the reason that we decided to work on conditions governing access/use was because we were interested in using DACS guidance for aggregated materials. Doing description outside of the content standard -- rather, in lieu of the content standard used for all other records -- seems pretty iffy to me. If it were me, I would use DACS elements for archival description and PREMIS elements for digital preservation activities.

As you say, the rights module will be very good for recording atomic rights information on a PREMIS model. But if you're looking at an aggregation of materials that may have children records, ArchivesSpace won't know that the rights subrecord applies to the physical, lower-level objects that circulate in boxes the same way that it knows about access/use notes -- as is appropriate! I haven't yet seen a full articulation of the difference between rights and conditions governing access/use, beyond what we had created at Yale and Mary had circulated, but it seems like conditions governing access/use are now very good with DACS principle 7, in a way that there's no expectation for PREMIS rights statements to be.

Indeed, the enhancements to access/use notes in 1.5.x use the archival principles of inheritance in a way that the rights subrecord does not plan to. In 1.5.x, if a series is marked as being available for research use in 2027, ArchivesSpace knows that all of the top containers in that series are not open until 2027. It won't know this about containers if rights subrecords are used (because rights subrecords are based on PREMIS, which is about electronic records -- although there's a role for aggregation in describing electronic records too, of course).

Finally, a big part of the migration from Archivists' Toolkit to ArchivesSpace at Yale had to do with reconciling non-standard usage of AT. There had been good reasons, I know, for using fields and records in non-standard ways in AT at Yale, but the result was 80% of my time and 80% of another colleague's time for six months (and thousands of dollars toward contract programmers) to put the data back where it was expected so that it could go into ArchivesSpace smoothly. You don't want to go through that if you can avoid it. Plus, beyond the PUI, your EAD won't have the relevant access/use information you need, which may be fine eventually but for now won't work for inclusion in ArchiveGrid and a number of other projects that rely on EAD.

Since I'm away from Yale and this work now<http://4.bp.blogspot.com/-hjyKJqD6Gz0/VEW1DU_xHzI/AAAAAAAAGFM/kjQLzEDFOOU/s1600/pullmebackin.gif>, I'd love to hear what others who are using 1.5.x think about this.

All best,
Maureen

On Wed, Oct 5, 2016 at 12:27 PM, Max Eckard <eckardm at umich.edu<mailto:eckardm at umich.edu>> wrote:
Hi Jordon,
The purpose of the community review just started is to surface pros and cons and to adjust or augment the specification for a modification to the Rights module in ArchivesSpace accordingly.

The primary reasoning behind this specification is to support atomic and thus machine-actionable rights statements in ArchivesSpace. However, these statements, like you said, can also be used as descriptive elements, and could display in ArchivesSpace public displays (in ArchivesSpace or in other discovery systems). At the end of this process, if/when this specification is implemented, users will have at least three basic options:

  1.  Use only Conditions Governing Access/Use notes.
  2.  Use only the Rights module.
  3.  Use the Conditions Governing Access/Use notes in conjunction with the Rights module in the way I described above or in some other way (the "we" I was referring to earlier was just the group of us that did some research and wrote up the rights module).
This approach accommodates the various ways institutions already use and want to use rights statements. Users recording rights data in the Rights module should have the ability to publish (or not publish) to the PUI. I talked with Brad briefly about this; sounds like it will need to be reflected in the specification and the PUI group will need to be informed to account for this change in its work. The specifics of that (what displays, what doesn't, etc.) seem like they'd still need to be worked out.
Finally, this enhancement work should not result in any data being lost. While some current fields (like the ones you mentioned--these and others are written out in the "Removals" section of the "Data Migrations" table) are being transferred to others that support atomic statements. Actually, the current Permissions/Restrictions field is a good case in point. The migration scenarios provided in the specification indicate these changes and what is to happen to current data, in this case being transferred to an "Act" note with an appropriate label.

Hope this helps and thanks again for the feedback!
Max

On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Thanks for your response, Max. When you say ?we,? do you mean the Technical Advisory Council? And please forgive my limited understanding about the functions of the ASpace groups, but should the decision about the pros and cons of integration and redundancy rest with the TAC or the User Advisory Council?or Governance? My cursory understanding is that the UAC advises the TAC on what feature enhancements the TAC should implement. Maybe UAC and TAC have discussed this?

To your point that the Rights module only should be used to manage machine-actionable rights information, unless you plan to change something in the enhancements, currently a user is not required to use the Rights module only for this purpose?there are notes fields that one can use to put rights statements that could easily live in access/use notes, too, and the machine-actionable features are not required to create a rights record.

Also, an important implication that one of my staff mentioned yesterday is that it?s possible the public user interface development going on does not account for institutions that choose to put their access/use information in the rights module. Have there been discussions with the PUI group about this?

Speaking of granularity, I have a more granular request: your attachments are useful, but it appears you have not provided a list of elements that would be eliminated if these enhancements were adopted. For instance, looking at your wireframes, it would appear that the free-text fields of ?permissions? and ?restrictions? would go away. I don?t really have an opinion right now on whether that?s a good idea or not, but it would be helpful if you could provide us with a list of fields you?re proposing to remove.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Max Eckard
Sent: Wednesday, October 05, 2016 9:08 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Hi Jordan,
Thanks for the feedback! This issue about the pairing of Conditions Governing Access/Use notes and the Rights module has definitely come up in our conversations.

Borrowing some language from these conversations, at least for the moment we see the statements in the ArchivesSpace Rights module being used in conjunction with rights/access statements supported in the Conditions Governing Access and Conditions Governing Use notes. The Rights module statements are for granular, actionable statements, whereas the Conditions Governing Access/Use notes are for summary, non-actionable statements, and instructions, where appropriate, for contacting rights holders. That may turn out to be an unnecessary redundancy, and clearly there are folks like you that make a good case for that in theory and in practice, but that's at least our thinking for now.
Thanks again for your input! It really is very much appreciated!
Max

On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Max,

These enhancements look good to us, thanks for your efforts.

We?ve been discussing at JHU the overlap and, frankly, similarity between what sort of information the Rights Management module is trying to capture and the Conditions Governing Access/Use notes are used for, and we?re not seeing a difference in concept between the two.  ?Archivists have always used the Access/Use notes? or ?Access/Use notes are an EAD/DACS/AT hold-over? may be factually accurate but they are not strong cases for continuing use.

So for the sake of not over-complicating the ASpace data model--where equally valid locations for putting the same type of information proliferate and, therefore, confuse?my main feedback is that you/the community/whoever take a good look at integration between the access/use notes and the rights management module. (After review of the responses I received from the ASpace listserv and internal discussion, JHU has decide to stop using the Access/Use notes and begin to use the Rights sub-records to manage information about what people are allowed and not allowed to do with all of our collections?analog and digital.) Your work presents a good opportunity for us all to try to get on the same page.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Max Eckard
Sent: Monday, October 03, 2016 2:49 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Good morning ArchivesSpace community,
You may already be aware that representatives from the ArchivesSpace membership, the ArchivesSpace program team and Artefactual, Inc. have been working on a specification for enhancing the rights module in ArchivesSpace.

The primary aim of this specification is to enable the expression of standards-based rights statements that are atomic and actionable and that support data transfers with other applications using rights statements, such as Archivematica.
We have completed a draft specification, and are now asking for community review and feedback.

The attached packet includes:

  *   a summary of the enhancements requested in the specification and their purpose;
  *   a spreadsheet containing:

     *   1) the data model being proposed for the rights management module in ArchivesSpace,
     *   2) the data migrations necessary for moving data in the current data model to the new data model,
     *   3) a chart indicating the data elements to be migrated from Archivematica to ArchivesSpace, and
     *   4) a data map illustrating how PREMIS rights elements are supported in Archivematica and ArchivesSpace; and

  *   ten wire frames illustrating how the proposed data model should be reflected in the ArchivesSpace staff interface.

If you need some orientation to the way that PREMIS Rights Statements are used (regardless of whether these are authored in ArchivesSpace), see the attached PDF.

Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org<http://lyrasis.org>), Hillel Arnold (harnold at rockarch.org<http://rockarch.org>) and/or myself (eckardm at umich.edu<mailto:eckardm at umich.edu>) are happy to answer any questions that you may have and to receive feedback on the specification by Friday, October 21, 2016.
Regards,
Max Eckard

--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

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



--
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981<tel:413%20585%202981> C. 215.863.1860<tel:215.863.1860>
mcallahan at smith.edu<mailto:mcallahan at smith.edu>

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



--
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981<tel:413%20585%202981> C. 215.863.1860<tel:215.863.1860>
mcallahan at smith.edu<mailto:mcallahan at smith.edu>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161007/8872dc71/attachment-0001.html>

From Scott.Renton at ed.ac.uk  Mon Oct 10 09:58:29 2016
From: Scott.Renton at ed.ac.uk (RENTON Scott)
Date: Mon, 10 Oct 2016 13:58:29 +0000
Subject: [Archivesspace_Users_Group] Slow Performance- Admin Area
Message-ID: <ED0172F5-6CC2-4C46-A778-C9F3504EFAD6@ed.ac.uk>

Hi folks

Our major user, Grant Buttars, has noticed slowness in the performance of his Archives Space installation, specifically in the Admin Area- he says it?s particularly noticeable when building hierarchies (he was wondering if there was anything in that that?s JavaScript driven). We?ve tried upping the CATALINA_OPTS and lowering the logging level in config.rb, and our next step is probably going to be to get a robots.txt in place (although I do wonder if that will help, given the Admin Area is secure). Just wondering if any other users have taken steps to improve performance and if there?s any advice I should heed!

Grant may be able to give a bit more info about the problem if he sees this.

Thanks very much indeed
Scott
--
Scott Renton
Digital Development
Library and University Collections
Argyle House, Floor F
ext: 515219

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161010/7834e281/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161010/7834e281/attachment.ksh>

From PGalligan at rockarch.org  Mon Oct 10 10:55:53 2016
From: PGalligan at rockarch.org (Galligan, Patrick)
Date: Mon, 10 Oct 2016 10:55:53 -0400
Subject: [Archivesspace_Users_Group] Container type in EAD export
Message-ID: <F6E0CB227A713F4AA8F9598060B8F063D8BED23862@racex01>

Hi all,

We've noticed that when no container type is selected in version 1.5.1, the EAD exporter automatically assigns the container a type of 'box'.

Is this intended behavior? I'd guess not since the container type is not a required field in the top container functionality.

Patrick Galligan
Rockefeller Archive Center
Digital Archivist
914-366-6386

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161010/c124019c/attachment.html>

From noah.huffman at duke.edu  Mon Oct 10 15:22:04 2016
From: noah.huffman at duke.edu (Noah Huffman)
Date: Mon, 10 Oct 2016 19:22:04 +0000
Subject: [Archivesspace_Users_Group] Unable to browse location records
Message-ID: <CO1PR05MB329C5F37AE3275F2C616F7AE6DB0@CO1PR05MB329.namprd05.prod.outlook.com>

Hi all,

After upgrading to v1.5.1, I'm getting a NoMethodError when I try to browse location records in the staff interface.  Has anyone else experienced this?  Curiously, I'm able to search for locations by keyword and then facet on record type (location), I just can't browse locations.  The location typeahead is also working properly.
 
Here is the text of the error:

++++++++
 
NoMethodError in LocationsController#index

undefined method `[]=' for nil:NilClass
Rails.root: /srv/duke/apps/archivesspace-v1.5.1/data/tmp/jetty-0.0.0.0-8080-frontend.war-_-any-/webapp/WEB-INF

Application Trace | Framework Trace | Full Trace
app/models/search.rb:16:in `all'
app/models/search.rb:8:in `for_type'
app/controllers/locations_controller.rb:14:in `index'
app/controllers/locations_controller.rb:12:in `index'

++++++++

Does anyone have any idea what might be going on here?

Thanks!
-Noah

From Joshua.D.Shaw at dartmouth.edu  Tue Oct 11 10:22:18 2016
From: Joshua.D.Shaw at dartmouth.edu (Joshua D. Shaw)
Date: Tue, 11 Oct 2016 14:22:18 +0000
Subject: [Archivesspace_Users_Group] Unable to browse location records
In-Reply-To: <CO1PR05MB329C5F37AE3275F2C616F7AE6DB0@CO1PR05MB329.namprd05.prod.outlook.com>
References: <CO1PR05MB329C5F37AE3275F2C616F7AE6DB0@CO1PR05MB329.namprd05.prod.outlook.com>
Message-ID: <DM5PR03MB2972CAE79ABC0102AD24B92FABDA0@DM5PR03MB2972.namprd03.prod.outlook.com>

Hi Noah-


I've gotten a similar error for records that were imported directly but were missing some required fields. Perhaps something similar in your case?


Joshua

________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Noah Huffman <noah.huffman at duke.edu>
Sent: Monday, October 10, 2016 3:22:04 PM
To: 'Archivesspace_Users_Group at lyralists.lyrasis.org'
Subject: [Archivesspace_Users_Group] Unable to browse location records

Hi all,

After upgrading to v1.5.1, I'm getting a NoMethodError when I try to browse location records in the staff interface.  Has anyone else experienced this?  Curiously, I'm able to search for locations by keyword and then facet on record type (location), I just can't browse locations.  The location typeahead is also working properly.

Here is the text of the error:

++++++++

NoMethodError in LocationsController#index

undefined method `[]=' for nil:NilClass
Rails.root: /srv/duke/apps/archivesspace-v1.5.1/data/tmp/jetty-0.0.0.0-8080-frontend.war-_-any-/webapp/WEB-INF

Application Trace | Framework Trace | Full Trace
app/models/search.rb:16:in `all'
app/models/search.rb:8:in `for_type'
app/controllers/locations_controller.rb:14:in `index'
app/controllers/locations_controller.rb:12:in `index'

++++++++

Does anyone have any idea what might be going on here?

Thanks!
-Noah
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/e2d98ecc/attachment.html>

From noah.huffman at duke.edu  Tue Oct 11 10:32:53 2016
From: noah.huffman at duke.edu (Noah Huffman)
Date: Tue, 11 Oct 2016 14:32:53 +0000
Subject: [Archivesspace_Users_Group] Unable to browse location records
In-Reply-To: <DM5PR03MB2972CAE79ABC0102AD24B92FABDA0@DM5PR03MB2972.namprd03.prod.outlook.com>
References: <CO1PR05MB329C5F37AE3275F2C616F7AE6DB0@CO1PR05MB329.namprd05.prod.outlook.com>
 <DM5PR03MB2972CAE79ABC0102AD24B92FABDA0@DM5PR03MB2972.namprd03.prod.outlook.com>
Message-ID: <CO1PR05MB329E9AFEBB79B3122F569F7E6DA0@CO1PR05MB329.namprd05.prod.outlook.com>

Thanks Joshua.  I think we might have pinned this down on a failure to upgrade our external Solr schema to the latest version.

We're also getting this error in the logs:
org.apache.solr.common.SolrException: undefined field: "location_profile_display_string_u_ssort"

It looks like this field was added to the Solr schema recently.

-Noah


From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Joshua D. Shaw
Sent: Tuesday, October 11, 2016 10:22 AM
To: 'Archivesspace_Users_Group at lyralists.lyrasis.org' <Archivesspace_Users_Group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Unable to browse location records


Hi Noah-



I've gotten a similar error for records that were imported directly but were missing some required fields. Perhaps something similar in your case?



Joshua

________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>>
Sent: Monday, October 10, 2016 3:22:04 PM
To: 'Archivesspace_Users_Group at lyralists.lyrasis.org'
Subject: [Archivesspace_Users_Group] Unable to browse location records

Hi all,

After upgrading to v1.5.1, I'm getting a NoMethodError when I try to browse location records in the staff interface.  Has anyone else experienced this?  Curiously, I'm able to search for locations by keyword and then facet on record type (location), I just can't browse locations.  The location typeahead is also working properly.

Here is the text of the error:

++++++++

NoMethodError in LocationsController#index

undefined method `[]=' for nil:NilClass
Rails.root: /srv/duke/apps/archivesspace-v1.5.1/data/tmp/jetty-0.0.0.0-8080-frontend.war-_-any-/webapp/WEB-INF

Application Trace | Framework Trace | Full Trace
app/models/search.rb:16:in `all'
app/models/search.rb:8:in `for_type'
app/controllers/locations_controller.rb:14:in `index'
app/controllers/locations_controller.rb:12:in `index'

++++++++

Does anyone have any idea what might be going on here?

Thanks!
-Noah
_______________________________________________
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=CwMFAg&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko&m=dKZgCNwqk5vPeve44S6AC_Lgp6n_n-i7XMcbBvbLn-E&s=mhnO7UiU3RxjIpMnVvRdwdzdkplb1ATx5rXKlcyoz8w&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/69b22158/attachment.html>

From NHOSBURGH at Rollins.edu  Tue Oct 11 13:47:06 2016
From: NHOSBURGH at Rollins.edu (Nathan Hosburgh)
Date: Tue, 11 Oct 2016 17:47:06 +0000
Subject: [Archivesspace_Users_Group] CSS changes clarification
Message-ID: <CY1PR02MB13984A72769CDC02EC0A27A9B9DA0@CY1PR02MB1398.namprd02.prod.outlook.com>

We are attempting to do some CSS customizations and I'm following the directions under "I just want to add a few CSS rules" here<http://archivesspace.github.io/archivesspace/user/customizing-and-theming-archivesspace/>.

There are specific directions to create a file called archivesspace/plugins/local/frontend/views/layout_head.html.erb and add the line:
<%= stylesheet_link_tag "#{@base_url}/assets/custom.css" %>

Should I actually insert our "base url" (in our case http://aspace.rollins.edu) above so that it would read:

<%= stylesheet_link_tag "#{@http://aspace.rollins.edu}/assets/custom.css" %>

Thanks
Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/78153f4a/attachment.html>

From LawlorS at tncc.edu  Tue Oct 11 14:32:19 2016
From: LawlorS at tncc.edu (Lawlor, Susan)
Date: Tue, 11 Oct 2016 18:32:19 +0000
Subject: [Archivesspace_Users_Group] Unwanted Pre-populated of
	record	fields
In-Reply-To: <CY1PR0801MB0842590495628400CD25260BF1C80@CY1PR0801MB0842.namprd08.prod.outlook.com>
References: <BN6PR01MB26911F50BB6C8122DFC42313C2C90@BN6PR01MB2691.prod.exchangelabs.com>
 <CY1PR0801MB0842590495628400CD25260BF1C80@CY1PR0801MB0842.namprd08.prod.outlook.com>
Message-ID: <MWHPR01MB27020429E527B9C060673FE6C2DA0@MWHPR01MB2702.prod.exchangelabs.com>

Follow up on this problem, just in case anyone else experiences it.   What Christine described was the issue, the unintended population of fields was occurring when we tried to start a new sibling record before the old one had completely finished loading.  A little patience solves the problem.

Susan

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Christine Di Bella
Sent: Friday, September 23, 2016 1:51 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Unwanted Pre-populated of record fields

Dear Susan,

Since you're hosted by LYRASIS, it sounds like you may have heard more from LYRASIS tech folks since this message, but what you're describing sounds like it may be related to the loading time for the record. Perhaps requesting a new sibling record is happening before the original record has completely loaded (or saved, depending on the sequence). Does this behavior happen on only records of a certain size or complexity? Are you seeing noticeable slowness in other ArchivesSpace or non-ArchivesSpace functions?

Christine

Christine Di Bella
Community Outreach Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)
[cid:image003.png at 01CE734E.FD759D30]



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 Lawlor, Susan
Sent: Thursday, September 22, 2016 4:30 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Unwanted Pre-populated of record fields

We've started having a bizarre, intermittent problem when adding sibling records.  We'll have a record highlighted in Edit mode, and click on Add Sibling.  A blank archival object record appears and then a few seconds later, all the fields populate with the data from the previous record.  If we try deleting and typing over the data and saving a new record, it instead overwrites the old one. So we are effectively prevented from adding a sibling record.

Has anyone else ever seen anything like this?  We're a Lyrasis hosted site, and we're already walked through the process with Lyrasis support desk and they couldn't figure out what was going wrong.  We've tried different browsers, and have already checked the repository settings, Pro-populate Records in NOT checked anywhere.



Susan Lawlor
Technical Services Librarian
99 Thomas Nelson Drive
Hampton, VA 23666
Tel: 757.825.3530
Fax: 757.825.2870
E-mail: lawlors at tncc.edu<mailto:lawlors at tncc.edu>

[cid:image001.png at 01CF7437.0A084090]

 Success. It's closer than you think.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/dfb852dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7645 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/dfb852dd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 37790 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/dfb852dd/attachment-0001.png>

From amadkins at cpp.edu  Tue Oct 11 16:10:49 2016
From: amadkins at cpp.edu (Alexis Adkins)
Date: Tue, 11 Oct 2016 20:10:49 +0000
Subject: [Archivesspace_Users_Group] Permissions to delete components
Message-ID: <SN1PR01MB1695176558B4867C929B786BD5DA0@SN1PR01MB1695.prod.exchangelabs.com>

Hi all,

What functions need to be enabled in a permission group profile to allow members of that group to delete components?

Thanks,
Alexis

Alexis Adkins
Archivist
Special Collections and Archives
University Library
California State Polytechnic University, Pomona

amadkins at cpp.edu
909-869-3092


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/58eaeb65/attachment.html>

From lmcphee at ucsd.edu  Tue Oct 11 18:41:52 2016
From: lmcphee at ucsd.edu (McPhee, Laurel)
Date: Tue, 11 Oct 2016 22:41:52 +0000
Subject: [Archivesspace_Users_Group] Permissions to delete components
In-Reply-To: <SN1PR01MB1695176558B4867C929B786BD5DA0@SN1PR01MB1695.prod.exchangelabs.com>
References: <SN1PR01MB1695176558B4867C929B786BD5DA0@SN1PR01MB1695.prod.exchangelabs.com>
Message-ID: <3975740D6A5FF946B2A77B95A7B228D73ABA0C9A@XMAIL-MBX-AV1.AD.UCSD.EDU>

Hi Alexis,

I believe you're looking to check the box next to "delete the major record types in this repository" from the list of options.

Best,
Laurel

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Alexis Adkins
Sent: Tuesday, October 11, 2016 1:11 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Permissions to delete components

Hi all,

What functions need to be enabled in a permission group profile to allow members of that group to delete components?

Thanks,
Alexis

Alexis Adkins
Archivist
Special Collections and Archives
University Library
California State Polytechnic University, Pomona

amadkins at cpp.edu<mailto:amadkins at cpp.edu>
909-869-3092


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/648142fe/attachment.html>

From carol.mandel at nyu.edu  Tue Oct 11 19:25:02 2016
From: carol.mandel at nyu.edu (Carol A Mandel)
Date: Tue, 11 Oct 2016 19:25:02 -0400
Subject: [Archivesspace_Users_Group] ArchivesSpace Board update
Message-ID: <a8f2ab72207cae248b349ec38f2c7a27@mail.gmail.com>

Dear ArchivesSpace members,



I am writing to report on the ArchivesSpace Governance Board 1st Quarter
meeting which was held Monday, September 19, 2016.    We met in person in
Chicago.



During the meeting, I was honored to be elected to another term as chair
for 2016-2018.



We were pleased to welcome three new board members:

?                  Alston Cobourn is the Digital Scholarship Librarian at
Washington and Lee University. She represents the small membership level.

?                  Gregor Trinkhaus-Randall is the new liaison to the
ArchivesSpace Board from the LYRASIS Board.  He was most recently the Vice
Chair of the LYRASIS board and a former SAA President.  Gregor succeeds Jay
Schafer as the LYRASIS Board Liaison. We thank Jay for his service.

?                  Audra Eagle Yun is the Head of Special Collections &
Archives and University Archivist from University of California, Irvine.
She represents the very large membership level.



We know that your highest priority is the continued improvement of the
functionality of the software and we are working to ensure the best
processes to achieve that.  In Chicago, we unanimously agreed to change the
budgeted Developer position to a Tech Lead position.  This will allow for
stronger technical leadership on behalf of and in engagement with the
community, more proactive code contribution from both the user community
and the Tech Lead Position itself, and better coordination with 3rd party
vendor code development. Upgrading this position will not slow down any of
the hiring process or the technical development process. The Board?s
continuing objective is to ensure that membership dues are invested in the
most effective way to meet the community?s needs.



We also approved a plan for increasing support for members.  The
ArchivesSpace staff and the ArchivesSpace member community are excellent
resources, but sometimes members have more advanced technical questions.
This fall, we will be working with LYRASIS Technology Services to offer a
part time support position to answer technical questions on a wide variety
of topics, such upgrading to v1.5, local installations, data migrations,
and more. We will be finalizing this arrangement in the weeks ahead and
will have a more formal announcement soon.



Other areas covered during the 1st Quarter Board meeting included:

?                  Reviewing training options - training videos were added
to the ArchivesSpace wiki in the last quarter and are seeing high use; we
continue to explore new ways to strengthen training opportunities

?                  Working to update the ASpace membership agreement

?                  Developing the process and timeline of the 5 year
organizational home review which will be coming due in June of 2018



In closing, while we are not resting on our laurels, I am very happy to
report that the ArchivesSpace program is fiscally sustainable, is vibrant
and is growing at a steady rate.   As of September, there are 301 members
across the five membership levels, 10 Educational members, and three
Registered Service Providers hosting 65 ArchivesSpace databases.



The Board welcomes your communications and comments to any and all of us,
and we extend our thanks to all of you for your continuing support and
ongoing contributions to the community we are building.



Respectfully,

Carol A. Mandel

Chair, ArchivesSpace Governance Board
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/76c27400/attachment.html>

From kayla.skillin at boston.gov  Tue Oct 11 16:02:19 2016
From: kayla.skillin at boston.gov (Kayla Skillin)
Date: Tue, 11 Oct 2016 16:02:19 -0400
Subject: [Archivesspace_Users_Group] Unable to change title of an item
Message-ID: <CALSLJ1SvvHWenO1iHr5GqYLCZMOcLdncvGr3_DQQsbDJ3_0M3w@mail.gmail.com>

Hello all,

I am doing some cleanup in our item level photograph records and have come
across an issue. I am trying to update the titles of some of our items and
I am receiving an error message (please see image attached).

[image: Inline image 1]

My coworker, who is our admin, tried to do it as well but received the same
message. We exported the EAD to make sure there were no duplicate Ref IDs
or component IDs and we confirmed that there were not. I also cleared my
browsing history and cookies just to double check.

Does anyone have any solutions for this error message?

Thanks in advance!
Kayla

[image: Digital_City_Seal_black.png]

Kayla Skillin

Assistant Archivist

City of Boston Office of the City Clerk
Archives and Records Management Division

617.635.1195 (w)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/4ef51421/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13235 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161011/4ef51421/attachment.png>

From christy.tomecek at yale.edu  Wed Oct 12 08:40:17 2016
From: christy.tomecek at yale.edu (Tomecek, Christy)
Date: Wed, 12 Oct 2016 12:40:17 +0000
Subject: [Archivesspace_Users_Group] Unable to change title of an item
In-Reply-To: <CALSLJ1SvvHWenO1iHr5GqYLCZMOcLdncvGr3_DQQsbDJ3_0M3w@mail.gmail.com>
References: <CALSLJ1SvvHWenO1iHr5GqYLCZMOcLdncvGr3_DQQsbDJ3_0M3w@mail.gmail.com>
Message-ID: <BN3PR08MB185732ABF6F4DC5C305E7D7D8FDD0@BN3PR08MB1857.namprd08.prod.outlook.com>

Hi Kayla,

We get the same error here when we import an EAD into ASpace. (the string after the record number is different by one number: @archival_object-1__for_key__uniq_ao_pos_) We?re not sure what causes the error, but it resolves when we resync the record. Was this finding aid imported into ASpace?

Best,
Christy
--

Christy Tomecek
Archives Assistant
Manuscripts and Archives
Yale University Library
203-432-7382
christy.tomecek at yale.edu



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kayla Skillin
Sent: Tuesday, October 11, 2016 4:02 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Unable to change title of an item

Hello all,

I am doing some cleanup in our item level photograph records and have come across an issue. I am trying to update the titles of some of our items and I am receiving an error message (please see image attached).

[Inline image 1]

My coworker, who is our admin, tried to do it as well but received the same message. We exported the EAD to make sure there were no duplicate Ref IDs or component IDs and we confirmed that there were not. I also cleared my browsing history and cookies just to double check.

Does anyone have any solutions for this error message?

Thanks in advance!
Kayla


[Digital_City_Seal_black.png]


Kayla Skillin

Assistant Archivist

City of Boston Office of the City Clerk
Archives and Records Management Division

617.635.1195 (w)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161012/9a98ae64/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 13675 bytes
Desc: image003.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161012/9a98ae64/attachment.png>

From smithkr at mit.edu  Wed Oct 12 11:00:54 2016
From: smithkr at mit.edu (Kari R Smith)
Date: Wed, 12 Oct 2016 15:00:54 +0000
Subject: [Archivesspace_Users_Group] Data migration problem ATK -
 ArchivesSpace only specific Resource records not transferred
Message-ID: <29F559819ACA9A4FBF208407D4B63ABBF4AA4F59@OC11expo28.exchange.mit.edu>

Hello,
In our recent data migration from ATK to ArchivesSpace there were 6 Resource records that did not transfer.  We have the IDs of the records.  The components, Names, Accession records associated all transferred.

Is there a way to run the migrator tool for just the 6 specific collections?  Or am I best off doing an EAD XML export from ATK and then Importing those into ArchivesSpace?

Thanks!

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161012/05ffbf64/attachment.html>

From noah.huffman at duke.edu  Wed Oct 12 14:50:10 2016
From: noah.huffman at duke.edu (Noah Huffman)
Date: Wed, 12 Oct 2016 18:50:10 +0000
Subject: [Archivesspace_Users_Group] Data migration problem ATK -
 ArchivesSpace only specific Resource records not transferred
In-Reply-To: <29F559819ACA9A4FBF208407D4B63ABBF4AA4F59@OC11expo28.exchange.mit.edu>
References: <29F559819ACA9A4FBF208407D4B63ABBF4AA4F59@OC11expo28.exchange.mit.edu>
Message-ID: <BN1PR05MB325739E4F80137A2FF3DB88E6DD0@BN1PR05MB325.namprd05.prod.outlook.com>

Hi Kari,

I'm not aware of a way to run the AT migration tool on a subset of resource records.

I think your options are:

1.       Figure out why the 6 records did not migrate (did you see any issues reported in the migration error log?), fix the issues, and run the entire ATK to ASpace migration again

2.       Export the 6 resources from ATK as EAD and import the EAD into ASpace.

If you choose option 2, you'll lose some of the relationships you may have established in ATK between the resource record and other record types, particularly accession records.

We encountered a similar problem during our ATK to ASpace migration and chose option 1, iteratively solving the problems reported in the migration error log and then re-running the migration tool.

-Noah

================
Noah Huffman
Archivist for Metadata, Systems, and Digital Records
David M. Rubenstein Rare Book & Manuscript Library
Duke University | 919-660-5982
http://library.duke.edu/rubenstein/

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kari R Smith
Sent: Wednesday, October 12, 2016 11:01 AM
To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org) <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hello,
In our recent data migration from ATK to ArchivesSpace there were 6 Resource records that did not transfer.  We have the IDs of the records.  The components, Names, Accession records associated all transferred.

Is there a way to run the migrator tool for just the 6 specific collections?  Or am I best off doing an EAD XML export from ATK and then Importing those into ArchivesSpace?

Thanks!

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161012/f27c1b07/attachment.html>

From mark.custer at yale.edu  Wed Oct 12 15:58:36 2016
From: mark.custer at yale.edu (Custer, Mark)
Date: Wed, 12 Oct 2016 19:58:36 +0000
Subject: [Archivesspace_Users_Group] Data migration problem ATK -
 ArchivesSpace only specific Resource records not transferred
In-Reply-To: <BN1PR05MB325739E4F80137A2FF3DB88E6DD0@BN1PR05MB325.namprd05.prod.outlook.com>
References: <29F559819ACA9A4FBF208407D4B63ABBF4AA4F59@OC11expo28.exchange.mit.edu>
 <BN1PR05MB325739E4F80137A2FF3DB88E6DD0@BN1PR05MB325.namprd05.prod.outlook.com>
Message-ID: <BN3PR08MB1318E7CEDB193153C08F8D258CDD0@BN3PR08MB1318.namprd08.prod.outlook.com>

Just a quick reply to say that we chose option 1, too, here at Yale.  We tested the migration process many times before we performed the official migration.  Maureen Callahan provided a window into the fun in the following blog post:  http://campuspress.yale.edu/yalearchivesspace/2015/04/23/reading-migration-bugs-and-fixing-our-data/

Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman
Sent: Wednesday, 12 October, 2016 2:50 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hi Kari,

I'm not aware of a way to run the AT migration tool on a subset of resource records.

I think your options are:

1.       Figure out why the 6 records did not migrate (did you see any issues reported in the migration error log?), fix the issues, and run the entire ATK to ASpace migration again

2.       Export the 6 resources from ATK as EAD and import the EAD into ASpace.

If you choose option 2, you'll lose some of the relationships you may have established in ATK between the resource record and other record types, particularly accession records.

We encountered a similar problem during our ATK to ASpace migration and chose option 1, iteratively solving the problems reported in the migration error log and then re-running the migration tool.

-Noah

================
Noah Huffman
Archivist for Metadata, Systems, and Digital Records
David M. Rubenstein Rare Book & Manuscript Library
Duke University | 919-660-5982
http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=kCFtHMS6FHGe35dhJfwb63t9TdWkUzsrgc_BkKPo41U&s=QdzD5U5IFhYpcpYq7VZjIT37qoal_k_raX05oP2g57Q&e=>

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 Kari R Smith
Sent: Wednesday, October 12, 2016 11:01 AM
To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>) <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hello,
In our recent data migration from ATK to ArchivesSpace there were 6 Resource records that did not transfer.  We have the IDs of the records.  The components, Names, Accession records associated all transferred.

Is there a way to run the migrator tool for just the 6 specific collections?  Or am I best off doing an EAD XML export from ATK and then Importing those into ArchivesSpace?

Thanks!

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/<https://urldefense.proofpoint.com/v2/url?u=http-3A__libraries.mit.edu_archives_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=kCFtHMS6FHGe35dhJfwb63t9TdWkUzsrgc_BkKPo41U&s=n2vPc-OJ2GbEHRLGv9-KOoN45SgcEpLIpu9rzrj4pxI&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161012/dbb2e4c9/attachment.html>

From smithkr at mit.edu  Wed Oct 12 16:24:26 2016
From: smithkr at mit.edu (Kari R Smith)
Date: Wed, 12 Oct 2016 20:24:26 +0000
Subject: [Archivesspace_Users_Group] Data migration problem ATK -
 ArchivesSpace only specific Resource records not transferred - Resolution
Message-ID: <29F559819ACA9A4FBF208407D4B63ABBF4AA59F8@OC11expo28.exchange.mit.edu>

Thanks, Noah and Mark.  There were no indications in the Error log that these were missed except for the total count of Resources and Resources copied so no help in the log.  Interestingly, we tracked them down and it was a set of 6 Resource records in coll # sequence in  ATK.

I then exported the EAD xml from ATK for each of the 6 resources and tried the Import job.  Failed on all 6 records.  Something to do with 'cdata' but I couldn't make out the error enough and the XML looked fine to me - and like the EAD xml of another record from the same ATK.

Ultimately, we've decided to re-enter the data into ArchivesSpace since they are Resources for very small collections.  All of the associated component records did transfer so it's a matter of linking up Agents/Subjects and Accession records for the most part.

If someone is interested in looking at the xml and figuring out what was wonky I'm happy to share (for a collection with 1 item).

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Noah Huffman
Sent: Wednesday, October 12, 2016 2:50 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hi Kari,

I'm not aware of a way to run the AT migration tool on a subset of resource records.

I think your options are:

1.      Figure out why the 6 records did not migrate (did you see any issues reported in the migration error log?), fix the issues, and run the entire ATK to ASpace migration again

2.      Export the 6 resources from ATK as EAD and import the EAD into ASpace.

If you choose option 2, you'll lose some of the relationships you may have established in ATK between the resource record and other record types, particularly accession records.

We encountered a similar problem during our ATK to ASpace migration and chose option 1, iteratively solving the problems reported in the migration error log and then re-running the migration tool.

-Noah

================
Noah Huffman
Archivist for Metadata, Systems, and Digital Records
David M. Rubenstein Rare Book & Manuscript Library
Duke University | 919-660-5982
http://library.duke.edu/rubenstein/

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 Kari R Smith
Sent: Wednesday, October 12, 2016 11:01 AM
To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>) <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hello,
In our recent data migration from ATK to ArchivesSpace there were 6 Resource records that did not transfer.  We have the IDs of the records.  The components, Names, Accession records associated all transferred.

Is there a way to run the migrator tool for just the 6 specific collections?  Or am I best off doing an EAD XML export from ATK and then Importing those into ArchivesSpace?

Thanks!

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161012/7123630f/attachment.html>

From thc4 at columbia.edu  Wed Oct 12 16:40:17 2016
From: thc4 at columbia.edu (Terry Catapano)
Date: Wed, 12 Oct 2016 16:40:17 -0400
Subject: [Archivesspace_Users_Group] Data migration problem ATK -
 ArchivesSpace only specific Resource records not transferred - Resolution
In-Reply-To: <29F559819ACA9A4FBF208407D4B63ABBF4AA59F8@OC11expo28.exchange.mit.edu>
References: <29F559819ACA9A4FBF208407D4B63ABBF4AA59F8@OC11expo28.exchange.mit.edu>
Message-ID: <90b891dd-2fba-90a2-d786-c4ef4c82baf4@columbia.edu>

Kari,

I'd like to take a look at an example of a collection which failed. 
Would be good for the migrations group know about.

/Terry

On 10/12/2016 04:24 PM, Kari R Smith wrote:
>
> Thanks, Noah and Mark.  There were no indications in the Error log 
> that these were missed except for the total count of Resources and 
> Resources copied so no help in the log.  Interestingly, we tracked 
> them down and it was a set of 6 Resource records in coll # sequence in 
>  ATK.
>
> I then exported the EAD xml from ATK for each of the 6 resources and 
> tried the Import job.  Failed on all 6 records.  Something to do with 
> ?cdata? but I couldn?t make out the error enough and the XML looked 
> fine to me ? and like the EAD xml of another record from the same ATK.
>
> Ultimately, we?ve decided to re-enter the data into ArchivesSpace 
> since they are Resources for very small collections.  All of the 
> associated component records did transfer so it?s a matter of linking 
> up Agents/Subjects and Accession records for the most part.
>
> If someone is interested in looking at the xml and figuring out what 
> was wonky I?m happy to share (for a collection with 1 item).
>
> Kari R. Smith
>
> Digital Archivist, Institute Archives and Special Collections
>
> Massachusetts Institute of Technology Libraries
>
> 617.253.5690 smithkr at mit.edu   http://libraries.mit.edu/archives/
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org 
> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] *On 
> Behalf Of *Noah Huffman
> *Sent:* Wednesday, October 12, 2016 2:50 PM
> *To:* Archivesspace Users Group 
> <archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Data migration problem ATK 
> - ArchivesSpace only specific Resource records not transferred
>
> Hi Kari,
>
> I?m not aware of a way to run the AT migration tool on a subset of 
> resource records.
>
> I think your options are:
>
> 1.Figure out why the 6 records did not migrate (did you see any issues 
> reported in the migration error log?), fix the issues, and run the 
> entire ATK to ASpace migration again
>
> 2.Export the 6 resources from ATK as EAD and import the EAD into ASpace.
>
> If you choose option 2, you?ll lose some of the relationships you may 
> have established in ATK between the resource record and other record 
> types, particularly accession records.
>
> We encountered a similar problem during our ATK to ASpace migration 
> and chose option 1, iteratively solving the problems reported in the 
> migration error log and then re-running the migration tool.
>
> -Noah
>
> ================
>
> Noah Huffman
>
> Archivist for Metadata, Systems, and Digital Records
>
> David M. Rubenstein Rare Book & Manuscript Library
>
> Duke University | 919-660-5982
>
> http://library.duke.edu/rubenstein/
>
> *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 *Kari R Smith
> *Sent:* Wednesday, October 12, 2016 11:01 AM
> *To:* Archivesspace Users Group 
> (archivesspace_users_group at lyralists.lyrasis.org 
> <mailto:archivesspace_users_group at lyralists.lyrasis.org>) 
> <archivesspace_users_group at lyralists.lyrasis.org 
> <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
> *Subject:* [Archivesspace_Users_Group] Data migration problem ATK - 
> ArchivesSpace only specific Resource records not transferred
>
> Hello,
>
> In our recent data migration from ATK to ArchivesSpace there were 6 
> Resource records that did not transfer.  We have the IDs of the 
> records.  The components, Names, Accession records associated all 
> transferred.
>
> Is there a way to run the migrator tool for just the 6 specific 
> collections?  Or am I best off doing an EAD XML export from ATK and 
> then Importing those into ArchivesSpace?
>
> Thanks!
>
> Kari R. Smith
>
> Digital Archivist, Institute Archives and Special Collections
>
> Massachusetts Institute of Technology Libraries
>
> 617.253.5690   smithkr at mit.edu http://libraries.mit.edu/archives/ 
> <http://libraries.mit.edu/archives/>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161012/de892446/attachment.html>

From lavetta at pa.gov  Thu Oct 13 08:10:35 2016
From: lavetta at pa.gov (Avetta, Linda)
Date: Thu, 13 Oct 2016 12:10:35 +0000
Subject: [Archivesspace_Users_Group] Data migration problem ATK -
 ArchivesSpace only specific Resource records not transferred
In-Reply-To: <BN3PR08MB1318E7CEDB193153C08F8D258CDD0@BN3PR08MB1318.namprd08.prod.outlook.com>
References: <29F559819ACA9A4FBF208407D4B63ABBF4AA4F59@OC11expo28.exchange.mit.edu>
 <BN1PR05MB325739E4F80137A2FF3DB88E6DD0@BN1PR05MB325.namprd05.prod.outlook.com>
 <BN3PR08MB1318E7CEDB193153C08F8D258CDD0@BN3PR08MB1318.namprd08.prod.outlook.com>
Message-ID: <32ab95ceaafc430a96c95795c3ffe04a@ENCTCEXCH007.PA.LCL>

Mark,

I'm curious to know what container management plug-in you use at Yale, and if you will still be using the same plug-in in AS.  Or do you think AS has sufficient location/barcode/space management that a separate plug-in is not needed.  Any feedback would be appreciated.

Thanks,
Linda

Linda Avetta | Division Chief
Digital Archives & Records Division
Pennsylvania State Archives
PA Historical & Museum Commission
The Commonwealth of Pennsylvania
1825 Stanley Drive | Harrisburg, PA 17103
Phone: 717.705.6923
Visit us on the web at PHMC.state.pa.us<http://www.phmc.state.pa.us/> and DigitalArchives<http://www.digitalarchives.state.pa.us/>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Wednesday, October 12, 2016 3:59 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Just a quick reply to say that we chose option 1, too, here at Yale.  We tested the migration process many times before we performed the official migration.  Maureen Callahan provided a window into the fun in the following blog post:  http://campuspress.yale.edu/yalearchivesspace/2015/04/23/reading-migration-bugs-and-fixing-our-data/

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 Noah Huffman
Sent: Wednesday, 12 October, 2016 2:50 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hi Kari,

I'm not aware of a way to run the AT migration tool on a subset of resource records.

I think your options are:

1.       Figure out why the 6 records did not migrate (did you see any issues reported in the migration error log?), fix the issues, and run the entire ATK to ASpace migration again

2.       Export the 6 resources from ATK as EAD and import the EAD into ASpace.

If you choose option 2, you'll lose some of the relationships you may have established in ATK between the resource record and other record types, particularly accession records.

We encountered a similar problem during our ATK to ASpace migration and chose option 1, iteratively solving the problems reported in the migration error log and then re-running the migration tool.

-Noah

================
Noah Huffman
Archivist for Metadata, Systems, and Digital Records
David M. Rubenstein Rare Book & Manuscript Library
Duke University | 919-660-5982
http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=kCFtHMS6FHGe35dhJfwb63t9TdWkUzsrgc_BkKPo41U&s=QdzD5U5IFhYpcpYq7VZjIT37qoal_k_raX05oP2g57Q&e=>

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 Kari R Smith
Sent: Wednesday, October 12, 2016 11:01 AM
To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>) <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hello,
In our recent data migration from ATK to ArchivesSpace there were 6 Resource records that did not transfer.  We have the IDs of the records.  The components, Names, Accession records associated all transferred.

Is there a way to run the migrator tool for just the 6 specific collections?  Or am I best off doing an EAD XML export from ATK and then Importing those into ArchivesSpace?

Thanks!

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/<https://urldefense.proofpoint.com/v2/url?u=http-3A__libraries.mit.edu_archives_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=kCFtHMS6FHGe35dhJfwb63t9TdWkUzsrgc_BkKPo41U&s=n2vPc-OJ2GbEHRLGv9-KOoN45SgcEpLIpu9rzrj4pxI&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161013/1f242bd8/attachment.html>

From jacqueline.rider at ptsem.edu  Thu Oct 13 14:29:45 2016
From: jacqueline.rider at ptsem.edu (Rider, Jacqueline)
Date: Thu, 13 Oct 2016 18:29:45 +0000
Subject: [Archivesspace_Users_Group] CSV question
Message-ID: <C4CB213B-ADDA-4834-A747-F951A312CA8D@ptsem.edu>

When importing a CSV file of accession records, if a given value itself
contains a comma (as is especially common for descriptive text fields),
how should the internal comma be escaped? One common way to do this is to
use a backslash immediately before the comma, for example:

accession_acquisition_type,accession_title,accession_use_restrictions, ...
Gift,Horace T. Allen\, Jr. Collection,FALSE, ...


Another common method is to wrap the value in quotation marks, for example:

accession_acquisition_type,accession_title,accession_use_restrictions, ...
Gift,"Horace T. Allen, Jr. Collection",FALSE, ...


Which of these (or some other technique) does the accession CSV importer
allow?

Thanks,
Jackie Rider

Jacqueline Rider
Digital Archivist
Princeton Theological Seminary
Library
PO Box 821
Princeton NJ 08542
609-497-7862
jacqueline.rider at ptsem.edu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161013/9a4daf97/attachment.html>

From bthomas at tsl.texas.gov  Thu Oct 13 15:21:22 2016
From: bthomas at tsl.texas.gov (Brian Thomas)
Date: Thu, 13 Oct 2016 19:21:22 +0000
Subject: [Archivesspace_Users_Group] CSV question
In-Reply-To: <C4CB213B-ADDA-4834-A747-F951A312CA8D@ptsem.edu>
References: <C4CB213B-ADDA-4834-A747-F951A312CA8D@ptsem.edu>
Message-ID: <BLUPR16MB0371FB477308B5CA172A8BBBFADC0@BLUPR16MB0371.namprd16.prod.outlook.com>

Jacqueline,

While I don?t know the answer to this directly from the program standpoint, Ido know that if you create the file in excel and save as a csv it should do the proper method automatically. I believe my tests of the csv upload was with the ?? option in the file. However excel does it automatically works just fine.
Thanks,

Brian Thomas
Electronic Records Specialist
Texas State Library and Archives Commission
1201 Brazos Street
Austin, TX 78701
PH: (512) 475-3374
e-mail: bthomas at tsl.texas.gov
tsl.texas.gov<http://tsl.texas.gov/>
[cid:image001.jpg at 01D029A2.37194C70]



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rider, Jacqueline
Sent: Thursday, October 13, 2016 1:30 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] CSV question

When importing a CSV file of accession records, if a given value itself
contains a comma (as is especially common for descriptive text fields),
how should the internal comma be escaped? One common way to do this is to
use a backslash immediately before the comma, for example:

accession_acquisition_type,accession_title,accession_use_restrictions, ...
Gift,Horace T. Allen\, Jr. Collection,FALSE, ...


Another common method is to wrap the value in quotation marks, for example:

accession_acquisition_type,accession_title,accession_use_restrictions, ...
Gift,"Horace T. Allen, Jr. Collection",FALSE, ...


Which of these (or some other technique) does the accession CSV importer
allow?

Thanks,
Jackie Rider

Jacqueline Rider
Digital Archivist
Princeton Theological Seminary
Library
PO Box 821
Princeton NJ 08542
609-497-7862
jacqueline.rider at ptsem.edu<mailto:jacqueline.rider at ptsem.edu>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161013/c993e87e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5314 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161013/c993e87e/attachment.png>

From jacqueline.rider at ptsem.edu  Fri Oct 14 08:25:17 2016
From: jacqueline.rider at ptsem.edu (Rider, Jacqueline)
Date: Fri, 14 Oct 2016 12:25:17 +0000
Subject: [Archivesspace_Users_Group] CSV question
Message-ID: <0CF9E4A8-018A-4841-8B1D-EA300D1F2BFE@ptsem.edu>

Thanks, Brian!

Jackie

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Brian Thomas <bthomas at tsl.texas.gov>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Thursday, October 13, 2016 at 3:21 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] CSV question

Jacqueline,

While I don?t know the answer to this directly from the program standpoint, Ido know that if you create the file in excel and save as a csv it should do the proper method automatically. I believe my tests of the csv upload was with the ?? option in the file. However excel does it automatically works just fine.
Thanks,

Brian Thomas
Electronic Records Specialist
Texas State Library and Archives Commission
1201 Brazos Street
Austin, TX 78701
PH: (512) 475-3374
e-mail: bthomas at tsl.texas.gov
tsl.texas.gov<http://tsl.texas.gov/>
[id:image001.jpg at 01D029A2.37194C70]



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rider, Jacqueline
Sent: Thursday, October 13, 2016 1:30 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] CSV question

When importing a CSV file of accession records, if a given value itself
contains a comma (as is especially common for descriptive text fields),
how should the internal comma be escaped? One common way to do this is to
use a backslash immediately before the comma, for example:

accession_acquisition_type,accession_title,accession_use_restrictions, ...
Gift,Horace T. Allen\, Jr. Collection,FALSE, ...


Another common method is to wrap the value in quotation marks, for example:

accession_acquisition_type,accession_title,accession_use_restrictions, ...
Gift,"Horace T. Allen, Jr. Collection",FALSE, ...


Which of these (or some other technique) does the accession CSV importer
allow?

Thanks,
Jackie Rider

Jacqueline Rider
Digital Archivist
Princeton Theological Seminary
Library
PO Box 821
Princeton NJ 08542
609-497-7862
jacqueline.rider at ptsem.edu<mailto:jacqueline.rider at ptsem.edu>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161014/7799788e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5315 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161014/7799788e/attachment.png>

From laurie.arp at lyrasis.org  Fri Oct 14 16:20:22 2016
From: laurie.arp at lyrasis.org (Laurie Arp)
Date: Fri, 14 Oct 2016 20:20:22 +0000
Subject: [Archivesspace_Users_Group] ArchivesSpace and Hudson Molonglo (HM)
 are pleased to announce HM as an ArchivesSpace development partner!
Message-ID: <BN3PR0801MB09169C529B61EFC94554F7B98ADF0@BN3PR0801MB0916.namprd08.prod.outlook.com>

Announcement to the ArchivesSpace Community

As part of the strategy to move the ArchivesSpace code development forward more quickly, LYRASIS, the Organizational Home for ArchivesSpace is pleased to announce a long-term development partnership agreement has been signed with Hudson Molonglo (HM). This partnership will run for the duration of the fiscal year. The primary goal is to allow HM to focus on high-impact code development while the ArchivesSpace community continues to grow code contributions from within.

Why is this partnership important? We know that one of your highest priorities is the improved functionality of the software. As such, HM will begin immediate work on identified bug fixes and minor improvements to improve efficiency. In November, work will commence on more intricate stack improvements, new feature development and the creation of a development road map. Work will follow the path as outlined in the ArchivesSpace development catalog and/or prioritized by the ArchivesSpace Prioritization sub team.

In sum, we are delighted to be partnering with HM.  As many of you know, HM built version 1.0 of ArchivesSpace and has been responsible for significant code contributions since, including the new container management functionality and location enhancements present in the 1.5.0 release. HM is also currently working on the highly anticipated Public User Interface.

This partnership will not slow the ongoing effort to hire the Tech Lead Position.

We look forward to working together for the benefit of the ArchivesSpace community!

For more information about ArchivesSpace, Hudson Molonglo or LYRASIS, please visit:
http://www.archivesspace.org/
http://hudsonmolonglo.com/
http://www.lyrasis.org



Laurie Gemmill Arp
Director, Collections Services & Community Supported Software
laurie.arp at lyrasis.org<mailto:laurie.arp at lyrasis.org>
800.999.8558 x 2908
Fax: 404.592.4804
laurie.gemmill1 Skype

[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]
Check lyrasisnow.org<http://www.lyrasisnow.org/> for up-to-date news and feature articles.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161014/0c729f76/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4483 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161014/0c729f76/attachment.png>

From ccauste1 at swarthmore.edu  Tue Oct 18 10:45:45 2016
From: ccauste1 at swarthmore.edu (Celia Caust-Ellenbogen)
Date: Tue, 18 Oct 2016 10:45:45 -0400
Subject: [Archivesspace_Users_Group] Importing container profiles?
Message-ID: <CAFvko3s-iCieJGXaUCAzdQrukab2k23AfLkUe7JUT4=TnvEmRg@mail.gmail.com>

Hello,

We've just migrated to v.1.5.1, so we need to create a whole bunch of
container profiles. I know others have been in this exact same situation,
and most of our boxes are the same as at every other repository.

   - Does anyone have a list/spreadsheet/etc of container profiles they're
   willing to share, so I don't have to look up dimensions on a vendor website
   (or worse, head into the stacks with a yardstick)?
   - Is there no way to import multiple container profiles at once from the
   ASpace staff interface? Or is the only way with the API?

Thanks,
Celia

-- 
Celia Caust-Ellenbogen
Friends Historical Library of Swarthmore College
<http://swarthmore.edu/friends-historical-library>
610-328-8498
ccauste1 at swarthmore.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/de034eb0/attachment.html>

From mcallahan at smith.edu  Tue Oct 18 10:52:59 2016
From: mcallahan at smith.edu (Maureen Callahan)
Date: Tue, 18 Oct 2016 10:52:59 -0400
Subject: [Archivesspace_Users_Group] Importing container profiles?
In-Reply-To: <CAFvko3s-iCieJGXaUCAzdQrukab2k23AfLkUe7JUT4=TnvEmRg@mail.gmail.com>
References: <CAFvko3s-iCieJGXaUCAzdQrukab2k23AfLkUe7JUT4=TnvEmRg@mail.gmail.com>
Message-ID: <CAH0VKbDe0ocraZJ=hLF_fyR63ecOT_kYmJcYWQd3_frEmRCcQQ@mail.gmail.com>

Hi Celia,

What a great question! I don't currently have access to a long list of
container profiles (my former colleagues at Yale may be willing to share
the ones we came up with there), but I do have a quick-and-dirty method for
importing them into ArchivesSpace via the API, available here:
https://github.com/smith-special-collections/aspace-migration/blob/master/container%20profiles/AddContainerProfiles.py
(I prepared this as a proof of concept when working with a colleague --
you'll want to update the variables to match your own environment, and you
will also need to update infile.csv to reflect the list of contianer
profiles you'll end up using)

Maureen

On Tue, Oct 18, 2016 at 10:45 AM, Celia Caust-Ellenbogen <
ccauste1 at swarthmore.edu> wrote:

> Hello,
>
> We've just migrated to v.1.5.1, so we need to create a whole bunch of
> container profiles. I know others have been in this exact same situation,
> and most of our boxes are the same as at every other repository.
>
>    - Does anyone have a list/spreadsheet/etc of container profiles
>    they're willing to share, so I don't have to look up dimensions on a vendor
>    website (or worse, head into the stacks with a yardstick)?
>    - Is there no way to import multiple container profiles at once from
>    the ASpace staff interface? Or is the only way with the API?
>
> Thanks,
> Celia
>
> --
> Celia Caust-Ellenbogen
> Friends Historical Library of Swarthmore College
> <http://swarthmore.edu/friends-historical-library>
> 610-328-8498
> ccauste1 at swarthmore.edu
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Maureen Callahan
Sophia Smith Collection Archivist
Smith College Special Collections
Northampton, Massachusetts 01063
T. 413 585 2981 C. 215.863.1860
mcallahan at smith.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/625596bd/attachment.html>

From Kevin.Clair at du.edu  Tue Oct 18 11:16:47 2016
From: Kevin.Clair at du.edu (Kevin Clair)
Date: Tue, 18 Oct 2016 15:16:47 +0000
Subject: [Archivesspace_Users_Group] Importing container profiles?
In-Reply-To: <CAFvko3s-iCieJGXaUCAzdQrukab2k23AfLkUe7JUT4=TnvEmRg@mail.gmail.com>
References: <CAFvko3s-iCieJGXaUCAzdQrukab2k23AfLkUe7JUT4=TnvEmRg@mail.gmail.com>
Message-ID: <786EE0EF-BD0B-4060-B5F2-A12B366C4EE7@du.edu>

Hello,

Attached is a quick JSON dump of all the container profiles we have in Denver?s ArchivesSpace instance so far. You?ll probably want to have someone take out all the created/last modified data if you use this, and I?m not 100% sure the dimensions are exactly accurate (I rounded up to the nearest quarter inch), but it covers most of the Gaylord boxes we buy in bulk. Titles include human-readable names as well as the Gaylord product code.

We added these one by one through the staff interface, so I?m not sure if there?s a non-API method we could have used to do it in a batch.  -k

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Celia Caust-Ellenbogen <ccauste1 at swarthmore.edu>
Reply-To: Archivesspace Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Tuesday, October 18, 2016 at 8:45 AM
To: Archivesspace Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Importing container profiles?

Hello,

We've just migrated to v.1.5.1, so we need to create a whole bunch of container profiles. I know others have been in this exact same situation, and most of our boxes are the same as at every other repository.

  *   Does anyone have a list/spreadsheet/etc of container profiles they're willing to share, so I don't have to look up dimensions on a vendor website (or worse, head into the stacks with a yardstick)?
  *   Is there no way to import multiple container profiles at once from the ASpace staff interface? Or is the only way with the API?
Thanks,
Celia

--
Celia Caust-Ellenbogen
Friends Historical Library of Swarthmore College<http://swarthmore.edu/friends-historical-library>
610-328-8498
ccauste1 at swarthmore.edu<mailto:ccauste1 at swarthmore.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/93455957/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: container_profiles_report.json
Type: application/json
Size: 10592 bytes
Desc: container_profiles_report.json
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/93455957/attachment.json>

From cobourna at wlu.edu  Tue Oct 18 11:24:26 2016
From: cobourna at wlu.edu (Cobourn, Alston)
Date: Tue, 18 Oct 2016 15:24:26 +0000
Subject: [Archivesspace_Users_Group] Easy question on 1.5
In-Reply-To: <08533c61f7744bf39593f197f2dfe2ec@ESGMTWEX12.win.ad.jhu.edu>
References: <21ad4d58bd0f49099ad019394c48f395@ESGMTWEX12.win.ad.jhu.edu>
 <DM2PR0801MB1136249487FDF81E90ACB60494300@DM2PR0801MB1136.namprd08.prod.outlook.com>
 <08533c61f7744bf39593f197f2dfe2ec@ESGMTWEX12.win.ad.jhu.edu>
Message-ID: <BFAA390DF83B564584B4A5AF345623CA021F8B7C95@MEX10MBA3.ad.wlu.edu>

I also just realized that we have the same issue unfortunately.  Am now watching that JIRA.

Alston Cobourn
Assistant Professor and Digital Scholarship Librarian
Washington and Lee University
cobourna at wlu.edu<mailto:cobourna at wlu.edu>
540-458-8657
ORCID 0000-0002-3756-6476


From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Valerie Addonizio
Sent: Tuesday, July 12, 2016 11:19 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Easy question on 1.5

Thanks for you quick response, Brad. I'll keep an eye on that JIRA.

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 Brad Westbrook
Sent: Tuesday, July 12, 2016 9:54 AM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Easy question on 1.5

Hi, Valerie,

1.    V1.5.0 RC3 does not have a feature for merging top containers.  That is still an open request; see AR-1436<https://archivesspace.atlassian.net/browse/AR-1436>.

Brad



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 Valerie Addonizio
Sent: Tuesday, July 12, 2016 9:33 AM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Easy question on 1.5

Hopkins is currently using 1.4.2 with container management, and is wondering whether 1.5 includes the ability to merge top_containers? We have a number of containers that converted to distinct containers when they should be the same container (two box 252s, for example, when they are the same), and in order to correct the problem we have to manually change each instance affected. Before putting in a feature request, we through it prudent to ask whether there is a merge function in 1.5.

Thank you.

-Valerie

--------------------------------
Valerie Addonizio
Archivist
The Sheridan Libraries
Johns Hopkins University
vaddoniz at jhu.edu<mailto:vaddoniz at jhu.edu>
410-516-5261

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/598add8e/attachment.html>

From Robert.Miller at lyrasis.org  Tue Oct 18 13:34:39 2016
From: Robert.Miller at lyrasis.org (Robert Miller)
Date: Tue, 18 Oct 2016 17:34:39 +0000
Subject: [Archivesspace_Users_Group] personnel update
Message-ID: <19D93ACB-B58D-4EE6-8CF9-E226CE03516C@lyrasis.org>

To the ArchivesSpace community,
It is with regret that we received notice that Brad Westbrook, ArchivesSpace Program Manager, wishes to move on to pursue new opportunities after three years of dedicated service with the ArchivesSpace program. He will be missed.

Brad has worked tirelessly since 2013 to help position ASpace for success in the community. He was one of the original architects of the Archivists Toolkit when he was at UCSD, and has been instrumental in bringing the software to archivists ever since.  In his role at ArchivesSpace, he has helped navigate the myriad issues associated with bringing a new software service to the community. Brad?s familiar face was often seen at SAA and the many events, conferences and hackathons that he participated in or led.
Fortunately, Brad will remain in his position for the next six weeks with the ArchivesSpace program and LYRASIS, the Organizational Home, to help find a suitable replacement. He will also help in the recruiting and hiring of a tech lead.
While November 30th will be his last day as Program Manager, Brad has kindly agreed to continue working with ASpace on dedicated projects after that.   We will announce more details on that as specific plans are confirmed.
Laurie Gemmill Arp, Director of Collections Services and Community Supported Software at the LYRASIS Organizational Home, to whom Brad reports, will work closely with Brad and Christine Di Bella during this transition to ensure that commitments are reviewed and kept.
We wish Brad well in his future endeavors.
If there are questions, please feel free to reach out to me, Robert Miller, CEO of LYRASIS which is the Organizational Home for ASpace (robert.miller at lyrasis.org<mailto:robert.miller at lyrasis.org>).

Sincerely,

Robert
 Robert Miller
Chief Executive Officer
1438 West Peachtree Street NW, Suite 150, Atlanta, GA 30309
Cell: 415-640-1092
Toll free: 800-999-8558
Skype: Robert-Miller

[cid:152E64D5-4E98-43BE-8C93-F62E3E18C830 at dia.dnvr][cid:88B96204-848E-450E-AFEA-1E44142C5004] <https://twitter.com/lyrasis>
<https://twitter.com/lyrasis>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/3f860c16/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.png
Type: image/png
Size: 4483 bytes
Desc: unknown.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/3f860c16/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 854 bytes
Desc: image002.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161018/3f860c16/attachment.jpg>

From THamilton at hersheyarchives.org  Wed Oct 19 14:33:36 2016
From: THamilton at hersheyarchives.org (THamilton at hersheyarchives.org)
Date: Wed, 19 Oct 2016 14:33:36 -0400
Subject: [Archivesspace_Users_Group] Archivesspace Migration RFP
Message-ID: <OFBB943831.53CAC175-ON85258051.0065D6F7-85258051.0065F436@HersheyPA.com>

Good afternoon.  We are looking into migrating records from Inmagic 
DBTextworks into Archivesspace.  As we do not have an in-house IT 
department and this is outside the staff?s capabilities we are drafting an 
RFP for IT assistance.  Has anyone else on the list drafted an RFP for IT 
support?  Does anyone have any tips or ideas about things to consider when 
outsourcing IT support?
Thank you,
Tammy


Tammy L. Hamilton
Archivist 
Hershey Community Archives 
63 West Chocolate Avenue | Hershey, PA 17033 
tel: 717.508.1988 




DISCLAIMER: The information contained in this e-mail may be confidential 
and is intended solely for the use of the named addressee. Access, 
copying, or re-use of the e-mail or any information contained therein by 
any other person is not authorized. If you are not the intended recipient 
please notify us immediately by returning the e-mail to the originator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161019/acce994e/attachment.html>

From smithkr at mit.edu  Wed Oct 19 15:26:34 2016
From: smithkr at mit.edu (Kari R Smith)
Date: Wed, 19 Oct 2016 19:26:34 +0000
Subject: [Archivesspace_Users_Group] Which permission give a User the right
	to Print to PDF?
Message-ID: <29F559819ACA9A4FBF208407D4B63ABBF4AC44F0@OC11expo28.exchange.mit.edu>

We're giving some folks View only access ... but they cannot also Export - Print to PDF, which they need to do.
In the Permissions list I see options for Import jobs but not for Export jobs.

What am I missing?     Thanks for help with this one!

Kari

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161019/a1567926/attachment.html>

From carlos.lemus at unlv.edu  Thu Oct 20 20:40:51 2016
From: carlos.lemus at unlv.edu (Carlos Lemus)
Date: Thu, 20 Oct 2016 17:40:51 -0700
Subject: [Archivesspace_Users_Group] CSS changes clarification
Message-ID: <CAPsSwYpyXebdf4oTxyfnjJjWHtg1t0WysPz9tOg5mg2qBw_QYg@mail.gmail.com>

Hello Nate,

Yup! just go ahead and leave that base_url in there if you haven't tried it
already.

I can't pinpoint where in the code that variable is actually created, but
it basically looks like it points to the location of the plugin in this
case.

yourArchiveSpaceDirectory/plugins/YourPlugin(probably local)/wherever you
created the layout_head(frontend or public)

and then you append /assets/stylesheets(if you wish to organize this
way)/custom.css

Hope this helps, I know it may be a bit late!
Carlos Lemus
Application Programmer, Special Collections Technical Services
University Libraries, University of Nevada, Las Vegas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161020/1a54c0d1/attachment.html>

From M.Romero at northeastern.edu  Fri Oct 21 11:34:58 2016
From: M.Romero at northeastern.edu (Romero, Michelle)
Date: Fri, 21 Oct 2016 15:34:58 +0000
Subject: [Archivesspace_Users_Group] Alternative Way to Delete a Resource
Message-ID: <BLUPR0601MB1700610801D27D5D33ACA81DFED40@BLUPR0601MB1700.namprd06.prod.outlook.com>

Sorry if this question has been asked before, but I wasn't able to find anything in the list archives.  We're using version v1.5.0.  I imported a large batch of EAD finding aids at the same time. The import completed with no errors, but, when I tried to find the resources, they weren't visible in the backend or front end. I thought the import failed and tried to re-import them.  However, when I attempted to re-import them, I received an error message that the id numbers were already in use.  By searching the id number, I was able to find the top level containers.  Most of them had archival objects attached which then allowed me to access the resource and delete it.  I then re-imported the EAD with no issues. However, there are four that don't have archival objects associated with the top level containers. Is there another way to find and delete these four resources?



Thank you in advance for your assistance,

Michelle

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Michelle Romero
Assistant Archivist, Archives and Special Collections Department
92 Snell Library
Northeastern University
360 Huntington Avenue
Boston, MA 02115-5000
(v) 617-373-7656 (f) 617-373-5409

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161021/e14ffad0/attachment.html>

From sdm7g at eservices.virginia.edu  Fri Oct 21 11:52:59 2016
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Fri, 21 Oct 2016 15:52:59 +0000
Subject: [Archivesspace_Users_Group] Alternative Way to Delete a Resource
In-Reply-To: <BLUPR0601MB1700610801D27D5D33ACA81DFED40@BLUPR0601MB1700.namprd06.prod.outlook.com>
References: <BLUPR0601MB1700610801D27D5D33ACA81DFED40@BLUPR0601MB1700.namprd06.prod.outlook.com>
Message-ID: <AED63CD5-6A38-4FEF-B424-81F8D26F0EDF@eservices.virginia.edu>


After import, it may take a while for the new resources to be indexed and show up in resource browse ? especially for importing a large batch. In the status page for the batch import job, on completion, it will show links at the bottom of the page for newly created resources so you can check them without waiting for reindexing to complete. ( I?ve run into a few cases where import is successful, but it doesn?t display resources at the end. Not sure what the bug is there. )

Are you sure those missing resources aren?t findable now that reindexing is complete ?

If you still can?t find them, you should be able to see (and delete) all of the resources via the backend API.

? Steve Majewski



On Oct 21, 2016, at 11:35 AM, Romero, Michelle <M.Romero at northeastern.edu<mailto:M.Romero at northeastern.edu>> wrote:

Sorry if this question has been asked before, but I wasn?t able to find anything in the list archives.  We?re using version v1.5.0.  I imported a large batch of EAD finding aids at the same time. The import completed with no errors, but, when I tried to find the resources, they weren't visible in the backend or front end. I thought the import failed and tried to re-import them.  However, when I attempted to re-import them, I received an error message that the id numbers were already in use.  By searching the id number, I was able to find the top level containers.  Most of them had archival objects attached which then allowed me to access the resource and delete it.  I then re-imported the EAD with no issues. However, there are four that don't have archival objects associated with the top level containers. Is there another way to find and delete these four resources?

Thank you in advance for your assistance,
Michelle

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Michelle Romero
Assistant Archivist, Archives and Special Collections Department
92 Snell Library
Northeastern University
360 Huntington Avenue
Boston, MA 02115-5000
(v) 617-373-7656 (f) 617-373-5409

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161021/63eac6c7/attachment.html>

From alexanderduryee at nypl.org  Fri Oct 21 14:01:37 2016
From: alexanderduryee at nypl.org (Alexander Duryee)
Date: Fri, 21 Oct 2016 14:01:37 -0400
Subject: [Archivesspace_Users_Group] Creating enumeration values via API
Message-ID: <CAK5BadD1XrJCisNVqBpnBj3ZNHfb3FZUgYNbj+5mjbMLTzmU0w@mail.gmail.com>

As part of our deployment process, I would like to have a script that
automatically adds new enumeration values to certain enumerations.
Querying on the /config/enumerations/:enumeration_id endpoint returns a
JSON object that ensconces a number of enumeration_value objects, so it
seems like I need to create the enumeration_value, then add that to the
enumeration.  However, there seem to be no endpoints for creating new
enumeration_value objects.  Is there another method that I should be using
to create/update enumerations with new values via the API?

Thanks,
--Alex

-- 
Alexander Duryee
Metadata Archivist
New York Public Library
(917)-229-9590
alexanderduryee at nypl.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161021/13b46014/attachment.html>

From djpillen at umich.edu  Fri Oct 21 14:24:56 2016
From: djpillen at umich.edu (Dallas Pillen)
Date: Fri, 21 Oct 2016 14:24:56 -0400
Subject: [Archivesspace_Users_Group] Creating enumeration values via API
In-Reply-To: <CAK5BadD1XrJCisNVqBpnBj3ZNHfb3FZUgYNbj+5mjbMLTzmU0w@mail.gmail.com>
References: <CAK5BadD1XrJCisNVqBpnBj3ZNHfb3FZUgYNbj+5mjbMLTzmU0w@mail.gmail.com>
Message-ID: <CAPy_BxcTeUCXRT5qCT1HtAXqCWM4D9HVqa2PsdsQtrg6twV-Gg@mail.gmail.com>

Hi Alexander,

We had a script that did just that using the update enumeration endpoint
(POST /config/enumerations/:enum_id) by first getting the enumeration's
JSON object, adding new enumeration values to the enumeration's "values"
array, and posting the updated JSON (see example gist
<https://gist.github.com/djpillen/4dd8f3b2e4672a1874c8ac8c646037db>). This
handles the creation of new enumeration_values; they do not need to be
created separately.

On Fri, Oct 21, 2016 at 2:01 PM, Alexander Duryee <alexanderduryee at nypl.org>
wrote:

> As part of our deployment process, I would like to have a script that
> automatically adds new enumeration values to certain enumerations.
> Querying on the /config/enumerations/:enumeration_id endpoint returns a
> JSON object that ensconces a number of enumeration_value objects, so it
> seems like I need to create the enumeration_value, then add that to the
> enumeration.  However, there seem to be no endpoints for creating new
> enumeration_value objects.  Is there another method that I should be using
> to create/update enumerations with new values via the API?
>
> Thanks,
> --Alex
>
> --
> Alexander Duryee
> Metadata Archivist
> New York Public Library
> (917)-229-9590
> alexanderduryee at nypl.org
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 

*Dallas Pillen*Assistant Archivist for Metadata and Digital Projects


  Bentley Historical Library <http://bentley.umich.edu/>
  1150 Beal Avenue
  Ann Arbor, Michigan 48109-2113
  734.647.3559
  Twitter <https://twitter.com/umichBentley> Facebook
<https://www.facebook.com/bentleyhistoricallibrary>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161021/ffec2006/attachment.html>

From mark.custer at yale.edu  Sat Oct 22 12:47:59 2016
From: mark.custer at yale.edu (Custer, Mark)
Date: Sat, 22 Oct 2016 16:47:59 +0000
Subject: [Archivesspace_Users_Group] Data migration problem ATK -
 ArchivesSpace only specific Resource records not transferred
In-Reply-To: <32ab95ceaafc430a96c95795c3ffe04a@ENCTCEXCH007.PA.LCL>
References: <29F559819ACA9A4FBF208407D4B63ABBF4AA4F59@OC11expo28.exchange.mit.edu>
 <BN1PR05MB325739E4F80137A2FF3DB88E6DD0@BN1PR05MB325.namprd05.prod.outlook.com>
 <BN3PR08MB1318E7CEDB193153C08F8D258CDD0@BN3PR08MB1318.namprd08.prod.outlook.com>,
 <32ab95ceaafc430a96c95795c3ffe04a@ENCTCEXCH007.PA.LCL>
Message-ID: <BN3PR08MB13182C2156F123C54C1D88678CD70@BN3PR08MB1318.namprd08.prod.outlook.com>

Hi Linda,


Sorry for not replying earlier.  With versions 1.5 of ArchivesSpace, we are no longer using any plugins for container and location management at Yale.  In addition to the features added to the core code from Yale's plugin for container management (described here http://guides.library.yale.edu/archivesspace/ASpaceContainerManagement), versions 1.5 of ArchivesSpace also include some nifty new methods for location management, which were developed by our colleagues at NYU (described here http://guides.nyu.edu/archivesspace/development#s-lg-box-10702482).


All of which is to say that I don't think that a separate plugin for container/location management is required.  There are still some additional features that are desired (e.g. the ability to merge containers, including when staff users use the resource merge function), but I expect that such features and other enhancements will be added directly to the core code moving forward.


Mark

________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Avetta, Linda <lavetta at pa.gov>
Sent: Thursday, October 13, 2016 8:10:35 AM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Mark,

I?m curious to know what container management plug-in you use at Yale, and if you will still be using the same plug-in in AS.  Or do you think AS has sufficient location/barcode/space management that a separate plug-in is not needed.  Any feedback would be appreciated.

Thanks,
Linda

Linda Avetta | Division Chief
Digital Archives & Records Division
Pennsylvania State Archives
PA Historical & Museum Commission
The Commonwealth of Pennsylvania
1825 Stanley Drive | Harrisburg, PA 17103
Phone: 717.705.6923
Visit us on the web at PHMC.state.pa.us<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phmc.state.pa.us_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=ocDmVxLGTIl3XCIWNtmmSP1vh96Z0r-hkqodUzf7hdQ&s=NsXWtrKBYrLHCVB4iJ5NiGKr29Z2DlWM_OjCF6MtpRo&e=> and DigitalArchives<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.digitalarchives.state.pa.us_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=ocDmVxLGTIl3XCIWNtmmSP1vh96Z0r-hkqodUzf7hdQ&s=740yfwjw57gZhC04Vk5w8GWaCFjTpYbv21AnaIKmWzg&e=>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Wednesday, October 12, 2016 3:59 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Just a quick reply to say that we chose option 1, too, here at Yale.  We tested the migration process many times before we performed the official migration.  Maureen Callahan provided a window into the fun in the following blog post:  http://campuspress.yale.edu/yalearchivesspace/2015/04/23/reading-migration-bugs-and-fixing-our-data/

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 Noah Huffman
Sent: Wednesday, 12 October, 2016 2:50 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hi Kari,

I?m not aware of a way to run the AT migration tool on a subset of resource records.

I think your options are:

1.       Figure out why the 6 records did not migrate (did you see any issues reported in the migration error log?), fix the issues, and run the entire ATK to ASpace migration again

2.       Export the 6 resources from ATK as EAD and import the EAD into ASpace.

If you choose option 2, you?ll lose some of the relationships you may have established in ATK between the resource record and other record types, particularly accession records.

We encountered a similar problem during our ATK to ASpace migration and chose option 1, iteratively solving the problems reported in the migration error log and then re-running the migration tool.

-Noah

================
Noah Huffman
Archivist for Metadata, Systems, and Digital Records
David M. Rubenstein Rare Book & Manuscript Library
Duke University | 919-660-5982
http://library.duke.edu/rubenstein/<https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=kCFtHMS6FHGe35dhJfwb63t9TdWkUzsrgc_BkKPo41U&s=QdzD5U5IFhYpcpYq7VZjIT37qoal_k_raX05oP2g57Q&e=>

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 Kari R Smith
Sent: Wednesday, October 12, 2016 11:01 AM
To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>) <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Data migration problem ATK - ArchivesSpace only specific Resource records not transferred

Hello,
In our recent data migration from ATK to ArchivesSpace there were 6 Resource records that did not transfer.  We have the IDs of the records.  The components, Names, Accession records associated all transferred.

Is there a way to run the migrator tool for just the 6 specific collections?  Or am I best off doing an EAD XML export from ATK and then Importing those into ArchivesSpace?

Thanks!

Kari R. Smith
Digital Archivist, Institute Archives and Special Collections
Massachusetts Institute of Technology Libraries
617.253.5690   smithkr at mit.edu   http://libraries.mit.edu/archives/<https://urldefense.proofpoint.com/v2/url?u=http-3A__libraries.mit.edu_archives_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=kCFtHMS6FHGe35dhJfwb63t9TdWkUzsrgc_BkKPo41U&s=n2vPc-OJ2GbEHRLGv9-KOoN45SgcEpLIpu9rzrj4pxI&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161022/de5882df/attachment.html>

From laurie.arp at lyrasis.org  Sun Oct 23 15:14:36 2016
From: laurie.arp at lyrasis.org (Laurie Arp)
Date: Sun, 23 Oct 2016 19:14:36 +0000
Subject: [Archivesspace_Users_Group] ArchivesSpace updates and next steps
Message-ID: <BN3PR0801MB09164C18117696761B5C107D8AD60@BN3PR0801MB0916.namprd08.prod.outlook.com>

Greetings,

On behalf of the ArchivesSpace Organizational Home Team at LYRASIS, I wanted to update you on a number of significant announcements within the ArchivesSpace program. We thought it would be helpful to summarize where things are and provide the overall plan for the near future so you have a good picture of our roadmap in one email.

HM Development Partner
We are pleased to have Hudson Molonglo (HM) http://hudsonmolonglo.com/ as a development partner. For the next year, HM will work on bug fixes, stack improvements, new feature development and the creation of a development road map.   They will be providing support to address high priority development needs while the new technical lead works with the ArchivesSpace community on code contributions from within. This two-pronged approach will have a substantial, positive short- and long-term impact on the software.  HM's work will follow the path as outlined in the ArchivesSpace development catalog and/or as prioritized by the ArchivesSpace Prioritization sub team. https://archivesspace.atlassian.net/wiki/display/AC/Development+Prioritization+sub-team

Technical Advisory Committee (TAC)/User Advisory Committee (UAC)
The TAC and UAC continue to thrive and provide opportunities for individuals from member institutions to participate and help advance the software.  HM will be working with both Councils and in particular the Technical Advisory Committee (TAC) and its sub-teams.

Technical Lead
The search for the new Technical Lead is well underway.  This position will be responsible for the overall development of the software and will work to engage a broader set of developers to participate in the program, providing technical guidance, support and leadership to create a robust developer community.   We have received numerous applications for the position and have started the review process and initial interviews.

Program Manager
As announced last week, Brad Westbrook will soon step down as the ArchivesSpace inaugural Program Manager, after three years of outstanding service.  His last day as full-time Program Manager will be November 30. We have initiated the search for a new Program Manager and will be posting the position announcement soon. The Program Manager is central to the success of the program, working closely and collaboratively with the ArchivesSpace community, advisory groups, and Board to develop strategy and goals. The Program Manager will be involved in all aspects of the program, and will be a key spokesperson and advocate for the program.  We will be seeking someone with strong experience with archives, technology projects, software development and in building consensus across a diverse group of perspectives.

Conducting searches for the Technical Lead and Program Manager at the same time allows us the opportunity to think more broadly about the program's needs, with an eye toward hiring for those needs in a more comprehensive way.

The LYRASIS Org. Home looks forward to working together with the ArchivesSpace community-including its members, the program team, the Governance Board, TAC/UAC, and HM-to continue to advance ArchivesSpace.

Best wishes,


Laurie Gemmill Arp
Director, Collections Services & Community Supported Software
laurie.arp at lyrasis.org<mailto:laurie.arp at lyrasis.org>
800.999.8558 x 2908
Fax: 404.592.4804
laurie.gemmill1 Skype

[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]
Check lyrasisnow.org<http://www.lyrasisnow.org/> for up-to-date news and feature articles.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161023/3ddd0856/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4483 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161023/3ddd0856/attachment.png>

From jane.labarbara at mail.wvu.edu  Mon Oct 24 11:47:23 2016
From: jane.labarbara at mail.wvu.edu (Jane LaBarbara)
Date: Mon, 24 Oct 2016 15:47:23 +0000
Subject: [Archivesspace_Users_Group] Character limits on sub notes?
Message-ID: <CY4PR03MB264840709346E35EFA85B47FB1A90@CY4PR03MB2648.namprd03.prod.outlook.com>

Dear all,

My institution is migrating into ASpace and using the Public User Interface, and we're hoping to completely transition out of our old system/user interface by the end of 2016.

Because of the issue with <emph> tags/@render attributes showing up as text instead of displaying as italics etc. (AR-1234-we've noticed this in the "title" field, example here: https://archives.lib.wvu.edu/repositories/2/archival_objects/328) , we're trying to find a workaround for one of our most prominent collections, the Pearl Buck Literary Manuscripts, which has a LOT of folder titles that include italics (you can see the S/C note and contents list here https://findingaids.lib.wvu.edu/cgi/f/findaid/findaid-idx?c=wvcguide;cc=wvcguide;type=simple;rgn=Entire%20Finding%20Aid;q1=4052;view=reslist;subview=standard;sort=occur;start=1;size=25;didno=4052;focusrgn=scopecontent;byte=24750517&newsid=1).

I thought we could try to put the contents list of each series in the series Scope and Content Note until the bug is fixed (so our italics won't look ugly to the public), but when I tried that, saved the record, and tried to navigate around in that resource record, I got something about "an error occurred" and "FULL head" - we were able to fix that with help from a previous listserv exchange--see http://lyralists.lyrasis.org/mailman/htdig/archivesspace_users_group/2016-March/003316.html-- but our Systems person doesn't want to leave the fix in place, which means I can't put that much text in the Scope and Content Note.  I had this issue in version 1.4.2, but we're in the middle of moving to 1.5.1.

TL;DR Does anyone know how many characters can fit into a sub note without breaking it?

Any other ideas on how to present this massive contents list to the public until the italics-related bug is fixed would also be welcome.

Thank you,
Jane

/ Jane Metters LaBarbara
Assistant Curator, West Virginia & Regional History Center<https://wvrhc.lib.wvu.edu/>
West Virginia University Libraries
(304) 293-0352 office
jane.labarbara at mail.wvu.edu<mailto:jane.labarbara at mail.wvu.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161024/d5b4c6a5/attachment.html>

From laurie.arp at lyrasis.org  Tue Oct 25 09:53:41 2016
From: laurie.arp at lyrasis.org (Laurie Arp)
Date: Tue, 25 Oct 2016 13:53:41 +0000
Subject: [Archivesspace_Users_Group] ArchivesSpace Program Manager Position
	Announcement
Message-ID: <BN3PR0801MB0916882EBC564347713B84748AA80@BN3PR0801MB0916.namprd08.prod.outlook.com>

ArchivesSpace Program Manager Position Announcement

LYRASIS is seeking a dynamic Program Manager for ArchivesSpace, an open-source, archives information management web application designed for managing descriptive information about archives, manuscripts, and digital objects.  (http://www.archivesspace.org/)

The Program Manager plays a key role working with the community to set the strategy and goals for ArchivesSpace.  The Program Manager is central to the success of the program, and works closely and collaboratively with the ArchivesSpace community, advisory groups and Board to ensure success. The Program Manager will be involved in all aspects of the program, and be a key spokesperson and advocate for the program.
We are seeking someone with strong experience with archives, technology projects, software development and building consensus across a diverse group of perspectives.

Attached is the position description.  It will also be available at: http://www.lyrasis.org/job/Pages/LYRASIS-Positions.aspx


The position is part of a geographically and institutionally distributed team, and, as such, applications from candidates interested in telecommuting are welcome.



Please submit your application, including cover letter, to human.resources at lyrasis.org<mailto:human.resources at lyrasis.org>
Applications will be accepted until the position is filled, but review of applications will begin 11/11.

Best wishes,


Laurie Gemmill Arp
Director, Collections Services & Community Supported Software
laurie.arp at lyrasis.org<mailto:laurie.arp at lyrasis.org>
800.999.8558 x 2908
Fax: 404.592.4804
laurie.gemmill1 Skype

[cid:D9C43C04-DF4E-467C-B0BC-358EF417F998]
Check lyrasisnow.org<http://www.lyrasisnow.org/> for up-to-date news and feature articles.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161025/de2ba615/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4483 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161025/de2ba615/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ASpaceProgMgr2016010.pdf
Type: application/pdf
Size: 328218 bytes
Desc: ASpaceProgMgr2016010.pdf
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161025/de2ba615/attachment-0001.pdf>

From sally.vermaaten at nyu.edu  Wed Oct 26 09:31:13 2016
From: sally.vermaaten at nyu.edu (Sally Vermaaten)
Date: Wed, 26 Oct 2016 09:31:13 -0400
Subject: [Archivesspace_Users_Group] Call for Technical Advisory Council
	nominations
Message-ID: <CALt9ybt+M9FWTbdh0Qm-R0+GpVetsg-WyLQmRPQ2ZLSD5om82Q@mail.gmail.com>

*Nominations Requested for ArchivesSpace Technical Advisory Council*


The ArchivesSpace Governance Board is *seeking nominations to fill one
vacancy on the ArchivesSpace Technical Advisory Council (TAC)*.

Nominations may be made only by ArchivesSpace member representatives.
Member representatives are encouraged to nominate persons from their
institution or from other institutions, including Registered Service
Providers, (please see the lists at http://archivesspace.org/members
<http://archivesspace.org/members>) who are experienced with some of the
activities assigned to TAC and who are capable of participating on a
regular basis throughout the term of service of  December 1, 2016-June 30,
2018.

TAC (http://www.archivesspace.org/technicaladvisory) is a critical part of
the ArchivesSpace community, having responsibility for providing technical
guidance to individuals or organizations contributing to application
development, to the User Advisory Council, and to the ArchivesSpace
Governance Board. TAC's current activities include:

   - developing a community of code committers, including helping to
   establish guidelines for contributing code and reviewing contributions,
   - reviewing enhancements and priorities and testing in collaboration
   with the User Advisory Council,
   - providing support for migrating data to ArchivesSpace and support for
   importing and exporting data such as EAD, MARCXML, CSV
   - documenting and assisting with resolving bugs identified in the
   application,
   - identifying integration points for ArchivesSpace with other systems
   (e.g. digital asset management systems, patron and request management
   systems, etc.), creating resources to assist the community with integration
   work and, for specific integrations, developing technical requirements, and
   - updating technical documentation.

Sub-teams are established within TAC to address the areas identified above
and other areas subsequently identified as priorities and a good fit for
the Council. Nominees must have sufficient knowledge of application
development methods, architectures and coding practices to participate in
and lead some of the identified activities. Nominees with experience in
open source projects, developing web applications (particularly using Ruby
on Rails and Sinatra), software testing, or interest in those areas, are
especially welcome.

The anticipated time commitment for each appointee is expected to be two
hours per week on average.

To nominate a candidate for the ArchivesSpace Technical Advisory Council,
please respond to the questions below, indicate the areas of activity to
which the nominee is prepared to contribute. Send this information via
email to ArchivesSpace Program Manager Bradley Westbrook (brad.westbrook@
lyrasis.org),  who will collect nominations on behalf of the Council.
Self-nominations
are encouraged. *All nominations must be submitted by 9:00 p.m. EDT Friday,
Nov 11th.  *

Thank you for your participation in this important process, which is an
essential part of our identity and operations as a community-based software
organization.




******

1. Nominee name:



2. Nominee organization:



3. Indicate all areas to which the nominee might contribute:

___Managing/endorsing/eliciting code contributions

___Bug fixes

___Technical documentation

___Program architecture and integrations with other software

___Migration issues, including import/exports and API design and
implementation

___Application testing


4. Please briefly describe the reason the nominee would be a good fit for
the ArchivesSpace Technical Advisory Council.



-- 
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161026/d25f21c0/attachment.html>

From alexanderduryee at nypl.org  Thu Oct 27 10:24:32 2016
From: alexanderduryee at nypl.org (Alexander Duryee)
Date: Thu, 27 Oct 2016 10:24:32 -0400
Subject: [Archivesspace_Users_Group] Creating enumeration values via API
In-Reply-To: <CAPy_BxcTeUCXRT5qCT1HtAXqCWM4D9HVqa2PsdsQtrg6twV-Gg@mail.gmail.com>
References: <CAK5BadD1XrJCisNVqBpnBj3ZNHfb3FZUgYNbj+5mjbMLTzmU0w@mail.gmail.com>
 <CAPy_BxcTeUCXRT5qCT1HtAXqCWM4D9HVqa2PsdsQtrg6twV-Gg@mail.gmail.com>
Message-ID: <CAK5BadD2uTSXLm5-dxySE1zXWZoJ6Bs_YTB6rLkdzwQkKXba4A@mail.gmail.com>

Dallas,

Many thanks!  This worked perfectly.

Thanks again,
--Alex

On Fri, Oct 21, 2016 at 2:24 PM, Dallas Pillen <djpillen at umich.edu> wrote:

> Hi Alexander,
>
> We had a script that did just that using the update enumeration endpoint
> (POST /config/enumerations/:enum_id) by first getting the enumeration's
> JSON object, adding new enumeration values to the enumeration's "values"
> array, and posting the updated JSON (see example gist
> <https://gist.github.com/djpillen/4dd8f3b2e4672a1874c8ac8c646037db>).
> This handles the creation of new enumeration_values; they do not need to be
> created separately.
>
> On Fri, Oct 21, 2016 at 2:01 PM, Alexander Duryee <
> alexanderduryee at nypl.org> wrote:
>
>> As part of our deployment process, I would like to have a script that
>> automatically adds new enumeration values to certain enumerations.
>> Querying on the /config/enumerations/:enumeration_id endpoint returns a
>> JSON object that ensconces a number of enumeration_value objects, so it
>> seems like I need to create the enumeration_value, then add that to the
>> enumeration.  However, there seem to be no endpoints for creating new
>> enumeration_value objects.  Is there another method that I should be using
>> to create/update enumerations with new values via the API?
>>
>> Thanks,
>> --Alex
>>
>> --
>> Alexander Duryee
>> Metadata Archivist
>> New York Public Library
>> (917)-229-9590
>> alexanderduryee at nypl.org
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
>
> --
>
> *Dallas Pillen*Assistant Archivist for Metadata and Digital Projects
>
>
>   Bentley Historical Library <http://bentley.umich.edu/>
>   1150 Beal Avenue
>   Ann Arbor, Michigan 48109-2113
>   734.647.3559
>   Twitter <https://twitter.com/umichBentley> Facebook
> <https://www.facebook.com/bentleyhistoricallibrary>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Alexander Duryee
Metadata Archivist
New York Public Library
(917)-229-9590
alexanderduryee at nypl.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161027/4f19a8dc/attachment.html>

From clifford.allen at watermillcenter.org  Thu Oct 27 11:27:08 2016
From: clifford.allen at watermillcenter.org (Clifford Allen)
Date: Thu, 27 Oct 2016 11:27:08 -0400
Subject: [Archivesspace_Users_Group] LibraryHost
Message-ID: <CABa1G0KriGHrmsXe1xiSKdNgqvLJwuqPYk-yJVAO4j1TEX6W0A@mail.gmail.com>

Hi All,

Forgive me if this has been brought up before and is a dead-horse topic,
but as someone who is just beginning to implement ArchivesSpace, what are
the advantages/disadvantages of LibraryHost as compared to Atlas and
LYRASIS? As we are a small institution their lower price points are
attractive, but I'm wondering if that is because certain necessary
services/aspects aren't being offered.

Thanks so much in advance for weighing in.

Sincerely,

-- 
Clifford Allen
Archivist | The Watermill Center | Robert Wilson
115 W 29th St., 10th Fl., New York, NY 10001
main:  +1 212 253 7484 x 113
clifford.allen at watermillcenter.org | www.watermillcenter.org

JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY

Connect with us on Facebook <https://www.facebook.com/thewatermillcenter>,
Twitter <http://twitter.com/#%21/watermillcenter>, Instagram
<http://instagram.com/watermillcenter>, Flickr,
<http://www.flickr.com/photos/watermillresidencies/> and Vimeo
<https://vimeo.com/watermillcenter>. Join our email list!
<http://watermillcenter.org/content/newsletter-signup>

The Watermill Center is the principal operation of the Byrd Hoffman
Watermill Foundation, a US 501(c)3 organization incorporated in the state
of New York.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161027/df0b461a/attachment.html>

From atummino at sunymaritime.edu  Thu Oct 27 15:21:52 2016
From: atummino at sunymaritime.edu (Tummino, Annie)
Date: Thu, 27 Oct 2016 19:21:52 +0000
Subject: [Archivesspace_Users_Group] LibraryHost
In-Reply-To: <CABa1G0KriGHrmsXe1xiSKdNgqvLJwuqPYk-yJVAO4j1TEX6W0A@mail.gmail.com>
References: <CABa1G0KriGHrmsXe1xiSKdNgqvLJwuqPYk-yJVAO4j1TEX6W0A@mail.gmail.com>
Message-ID: <1b1114aefbd64db59088e2fd22a8718a@EX02.sunymaritime.edu>

Hi Allen,
We just started using LibraryHost a couple of months ago and it is working out great so far. I sent this same query to the SAA Lone Arrangers list and only got positive feedback about LibraryHost, which made me confident about moving forward. They also offer a free trial which is nice.

Because we have no EAD files to begin with, we are starting with a  relatively clean slate, so we didn?t need assistance with migration. Generally speaking, I am sure starting from scratch is a lot easier than what large institutions are confronting.

I?ll note that the LibraryHost expert on ASpace is currently on maternity leave, so they are not able to do a training until she returns, but we are moving forward with branding in her absence. I have found that for our needs, I?ve been getting along just fine using the ASpace help center documentation, and it?s not really been a problem that we had to put off the training. We are creating a user guide which I?d be happy to share with you.

Hope this helps,
Annie

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Clifford Allen
Sent: Thursday, October 27, 2016 11:27 AM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] LibraryHost

Hi All,

Forgive me if this has been brought up before and is a dead-horse topic, but as someone who is just beginning to implement ArchivesSpace, what are the advantages/disadvantages of LibraryHost as compared to Atlas and LYRASIS? As we are a small institution their lower price points are attractive, but I'm wondering if that is because certain necessary services/aspects aren't being offered.

Thanks so much in advance for weighing in.

Sincerely,

--
Clifford Allen
Archivist | The Watermill Center | Robert Wilson
115 W 29th St., 10th Fl., New York, NY 10001
main:  +1 212 253 7484 x 113
clifford.allen at watermillcenter.org<mailto:clifford.allen at watermillcenter.org> | www.watermillcenter.org<http://www.watermillcenter.org>

JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY

Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup>

The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161027/049c9a03/attachment.html>

From clifford.allen at watermillcenter.org  Thu Oct 27 15:56:56 2016
From: clifford.allen at watermillcenter.org (Clifford Allen)
Date: Thu, 27 Oct 2016 15:56:56 -0400
Subject: [Archivesspace_Users_Group] LibraryHost
In-Reply-To: <1b1114aefbd64db59088e2fd22a8718a@EX02.sunymaritime.edu>
References: <CABa1G0KriGHrmsXe1xiSKdNgqvLJwuqPYk-yJVAO4j1TEX6W0A@mail.gmail.com>
 <1b1114aefbd64db59088e2fd22a8718a@EX02.sunymaritime.edu>
Message-ID: <CABa1G0LQ2+7hxoASuAdUCupf7f2_3wQEsr5KssKkh2LbixkELQ@mail.gmail.com>

Thanks Annie -- we're in the same boat. Good to know that the training is
on hold; maybe that'll give us a little time to get more of our stuff
together.

I would be interested in seeing that user guide if it is not too much
trouble. This is virgin territory for us though I have worked in porting
out EAD to DAMs before... it's a little different.

Cheers,
Clifford

On Thu, Oct 27, 2016 at 3:21 PM, Tummino, Annie <atummino at sunymaritime.edu>
wrote:

> Hi Allen,
>
> We just started using LibraryHost a couple of months ago and it is working
> out great so far. I sent this same query to the SAA Lone Arrangers list and
> only got positive feedback about LibraryHost, which made me confident about
> moving forward. They also offer a free trial which is nice.
>
>
>
> Because we have no EAD files to begin with, we are starting with a
>  relatively clean slate, so we didn?t need assistance with migration.
> Generally speaking, I am sure starting from scratch is a lot easier than
> what large institutions are confronting.
>
>
>
> I?ll note that the LibraryHost expert on ASpace is currently on maternity
> leave, so they are not able to do a training until she returns, but we are
> moving forward with branding in her absence. I have found that for our
> needs, I?ve been getting along just fine using the ASpace help center
> documentation, and it?s not really been a problem that we had to put off
> the training. We are creating a user guide which I?d be happy to share with
> you.
>
>
>
> Hope this helps,
>
> Annie
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Clifford
> Allen
> *Sent:* Thursday, October 27, 2016 11:27 AM
> *To:* archivesspace_users_group at lyralists.lyrasis.org
> *Subject:* [Archivesspace_Users_Group] LibraryHost
>
>
>
> Hi All,
>
>
> Forgive me if this has been brought up before and is a dead-horse topic,
> but as someone who is just beginning to implement ArchivesSpace, what are
> the advantages/disadvantages of LibraryHost as compared to Atlas and
> LYRASIS? As we are a small institution their lower price points are
> attractive, but I'm wondering if that is because certain necessary
> services/aspects aren't being offered.
>
>
>
> Thanks so much in advance for weighing in.
>
>
>
> Sincerely,
>
>
>
> --
>
> Clifford Allen
> Archivist | The Watermill Center | Robert Wilson
> 115 W 29th St., 10th Fl., New York, NY 10001
> main:  +1 212 253 7484 x 113
> clifford.allen at watermillcenter.org | www.watermillcenter.org
>
>
>
> *JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY*
>
>
>
> Connect with us on Facebook <https://www.facebook.com/thewatermillcenter>,
> Twitter <http://twitter.com/#%21/watermillcenter>, Instagram
> <http://instagram.com/watermillcenter>, Flickr,
> <http://www.flickr.com/photos/watermillresidencies/> and Vimeo
> <https://vimeo.com/watermillcenter>. Join our email list!
> <http://watermillcenter.org/content/newsletter-signup>
>
>
> The Watermill Center is the principal operation of the Byrd Hoffman
> Watermill Foundation, a US 501(c)3 organization incorporated in the state
> of New York.
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Clifford Allen
Archivist | The Watermill Center | Robert Wilson
115 W 29th St., 10th Fl., New York, NY 10001
main:  +1 212 253 7484 x 113
clifford.allen at watermillcenter.org | www.watermillcenter.org

JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY

Connect with us on Facebook <https://www.facebook.com/thewatermillcenter>,
Twitter <http://twitter.com/#%21/watermillcenter>, Instagram
<http://instagram.com/watermillcenter>, Flickr,
<http://www.flickr.com/photos/watermillresidencies/> and Vimeo
<https://vimeo.com/watermillcenter>. Join our email list!
<http://watermillcenter.org/content/newsletter-signup>

The Watermill Center is the principal operation of the Byrd Hoffman
Watermill Foundation, a US 501(c)3 organization incorporated in the state
of New York.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161027/b2854a95/attachment.html>

From k-miller3 at northwestern.edu  Mon Oct 31 10:51:28 2016
From: k-miller3 at northwestern.edu (Karen Miller)
Date: Mon, 31 Oct 2016 14:51:28 +0000
Subject: [Archivesspace_Users_Group] exporting an identifier for use in a
	URL to the public user interface
Message-ID: <bf7a7f6cb2444901932e19172e301de2@evcspmbx05.ads.northwestern.edu>

Good morning.

We are getting ready (at long last!) to migrate from Archon to ArchivesSpace at Northwestern University. Currently we have a customized EAD Export from Archon that writes an <eadid at identifier> value that can be stuck to the end of a static URL to create a link back to the finding aid in our customized portal. The portal we use now is a Blacklight interface that draws from finding aids stored in Fedora. When we move to ArchivesSpace, we'll be using the ArchivesSpace PUI instead of the Fedora/Blacklight setup.

My question is whether there's a way to export an <eadid> element either with a url attribute that contains a full URL to the finding aid in the PUI or with an identifier attribute that can be used to build a URL. We are currently using the EAD exported from Archon to create records for ingest into our Primo discovery layer and I'd like to continue doing this with ArchivesSpace.

I saw this question raised about a year ago in the Google Group for ArchivesSpace, but the only response was a suggestion to copy the URL from the finding aid in the PUI into the EAD Location field in the Finding Aid Data sub-record in the staff interface before exporting the EAD. We have over 1100 finding aids that we're going to have to reharvest into Primo (not to mention ArchiveGrid and the Chicago Collections website) with updated URLs, and I just don't see that as a good option for us.

I though perhaps I could use the URL that appear in the staff interface (like this one):

http://archival2-d.library.northwestern.edu:8080/resources/53/edit#finding_aid

to build the URL that appears in the public user interface (like this one):

http://archival2-d.library.northwestern.edu:8081/repositories/2/resources/53

but that requires knowing the repository that holds the resource. I suppose that could be gotten from the filedesc\publicationstmt, but it seems a little inelegant, and perhaps dicey as well.

Has anybody else come up with an elegant solution to this issue? I can't imagine we're the only institution that's repurposing our EAD. Any suggestions are appreciated!

Karen

Karen D. Miller
Monographic Cataloger/Metadata Specialist
Northwestern University Libraries
Northwestern University
1970 Campus Drive
Evanston, IL 60208
www.library.northwestern.edu
k-miller3 at northwestern.edu
874.467.3462

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161031/d289066d/attachment.html>

From sdm7g at eservices.virginia.edu  Mon Oct 31 12:58:42 2016
From: sdm7g at eservices.virginia.edu (Majewski, Steven Dennis (sdm7g))
Date: Mon, 31 Oct 2016 16:58:42 +0000
Subject: [Archivesspace_Users_Group] exporting an identifier for use in
 a	URL to the public user interface
In-Reply-To: <bf7a7f6cb2444901932e19172e301de2@evcspmbx05.ads.northwestern.edu>
References: <bf7a7f6cb2444901932e19172e301de2@evcspmbx05.ads.northwestern.edu>
Message-ID: <69E56832-AA48-4A06-A1F2-1C04B9652554@eservices.virginia.edu>



In the staff interface, there is a ?View Published? button (in the same row as the ?Edit? button) that takes you to the resource in the public interface.

The template code producing that button is in frontend/app/views/shared/_resource_toolbar.html.erb :


https://github.com/archivesspace/archivesspace/blob/master/frontend/app/views/shared/_resource_toolbar.html.erb#L37-L41


          <% if record.publish %>
          <div class="btn-group">
              <%= link_to I18n.t("actions.view_published"), File.join(AppConfig[:public_proxy_url], record.uri).to_s, :target => "_blank", :class => "btn btn-sm btn-default" %>
            </div>
          <% end %>


And all it?s doing is concatenating the AppConfig[:public_proxy_url] and the resource .uri value, which has the repo value embedded. ( If you prefix it with the backend base URI instead, you?ll get the JSON model from the backend API. )



[ Note: If you are proxying public interface thru apache to another virtual host, you probably need to have changed AppConfig[:public_proxy_url] in your config.rb file from it?s default. And even if you?re not proxying, check to make sure it?s not pointing at localhost. ]

? Steve Majewski



On Oct 31, 2016, at 10:51 AM, Karen Miller <k-miller3 at northwestern.edu<mailto:k-miller3 at northwestern.edu>> wrote:

Good morning.

We are getting ready (at long last!) to migrate from Archon to ArchivesSpace at Northwestern University. Currently we have a customized EAD Export from Archon that writes an <eadid at identifier> value that can be stuck to the end of a static URL to create a link back to the finding aid in our customized portal. The portal we use now is a Blacklight interface that draws from finding aids stored in Fedora. When we move to ArchivesSpace, we?ll be using the ArchivesSpace PUI instead of the Fedora/Blacklight setup.

My question is whether there?s a way to export an <eadid> element either with a url attribute that contains a full URL to the finding aid in the PUI or with an identifier attribute that can be used to build a URL. We are currently using the EAD exported from Archon to create records for ingest into our Primo discovery layer and I?d like to continue doing this with ArchivesSpace.

I saw this question raised about a year ago in the Google Group for ArchivesSpace, but the only response was a suggestion to copy the URL from the finding aid in the PUI into the EAD Location field in the Finding Aid Data sub-record in the staff interface before exporting the EAD. We have over 1100 finding aids that we?re going to have to reharvest into Primo (not to mention ArchiveGrid and the Chicago Collections website) with updated URLs, and I just don?t see that as a good option for us.

I though perhaps I could use the URL that appear in the staff interface (like this one):

http://archival2-d.library.northwestern.edu:8080/resources/53/edit#finding_aid

to build the URL that appears in the public user interface (like this one):

http://archival2-d.library.northwestern.edu:8081/repositories/2/resources/53

but that requires knowing the repository that holds the resource. I suppose that could be gotten from the filedesc\publicationstmt, but it seems a little inelegant, and perhaps dicey as well.

Has anybody else come up with an elegant solution to this issue? I can?t imagine we?re the only institution that?s repurposing our EAD. Any suggestions are appreciated!

Karen

Karen D. Miller
Monographic Cataloger/Metadata Specialist
Northwestern University Libraries
Northwestern University
1970 Campus Drive
Evanston, IL 60208
www.library.northwestern.edu<http://www.library.northwestern.edu/>
k-miller3 at northwestern.edu<mailto:k-miller3 at northwestern.edu>
874.467.3462

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161031/9465b01c/attachment.html>

From akroeger at unomaha.edu  Mon Oct 31 13:02:36 2016
From: akroeger at unomaha.edu (Angela Kroeger)
Date: Mon, 31 Oct 2016 17:02:36 +0000
Subject: [Archivesspace_Users_Group] Character limits on sub notes?
In-Reply-To: <CY4PR03MB264840709346E35EFA85B47FB1A90@CY4PR03MB2648.namprd03.prod.outlook.com>
References: <CY4PR03MB264840709346E35EFA85B47FB1A90@CY4PR03MB2648.namprd03.prod.outlook.com>
Message-ID: <CO2PR07MB2582C7C2FDE05E52654788CCD3AE0@CO2PR07MB2582.namprd07.prod.outlook.com>

Jane asked, "Does anyone know how many characters can fit into a sub note without breaking it?"

The character limit is 65000 for any given note or subnote. We actually hit it with one finding aid, so I confirm this from personal experience.

Angela Kroeger
akroeger at unomaha.edu<mailto:akroeger at unomaha.edu>
Archives and Special Collections Associate
Dr. C.C. and Mabel L. Criss Library
University of Nebraska at Omaha
(402) 554-4159


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161031/9b3b8502/attachment.html>

From k-miller3 at northwestern.edu  Mon Oct 31 16:48:41 2016
From: k-miller3 at northwestern.edu (Karen Miller)
Date: Mon, 31 Oct 2016 20:48:41 +0000
Subject: [Archivesspace_Users_Group] exporting an identifier for use in
	a	URL to the public user interface
In-Reply-To: <69E56832-AA48-4A06-A1F2-1C04B9652554@eservices.virginia.edu>
References: <bf7a7f6cb2444901932e19172e301de2@evcspmbx05.ads.northwestern.edu>
 <69E56832-AA48-4A06-A1F2-1C04B9652554@eservices.virginia.edu>
Message-ID: <e9f16a59c6694d1486482b82cfcfad2c@evcspmbx05.ads.northwestern.edu>

Thank you, Steven!

I?m going to pass this along to our developer so he can implement it. I get the gist of it, but my coding skills stop at XSL. I really appreciate the quick and detailed response!

Karen


Karen D. Miller
Monographic Cataloger/Metadata Specialist
Northwestern University Libraries
Northwestern University
1970 Campus Drive
Evanston, IL 60208
www.library.northwestern.edu
k-miller3 at northwestern.edu
874.467.3462

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Majewski, Steven Dennis (sdm7g)
Sent: Monday, October 31, 2016 11:59 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] exporting an identifier for use in a URL to the public user interface



In the staff interface, there is a ?View Published? button (in the same row as the ?Edit? button) that takes you to the resource in the public interface.

The template code producing that button is in frontend/app/views/shared/_resource_toolbar.html.erb :


https://github.com/archivesspace/archivesspace/blob/master/frontend/app/views/shared/_resource_toolbar.html.erb#L37-L41<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_archivesspace_archivesspace_blob_master_frontend_app_views_shared_-5Fresource-5Ftoolbar.html.erb-23L37-2DL41&d=CwMGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ&m=mSeY-rdXXr63jFudhwZaHzl4qc8jfI7c3LP0OnBTsiA&s=SSlJBRkMsLGptD9crM4rDHMJ4RcJ9itGa1BlSVYOWOM&e=>


          <% if record.publish %>
          <div class="btn-group">
              <%= link_to I18n.t("actions.view_published"), File.join(AppConfig[:public_proxy_url], record.uri).to_s, :target => "_blank", :class => "btn btn-sm btn-default" %>
            </div>
          <% end %>


And all it?s doing is concatenating the AppConfig[:public_proxy_url] and the resource .uri value, which has the repo value embedded. ( If you prefix it with the backend base URI instead, you?ll get the JSON model from the backend API. )



[ Note: If you are proxying public interface thru apache to another virtual host, you probably need to have changed AppConfig[:public_proxy_url] in your config.rb file from it?s default. And even if you?re not proxying, check to make sure it?s not pointing at localhost. ]

? Steve Majewski



On Oct 31, 2016, at 10:51 AM, Karen Miller <k-miller3 at northwestern.edu<mailto:k-miller3 at northwestern.edu>> wrote:

Good morning.

We are getting ready (at long last!) to migrate from Archon to ArchivesSpace at Northwestern University. Currently we have a customized EAD Export from Archon that writes an <eadid at identifier> value that can be stuck to the end of a static URL to create a link back to the finding aid in our customized portal. The portal we use now is a Blacklight interface that draws from finding aids stored in Fedora. When we move to ArchivesSpace, we?ll be using the ArchivesSpace PUI instead of the Fedora/Blacklight setup.

My question is whether there?s a way to export an <eadid> element either with a url attribute that contains a full URL to the finding aid in the PUI or with an identifier attribute that can be used to build a URL. We are currently using the EAD exported from Archon to create records for ingest into our Primo discovery layer and I?d like to continue doing this with ArchivesSpace.

I saw this question raised about a year ago in the Google Group for ArchivesSpace, but the only response was a suggestion to copy the URL from the finding aid in the PUI into the EAD Location field in the Finding Aid Data sub-record in the staff interface before exporting the EAD. We have over 1100 finding aids that we?re going to have to reharvest into Primo (not to mention ArchiveGrid and the Chicago Collections website) with updated URLs, and I just don?t see that as a good option for us.

I though perhaps I could use the URL that appear in the staff interface (like this one):

http://archival2-d.library.northwestern.edu:8080/resources/53/edit#finding_aid

to build the URL that appears in the public user interface (like this one):

http://archival2-d.library.northwestern.edu:8081/repositories/2/resources/53

but that requires knowing the repository that holds the resource. I suppose that could be gotten from the filedesc\publicationstmt, but it seems a little inelegant, and perhaps dicey as well.

Has anybody else come up with an elegant solution to this issue? I can?t imagine we?re the only institution that?s repurposing our EAD. Any suggestions are appreciated!

Karen

Karen D. Miller
Monographic Cataloger/Metadata Specialist
Northwestern University Libraries
Northwestern University
1970 Campus Drive
Evanston, IL 60208
www.library.northwestern.edu<http://www.library.northwestern.edu/>
k-miller3 at northwestern.edu<mailto:k-miller3 at northwestern.edu>
874.467.3462

_______________________________________________
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=CwMGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ&m=mSeY-rdXXr63jFudhwZaHzl4qc8jfI7c3LP0OnBTsiA&s=ldvZX13JbQnwmOZwZczOV1zZHENuYJrZqJdfEPTT9iA&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161031/73238f35/attachment.html>