Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03413.jsonl.gz/813

Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
Umsetzung von OAIS
Die folgende Grafik zeigt im Überblick, mit welchen Werkzeugen wir das OAIS (Open Archival Information System, ISO 14721) modularisiert umsetzen.
Das Datenmodell: METS Matterhorn Profil
Das Daten- und Metadatenmodell, welches Docuteam für Informationspakete verwendet, basiert auf weit verbreiteten, etablierten und öffentlich zugänglichen Standards:
- METS Metadata Encoding and Transmission Standard als Containerformat
- PREMIS Data Dictionary 2.1 für technische und administrative Metadaten. Daraus verwenden wir gegenwärtig die Sektionen „Object“ und „Event“. Geplant ist, in einer nächsten Version mit Hilfe von „Rights“ auch Benutzerrechte innerhalb des Archivs abzubilden.
- Dublin Core für beschreibende Metadaten
- Oder für komplexer strukturierte Metadaten Encoded Archival Description (EAD). Hier arbeiten wir nach wie vor mit der Version 2002.
Unser SIP-Format haben wir zusammen mit dem Staatsarchiv Wallis in Form eines METS-Profils im Detail beschrieben.
Andere SIP-Formate
Docuteam feeder kann auch digitale Ablieferungen entgegennehmen, die in anderen SIP-Formaten angeliefert werden.
eCH-0160
Der Crosswalk zwischen eCH-0160 und Matterhorn METS wurde im Rahmen eines eCH-Whitepapers und eines detaillierten Data Dictionaries spezifiziert. Die Dokumente finden sich bei eCH unter diesem Link. eCH-0160 ist ein Ablieferungsformat für GEVER-Systeme. Es ist kein Format für die Langzeitarchivierung, weil es das OAIS-Informationsmodell nur unvollständig abbildet.
Docuteam Dublin Core
Ablieferungen aus Fachapplikationen verfügen nicht grundsätzlich über eine komplexe Struktur oder umfassende Metadaten. Für solche Fälle stellt das Docuteam Dublin Core-Format einen effizienten, und dennoch konsistenten Weg zur Verfügung. Es baut auf folgender Basis auf:
- BagIt als Container-Format
- SHA-256 (plus optional weitere) für Checksummenprüfung
-
- Container-Struktur (innerhalb des Bags)
- the root folder, corresponding to the „object“, must be named „data“
- subfolders may be named freely
- subfolders may be organized recursively
- in each folder (at all levels) there is a mandatory metadata file always named „dc.xml“
- in addition, each folder (at all levels) may contain either (but not both!):
- one or more subfolders
- one datafile, which may be named freely (except „dc.xml“)
-
-
- metadata constraints
This version 1.0 of the package format is restricted to the Dublin Core Metadata Element Set, limited to 15 elements (dc 1.1 terms, see http://dublincore.org/documents/dcmi-terms/#section-3). In addition, the following constraints apply:
- The „Identifier“ field is mandatory at each level in „dc.xml“, it must contain:
- At each level: the the client application identifier of the object with the prefix „clientid:“ e.g. „clientid:1234567“ or „clientid:d4FTw3v6T“
- At root level, a mandatory identifier with the customer namespace in the repository (this is often the ISIL code) prefixed with „namespace:“, e.g. „namespace:CH-1234-1“
-
- The „Title“ field is mandatory at each level in the „dc.xml“ file. It is not repeatable.
- All other 13 dublin core elements are optional and repeatable
-
Automatisierte Migration von Dateien in Archivformate
Unser Ingest-Prozess docuteam feeder ist in der Lage, eine Grosszahl von Ausgangsformaten automatisiert in archivtaugliche Dateiformate umzuwandeln.
- Wir verweisen in unseren Projekten auf den Katalog archivtaugliche Dateiformate des Schweizerischen Bundesarchivs.
Software "Von Archivaren für Archivare"
Unsere Software steht unter der Open Source-Lizenz GPLv3. Docuteam will als Unternehmen von Projekt zu Projekt dazulernen. Wenn wir ein digitales Archiv umsetzen, dann bringen wir unseren bestehenden Code ins Projekt ein. Der Kunde bezahlt dafür keine Lizenzgebühren sondern nur Entwicklungskosten für das, was er an Funktionalitäten zusätzlich benötigt. Wenn möglich führen wir Entwicklungsprojekte für mehrere Kunden gemeinsam durch, so verteilen sich die Kosten auf mehrere Organisationen. Wir glauben an dieses Innovationsmodell: Es hält Projektkosten tief, beschleunigt die Entwicklungszyklen und erlaubt es uns, unser Know-how und unsere Expertise als Archivare bestens in die Projekte einzubringen. Wir sehen uns als fachliche Partner der Archivinstitutionen und nicht als reine Softwarelieferanten.
Auch die mitgelieferten Drittwerkzeuge stehen unter Open Source-Lizenzen. Es ist aber durchaus möglich (und auch üblich), kommerzielle Komponenten miteinzubinden, beispielsweise für bestimmte Dateikonvertierungen. Open Source bedeutet nicht, dass auf Wartung, Support und Störungsbehebung verzichtet werden muss. In der Regel schliessen wir Wartungs- und Unterstützungsverträge ab, dann sind die Verantwortungen und Ansprechspartner klar geregelt.
Repository: Fedora Commons
Grundsätzlich ist unser Ingest-Workflow konfigurierbar, dass er Informationspakete an eine beliebige Respository-Software abliefern kann. In unseren Projekten verwenden wir in aller Regel Fedora Commons als Repository. Dieses System steht, genau gleich wie auch unsere übrigen Komponenten, unter einer Open Source-Lizenz. Für die Installation, Konfiguration und Verwendung von Fedora verweisen wir auf die entsprechenden Kapitel der englischen Originaldokumenation:
End of Life
Folgende Applikationen sind End of Life und werden nicht mehr untersützt: