[Archivesspace_Users_Group] [archivesspace] Digital Object module use

[Michael Shallcross]

Hi, all; this thread was very useful in our thinking of how we might employ
the digital object module in our ArchivesSpace-Archivematica-DSpace
Workflow Integration project.  Just wanted to share a recent blog post that
details our current thoughts:

http://archival-integration.blogspot.com/2015/11/digital-objects-and-archivesspace.html

It would be great to hear thoughts/reactions--thanks!

Best,

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/
http://archival-integration.blogspot.com/
@umbhlcuration



On Fri, Oct 9, 2015 at 2:48 PM, Jarrett Drake <jarrett.m.drake at gmail.com>
wrote:

> I think the use cases will vary in response to your question, Ben, but for
> our context, I am anticipating that ArchivesSpace will hold our canonical
> administrative data for all our archival collections; accessions, donors
> (agents), digital objects, and possibly locations. There will likely be
> other application environments (BitCurator, Hydra) in which we'll do more
> granular activities, but I foresee ArchivesSpace as our application in
> which these different pieces are woven together. I do not foresee us
> relying on the Resources module much, but if we were, then I see your point
> about not using the DO module in this exact fashion, and instead simply
> adding a DO instance directly within a resource record. However, our
> descriptive data currently live outside of AT and may well live outside of
> ArchivesSpace; this decision and many others will be made in concert with
> our library systems team.
>
> Jarrett
>
>
>
> On Thu, Oct 8, 2015 at 8:50 PM, Ben Goldman <bmrgoldman at gmail.com> wrote:
>
>> I've read through this thread a couple of times now, and I keep coming
>> back to Maureen's question "what is the good of the digital object record?"
>> If most of the fields and related data in the DO replicate fields and data
>> in the archival object (and I agree they do, and I don't necessarily want
>> them to), I have been wondering why not simply add a digital object
>> identifier field to the archival object? It seems a rather unwieldy way
>> just to add URIs. But maybe there is something more to it I'm missing (or
>> we're not discussing)?
>>
>> -Ben
>>
>>
>>
>> On Thu, Oct 8, 2015 at 5:07 PM, Jarrett Drake <jarrett.m.drake at gmail.com>
>> wrote:
>>
>>> Thank you to everyone who responded to this revived thread. At my
>>> institution, we are currently discussing how to best optimize the DO module
>>> without replicating data in other systems. We aren't live with these other
>>> systems yet, but my hunch is that the DO module will function similarly to
>>> how Chris described the plans at the University of Illinois. In our case,
>>> we're thinking that each AIP would be represented as a digital object
>>> component that is nested within the digital object record titled after the
>>> collection's call number. The DO component would be very thin; likely just
>>> identifiers (an absolute path to the location of preservation copies) and
>>> extents.
>>>
>>> Like others, we'd likely do the actual management elsewhere. I like
>>> Maureen's phrase about the DO module being the "glue" that holds together
>>> disparate systems.
>>>
>>> Thanks again!
>>>
>>> Jarrett
>>>
>>> On Fri, Oct 2, 2015 at 5:11 PM, Max Eckard <eckardm at umich.edu> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> It sounds like we're pretty much on the same page as Yale and Illinois.
>>>> Acknowledging that we're also still thinking about this because we aren't
>>>> live with ASpace yet, it's safe to say that our digital object records will
>>>> be very minimal, just a "simple" digital with the title and a pointer to an
>>>> AIP in DSpace/Hydra (where it may be more complex). We're thinking of the
>>>> DO module more as a place to record location than as a place to "manage"
>>>> digital objects or the events that happen to them.
>>>>
>>>> While we have mostly been considering born-digital use cases so far, I
>>>> suspect we'll follow the same principles for digitized material as well.
>>>> Maureen's idea of describing born-digital and digitized records differently
>>>> seems reasonable.
>>>>
>>>> The plan here is to get descriptive information for digital objects in
>>>> our repository from the resource record. We'll have technical information
>>>> from Archivematica, and that sit "chipped dog"-style with the digital
>>>> object in the repository.
>>>>
>>>> We're also investigating expanding rights in resource records so that
>>>> ASpace can be the system of record for machine-actionable PREMIS rights
>>>> statements coming from Archivematica. These would extend to digital object
>>>> instances, although we still have questions about how exactly that would
>>>> work. We still intend to have human-readable Conditions Governing Access
>>>> notes as well.
>>>>
>>>> Thanks! Have a nice weekend!
>>>> Max
>>>>
>>>>
>>>> On Fri, Oct 2, 2015 at 4:17 PM, Prom, Christopher John <
>>>> prom at illinois.edu> wrote:
>>>>
>>>>> Maureen,
>>>>>
>>>>> This matches more or less what the Univeristy of Illinois Archives is
>>>>> currently doing and we plan to continue with this in the future.  The only
>>>>> additional point I'd like to make is that we are following the rule of "one
>>>>> digital object record per each top level resource record."
>>>>>
>>>>> In this way, the DO record operates as minimal descriptive record for
>>>>> an entire archival information packet, with the majority of the technical
>>>>> and item level descriptive metadata handled in the preservation repository
>>>>> and DO access systems, which leverages the advantages of both systems.
>>>>>
>>>>> Chris Prom
>>>>> University of Illinois Archives
>>>>>
>>>>>
>>>>> On Oct 2, 2015, at 2:59 PM, Callahan, Maureen <
>>>>> maureen.callahan at yale.edu> wrote:
>>>>>
>>>>> I’m really glad you resuscitated this thread, Jarrett, because we’re
>>>>> talking a lot about this at Yale.
>>>>>
>>>>> A lot of work is happening right now on integration of archival
>>>>> description in our database of record (ArchivesSpace) with our digital
>>>>> preservation system (Preservica) and our access system for digitized
>>>>> objects (Blacklight).
>>>>>
>>>>> Here are some common questions that have come up and my answers to
>>>>> them:
>>>>>
>>>>> 1. Are we “managing” digital objects in ArchivesSpace?
>>>>> This depends on what you mean by managing.
>>>>> I cannot think of a situation where ArchivesSpace would be the only
>>>>> layer between metadata and a file system (other than, possibly, very basic
>>>>> digitization activities), so no, we are not doing that kind of management
>>>>> in ArchivesSpace.
>>>>> But I think ArchivesSpace digital objects WILL be the glue between two
>>>>> different management systems — ArchivesSpace (for the description of
>>>>> functions like accessioning and description) and
>>>>> Preservica/FindIt/Quicksearch/Kaltura/HathiTrust/what-friggin-ever where
>>>>> more robust information about complex objects, preservation actions,
>>>>> technical facts about the object, etc. are stored.
>>>>> As I see it, the best thing that AS digital objects could do would be
>>>>> to be a place to keep URIs so that we can sync the systems together. If we
>>>>> think about it this way, this whole project becomes a lot less complicated,
>>>>> I think.
>>>>>
>>>>> 2. What is the good of the digital object record?
>>>>> The digital object record lets us keep structured metadata in
>>>>> ArchivesSpace about digital objects that can serialize as ead//dao or METS.
>>>>> It can also be accessed through the API as structured, JSON objects. We had
>>>>> discussed the idea of using “location of copies” and “location of
>>>>> originals” notes as a possible alternative to DOs, but there is an
>>>>> advantage to storing information about digital objects in a DO record
>>>>> rather than having a URL as part of a string in a note. Notes are difficult
>>>>> to query and manage; digital objects are a bit easier.
>>>>> There’s also a bit of extra metadata that can be created/stored in the
>>>>> digital object record that can help our public interfaces know what to do
>>>>> with these links to other system, which is pretty useful.
>>>>>
>>>>> 3. Should digital surrogates and born-digital records be treated
>>>>> differently in ArchivesSpace?
>>>>> If the DO is just the glue between the description of the object and
>>>>> the system that gives you the object, then no. I think that they need to be
>>>>> *described* differently, because there’s a different facticity to
>>>>> them as records, but I don’t think that they need to be managed
>>>>> differently. And since there are really pretty good attributes and elements
>>>>> on the digital object record to help us determine what kind of a digital
>>>>> object we’re dealing with and how it should load/display, I don’t think
>>>>> it’s a problem to have many digital objects on an archival object that
>>>>> point to different manifestations in different systems.
>>>>>
>>>>> So here’s what our digital objects look like:
>>>>> Title: display title from archival object (title and date) — N.B.,
>>>>> this is only because it’s required. I’d prefer not to have the duplicate
>>>>> data.
>>>>> Publish: publish status from archival object
>>>>> Digital object identifier: handle to object in
>>>>> Blacklight/Preservica/Whatever
>>>>>
>>>>> Most of the creation of digital objects will be done through scripting
>>>>> or automatic integration between systems.
>>>>> Since we’re not pointing to actual files in actual systems, we won’t
>>>>> be using FIleURIs.
>>>>>
>>>>> We may include more metadata to indicate whether this is a digital
>>>>> object that takes the user to an access system or whether it takes a staff
>>>>> member to the place where she can do preservation actions (this will also
>>>>> affect the publish element).
>>>>>
>>>>> What about everyone else? How are you using digital objects? By the
>>>>> way, we’re still in the middle of figuring this out, so the above only
>>>>> represents my thinking and current understanding of the direction at Yale.
>>>>>
>>>>> Maureen
>>>>>
>>>>>
>>>>> On Sep 28, 2015, at 9:55 AM, Jarrett Drake <jarrett.m.drake at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'm reviving this thread in case others have more thoughts about the
>>>>> digital objects module and its utility in regards to born-digital material.
>>>>> If you're using it in your workflow, I'd be curious to know how. Please
>>>>> contact me here or offline.
>>>>>
>>>>> Best,
>>>>> Jarrett
>>>>>
>>>>> On Wednesday, February 25, 2015 at 9:49:04 PM UTC-5, Carolyn Runyon
>>>>> wrote:
>>>>>>
>>>>>> Good question!
>>>>>>
>>>>>> We’ve decided not use the digital object module in ASpace in an
>>>>>> effort not to duplicate the work we have to do to upload our digital
>>>>>> objects to CONTENTdm. If ASpace decided to grow the digital object module
>>>>>> (with embedded viewers/players OAI-PMH harvest ability,etc.), we’d
>>>>>> definitely take advantage of the module. As it stands, I can’t justify the
>>>>>> extra work it would take to maintain our digital object data and metadata
>>>>>> in 2 different systems.
>>>>>>
>>>>>> Maybe others have a different view?
>>>>>>
>>>>>> Carolyn
>>>>>>
>>>>>>
>>>>>> Carolyn Runyon, Digital Archivist
>>>>>> Special Collections & University Archives
>>>>>> University of Tennessee at Chattanooga
>>>>>> 615 McCallie Ave., Chattanooga, TN  37403
>>>>>> csg... at mocs.utc.edu, (423) 425-4503
>>>>>> Dept. 6456, LIB 439C
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 12, 2015, at 4:43 PM, 'Ben Goldman' via ArchivesSpace <
>>>>>> archiv... at googlegroups.com> wrote:
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I'd be interested to hear more from those of you using the Digital
>>>>>> Object module in ASpace. How are you using it, to support what aims. Are
>>>>>> you using it to get <dao> tags in EAD, for recording existence of digital
>>>>>> surrogates (linking or not), for notating born-digital material or even web
>>>>>> archives? Are you using the grouping feature in the module to organize
>>>>>> digital object hierarchies? We're trying to sort out what should be our
>>>>>> best practices around using this module (or not) to support some of the
>>>>>> scenarios I just mentioned.
>>>>>>
>>>>>> -Ben
>>>>>>
>>>>>> Ben Goldman
>>>>>> Digital Records Archivist
>>>>>> Penn State University Libraries
>>>>>>
>>>>>> --
>>>>>> 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 archivesspac... at googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=fCX0McITWnHK7ytux_2n9Ub4wwct61jGqvschXNygZg&s=nMmM45GcfxM1D6NHQuMcGbzuULdjjPDozcVpztm5_qY&e=>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> 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
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=fCX0McITWnHK7ytux_2n9Ub4wwct61jGqvschXNygZg&s=nMmM45GcfxM1D6NHQuMcGbzuULdjjPDozcVpztm5_qY&e=>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Max Eckard*
>>>> *Assistant Archivist for Digital Curation*
>>>>
>>>>
>>>> Bentley Historical Library
>>>> 1150 Beal Ave.
>>>> Ann Arbor, MI 48109-2113
>>>> 734/763-7518 <734.763.7518>
>>>> http://bentley.umich.edu/
>>>>
>>>> --
>>>> 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.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ArchivesSpace" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/archivesspace/92Dyl9Y3za8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> archivesspace+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Ben Goldman
>> Digital Records Archivist
>> Penn State University Libraries
>> University Park, PA
>> 814-863-8333
>> http://www.libraries.psu.edu/psul/speccolls.html
>>
>> --
>> 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.
>>
>
> --
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20151118/2c4766b3/attachment.html>