We want the default disseminator to be as simple as possible, so it is easy to make objects in the repository implement it. This page outlines the driving factors that force us to include behaviors in the default design.
The purpose of default disseminator is to support functionality across multiple types of objects, across multiple collections, and even across repositories. The following cases illustrate some of the possible uses our objects and collections may need to support. The use cases can serve as a guide for decisions we need to make regarding the default disseminator.
Case 1: Use of items by an external service
Anne is writing a presentation on the evolution of photography. She wants to build a concept map in VUE that includes photos from the Hohenberger and Cushman collections.
Alan is creating a presentation on music in the Midwest. He wants to use the collector tool to combine photos from the Cushman collection with sheet music and recordings from the Hoagy Carmichael collection. He would like to include a short description of each item in the presentation.
Case2 : Federated searches
Boyd searches "chicago" in the IU digital library search system, retriving results from multiple collections, including photos from the Cushman collection and sheet music from the DeVincent collection. The search results display a thumbnail for each item accompanied by some minimal metadata. The metadata includes the name of the source collection. Clicking on a thumbnail brings up the item in its default collection.
Brianna searches OAIster for "horseshoe players", and sees a result from the Hohenberger collection. She clicks on the PURL to display the item.
Case 3: Cataloging
Carlos wants to verify that our usage of the subject heading "Bodies of water" is consistent across collections. After performing a federated search for this heading, he notices an incorrectly cataloged item. He copies the ID number into the cataloging tool, and opens the relevant record to make the change.
Case 4: Preservation integrity checking
An automated script runs to check the status of media files. It selects a random item from Fedora, collects all of the lowest-level objects that make it up, gets a list of files and checksums from the metadata, and performs the needed checks.
Case 5: Use in another collection
The Aquifer project wants to include selected items from the Cushman collection. They ingest the OAI records for these items. They send PURLs of the requested items to the DLP, and we send back a set of Dissemination Information Packages.
Requirements for the Default Disseminator (DD)
- The DD must have access to metadata (DC, MODS, or full METS). [all cases]
- DD must contain getAssetDefinition so external tools can determine which method to call to get thumbnails. [case 1]
- DD should have some sort of image representation for each item, because most of our collections have a visual aspect. [case 2]
- DD must have a way to render the "standard" (collection-specific) view of the item, likely called getFullView (or viewFullView?). [case 2]
- There must be an easy way to identify children of a given object. This could be in the default disseminator, or stored in the metadata. [case 4]
- There should be a way to tell the format of the object, so systems that don't want to display the "standard" preview images can do something else. This format should be in the metadata. [case 1, case 2]
- There should be a way to generate a DIP. However, it's unlikely that we would want this in the default disseminator, as the implementation will definitely depend on the type of the object, but may also be collection-specific. [case 5]
Other random thoughts
It seems useful to separate the default behaviors into "default" and "metadata" disseminators, because this makes implementation easier. For example, we could have image collections with varying metadata implementations, which need different metadata mechanisms, but a single mechanism will suffice for the rest of the default behaviors. Conversely, we may have collections with differning types of media that share a common metadata format.
Due to the peculiarities of Fedora's implementation, it is generally easier to change the implementation of the getMetadata behavior to accept more arguments than to create and attach new behaviors. Extending this logic to all of the behaviors, it is useful to keep all behaviors as high-level as possible and leave most of the work to the implementation. Of course, we don't want to carry this to the extreme, where every object simply impelmented a single behavior, because that behavior would be incredibly complex and inefficient.
Most federated search systems (OAIster, Google, etc.) display metadata in their results list, then go to a colletion-specific (or site-specific) page upon a link click. Anyone who wishes to build a service like that from our repository can use getMetadata(dc) along with getFullView. By defining getPreview as returning an image, we can more easily implement systems that give a thumbnail along with the metadata (or thumbnail only).
- Do all of these requirements make sense when we're dealing with non-primary objects? That is, should we only apply the DD at the collection level and the item level, ignoring any Fedora objects at other structural levels (portions of an item or groupings of items)? It does seem useful for some of this functionality. For example, it should be possible to search for a specific page object, and then ask for this object's getFullView (which would invoke the item's page turner and turn to the correct page).