ech-0160 Archivische Ablieferungsschnittstelle

Transkript

1 E-Government-Standards Seite 1 von 56 ech-0160 Archivische Ablieferungsschnittstelle Name Standard-Nummer Kategorie Reifegrad Archivische Ablieferungsschnittstelle (SIP) ech-0160 Standard Implementiert Version 1.0 Status Abgelöst Genehmigt am Ausgabedatum Ersetzt Standard Sprachen Autoren Deutsch (Original), Französisch (Übersetzung) Fachgruppe Digitale Archivierung arguérite Bos, Schweizerisches Bundesarchiv, marguerite.bos@bar.admin.ch Georg Büchler, KOST georg.buechler@kost.admin.ch Anouk Dunant Gonzenbach, Archives de l Etat de Genève anouk.dunant-gonzenbach@etat.ge.ch David Gubler, Fachlabor Gubler AG d.gubler@swiss-mikrosave.ch artin Kaiser, KOST martin.kaiser@kost.admin.ch arkus Lischer, Staatsarchiv Luzern markus.lischer@lu.ch Nicole artini, Schweizerisches Bundesarchiv nicole.martini@bar.admin.ch Urs eyer, Schweizerisches Bundesarchiv urs.meyer@bar.admin.ch Ursina Rodenkirch-Brändli, Staatsarchiv Graubünden ursina.rodenkirch@sag.gr.ch Stefan Ryter, Staatsarchiv Bern stefan.ryter@sta.be.ch Herausgeber / Vertrieb /

2 Zusammenfassung E-Government-Standards Seite 2 von 56 Dieses Dokument spezifiziert eine Ablieferungsschnittstelle für Dossiers und Dokumente aus Geschäftsverwaltungssystemen, Fachanwendungen/Datenbanken und Dateisammlungen an ein Archiv. Es handelt sich dabei um eine Präzisierung des Submission Information Packages SIP, einem der Kernkonzepte des Open Archival Information Systems OAIS (ISO 14721:2003), des zentralen Referenzmodells für die Archivierung digitaler Unterlagen. Die Grundlage für das vorliegende Dokument bildet die Spezifikation Submission Information Package (SIP), Version 4.0, des Schweizerischen Bundesarchivs BAR. In diese Spezifikation sind Ergänzungen und Korrekturen aus den in der Koordinationsstelle für die dauerhafte Archivierung digitaler Unterlagen KOST vertretenen Archiven eingeflossen. Die Schnittstelle wird vom BAR und von verschiedenen Schweizer Staatsarchiven bereits verwendet.

3 Inhaltsverzeichnis E-Government-Standards Seite 3 von 56 1 Einleitung Status des Dokuments Ziel und Zweck Struktur des Dokuments Aufbau Kapitel ID Anforderungen Unterscheidung zwischen uss und Kann-Anforderungen Notation Ordner, Dateien und Ordnerstrukturen Präzisierungsbedarf Übersicht Abgrenzung Definitionen Anforderungen pro Ablieferungstyp Anwendungsgebiet Prozess Ablieferungsobjekt Paket SIP Inhalt Verhältnis Ablieferung Paket Sicherheitseinstellungen Dateien im Paket Primärdaten Grundsätzliches Formate etadaten Allgemeine Anforderungen Konzeptuelles Datenmodell Datenmodell Ablieferungstyp GEVER Datenmodell Ablieferungstyp FILES Data Dictionary XSD Aufbau Inhaltsverzeichnis im metadata.xml apping etadaten des Ursprungssystems auf SIP-etadaten... 21

4 E-Government-Standards Seite 4 von etadaten zu den Schutzfristen etadaten zu den Zeiträumen der Dossiers etadaten zu den Prüfsummen der Dateien Referenzierung der Zugehörigkeit zu Dossiers in den etadaten Struktur SIP Rahmenvorgaben und Begrenzungen Grösse Paket Rahmenvorgaben und Begrenzungen Anzahl Dateien im Paket Erlaubte Zeichen bei der Benennung der Ordner und Dateien Aufbau eines SIP Pfadlängen und Hierarchien im SIP Spezifische Vorgaben zu einem SIP für GEVER Spezifische Vorgaben zu einem SIP für FILES Aufbau eines FILES SIP mit integrierter Dokumentation Transfer Format Package Container Änderungen gegenüber Vorversion der Spezifikation Version und Gültigkeit der Spezifikation Change-Request-Prozess Haftungsausschluss/Hinweise auf Rechte Dritter Urheberrechte Anhang A itarbeit & Überprüfung Anhang B Abkürzungen und Glossar Anhang C Gültigkeit Kapitel Anhang D Ausschnitt apping SIP-etadaten GEVER-System Anhang E Zeichensätze... 49

5 1 Einleitung E-Government-Standards Seite 5 von Status des Dokuments Abgelöst: Das Dokument wurde durch eine neue, aktuellere Version ersetzt. Die Benutzung ist zwar noch möglich, es wird aber empfohlen, die neuere Version einzusetzen. 1.2 Ziel und Zweck Die Spezifikation Archivische Ablieferungsschnittstelle (SIP) hat die folgenden Ziele: Die Spezifikation enthält die Anforderungen für die Realisierung eines Submission Information Package (SIP), das digitale Informationspaket für die Ablieferung von digitalem Archivgut an ein Archiv. Die Spezifikation legt fest, wie eine digitale Ablieferung an das Archiv aussehen muss und dient damit den abliefernden Stellen einerseits als intern anzuwendende Spezifikation wie auch zur Kommunikation mit ihren Leistungserbringern und Softwareherstellern. Die Spezifikation gibt Auskunft über die Anforderungen, die bei der Implementierung von digitalen Schnittstellen in GEVER-Systemen für die Ablieferung und bei der Erstellung von digitalen Ablieferungen aus Datenbanken und aus Dateisystemen eingehalten werden müssen. Die Spezifikation Archivische Ablieferungsschnittstelle richtet sich an die folgenden Zielgruppen: Abliefernde Stellen Leistungserbringer und Softwarehersteller von Applikationen, welche archivische Ablieferungsschnittstellen implementieren. itarbeitende des Archivs 1.3 Struktur des Dokuments Aufbau Kapitel Jedes Kapitel in dieser Spezifikation ist nach demselben uster aufgebaut. Nach einer kurzen Einleitung werden die Anforderungen in einer Tabelle aufgeführt. ID Beschreibung Anforderung /K enthält die ID der Anforderung enthält den Anforderungstext definiert ob uss- oder Kann- Anforderung

