You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Table of Contents

Installation Guide

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 sizeable 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 basicly two components, the validator webservices, and the new content models.

Api hooks

First, look at Api Hooks. You need to add three 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"/>

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. Please note, the system does not really use config files right now, it uses hardcoded strings, so you might want to build from source.
Anyway, the DomsValidatorInvocationHandler just calls webservice, which it believes to reside on "http://localhost:7910/doms-validator_webservice/"
Install the jar file in $TOMCAT_HOME/webapps/fedora/WEB_INF/lib so that Fedora can access 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. It expects to be able to connect to the Fedora server on localhost:7910/fedora with the credentials FedoraAdmin/FedoraAdminPass. This is hardcoded at the moment, but will move to a config file soon.

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, 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 (abr@statsbiblioteket.dk)

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