* Intro NAT

Intro MB ARIADNE ARCHIVE INFORMATION & ADMINISTRATION NETWORK Der Einsatz eines Redaktionssystems im ARIADNE – Verbund Mecklenburg - Vorpommern

Überarbeiten Bergen Carbäk

Ariadne Überblick Überblick ARIADNE Das ARIADNE-System ist eine Anwendung zur Verzeichnung von Archivbeständen und deren Recherche in lokalen Netzen wie auch im Internet Das ARIADNE-System wird am Universitätsarchiv Greifswald entwickelt und das Projekt durch die Deutsche Forschungsgemeinschaft DFG gefördert. Das Ziel des Projektes ist die Schaffung eines virtuellen Archivverbundes für Mecklenburg-Vorpommern mit einem gemeinsamen Internetportal Derzeit sind 14 Archive des Landes Mecklenburg-Vorpommern mit ARIADNE ausgestattet. Davon sind 7 Archive mit ca. 160.000 Akteneinheiten online. Das Portal ist unter der Adresse http://ariadne.uni-greifswald.de im Internet zu finden.

Heirarchischer Aufbau ARIADNE-Archivverbund mit den Ebenen : regionale Archive, deren zentraler Bestandsnachweis, den jeweiligen Einzelbeständen, mit und ohne Klassifikation und Akteneinheiten innerhalb eines Bestandes. Aktengattungen sind Sachakten, Personalakten, Urkunden sowie Karten, Risse und Pläne.

Technischer Aufbau Technischer Aufbau des ARIADNE-Systems Zentraler ARIADNE-Server am Rechenzentrum der Universität Greifswald, Regionale Archive mit lokalen Netzwerk und der ARIADNE Administrations- bzw. Verzeichnungssoftware, ARIADNE-Recherchewerk-zeuge für der Internetbereich.

Internetrecherche Ariadne Server Internetrecherche über den zentralen ARIADNE-Server Der Server hält die Archivdaten in einer zentralen MySQL-Datenbank. Der Server stellt ein WEB-Portal zur Verfügung welches via PHP dynamische HTML Seiten erzeugt. Der externe Nutzer greift auf die Internetadresse des WEB-Portals zu http://ariadne.uni-greifswald.de. Die vom Server generierten Seiten erlauben es ihm in den freigestellten Archivbeständen zu recherchieren.

Administrativer Teil Ariadne Zusammenspiel regionaler Archive mit dem zentralen ARIADNE-Server Die Archive verzeichnen ihre Daten mit der ARIADNE- Administrationssoftware und stellen anschließend Bestände frei. Die Administrationssoftware speichert die Daten konform zu den Datenstrukturen auf dem zentralen Server. Die Daten werden verschlüsselt über ein Protokoll zum Server übertragen und in der Verbund- datenbank gespeichert.

* Grundlagen der Implemetierung Grundlagen der Implementierung Betriebsysteme: 32Bit – Windows Systeme der Fa. MICROSOFT sowie alle LINUX Betriebsysteme mit einem Kylix fähigen Kernel. Internetserver: Als Internetserver wird derzeit der Apacheserver ver-wendet. Dieser Server läuft auf Linux wie auch auf Windows-Systemen. SQL-Datenbank: Als Hintergrunddatenbank wird MySQL verwendet diese Datenbank ist ebenfalls als Freeware und für Linux wie Windows erhältlich. Die Verwendung eines ODBC-Treibers ist nicht notwendig. Entwicklungsumgebung: Als Entwicklungsumgebung wird Delphi für Windows bzw. Kylix für Linux verwendet. Alle zusätzlichen Ressource und Komponenten besitzen ebenfalls OpenSource-Status.

* Ausblick NAT Ausblick Die steigende Zahl regionaler Archivportale in Deutschland, deutet auf eine Entwicklung der Archive hin zum Informationsdienstleister an. Das bedeutet eine erhebliche Ausweitung des Nutzerkreises für archivische Findhilfsmittel. Dabei erscheint es sinnvoll, daß sich die Anbieter von elektronischen, datenbank- gestützten Findhilfsmitteln auf ein Protokoll einigen, welches es gestattet Daten, unterschiedlicher Herkunft für die Online-Recherche nachvollziehbar bereitzustellen. Lösungsansätze und Modelle für diesen Weg, wie etwa der die „Encoded Archival Description (EAD)“ der Online-Archive Kaliforniens oder das „Open Archive Initiative – Protocol for Metadate Harvesting (OAI-PMH)“ existieren bereits. Bei der im deutschen Archivwesen praktizierten normierten Verzeichnung, die sich zwangsläufig in den online-fähigen Repertorien abbildet, wäre ein Gesamtportal, welches übergreifende Abfragen in allen angeschlossenen Einzelarchiven und Verbünden zuließe, über ein solches Protokoll realisierbar, ohne daß die Beteiligten auf eigenständige Entwicklungen verzichten müßten.

