Fedora

by C. Göpfert

Entwicklung von Fedora• Fedora →Flexible Extensible Digital Object

Repository Architecture• Ursprünglich von der Cornell University

entwickelt als eine Architektur für das Speichern, Verwalten und den Zugriff auf digitale Inhalte

• 2007 wurde die not-for-profit organization Fedora Commons gegründet

• 2009 schloss sich Fedora mit der DSpace Foundation zusammen → ab Juli werden sie unter dem Namen DuraSpace agieren

Fedora Versionen

• 2002 wurde die Beta-Version der Fedora open-source Software veröffentlicht

• 2003 folgte die offizielle Veröffentlichung von Fedora 1.0

• 2005 wurde Fedora 2.0 veröffentlicht• 2008 wurde Version 3.0 herausgegeben• Zur Zeit aktuell ist Version 3.2

Was kann Fedora I

• Fedora ist eine digitale open-source Bibliothek• Neben dem repository service (quasi der

Vorratskammer) auch unterstützende Dienste wie zum Beispiel Suchfunktionen (auch RDF), also ein Content-Management-System

• Vergleichbar ist Fedora von der Funktionalität her mit (dem bald ehemaligen) DSpace oder Greenstone

Was kann Fedora II

• Fedora bietet ein sehr flexibles Modell für digitale Inhalte jedweder Art

• Zusätzlich übernimmt es auch die Verwaltung der Metadaten

• Es stellt Beziehungen zwischen den einzelnen Objekten dar

• Verwaltung von Referenzen auf die Objekte• Zusätzlich ist Fedora kompatibel zu den

Anforderungen der Open Archives Initiative

Wo wird Fedora eingesetzt

• Da das Fedora Repository sehr flexibel ist, sind die Einsatzbereiche weit gefächert:- Rundfunk und Medien- Regierungsbehörden- medizinische Zentren und Bibliotheken- Museen und kulturelle Organisationen- Virtuelle Bibliotheken-Projekte- …

Probleme bei der Verwaltung von digitalen Inhalten

• Es gibt vielfältige Arten von digitalen Objekten wie Bücher, Texte, Bilder, Videodateien, Audiodateien…

• Vermehrte Erfassung von digitalen Inhalten bedeutet komplexere Anforderungen für die Archivierung dieser Daten

• Höhere Komplexität erfordert die Darstellung der Beziehungen der Objekte mittels Metadaten

Daraus resultierende Fragestellungen

• Wie können die Anwender leicht mit einer Sammlung von komplexen Daten umgehen?

• Wie können die Dienste und Werkzeuge so mit den Objekten verknüpft werden dass sie in der Lage sind, verschiedene Darstellungen der Objekte zu liefern?

• Wie kann man eine langfristige Archivierung der Daten ermöglichen?

Ziele von Fedora I• Identifiers → Persistente Identifikatoren (eindeutige

Namen) für alle Ressourcen• Relationships → Darstellung der Objektbeziehungen

(wie z.B. Parent, child)• Tame Content → Vereinheitlichung der heterogenen

Inhalte und Metadaten aufgrund eines erweiterbaren Objektmodells

• Integrated Management → Verwaltung nicht nur der Daten sondern auch der unterstützenden Programme, Dienste und Werkzeuge, die für eine Präsentation der Daten und Metadaten zuständig sind

• Interoperable Access → Bereitstellung eines Zugangs zu Informationen über die Objekte und die Inhalte dieser Objekte durch Standard Protokolle

Ziele von Fedora II• Scalability → Support von über 10 Millionen Objekten• Security → Bereitstellung einer flexiblen

Authentifizierung• Preservation → Unterstützung von langfristiger

Archivierung einschließlich XML Serialisierung von Objekten und Versionierung des Inhalts

• Content Recon → Wiederverwendung von Objekten und deren Inhalten um dynamische Inhaltstransformationen an neue Präsentationsanforderungen anzupassen

• Self-Actualizing Objects → Verbreitung von Werkzeugen für die User-Interaktion mit Inhalten

Ziele von Fedora III

• Fedora soll flexibel, einfach und verallgemeinernd sein damit verschiedene Arten von Objekten erstellt und verwaltet werden können

• Objekte können dabei Daten, Metadaten, Eigenschaften und mögliche Dienste der Inhalte beschreiben

• Das Objekt-Modell von Fedora ist in einem XML-Schema definiert

Fedoras Object Model I• Abstraction → Das Objektmodell ist immer gleich, egal

um welchen Datentyp es sich handelt• Flexibility → Fedora kann jeglichen speziellen

Anforderungen angepasst werden• Generic → Metadaten und Inhalte sind eng verknüpft mit

dem digitalen Objekt• Aggregation → Objekte können sich auf Daten beziehen,

die lokal gespeichert sind oder sich extern auf einem Webserver befinden

• Extensibility → Die Schnittstellen sind erweiterbar, da die Dienste in direktem Zusammenhang mit den Daten eines Objekts stehen. Ändern sich die Dienste ändern sich die Objekte mit ihnen.

Fedoras Object Model II

• Compound Digital Objekt → Zusammenfassung mehrerer Inhalte in einem Objekt unabhängig von Format und Standort; die Inhalte können sowohl intern als auch extern oder auch nur als Referenz vorliegen

Aufbau eines Fedora-Systems

Objektaufbau I• Die PID wird einmal und für

immer an dieses Objekt vergeben

• Die Object Properties sind eine systemdefinierte Sammlung von Eigenschaften um innerhalb des Repositorys mit dem Objekt zu arbeiten

• Die Datastreams sind Inhalte; es gibt beliebig viele mit beliebigen Inhalten

Objektaufbau II• Die Datastreams werden

mit Identifikationskürzeln versehen

• Es gibt beliebig viele IDs, aber 3 davon sind reserviert für Angaben über DC-Medadaten, Veränderungen des Streams und über mögliche Relationen zu anderen Objekten

Objektaufbau III

• Ansonsten werden die Datastreams definiert durch: Datastream identifier, State, Date of Creation, Date of Modification, Format Identifier…

• Schließlich werde sie noch definiert durch die Kontrollgruppen, von denen es 4 gibt:- Internal XML Metadata- Managed Content- External Referenced Content- Redirect Referenced Content

Objektaufbau IV

• So bietet Fedora innerhalb des Datastreams viele Auszeichnungs- und Schnittstellentechnologien wie XML, RDF… an

• So werden Beziehungen zwischen Objekten über die Grenzen der lokalen Repositorys hinaus realisiert