[Archivesspace_Users_Group] Fwd: exporting resource components as MARCXML

[Jason Loeffler]

Hi all,

I've seen some work from a few quarters on tweaking MARC and EAD exports. I
may be missing something but these all seem to work with exporting resource
records from the top of the tree. Our immediate use case is batch exporting
descendant archival objects in MARC* for inclusion in our ILS. As such,
resurrecting this thread to get a pulse of whether other institutions (and
vendors) might have a use for this or if there's any work already ongoing
in this area. (Unfortunately, we don't have a full-time Ruby dev on staff.)

Best, Jason

Jason Loeffler
Technology Consultant
The American Academy in Rome
Minor Science | Application Development & Metadata Strategy
Brooklyn, New York
jason at minorscience.com
(347) 405-0826
minorscience (Skype)


---------- Forwarded message ----------
From: Jason Loeffler <j at minorscience.com>
Date: Fri, Nov 6, 2015 at 3:56 PM
Subject: exporting resource components as MARCXML
To: Archivesspace Users Group <
archivesspace_users_group at lyralists.lyrasis.org>


Hi everyone.

Posted this on AR/JIRA and here, too, in the event any one has ideas.

Here's how we're using ArchivesSpace to catalog visual materials:

Repository
    Collection (Resource)
        Photographic Material (Archival Object, Resource Component)
            Item (Archival Object, Resource Component)
                Digital Object

>From the OPAC side, we'd like to represent the Photographic Material
resource component as a discrete biblio holding in our OPAC.

As I understand it, ArchivesSpace only exports top-level resources as
MARCXML (i.e. Collection, in this case). Child resource components are
available by exporting EAD container objects.

This is not ideal for our use case, as any post-processing and reformatting
of EAD for consumption by OPACs is impractical. For example, EAD "flattens"
subjects/agents (does not preserve datafield/subfields expected by
consuming OPACs). Additionally, EAD output is monolithic; parsing several
thousand container tags is onerous at best.

Can someone confirm whether this sort of task suitable for plugin
development? I'm new to plugin architecture and could use some guidance
before I do the deep dive and/or promote this idea to the ArchivesSpace
developers. Moreover, is this a feature other institutions could benefit
from?

Thanks and best, Jason

Jason Loeffler
Principal
Minor Science | Application Development & Metadata Strategy
Brooklyn, New York
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160307/53494290/attachment.html>