Lokale Installation Installation im Archiv - Das Installationsmodul - Für die Funktionsfähigkeit des Installationsmodul wird vorausgesetzt, daß der MySQL-Server bereits installiert ist und über mindestens einen Administrator-zugang verfügt.   - Zuerst wird eine Datenbank unter MySQL angelegt, welche die Struktur von Ariadne aufnehmen wird. - Danach werden die Standard-Einstellungen von Ariadne in den Konfigurationstabellen gespeichert. Dabei werden auch Informationen über das Archiv abgelegt, welches Ariadne einsetzen möchte. - Nun werden die Benutzergruppen und Benutzer in Ariadne angelegt, die später Zugriff auf die Software haben sollen. Dabei wird stets der Benutzer "Gast" angelegt.

Benutzermodell Das Benutzermodell von ARIADNE - Die Mitarbeiter eines Archivs werden unter Ariadne durch Benutzer repräsentiert, die zu Benutzergruppen zusammen gefaßt werden. Dabei kann jeder Benutzer nur einer Benutzergruppe und jede Benutzergruppe nur einem Archiv zugeordnet werden. - Jeder Benutzer wird nach seinen Rechten in Ariadne klassifiziert: 1. Gast: Dieser Benutzer darf nur Informationen einsehen. Diese müssen vorher durch einen Archivar freigestellt worden sein. 2. User: Hierbei handelt es sich um Archivare, die Bestände verwalten und verzeichnen sollen. Sie können an den Daten, die von ihnen oder von Benutzern ihrer Gruppe erstellt wurden, jede beliebige Manipulation durchführen. 3. Admin: Das ist ein Benutzer, der alle Rechte in dem Archiv hat, dem er zuge- wiesen ist. Dadurch kann er auch sensible Arbeiten durchführen, wie ein Export oder Backup der Datenbank.

Bestandsinfo Recherche Bestandsinformation der Rechercheapplikation Basiert auf einer Liste aller erfaßten Bestände und deren Detailinformationen. Es ist die Suche in den Bestandsbildnerangaben möglich. Ein Überblick zu vorhandenen Aktengruppen wie Ordnungsschemata bzw. Bestandsgliederungen werden aufgezeigt.

Volltextrecherche Volltextsuche der Rechercheapplikation Die Volltextsuche wird auf der Ebene von Aktentiteln und Enthältvermerken vollzogen. Die Suchen wird relational, also mit Platzhaltern und Varianten realisiert (reguläre Ausdrücke). Weiterhin ist eine Verknüpfung von Stichworten möglich.  Die Summe der Treffer wird nach Aktentypen abgelegt.

Selektive Suche Selektive Suche der Rechercheapplikation Die Selektive Suche erfolgt auf der Ebene der Bestands-informationen und Ordungsschemata nach Stichworten. Die Suchen wird relational, also mit Platzhaltern und Varianten realisiert (reguläre Ausdrücke).  Die Summe der Treffer wird sortiert nach Beständen und Aktengruppen abgelegt.  Dies gestattet eine komplexe und provenienz- orientierte Suche.

Treffermengenanalyse Treffermengenanalyse der Rechercheapplikation Volltextsuche Die Volltextsuche zielt auf den thematischen Betreff. Selektive Suche Die selektive Suche zielt den Überlieferungszusammenhang. Es entstehen unterschiedliche Treffermengen. Treffermenge und Treffergenauigkeit sind abhängig von der Erschließungstiefe.

Bestandverwaltung Verzeichnung Bestandsverwaltung der Verzeichnungsapplikation Die Bestandsverwaltung dient der Pflege des Bestandsnachweises. Die Bestandsverwaltung ermöglicht die Abbildung des Bestandes auf die Tektonik. Dabei werden technische Daten der Bestände erfaßt. Die Bestandsbildnerinformationen werden gesammelt. Der Bearbeitungsstand der Bestände wird dokumentiert.

