docuteam wiki

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

Download als PDF

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.

• SIP-Profil als XML-Datei.
• Spezifikation von Matterhorn METS (Stand 30.8.2017)
• Beispielpaket 1: Einfaches Paket mit nur einer Textdatei
• Beispielpaket 2: Paket mit mehreren Bilddateien
• Detaillierte Auflistung der aktuell unterstützten EAD-Felder

Docuteam feeder kann auch digitale Ablieferungen entgegennehmen, die in anderen SIP-Formaten angeliefert werden.

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.

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

Unser Ingest-Prozess docuteam feeder ist in der Lage, eine Grosszahl von Ausgangsformaten automatisiert in archivtaugliche Dateiformate umzuwandeln.

• Tabelle mit unserer Default-Konfiguration für Dateimigration
• Wir verweisen in unseren Projekten auf den Katalog archivtaugliche Dateiformate des Schweizerischen Bundesarchivs.
  
  

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.

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:

• Getting Started with Fedora
• Installation and Configuration
• Benutzermanuals (Client Reference, also alle Client-seitigen Dokumentationen)
• docuteamOAIS: Unsere Webapplikationen für einen einfachen Zugriff auf Fedora Commons

Folgende Applikationen sind End of Life und werden nicht mehr untersützt:

• docuteam transfer zur automatisierten Verschiebung abgeschlossener Dossiers aus dem Dateisystem in einen Speicherbereich. EOL September 2018.
• SIP-Creator (webbasierte Erstellung von SIP)
• Editor für Ablieferungsvereinbarungen