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
On Mon, Jul 23, 2012 at 11:47 AM, Jim Coble <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
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] On Behalf Of Mike Stroming
Sent: Monday, July 23, 2012 4:11 PM
To: hydra-tech@googlegroups.com
Subject: Re: [hydra-tech] New to Hydra -- example practices for still images?
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
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+models +%28cModels%29+and+disseminators#Hydraobjects%2Ccontentmodels%28cModels%
29anddisseminators-models). 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!
From: 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
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]
On Behalf Of Mike Stroming
Sent: Monday, July 23, 2012 4:11 PM
To: hydra-tech@googlegroups.com
Subject: Re: [hydra-tech] New to Hydra -- example practices for still
images?
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> 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 **************************************************
On Tue, Jul 24, 2012 at 4:54 AM, Richard Green <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!****
> *From:* 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
> *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<hydra-tech@googlegroups.com>]
> *On Behalf Of *Mike Stroming
> *Sent:* Monday, July 23, 2012 4:11 PM
> *To:* hydra-tech@googlegroups.com
> *Subject:* Re: [hydra-tech] New to Hydra -- example practices for still
> images?****
> 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> 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 > **************************************************
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] On Behalf Of Mike Stroming
Sent: Tuesday, July 24, 2012 9:49 AM
To: 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!
From: hydra-tech@googlegroups.com<mailto: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?
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 **************************************************
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).
On Tue, Jul 24, 2012 at 10:01 AM, Jim Coble <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] On
> Behalf Of Mike Stroming
> Sent: Tuesday, July 24, 2012 9:49 AM
> To: 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> 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!
> From: 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
> 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] On
> Behalf Of Mike Stroming
> Sent: Monday, July 23, 2012 4:11 PM
> To: hydra-tech@googlegroups.com
> Subject: Re: [hydra-tech] New to Hydra -- example practices for still
> images?
> 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> 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 > **************************************************
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 and 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> 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] On
>> Behalf Of Mike Stroming
>> Sent: Tuesday, July 24, 2012 9:49 AM
>> To: 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> 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!
>> From: 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
>> 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] On
>> Behalf Of Mike Stroming
>> Sent: Monday, July 23, 2012 4:11 PM
>> To: hydra-tech@googlegroups.com
>> Subject: Re: [hydra-tech] New to Hydra -- example practices for still
>> images?
>> 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> 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 >> **************************************************
As someone who knows little about content modeling in Fedora/Hydra and is currently in the middle of such work, I would really like to see other models.
> 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!
>>> 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?
>>> 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.
Is that what you envisage? What else does it need? Or is this not the sort of thing you envisaged? In which case?
The page is intended as a straw man...
R
From: hydra-tech@googlegroups.com [mailto:hydra-tech@googlegroups.com] On Behalf Of Tom Cramer
Sent: 25 July 2012 4:07 PM
To: hydra-tech@googlegroups.com
Cc: Tom Cramer
Subject: Re: [hydra-tech] New to Hydra -- example practices for still images?
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> 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] On
Behalf Of Mike Stroming
Sent: Tuesday, July 24, 2012 9:49 AM
To: 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> 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
**************************************************
To view the terms under which this email is distributed, please go to http://www2.hull.ac.uk/legal/disclaimer.aspx **************************************************
I definitely think something like this will be useful, especially to beginners like me.
In addition to the information that Richard has provided, I think it would be helpful to have links somewhere to the Foxml for at least the basic Hydra models (e.g., commonMetadata, genericContent, genericParent, implicitSet, explicitSet, etc.). They are described in text on the "Hydra objects, content models (cModels) and disseminators" page and there are links to the Foxml for some of them at the bottom of that page ... but, when I first started looking at Hydra, I spent a good deal of time trying to see if I could find Foxml objects for all of these content models.
Another thing that I personally would find helpful as a beginner would be examples of what sites are putting into the various datastreams of the commonMetadata datastreams ... or even of example Foxml objects. I can imagine that this could quickly become unwieldy and may not be realistic but I do think it would be helpful for us as we are just starting to figure out to model our data in Fedora / Hydra.
--Jim
From: hydra-tech@googlegroups.com [mailto:hydra-tech@googlegroups.com] On Behalf Of Richard Green
Sent: Wednesday, July 25, 2012 12:15 PM
To: hydra-tech@googlegroups.com
Subject: RE: [hydra-tech] New to Hydra -- example practices for still images?
Is that what you envisage? What else does it need? Or is this not the sort of thing you envisaged? In which case?
The page is intended as a straw man...
R
From: hydra-tech@googlegroups.com<mailto:hydra-tech@googlegroups.com> [mailto:hydra-tech@googlegroups.com]<mailto:[mailto:hydra-tech@googlegroups .com]> On Behalf Of Tom Cramer
Sent: 25 July 2012 4:07 PM
To: hydra-tech@googlegroups.com<mailto:hydra-tech@googlegroups.com>
Cc: Tom Cramer
Subject: Re: [hydra-tech] New to Hydra -- example practices for still images?
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!
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?
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
...
I think something like this, plus examples from individual institutions of XML from particular datastreams where they vary from the text descriptions, would be very helpful. It might also be useful to put up the full set of objects (maybe in Github, not confluence?) as samples / fixture data.
> Is that what you envisage? What else does it need? Or is this not the sort of thing you envisaged? In which case?
> The page is intended as a straw man…
> R
> From: hydra-tech@googlegroups.com [mailto:hydra-tech@googlegroups.com] On Behalf Of Tom Cramer
> Sent: 25 July 2012 4:07 PM
> To: hydra-tech@googlegroups.com
> Cc: Tom Cramer
> Subject: Re: [hydra-tech] New to Hydra -- example practices for still images?
> 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 and 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> 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] On
> Behalf Of Mike Stroming
> Sent: Tuesday, July 24, 2012 9:49 AM
> To: 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> 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!
> From: 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
> 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] On
> Behalf Of Mike Stroming
> Sent: Monday, July 23, 2012 4:11 PM
> To: hydra-tech@googlegroups.com
> Subject: Re: [hydra-tech] New to Hydra -- example practices for still
> images?
> 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> 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
In fact, Tom, the cModels page does say that the Hydra cModels are all on github and gives the link. I'm not sure that we ever put them there though (oops!) and I can't obviously see them. We should get someone with commit rights to fix that asap. I recall that we took them out of the wiki page because they were not being maintained as modifications came along.
R
From: hydra-tech@googlegroups.com [mailto:hydra-tech@googlegroups.com] On Behalf Of Tom Cramer
Sent: 26 July 2012 12:58 AM
To: hydra-tech@googlegroups.com
Cc: Tom Cramer
Subject: Re: [hydra-tech] New to Hydra -- example practices for still images?
Richard,
I think something like this, plus examples from individual institutions of XML from particular datastreams where they vary from the text descriptions, would be very helpful. It might also be useful to put up the full set of objects (maybe in Github, not confluence?) as samples / fixture data.
Is that what you envisage? What else does it need? Or is this not the sort of thing you envisaged? In which case?
The page is intended as a straw man...
R
From: hydra-tech@googlegroups.com [mailto:hydra-tech@googlegroups.com] On Behalf Of Tom Cramer
Sent: 25 July 2012 4:07 PM
To: hydra-tech@googlegroups.com
Cc: Tom Cramer
Subject: Re: [hydra-tech] New to Hydra -- example practices for still images?
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> 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] On
Behalf Of Mike Stroming
Sent: Tuesday, July 24, 2012 9:49 AM
To: 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> 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
**************************************************
To view the terms under which this email is distributed, please go to http://www2.hull.ac.uk/legal/disclaimer.aspx **************************************************
> I definitely think something like this will be useful, especially to
> beginners like me.
> In addition to the information that Richard has provided, I think it
> would be helpful to have links somewhere to the Foxml for at least the
> basic Hydra models (e.g., commonMetadata, genericContent, genericParent,
> implicitSet, explicitSet, etc.). They are described in text on the
> Hydra objects, content models (cModels) and disseminators page and
> there are links to the Foxml for some of them at the bottom of that page
> but, when I first started looking at Hydra, I spent a good deal of
> time trying to see if I could find Foxml objects for all of these
> content models.
> Another thing that I personally would find helpful as a beginner would
> be examples of what sites are putting into the various datastreams of
> the commonMetadata datastreams or even of example Foxml objects. I
> can imagine that this could quickly become unwieldy and may not be
> realistic but I do think it would be helpful for us as we are just
> starting to figure out to model our data in Fedora / Hydra.
> --Jim
> *From:*hydra-tech@googlegroups.com [mailto:hydra-tech@googlegroups.com]
> *On Behalf Of *Richard Green
> *Sent:* Wednesday, July 25, 2012 12:15 PM
> *To:* hydra-tech@googlegroups.com
> *Subject:* RE: [hydra-tech] New to Hydra -- example practices for still
> images?
> 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
