Versions Compared

Key

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

...

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. Image Removed
Figure 13 - Fundamental CMA Relationships

Section
Wiki Markup

{center}
!worddav260b00704cd49b2f81797bbe01694fa5.png|height=310,width=524!
*Figure 13 -- Fundamental CMA Relationships* 
{center}

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. Image Removed
Figure 14 - Dynamic dissemination access

Section
Wiki Markup

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

Example 3: Using SDefs, SDeps and CModels

...

This example makes use of a SDef, SDep and CModel supplied with the Fedora tutorial. This will help you understand the basics of dynamic disseminations in Fedora under the Content Model Architecture, without writing a SDef, SDep or CModel. The next example describes how to do that more advanced task.

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.

Ingesting

...

Pre-defined SDef, SDep and CModel

...

Objects

First we will ingest a sample SDef object into the repository.

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

Section
Wiki Markup

{center}
!worddav766c8e413d3860eaec6409d0a6d5b61c.png|height=366,width=508!
{center}

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:Image Removed

Section
Wiki Markup

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

This will create the digital object 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 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:

  • Service Contract: the SDep indicates the PID of the SDef that it is related to. This is like saying that the SDep provides and implementation of the SDef.

...

  • Service binding metadata (i.e., in WSDL) : concrete binding for the getContent method that is defined. Specifically, the WSDL indicates that the getContent operation binding exists at the base URL of http://localhost:8080/service/saxonImage Modified. Note that this service is hosted at the same host and port as the Fedora repository. As noted earlier, this is a local service that is packaged with Fedora.

...

  • Data input profile that indicates that the SDep service operation getContent will take the following inputs at runtime:

      ...

        • "xsl" with MIME type text/xml.

      ...

        • "source" with MIME type text/xml.

      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 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 demo:ex3SDef ingested previously.

      Creating a

      ...

      Digital Object with Appropriate Datastreams

      Now you need to create the new digital object 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.

      You now need to add the two datastreams: the xml source document and the xsl transform document. Using the same method described in Example 1, select the Datastreams tab and:

      • 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

              ...

              Digital Object to the Content Model

              In Fedora Administrator, select the Datastreams tab from the digital object 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:

              ...

              The resulting Object window should look like that illustrated in Figure 15.
              Image Removed
              Figure 15 - Example 3 Linking a Digital Object to a Content Model

              Section
              Wiki Markup
              
              {center}
              !worddav312dbd28306cd3f7f643185f2cb1dc19.png|height=488,width=576!
              *Figure 15 -- Example 3 Linking a Digital Object to a Content Model* 
              {center}
              

              You're done! Figure 16 illustrates the role of this digital object and disseminator in response to a client request. You can go to the digital object 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.

              Image Removed
              Figure 16 - Example 3 dissemination via CMA

              ...

              Section
              Wiki Markup
              
              {center}
              !worddav99c4468a3a6c6a98dba66f8cd6c30ba1.png|height=353,width=565! 
              *Figure 16 -- Example 3 dissemination via CMA* 
              {center}
              

              Example 4 – Modifying Example 3 Using a Redirect Datastream

              Example 3 packages the XSL transform datastream in the same digital object 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 of its own. Then every digital object 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 is used by another.

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

              • Create a new digital object (the "XSL" digital object) 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 (the "disseminator" digital object) 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
                          6. o Now create the datastream that will redirect to the XSL in demo:400 as follows:
                          7. ID - xsl
                          8. Control Group - Redirect
                          9. Mime Type - text/xml
                          10. Label - Poem XSL Transform
                          11. location: http://localhost:8080/fedora/get/demo:400/XSLImage Modified
                          12. • 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 should now behave exactly the same as the demo:300 digital object in Example 3. Figure 17 refines Figure 16 (with some labeling removed for clarity) with the new redirect configuration.

                      ...