Bestandsbearbeitung Verzeichnung Bestandsbearbeitung der Verzeichnungsapplikation In dieser Applikation werden Bestände in der Datenbank angelegt und sämtliche bestands- und aktentypenbezogenen Masken und Formulare erzeugt. Dabei kann je Bestand ein Ordungsschema festgelegt werden. Die Akten der Bestände können verzeichnet werden. Die Erzeugung eines Findbuches ist möglich.

Transfer ACCESS Transfer auf den Verbundserver - aktuelle Variante - Zuerst muß durch einen Admin ein Export der freigestellten Daten initiiert werden. Die Daten werden auf der Festplatte als Text-Datei gespeichert, die direkt in die MySQL-Konsole geleitet werden kann. - Diese Datei wird nun via eMail, Datenträger oder FTP-Transfer auf den Verbundserver übertragen. - Dort werden die Daten in den MySQL-Server importiert und durch ein Import-Modul in die Verbundstruktur eingefügt.

Internet-Recherche aktuell Internet-Recherche - aktuelle Variante - Die Recherche erfolgt stets archiv- und bestandsübergreifend auf dem Verbundserver. Es werden momentan nur freigestellte Informationen durchsucht. - Der Benutzer kann am Anfang zwischen vier Recherche-Strategien wählen, die analog zur lokalen Recherche im Archiv realisiert sind. Sie umfassen eine Recherche in der Tektonik, in der Klassifikation und in den einzelnen Akten. - Wird eine Anfrage abgeschickt, so wird der Verbundserver durch die PHP-Skripte nach relevanten Datensätzen durchsucht. Die Suchergebnisse werden dann durch HTML-Seiten präsentiert, die stets dynamisch durch PHP erzeugt werden.

Internet-Recherche Entwicklung Internet-Recherche – Entwicklungsaufgaben Internet-Recherche wird momentan stets im „Gast-Modus“durchgeführt Problem: Archive haben jedoch nicht die Möglichkeit, via Internet komplett in den eigenen Beständen zu recherchieren. - Lösung: Übertragen des lokalen Benutzermodells auf den Verbundserver Die Zugriffsrechte auf die Archive werden strikt getrennt

Ariadne als OpenSource-Projekt Seit September 2002 erfolgt in einer Zusammenarbeit mit der DFG eine Überarbeitung des gesamten bestehenden Projektes. Ziel der Überarbeitung ist es, die ursprünglich rein MS-Access und MS-VBA basierte Anwendungen in eine OpenSource-Software zu überführen. Als Zielbetriebssysteme sollen weiterhin die 32-Bit Windowsbetriebssysteme LINUX bedient werden. Als Teilkomponenten, welche den OpenSource Anforderungen genügen und für beide Betriebsystemplattformen verfügbar sind, wurden der Internetserver Apache, die SQL-Datenbank MySQL, zur Erzeugung dynamischer HTML Seiten PHP, für Austausch-formate XML und als Entwicklungsumgebung Delphi/Kylix gewählt. Die Entwicklung erfolgt weiterhin konsequent in zwei Anwendungsgruppen: - Anwendungen der zentralen Verbunddatenbank.- Internetredaktion - und die lokalen archivbezogenen Anwendungsimplementierung.

Anwendungen der zentralen Verbunddatenbank Die Anwendungen der zentralen Verbunddatenbank bedienen 3 Aufgabenbereiche: Die Software zur Archivverbundverwaltung realisiert die Registrierung der Verbundpartner und die Bereitstellung der Softwareinstallation, die Nutzerverwaltung der angeschlossenen Archive (Transferpasswörter) sowie Datenimport, -pflege und –backup. Die zentrale Verbunddatenbank hält die Daten in der MySQL-Datenbank realisiert das Archivportal via Apache-Internetserver und stellt die PHP-Skripte zur Recherche in den freigestellten Archivbeständen. Der zentrale Softwareserver zur Offenlegung der Quelltexte, zur Verwaltung von Anwendungsversionen und Fehlervarianten (Bugtracking) und die Verlinkung zu Internetseiten verwendeter Fremdkomponenten.

Protokoll zur Anwendungsinstallation eines Verbundpartners -Übersicht Die Anwendungsinstallation eines Verbundpartners erfolgt in 3 Schritten: Anmeldung und Registrierung eines potentiellen Teilnehmers auf dem Verbundserver Softwareinstallation im Archiv und Bestätigung dieser Installation Erster Datentransfer, Rückgabe der der Schlüsseltabelle und Freigabe des Archivs im Internet

