I’ve been working to get JBoss Seam tied into Fedora, and along the way thought it would be wise to stop and document a core concept of this integration: the centrality of Fedora Disseminators in the the design of the Ohio Digital Resource Commons. Although there is nothing specific to JBoss Seam (a Java Enterprise Edition application framework) in these concepts, making an object “render itself” does make the Seam-based interface application easier to code and understand. A disseminator-centric architecture also allows us to put our code investment where it matters the most — in the repository framework — and exploit that investment in many places. So what does it mean to have a disseminator-centric architecture and have objects “render themselves”?

How It Works

• Browser: The user’s browser
• DRCseam: A JBoss Seam application that generates the user interface and performs much of the business logic. DRCseam, however, does not render the objects or their metadata into browser-consumable artifacts. Read on!
• Fedora: A basic Fedora digital object repository.
• Disseminator: A simple servlet that performs various transformations on object datastreams to render content usable by the browser.

With these components in play, here is the description of a sequence to render a page showing the metadata for a repository item:

1. request item page: The browser follows a link to an item detail page.
2. API-A ObjectProfile: The interface application asks the repository for the ‘Object Profile’ of the item…
3. return object profile: …which the repository returns. The interface application now knows basic details about the object: that it exists, the creation and updated timestamps, and so forth.
4. API-A DatastreamDissemination for fullDisplay: The interface application needs the object’s metadata display, so it asks the object to “render itself” by making a call to the Fedora repository for the object’s “FullDisplay” disseminator.
5. call getFullDisplay: The Fedora repository in turn calls the object’s disseminator with the Persistent Identifier (PID) of the object as a parameter.
6. API-A Datastream for metadata: Using the object PID, the disseminator calls back to the Fedora repository for the descriptive metadata datastream (the DC datastream, in this case)…
7. XML metadata: …which the Fedora repository returns.
8. transform metadata: The disseminator performs some transformation or derivation on the descriptive datastream to create an XHTML representation…
9. XHTML fragment: …which it returns to the Fedora software…
10. XHTML fragment: …which is returned to the interface application…
11. XHTML page: …which inserts it at the appropriate place in the XHTML page it has built and returns the XHTML page to the browser.

Step #4 is where we diverge from previous architectures. Instead of making the interface application transform the metadata into a human-readable format, the interface application calls the object’s disseminator to do the job.

The Heart of It All: The Disseminator

Rather than putting special case code in the interface application to render the description of the journal article one way and the thesis another way, that special case code is bound to the object in the form of a “disseminator”. The disseminator methods for the journal article and the thesis share the same name — getFullDisplay — but will return entirely different XHTML fragments — one for a journal article and one for a thesis. For both objects, though, the interface application will make a call to the object in the Fedora repository asking for the output of each getFullDisplay dissemination. In the case of a Dublin Core description, the dissemination output could look like this:

<table class="drc_dublinCore_table">
<tr class="drc_dublinCore_row drc_dublinCore_title">
<td class="drc_dublinCore_label drc_dublinCore_title">Title:</td>
<td class="drc_dublinCore_value drc_dublinCore_title">Jester Example</td>
</tr>
<tr class="drc_dublinCore_row drc_dublinCore_identifier">
<td class="drc_dublinCore_label drc_dublinCore_identifier">Identifier:</td>
<td class="drc_dublinCore_value drc_dublinCore_identifier">demo:exampleObject</td>
</tr>
</table>

You’ll note that there is a liberal application of CSS styles on all of the XHTML elements, allowing for the look of the dissemination to be further transformed in the browser via CSS stylesheets. A getFullDisplay dissemination for a journal article could look like this:

<table class="drc_ejc_table">
<tr class="drc_ejc_row drc_ejc_title">
<td class="drc_ejc_label drc_ejc_title">Article Title:</td>
<td class="drc_ejc_value drc_ejc_title">Taking Advantage of Fedora Disseminations</td>
</tr>
<tr class="drc_ejc_row drc_ejc_volume">
<td class="drc_ejc_label drc_ejc_volume">Volume:</td>
<td class="drc_ejc_value drc_ejc_volume">3</td>
</tr>
<tr class="drc_ejc_row drc_ejc_issue">
<td class="drc_ejc_label drc_ejc_issue">Issue:</td>
<td class="drc_ejc_value drc_ejc_issue">2</td>
</tr>
</table>

