Page History

...

Author: The Fedora Development Team

...

Audience: This tutorial is intended for repository administrators or content developers who will be using the Fedora software.

Table of Contents

 
Figures

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 the Content Model Architecture
Figure 14 – Dynamic Dissemination Access
Figure 15 – Example 3 Linking a Fedora Digital Object to a Content Model
Figure 16 – Example 3 Dissemination via the Content Model Architecture
Figure 17 – Dissemination with Redirect Datastream

...

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, 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.

...

This document is intended to be hands-on, with you trying the examples on a running Fedora repository. You should therefore, have already downloaded and installed Fedora, and started a server. You should then access the Fedora repository by running the Fedora Administrator interface, fedora-admin, which is located in the FEDORA_HOME/client directory (you can start this program from the command line if you have configured your environment variables properly). Upon starting up the administrator interface you will be presented with the Login screen shown in Figure 2. This document assumes that you have not changed any of the configuration defaults for your Fedora server so the password you enter should be fedoraAdmin. If you have changed your configuration values or are running the Fedora Administrator from a machine different from the machine on which your Fedora server is running you will need to change the values in the Login screen appropriately.

...

1. Fedora Digital Object or FDO – This is the basic unit for information aggregation in Fedora. At a minimum a FDO has:
   
   
   1. A Persistent Identifier or PID – The PID provides the key by which the FDO is accessed from the repository.
   2. Dublin Core – It provides a basic description of the FDO.
2. Datastream – A component of a FDO that represents a data source. A FDO may have just the basic Dublin Core Datastream, or any number of additional Datastreams. Each Datastream can be any MIME-typed data or metadata, and can either be content managed locally in the Fedora repository or by some external data source (and referenced by a URL). When you create a new Datastream in a FDO, you assign it to one of four types, or control groups, depending on the nature of the data that it represents.
   
   
   1. Managed Content (M): Datastream content is stored and managed within the Fedora repository's persistent storage. The content can be any MIME type including XML.
   2. Inline XML (X): A special case of M, restricted to well-formed XML. In this case, the Datastream content is stored as part of the XML structure of the FDO itself and is thus included when the it is exported (e.g., for archival purposes).
   3. Externally Referenced (E): Datastream content is external to the Fedora repository and is referenced by a URL that is recorded within the FDO. The content can be any MIME type including XML.
   4. Redirected Content (R): Like E, but Datastream content is delivered to the client without any mediation by Fedora; i.e., via an HTTP redirect. You should use this Datastream type when the external content is a web page with relative links or it is streaming audio or video. The content can be any MIME type including XML.

...

Start by selecting File/New/Data Object in the Fedora Admin GUI. Complete the New Object dialog box as shown in Figure 3.

Check the box for Use Custom PID and enter demo:100. Note that when you do not assign your own PID, the Fedora repository will create one for you. Select the Create button and you should see a window like that shown in Figure 4. Observe that the PID of the created object (in this case demo:100) is displayed in the title bar.

Since our task here is to define the Datastreams in the object, click on the Datastreams tab and you will see a window like that shown in Figure 5. Note that at this point there is only one Datastream in the object – the DC Datastream containing basic descriptive metadata that was automatically created by Fedora. You can select that Datastream and select the Edit button to see the its default contents, with the DC title and identifier fields already filled in.

...

1. You will notice that the Control Group of the DC Datastream is Internal XML Metadata. As explained earlier, Fedora has a number of control group types, of which this is one. This type is appropriate for metadata that is represented in XML – Dublin Core metadata being one example. A FDO can have multiple metadata Datastreams, for example MARC, LOM, Dublin Core, and others.
2. You can directly edit the Dublin Core metadata – e.g., add new Dublin Core fields – by selecting the Edit button and modifying the contents of the text pane. When you press Save Changes…, Fedora will check that the Datastream is well-formed XML.

...

• FEDORA_HOME/userdocs/tutorials/2/example1/artex.html
• FEDORA_HOME/userdocs/tutorials/2/example1/artex.pdf
• FEDORA_HOME/userdocs/tutorials/2/example1/artex.tex

NOTE : Tutorial files are no longer included with Fedora. You can retrieve the needed files from Fedora 3.0 at sourceforge.

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're done! Your Datastreams window should now look something like that shown in Figure 7, showing all the Datastreams you have entered in the left-side tabs in the window.

...

Figure 8 illustrates the structure of the object you have created and the correspondence of REST-based access requests to the object and its components (via API-A-LITE).

...

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.

...

The resulting Datastream window should now look like that shown in Figure 10.

...

You can access the Datastreams for this FDO by viewing the item linked to from the object profile page. Then, select the link for one of the redirected Datastreams. Fedora will redirect your browser to the location of the Datastream content, without streaming the content through the Fedora repository server.

...

Figure 12 shows an abstract view of the different components of the Fedora repository architecture that are key to how Fedora produces "disseminations" of FDO object content.

...

At the end of the day, FDOs make references to SDefs, SDeps and CModels as the way of providing extended access points for FDOs (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 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 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 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 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 FDO.

...

Select File/Ingest/One Object/From File… in the Fedora Administrator. This will bring up a file selection dialog box as follows:

Browse the file system to select the ingest file for the SDef object whose file name is FEDORA_HOME/userdocs/tutorials/2/example3/SDef.xml. Since this ingest file is encoded as FOXML 1.1 select the FOXML 1.1 radio button as below:

This will create the 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.

...

The resulting Object window should look like that illustrated in Figure 15.

You're done! Figure 16 illustrates the role of this FDO and dissemination service in response to a client request. You can go to the FDO header page at http://localhost:8080/fedora/get/demo:300 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.

...

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

...