6 E-Government-Standards Seite 6 von 56 Eine Anforderung wird häufig durch Empfehlungen und Beispiele weiter erklärt. Sowohl Empfehlungen wie auch Beispiele sind speziell gekennzeichnet. ID Beschreibung Anforderung /K A_4.1-1 Anforderungstext Beispiel Beispieltext Empfehlung Empfehlungstext ist immer kursiv ID Anforderungen Die Anforderungen sind über eine ID eindeutig identifizierbar. ID A_4.1-1 Diese ID ist nach dem folgenden uster aufgebaut: A_ Buchstabe + _ identifiziert Hauptkapitel A_ = Allgemeine Anforderungen P_ = Anforderungen an die Primärdaten _ = Anforderungen an die etadaten S_ = Anforderungen an die Paketstruktur T_ = Anforderungen an den Pakettransfer Die Nummer beginnt mit der Angabe des Kapitels (Gruppierung der Anforderungen zum gleichen Thema), die Zahl hinter dem Bindestrich wird durchnummeriert und kennzeichnet so alle Anforderungen des Kapitels Unterscheidung zwischen uss und Kann-Anforderungen Jede Anforderung ist entweder eine uss- oder eine Kann-Anforderung. Dies wird mit einem Buchstaben kenntlich gemacht, der auf die Verbindlichkeit verweist: Abkürzung K Bedeutung uss-anforderung Diese Anforderung muss erfüllt sein, um eine gültige Ablieferung zu erhalten. Kann-Anforderung Diese Anforderung sollte erfüllt sein. Sie vereinfacht das Handling einer Ablieferung sowohl für die abliefernde Stelle wie auch für das Archiv im Sinne von Best Practice.

7 E-Government-Standards Seite 7 von Notation Ordner, Dateien und Ordnerstrukturen Für die Notation von Ordnern, Dateien etc. werden die folgenden Symbole und Parameter verwendet. Symbol Bedeutung / Ordner header/ xy.txt dir1/ abc.pdf Ein Ordner mit dem Namen «header» Datei (mit Datei-Endung «txt») Beispiel-Ordner (in roter Farbe) Beispiel-Dateien (in roter Farbe) Platzhalter für Dateien oder Ordner, die für die Erklärung nicht relevant sind. [] Platzhalter für einen Ausdruck oder einen Basistyp wie «string», «integer» etc. 1.4 Präzisierungsbedarf Institutionen, die die vorliegende Spezifikation implementieren, müssen unter Umständen die folgenden Punkte präzisieren: - zugelassene archivtaugliche Formate für die Primärdaten (siehe 3.2) - aximalgrösse eines SIP (siehe 5.1) - aximale Anzahl Dateien in einem Ordner innerhalb des SIP (siehe 5.2) - Name des Toplevel-Ordners / SIP-Identifikators (siehe 0). - Übernahmevorgaben für das Ordnungssystem (siehe 4.8-2)

8 2 Übersicht 2.1 Abgrenzung E-Government-Standards Seite 8 von 56 Das vorliegende Dokument spezifiziert das Submission Information Package (SIP), das Ablieferungsobjekt für digitale Unterlagen an ein Archiv. Digitale Unterlagen müssen aufbereitet als SIP an das Archiv abgeliefert werden. (Vgl. Abb. 1). Abb. 1: Abgrenzung Ablieferungsobjekt SIP Die vorliegende Spezifikation beschreibt die Anforderungen an alle technischen Implementierungen, die zum Ziel haben, ein SIP für das Archiv aus einem bestehenden System zu extrahieren resp. aus einer Datei-Ablage herzustellen. (z. B. aus einem GEVER-System oder mit Daten aus einer Datenbank oder aus einer Sammlung von zusammengehörenden digitalen Unterlagen aus einer Datei-Ablage) Definitionen Im Rahmen dieser Spezifikation wird auf oberster Ebene zwischen zwei Ablieferungstypen unterschieden: GEVER-Ablieferungen und FILES-Ablieferungen. Der Typ FILES kann zusätzlich noch als FILES mit integrierter Dokumentation vorkommen. Dabei handelt es sich nicht um einen eigenen Ablieferungstyp sondern um einen Untertyp zur FILES-Ablieferung. Diese Typisierung leitet sich aus der vorarchivischen Herkunft des digitalen Archivgutes ab. Ablieferungstyp GEVER FILES Beschreibung Das digitale Archivgut in der Ablieferung stammt aus einem Geschäftsverwaltungssystem (GEVER-System). Das digitale Archivgut in der Ablieferung stammt aus einer Dateiablage oder aus einer relationalen Datenbank oder aus einem anderen System.

9 E-Government-Standards Seite 9 von 56 Ablieferungstyp FILES-SIP mit integrierter Dokumentation Beschreibung Falls die FILES-Ablieferung digitale Unterlagen enthält, die aus einer Datenbank oder aus einem anderen System stammen, für das dem Archiv zusätzlich noch eine System-Dokumentation abgeliefert wird, gibt es zusätzlich zu den allgemeinen Vorgaben für FILES-SIP noch weitergehende Anforderungen an die Struktur. Bei diesen Ablieferungen handelt es sich um ein FILES-SIP mit integrierter Dokumentation zu den Daten Anforderungen pro Ablieferungstyp Nicht alle Kapitel der vorliegenden Spezifikation müssen bei der Erstellung eines SIP angewendet werden. Die Anforderungen an ein SIP können sich aufgrund der vorarchivischen Herkunft der Unterlagen unterscheiden. Die Abbildung 2 hilft dabei, zu eruieren, welche Kapitel der vorliegenden Spezifikation für welche Ablieferung relevant sind. Die genaue Auflistung der relevanten Kapitel ist anhand der Übersicht im Anhang C ersichtlich. Abb. 2: Ablieferungskategorien SIP 2.2 Anwendungsgebiet Prozess Diese Spezifikation wurde auf der Grundlage des Ablieferungsprozesses des Schweizerischen Bundesarchivs für digitale Unterlagen entwickelt. Die als archivwürdig bewerteten digitalen Unterlagen müssen technisch und inhaltlich gemäss den Anforderungen in dieser Spezifikation aufbereitet und in einem korrekt erstellen SIP geliefert werden. Ist dies nicht der Fall werden die Unterlagen an die abliefernde Stelle zurückgesendet, damit diese die Korrekturen durchführen kann, resp. ein neues SIP gemäss den Anforderungen erstellt.

10 E-Government-Standards Seite 10 von Ablieferungsobjekt Paket SIP Das Ablieferungsobjekt ist ein Informationspaket, das auf dem odell des OAIS-Standard (Open Archival Information System) basiert (vgl. Abb. 3). Dieser Standard wurde durch das Consultative Commitee for Space Data System (CCSDS) entwickelt. Eines der Hauptelemente des OAIS ist, dass alle zusammengehörenden Informationen in einem sogenannten Paket zusammengefasst werden. Abb. 3: OAIS odell mit Kennzeichnung SIP Es gibt drei Pakettypen: SIP, AIP und DIP. Pakettyp SIP Submission Information Package Paket zur Ablieferung digitaler Unterlagen AIP Archival Information Package Paket zur Archivierung digitaler Unterlagen DIP Dissemination Information Package Paket zur Vermittlung digitaler Unterlagen In der vorliegenden Spezifikation werden die Anforderungen an ein SIP definiert (archivisch und technisch). Bei Einhaltung dieser Spezifikation ist sichergestellt, dass alle Pakete mit einer entsprechenden Archivierungsinfrastruktur und Archivierungsprozessen für digitales Archivgut kompatibel sind.

11 E-Government-Standards Seite 11 von Inhalt Basierend auf dem OAIS odell enthält das SIP gemäss der vorliegenden Spezifikation zwei separate Teile, die immer gemeinsam abgeliefert werden müssen. Der erste Teil ist der Header. Dieser Teil enthält alle etadaten (beschreibende Informationen betreffend das Paket und die Primärdaten) im XL-Format. Der zweite Teil ist der Content. Dieser Teil enthält alle Primärdaten. (Vgl. Abb. 4.) Abb. 4: Aufbau SIP etadaten und Primärdaten 2.5 Verhältnis Ablieferung Paket Im Fall einer Ablieferung von digitalen Unterlagen muss diese in der Form eines SIP abgeliefert werden. ID Beschreibung Anforderung /K A_2.5-1 Eine Ablieferung an das Archiv besteht aus einem oder mehreren Paketen (SIP). Dies verringert die Komplexität und vereinfacht das Handling sowohl für die abliefernde Stelle wie auch für das Archiv. 2.6 Sicherheitseinstellungen Dateien im Paket Die Dateien, die in einem SIP enthalten sind, müssen ohne Einschränkung zugänglich sein. Für den Transfer von digitalen Unterlagen mit erhöhtem Schutzbedarf von der abliefernden Stelle ins Archiv (und nur dafür) kann es nötig sein, das SIP als Ganzes z. B. mit einem Passwort zu schützen. Die Anforderungen für den Transfer sind zwischen der abliefernden Stelle und dem Archiv vorgängig auszuhandeln. ID Beschreibung Anforderung /K A_2.6-1 Die Dateien in einem SIP dürfen nicht verschlüsselt sein. A_2.6-2 Die Dateien in einem SIP dürfen nicht passwortgeschützt sein.

12 3 Primärdaten 3.1 Grundsätzliches E-Government-Standards Seite 12 von 56 Primärdaten sind alle digitalen Unterlagen, die in den abliefernden Stellen (im Rahmen von Geschäften, in Dossiers, in Geschäftsverwaltungssystemen, in Datenbanken) produziert wurden. Es gibt viele verschiedene Typen (wie z. B. Textdateien, Bilder, Datenbanken, Präsentationen, etc.). Primärdaten können «born-digital» Unterlagen sein wie auch «digitalisierte» Unterlagen. Als Primärdaten werden alle in diesem Sinne entstandenen Unterlagen bezeichnet. 3.2 Formate Die Primärdaten, die in einem SIP, das dem Archiv abgeliefert wird, enthalten sind, müssen zwingend in einem archivtauglichen Format vorliegen. Das zuständige Archiv definiert die als archivtauglich akzeptierten Formate. Diese sind nicht Bestandteil der vorliegenden Spezifikation. ID Beschreibung Anforderung /K P_3.2-1 Die Primärdaten müssen in einem für die Unterlagen geeigneten archivtauglichen Format im SIP integriert werden. P_3.2-2 Empfehlung Es ist von Vorteil, die Unterlagen bereits in einem archivtauglichen Format zu erstellen oder sie so früh wie möglich in ein archivtaugliches Format zu konvertieren. In einem GEVER-System ist die Konversion spätestens bei Dossierabschluss vorzunehmen. Auf jeden Fall muss die Konversion der Primärdaten vor der Integration der Unterlagen in das SIP erfolgen. Die Dateiendungen der Dateien müssen den üblichen Konventionen in Bezug auf die Formate der jeweiligen Dateien entsprechen. Beispiel Eine Bilddatei im TIFF-Format: Eine Tondatei im WAVE-Format:

13 4 etadaten E-Government-Standards Seite 13 von 56 etadaten sind «Informationen über Daten». Sie beschreiben die Primärdaten genauer. etadaten können in eigenen Dateien abgespeichert (sog. «separate etadaten» z.b. in einer XL-Datei), oder als so genannte «eingebettete etadaten» in einer Primärdatei bereits enthalten sein. Ein S-Word Dokument beinhaltet beispielsweise eingebettete etadaten in Form von Titel, Thema, Autor etc. Der Erhalt von eingebetteten etadaten kann aufgrund von möglichen Formatkonvertierungen im Archiv nicht sichergestellt werden. In diesem Kapitel werden die etadaten für die SIP der folgenden Ablieferungstypen spezifiziert: GEVER: Ablieferung aus einem GEVER-System, sogenannte GEVER-Ablieferung. FILES: Ablieferung einer Sammlung von Dateien (sog. FILES-Ablieferung). Unter den FILES-Ablieferungen sind auch die Ablieferungen aus relationalen Datenbanken mit integrierter Dokumentation subsumiert. 4.1 Allgemeine Anforderungen ID Beschreibung Anforderung /K _4.1-1 Alle etadaten, welche über die gesamten Archivierungsprozesse hinweg erhalten bleiben müssen, müssen als separate etadaten in einer separaten Datei im XL-Format namens metadata.xml (getrennt von den Primärdaten) vorliegen. Die Spezifikation gibt sowohl die Struktur der etadatendatei wie auch Inhalt der etadaten vor (vgl. dazu die Kapitel zur XSD und zum Data Dictionary). Diese Vorgaben müssen exakt eingehalten werden. 4.2 Konzeptuelles Datenmodell Das konzeptuelle Datenmodell vermittelt eine Übersicht über alle grundlegenden Komponenten (Entitäten) im metadata.xml sowie über deren Repräsentation im XSD, das dem metadata.xml zugrunde liegt. Im konzeptuellen Datenmodell werden die Entitäten, die zum digitalen Informationspaket gehören, wie auch die Beziehungen zwischen diesen Entitäten grafisch dargestellt. Jede Entität umfasst einen Teil der etadaten im metadata.xml. Das konzeptuelle Datenmodell liegt sowohl für das metadata.xml für Pakete des Ablieferungstyps GEVER wie auch für Pakete des Ablieferungstyps FILES vor. ID Beschreibung Anforderung /K _4.2-1 _4.2-2 Das Einhalten bzw. Umsetzen des konzeptuellen Datenmodells ist für alle Ablieferungstypen eine verbindliche Vorgabe. Es dient der Orientierung und gibt einen Überblick über alle existierenden Entitäten. Das konzeptuelle Datenmodell unterscheidet zwischen zwei Ablieferungstypen, nämlich GEVER und FILES. Je nach Herkunft des Archivgutes muss der entsprechende Ablieferungstyp gewählt werden.