Looking at the Pieces

• http://drc-dev.ohiolink.edu:8080/BaseDisseminator/getFullDisplay/demo:exampleObject

Next, how this disseminator looks as accessed through the Fedora repository:

• http://drc-dev.ohiolink.edu:8080/fedora/get/demo:exampleObject/demo:bDefExample/getFullDisplay/

And finally, how this result looks through the Seam-based interface application. (A note about this application — only this URL works at the moment even though there are other links on the page. This is also the ‘trunk’ version of our interface code, so it is likely to change and/or break and/or work better at any time.)

• http://drc-dev.ohiolink.edu:8080/drc/item.seam?itemId=demo%3AexampleObject

Fedora Setup

Disseminator Behavior Definition (bDef)

Under the “Abstract Methods” pane, create new definitions for each of the disseminator methods.

Under the “Documentation” pane, put something in the first entry. Again, it doesn’t matter what is put in for these values, but they are required.

Select “Ingest” at the bottom of the window, and the demo:bDefExample bDef will be created. Alternatively, you could import the demo:bDefExample saved in the DRC source code repository (choose “original format” at the bottom of that page).

Disseminator Mechanism Definition (bMech)

In the “Service Profile” pane, put in values in the “General” area (it doesn’t matter what). In the Service Binding area, make sure the Message Protocol is HTTP GET, put in text/html, text/xml for Input MIME Types and put in text/html, text/xml, text/plain for Output MIME Types.

Under the Service Methods pane, put in http://localhost:8080/BaseDisseminator for the Base URL. (The disseminator is also loaded in the same servlet as the Fedora repository and the Seam interface application, and it is loaded at the “/BaseDisseminator” context path in the servlet.) Create Service Method Definitions that correspond to the Abstract Methods in the bDef.

Select “Properties” for each one of the Service Method Definitions in turn. “echo” is a unique disseminator method that simply echos back the context parameters of the disseminator request. This is useful for seeing exactly what the Fedora server is going to give to the disseminator.

With the exception of “echo” all of the other Service Method Definitions are the same. The Method Binding consists of the disseminator method followed by a slash and the PID placeholder followed by a question mark and ‘dc’ equals the DC placeholder. Since the Method Binding field has two placeholders, there are two entries in the Method Parameter Definitions area. The first is for PID — a “Default” parameter that is required and passed by value to the disseminator. The default value is the special value $PID, which the repository software will replace with the PID of the object as the disseminator is called. The second is for DC, a “Datastream” parameter that is required and passed to the disseminator by URL reference. The disseminator doesn’t actually use this reference to a datastream, but it is a requirement that all bMechs pass a datastream of one sort or another to the disseminator.

If you have followed all of the steps so far, under the “Datastream Input” pane there will be one entry for DC in the table. The only thing that needs to be done here is adding “text/xml” in the MIMEType column.

Under the “Documentation” pane, put something in the first entry. Again, it doesn’t matter what is put in for these values, but they are required.

Select “Ingest” at the bottom of the window, and the demo:bMechExample bMech will be created. Alternatively, you could import the demo:bMechExample saved in the DRC source code repository (choose “original format” at the bottom of that page).

Sample Object

Select “Save Changes” at the bottom. The completed disseminator looks like this:

There is a sample object in the DRC source code repository that has the disseminator already defined.

Notes

Future Directions

On a related front, this style of implementation would be greatly enhanced by the work of the Fedora Content Model Dissemination Architecture (CMDA). Because disseminators must be bound to specific objects rather than classes of objects, management of the variety of bMechs in a scenario such as this will likely become difficult very soon. I’m heartened by the fact that the CMDA work is going on and will cut our management complexity dramatically when it becomes available.

Acknowlegements

[Update 20070426T1147 : Fixed the sample object URL. Thanks, Jodi.]

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/BaseDisseminator/trunk/resources/foxml/demo_exampleObject.xml?rev=774 on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/BaseDisseminator/trunk/resources/foxml/demo_bMechExample.xml?rev=774 on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/BaseDisseminator/trunk/resources/foxml/demo_bDefExample.xml?rev=774 on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu:8080/drc/item.seam?itemId=demo%3AexampleObject on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu:8080/fedora/get/demo:exampleObject/demo:bDefExample/getFullDisplay/ on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu:8080/BaseDisseminator/getFullDisplay/demo:exampleObject on January 13th, 2011.

