Fedora

Fedora
Flexible
Extensible
Digital
Object
Repository
Architecture
Carsten Schulze
AG Metadaten 2009-09-23

23.09.2009 |Carsten Schulze | Zeitungsinformationssystem ZEFYS S. 2
Warum brauchen wir ein Repositorium?
 anders gefragt: Warum können wir uns nicht KEIN
Repositorium leisten?
 Stand der Dinge:
 alle Digitalisate liegen unverwaltet im Filesystem
 Beschreibung der Digitalisate durch METS
 Möglichkeit der Anzeige durch GOOBI-Präsentation, DFG-Viewer
oder Insellösungen (z.B. ZEFYS)
 kein zentraler Zugriff auf Digitalisate/Metadaten
 kein zentraler Einstiegspunkt für Nutzerrecherchen/Serviceprovider
 heterogene Metadatenprofile
 hoher Mittel- und Personalaufwand für Programmierungen
 schlechte bis keine Nachnutzbarkeit der Insellösungen
 Produktion der Metadaten auf „Verdacht“

 Wie könnte es sein?
 Digitalisate werden zentral verwaltet
 Versionskontrolle, Rechtemanagement, Langzeitarchivierung
 Repositorium gibt METS Profil vor, für den Ingest von Daten
 alle Digitalisierungsprojekte müssen sich nach dem Ingest-Profil
des Repositoriums richten -> einheitliche Metadatenerstellung
 einheitliche Dissemination-Profiles (z.B. SBB METS-Profil)
 Interoperabilität durch Bekanntmachung des Metadtenprofils für
die Community (z.B. OAI-Profil, METS Profile Registry)
 zentraler Zugriff für alle
 Recherche über alle oder Subsets von Digitalisaten
 Schnittstellen sind schon im Repositorium vorhanden
 Nachnutzung von Services für alle Projekte
 geringer Mittel- und Personalaufwand durch Synergieeffekte

 weitere Vorteile:
 Definition von Relationen zwischen digitalen Objekten
 gezieltes Ansprechen von kleinsten Teilen von digitalen Objekten
(z.B. ein Zeitungsartikel)
 Zitieren von digitalen Objekten (jedes kleinste Teil hat ein URI)
 Nutzung von Suchmaschinentechnologie für Recherche
 Einbindung von Ontologien
 semantische Suche
 Mal angenommen jemand hätte eine LZA-Lösung (z.B. DNB)
 nur über ein Repositorium könnte man sinnvoll (interoperabel) auf
unsere Daten zugreifen

Vorschlag zur Diskussion
 Ein Repositorium baut sich nicht alleine auf:
 Anpassung und Pflege der Schnittstellen
 Definition von Ingest und Dissemination Packages
 Definition Pflege von Services
 Verknüpfung mit Ontologien
 Ansprechpartner für alle Digitalisierungsprojekte
 Wir brauchen eine Person, die in Vollzeit (zumindest zwei
Jahre) das Repositorium aufbaut und anpasst.
 danach für die Pflege und Verwaltung eine halbe Stelle

Angenda
1. Kontext
2. Was macht Fedora einzigartig
3. Was bietet Fedora
4. Wie gelangen meine Digitalisate in Fedora
5. Wie ist ein Fedora Objekt aufgebaut
6. Zugriff auf Fedora Inhalte
7. Zugriffsmodell
8. Services
9. Beziehung von Objekten

Kontext
 hauptverantworliche Organisation: DuraSpace (non-profit)
 open source
 lizensiert unter der Apache License, Version 2.0
 Software zum
 Speichern
 Verwalten
 Zugriff
 digitale Inhalte jeglicher Art
 geeignet für
 digitale Sammlungen
 digitale Bibliotheken
 Archive
 Langzeitarchivierung und –verfügbarkeit
 institutionelle Repositorien
 open access publishing
 Dokumentenmanagement
 usw.

Was macht Fedora einzigartig?
 abstrakte Methoden um digitale Objekte zu beschreiben
 kann Beziehungen zwischen digitalen Objekten beschreiben
 gibt eine Serviceorientierte Architektur (SOA) vor, in die
digitalen Objekte eingebunden werden können
 eine offene Architektur, die nach eigenen Vorstellungen
angepasst und erweitert werden kann
 Speichern und Verwalten jeglichen Typen von digitalen
Inhalten (Text, Audio, Film, Multimedia etc.)

Was bietet Fedora?
 repository (core) service
 web-basierter Service mit SOAP/REST APIs (z.B. SRU)
 zusätzliche Services
 Suche mit Suchmaschinentechnologie
 Triple-Store für semantisches Retrieval (SPARQL)
 Versionierungs- und Wiederherstellungsmechanismen
 OAI-PMH Provider Service
 Service zum (Batch-)Einlesen aus Ordnerstrukturen
 Trennung von digitalen Objekten bezüglich ihres Inhalts
 eindeutige Identifizierung beliebiger Datenströme durch URI
 verschiedene grafische Oberflächen zur Verwaltung (z.B. Fez)
 erfüllt DINI-Anforderungen (von Softwareseite aus)

Wie gelangen meine Digitalisate in Fedora?
 z.B. durch den Directory IngestService
Ordnerstruktur mit
METS und
Digitalisaten
Regeln, wie die
Ordnerstruktur
ausgelesen werden
soll

Wie ist ein Fedora Objekt aufgebaut?
 ein Objekt in Fedora wird mittels FedoraObject XML (FOXML)
definiert und verwaltet
Metadaten über das Objekt
verfolgt alle Änderungen am
Objekt / wird nur vom System
kontrolliert
Beziehung zu anderen digitalen
Objekten
•intern gespeichert oder extern
referenziert
•Metadaten oder Daten
•MIME-Typ
•lokaler + globaler Identifier (DOI
oder Handle)
•Status (gelöscht, aktiv?)
•Checksum (MD5, SHA-1...)

Zugriff auf Fedora Inhalte
 für jeden Inhalt (Datastream) hält Fedora ein „access point“
vor
 jeder „access point“ wird durch eine URI identifiziert
 welche „access points“ bzw. Typen von Datastreams ein
Fedora Objekt hat wird durch ein „Content Model Object “
beschrieben

Zugriffsmodell

Services
 Services, die auf Inhalte angewandt werden können, werden
in einem „Service Definition Object“ definiert und über ein
„Service Deployment Object“ an das System angepasst
Service Definition Object
Service Deployment Object

Beziehungen von Objekten
 Fedora bietet die Möglichkeit Beziehungen von Objekten zu definieren (z.B.
Sammlung <-> Sammlungsstück
 Fedora Objektbeziehungen sind in der „Fedora relationship ontology“ definiert
 Fedora Objektbeziehungen sind innerhalb eines Objekts als Datastreams
verankert
 Fedora Objektbeziehungen werden in RDF kodiert
 Fedora indiziert automatisch alle Objektbeziehungen in den „RDF-based Resource
Index“

Vielen Dank für Ihre Aufmerksamkeit
Carsten Schulze
Zeitungsinformationssytem ZEFYS
carsten.schulze@sbb.spk-berlin.de

Fedora

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Fedora

Ähnlich wie Fedora (20)

Fedora