Archivregistrierung und Softwareinstallation - Anmeldung

Archivregistrierung und Softwareinstallation - Installation

Archivregistrierung und Softwareinstallation – Datentransfer

Das XML-Austauschformat - Übersicht 1. Das ARIADNE Austauschformat ist ein XML -Austauschformat mit vollständig eingebetteter DTD und einer HTML 4.0 Standardbehandlung für Sonderzeichen 2. Die Datei ist als XML Kode Version 1.0 deklariert und enthält in einem Kommentar die Kopierrechte. Der festgelegte Dokumenttyp ist AriadneDB. <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!-- XML-CODE ARIADNE DATABASE TRANSFERFILE VERSION 1 (c) - 2003 Ariadne Workgroup University of Greifswald, GERMANY --> <!DOCTYPE AriadneDB [...]> 3. Das Datenformat ist nicht direkt auf Ariadne ausgerichtet und benötigt keine feldspezifischen Tags. Die Tabellendefinitionen wie auch die Archivkennung werden daher in einem Datenbankheader <Header> </Header> übertragen, welcher alle Informationen enthält. 4. Die eigentlichen Informationen werden dann im Tagblock <Datas></Datas> übertragen.

Die DTD des XML-Austauschformats - Übersicht Blöcke Die DTD gliedert sich wie folgt : Dokumentdeklaration Sonderzeichen Headerdeklaration Deklaration der Dateninhalte Es werden dabei folgende Hauptblöcke definiert: den Dokument-"Container" <Database> Dokument ... </Database> , den Datenbankdefinitions- und Identifikationsteil <Header> Nutzer-, Archiv-, Datenbank- und Tabelleninformationen ... </Header> und den Dokumentenbereich welcher, die Tabelleninhalte defniert <Datas> <Table> </Table>, <Table> </Table> ... </Datas> Es werden die Sonderzeichen für den HTML4 Standard eingebettet und binäre Dateninhalte hexadezimal blockweise kodiert.. Basiselement des Dokumentes <!ELEMENT Database (Header?, Datas?) >

