Recto / Verso Solution Pack?

[Mark McFate]

I think I may have asked this question before, but perhaps not here?  I have searched this forum and found only one thread from 2012 thus far, and I think that discussion was all related to Islandora v6.

I'm looking for an Islandora solution, ideally a solution pack, that would allow me to display recto/verso object pairs without having to employ relatively cumbersome compound objects.  

It seems a growing number of our new collections include digital images in recto/verso (front and back) pairs, and it seems employing compound objects in this case is, manageable, but not optimal.

Anyone have an alternative solution to suggest, or a keen interest in such?  I'm not opposed to developing something if necessary, and if there is sufficient shared interest.  Should new development become necessary, can anyone suggest an open source viewer or package that is well-suited to rendering images in pairs, and a datastream structure to accommodate the same?

Another approach that I have considered would involve creating an image pair or 'montage', presumably a large image (TIFF) or basic image (JPG) depending on the type of digital images provided, before ingest into Islandora.  We would subsequently display the montage as the OBJ of a single Fedora object, and perhaps hold the individual images as 'archival-only' managed datastreams.  Has anyone developed a similar process they care to share, or are there issues with such an approach that I might have overlooked?

Thanks.

-Mark

[Mark Jordan]

Mark M,

At this week's iCamp one of my colleagues demoed a custom viewer for objects managed by the Simple XML Solution Pack that renders a TEI markup file and a set of page-level JPEGs in a left-right layout, as illustrated in the attached cropped screenshot (this is on our staging server and is not yet in production). His viewer module is also available, but it's very specific to the XML and other datastreams we are using for this collection.

Using this approach, you would use a small XML file to structure your left-right object, then attach two images to the object as datastreams, one for the left page and one for the right. Then you can attach a single XSLT file to the collection object that renders the XML into HTML for the end user. It's very flexible but solutions using it would tend to be bespoke.

As a side question, I'm curious to know why you consider compound objects to be relatively cumbersome. Are there any ways they could be made less cumbersome?

Mark J

---

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
Visit this group at https://groups.google.com/group/islandora.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/5fac80af-5364-43fb-9bea-c7db2da1d3ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark McFate]

Hello and thanks for the quick reply Mark.   I'll try to take a look at the Simple XML SP and the viewer as soon as I can.

I've done quite a bit of customization of compound object presentation so I'm a big fan, but in the past we have always required that all compounds include an islandora:compoundCModel parent object.  Consequently, a single recto/verso pair of images requires 3 Fedora objects (the compound parent and two children) with lots of redundant metadata.  (Some of my customization eliminates displaying duplicate metadata, but that data still has to be ingested and managed.)  Our catalogers are understandably not fond of creating 3 digital objects just to represent a single, physical object. 

I'm also planning to ingest my next recto/verso collection using a CSV importer that some colleagues and I have been writing.  Expressing parent/child relationships in CSV is also a bit of a pain, especially since this next set of objects do not carry any local identifiers...we would have to introduce some extra metadata just to make sure the parent/child relationships propagate into our repository.   

Thanks again and take care.

-Mark