14 E-Government-Standards Seite 14 von 56 Notation des konzeptuellen Datenmodells Das konzeptuelle Datenmodell wird in der vorliegenden Spezifikation gemäss dem UL- Standard (Unified odeling Language) notiert. Beschreibung der Entitäten Entität Paket Ablieferung Beschreibung Die Entität Paket beschreibt die «Verpackung» der Ablieferung in einen technischen Behälter (Ordner). Das Paket trägt je nach Phase im Paket- Lifecycle einen anderen Namen (SIP/AIP/DIP). Für die Ablieferung von digitalem Archivgut handelt es sich immer um ein SIP. Die Entität Ablieferung beinhaltet alle Angaben zur abliefernden Stelle und zur Ablieferung ans Archiv. Provenienz Die Entität Provenienz repräsentiert den Aktenbildner und bei - Ablieferungen vom Ablieferungstyp FILES zusätzlich das Informationssystem, aus dem die Ablieferung stammt. Ordnungssystem Ordnungssystemposition Dossier Dokument Inhaltsverzeichnis Ordner Datei Unstrukturierter Anhang Die Entität Ordnungssystem beschreibt den amtsseitig verwendeten Registraturplan, Aktenplan oder Strukturplan resp. die Ordnung des Archivgutes. Die Entität Ordnungssystemposition beschreibt die Eigenschaften der einzelnen Ordnungssystempositionen im Ordnungssystem. Die Entität Dossier beschreibt die Eigenschaften des zusammengehörenden Archivguts aus einem Geschäft oder aus einer anderen Ordnungsstruktur (Datenbank, Datei-Ablage). Die etadaten aus der Entität sind sowohl für Dossiers wie auch für Subdossiers anzuwenden. Die Entität Dokument repräsentiert die kleinste Ebene auf der das Archivgut inhaltlich dargestellt wird. Diese Entität enthält die etadaten, die zum Verständnis der eigentlichen Unterlagen resp. ihrem Inhalt notwendig sind. Die Entität Inhaltsverzeichnis repräsentiert das im metadata.xml enthaltene Inhaltsverzeichnis, das alle Ordner und Dateien umfasst. Die Entität Ordner repräsentiert die Ordner im Paket, in denen das Paket strukturiert ist. Die Entität Datei repräsentiert die Primärdateien im Dateisystem und beinhaltet auch Angaben zur Identifikation und Beschreibung der einzelnen Dateien. Die Entität Unstrukturierter Anhang repräsentiert die Beschreibung von Dateien, bei denen es sich nicht um eigentliches Archivgut handelt, die dem Paket als zusätzliche Information in einem speziell dafür gekennzeichneten Ordner beigegeben werden. Diese Entität ist deprecated. Von ihrer Verwendung wird abgeraten. In zukünftigen Versionen des Standards wird sie unter Umständen nicht mehr enthalten sein.

15 E-Government-Standards Seite 15 von 56 Entität Archivischer Vorgang Archivische Notiz Beschreibung Die Entität archivischer Vorgang wird erst im Archiv mit etadaten gefüllt und dokumentiert Tätigkeiten wie die Eingangskontrolle in einem SIP oder auch Formatkonvertierungen bei einem AIP. Für die Erstellung eines SIP ist diese Entität nicht von Bedeutung. Sie darf bei der Erstellung nicht verwendet werden. Die Entität archivische Notiz wird vom Archiv verwendet, um Notizen zu Objekten aus den einzelnen Entitäten zu erfassen. Für die Erstellung eines SIP ist diese Entität nicht von Bedeutung. Sie darf bei der Erstellung nicht verwendet werden. Beziehungen zwischen den Entitäten Die Beziehungen zwischen den Entitäten sind im konzeptuellen Datenmodell aus der Paketinternen Sicht zu lesen. Das konzeptuelle Datenmodell bildet damit die Welt eines einzelnen Paketes (und damit einer einzelnen digitalen Ablieferung) ab, wie sie im metadata.xml dargestellt wird. Dabei können Entitäten referenziell miteinander verbunden sein oder auch sich selbst referenzieren, wie dies bei der Ordnungssystemposition, dem Dossier und dem Ordner der Fall ist. Bei der Ordnungssystemposition ist dies notwendig, weil in einem Ordnungssystem verschiedene Hierarchien bis zur untersten Ordnungssystemposition (der Rubrik) abgebildet werden müssen. Ein Dossier kann verschiedene Subdossiers enthalten, welche aber in der Welt des Datenmodells alle unter der Entität Dossier subsumiert sind. Auch die Entität Ordner kann sich selber referenzieren und bildet die verschiedenen Hierarchien in der Ordnerstruktur eines Paketes ab. Bei den Beziehungen von der Entität Provenienz zur Entität Ablieferung und von der Entität Ordnungssystem zur Entität Ablieferung handelt es sich im Paket immer um 1:1- Beziehungen. Es kann nur eine Provenienz und ein Ordnungssystem für das digitale Archivgut in einem Paket geben. Allerdings können von einer Provenienz mehrere Ablieferungen gemacht werden und auch aus einem Ordnungssystem werden über die Zeit hinweg mehrere Ablieferungen getätigt. Diese Tatsache wird aber im konzeptuellen Datenmodell nicht abgebildet, da dieses nur die Sicht auf ein einziges Paket enthält. Die Entitäten Archivischer Vorgang und Archivische Notiz sind Entitäten, die etadaten enthalten, die erst im Archiv (nach dem Transfer des Paketes von der abliefernden Stelle ins Archiv) von Bedeutung sind. Für die Erstellung eines Paketes in der abliefernden Stelle sind diese Entitäten nicht von Bedeutung. Sie werden deshalb hier genauso wie die Entität Unstrukturierter Anhang, die für das SIP nicht von Bedeutung ist nur der Vollständigkeit halber für die Dokumentation aller Entitäten im XSD aufgeführt.

16 E-Government-Standards Seite 16 von Datenmodell Ablieferungstyp GEVER ID Beschreibung Anforderung /K _4.3-1 Der Ablieferungstyp GEVER gilt für alle Ablieferungen, die digitale Unterlagen aus einem Geschäftsverwaltungssystem (GEVER) enthalten. Das Datenmodell für GEVER-Ablieferungen ist in der Abb. 5 ersichtlich. Die folgenden Entitäten kommen im GEVER SIP (resp. in den etadaten) vor: Provenienz Paket Ablieferung Ordnungssystem Ordnungssystemposition Inhaltsverzeichnis Dossier Dokument Datei Ordner Die Entität Archivischer Vorgang wird erst nach dem Transfer des Paketes ins Archiv relevant. Die Anzahl der archivischen Vorgänge in einem SIP einer abliefernden Stelle vor dem Transfer beträgt daher immer 0. Die Entität Archivische Notiz wird erst nach dem Transfer des Paketes ins Archiv relevant. Die Anzahl der archivischen Notizen in einem SIP einer abliefernden Stelle vor dem Transfer beträgt daher immer 0. Die Entität Unstrukturierter Anhang soll in einem GEVER SIP nicht vorkommen. Abb. 5: Konzeptuelles Datenmodell Anwendungsbereich Ablieferungstyp GEVER

17 E-Government-Standards Seite 17 von Datenmodell Ablieferungstyp FILES ID Beschreibung Anforderung /K _4.4-1 Die Ausprägung FILES gilt für alle Ablieferungen, die digitale Unterlagen aus einer relationalen Datenbank oder aus einer Datei-Ablage enthalten. Das Datenmodell für FILES-Ablieferungen ist in der Abb. 6 ersichtlich. Die folgenden kommen im FILES SIP (resp. in den etadaten) vor: Provenienz Paket Ablieferung Ordnungssystem Ordnungssystemposition Inhaltsverzeichnis Dossier Dokument Datei Ordner Die Entitäten Dokument muss in einem FILES SIP nicht zwingend vorkommen. Sie kann bei Bedarf verwendet werden. Die Entität Archivischer Vorgang wird erst nach dem Transfer des Paketes ins Archiv relevant. Die Anzahl der archivischen Vorgänge in einem SIP einer abliefernden Stelle vor dem Transfer beträgt daher immer 0. Die Entität Archivische Notiz wird erst nach dem Transfer des Paketes ins Archiv relevant. Die Anzahl der archivischen Notizen in einem SIP einer abliefernden Stelle vor dem Transfer beträgt daher immer 0. Die Entität Unstrukturierter Anhang soll in einem FILES SIP nicht vorkommen. Abb. 6: Konzeptuelles Datenmodell Anwendungsbereich Ablieferungstyp FILES