Das XML-Austauschformat – XML-Tags des Headers 1. <!ELEMENT Header ( Author?, ArchiveIdent?, ArchiveKey?, ArchiveName?, Tables?, TableDef+, BackupType?, Timestamp? ) > Archividentifikation und Tabellendefinition 1.1 <!ELEMENT Author (#PCDATA) > Erzeuger der Datei 1.2 <!ELEMENT ArchiveIdent (#PCDATA) > Versendendes Archiv 1.3 <!ELEMENT ArchiveKey (#PCDATA) > Installationsschlüssel des Archivs 1.4 <!ELEMENT ArchiveName (#PCDATA) > Name des Archivs 1.5 <!ELEMENT BackupType (#PCDATA) > Backuptyp (vollständig oder inkrementell) 1.6 <!ELEMENT Timestamp (#PCDATA) > Zeitmarke des Backups 1.7 <!ELEMENT TableDef (Name?, Type?, FieldDefs?, KeyDefs?, SQLCode?) > Tabellendefinitionsblöcke und deren Elemente 1.8 <!ELEMENT FieldDefs ( L+ ) > Tabellendefinition nach C-API 1.9 <!ELEMENT KeyDefs ( L+ ) > Indexdefinition nach C-API 1.10 <!ELEMENT SQLCode ( L+ ) > Tabellendefinition als SQL Kode. 1.11 <!ELEMENT Tables ( L+) > Tabellenliste Allgemein <!ELEMENT L (#PCDATA) > Code für eine Zeile

XML - Beispiel für Headerinformationen <Author>root@UAG</Author> Informationen zur Archividentifikation <ArchiveName>Universitätsarchiv Greifswald</ArchiveName> <ArchiveIdent>1</ArchiveIdent> <ArciveKey>012345678901234567890123456789</ArciveKey> <Timestamp>05/03/2003-12:33</Timestamp> <BackupType>FULL</BackupType> <Tables> Liste aller Tabellen <L>archive</L> ... weitere Tabelleneinträge </Tables> <TableDef> Erste Tabelledefinition <Name>archive</Name> <Type>ISAM</Type> <FieldDefs> ... Felddefinitionen </FieldDefs> <KeyDefs> ... Indexdefinitionen </KeyDefs> <SQLCode> ... SQL Feldefinitionszeilen, ... SQL Indexdefintionen </SQLCode> </TableDef> ...weiter Tebellendefinitionen </Header>

Das XML-Austauschformat – DTD für Dateninhalte 2. <!ELEMENT Datas ( Table+ ) > Markierung Datenblock zur Abgrenzung vom Header 2.1 <!ELEMENT Table ( Name?, Records?, Row+ ) > Öffne neue Tabelle 2.1.1 <!ELEMENT Name (#PCDATA) > Tabellenname 2.1.2 <!ELEMENT Records (#PCDATA) > Anzahl der Records 2.1.3 <!ELEMENT Row ( L+ ) > Neue Spalte Allgemein <!ELEMENT L (#PCDATA) > Zeile - Feldnummer, Feldinhalt <Datas> ... ein Beispiel <Table> <Name>archive</Name> Tabellenname <Records>8</Records> <Row> <L>0, 1</L> <L>1, "Universitätsarchiv Greifswald"</L> <L>2, "Greifswald"</L> <L>4, 0</L> <L>5, "03834-861155"</L> <L>6, "Dr. Alvermann"</L> </Row> ... weitere Zeilen </Table> ... weitere Tabellen </Datas>

* Die DTD - Tabellendefinition <TableDef> </TableDef> . Das Tag <TableDef></TableDef> enthält die Felddefinitionen und in die Feldindi- zierungen der Tabelle, welche durch den Tag <Name></Name> innerhalb des Blockes definiert wird. Das Tag <Type></Type> dient tabellenspezifischen Informationen und wird derzeit nicht ausgewertet. Es werden 3 Definitionsblöcke erzeugt: <FieldDefs></FieldDefs> für Felddefinitionen die konform zu den Datenstrukturen MySQL-API abgelegt sind. Die mit dem Tag <L></L> abgelegten Einträge stellen die Spaltendefinitionen der Tabelle dar. Feldeintrag ist im Aufbau an den MYSQL-API Definitionen orientiert und steht kommasepariert in einer Zeile. Zusätzlich müssen die Feldindizes deklariert werden das geschieht im Block <KeyDefs></KeyDefs> Die ebenfalls mit dem Tag <L></L> abgelegten Einträge enthalten die durch den Indexnamen referenzierten Spaltenindex. Neben diesen beiden Blöcken wird ein Block mit der vollständigen Zeilen entsprechend einer CREATE TABLE oder ALTER TABLE SQL-Anweisung abgelegt. Das geschieht im Block <SQLCode></SQLCode>

* Die DTD - Tabellendefinition Beispiel <TableDef> <Name>archive</Name> <Type>ISAM</Type> <FieldDefs> <L> 0,ArchivID,INT,11,0,0,[],[AEN],"AUTO_INCREMENT","";</L> <L> 1,Archivname,VARCHAR,0,0,100,[],[N],"","''";</L> <L> 2,Standort,VARCHAR,0,0,100,[],[],"","";</L> ... </FieldDefs> <KeyDefs> <L>PRIMARY,ArchivID,1,[P];</L> <L>Archivname,Archivname,1,[U];</L> </KeyDefs> <SQLCode> <L>ArchivID INT(11) NOT NULL AUTO_INCREMENT</L> <L>Archivname VARCHAR(100) NOT NULL DEFAULT ''</L> <L>Standort VARCHAR(100) DEFAULT NULL</L> <L>PRIMARY KEY(ArchivID)</L> <L>UNIQUE KEY Archivname (Archivname)</L> </SQLCode> </TableDef>

* Die DTD – Kodierung der Tabellendefinitionen Die Kodierung der einer <TableDef > - Zeile ergibt sich wie folgt: <L> Feldnummer, Feldname, Feldtyp, Dezimalstellen, Nachkommastellen, Feldgröße, [Aufzählungsstring], [Feldoptionen], Extrastring, Standardeintrag </L> Feldnummer - Die Feldnummer entspricht der Spaltennummer des Feldes in der Datentabelle. Feldname - Spaltenname des Feldes. Feldtyp - Datentyp der jeweiligen Spalte mit folgenden Typendefinitionen. NULL/ TINYINT, SMALLINT, MEDIUMINT, INTEGER, BIGINT/ DECIMAL, FLOAT, DOUBLE/ CHAR ,VARCHAR / TIME, DATE, DATETIME, TIMESTAMP, YEAR/ TINYTEXT, MEDIUMTEXT, TEXT, LONGTEXT/ TINYBLOB, MEDIUMBLOB, BLOB, LONGBLOB/ ENUM, SET / Dezimalstellen - Anzahl der Dezimalstellen einer Ganzenzahl oder eine reelwertigen Zahl. Nachkommastellen - reellwertiger Zahlen. Feldgröße - Feldlänge für Charakter und Textwerte. Aufzählungsstring - Aufzählungsstring für ein Feld vom Typ ENUM oder SET z.B. ['Y','N']. Feldoptionen - Es sind folgende Feldoptionen [ABEUN0] möglich und gelten für bestimmt Feldtypen. A - Automatisch inkrementelles Feld./ B - Das Feld ist binär kodiert./ E - Das Feld besitz Extrainformationen siehe ExtraString. U - Das Feld wird als vorzeichenlose Zahl interpretiert./ N - Das Feld darf nicht leer sein./ Z - Feld mit Nullen auffüllen. Extrastring - Eintrag korrespondierend mit dem Feldoptionsflag [E] Standardeintrag - gibt an ob mit welchem Feldinhalt das Feld gefüllt werden soll. Beispiel: <FieldDefs> <L> 0,UID,INT,11,0,0,[],[AEN],"AUTO_INCREMENT","";</L> .. weitere Spaltendefinitionen </FieldDefs>

* Die DTD – Kodierung der Indexinformation Der Block <KeyDefs></KeyDefs>. enthält die Indizierungsinformationen der Datentabelle und wird kommasepariert in einer Zeile wie folgt abgelegt.: <L> Indexname, Spaltenname,Spaltennummer,Schlüsseltyp </L> Indexname ist der Name des verwendeten Schlüssels, für Primärschlüssel wird PRIMARY verwendet. Spaltenname ist der Name der Spalte auf welchen der Index gesetzt ist. Spaltennummer wird zur Referenzierung der Position von Mehrfachindizes verwendet. Ansonsten ist diese Nummer immer 1. Es existieren folgende Schlüsseltypen F – Volltextindex M - Mehrfachschlüssel hier müssen die Indizes über die Indexnummer zusammengesetzt werden. P - Primärschlüssel U - In der Spalte dürfen Dateneinträge nicht doppelt vorhanden sein. Beispiel: <KeyDefs> <L>PRIMARY,UID,1,[P];</L> <L>Username,Username,1,[U];</L> </KeyDefs>

Delphi/Kylix Fremdkomponenten

Überblick über online-Recherche Unterschiede der aktuellen Archivinformationssysteme Ablageform der Datenbasis: - Recherche auf statischen Seiten Vertreter: TUSTEP/ARTUS, Midosa (ohne MySQL, PHP), DACHS-A (?) kurze Ladezeiten aufgrund schlanker HTML-Seiten ReExport notwendig, wenn die Datenbasis bearbeitet wurde - Recherche auf Datenbanken (dynamisch) Vertreter: ARIADNE, Augias, FAUST, HADIS, MidosaOnline Funktionalität/Leistungsspektrum: die Lösungen unterscheiden sich bzgl. ihrer Suchbreite (archiv- /bestandsübergreifend), ihrer Suchtiefe (Tektonik, Klassifikation, Akte) und ihrer Recherchealgorithmen (Volltext- suche, selektive Suche)

Ausblick Ausblick Die steigende Zahl regionaler Archivportale in Deutschland, deutet auf eine Entwicklung der Archive hin zum Informationsdienstleister an. Das bedeutet eine erhebliche Ausweitung des Nutzerkreises für archivische Findhilfsmittel. Dabei erscheint es sinnvoll, daß sich die Anbieter von elektronischen, datenbank- gestützten Findhilfsmitteln auf ein Protokoll einigen, welches es gestattet Daten, unterschiedlicher Herkunft für die Online-Recherche nachvollziehbar bereitzustellen. Lösungsansätze und Modelle für diesen Weg, wie etwa der die „Encoded Archival Description (EAD)“ der Online-Archive Kaliforniens oder das „Open Archive Initiative – Protocol for Metadate Harvesting (OAI-PMH)“ existieren bereits. Bei der im deutschen Archivwesen praktizierten normierten Verzeichnung, die sich zwangsläufig in den online-fähigen Repertorien abbildet, wäre ein Gesamtportal, welches übergreifende Abfragen in allen angeschlossenen Einzelarchiven und Verbünden zuließe, über ein solches Protokoll realisierbar, ohne daß die Beteiligten auf eigenständige Entwicklungen verzichten müßten.

OAI