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