Table of Contents

Installation Guide

Warning This page is no longer updated. The project is moved to http://ecm.sourceforge.net

For people who would like to use the Enhanced Content Models, here is a installation guide. First, two points of warning.

  1. The system is not yet done, and will have bugs. We would be grateful for any testing, and reporting. If you report bugs, we will adress them as fast as possible.
  2. The system is not merely a plugin. It requires sizable additions to your content models. We will include test examples, but the real deploy time includes the design and formalization of a datamodel.

With that out of the way, lets proceed. The system is basically two components, the validator webservices, and the new content models.

Api hooks

First, look at Api Hooks. You need to add some lines to your fedora.fcfg. In case you don't know this file, it is the big config file for Fedora, and reside in $FEDORA_HOME/server/config. Search for <module role="fedora.server.management.Management" class="fedora.server.management.ManagementModule">
and add these three decorator hooks

        <param name="decorator2" value="dk.statsbiblioteket.doms.fedora.server.management.DomsForbiddenInvocationHandler"/>
        <param name="decorator3" value="dk.statsbiblioteket.doms.fedora.server.management.DomsStateInvocationHandler"/>
        <param name="decorator4" value="dk.statsbiblioteket.doms.fedora.server.management.DomsValidatorInvocationHandler"/>
        <param name="validator.webservice.location" value="http://localhost:7910/fedora-validator/services/Validator">
            <comment>Specifies the location of the validator webservice invoked by Decorator 4 above.</comment>
        </param>
        <param name="validator.webservice.fedora.location" value="http://localhost:7910/fedora">
            <comment>Specifies the location of the fedora instance for the validator webservice</comment>
        </param>

        <param name="validator.webservice.fedora.username" value="fedoraAdmin">
            <comment>Specifies the username the validator should use to connect to Fedora. This user must have access to all non-changing
                API-M methods, but will never have to write to the repository.</comment>
        </param>

        <param name="validator.webservice.fedora.password" value="fedoraAdminPass">
            <comment>Specifies the password for the validator.webservice.fedora.username. Sorry about having to write the password in cleartext :(</comment>
        </param>

Of course, set the validator.webservice parameters to the correct values for your system.

Now Fedora will pass any Api-M call through those three InvocationHandlers. So we need to install these invocation handlers.
Look at the Api Hooks page. In the attachments to that page, there are two files, a src archive and a jar file. Choose whether or not
you want to build from source.
Either way, install the jar file in $TOMCAT_HOME/webapps/fedora/WEB_INF/lib so that Fedora can access it. For now you have to put it inside the webapps-extracted warfile, but I am looking for a place in $FEDORA_HOME where the classloader can find it.

Validator webservices

Next, the validator webservice needs to be installed. Look at the page Fedora Validator. Again, there is a source pack and a binary. Build the source, or download the binary. The binary is a war file, ready to be deployed in a tomcat. Deploy it in your tomcat, and note the location. This is the location that needs to be specified in validator.webservice.location above. The DomsValidatorInvocationHandler will take care of feeding the validator anything else it needs to know from the params in fedora.fcfg.

New Content Models

And now the big one. The new Content Models. Really look at the pages Fedora Ontologies, Fedora Type Checking and most importantly Sample Content Model
The Content Models must have a new datastream, "ONTOLOGY", containing the OWL description of the class (of objects represented by this content model).

I believe the validator will fail if there is no ONTOLOGY datastream, but this is not planned. It will be fixed in the next release.

If you want to validate the contents of your datastreams, you need to add enhancements to the DS-COMPOSITE-MODEL datastream. This extension should be relatively self-explanatory based on the sample content model. The actual schema will be encoded in some other datastream. A note about encoding schemas in datastreams: We desired that the Fedora repository should be selfdescribing, ie. that the objects should contain the schemas needed to understand them. For that reason, the schema extension will always point to a object, not an url. But you could make a datastream like, and point to that.

    <foxml:datastream
            CONTROL_GROUP="E"
            ID="SCHEMA"
            STATE="A"
            VERSIONABLE="true">
        <foxml:datastreamVersion
                ID="SCHEMA.0"
                MIMETYPE="text/xml"
                LABEL="schema">
            <foxml:contentDigest DIGEST="none" TYPE="DISABLED"/>
            <foxml:contentLocation REF="http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd" TYPE="URL"/>
        </foxml:datastreamVersion>
    </foxml:datastream>

If you look at our schema in Sample Content Model, you will see that we have changed the source location for all the import statements, as we did not want to depend on any schema outside the repository.

If you have any questions about any bit of this system, feel free to mail me (Asger Askov Blekinge)

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels