Page History

...

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)