The text was modified to update a link from http://rama.grainger.uiuc.edu/assetActions/ to https://wiki.dlib.indiana.edu/display/DLFAquifer/Asset+Action+Project on January 19th, 2011.

Calling all accessibility technology experts! What follows is a line of thinking about using characteristics of the FEDORA digital object repository to enable access to content through non-graphical interfaces. Thanks to Linda Newman from the University of Cincinnati and others on the Friday morning DRC Developers conference call for triggering this line of thinking.

In a recent post defining universal disseminators for every object in our repository (if the last dozen words didn’t make sense, please read the linked article and come back), I hinted at having an auditory derivative of each object, at least at the preview level. During today’s conference call, Linda asked if such a disseminator could be used to offer different access points for non-GUI users. Well, why not? Let’s look back at the “presentation” part of the disseminator label:

A presentation can be one of:

• “preview” – a small/short version of the datastream returned in the datastream’s original format
• “screen” – a roughly GUI-screen-sized version of the datastream returned in the datastream’s original format
• “thumb” – a small, static image derivative of the datastream
• “audio” – an auditory derivative of the datastream
• “description” – a Dublin Core description of the item marked up in an HTML table
• “record” – HTML markup of Thumb plus Description (suitable, for instance, as a representation of the object in a browse list)

Specifically, we talked about the audio presentation for non-audio objects (digital objects where audio is not the fundamental focus of the object).

• There could be a descriptive audio track, similar in concept to video description, that would be returned to the calling application. Perhaps, for instance, the audio of a commentary found on the handheld audio tour devices in art museums.
• In the absence of other audio description, the disseminator could run a text-to-speech algorithm against the title, creator, and description fields and return that to the calling application.

This brings to mind another transformation we could apply to give a preview of an object. (No, I haven’t moved into the odor or tactile senses — yet.) Would it be useful to have a disseminator return a text summary and/or metadata aggregation of an object on demand?

And, of course, the critical question: is it the job of a repository to build in access methods like this to be used by applications designed with alternate accessibility in mind? Should it be up to the application to create the derivatives necessary? I took a brief look at Section 508 requirements, but couldn’t find any real guidance about serving up accessible forms of content. (There is a great deal of information about how to create accessible web pages, but very little I could find about making assets in those pages accessible.) But I only know enough about this area to have it on my radar…and certainly not enough to formulate any answers.

The original goal of defining these universal disseminators was to assure a base level of functionality for every object in the system — a contract, if you will, between the repository and any consuming application that it could ask an object to return itself or a derivative of itself in all of these forms. What do you think? Should that contract be consciously extended to include universal accessibility?

Another reason to consider the FEDORA digital object repository system, if having the ability to put all of your content in one place and reducing the complexity of digital preservation aren’t enough, is the capability to create and define behaviors that the content can perform. In the FEDORA world, these behaviors are called disseminators.

By way of example — say you have a digital object that is an image that you want to display to users. Furthermore, you want to create at the time of the user’s request a smaller “thumbnail” version on search results lists and so forth. (Let’s set aside for a moment that the system could create thumbnail derivatives in batch and simply deliver that to the user. Someday I’ll propose that dynamic derivatives from a JPEG2000 master are a better way to go, but not now. Stick with me…it’ll be worth it.) From a system architecture point of view, the resize operation can happen in at least two places: as a function of the content repository or as a function of the interface application. In this simple example, one might argue that the best place is in the interface application.

Now let’s say that your content repository has not only still images but moving image files. Uh, oh. That means the application now has to be smart enough to know whether a particular search results hit is a still image or a moving image datastream. And the application is going to have to know how to transform a large image to a thumbnail and know how to extract a key frame from a sequence of moving images. And if you have more than one interface to the object repository (say, one that presents a digital library interface and one that integrates objects into your learning environment) then you’re going to have to replicate that still image and moving image capability in more than one application.