18 E-Government-Standards Seite 18 von 56 ID Beschreibung Anforderung /K _4.4-2 Für die Beziehungen zwischen den Entitäten Dossier, Dokument und Datei gibt es im FILES SIP zwei Fälle (vgl. Abb. 7). Fall A (blau markiert): Eine Datei ist direkt einem Dossier zugeordnet. Ein Dossier besitzt 0..* Dateien. Es gibt keine Dokumente. Fall B (grün markiert): Eine Datei ist einem Dokument zugeordnet. Das Dokument ist dem Dossier zugeordnet. Ein Dossier besitzt 0..* Dateien. 1 Dokument besteht aus 0..* Dateien. (wie bei der Ausprägung GEVER) Fall A und B können gleichzeitig in einem Paket vorkommen. Fall A und B können gleichzeitig in einem Dossier vorkommen. Abb. 7: Unterschiedliche öglichkeiten der Beziehungen zwischen Dossier, Dokument und Datei 4.5 Data Dictionary Im Data Dictionary sind die einzelnen etadatenelemente nach Entitäten aufgeteilt und spezifiziert. Das Data Dictionary basiert auf dem bereits vorgestellten Datenmodell. Jedes Kapitel des Data Dictionary behandelt eine Entität. ID Beschreibung Anforderung /K _4.5-1 Alle etadaten, die im Data Dictionary als uss bezeichnet sind, müssen ins SIP übertragen werden.

19 E-Government-Standards Seite 19 von 56 ID Beschreibung Anforderung /K _4.5-2 etadaten, die aus dem Ursprungssystem (GEVER, FILES) und über alle anderen Elemente der Ablieferung bekannt sind und für die ein geeignetes Attribut in den etadaten des SIP vorhanden ist, müssen zwingend ins SIP übertragen werden. Empfehlung Je genauer die digitalen Unterlagen mittels etadaten beschrieben sind, desto einfacher gestaltet sich auch der Umgang mit dem Archivgut, sobald es wieder bereitgestellt und vermittelt wird. Das Data Dictionary mit allen etadatenelementen des SIP sowie den für die Spezifikation der etadaten verwendeten Attribute liegt als Beilage zur Spezifikation vor. 4.6 XSD Die XSD (XL Schema Definition) inkl. Dokumentation beschreibt die Struktur (oder Grammatik) der XL Datei, welche die etadaten einer Ablieferung enthält (metadata.xml). Es ist die technische Umsetzung des Data Dictionary und des Datenmodells und zugleich die Grundlage für die Validierung des metadata.xml im SIP. ID Beschreibung Anforderung /K _4.6-1 Die XSD ist für das metadata.xml verbindlich einzuhalten. Das heisst, jedes metadata.xml in einem SIP muss gegenüber der XSD positiv validiert werden können. Die XSD liegt digital inklusive einer Dokumentation als Beilage zur Spezifikation vor.

20 E-Government-Standards Seite 20 von Aufbau Inhaltsverzeichnis im metadata.xml ID Beschreibung Anforderung /K _4.7-1 Alle Ordner und Dateien im Paket (Inhalte des Ordners content/ und Ordners header/) müssen im Inhaltsverzeichnis des metadata.xml gemäss den Vorgaben mit allen etadaten aufgeführt sein. Die einzige Ausnahme dieser Regel gilt für die Datei metadata.xml im Ordner header/. Diese Datei darf nicht im metadata.xml aufgeführt werden, da sie sonst auf sich selbst verweisen würde. Beispiel Aufbau des SIP (schematisch) SIP_ _Bm/ header/ metadata.xml xsd/ ablieferung.xsd.xsd content/ d0001/ d0002/ p0001.pdf Entsprechendes Inhaltsverzeichnis eines metadata.xml

21 E-Government-Standards Seite 21 von apping etadaten des Ursprungssystems auf SIP-etadaten Um die etadaten des SIP korrekt ausfüllen und aus dem System extrahieren zu können, braucht es ein apping zwischen den etadatenfeldern im System des Aktenbildners und denjenigen im SIP. ID Beschreibung Anforderung /K _4.8-1 _4.8-2 Die etadaten, die bei der abliefernden Stelle bereits vorhanden sind, entsprechen in ihren Inhalten, ihrer Aufbereitung und bei bereits vorhandenen Datenmodellen häufig nicht den Strukturen, die für Erstellung eines SIP benötigt werden. Deshalb muss ein apping zwischen den etadaten, die der Aktenbildner resp. die abliefernde Stelle erstellt hat und den etadaten im SIP zur Ablieferung des Archivgutes ans Archiv vorgenommen werden. Dies muss von der abliefernden Stelle sowohl für GEVER- SIP wie auch für FILES-SIP sichergestellt werden. Bei einem GEVER-SIP ist das Ordnungssystem ins SIP zu übernehmen. _4.8-3 Empfehlung Es wird empfohlen, zunächst ein apping zwischen den etadaten des ursprünglichen GEVER-Systems und den etadaten des SIPs herzustellen. Ein Beispiel eines Teils eines solchen appings für ein GEVER- System findet sich im Anhang D. Bei einem FILES-SIP muss nicht nur die Ablagestruktur (physische Ordnung) auf Ordner- und Dateiebene, sondern auch die entsprechende Systematik auf Ordnungssystem- und Unterlagenebene (logische Ordnung) in den etadaten verzeichnet werden. Die Unterlagen werden dadurch gemäss ihren Inhalten in sinnvolle Einheiten zusammengefasst und zu einem vermittelbaren Dossier zusammengefügt. Empfehlung Falls keine solche Ordnung bereits vorhanden ist, sollte sie aufgrund der Inhalte der Unterlagen erstellt werden. Es wird empfohlen, bereits vorhandene oder sinnvolle Systematiken und Ordnungen von Datei-Strukturen oberhalb der Dossiers im Ordnungssystem abzubilden und zusammengehörende Unterlagen in Dossiers zusammenzufassen.

22 E-Government-Standards Seite 22 von 56 ID Beschreibung Anforderung /K Beispiel Eine Dateiablage beinhaltet eine Bildersammlung aus unzähligen ungeordneten Bildern. Die Bilder könnten nun z. B. nach Entstehungsjahr geordnet und auf Dateiablage-Ebene in Ordnern zusammengefasst werden. Der Inhalt dieser Ordner wird dann jeweils als Dossier in den etadaten beschrieben. Der Order content im SIP sieht dann folgendermassen aus: content/ Bilder_2008/ Kaefer.tif Delfin.tif Sonnenblume.tif Orange_Blume.tif Bilder_2009/ ehrere_blumen.tif Pinguine.tif odellhaft könnte diese Ordnung mit der Zuordnung zu den Dossiers folgendermassen dargestellt werden: = Ordnungssystem = Ordnungssystemposition = Dossier

