...

Figure 1 – Fedora Repository as Mediator for Services and Content
Figure 2 – Fedora Administrator Login Screen
Figure 3 – New Object Dialog
Figure 4 – Configuring an Object
Figure 5 – Datastream Display
Figure 6 – Adding a New Managed Content Datastream
Figure 7 – Complete Datastreams for Example 1
Figure 8 – Example 1 Fedora Digital Object and Datastreams
Figure 9 – Adding a Datastream with Type Redirect
Figure 10 – Example 2 Datastream Display
Figure 11 – Example Fedora Digital Object and Redirected Datastream
Figure 12 – Abstract View: Key Fedora Components for Producing Disseminations of Content
Figure 13 – Relationships Between Data objects and CModel/SDef/SDep Objects for CMA
Figure 14 – Dynamic Dissemination Access
Figure 15 – Example 3 Linking a Fedora Digital Object to a Content Model
Figure 16 – Example 3 Dissemination via CMA
Figure 17 – Dissemination with Redirect Datastream

What is This Document and Who Should Read It?

...

1. It supports the creation and management of digital content objects (from this point on called a Fedora Digital Objects or FDO) that can aggregate data from multiple sources. For example, an a FDO might be a set of TIFF images that are the individual page images of a scanned document. The data sources may be either locally managed within the Fedora software or sourced from another URL accessible network server. The data sources may be content or metadata. You may think of these FDOs as advanced digital documents, especially in light of the feature described next.
   
   
2. It supports the association of web services with the FDOs. These services typically consume the data packaged within the FDOs to produce dynamic disseminations from them. For example, the FDO described above with multiple TIFF page images may be associated with a service that OCRs the images that are components of the FDO and disseminates an HTML version of the pages. The services may be either local to the machine of the respective Fedora server or sourced from another network accessible server that is addressable via a URL. In this manner, Fedora acts as a mediation layer that coordinates local and distributed data and web services within a uniform framework. This is illustrated in Figure 1.
   
   
3. It provides uniform access web-based interfaces to these FDOs, through REST requests and more powerful SOAP-based methods. These interfaces consist of a set of built-in methods to access characteristics common to all FDOs such as key metadata and internal structure. These include a method to introspect on an object to reveal the set of methods that constitute the extended behavior of that object. For example, a client could use these built-in methods to "learn" about the capability of the FDO described above to dynamically disseminate an HTML page from a set of TIFF images.
   The benefits of these are two-fold:
   
   
   1. Clients accessing Fedora Digital Objects can rely on uniform access regardless of the nature of the object.
      
      
   2. The disseminations available from an object are independent of the internal structure of the object. For example, the client interface of the example above in which HTML is disseminated from a set of source TIFF pages could remain constant regardless of whether the underlying object contained TIFF images, JPEG, PDF, or even simple static HTML. This gives the content developer great freedom to modify a repository's internals without disrupting the client and user views of the content.
      
      
4. It presents a uniform and powerful REST and SOAP-based management interface. All internal operations of the repository such as object creation and management are available through these APIs, providing the hooks for integrating Fedora into a variety of environments. These makes Fedora useful as the foundation for advanced content management applications.
   
   
5. It includes a comprehensive versioning framework that tracks the evolution of objects and provides access to earlier versions.
   
   
6. It includes a basic relationship framework for representing the links among FDOs.
   
   
7. It supports ingest and export of FDOs in a variety of XML formats. This enables interchange between Fedora and other XML-based applications and facilitates archiving tasks.

...

{center}
!worddavac540d3a8081463391d55fd33c857e39.png|height=293,width=520! 
*Figure 8 -- Example 1 _Fedora Digital Object_ and _Datastreams_*
{center}

Example 2: Creating a Surrogate for Distributed Content

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, FDOs may contain Datastreams that reference externally managed content, and in fact may mix local and distributed data sources.

