Thanks, Stuart. Adding complete metadata to the SIP certainly makes sense
for a monolithic preservation/access system like Rosetta. It seems less
applicable to a distributed preservation and access environment like ours.
Descriptive metadata changes quite frequently, and syncing that data
between access and preservation could be problematic. Have others solved
that problem with automation in an [insert access system here] to
Archivematica environment?
Outside of systems like Rosetta and Archivematica, I see room for doing
preservation/protection of data that changes frequently by developing a
robust storage architecture that includes time-based snapshots, redundancy,
and geographic replication. I'm curious if anyone on this list has
addressed the frequently changing data problem in this way.
Have a great weekend,
Andy
On Fri, Jun 2, 2017 at 3:49 PM, Stuart A. Yeates <[log in to unmask]> wrote:
> We're currently migrating a number of in-house and DSpace systems into SIPs
> for ingest into Rosetta.
>
> My advice is to put as much metadata as possible into the METS. For
> example, just this week we seriously discussed putting sushi sections in at
> the item level. Previously sushi was done by very different systems at very
> different levels, but it's emerged as the only serious standard for
> encoding usage statistics.
>
> We're also using putting TEIHDRs and things like that in, simply because it
> makes them much more available.
>
> cheers
> stuart
>
> --
> ...let us be heard from red core to black sky
>
> On 3 June 2017 at 01:56, Andrew Weidner <[log in to unmask]> wrote:
>
> > Hi all,
> >
> > Can anyone point me to guidelines or best practices documentation around
> > creating SIPs for transfer to archival storage? What does an ideal AIP
> look
> > like for digitized cultural heritage materials?
> >
> > I'd like to set up a pipeline that sends single object (e.g. one
> > photograph, one book) SIPs from our digitization workflow to
> Archivematica
> > for automated transfer to archival storage. Here's a brief slide deck
> > outlining the approach I'm envisioning:
> >
> > https://docs.google.com/presentation/d/19F5seismyBdhgIWk7Kt0jmJjqis--
> > FCpOwNr3v6Iu-w/edit?usp=sharing
> >
> > I welcome any thoughts that you all may have on this, especially about
> > pitfalls to avoid.
> >
> > Thanks,
> >
> > Andy
> >
>
|