23 E-Government-Standards Seite 23 von 56 ID Beschreibung Anforderung /K _4.8-4 Für FILES-SIP mit integrierter Dokumentation (z. B. Datenbankarchivierungen mit SIARD) ist ein einfaches Ordnungssystem zu erstellen, um die Dossiers mit der Dokumentation und den Daten zu integrieren. Beispiel odellhaft könnte eine solche Ordnung folgendermassen dargestellt werden: = Ordnungssystem = Ordnungssystemposition = Dossier 4.9 etadaten zu den Schutzfristen Die Angaben zu den Schutzfristen der abgelieferten Unterlagen müssen in den etadaten des SIP festgehalten werden. ID Beschreibung Anforderung /K _4.9-1 Die Angaben zu den Schutzfristen der Unterlagen im Paket müssen in die dazu zur Verfügung stehenden etadaten im metadata.xml eingetragen werden. Bei den etadaten handelt es sich um die folgenden: <schutzfristenkategorie>: Angabe des relevanten Artikels in den gesetzlichen Grundlagen (falls anwendbar) <schutzfrist>: Dauer der Schutzfrist in Jahren Das etadatenpaar, das die Schutzfristen festhält, steht in drei Entitäten zur Verfügung: Ablieferung Ordnungssystemposition Dossier Die Schutzfristen müssen entweder global für die gesamte Ablieferung (gleiche Schutzfrist für alle Unterlagen) oder pro Ordnungssystemposition oder pro Dossier in den etadaten festgehalten werden. Empfehlung Es wird empfohlen, die etadaten zu Datenschutz, Klassifizierung und Öffentlichkeitsstatus für Dossiers und Dokumente bereits im GEVER- System zu führen. Auf der Basis dieser Angaben können die Schutzfristen bei der Erstellung eines SIP hergeleitet und direkt in den etadaten verzeichnet werden.

24 E-Government-Standards Seite 24 von etadaten zu den Zeiträumen der Dossiers ID Beschreibung Anforderung /K _ Sobald eine Angabe zu einem Entstehungszeitraum eines Dossiers (etadatum <entstehungszeitraum> in der Entität Dossier) geschätzt wird, ist eine Begründung für diese Schätzung in das etadatum <entstehungszeitraumanmerkung> beim betroffenen Dossier einzutragen etadaten zu den Prüfsummen der Dateien ID Beschreibung Anforderung /K _ Zu jeder Datei im Paket (ausser zur Datei metadata.xml) muss eine Prüfsumme berechnet und in den etadaten zu dieser Datei im metadata.xml eingetragen werden. Dazu stehen die folgenden etadaten in der Entität Datei zur Verfügung: <pruefalgorithmus> : Bezeichnung des bei der Erstellung der Prüfsumme verwendeten Algorithmus. <pruefsumme> : Prüfsummenwert, abhängig vom verwendeten Prüfalgorithmus Als Prüfalgorithmus können folgende Hash-Funktionen verwendet werden: D5 SHA-1 SHA-256 SHA-512

25 E-Government-Standards Seite 25 von Referenzierung der Zugehörigkeit zu Dossiers in den etadaten ID Beschreibung Anforderung /K _ Das etadatum <dateiref> dient dazu, den Zusammenhang zwischen den Dateien im Paket und deren Zugehörigkeit zu den Dokumenten in den Dossiers oder direkt zu einem Dossier herzustellen. Dieser Zusammenhang wird durch die entsprechende Referenzierung der <dateiref> zu der entsprechenden Datei im Inhaltsverzeichnis des metadata.xml festgehalten. Diese Referenzierung ist die eindeutige Zuweisung der Inhalte der Dateien zu den Dossiers. Hinweis: In einem FILES-SIP kann ab der XSD-Version 4.0 eine Datei auch mehreren Dokumenten oder mehreren Dossiers gleichzeitig zugewiesen werden. Diese öglichkeit sollte aber nur aufgrund eines fachlich zwingenden Grunds eingesetzt werden. Beispiel: ehrere Dokumente beschreiben den Inhalt der gleichen Videodatei in aufeinanderfolgenden Abschnitten.

26 5 Struktur SIP E-Government-Standards Seite 26 von Rahmenvorgaben und Begrenzungen Grösse Paket ID Beschreibung Anforderung /K S_5.1-1 Ein SIP darf maximal 8 GB gross sein. S_5.1-2 Empfehlung Es wird empfohlen, aus Gründen der schnelleren Übertragung und Vermittlung, die Grösse eines einzelnen SIP für die Ablieferung unter 2 GB zu halten. Dies kann durch eine regelmässige Ablieferung von Unterlagen an das Archiv und durch eine gute Aussonderungsplanung erreicht werden. Nur in begründeten Ausnahmefällen kann das Archiv ein SIP annehmen, das grösser als 8 GB ist. In diesem Fall muss die abliefernde Stelle vor der Erstellung der Ablieferung und dem Transfer des Paketes mit dem Archiv Kontakt aufnehmen. 5.2 Rahmenvorgaben und Begrenzungen Anzahl Dateien im Paket ID Beschreibung Anforderung /K S_5.2-1 Ein SIP darf nicht mehr als Dateien enthalten. S_5.2-2 Ein einzelner Ordner innerhalb des SIP sollte nicht mehr als 5'000 Dateien enthalten. K Empfehlung Die Anforderung sollte eingehalten werden, weil sonst Probleme mit der Darstellung des SIP auf dem Explorer auftreten können. Falls ein einzelner Ordner mehr als 5000 Dateien enthält, wird empfohlen, Ordner zur weiteren Unterteilung einzufügen. Beispiel Der Ordner d00003/ enthält ursprünglich Dateien.

27 E-Government-Standards Seite 27 von 56 ID Beschreibung Anforderung /K Im Ordner d00003/ werden zwei Ordner eingefügt, und die 9'000 Dateien so darauf verteilt, das kein Ordner mehr als 5'000 Dateien enthält. Die Benennung dieser Ordner ist grundsätzlich frei (hier A/ und B/), sollte aber innerhalb des Ordners d00003/ eindeutig und möglichst kurz gehalten werden, um die Pfadlänge nicht übermässig zu verlängern. 5.3 Erlaubte Zeichen bei der Benennung der Ordner und Dateien In den Namen der Dateien und Ordner darf nur ein begrenzter Satz von Zeichen verwendet werden. Dadurch werden falsche Konvertierungen innerhalb der Namen verhindert, die sonst auftreten könnten, wenn Pakete zwischen unterschiedlichen Betriebssystemen transferiert und verarbeitet werden. ID Beschreibung Anforderung /K S_5.3-1 S_5.3-2 S_5.3-3 Die Vorgaben in Bezug auf den zu verwendenden Zeichensatz zur Benennung von Ordnern und Dateien müssen vollumfänglich eingehalten werden. Der erlaubte Zeichensatz zur Benennung von Ordnern und Dateien ist ein Subset von US-ASCII. Die folgenden Zeichen sind erlaubt: Buchstaben: A-Z a-z Ziffern: 0-9 Andere:! # $ % ( ) +, -. [ ] { } ~_ SPACE Die Zeichencodes der erlaubten Zeichen sind in den Zeichensätzen US- ASCII, ISO-8859 und UTF-8 identisch. Wenn die Namen von Ordnern und Dateien nicht erlaubte Zeichen enthalten, müssen diese vor der Ablieferung an das Archiv normalisiert werden. Empfehlung Im Anhang E finden sich Empfehlungen im Sinne einer Best Practice, die bei der Normalisierung von Namen befolgt werden können.

