Versions Compared

Key

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

...

Contributor: State and University Library, Denmark Asger Blekinge-Rasmussen abr@statsbiblioteket.dk

website

Fedora is at the core of the new DOMS (Digital Object Management System) being developed at the State and University Library. For this system,
we needed more powerful content models. More specifically, we needed content models the describe the xml schema for datastreams, cardinality
restrictions on relations and allowed types for the target of relations. In addition, we needed to retain compability with the original fedora
system.

Enhanced Content Models have a number of new features compared to the Fedora 3.0 content models. First of these is the more elaborate specification of the data objects. Second is the repository view system, which allows the repository to dynamically remap the contained data to virtual data objects. And third is the object creation templates, which allows the content models to behave as object classes from which new data object instances can be made.

All our work is under the Apache 2.0 License, and is/will be available as add-ons to Fedora.

Fedora is an extensible repository system, containing data objects and content models, which hold descriptions of the data objects that subscribe to them. In Fedora 3.0 Content Models express the classes of objects, and tie data objects to disseminators, but do little else.

Content Models are formal descriptions of data objects, which should be distinguished from datamodels, which are descriptions of collections of data. Having a datamodel is a requirement for many digital repositories and the easiest solution is creating an interface that only allows data to be entered in a special format. If all data is input through this interface, it will adhere to the datamodel. Unfortunately, this has the side effect of coupling the datamodel to the program code of the interface.

We believe that the datamodel should not be part of the interface, it should be part of the repository. We achieved this by enhancing the Content Models. The Enhanced Content Models can specify the cardinality and target classes of relations, and schemas for datastreams. We have implemented a validator, which checks data objects against their Content Models. A set of Enhanced Content Models makes up a datamodel.

In Fedora, you might have atomic objects making up a "record", but for indexing purposes, this record must be flattened to one compound. Enhanced Content Models can specify how to do this flattening, in the repository view system, and we have implemented a webservice to create such compounds.

In many OO programming languages new objects are created as instances of a class. Enhanced Content Models implements this pattern. You can declare certain data objects to be templates for an enhanced content model. We have developed a webservice that can create new objects in Fedora, given a content model and a template to use as basis.We did this by enhancing the DS-COMPOSITE-MODEL datastream in content models, and adding the ONTOLOGY datastream to content models.
The ONTOLOGY datastream specify restrictions on relations. DS-COMPOSITE-MODEL specify a location for an xml schema for the described datastream


Fedora-OKI

Fedora-OKI Bridge

...