Summary Fedora Workshop Karlsruhe 4/5 May 2006

Participants from SB

• Kaare Fiedler Christiansen (DOMS)
• Toke Eskildsen (DOMS)
• Stephan Drescher (DOMS/BART)

Objective/Problem

The notion of a content model in Fedora has until now been informally provided, not validated, not expressed via a standard formalism and only identified via an object property (cModel). The Fedora Development Team has realized that it will have to work towards more formalized content model support.

Current projects address the following key activities concerning content models:

• object typing for an improvement for access and search
• object validation especially at ingest
• object creation and the possibilities of templates

Content Models

On the first day Sandy Payette gave a general overview of the current state and future problems, regarding content models in Fedora. As examples were shown content models from the University of Virginia, and the Chicago Encyclopaedia.

The second part of the first day was reserved for presentation of projects and plans from the different participants. Here the sentence "You need to know your content in order to manage it", by Natasa Bulatovic from the Max-Plank-Society, summed up the need for content models.

Generally speaking, major research institutions like AWI, Max-Plank, FIZ and Frauenhofer has shown an interest in Fedora and most have used, or will use, it for their institutional repositories and collaborative environments. Naturally, questions about authorization and administrative MD had a high priority to them. Several of the presented datamodels were very complex.

A common trend for the presented projects was ad-hoc typing and systems akin to prototyping. The prototyping introduced complexities in the form of custom middleware and cumbersome updating, in case of changes to the prototypes. The classical object oriented solutions to prototyping, by using delegation, doesn't work well with Fedora's disseminator model.

SB presentation

Our presentation included three parts:

1. Introduction and DOMS at SB, focused on the task of making content models for large quantity of legacy and future projects, presented by Kaare,
2. An atomistic, relational graph approach to model those, also explaining the purpose of the "Fedora Explorer", presented by Toke.
3. A practical example, with the BART content model, done by Stephan who also wrapped it up.

We concluded with a wish list for Fedora and mentioned our plans to come up with a repository integrity checker. It did strike us how many points we had in common from the Fedora outlook presentation by Sandy earlier that morning, but we were glad to see that the problems are being recognized by Fedora and also shared among the majority of participants at the workshop. Although on opinions how to solve those were rather wide-spread. Therefore the second day became filled with debates and another fresh proposal from the Fedora Development Team.

New developments

• Support for data stream heavy objects (compound model) to create relationsships at the data stream level, which was originally suggested by the Australian Arrow project.
• The CMDA (Content Model Dissemination Architecture) proposal for Fedora 3.0 (~ late 2007) -- a more relational orientated architecture.
• A content model workgroup. Toke and Stephan have signaled their interest to participate, Thornton Staples, whom we meet 2005 in Wales, is head of the group from Fedora's side .

On the programming front, speakers elaborated on object types, inheritance and polymorphism of objects.

CMDA Proposal

The Fedora Development Team had produced a specification draft (CMDA), that addressed the need for content models in Fedora. One of the main motivations for the proposal was the practical problems with the prototype approach to disseminators, that Fedora 2.1 requisited. Sandy Payette presented this proposal to the workshop participants for review on the second day.

http://www.cs.cornell.edu/payette/fedora/designs/cmda/

The Content Model Dissemination Architecture, was very much a work in progress. It outlined ideas for types (id + datastream schema + disseminators). There seemed to be widespread agreement at the workshop for the need for a schema for relations, which fits very well with our vision for content modelling (many small inter-related objects).

Some kind of multiple types for each objects was also called for. Whether this should be done with multiple attachments to types (interface approach), inheritance or even multiple inheritance, is still an open issue.

A content model working group was proposed. Toke and Stephan would like to be active members of that group.

Conclusion

We had two intense but enjoyable days of workshop time in Karlsruhe. Our estimates about needed future developments, that we made in preparation of the workshop, has been proven to quite accurately match those of the Fedora Development Team. We recomment that we adjust our plans for tools for validation, so that they fit together with the strategy from the Fedora Development Team, and that we continue our work in this area.

The Fedora Content Model group will hopefully be a useful resource, which we should incorporate into our strategy from the beginning.

For the DOMS project we got valuable input in choices of data representation. First we got the assurance that what we are planning is not different to what other people in the community are doing, both in libraries and other institutions. Also, the workshop gave a better base for deciding on Fedora as the DOMS project solution. Also we got some input on content model descisions we need to make in our content models in DOMS.

Last remark, Sandy and Carl are getting married this summer, we like to wish them all the best.