Fedora by C. Göpfert. Entwicklung von Fedora Fedora →Flexible Extensible Digital Object...
-
Upload
gudrun-schierman -
Category
Documents
-
view
220 -
download
4
Transcript of Fedora by C. Göpfert. Entwicklung von Fedora Fedora →Flexible Extensible Digital Object...
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