Thanks, everyone, and keep them coming.
There can be a lot of different components to a single item, and we're
looking at ways of fitting it all together in a user friendly and elegant
way. I'm hoping that when a person clicks on something after searching or
browsing, they don't get a confusing/excessive dump of information that
only makes sense for librarians, but that the users are still able to get
all the info they need about the item.
On Thu, Jan 29, 2015 at 7:56 AM, Esmé Cowles <[log in to unmask]>
> We developed our own RDF ontology to model our data, based roughly on
> MODS and MADS, and we store our files and metadata in a custom
> repository which implements the core of the Fedora 3 REST API. We
> developed a Hydra head for searching, display, etc.
> There is currently an effort underway in the Hydra community called
> Hydra::Works to build a common data model that can handle complex
> objects. We plan to implement this model soon using Fedora 4, a Hydra head
> based on Sufia, and a data model that closely follows DPLA's v4 draft.
> If you are coming to C4L in Portland, I will be there there (as will be
> many other Hydra and Fedora 4 people), and there are also some sessions
> planned for Thursday and Friday after the conference proper ends.
> 1. https://github.com/ucsdlib/dams/tree/master/ontology
> 2. https://github.com/ucsdlib/damsrepo
> 3. https://github.com/ucsdlib/damspas
> 4. https://wiki.duraspace.org/display/hydra/Hydra::Works+Shared+Modeling
> 5. https://github.com/projecthydra/sufia
> > On 01/29/15, at 10:25 AM, Sarah Park <[log in to unmask]> wrote:
> > Esme,
> > Your examples are similar to what I am hoping for. Can you explain a
> > bit more what system you used for backend to store image URLs and Object
> > descriptions?
> > Sarah
> > -----Original Message-----
> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> > Cowles
> > Sent: Wednesday, January 28, 2015 4:14 PM
> > To: [log in to unmask]
> > Subject: Re: [CODE4LIB] examples of displays for compound objects and
> > metadata
> > Laura-
> > At UCSD, we have complex objects which range from a flat list of files
> > page images):
> > http://library.ucsd.edu/dc/object/bb59054559
> > all the way up to pretty involved hierarchy modeling a filesystem:
> > http://library.ucsd.edu/dc/object/bb9796611k
> > Many of these have a hierarchy with files attached, but not much metadata
> > for the individual parts. But there are also some objects with more
> > metadata for each part:
> > http://library.ucsd.edu/dc/object/bb0479301d?
> > -Esme
> >> On 01/28/15, at 4:43 PM, Laura Buchholz <[log in to unmask]>
> >> We're migrating from CONTENTdm and trying to figure out how to display
> >> compound objects (or the things formerly known as compound objects)
> >> and metadata for the end user. Can anyone point me to really good
> >> examples of displaying items like this, especially where the user can
> >> see metadata for parts of the whole? I'm looking more for examples of
> >> the layout of all the different components on the page (or pages)
> >> rather than specific image viewers. Our new system is homegrown, so we
> >> have a lot of flexibility in deciding where things go.
> >> We essentially have:
> >> -the physical item (multiple files per item of images of text, plain
> >> text, pdf) -metadata about the item -possibly metadata about a part of
> >> the item (think title/author/subjects for a newspaper article within
> >> the whole newspaper issue), of which the titles might be used for
> >> navigation through the whole item.
> >> I think Hathi Trust has a good example of all these components coming
> >> together (except viewing non-title metadata for parts), and I'm
> >> curious if there are others. Or do most places just skip
> >> creating/displaying any kind of metadata for the parts of the whole?
> >> Thanks for any help!
> >> --
> >> Laura Buchholz
> >> Digital Assets Specialist
> >> Reed College
> >> 503-517-7629
> >> [log in to unmask]
Digital Assets Specialist
[log in to unmask]