28 E-Government-Standards Seite 28 von 56 ID Beschreibung Anforderung /K S_5.3-4 Wenn zwei Dateien oder Ordner, die im selben Ordner abgelegt sind, auf denselben Namen normalisiert werden (was eher selten der Fall ist), treten Kollisionen auf. Um diese Kollisionen zu vermeiden, müssen die betroffenen Dateien während oder vor der Normalisierung geeignet ergänzt werden, z. B. durch anhängen eines Suffixes an den Basisnamen. Der ursprüngliche Dateiname muss entsprechend zuvor in den etadaten festgehalten werden und geht dadurch nicht verloren. Beispiel Kollision bei Normalisierung: Geeignete Ergänzung: S_5.3-5 Werden existierende Dateien im Paket bei der Paketerstellung (z. B. aus technischen Gründen) umbenannt, müssen die originalen Dateinamen im etadaten-element originalname in der Entität Datei eingetragen werden. Beispiel Umbenennung Dateiname bei Dateien im Paket Einträge in etadaten-elementen im metadata.xml <dateiname>jaeger.pdf</dateiname> <originalname>jäger.pdf</originalname>

29 E-Government-Standards Seite 29 von Aufbau eines SIP Die Basis des SIP ist eine Datei-Ordner-Struktur. Für diese gibt es sowohl Vorgaben über den Aufbau wie auch für die Benennungskonventionen (Inhalt und Aufbau der Namen) der einzelnen Ordner und Dateien. Als erste Übersicht folgen untenstehend die obersten Ordner eines SIP (Abb. 8). SIP_[Identifikatoren]/ header/ metadata.xml xsd/ arelda.xsd.xsd.xsd content/ Abb. 8: Grundstruktur eines Informationspaketes ID Beschreibung Anforderung /K S_5.4-1 Jedes Paket hat genau einen Toplevel-Ordner. Der Toplevel-Ordner ist der oberste Ordner, der den gesamten Inhalt eines einzelnen Paketes umfasst. Beispiele Der Toplevel-Ordner des Paketes heisst im untenstehenden Beispiel SIP_ _BAFU_uLe.

30 E-Government-Standards Seite 30 von 56 ID Beschreibung Anforderung /K S_5.4-2 Der Name des Toplevel-Ordners beginnt bei einem SIP immer mit der Zeichenfolge SIP_ gefolgt von bestimmten identifizierenden Angaben [Identifikatoren]. Empfehlung Der Name des Toplevel-Ordners soll gemäss dem folgenden uster aufgebaut sein: SIP_ [Ablieferungsdatum] _ [Name der abliefernden Stelle] _ [Referenz] [Ablieferungsdatum]: Aufbau des Ablieferungsdatums: JJJJTT [Name der abliefernden Stelle]: Der Name der abliefernden Stelle wird mit der offiziellen Abkürzung angegeben (z. B. EPA, DEZA, BFS). Wenn keine offizielle Abkürzung vorhanden ist, ist eine kurze, aber sprechende Bezeichnung der abliefernden Stelle zu wählen. [Referenz]: Die Referenz kann durch die abliefernde Stelle optional verwendet werden. Hier kann z. B. das Kürzel des Namens der Kontaktperson bzw. der Datenbank oder die Ablieferungsnummer angegeben werden. Beispiel Dargestellt sind 3 SIP, bei denen je der Toplevel-Ordner sichtbar ist. S_5.4-3 Der Toplevel-Ordner enthält immer genau zwei Ordner. Diese Ordner haben die Namen header/ und content/. Es ist nicht erlaubt, andere Ordner oder Dateien direkt im Toplevel-Ordner zu platzieren. Beispiel Der Inhalt des Toplevel-Ordners sieht bei allen SIP folgendermassen aus:

31 E-Government-Standards Seite 31 von 56 ID Beschreibung Anforderung /K S_5.4-4 Der Ordner header/ enthält die etadaten und deren XSD-Dateien. Der Ordner header/ enthält niemals Primärdaten. Der vordefinierte Ordner im Ordner header/ eines SIP für die Ablieferung heisst: xsd/ Es sind keine weiteren Ordner im Ordner header/ erlaubt. Die vordefinierte Datei im Ordner header/ heisst immer metadata.xml. Diese Datei ist die einzige Datei, die im Ordner header/ erlaubt ist. In dieser Datei werden die etadaten des Paketes gespeichert. Beispiel Der Inhalt des Ordners header/ eines SIP, das abgeliefert wird. S_5.4-5 Alle XSD-Dateien die zur benutzten XSD-Version gehören, werden im Ordner header/ in einem separaten Ordner mit dem Namen xsd/ abgelegt. Beispiel Alle XSD-Dateien für die etadatenversion ARELDA_v4.0 im Ordner xsd/. S_5.4-6 Der Ordner content/ enthält die Primärdaten eines SIP. Das heisst, der Ordner enthält alle Dateien, aus denen sich die Inhalte der Dossiers im SIP zusammensetzen.

