> We have a lot of local knowledge and a practical base line of
> experience on modeling and operations within the Hydra community, but
> we don't yet seem to have a good mechanism for sharing this. The
> Software Versions Installation Registry
> <https://wiki.duraspace.org/display/hydra/Software+Versions+Installati...> and
> Deployment Hardware Information
> <https://wiki.duraspace.org/display/hydra/Deployment+Hardware+Information> on
> the wiki are a good start at documenting and sharing these practices
> on the ops side.

> I'd like to see if we couldn't do something similar to these pages on
> content modeling approaches on the wiki, and create a knowledge base
> where the answers to good questions like Jim's could be found at any
> time. Mike, Ben: as you develop descriptions of your approaches to
> share, maybe you could also park them on the wiki? I've talked to Lynn
> about doing the same for some of our models.

> This (populating the wiki with exemplar models from different
> institutions / heads) seems like a good potential activity for the
> Sept Partners meeting.

> - Tom

> On Jul 24, 2012, at 7:24 AM, Benjamin Armintor wrote:

>> Just to chime in: We've been using atomic objects for images
>> (documents and audio too, actually) at Columbia, but I'm trying to
>> move to a compound model that uses RELS-INT to document the
>> relationship between the various datastreams.  I'll try to keep the
>> list posted as that develops (hopefully I'll have something to show at
>> the September Hydra Partners meeting).

>> - Ben

>> On Tue, Jul 24, 2012 at 10:01 AM, Jim Coble <jim.co...@duke.edu
>> <mailto:jim.co...@duke.edu>> wrote:
>>> We will also be glad to share whatever we come up with on the list.  Our
>>> situation is perhaps a bit different than others in that our current
>>> project
>>> vis-�-vis still image files is purely preservation focused.  We have a
>>> separate application that provides public access to derivative image
>>> files
>>> and I doubt that will change anytime soon.  We will be using Fedora
>>> / Hydra
>>> at this point only to store the preservation master files (which, in our
>>> case, are TIFF files) and associated metadata (along with a few
>>> staff-facing
>>> services).

>>> --Jim

>>> From: hydra-tech@googlegroups.com
>>> <mailto:hydra-tech@googlegroups.com>
>>> [mailto:hydra-tech@googlegroups.com] On
>>> Behalf Of Mike Stroming
>>> Sent: Tuesday, July 24, 2012 9:49 AM

>>> To: hydra-tech@googlegroups.com <mailto:hydra-tech@googlegroups.com>
>>> Subject: Re: [hydra-tech] New to Hydra -- example practices for still
>>> images?

>>> Hi Richard,

>>> Excellent point about not going off-list.  I will try to get
>>> something to
>>> the list regarding our modelling, etc, sometime next week, time
>>> permitting.

>>> Thanks,
>>> Mike Stroming

>>> On Tue, Jul 24, 2012 at 4:54 AM, Richard Green <R.Gr...@hull.ac.uk
>>> <mailto:R.Gr...@hull.ac.uk>> wrote:

>>> Jim

>>> Welcome!  It's a good idea to join forces with the folks at
>>> Northwestern but
>>> it would be good for others in the community if Mike (please, Mike)
>>> would
>>> actually share some of the modelling information with this list for the
>>> benefit of others rather than go totally off-list.

>>> In Hull we are just about to "do" simple images - primarily in order
>>> to deal
>>> with a big collection of old maritime photos that we want to get
>>> digitised
>>> and safe.  If you'd asked us a few weeks ago how we were going to do
>>> them
>>> I'd have given you the answer proposed as the basic Hydra image set up a
>>> couple of years or more ago (below); I'd now add a caveat that we
>>> may change
>>> this in the light of anything that might come out of your
>>> interaction with
>>> NU, and also out of a discussion I'm having with the Islandora folks
>>> to see
>>> what might be possible in terms of interoperability for simple image
>>> objects.  I keep using terms like 'simple' and 'basic' because at
>>> this stage
>>> we (Hull) are probably not in the market for the very clever image
>>> manipulation capabilities that NU have based on j2k -- more a
>>> straightforward
>>> galley browse leading to splash pages and a download capability.