So instead, what if we put the “smarts” of the object into the repository and create some well-defined expectations for what every object in the repository has to do. That “smarts” in the repository are the Disseminators and the well-defined expectations is the Content Model. The “dumb” application (relatively speaking) gets a list of record identifiers that are the results of a search and asks the repository to give it a thumbnail images for each one. The first record is a still image, so the repository resizes the image and delivers the result to the application. The second record is a moving image file, so the repository extracts one frame, resizes it, and delivers it back to the application. The third record is that of a book — want to guess what happens? Perhaps the repository returns a thumbnail-sized image of the book jacket? Or maybe an image rendering of the title page? Okay, now so the fourth record is of a dataset — how do we get a thumbnail of a dataset? Maybe a reduced size of visualization of the image? What if the fifth was of a website? Have you seen “thumbnail” sizes of websites, such as through Alexa or Thumbshots.org?

This is the key point: for each record, the application simply asked the repository to deliver a thumbnail of the object. And the repository, regardless of media type, delivered one.

Okay, enough background. Also keep in mind that OhioLINK’s Fedora repository vision doesn’t expect to have one front end; rather we anticipate getting to the repository data from a number of genre-, topic-, or technology-specific interfaces. In doing so, I think a lot of the intelligence about how to handle media types needs to go into the disseminators. So I’m thinking about how an object can present itself in generic ways to a wide variety of interfaces.

So in my current line of thinking, the name of a disseminator in the repository has three parts:

• action
• presentation
• optional sizing parameters

An action can be one of:

• “get” – raw stream of bits from the datastream
• “view” – HTML-wrapped version of the stream of bits plus activities that can be applied to the datastream intended for access by a GUI or to be transformed via XSLT

I tried to combine the GUI and XSLT actions into “view” on the theory
that the HTML wrapper would have sufficient CSS “id” and “class” values
to make it possible to style it with CSS or transform it with XSLT.
This may not be a practical theory once we get to implementation.

A presentation can be one of:

• “preview” – a small/short version of the datastream returned in the datastream’s original format
• “screen” – a roughly GUI-screen-sized version of the datastream returned in the datastream’s original format
• “thumb” – a small, static image derivative of the datastream
• “audio” – an auditory derivative of the datastream
• “description” – a Dublin Core description of the item marked up in an HTML table
• “record” – HTML markup of Thumb plus Description (suitable, for instance, as a representation of the object in a browse list)

The final piece of the name is “Sized” which can be used to pass parameters that override the dimensions of the “preview” and “thumb” presentations.

So these would get put together like this (with examples based on still images):

• “getPreview” – return an x-by-y derivative of the datastream
• “getThumb” – in the case of still images, same as “getPreview”
• “viewThumb” – the same derivative as “getThumb” wrapped in an HTML div such as:

  <div class="viewThumb" id="viewThumb[PID][DS]">  <div class="getThumb" id="getThumb[PID][DS]">    <img class="getThumbImg" id="getThumb[PID][DS]Img" alt="Thumbnail of [DS]" src="..." />  </div>  <div class="getThumbOptions" id="getThumbOptions[PID][DS]">    <span class="getThumbOptionScreen" id="getThumbOptionScreen[PID][DS]">      <a href="[URL to getScreen]">View Screen-sized</a>    </span>    <span class="getThumbOptionDescription"id="getThumbOptionDescription[PID][DS]">      <a href="[URL to getDescription">View Description</a>    </span>    ....  </div></div>

  (where [PID] is the Fedora PID and [DS] is the datastream label)

For non-static images, it gets a little more interesting because:

• "getPreview" of a video would return a short video segment defined as the 'preview' of the larger video where as "getThumb" of that same video datastream would return just a single frame from the video.
• "getPreview" of a journal article could return a block of text that is the abstract of the article while "getThumb" of that same journal article could return an image rendering of the first page of the article
• "getScreen" of a journal article could return an HTML fragment of the article itself while "getAudio" might return a prerecorded or computer-synthesized rendition of the article

That's the basic plan, open for comments before we get too far with the coding part of the project. Thoughts?

The text was modified to remove a link to http://pages.alexa.com/exec/faqsidos/help/index.html?index=126.

The text was modified to update a link from http://www.thumbshots.org/freethumbshots.pxf to http://www.thumbshots.org/.