...

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 FDO. A FDO 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 FDO content. While the default mode of accessing a FDO delivers the Datastreams (i.e., repository returns the bitstream represented by the 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 FDO 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 FDO content. Note that the Fedora repository itself is a Web service to access the default services of FDOs. Also, Fedora can interact with other Web services to product custom access services that transform FDO 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: FDOs objects are stored by the Fedora repository service. Datastreams are constituent parts of digital objects FDOs – essentially metadata about the bytestreams. Fedora interacts with low-level storage to access FDOs to fulfill client requests for access to content. Datastreams capture the raw content. As shown in the previous examples, 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 run time (using a raw Datastream as input).

...

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 FDO 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 FDO. 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 FDO (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 FDO.

{center}
!worddav16a77ff05b7cb41adf9bea82f2a3933d.png|height=360,width=565! 
*Figure 14 -- Dynamic Dissemination Access*
{center}

...

The web service used in the example performs an XSL transform using the well-known Saxon XSLT processor. This service requires two inputs, an XML source document and a XSL transform document. In this example, both of these XML documents are stored as managed content in a Fedora digital objectDigital Object. The XML source is data for a poem with tags for the structural elements of the poem (stanzas and lines). The XSL transform produces a HTML output of the poem that can be viewed in a browser. This example is borrowed from the web available source for Michael Kay's excellent XSLT book.

...

{center}
!worddav8014f2db32df4f6abbd0857010facd8c.png|height=350,width=350!
{center}

This will create the digital object FDO with PID demo:ex3SDef in your repository. This SDef defines one method getContent. This generic method name is intentional – one could imagine this one SDef being used as the basis for several SDeps, each of which produces "content" via a unique transformation of an underlying source. This is one of the advantages of Fedora – providing a common interface despite multiple underlying representations.

Follow the same procedure to ingest a sample SDep object into the repository. Select the file FEDORA_HOME/userdocs/tutorials/2/example3/SDep.xml. This will create the digital object FDO with the PID demo:ex3SDep. This SDep represents a concrete implementation of the abstract service operations defined in the SDef demo:ex3SDef. The SDep object contains metadata that specifies the following:

...

Next follow the same procedure to ingest a sample CModel object into the repository. Select the file FEDORA_HOME/userdocs/tutorials/2/example3/CModel.xml. This will create the digital object FDO with the PID demo:ex3CModel. This CModel describes the Datastreams that should be present in data objects that conform to this content model, it also has a RELS-EXT hasService relationship link to the digital object FDO demo:ex3SDef ingested previously.

Creating a Fedora Digital Object with Appropriate Datastreams

Now you need to create the new digital object FDO based on this SDef, SDep and CModel. To get started follow the same procedure as illustrated in Figure 3, this time entering demo:300 as the Datastream ID and Example 3 as the Label.

...

• Add a Datastream with:
  • ID – source
  • Control Group – Managed Content
  • Mime type – text/xml
  • Label – Poem XML Source
  • Import location: FEDORA_HOME/userdocs/tutorials/2/example3/poem.xml
• Add a Datastream with:
  • ID – xsl
  • Control Group – Managed Content
  • Mime type – text/xml
  • Label - Poem XSL Transform
  • Import location: FEDORA_HOME/userdocs/tutorials/2/example3/poem.xsl

Linking the Fedora Digital Object to the Content Model

In Fedora Administrator, select the Datastreams tab from the digital object FDO window, and then select the New RELS-EXT... tab. The resulting dialog will now allow you to create the necessary RELS-EXT relationship to allow dynamic dissemination to work. Follow these steps:

...

{center}
!worddav312dbd28306cd3f7f643185f2cb1dc19.png|height=488,width=576!
*Figure 15 -- Example 3 Linking a _Fedora Digital Object_ to a _Content Model_* 
{center}

You're done! Figure 16 illustrates the role of this digital object FDO and disseminator dissemination service in response to a client request. You can go to the digital object FDO header page at http://localhost:8080/fedora/get/demo:300 ^{Image Removed} and select the View Dissemination Index link. Your newly added dynamic dissemination should now appear, alongside the primitive behaviors for the object. To see the results of this dynamic dissemination, you can either select the Run button for getContent in the Method Index display or simply enter the URL http://localhost:8080/fedora/get/demo:300/demo:ex3SDef/getContent directly.

...

Example 3 packages the XSL transform Datastream in the same digital object FDO as the source XML Datastream. However, in many cases you will have XSL transform code that you want to share across several XML sources. This section modifies Example 3 to enable this sharing.

This is done by packaging the XSL transform code in a digital object FDO of its own. Then every digital object FDO that needs to make use of the XSL transform code can use the Fedora REST URL to access that Datastream. This is done by defining a redirect Datastream using the REST URL as the redirect target. Then, the same disseminator design used in Example 3 can be reused. This is known as dissemination chaining, whereby the dissemination of one digital object FDO is used by another.

The steps to do this are quite simple and use techniques introduced thus far:

• Create a new digital object FDO (the XSL digital object FDO) assigning the PID demo:400. Create one Datastream in addition to the DC with ID XSL. As before, this Datastream should be configured as:
  • ID – xsl
  • Control Group – Managed Content
  • Mime type – text/xml
  • Label - Poem XSL Transform
  • Import location: FEDORA_HOME/userdocs/tutorials/2/example3/poem.xsl
• Create another digital object FDO (the "disseminatordissemination service" digital object FDO) assigning the PID demo:500.
• Create two new Datastreams
  • One configured as follows (the same as the Source Datastream in Example 3):
    1. ID – source
    2. Control Group – Managed Content
    3. MIME type – text/xml
    4. Label - Poem XML Source
    5. Import location: FEDORA_HOME/userdocs/tutorials/2/example3/poem.xml
  • Now create the Datastream that will redirect to the XSL in demo:400 as follows:
    1. ID – xsl
    2. Control Group – Redirect
    3. Mime Type – text/xml
    4. Label - Poem XSL Transform
    5. location: http://localhost:8080/fedora/get/demo:400/XSL
    6. • On the New RELS-EXT... tab add the same hasContentModel relationship to demo:ex3CModel as you did in example 3.

You're done! The demo:500 digital object FDO should now behave exactly the same as the demo:300 digital object FDO in Example 3. Figure 17 refines Figure 16 (with some labeling removed for clarity) with the new redirect configuration.

...