Versions Compared

Key

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

...

  1. It supports the creation and management of digital content objects (from this point on called digital objects) that can aggregate data from multiple sources. For example, a digital object 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 digital objects as advanced digital documents, especially in light of the feature described next.

  2. It supports the association of web services with the digital objects. These services typically consume the data packaged within the digital object to produce dynamic disseminations from the digital object. For example, the digital object described above with multiple TIFF page images may be associated with a service that OCRs the images that are components of the digital object 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 digital objects, 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 digital objects 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 digital object 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 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 digital objects.

  7. It supports ingest and export of digital objects in a variety of XML formats. This enables interchange between Fedora and other XML-based applications and facilitates archiving tasks.

...

Fedora may be the wrong choice for management of simple static web pages. There are a number of excellent tools for HTML editing and web site creation. Fedora is more appropriate for more advanced content management tasks. These include management of content and associated metadata, multiple versions of content, content available in multiple formats, and dynamically generated content from local and dynamic sources.

...

It is often useful to provide access to a digital document in several formats. For example an ePrints server might provide HTML for those who wish to render the document in a browser, PDF for those who wish to view the document with author-determined formatting, and TeX for those who wish to access and use the document source. This example demonstrates how to construct a digital object where each Datastream corresponds to an available format. More advanced techniques, demonstrated later in this tutorial, make it possible to achieve the same results by generating formats dynamically from a single base format. But for now, we'll stick to simple static aggregation.

...

To do this, select the New... tab on the left side of the Datastreams window. We'll start with the text/html format. To insert data into the Datastream, you use the Import... button. This presents a dialog that will allow you to import from your local file system or from a URL.

Your completed HTML Datastream should look like the dialog as shown in Figure 6 (after you have imported the content).

...

You can now select the Save Datastream button and repeat the same process to add the pdf PDF and TeX Datastreams. For the pdf PDF, you can select Mime Type: application/pdf and import the file ex1.pdf. For TeX, you can select Mime Type: text/plain and import the file ex1.tex. In each case you should enter appropriate IDs and Labels.

...

  1. Rather than packaging multiple formats of a document as in Example 1, it is possible to have a digital object with one 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 PDF and html 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.

...

The web service used in the example performs an XSLT 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 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.

...