Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The previous example demonstrated how to aggregate imported content into a Fedora digital object. There are many reasons why importing content into a repository might not be appropriate such as rights restrictions or the dynamic nature of the content. To accommodate these restrictions, digital objects in Fedora may contain datastreams Datastreams that reference externally managed content, and in fact may mix local and distributed data sources.

This section describes how to do this where the motivating example is the creation of a hypothetical learning object in an educational digital library, such as the NSDL}. The digital object created in this example combines three frog images from the NSDL collection and some locally-managed text.

To get started follow the same procedure as illustrated in Figure 3, this time entering Example 2 as the Label and demo:200 as the custom PID. As in Example 1, select the Datastreams tab and then enter the information as shown in Figure 9.
Image Removed
Figure 9 - Adding a datastream with type Redirect

Section
Wiki Markup

{center}
!worddav1972a2440b8bde2508fe39ee231c0562.png|height=488,width=576!
*Figure 9 -- Adding a Datastream with Type Redirect* 
{center}

You will enter the datastream Datastream identifier of IMAGE1, a label for this datastreamDatastream, and then information about the content. The content is of MIME type image/gif. You should select the Control Group of Redirect, and then enter a URL that specifies the Location of the image file, specifically:

http://www.frogsonice.com/froggy/images/toads.gifImage Removed

A few notes on the contents of this dialog:

  • Pertaining to the selection of a Control Group, you have two choices if you want the datastream to point to content that resides outside the Fedora repository (External Referenced Content and Redirect). In this case we chose Redirect . To review, the meaning of the two options for mapping to external content are:
    o External Referenced Content is useful when you want Fedora to mediate access to the datastream, for example when you want to hide the source URL from the user. Fedora mediates access to these datastreams, meaning that the content is streamed through the Fedora server.
    o Redirect. makes use of a simple HTTP redirect to provide the content. This is useful when there are relative hyperlinks in the external content, but reveals the source URL to the user.

...

  • Make sure that the MIME Type choice matches that of the content offered by the external source, in this case image/gif.

In the same manner, you can now proceed to add the two other datastreams with locations: http://www.werc.usgs.gov/fieldguide/images/hycafr.jpg and http://www.aquariumofpacific.org/images/olc/treefrog600.jpg

You should respectively identify these datastreams as IMAGE2 and IMAGE3. (Note that if these sample URLs are no longer active, you can enter other URLs pointing to jpeg images to complete this tutorial exercise.)

Finally, add another datastream labeled MyText (containing some descriptive text about the images), with MIME Type text/html. Assign this datastream a Control Group of Managed Content indicating that the content will be imported and stored permanently in the Fedora repository. Import the content from the following location:

FEDORA_HOME/userdocs/tutorials/2/example2/mytext.html.

The resulting datastream window should now look like that shown in Figure 10. Image Removed
Figure 10 - Example 2 datastream display

Section
Wiki Markup

{center}
!worddav72ebf8c8b1101637a55c32bf7397d91f.png|height=488,width=576!
*Figure 10 -- Example 2 Datastream Display* 
{center}

You're done! Figure 11 illustrates the role of the redirected datastream Datastream at the time of digital object access via the Fedora REST-based interface (API-A-LITE). You can see this by going to the digital object profile page at: http://localhost:8080/fedora/get/demo:200Image Removed

You can access the datastreams Datastreams for this digital object by viewing the item linked to from the object profile page. Then, select the link for one of the redirected datastreamsDatastreams. Fedora will redirect your browser to the location of the datastream content, without streaming the content through the Fedora repository server.
Image Removed
Figure 11 - Example digital object and redirected datastream

...

Section
Wiki Markup

{center}
!worddav908cefe719739375d93c8585ac14aa7e.png|height=289,width=545! 
*Figure 11 -- Example Digital Object and Redirected Datastream* 
{center}

Using Fedora to Produce Dynamic Content

The examples described so far demonstrate the basic content aggregation features of Fedora. As mentioned already, the power of Fedora lies in its ability to associate the data in a digital object with web services to produce dynamic disseminations.Some examples of this capability are as follows:

  1. Rather than packaging multiple formats of a document as in Example 1, it is possible to have a digital object with one datastream Datastream in a source format (e.g. TeX) and then associate a service with the digital object to transform the source format into multiple output formats (e.g. pdf and html). An obvious advantage of this is that any changes to the source format propagate out to the derived formats. Furthermore, less content is stored and/or duplicated in the repository.

...

  • Rather than packing multiple metadata XML-based metadata formats in a digital object, it is possible to package a single base metadata format in a digital object (for example, fully qualified Dublin Core) and use that base format as the basis of metadata crosswalks. To do this, one could associate an XSLT engine (e.g. saxon) service with the digital object that processes the base format with a transform XSL document (packaged as a

...

  • Datastream in another digital object) to derive one or more additional formats.
    In both cases, static and dynamic, disseminations are available via REST or SOAP requests from clients to the Fedora Access service (API-A and API-A-LITE). The nature of the disseminated content

...

  • the format of the underlying data, where it is located, and whether it is static or dynamically generated

...

  • is invisible from the client perspective. As a result, a repository manager can significantly alter the nature of a digital object and the web services that it uses while maintaining the same interface vis-à-vis the client. Correspondingly, two digital objects with entirely different structure can appear the "same" from the perspective of consuming clients.

The remainder of this section presents a series of examples demonstrating how to create digital objects that exploit web services. The initial examples make use of services available in the Fedora software release (they run as "local services" within the Fedora server container). Later examples demonstrate how to construct your own custom objects with external web services. Before proceeding with the examples, this introduction summarizes the concepts and defines the terms used in the examples. Don't worry if the concepts are not entirely clear at first. You should read them now and then refer back to them as you work through the examples.

Figure 12 shows an abstract view of the different components of the Fedora repository architecture that are key to how Fedora produces "disseminations" of digital object content. .
Image Removed
Figure 12 - Abstract View: Key Fedora Components for Producing Disseminations of Content

Section
Wiki Markup

{center}
!worddavd2a3455b17ad8f4c77993ff48496a668.png|height=197,width=206! 
*Figure 12 -- Abstract View: Key Fedora Components for Producing Disseminations of Content*  
{center}

These layers are:

  1. . Client: Clients make requests for content disseminations through the Fedora Access service APIs (i.e., API-A-LITE and API-A). These interfaces include operations for discovering and accessing all disseminations that are available for a particular digital object. A digital object can have both static and dynamic disseminations, which are described below.
  2. . Fedora APIs: The Fedora repository service is exposed via a uniform set of APIs. Fedora's API-A and API-A-Lite provide operations (methods) for accessing digital object content. While the default mode of accessing a digital object directly delivers the datastreams (i.e., repository returns a bitstream for a datastream un-transformed), the CMA (Content Model Architecture) enables defining any number of custom services for accessing datastream content. These custom services are produced when the Fedora repository service calls another Web service to transform datastream content. Such transformations can be thought of "virtual" views of digital object content, since these views are created dynamically at runtime.
  3. . Web Services: These are Web-accessible programs that are invoked by HTTP to produce disseminations of digital object content. Note that the Fedora repository itself is a Web service to access the default services of digital objects. Also, Fedora can interact with other Web services to product custom access services that transform digital object content on-the-fly. In this tutorial we will describe how Fedora interacts with simple REST-based services to product such custom services. Custom services are produced when the Fedora repository service itself makes outbound service calls to other Web services using simple REST-based requests. We will not discuss Fedora interacting with SOAP-based web services here.
  4. Storage: Digital objects are stored in the Fedora repository service. Datastreams are constituent parts of digital objects - essentially the content streams. Fedora interacts with low-level storage to access digital objects to fulfull fulfill client requests for access to content. Datastreams capture the raw content. As shown in the previous examples, datastreams Datastreams can be directly disseminated via the Fedora Access service. Also, datastreams can serve as input to other custom services that are produced on-the-fly when the Fedora repository service calls upon another Web service at runtime run time (using a raw datastream Datastream as input).

The process of creating digital objects with dynamic content disseminations involves creating linkages between these layers. During this process you will create and employ the following:

  1. ervicer Service Definition (or SDef): A digital object that is a template for client-side services, defining a set of abstract operations (methods) and their client-side arguments. Association of a SDef with a digital object augments the basic behavior of the object with the operations defined in the SDef template. A SDef may be associated with more than one digital object, thereby augmenting all of them with the same operations.
  2. ervice Service Deployment (or SDep): A digital object that registers within Fedora the capability of web service(s) to perform the operations defined by a specific SDef. This registration includes defining service binding metadata encoded in the Web Service Description Language (WSDL) and also a data profile of the SDep. The data profile defines the types of inputs that are considered compatible with the service. In particular it declares the MIME types that are needed by the respective web service to perform its task. Multiple SDeps may be registered for an individual SDef, thereby exposing a generic client-side interface (defined by the SDef) over multiple data and web service foundations (defined by the SDep).
  3. ontent Content Model (or CModel): A digital object that is used to store information which will allow Fedora to determine whether a data object, which asserts conformance to a content model, is valid. The Content Model is also important for performing disseminations in Fedora, based on the Content Model Architecture. A Data Object will indicate which Content model they represent via a special RELS-EXT relationship. The Content Model will in turn indicate which SDef(s) it is associated with (also with a special RELS-EXT relationship).

These three kinds of special Fedora objects are stored in Fedora repositories. The set of all SDefs represents a "registry" of all the kinds of abstract services supported by the Fedora repository. The set of all SDeps represents a "registry" of all the concrete service bindings for the abstract service definitions supported by the Fedora repository. The set of all CModels represent a "registry" of the different user-defined types of data objects that exist in that Fedora repository.

At the end of the day, digital objects make references to SDefs, SDeps and CModels as the way of providing extended access points for digital objects (i.e., dynamic content disseminations.) This is done by adding special relationships between the objects that are stored in the RELS-EXT datastreams of those objects.
Figure 13 indicates the relationships that exist between the four object types. Data objects assert that they conform to a particular Content Model using the hasModel relationship. Content Model objects assert they provide the services included in an SDef using the hasService relationship. Service Deployment objects assert the services for which they provide binding information by using the isDeploymentOf relationship, as well as asserting the Content Models for which they provide service bindings using the isContractorOf relationship.

Figure 13 - Fundamental CMA Relationships


Figure 14 illustrates the interactions among Fedora and Web services in response to an access request. As indicated, a client makes a request to the Fedora API (with a URL in this case.) The Fedora repository service then determines the content model that is associated with the digital object for which the request is being made. Once it knows the content model, the Fedora repository can discover what SDefs and SDeps are in play for this digital object. Once all of this information is gathered, the Fedora repository can construct a request to the appropriate web service to transform the datastreams of the target digital object (demo:2). The Fedora repository service invokes a REST-based request to the web service via HTTP, sending along arguments to enable the web service to obtain the required datastream inputs to fulfill the request. The Fedora repository mediates all invocations with the external web service. When it receives a response from the web service it streams it back to the original calling client. In this case, the response is a transformation based on the raw material of Datastream1 and Datastream2 in the digital object.


Figure 14 - Dynamic dissemination access

...