Benutzer-Werkzeuge

Webseiten-Werkzeuge


Action disabled: source
docuteam:oais

Umsetzung von OAIS

Die folgende Grafik zeigt im Überblick, mit welchen Werkzeugen wir das OAIS (Open Archival Information System, ISO 14721) modularisiert umsetzen.

Download als PDF

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:

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)
    1. the root folder, corresponding to the „object“, must be named „data“
    2. subfolders may be named freely
    3. subfolders may be organized recursively
    4. in each folder (at all levels) there is a mandatory metadata file always named „dc.xml“
    5. in addition, each folder (at all levels) may contain either (but not both!):
      1. one or more subfolders
      2. 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:
    1. 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“
    2. The „Title“ field is mandatory at each level in the „dc.xml“ file. It is not repeatable.
    3. 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.

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

docuteam/oais.txt · Zuletzt geändert: 2019/06/11 14:10 von Andreas Nef