32 E-Government-Standards Seite 32 von 56 ID Beschreibung Anforderung /K S_5.4-7 Es wird empfohlen, alle Ordner, die einem Dossier entsprechen, auf demselben Ordnerlevel innerhalb des Ordners /content zu platzieren. K Beispiel Beispiel GEVER Die blau eingefärbten Ordner enthalten je Dateien die zum selben Dossier gehören. Ein Ordner (z. B. d00001) entspricht dabei einem Dossier. content/ d00001/ d00002/ d00003/ d00004/ d00005/ Beispiel FILES Die blau eingefärbten Ordner enthalten je Dateien die zum selben Dossier gehören. Ein Ordner (z. B. Baum_1 entspricht dabei einem Dossier. content/ teil_1/ Baum_1/ Baum_2/ teil_2/ Fisch_1/ Fisch_2/ Fisch_3/ Pfadlängen und Hierarchien im SIP ID Beschreibung Anforderung /K S_5.5-1 Die Pfadlänge zu jeder Datei und zu jedem Ordner innerhalb des Informationspaketes muss weniger als 180 Zeichen betragen. Der Pfad beinhaltet dabei immer auch den Toplevel-Ordner. Auch die / müssen mitgezählt werden. Die Länge des Namens eines Ordners oder einer Datei muss verkürzt werden, wenn der Pfad zu diesem Ordner oder zu dieser Datei über 180 Zeichen lang ist. Die Namen in einem Pfad müssen solange gekürzt werden, bis die Länge des gesamten Pfades weniger als 180 Zeichen beträgt. Beispiel SIP_ _EPA_hp/header/metadata.xml Dieser Pfad besteht aus 39 Zeichen. SIP_ _SBF_hp/content/d /p pdf Dieser Pfad besteht aus 51 Zeichen. SIP_ _BFS_hp/content/orange_zettel/zettel_1.tif Dieser Pfad besteht aus 54 Zeichen.

33 E-Government-Standards Seite 33 von Spezifische Vorgaben zu einem SIP für GEVER Zu den allgemeinen Vorgaben an die Struktur eines SIP gibt es für GEVER SIP noch spezifische Vorgaben, die nur für SIP aus GEVER Systemen gelten. Die Struktur eines SIP aus einem GEVER System ist in Abb. 9 ersichtlich. SIP_ _BFS_hpm/ header/ metadata.xml xsd/ arelda.xsd content/ d00001/ p00001.pdf p00002.txt p00003.tif d00002/ p00004.pdf d00003/ p00005.pdf d00004/ p00006.pdf p00007.tif Abb. 9: Struktur eines GEVER SIP ID Beschreibung Anforderung /K S_5.6-1 Es wird im Sinne eines Best-Practice-Lösungsansatzes empfohlen, dass jedes Dossier und jedes Subdossier in der Ablieferung einem Ordner im Ordner content/ oder tiefer entspricht. K

34 E-Government-Standards Seite 34 von 56 ID Beschreibung Anforderung /K S_5.6-2 Es wird im Sinne eines Best-Practice-Lösungsansatzes empfohlen, dass bei jedem Ordner, der einem Dossier oder einem Subdossier entspricht, die Ordnernamen mit dem Buchstaben d beginnen. Alle Ordner werden mittels einer Laufnummer durchnummeriert. K uster: d n n n d n n n n n n d: ist die Abkürzung für (Sub-)Dossier n: ist ein Integer mit einer innerhalb des Paketes fixen Anzahl Ziffern für die Laufnummer. Nicht benutzte Stellen werden mit einer 0 ausgefüllt. Die maximale Anzahl der Ziffern für die Laufnummer ist 6. Die Laufnummern (aus d und dem Integer) sind als Identifikatoren eindeutig und werden innerhalb des SIP nur einmal vergeben. Beispiel Ein Ordner, der einem Dossier oder einem Subdossier entspricht, wird wie folgt benannt: d n n n n oder d n n n n n n

35 E-Government-Standards Seite 35 von 56 ID Beschreibung Anforderung /K S_5.6-3 Benennung von Dateien innerhalb des Ordners content/: Es wird im Sinne eines Best-Practice-Lösungsansatzes empfohlen, dass bei jeder Datei der Dateiname mit dem Buchstaben p beginnt. Alle Dateien werden mittels einer Laufnummer durchnummeriert. Die originalen Dateinamen sind dabei wie in Anforderung S_5.3-5 beschrieben in den etadaten einzutragen und können auf diese Weise erhalten werden. uster: K p n n n n. [Dateiendung] p n n n n n n. [Dateiendung] p: ist die Abkürzung für (Primär-)Datei. n: ist ein Integer mit einer innerhalb des Paketes fixen Anzahl Ziffern für die Laufnummer. Nicht benutzte Stellen werden mit einer 0 ausgefüllt. Die maximale Anzahl der Ziffern für die Laufnummer ist 6. [Dateiendung]: Die Dateiendung gehört zum Dateinamen. Sie muss nach dem Punkt ebenfalls angegeben werden. Die Laufnummern (aus p und dem Integer) sind als Identifikatoren eindeutig und werden innerhalb des SIP nur einmal vergeben. Beispiel p n n n n n. [Dateiendung] oder p n n n n n n. [Dateiendung]

36 E-Government-Standards Seite 36 von 56 ID Beschreibung Anforderung /K S_5.6-4 Alle Ordner, die Dossiers aus dem GEVER-System entsprechen, sind mit Vorteil auf der obersten Ebene im Ordner content/ verzeichnet. Die Ordnungssystemstruktur sollte nicht in Ordnern abgebildet werden. K Beispiel Oberste Ebene Ordner für Dossiers im Ordner content/. Weitere Ebenen Ordner für Subdossiers Der Ordner d entspricht einem Subdossier.

37 E-Government-Standards Seite 37 von Spezifische Vorgaben zu einem SIP für FILES Zu den allgemeinen Vorgaben an die Struktur eines SIP gibt es für FILES SIP noch spezifische Vorgaben, die nur für SIP aus Datei-Ablagen oder für SIP aus relationalen Datenbanken gelten. Die Struktur eines FILES SIP ist in Abb. 10 ersichtlich. SIP_ _BAK_hanspeter.meier/ header/ metadata.xml xsd/ arelda.xsd content/ Kunstsammlung_eier/ Einfuehrung/ Dokumentation.txt Fruehwerk/ Loewe.tif rote_phase/ Kamel_gross.tif Kamel_klein.tif blaue_phase/ Das_meer.tif dunkelblaue_phase_dezember1867_april1868/ der_ozean.tif ittleres_schaffen/ katze.tif Spaetwerk/ ein_rentier.tif Notizbuecher/ Notizen_2000_2002.tif Abb. 10: Struktur eines FILES SIP ID Beschreibung Anforderung /K S_5.7-1 Die ganze Ordnerstruktur der Primärdaten der Ablieferung ist im Ordner content/ enthalten und abgebildet. Deshalb entsprechen die Ordner im content/ nicht zwingend Dossiers und Subdossiers. S_5.7-2 Empfehlung Es wird im Interesse der Übersichtlichkeit empfohlen, in einem FILES SIP die Ordner, die Dossiers entsprechen, auf einer Hierarchiestufe darzustellen. Für die Benennung von Ordnern und Dateien innerhalb des Ordners content/ gibt es keine inhaltlichen Restriktionen oder Vorgaben. Die Namen der Ordner und Dateien können frei gewählt werden, solange sie den Anforderungen hinsichtlich Zeichensatz und Pfadlänge entsprechen.

38 E-Government-Standards Seite 38 von 56 ID Beschreibung Anforderung /K S_5.7-3 Es ist die Aufgabe der abliefernden Stelle, die Zuordnung zwischen den Dateien im Paket und deren Gruppierung in den Dossiers im metadata.xml herzustellen. Dies geschieht technisch über die <dateiref> im Teil <ablieferung>. Diese referenziert ein <datei>-element im <inhaltsverzeichnis> über das id-attribut. Im <datei>-element sind Angaben zur Datei wie Name und Prüfsumme enthalten. Das <inhaltsverzeichnis> listet alle Ordner und Dateien der Ablieferung auf. Der Pfad einer Datei ergibt sich aus der Position in der Ordnerstruktur im Inhaltsverzeichnis. (Vgl. dazu Abb. 11). Abb. 11: Struktur eines FILES SIP Referenzierung der Datei aus dem Dossier zur Dateibeschreibung im Inhaltsverzeichnis 5.7 Aufbau eines FILES SIP mit integrierter Dokumentation Ein SIP einer Ablieferung mit Archivgut aus einer relationalen Datenbank oder aus einer Fachapplikation ist grundsätzlich ein SIP mit einer SIP Struktur für FILES Ablieferungen. Es gelten für ein solches SIP allerdings noch weitere spezifische Vorgaben. Vor allem ist es wichtig, dass das System, aus dem die Daten stammen (Datenbank oder Fachapplikation), in einer Dokumentation beschrieben wird.