[Archivesspace_Users_Group] batch delete dates saga continues

[Margaret Kidd]

I second that last part of Lydia's remarks about where to begin learning
more about XML, JSON, python, ruby, etc. and applying it to ArchivesSpace.
I want to learn, but it is overwhelming to know where to begin and my time
to devote to it is rather limited. Every time I start trying to teach
myself I have other work priorities that take up all my time and soon
forget whatever progress I have made.

Thanks,

Margaret


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

Margaret T. Kidd

Project Archivist, Special Collections & Archives

VCU Libraries | Tompkins-McCaw Library for the Health Sciences

509 N. 12th Street / Box 980582, Richmond, VA 23298-0582

(804) 828-3152
[image: em_twitter.png] <https://twitter.com/VCUTMLibrary> [image:
em_fb.png] <https://www.facebook.com/VCUTMLib>


<http://www.vcu.edu/>      <http://vaheritage.org>


On Fri, Nov 10, 2017 at 12:02 PM, Tang, Lydia <ltang5 at lib.msu.edu> wrote:

> Mark,
> Thank you for identifying my problem!  Just for the sake of technological
> dummies like me, what should I do?  Everything there (besides removing the
> <unitid> tags is exactly as it spat out of ArchivesSpace, so I wonder if
> the export allowed the invalid characters?  I also wonder if the importing
> process could be improved within the ArchivesSpace code to search for
> “aspace_" and not batch add it as well as recognize (or not export out in
> the first place) the "Linear Feet" / linear_feet controlled vocabulary?
> Ideally, after establishing with the database that linear_feet should
> publish as Linear Feet, I wish it would continue to recognize that rule
> when new stuff is imported in.
> I was also meaning poll people on “how do I even get started” with
> learning more about working the ArchivesSpace guts?  I can understand EAD
> but obviously don’t know the wizardry possible with XML, there’s JSON,
> python, etc, and I would be interested in starting courses with Code
> Academy to learn, but I don’t even know where to begin.  Advice appreciated!
> Lydia
>
> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf
> of "Custer, Mark" <mark.custer at yale.edu>
> Reply-To: Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> Date: Friday, November 10, 2017 at 11:50 AM
> To: Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> Subject: Re: [Archivesspace_Users_Group] batch delete dates saga continues
>
> Lydia,
>
> In the EAD files that you attached, both have invalid XML characters in
> them (Unicode: 0x14).  Those are easy to remove before re-importing in an
> XML editor like oXygen, but I'm curious how they got into ASpace in the
> first place?   In any event, it's possible that that's what's blocking your
> imports this time around, and if that's the issue, if you just fix on those
> issues, then the ASpace importer won't tell you about the next issue until
> it runs again.
>
> In any event, I'd also suggest making  the following changes to your XML
> file before re-importing, so perhaps the snag is a good thing for now 😊 :
>
> ·         ASpace adds "aspace_" to all of the @id values in the EAD file
> upon export.  If you don't remove those before reimporting, then on the
> next export you'll get "aspace_aspace_".  Removing them will invalidate the
> EAD file, but ASpace doesn't care whether the file is valid or not upon
> re-importing it.
> ·         ASpace expects to have the database values for the controlled
> value terms in the exports, not the translation values.  So, if you don't
> change things like "Linear Feet" to linear_feet and "Mixed Materials" to
> mixed_materials, then you'll wind up with new database values in ASpace
> after the import.  Those of course can be merged after the fact, but that's
> another step, and it would be unfortunate to have to do that on every
> occasion.
>
> There's a lot more to say on the practice of re-importing EAD into ASpace,
> but I haven't still come up with a great strategy for that, so basically we
> try to avoid it 😊
>
> Mark
>
>
> -----Original Message-----
> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of
> Tang, Lydia
> Sent: Friday, 10 November, 2017 10:47 AM
> To: Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> Subject: Re: [Archivesspace_Users_Group] batch delete dates saga continues
>
> Wizardry!  Thank you, Olivia!  I would have NEVER figured that out.  It
> seemed to take out the <unitdate> tags perfectly but I ended up getting
> snagged on importing because of, um, a seemingly benign line which was
> marked as not well-formed.  Oof, so close, but snagged up!
> Lydia
>
> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf
> of Olivia S Solis <livsolis at utexas.edu>
> Reply-To: Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> Date: Friday, November 10, 2017 at 10:36 AM
> To: Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> Subject: Re: [Archivesspace_Users_Group] batch delete dates saga continues
>
> <unitda[^>]+>[^<]+<\/unitdate>
>
> _______________________________________________
> 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/20171110/7126e202/attachment.html>