>>> The current intention is that our images will be compound (multi-
>>> content
>>> datastream) objects because the content datastreams will represent
>>> the same
>>> thing just in different resolutions etc.  We'll use the generic simple
>>> content cModel and the static image cModel in combination (see
>>> https://wiki.duraspace.org/display/hydra/Hydra+objects%2C+content+mod...).
>>> Each object will only deal with a single image and so we will not
>>> need to
>>> 'order' in a page sense, but in any case the contentMetadata datastream
>>> provides for sequencing multiple download links (perhaps you were
>>> thinking
>>> about ordering *across* objects rather than *within* them which is a
>>> different ball game)?

>>> Our descMetadata will be MODS (as for all our other content) and
>>> we'd use
>>> technicalMetadata for a JHOVE (or similar) record where that's
>>> appropriate.
>>> We actually have a 'properties' datastream that we use for things like
>>> depositor information and I think we would put QA information there
>>> too --
>>> that said, I know others have a 'workflow' datastream to deal with such
>>> matters.

>>> Images is a poorly developed area within production Hydra heads at the
>>> moment so we'll all be interested in your work and the discussions
>>> that you
>>> have with NU if you'd care to share the juicy bits!

>>> Best

>>> Richard

>>> ___________________________________________________________________

>>> Richard Green

>>> Consultant to Library & Learning Innovation, University of Hull

>>> managing the Hydra in Hull and Hydra (Hull) Projects

>>> http://hydra.hull.ac.uk

>>> http://projecthydra.org

>>> From: hydra-tech@googlegroups.com
>>> <mailto:hydra-tech@googlegroups.com>
>>> [mailto:hydra-tech@googlegroups.com] On
>>> Behalf Of Jim Coble
>>> Sent: 23 July 2012 9:32 PM
>>> To: hydra-tech@googlegroups.com <mailto:hydra-tech@googlegroups.com>
>>> Subject: RE: [hydra-tech] New to Hydra -- example practices for still
>>> images?

>>> Mike---

>>> That sounds good.  I'll switch to using your individual email
>>> address to set
>>> that up.  Thanks!

>>> --Jim

>>> From: hydra-tech@googlegroups.com
>>> <mailto:hydra-tech@googlegroups.com>
>>> [mailto:hydra-tech@googlegroups.com] On
>>> Behalf Of Mike Stroming
>>> Sent: Monday, July 23, 2012 4:11 PM
>>> To: hydra-tech@googlegroups.com <mailto:hydra-tech@googlegroups.com>
>>> Subject: Re: [hydra-tech] New to Hydra -- example practices for still
>>> images?

>>> Hi Jim,

>>> At Northwestern University Library, we are currently developing a
>>> Digital
>>> Image Library application using Hydra
>>> (http://projecthydra.org/apps-demos/northwestern-digital-image-library...).

>>> I wouldn't mind setting up a call where I can demo our app to you
>>> and answer
>>> these questions.

>>> Does that sound alright?

>>> Thanks,
>>> Mike Stroming
>>> Software Developer
>>> Northwestern University Library

>>> On Mon, Jul 23, 2012 at 11:47 AM, Jim Coble <jim.co...@duke.edu
>>> <mailto:jim.co...@duke.edu>> wrote:

>>> At Duke, we are beginning to build a preservation repository using
>>> Fedora.
>>> Three of us attended OR2012, which confirmed our interest in Hydra.
>>>  Two of
>>> us are on the waiting list for this year's Hydra Camp.  In the meantime,
>>> we'd like to see if we can make some progress on our initial Fedora
>>> pilot
>>> project, which focuses on preserving still image files and associated
>>> metadata in Fedora in a Hydra-ish manner.  We would be interested in
>>> learning how other Hydra sites that are dealing with still images are
>>> modeling and storing them.  For example ... What content models and
>>> relationships are you using?  What are you storing in the various
>>> xxxMetadata datastreams in the Hydra commonMetadata content model?
>>>  How are
>>> you handling ordering among items and/or among components (e.g.,
>>> pages) of
>>> an item?  If you have example Foxml objects you can share, we think
>>> those
>>> would be useful to look at.  One question we have in particular
>>> concerns the
>>> technicalMetadata datastream.  Is it being used just for the technical
>>> metadata extracted from the image file itself?  Our digitization
>>> operation
>>> also creates and maintains additional "technical" metadata (such as
>>> when QA
>>> was done on the master image file and by whom) that they would to
>>> preserve
>>> and we're wondering if this should be mixed in with the technical
>>> metadata
>>> extracted from the image file or maintained separately.  We're still
>>> very
>>> new to all this and I'm not even sure we know the right questions to be
>>> asking ourselves at this point.  That's why we think we some examples or
>>> pointers on how other Hydra sites are handing still image files and
>>> metadata
>>> would be helpful.
>>> Thanks for any assistance you can provide.
>>> --Jim Coble
>>> Perkins Library
>>> Duke University

>>> **************************************************
>>> To view the terms under which this email is
>>> distributed, please go to
>>> http://www2.hull.ac.uk/legal/disclaimer.aspx
>>> **************************************************