Papyrus Portal - Index of
Werbung
Papyrus Portal Umsetzung einer Portallösung für alle Papyrussammlungen in Deutschland von Stefan Freitag (Uni Leipzig) Marius Gerhardt (Uni Leipzig) Jens Kupferschmidt (Uni Leipzig) Prof. Reinhold Scholl (Uni Leipzig) Leipzig, 08/04/2017 Version 1.1.1 Abstrakt Das 'Papyrus Portal' ist ein Projekt, das dem Nutzer eine effiziente Suche durch alle digitalisierten und elektronisch katalogisierten Papyrussammlungen Deutschlands und eine einheitliche Präsentation der Suchergebnisse mit den wichtigsten Informationen zu einem Papyrus ermöglicht. Außerdem wird auf die umfangreicheren und detaillierten Daten der Originaldatenbanken verlinkt. Die inhaltlichen und informationstechnologischen Unterschiede in den einzelnen Datenbanken auszugleichen, ist eine wesentliche Aufgabe des 'Papyrus Portals'. Dafür wurden ein Standard für die Erschließungskategorien und Festlegungen für Metadaten geschaffen. Das 'Papyrus Portal' ist kompatibel mit dem Advanced Papyrological Information System (APIS) und anderen Metadatenbanken. Unter Verwendung der Open Source Software 'MyCoRe' und aufbauend auf den Erfahrungen im 'Papyrusprojekt HalleJena-Leipzig' fand der Aufbau des 'Papyrus Portal' mit der finanziellen Unterstützung der Deutschen Forschungsgemeinschaft statt. Die vorliegende Dokumentation gliedert sich in folgende Teile: Allgemeine Projektbeschreibung und Anleitung zur Benutzung des Systems Beschreibung der inhaltlichen und informationstechnischen Umsetzung mit MyCoRe in Verbindung zu anderen Datenbanken Version 1.1.1 2 Änderungen Version 1.0.0 1.0.1 1.0.2 Datum 09.08.2007 20.11.2007 22.01.2008 1.0.3 25.07.2008 1.0.4 1.0.5 1.1.0 1.1.1 24.09.2008 01.10.2008 10.10.2008 13.10.2008 Version 1.1.1 Autor Jens Kupferschmidt, URZ der Uni Leipzig Jens Kupferschmidt, URZ der Uni Leipzig Jens Kupferschmidt, URZ der Uni Leipzig Stefan Freitag, UBL Marius Gerhardt, UBL Stefan Freitag, UBL Marius Gerhardt, UBL Marius Gerhardt, UBL Stefan Freitag, UBL Stefan Freitag, UBL Marius Gerhardt, UBL Stefan Freitag, UBL 3 Abkürzungen Kürzel Erläuterung ACL Access Control List – eine Technologie für die Zugriffskontrolle auf Daten. API Application Programming Interface – eine allgemeine Bezeichnung der Programmierschnittstellen in einem Projekt. HSQLDB Dies ist eine zu 100% in Java geschriebene SQL-Datenbank. ID Identifikator, eine eindeutige Marke JAVA Eine objektorientierte, weit verbreitete Programmiersprache. JDBC Java Database Connectivity – eine Schnittstelle zum einheitlichen Zugriff auf relationale Datenbanken. Jetty Ein Servlet-Engine-Produkt. SQL Structured Query Language – eine vereinheitlichte Abfragesprache für relationale Datenbanken. UBL Universitätsbibliothek Leipzig URZ Universitätsrechenzentrum der Universität Leipzig XML Extensible Markup Language – ein Standard zur Notation von Daten. XPath Ein Standard zum Zugriff auf XML-Daten. XSLT Extensible Stylesheet Language for Transformation Beschreibungssprache zur Transformation von XML Daten. Version 1.1.1 – eine 4 Inhaltsverzeichnis 1 Projektbeschreibung und Benutzeranleitung ........................................................................... 7 1.1 Allgemeiner Stand der digitalisierten Papyrussammlungen in Deutschland .................... 7 1.2 Das 'Papyrus Portal' als virtuelle Zusammenführung der Sammlungen ........................... 8 1.3 Benutzung des 'Papyrus Portals'........................................................................................ 8 1.3.1 Aufbau der Homepage ................................................................................................ 8 1.3.1.1 Allgemeines .......................................................................................................... 8 1.3.1.2 Die Kurzbeschreibungen der teilnehmenden Sammlungen ................................. 9 1.3.2 Die Recherche........................................................................................................... 10 1.3.2.1 Die Suche in den Klassifikationsfeldern ............................................................ 10 1.3.2.2 Die Suche in den restlichen Feldern ................................................................... 10 1.3.2.3 Die Datumssuche................................................................................................ 11 1.3.2.4 Beispielsuchen .................................................................................................... 11 2 Technische und inhaltliche Umsetzung................................................................................. 12 2.1 Allgemeine Voraussetzungen und Ausgangslage ........................................................... 12 2.2 Die Portallösung .............................................................................................................. 14 2.3 Allgemeines zu MyCoRe ................................................................................................ 15 2.4 Zugriff auf die Datenbanken ........................................................................................... 16 2.4.1 Beteiligte Einrichtungen und ihre Anbindung .......................................................... 17 2.5 Die Client-Software ........................................................................................................ 17 2.5.1 Der Client ................................................................................................................. 17 2.5.2 Möglichkeiten und Grenzen des Clients ................................................................... 18 2.6 Felder der Suche und der Trefferliste im Portal .............................................................. 19 2.6.1 Inventarnummern (Port01) ....................................................................................... 19 2.6.2 Sammlung (Port02)................................................................................................... 20 2.6.3 Sprache (Port03) ....................................................................................................... 20 2.6.4 Textart (Port04) ........................................................................................................ 20 2.6.5 Titel (Port05) ............................................................................................................ 20 2.6.6 Datierung (Port06a und 06b) .................................................................................... 20 2.6.7 Herkunft (Port07 und 08) ......................................................................................... 21 2.6.8 Material (Port09) ...................................................................................................... 21 2.6.9 Inhalt (Port10)........................................................................................................... 21 2.6.10 Publikationsnummer (Port11)................................................................................. 21 2.6.11 Statischer Link (Port12).......................................................................................... 21 2.6.12 Weitere Links (Port13) ........................................................................................... 21 2.6.13 Freitext (Port14) ..................................................................................................... 22 2.6.14 Datum Erwerbung (Port 15) ................................................................................... 22 2.6.15 Text Erwerbung (Port16) ........................................................................................ 22 2.7 Mapping der Metadaten .................................................................................................. 22 2.8 Harmonisierung ............................................................................................................... 24 2.9 Korrekturen und Konkordanzen...................................................................................... 24 2.9.1 Konkordanz zur Klassifikationsliste des Materials .................................................. 25 2.9.2 Konkordanz zur Klassifikationsliste der Textart ...................................................... 25 2.9.3 Konkordanz zur Klassifikationsliste der Sprache ..................................................... 25 2.9.4 Konkordanz zur Klassifikationsliste des Ortes ......................................................... 25 2.9.5 Konkordanz zur Klassifikationsliste des Gaues ....................................................... 26 2.10 Klassifikationen ........................................................................................................... 26 2.10.1 Teilnehmende Sammlungen ................................................................................... 27 2.10.2 Klassifikationsliste Sprache .................................................................................... 27 2.10.3 Klassifikationsliste Textart ..................................................................................... 28 2.10.4 Klassifikationslisten Herkunft ................................................................................ 28 2.10.4.1 Klassifikationsliste Herkunft Gau .................................................................... 28 Version 1.1.1 5 2.10.4.2 Klassifikationsliste Herkunft Ort ..................................................................... 30 2.10.5 Klassifikationsliste Material ................................................................................... 34 3 Glossar ................................................................................................................................... 35 4 Anhang .................................................................................................................................. 36 4.1 Projektbeteiligte .............................................................................................................. 36 4.1.1 Projektleitung............................................................................................................ 36 4.1.2 Mitarbeiter ................................................................................................................ 36 4.1.3 Design ....................................................................................................................... 36 4.1.4 Hilfskräfte ................................................................................................................. 36 4.1.5 Antragsteller ............................................................................................................. 37 4.2 Checkliste für momentane und zukünftige Teilnehmer am 'Papyrus Portal' .................. 38 4.3 Client Dokumentation ..................................................................................................... 39 4.3.1 Zusammenfassung .................................................................................................... 39 4.3.2 Installation des Clients.............................................................................................. 39 4.3.3 Einstellungen der Filemaker-Datenbank .................................................................. 39 4.3.4 Konfiguration des Clients ......................................................................................... 40 4.3.5 Starten des Clients .................................................................................................... 41 4.3.6 Technische Informationen ........................................................................................ 41 4.3.6.1 Zuweisung von Feldern aus der Datenbank ....................................................... 41 4.3.6.2 Einstellen der Suchschärfe ................................................................................. 42 4.3.7 Die Properties-Datei ................................................................................................. 43 4.3.8 Datenanbindung zwischen Client und Portal............................................................ 43 4.3.9 Datenbankzugriffe .................................................................................................... 43 Version 1.1.1 6 1 Projektbeschreibung und Benutzeranleitung 1.1 Allgemeiner Stand der digitalisierten Papyrussammlungen in Deutschland Einige deutsche Papyrussammlungen haben ihre Bestände bereits digitalisiert und elektronische und im Internet benutzbare Kataloge angefertigt. So ist es möglich, die Papyri in Heidelberg, Köln, Trier, Bonn, Giessen, Halle, Jena, Leipzig und Würzburg zu durchsuchen. Einige der genannten Sammlungen haben ihre Katalogisierung und Digitalisierung noch nicht abgeschlossen, andere wie z.B. Bonn haben gerade erst begonnen. Schließlich wird auch Deutschlands größte Papyrussammlung, in Berlin, in naher Zukunft damit beginnen, ihre Bestände zu digitalisieren und elektronische Kataloge im Internet zur Verfügung zu stellen. Die Projekte zur Digitalisierung und elektronischen Katalogisierung fanden in den letzten beiden Dekaden statt, was zur Folge hat, daß sie mit verschiedenen Entwicklungsstufen geeigneter Software konfrontiert waren. So entwickelten sich auch verschiedene Lösungen, um die jeweilige Papyrussammlung im Internet zu präsentieren. In Giessen wurde mit Allegro C (Hans) eine Katalogisierungsoftware für Bibliotheken verwendet. In Heidelberg, Köln, Trier und Bonn wurden auf der Grundlage der Datenbanksoftware FileMaker unterschiedliche Lösungen entwickelt. Schließlich wurde auf Grundlage von MyCoRe eine dritte Möglichkeit geschaffen, die zunächst im Papyrusprojekt Halle-Jena-Leipzig Verwendung fand und dann auch von anderen Sammlungen übernommen wurde. Aufgrund dieser Vielfalt ist es bisher nicht möglich, alle deutschen Papyrussammlungen gleichzeitig zu durchsuchen, wie man beispielsweise über das Advanced Papyrological Information System (APIS) alle teilnehmenden amerikanischen (und einige andere) Papyrussammlungen gleichzeitig durchsuchen kann. Deswegen wurde die Idee geboren, ein Instrument zu entwickeln, mit dem man auch die deutschen Papyrussammlungen gleichzeitig durchsuchen kann. Damit soll nicht nur eine Vereinheitlichung der verschiedenen Lösungen in den Papyrussammlungen erreicht, sondern darüber hinaus auch ein Standard geschaffen werden, wie in der Zukunft Papyrussammlungen zu katalogisieren sind. Die nachfolgende Tabelle beschreibt die konkreten Stadien der einzelnen digitalen Präsentationen der Papyrussammlungen, die bereits von Beginn an am Portal teilnahmen. Lokation Datenbank Heidelberg Filemaker (Version 8.5 Server), 3 separate Datenbanken Trier Filemaker (Version 8.5 Pro) Köln Filemaker (Version 7), online: statische HTML-Seiten; Migration auf MyCoRe (Version 2.0) Bonn Filemaker (Version 9 Pro) Gießen Allegro C (HANS) Halle-Jena-Leipzig MyCoRe (Version 2.0) Würzburg MyCoRe (Version 2.0) Tabelle 1: Beteiligte Papyrussammlungen Version 1.1.1 7 1.2 Das 'Papyrus Portal' als virtuelle Zusammenführung der Sammlungen Die Zusammenführung der Sammlungen im Papyrus Portal erfolgt nur virtuell. Die Projektbeteiligten hatten sich im Vorfeld der Projektkonzeption gegen ein Harvesting der Daten durch eine zentrale Instanz ausgesprochen. Somit werden zum Zeitpunkt einer Anfrage alle beteiligten Systeme direkt abgefragt. Die Systeme in den Lokationen arbeiten völlig autonom. Das nachfolgende Bild zeigt den allgemeinen Ablauf der Arbeit des Portals. Dabei geht es vorrangig darum, was innerhalb der Portalanwendung abläuft. Funktionalitäten in den einzelnen Lokationen werden dabei nicht berücksichtigt. Diese obliegen auch weiterhin der Verantwortlichkeit und Gestaltung der jeweiligen Einrichtung. Abbildung 1: Allgemeiner Ablauf der Suche 1.3 Benutzung des 'Papyrus Portals' 1.3.1 Aufbau der Homepage 1.3.1.1 Allgemeines Der Internetauftritt des 'Papyrus Portals' ist relativ einfach und übersichtlich gestaltet, um dem Benutzer einen schnellen Überblick und somit eine rasche Benutzung zu ermöglichen. Hier werden kurz die einzelnen Punkte der Homepage erläutert. Auf der Startseite gibt es die Möglichkeit, die Sprache zu wählen, in denen die Portalseiten angezeigt werden sollen. Momentan sind das "Deutsch" und "Englisch". Durch die Wahl des entsprechenden Buttons gelangt man auf die Hauptseite des 'Papyrus Portals'. Zwischen den Sprachen kann man auch später und jederzeit wechseln, indem man in der schwarzen Leiste rechts oben die jeweils andere Sprache wählt. Dabei wird direkt an der Stelle in die neu gewählte Sprache gewechselt, an der man sich gerade befindet. Ein Neustart des 'Papyrus Portals' ist nicht notwendig. Version 1.1.1 8 Abbildung 2: Hauptseite des 'Papyrus Portals' Auf der Hauptseite des 'Papyrus Portals' sind alle weiteren, für den Benutzer relevanten Verweise zu finden. Grundlegend ist dabei, daß sich lediglich der mittlere, blaßgrüne Bereich ändert. Alle übrigen Bereiche der Homepage sind immer sichtbar und zu jedem Zeitpunkt benutzbar. Man gelangt dann immer auf die jeweils gewünschte Seite. In der oberen schwarzen Leiste befinden sich neben der eben schon genannten Möglichkeit, die Sprache zu wechseln, auf der linken Seite die Verweise, mit denen man jederzeit wieder auf die Hauptseite gelangt ("Start") und sich eine Übersicht der gesamten 'Papyrus Portal'Homepage anzeigen lassen kann ("Sitemap"). In der linken Menüleiste befinden sich die meisten wichtigen Verweise des 'Papyrus Portals'. Unter dem Punkt "Allgemeines" findet sich eine kurze Beschreibung des Projektes. Unter "Recherche", dem wohl wichtigsten Menüpunkt des 'Papyrus Portals', liegt die Suchmaske. "Teilnehmer" beinhaltet eine Karte, auf der die teilnehmenden Sammlungen verzeichnet sind. Unter "Mitarbeiter" sind alle Antragsteller und Projektmitarbeiter des 'Papyrus Portals' aufge- listet. Das "Glossar" bietet eine Liste von relevanten fachlichen Begriffen mit Erklärungen. Diese Liste wird beständig mit einer vergleichbaren Liste des Papyrusprojektes Halle-JenaLeipzig abgeglichen und laufend ergänzt. Die "Dokumentation" enhält dieses Schriftstück und weitere Dokumente, die den Hintergrund und die Arbeitsweise des 'Papyrus Portals' erklären. Unter dem Verweis "Hilfe" sind einige allgemeinere Hinweise für eine Suche und Beispielsuchen zusammengefaßt worden. Der "Disclaimer" enthält den Haftungsausschluß. Unter "Kontakt" sind relevante Kontaktpersonen und deren Adressen aufgelistet. 1.3.1.2 Die Kurzbeschreibungen der teilnehmenden Sammlungen Die Verweise zu den Kurzbeschreibungen der teilnehmenden Sammlungen befinden sich am rechten oberen Rand des zentralen Bereiches. Hier sind alphabetisch die Orte der entsprechenden Sammlungen verzeichnet worden. Die Kurzbeschreibungen selbst sind möglichst einheitlich gehalten. Hier findet man die Kontaktdaten der einzelnen Sammlungen und Verweise auf existierende Internetseiten, Datenbanken etc. auf der linken Seite und eine kurze Beschreibung der Sammlung, besonderer Stücke und eine Liste der wichtigsten Literatur über die jeweilige Sammlung und ihre BestänVersion 1.1.1 9 de auf der rechten Seite. Zusätzlich ist eine kleine Abbildung eines besonderen Objektes jeder Sammlung aufgenommen worden. Bei jeder dieser Kurzbeschreibungen ist das Layout durch das 'Papyrus Portal' angefertigt und vorgegeben worden. Die enthaltenen Inhalte der Seiten wurden jedoch von den jeweiligen Sammlungen bestimmt. Diese sind auch für eine Aktualisierung dieser Seite verantwortlich. Abbildung 3: Kurzbeschreibung der Leipziger Papyrus- und Ostrakasammlung 1.3.2 Die Recherche Die Recherche ist das Kernstück des 'Papyrus Portals'. Im Folgenden sollen einige allgemeine Suchhilfen und Beispiele gegeben werden, die die Suche über das 'Papyrus Portal' erleichtern sollen. Kurze Hinweise und spezielle Suchhilfen für einzelne Felder (insb. zur Datumssuche) finden man auch in den Hilfebuttons neben den einzelnen Suchfeldern, die mit einem “?” gekennzeichnet sind. 1.3.2.1 Die Suche in den Klassifikationsfeldern Für viele Felder erfolgt die Suche mit Hilfe von vorgegebenen Listen, in denen Sie den gewünschten Suchbegriff auswählen können. Das betrifft folgende Felder: Sprache, Textart, Ort, Gau und Material. In den Listen sind alle Einträge der angeschlossenen Datenbanken aufgenommen worden, die in diesen Feldern vorkommen. Darüber hinaus sind verschiedene Varianten (z.B. unterschiedliche Schreibweisen) eines Eintrages vereinheitlicht bzw. zusammengefaßt worden. (s.u. Klassifikationen und Konkordanzen) 1.3.2.2 Die Suche in den restlichen Feldern Version 1.1.1 10 Für eine Suche in den anderen Feldern (Inventarnummer, Titel, Datierung, Inhalt, Freitext) gibt man den Suchbegriff direkt in eines der vorgesehenen Felder ein. Dabei kann man Worte auch trunkieren und nur einen Teil eines Wortes eingeben, z.B. *klav* für eine Suche nach "Sklave", "Haussklave", "Sklavenkauf" etc. Umlaute sind in ihre Grundbuchstaben aufzulösen und in zwei Buchstaben abzubilden, z. B. ä als ae. Zu beachten ist, daß die Schreibweise (z.B. vollständige Inventarnummern) sehr verschieden sein kann, so daß schon aufgrund eines fehlenden Leerzeichens ein Datensatz nicht gefunden werden kann. Eine Kombination mehrerer Suchbegriffe in einem Feld ist möglich und wird automatisch als logische "und"-Verknüpfung ausgeführt. Ebenso werden auch Einträge in verschiedenen Feldern automatisch durch "und" verbunden. Eine gleichzeitige Suche nach verschiedenen Begriffen, die nicht durch "und" verbunden werden sollen ("oder"-Verknüpfung), teilt man in ihre Bestandteile auf und führt die Suchen nacheinander durch. 1.3.2.3 Die Datumssuche Für eine Datumssuche müssen die Datumsangaben für den gesuchten Zeitraum eingeben werden. Bei der Suche nach der Datierung wird immer nach einem Zeitraum gesucht. Deswegen werden die Datumsangaben immer in ein Startdatum und ein Enddatum aufgeteilt. Daher sind auch bei exakten Datumsangaben immer beide Felder auszufüllen, z.B. für eine Suche nach dem 12. Januar 31 n.Chr. ist in das "nicht vor" und in das "und nicht nach"-Feld jeweils "12.01.31" einzugeben. Bei größeren Zeiträumen (z.B. Jahrhunderten) steht das "nicht vor"-Datum für den Beginn und das "und nicht nach"-Datum für das Ende der Zeitspanne, z.B. für eine Suche nach dem 1 Jh.n.Chr. ist in das "nicht vor"-Feld "1" und in das "und nicht nach"-Feld "99" einzugeben. 1.3.2.4 Beispielsuchen Gesucht sind alle Steuerlisten aus Hermupolis Eingabe: "Hermupolis" aus der Liste im Feld "Ort" wählen, "Steuerliste" oder eine entsprechend trunkierte Form (z.B. "Steuer*") im Feld "Inhalt" eingeben. Gesucht sind alle Dokumente aus dem 3. Jh.v.Chr., die Sklaven betreffen Eingabe: in den Datierungsfeldern "-299" in das Feld "nicht vor" und "-200" in das Feld "und nicht nach" eingeben, "Sklav*" im Feld "Inhalt" eingeben. Gesucht sind Texte aus dem Jahre 138 aus dem Arsinoites, in denen eine Person namens Pasion vorkommt Eingabe: "Arsinoites" aus der Liste im Feld "Gau" wählen, "Pasion" oder eine entsprechend trunkierte Form im Feld "Inhalt" eingeben, in den Datierungsfeldern "138" in das Feld "nicht vor" und in das Feld "und nicht nach" eingeben. Gesucht sind paraliterarische Texte aus Krokodilopolis Eingabe: "Krokodilopolis" aus der Liste im Feld "Ort" wählen, "paraliterarisch" aus der Liste im Feld "Textart" wählen. Gesucht demotische Orakelfragen Eingabe: "demotisch" aus der Liste im Feld "Sprache" wählen, "Orakelfrage" oder eine entsprechend trunkierte Form (z.B. "Orakel*") im Feld "Inhalt" eingeben. Version 1.1.1 11 2 Technische und inhaltliche Umsetzung 2.1 Allgemeine Voraussetzungen und Ausgangslage Etliche deutsche Papyrussammlungen haben ihre Bestände bereits digitalisiert und Informationen über sie in Form von durchsuchbaren Datenbanken online der Öffentlichkeit zur Verfügung gestellt. So können mittlerweile Informationen über die Papyri, Ostraka etc. folgender Sammlungen im Internet recherchiert und eingesehen werden: Bonn, Giessen, Halle, Heidelberg, Jena, Köln, Leipzig, Trier, Würzburg. In den meisten dieser Standorte sind bereits die kompletten Bestände online vorhanden und werden regelmäßig mit neuen Informationen aktualisiert. In einigen Sammlungen ist diese Arbeit aber noch im Gange. Außerdem werden auch in der Zukunft weitere Papyrussammlungen dieser Entwicklung folgen und ihre Bestände online den Wissenschaftlern und der Öffentlichkeit zur Verfügung stellen. Das betrifft insbesondere Deutschlands größte Papyrussammlung in Berlin. Nun ist es zwar möglich, jede der genannten Sammlungen online zu durchsuchen, doch ist das ein zeitaufwendigen Unterfangen, da jede Datenbank separat durchsucht werden muß. Je mehr Papyrussammlungen ihre Daten ins Internet stellen, desto aufwendiger wird eine solche Suche also werden. Um diesen Makel zu beseitigen, wurde die Idee geboren, ein Instrument zu schaffen, mit dem man all diese Papyrussammlungen zur gleichen Zeit durchsuchen kann. Gleichzeitig sollte damit auch ein Standard geschaffen werden, wie in Zukunft Informationen über Papyri, Ostraka etc. in einer Datenbank abgelegt werden sollen. Eine Standardisierung der Einträge in den einzelnen Datenbanken war auch notwendig, um eine einheitliche Suche und Trefferanzeige zu ermöglichen. Ausgangspunkt der Überlegungen zu einem Instrument, mit dem man gleichzeitig alle angeschlossenen Papyrussammlungen durchsuchen kann, waren die Unterschiede zwischen den einzelnen Datenbanken. Dabei war jedoch noch grundlegender zu beachten, daß diese einzelnen Datenbanken auch auf verschiedenen Systemen laufen. Die folgende Tabelle gibt eine Übersicht über die einzelnen Betriebssysteme, in denen die Datenbanken der jeweiligen Papyrussammlungen laufen. Lokation Betriebssystem Heidelberg Windows Server 2003 Trier Mac OS 10.5 Leopard Bonn Windows Server 2003 Giessen Windows/Linux Köln, Würzburg, (MyCoRe) Halle-Jena-Leipzig Suse Linux 10.3 Tabelle 2: Beteiligte Lokationen und die verwendeten Betriebssysteme Wie in der Tabelle zu sehen ist, sind alle drei größeren Betriebssysteme vorhanden, wodurch bei einer Kommunikation der Standorte untereinander mit Kompatibilitätsschwierigkeiten zu rechnen ist. Hinzu kommt, daß diese Betriebssysteme sich in der Zukunft verändern werden. so ist davon auszugehen, daß nach ein paar Jahren auf dem jeweiligen Server eine neue Version des Betriebssystems installiert wird (Windows XP zu Windows Vista, Mac OS 10.5 Leopard zu Snow Leopard etc.). Zwar sind zukünftige Entwicklungen nicht vollständig voraussehbar, doch gibt es bei allen Systemen Konstanten, die bei einer Entwicklung eines Instruments für eine gleichzeitige Suche in allen Papyrussammlungen berücksichtigt werden müssen. Version 1.1.1 12 Von weitaus größerer Wichtigkeit sind jedoch die einzelnen Datenbanken, in denen die jeweiligen Sammlungen die Daten zu ihren Beständen gesammelt haben. In der folgenden Tabelle sind alle Datenbanktypen in den einzelnen Sammlungen. Lokation Systemtyp Heidelberg Filemaker (Version 8.5 Server) Trier Filemaker (Version 8.5 Pro) Köln Filemaker (Version 7), MyCoRe (Version 2.0) Bonn Filemaker (Version 9 Pro) Giessen Allegro HANS Halle-Jena-Leipzig MyCoRe (Version 2.0) Würzburg MyCoRe (Version 2.0) Tabelle 3: Beteiligte Datenbanktypen Eine mögliche Anbindung der einzelnen Datenbanken konnte mit allen Sammlungen diskutiert werden. Halle-Jena-Leipzig, Würzburg und Köln auf MyCoRe Basis (My Content Repository). MyCoRe ist ein Open Source Projekt zur Entwicklung eines Systems für digitale Bibliotheken und Archivlösungen. Auf der Basis eines Softwarekerns, der als Open Source unter der “GNU-General Public License” verfügbar ist, können spezifische Anwendungen an den jeweiligen Standorten realisiert werden. Mit der bestehenden, in ihrer strukturellen Bearbeitung neuartigen MyCoRe 2.0 Version können mehrere Instanzen nebeneinander arbeiten, da es sich um eine neutrale Software handelt, die auf PC und Macintosh (Unix-Kern) funktioniert. Daten und Programm sind voneinander getrennt. Die Metadaten werden als XML-Daten gespeichert. Die Bilder werden getrennt davon gehalten. Es gibt verschiedene Rechte und damit verschiedene Informationen: Mitglied einer Sammlung, Mitglied eines Projektes und Gäste. Allegro C (HANS) Bei allegro-Hans handelt es sich um eine auf allegro-C basierende Datenbanksoftware, die speziell für die elektronische Erfassung von Handschriften, Autographen, Nachlässen und Sonderbeständen konzipiert wurde. HANS ist keine Datenbank im eigentlichen Sinne, sondern ein Datensystem, welches per Web-Anbindung Daten ex- und importieren und diese in verschiedenen Formaten anzeigen kann. Filemaker Es existieren Datenbanken auf der Basis von FileMaker in Heidelberg, Köln, Bonn und Trier, Diese bauen jedoch auf verschiedenen FileMaker Versionen auf. Trotz vieler Gemeinsamkeiten ist jede dieser Datenbanken in ihrer Struktur unterschiedlich. Die Datenbanken sind untereinander nicht kompatibel. Während die Datenbanken in Heidelberg, Bonn und Trier in der Online-Version frei durchsuchbar sind, ist das in Köln nicht möglich. Es können dort lediglich die einzelnen erhobenen Datenfelder zu den jeweiligen Publikationsbänden angezeigt werden. Man hat aber die Möglichkeit, sich die Daten nach den wichtigen Feldern sortiert anzeigen zu lassen. Zu diesen Sammlungsdatenbanken kommt noch das Heidelberger Gesamtverzeichnis (HGV), das wegen seiner andersartigen Zielsetzung nicht in ein deutsches Papyrus Portal integriert werden kann; es erfaßt nämlich einerseits Papyri weltweit andererseits aber nur die bereits publizierten, und nochmals eingeschränkt nur die dokumentarischen Papyri. Version 1.1.1 13 2.2 Die Portallösung Für eine Verbindung verschiedener Papyrusdatenbanken gibt es zwei Möglichkeiten. Bei der einen Möglichkeit verbleiben alle Daten auf den lokalen Servern in den einzelnen Papyrussammlungen und werden lediglich von einer zentralen Suchmaschine abgefragt. Das hat den Vorteil, daß alle Daten autonom und die einzelnen Sammlungen direkt für ihre Datenbanken und deren Inhalte verantwortlich bleiben. Außerdem könnte eine solche Lösung einfach um weitere Sammlungen erweitert werden. Die Nachteile dieser Lösung sind ihre Abhängigkeit von der Geschwindigkeit und der Auslastung der Netzwerke der einzelnen Institutionen und dem Fakt, dass alle lokalen Sammlungen ihre Datenbanken auf jeweiligen Serversystemen rund um die Uhr zur Verfügung stellen müssen. Die zweite Möglichkeit ist das sogenannte Harvesting. Dabei werden alle Daten der lokalen Papyrussammlungen in einer zentralen Datenbank gesammelt, die dann für eine Metasuche zur Verfügung steht. Diese Lösung würde die Harmonisierung der Daten sehr einfach machen. Suchen wären nicht mehr von der Geschwindigkeit und der Auslastung der Netzwerke abhängig. Der Nachteil dieser Lösung ist der Umstand, dass alle Daten zur gleichen Zeit sowohl in der lokalen Datenbank als auch in der zentralen Datenbank vorhanden sind. Diese Daten müssten immer auf dem gleichen Stand gehalten werden, was nicht nur arbeitsaufwendig ist sondern mitunter auch Probleme bei der Konsistenz der Daten beinhaltet. Auf einem Workshop in Leipzig im November 2005 wurden die beiden Möglichkeiten mit den Vertretern aller deutschen Papyrussammlungen diskutiert. Das Ergebnis war eine Entscheidung für die Portallösung, bei der lediglich eine zentrale Suchmaschine die Daten in den lokalen Sammlungen abfragt, und gegen die Harvestinglösung. Einzig für die Sammlung in Giessen wurde ein partielles Harvesting entwickelt. Der Grund liegt in der Anbindungsmöglichkeit der Allegro/Hans-Datenbank. Diese verfügt einzig über eine OAISchnittstelle, die ihre Daten via HTTP versendet. Aus der großen Anzahl von Datensätzen und dem Kommunikationsmedium resultiert die Notwendigkeit eines vorherigen Erfassens der Informationen. Andernfalls wäre die Geschwindigkeit einer Abfrage für eine Echtzeitsuche nicht mehr zumutbar (Zugriffszeit für ca. 3000 Datensätze lag bei ca. 20 Minuten). Mögliche Treffer in Giessen werden dann wieder direkt mit den Originaldatensätzen der Datenbank in Giessen verlinkt. Aufgrund der guten Erfahrung, die im Papyrusprojekt Halle-Jena-Leipzig mit MyCoRe gemacht worden waren, entschied man sich dafür, daß 'Papyrus Portal' auf der Grundlage von MyCoRe zu erstellen. Version 1.1.1 14 2.3 Allgemeines zu MyCoRe MyCoRe1 ist eigentlich als Repository für Dokumente und Sammlungen gedacht und implementiert worden. Da eine Vielzahl von Funktionalitäten wie ein Remote-Suchsystem, Verarbeitung mehrsprachiger statischer Web-Seiten und ein einfaches WCMS (Web Content Management System) integraler Bestandteil sind, wurde von den Teilnehmern beschlossen, das Papyrus-Portal-Projekt mit dieser Software zu realisieren. Hinzu kommt, dass diese Software durch ihre Open-Source-Lizensierung (GPL Version 2) frei verfügbar ist. Zentraler Bestandteil des entwickelten 'Papyrus Portals' ist die Suche über heterogene Datenbanken. Von Hause aus verfügt MyCoRe neben der Suche in anwendungsinternen Datenbeständen nur über eine Suche via WebService in datenmodellgleichen entfernten Anwendungen. Da dieser WebService jedoch über eine definierte Schnittstelle in die SearchComponent von MyCoRe eingebunden wird, war es auf einfachem Wege möglich, auch für den Zugriff auf Datenbanken mit anderen Datenmodellstrukturen Add-Ons zu programmieren und einzubinden. Diese Add-Ons kommunizieren ihrerseits dann über proprietäre Netzprotokolle mit den Clients der teilnehmenden Partnerdatenbanken. Andere MyCoRe-Komponenten wie das Autorensystem oder die Stores für digitale Objekte oder der Image Viewer wurden für das 'Papyrus Portal' nicht benötigt. Diese Module wurden bei der Implementierung einfach abgeschaltet. Lediglich für das Glossar existiert eine kleine Datenbasis. 1 siehe http://www.mycore.de/ Version 1.1.1 15 2.4 Zugriff auf die Datenbanken Der Zugriff des Portals auf die Datenbanken erfolgt mittels Connector/Client-Systemen. Diese implementieren ein Interface zwischen der MyCoRe-Suche und den Sammlungen und ermöglichen den Zugriff auf die entsprechenden Datenbanken. Bedingt durch die unterschiedliche Struktur der Datenbanken sind hier verschiedene Techniken anzuwenden. Zugriff über eine WebService-Schnittstelle zu allen MyCoRe-Papyrusprojekten Zugriff über eine Socket-Dataobjekt-Schnittstelle unter Zuhilfenahme eines JDBCTreiber auf die FileMaker Datenbanken Zugriff über eine Open-Archive-Schnittstelle auf die Allegro/Hans-Datenbank und Extraktion von relevanten Suchinformationen Abbildung 4: Schema des verteilten Zugriffes Innerhalb der Clients werden alle sammlungsspezifischen Mappings durchgeführt. Darüber hinaus verfügen die Clients über leistungsstarke Suchmaschinen für eine kombinierte SQL/Information-Retrieval-Suche. Weiterhin sind die Clients für die Umsetzung spezieller Konkordanzen zuständig. Das Resultat wird einheitlich entsprechend der Vorgabe für das Portal zurückgegeben. 2.4.1 Beteiligte Einrichtungen und ihre Anbindung Version 1.1.1 16 Lokation Systemtyp Anbindung Heidelberg Filemaker (Version 8.5 Server) JDBC-Abfrage, Client vor Ort installieren Trier Filemaker (Version 8.5 Pro) Köln Filemaker (Version MyCoRe (Version 2.0) Bonn Filemaker (Version 9 Pro) JDBC-Abfrage, Client vor Ort installieren Giessen Allegro HANS Partielles Harvesting2 Halle-Jena-Leipzig MyCoRe (Version 2.0) WebService Würzburg MyCoRe (Version 2.0) WebService JDBC-Abfrage, Client vor Ort installieren 7), Migration auf MyCoRe 2 bzw. Eingabe neuer Daten direkt in MyCoRe 2, WebService Tabelle 4: Beteiligte Datenbanktypen und ihre Anbindung Tabelle 4 zeigt die beteiligten Sammlungen und spezifiziert ihre technischen Parameter. Die Sammlungsanbindungen teilen sich in die Client-Systeme, die MyCoRe-WebServices und in ein partielles Harvesting unter Verwendung der OAI-Schnittstelle. 2.5 Die Client-Software 2.5.1 Der Client Für den Zugriff auf Standorte mit FileMaker-Datenbanken ist eine spezielle Software erforderlich. Das Programm wird lokal beim jeweiligen Partner installiert und verfügt über drei separate Schnittstellen. Die JDBC-Treiber-Anbindung der Datenbank stellt eine der Schnittstellen dar. Die beiden verbleibenden Schnittstellen werden für die Kommunikation mit dem Portal benötigt. Die Suchanfragen der Eingabemaske werden via Java-Socket durch Kapselung als Datenobjekt an den Clienten versandt. Dieses Objekt versteht sich als Hülle für den Transport der Suchinformationen. Im Client werden die Daten aufbereitet und als dynamische partielle SQL-Suchanfragen über die JDBC-Schnittstelle an die FileMakerDatenbank weitergegeben. Die Client-Anwendung kann auf die Datenbank ausschließlich lesend zugreifen. Ein Schreibzugriff ist nicht möglich. Der Indexwert3 relevanter Suchergebnisse wird wiederum durch Datenkapselung an die Portal-Applikation zurückgeschickt und in der Trefferliste verarbeitet. Sobald ein Treffer in der Anzeige ausgegeben werden soll, findet wieder ein Aufruf über Java-Socket zum Clienten statt. Die Daten werden nun per HTTP-Anfrage als Datenstrom übertragen. Innerhalb des Datenstroms gekapselt findet sich die identifizierende Identifikationsnummer wieder. Über diese ID wird der Datensatz aufgefunden. Ein XMLGerüst nimmt die Daten auf und sendet diese an die Anzeigeapplikation des Portals zurück. Analog zu einer MyCoRe-MyCore-Anfrage werden die Daten dargestellt. Jeder angezeigte Datensatz ist mit der Web-Publishing-Anwendung der FileMaker-Datenbank am Zielort verlinkt. 2 Die Allegro-Hans-Datenbank bieten nur über OAI eine Anbindungsmöglichkeit. Diese Schnittstelle hat jedoch Defizite in der Geschwindigkeit, so dass Informationen vor einer Anfrage bereits gesammelt werden müssen, um dann eine zeitnahe Informationsauswertung und Antwortweiterleitung gewährleisten zu können. 3 Jeder Datenbankeintrag wird über einen Index eindeutig identifiziert. Version 1.1.1 17 Abbildung 5: Schematische Darstellung der Clientanbindung 2.5.2 Möglichkeiten und Grenzen des Clients Um den Client möglichst eigenständig und wartungsarm betreiben zu können, verfügt das Programm über diverse Einstellungsmöglichkeiten, um auf Änderungen der Umgebung reagieren zu können. Der Client enthält bei der Installation bereits die Konfigurationen der einzellen Datenbankfelder wie sie in der Datenbank vorgehalten werden. Da hier mit Klartextnamen gearbeitet wird, können diese Felder auch im Nachhinein angepasst und ggf. verändert werden. Die dafür nötigen Informationen befinden sich in der „config_sammlungsname.xml“-Datei. Durch die Nutzung zweier „Joker“-Felder können auch nachträglich Feldinformationen ausgegeben werden. In der „properties.xml“-Datei werden relevante Daten zum Datenbankzugang gespeichert. Dies gliedert sich im Einzelnen in Benutzername, Passwort und Datenbankname. Für die Sammlung Heidelberg können 2 zusätzliche Datenbanknamen definiert werden. Neben diesen grundlegenden Aufgaben erfüllt der Client aber auch Datenkonvertierung, beispielsweise für die Datumssuche. Da sich die Dokumente im Zeitraum vor Christus (BC) und nach Christus (AD) befinden können, werden alle gregorianischen Datumsangaben in das julianische Datum umgerechnet. So ist eine genaue und effiziente Suche in den Datensätzen möglich. Wie jedes Softwareprodukt sind dem Client aber auch Grenzen gesetzt. Das Programm arbeitet auf verschiedenen Systemen mit verschiedenen Datenbanken zusammen. Hinzu kommen sammlungsspezifische Besonderheiten, die unter den Aspekt des „Information Retrieval“ fallen und vom Client nur bedingt vereinheitlicht werden können. Kommt es zu einem Ausfall der Datenbank, so kann der Client natürlich keine Informationen mehr sammeln und es kommt zum Ausfall des betreffenden Standortes im Portal. Fehler, die durch unsachgemäße Datenverwaltung in der Filemaker-Datenbank entstehen, können vom Client nicht korrigiert werden. Kommt es schlussendlich zu einem Ausfall des Clients, so kann nur ein Neustart vor Ort das System wieder in Gang bringen. Zu beachten ist außerdem, dass der Client nur in einem bestimmten Umfang getestet werden konnte. Zum Zeitpunkt der Erstellung dieser Dokumentation läuft das Clientprogramm auf Betriebssystemen wie „Mac OS 10“ und höher, sowie „Windows Server 2003“. Tests unter „Windows XP“ und „Suse Linux 10.3“ waren ebenfalls erfolgreich. Mögliche Wechselwirkungen mit bestimmten Programmen der beschriebenen Betriebssysteme können die Funktionsweise des Clients beeinflussen, auch wenn die Wahrscheinlichkeit dafür relativ gering ist. Version 1.1.1 18 2.6 Felder der Suche und der Trefferliste im Portal In der nachfolgenden Tabelle sind alle für das Portal festgelegten Felder für die Suche und Trefferlistenanzeige notiert. Diese Felder erhalten zur besseren Orientierung Nummern, die sie eindeutig im 'Papyrus Portal' identifizieren. Nr. Suche Anzeige Bemerkung Port01 Inventarnummer Inventarnummer Text oder Textteile mit Trunkierung (*), Link zum lokalen Datensatz Port02 Sammlung Sammlung Auswahlliste (s. Klassifikation), Sammlungsvorstellung Port03 Sprache Sprache Auswahlliste (s. Klassifikation) Port04 Textart Textart Auswahlliste (s. Klassifikation) Port05 Titel Titel Text oder Textteile mit Trunkierung (*) Port06v Startdatum Startdatum Datum (von) in gregorianischer Schreibweise Port06b Enddatum Enddatum Datum (bis) in gregorianischer Schreibweise Port07 Herkunft Gau Herkunft Gau Auswahlliste (s. Klassifikation) Port08 Herkunft Ort Herkunft Ort Auswahlliste (s. Klassifikation) Port09 Material Material Auswahlliste (s. Klassifikation) Port10 Inhalt Inhalt Text oder Textteile mit Trunkierung (*) Port11 Publikationsnummer Port12 statischer Link Verweis zum Originaldatensatz Port13 weitere Links z.B. zum HGV usw. Link zu Port14 Freitext Freitextsuche über alle Suchfelder, Text oder Textteile mit Trunkierung (*) Port15 Datum Erwerbung Datum als Text Port16 Text Erwerbung Text oder Textteile mit Trunkierung (*) Tabelle 5: Such- und Anzeigefelder für das 'Papyrus Portal' Im Folgenden wird die Suche und Anzeige der einzelnen Felder beschrieben. 2.6.1 Inventarnummern (Port01) Inventarnummern werden durchsucht, um dem Benutzer die Möglichkeit zu bieten, eine Inventarnummer zu finden, ohne zu wissen, in welcher Sammlung das entsprechende Stück aufbewahrt wird. Außerdem kann man in vielen Fällen so an Informationen über kleinere Sammlungen innerhalb großer Sammlungen gelangen. Wegen der vielen Varianten und Möglichkeiten der Darstellung von Inventarnummern in den einzelnen Datenbanken wird die Suche automatisch als Freitextsuche im Feld „Inventarnummer“ vollzogen. Es können auch Teile der Inventarnummer gesucht werden, z.B. nur die Zahl. Die Trunkierung erfolgt bei den Zahlen automatisch, ansonsten durch "*". Für die Anzeigen wird der Inhalt des entsprechenden Feldes aus der lokalen Datenbank komplett übernommen, doch sind i.d.R. Ergänzungen nötig (z.B. „P. UB Trier S“ für die Trierer Inventarnummern). Diese ergeben sich jedoch aus der Datenbank, aus der die Daten stammen. Die Inventarnummer dient gleichzeitg als direkter Link zum entsprechenden Datensatz der lokalen Datenbank. Version 1.1.1 19 2.6.2 Sammlung (Port02) Die durchsuchbaren Sammlungen werden als Liste (s. Klassifikationen) angeboten, in der Sammlungen durch ein Häkchen ausgewählt werden können. Möglich sind eine Suche durch eine einzelne Sammlung, mehrere selbst kombinierte Sammlungen und alle Sammlungen gleichzeitig. Für Heidelberg werden immer automatisch alle drei Kataloge durchsucht, eine Auswahl einzelner Heidelberger Kataloge ist nicht möglich. Da mit Ausnahme der MyCoReDatenbanken dieses Feld in den lokalen Datenbanken nicht vorhanden ist, wird bei der Anzeige in diesen Fällen automatisch die betreffende Sammlung eingesetzt. 2.6.3 Sprache (Port03) Die möglichen Sprachen werden als Auswahlliste (s. Klassifikationen) angeboten. "Ägyptisch" ist als einzige Sprache in ihre Schriften aufgeteilt worden: Hieroglyphisch, Hieratisch und Demotisch. Nur diese können gesucht werden. Dies erschien notwendig, da das Interesse des Benutzers einer Datenbank eher den einzelnen Schriften des Ägyptischen gilt. Obwohl in Heidelberg für jede Sprache eine eigene Datenbank angelegt wurde, ist trotzdem ein Feld „Sprachen“ vorhanden, so daß auch hier kein Sonderfall vorliegt. In der Trefferliste wird immer der Eintrag des lokalen Datensatzes angezeigt. 2.6.4 Textart (Port04) Die Textart gibt eine grobe inhaltliche Klassifizierung der Texte an. Die Suchmöglichkeiten werden als Auswahlliste (s. Klassifikationen) angeboten. In der Trefferliste wird immer der Eintrag des lokalen Datensatzes angezeigt. 2.6.5 Titel (Port05) Die Suche erfolgt als Freitextsuche im Feld „Titel“, das in allen Datenbanken vorhanden ist. Es wird nur dieses Feld in den Datenbanken durchsucht. Angaben in anderen Feldern werden nicht berücksichtigt. Wegen der vielen Varianten und Möglichkeiten der Darstellung einer Titelangabe können auch Teile des Titels oder eines Titelwortes gesucht werden. Die Trunkierung erfolgt durch "*". Angezeigt wird das Feld „Titel“ aus der lokalen Datenbank. 2.6.6 Datierung (Port06a und 06b) In allen Datenbanken wird zwischen einem Anzeigefeld und verschiedenen Suchfeldern unterschieden. In den Suchfeldern ist die Eingabe der Daten allerdings nicht einheitlich. In den Datenbanken nach Heidelberger Vorbild beispielsweise existieren separate Felder für die Eingabe von Jahren und Jahrhunderten. All diese Felder werden in eine Datumssuche einbezogen. Bei der Eingabe wird immer eine Zeitspanne („von“ – „bis“) in gregorianischer Schreibweise eingegeben. Dabei können Tagesdaten oder auch nur Jahreszahlen eingegeben werden. Für Datierung v.Chr. muß vor die komplette Datumsangabe ein "-" gesetzt werden, z.B. -13.10.265 für den 13. Oktober 265 v.Chr. Bei einer Suche nach einem genauen Datum (z.B. 18.10.31) muß dieses in beide Felder eingegeben werden. Es findet immer eine scharfe Suche ohne jegliche Toleranz statt. Während der Suche wird das gesuchte Datum und das Datum der Datensätze von MyCoRe bzw. von den Clients in ein julianisches Datum umgerechnet und an die Erfordernisse der Suche angepasst. Für die Version 1.1.1 20 Darstellung wird das Feld der lokalen Datenbanken ausgelesen und angezeigt. Eventuelle Ungereimtheiten in diesen Feldern wurden den lokalen Datenbanken vorher mitgeteilt und behoben. 2.6.7 Herkunft (Port07 und 08) Die Suche nach der Herkunft ist in die Suche nach dem Ort und die Suche nach dem Gau unterteilt. Für beide Suchen werden Auswahllisten (s. Klassifikationen) angeboten. Die Suche in den lokalen Datenbank ist aufgrund der unterschiedlichen Eingabevarianten als Freitextsuche in den entsprechenden Feldern gestaltet. Es fehlt häufig eine der beiden Angaben. Die Anzeige wird aus dem Feldinhalt der lokalen Datenbank gespeist, da dort zusätzliche Informationen (z.B. Fragezeichen) vorhanden sind, die so auch angezeigt werden können. 2.6.8 Material (Port09) Die möglichen Materialien werden als Auswahlliste (s. Klassifikationen) angeboten. In der Trefferliste wird immer der Eintrag des lokalen Datensatzes angezeigt. 2.6.9 Inhalt (Port10) Die Suche erfolgt ähnlich der Titelsuche als Freitextsuche, die sich ausschließlich auf das Feld „Inhalt“ der jeweiligen Datenbanken erstreckt. Wegen der vielen Varianten und Möglichkeiten der Eingabe eines Inhalts können auch Teile des Inhalts oder eines Wortes gesucht werden. Die Trunkierung erfolgt durch "*". Angezeigt wird das Feld Inhalt der lokalen Datenbank. 2.6.10 Publikationsnummer (Port11) Nach den Publikationsnummern wird im 'Papyrus Portal' nicht gesucht. Das entsprechende Feld in den lokalen Datenbanken wird aber in der Trefferliste angezeigt. 2.6.11 Statischer Link (Port12) Hierbei handelt es sich um einen generierten Link, der direkt auf den entsprechenden Datensatz der lokalen Datenbank führt. Dieser ist mit der Inventarnummer verknüpft, so daß ein Anklicken der Inventarnummer direkt zum entsprechenden Datensatz der lokalen Datenbank führt. 2.6.12 Weitere Links (Port13) Mit "Weitere Links" sind Verweise zu anderen Metadatenbanken gemeint, z.B. HGV, CPP, LDAB etc., die insbesondere für publizierte Stücke interessant sind. Dieses Feld wird vom 'Papyrus Portal' in den lokalen Datenbanken nicht durchsucht. Das entprechende Feld wird jedoch ausgelesen und wird in der Trefferliste angezeigt. Version 1.1.1 21 2.6.13 Freitext (Port14) Die Suche erfolgt als Freitextsuche über alle Felder der Datenbank (mit Ausnahme der Datumsfelder). Wegen der vielen Varianten und Möglichkeiten der Eingabe der Informationen in den einzelnen Feldern können auch Teile eines Wortes gesucht werden. Die Trunkierung erfolgt durch "*". In den MyCoRe-Datenbanken werden die mit Klassifikationslisten versehenen Felder nicht in die Freitextsuche eingeschlossen. Angezeigt werden jeweils die separaten Felder (s. unter den einzelnen Feldern für Spezifika). 2.6.14 Datum Erwerbung (Port 15) Anders als bei der Datierungssuche erfolgt die Suche nach dem Datum der Erwerbung als Freitextsuche, d.h. die eingegebenen Datumsangaben und die in den Sammlungsdatenbanken vorhanden Datumsangaben in gregorianischer Schreibweise werden nicht in ein julianisches Datum umgewandelt. Stattdessen wird die Zahlefolge (z.B. "1904") im entsprechenden Feld der lokalen Datenbank gesucht. Angezeigt wird das Feld des Erwerbungsdatums der lokalen Datenbank. 2.6.15 Text Erwerbung (Port16) Die Suche erfolgt ähnlich der Titelsuche als Freitextsuche, die sich ausschließlich auf das Feld „Erwerbung“ (u.ä.) der jeweiligen Datenbanken erstreckt. Wegen der vielen Varianten und Möglichkeiten der Eingabe können auch einzelne Worte oder Teile eines Wortes gesucht werden. Die Trunkierung erfolgt durch "*". Angezeigt wird das Feld "Erwerbung" der lokalen Datenbank. 2.7 Mapping der Metadaten Diesen soeben vorgestellten Feldern der Suche und Anzeige im 'Papyrus Portal' werden in den einzelnen Datenbanken Felder eindeutig zugeordnet (Mapping). Dies ist in der folgenden Tabelle dargestellt. Dabei ist zu beachten, daß immer nur die angegebenen Felder der lokalen Datenbanken durchsucht und angezeigt werden. Alle anderen Felder bleiben unberücksichtigt. Das bedeutet, daß auch nur gefunden werden kann, was in diesen Feldern eingetragen worden ist. Die Verantwortlichkeit für die Inhalte liegt bei den lokalen Sammlungen. Legende: Es sind zunächst die Bezeichnungen der Felder angegeben worden, wie sie auch in den entsprechenden Such- und/oder Eingabemasken verwendet werden. Bei der Giessener Datenbank sind die Bezeichnungen für die entsprechenden, über OAI ausgegebenen DC-Properties angegeben worden. „Port”+Nr.: bezeichnet das Feld im 'Papyrus Portal' „st“+Nr.: bezeichnet ein Feld im Schriftträgerdatensatz der MyCoRe-Datenbank „te“+Nr.: bezeichnet ein Feld im Textdatensatz der MyCoRe-Datenbank Version 1.1.1 22 Papyrusportal Heidelberg Bonn Trier MyCoRe (Halle, Jena, Köln, Giessen Leipzig, Würzburg) Inventarnummer (Port01) P_Heid_Inv_L P.Bonn.Inv. Inventarnummer Inventarnummer (st02) source.call_number Sammlung (Port02) „Heidelberg“ „Bonn“ „Trier“ Sammlung (st04) „Giessen“ Sprache (Port03) Sprache Sprache_Schrift Sprache1, Sprache2 Sprache (st27) language.text, language.script Textart (Port04) Art Textart Art Textart (st24) type Titel (Port05) Originaltitel Titel Titel Titel (st01) title.publication Datierung (Port06) T, M, J, T2, M2, J2, Jh, Jh2, Tag, Monat, Jahr, Tag2, Monat2, Tag1, Monat1, Jahr1, Tag2, Monat2, Datierung: (st28/text) - „nicht date Datierung Jahr2, Jh, Jh2, Datierung Jahr2, Jh1, Jh2, DatierungText vor“ (st28/ivon), „und nicht nach“ (st28/ibis) Gau (Port07) Herkunft Nomos Herkunft Herkunft Gau (st29b) coverage.origin Ort (Port08) Herkunft Ort Herkunft Herkunft Ort (st29a) coverage.origin Material (Port09) Material Material Material Material (st09) format Inhalt (Port10) Inhalt Textinhalt Inhalt Inhalt (te07) subject.subject_heading subject.geographical_heading subject.personal_names Publ.Nr. (Port11) PublikationsL Publikation PublikationText Publikationsnummer (st08) source.publication_number Statische URL (Port12) - - - ?? identifier Weitere Links (Port13) * * * Referenzwerke (te28) - Freitext (Port14) alles alles alles alles alles Datum Erwerbung (Port15) erworben durch: Jahr Datum Fundort Kaufdatum (st06) subject.aquisition_supplier Text Erwerbung Fundort, erworben (Port 16) Name, Erw. Bem. durch: Erwerb Fundort Erwerbung (st06) Subject.aquisition_date + + Tabelle 6: Mapping der Datenfelder * Die entsprechenden Felder in den Datenbanken der Sammlungen Heidelberg, Bonn und Trier werden von diesen direkt eingetragen (Joker). Version 1.1.1 23 2.8 Harmonisierung Um eine möglichst effiziente Suche und eine korrekte Treffermenge zu erzielen, ist es sinnvoll, die Einträge in den verschiedenen lokalen Datenbanken für die Suche zu harmonisieren. Das folgende Beispiel mag verdeutlichen, wie unterschiedlich die Einträge in den lokalen Datenbanken sein können. Beispiel: Hermupolis Trier Heidelberg Bonn Giessen MyCoRe Hermupolis Hermupolis, Hermopolis - Hermu Polis Hermupolis Tabelle 7: Harmonisierung Die Differenzen zwischen den einzelnen Datenbanken auszugleichen, ist bei einer gleichzeitigen Suche über verschiedene Datenbanken sinnvoll, da ansonsten jede Möglichkeit separat gesucht werden müßte. Eine gemeinsame Anzeige aller Treffer wäre dann nicht möglich. Deswegen sollten die verschiedenen Versionen harmonisiert werden. Wie an diesem Beispiel auch sichtbar ist, können die Differenzen auch innerhalb einer Datenbank auftreten. Durch eine Harmonisierung der Daten erfolgt demnach auch eine qualitative Aufwertung der Inhalte der lokalen Datenbanken. 2.9 Korrekturen und Konkordanzen Um eine Harmonisierung unterschiedlicher Einträge in den lokalen Datenbanken zu erreichen, gibt es prinzipiell zwei Möglichkeiten: Korrektur vor Ort: Die Einträge in den lokalen Datenbanken werden durch Korrektur an den im 'Papyrus Portal' verwendeten Standard angeglichen. Damit wird gleichzeitig eine Datenpflege betrieben, die die Qualität der Inhalte der lokalen Datenbank verbessert. Konkordanz: In der Suchmaschine des 'Papyrus Portals' wird eine Konkordanz erstellt, die automatisch bei einer Suche im 'Papyrus Portal' neben dem Standardeintrag auch die Alternative sucht. Damit müssen in den lokalen Datenbanken keine weiteren Arbeiten vorgenommen werden. Außerdem würde auch der Arbeitsaufwand für derartige Dinge bei Teilnehmern am 'Papyrus Portal' mit den gleichen Phänomenen stark verringert werden. Nachtteilig wirken sich Konkordanzen in großer Masse allerdings auf die Suchgeschwindigkeit aus. Zudem kann die Trefferanzeige durch die vielen verschiedenen Varianten sehr uneinheitlich wirken. Da ein Standard in der Regel nur in den Feldern entwickelt wurde, die Klassifikationen enthalten, betrifft diese Harmonisierung vorrangig auch nur diese Felder. Nichtsdestotrotz erfordern vor allem auch die Datumsfelder einen Standard, damit sie von der Suchmaschine korrekt ausgewertet werden können. Hier bieten sich allerdings lediglich Korrekturen in den lokalen Datenbanken an, die den lokalen Datenbanken in derartigen Fällen auch mitgeteilt wurden. Die Konkordanzen sind den Klassifikationslisten (s.u.) zugeordnet. Bei einer Suche wird automatisch verglichen, ob es für einen Eintrag in der Klassifikationsliste auch einen Konkordanzeintrag vorhanden ist. Exisitiert er, wird er in die Suche einbezogen. Version 1.1.1 Im Folgenden werden die einzelnen Konkordanzlisten vorgestellt. Sie sind jederzeit erweiterbar, so daß auch weitere Varianten berücksichtigt werden können. Zu beachten ist, daß wie bei den unten beschriebenen Klassifikationen lediglich die Inhalte der am 'Papyrus Portal' beteiligten Sammlungsdatenbanken berücksichtigt wurden. Darüber hinaus ist keine Vollständigkeit angestrebt worden. 2.9.1 Konkordanz zur Klassifikationsliste des Materials Dateiname: PapyrusPortal_class_00000002.properties Klassifikationseintrag Konkordanz andere Bronze, Leder, Leinen, Rinde, Silber, Stein Ostrakon Ton Hadernpapier Papier Wachstafel Tabelle 8: Konkordanzliste Material Wachs 2.9.2 Konkordanz zur Klassifikationsliste der Textart Dateiname: PapyrusPortal_class_00000007.properties Klassifikationseintrag paraliterarisch Tabelle 9: Konkordanzliste Textart Konkordanz semi-literarisch, halbliterarisch 2.9.3 Konkordanz zur Klassifikationsliste der Sprache Dateiname: PapyrusPortal_class_00000009.properties Klassifikationseintrag Konkordanz Lateinisch Latein Hieroglyphisch Tabelle 10: Konkordanzliste Sprache Hieroglyphen 2.9.4 Konkordanz zur Klassifikationsliste des Ortes Dateiname: PapyrusPortal_class_00000011.properties Klassifikationseintrag Konkordanz Alexandria, Hauptstadt Ägyptens Alexandria, Alexandreia Ankyron Polis Ankyron, Ankyronon Antinoopolis Antinoupolis Apollonopolis Mikra Apollonospolis Mikra Apollonopolis Megale Apollonospolis Magna Apollonopolis Apollonos Polis Version 1.1.1 Athribis Atribis Berenikis Thesmophoru Berenike Thesmophoru Demetriu Epoikion Demetriu Euhemeria Euhemereia Kloster Hathor Hathor Hermupolis Hermopolis, Hermu polis Krokodilopolis Krokodilon Polis Philadelphia Philadelpheia Philopator Apiados Philopator Philopator alias Theogenes Philopator-Theogenes Samaria Samareia Theadelphia Theadelpheia Theben Diospolis Megale Temgenuthis Tegmenuthis Troia Tura Terythis Tabelle 11: Konkordanzliste Ort Therythis 2.9.5 Konkordanz zur Klassifikationsliste des Gaues Dateiname: PapyrusPortal_class_00000012.properties Klassifikationseintrag Konkordanz gaufrei Alexandria, Alexandreia Arsinoites Herakleidu Meris, Polemonos Meris, Themistu Meris außerhalb Ägyptens Tabelle 12: Konkordanzliste Gaues Iudaea, Griechenland 2.10 Klassifikationen Die Klassifikationen haben mehrere Funktionen. Zunächst sollen sie ganz sichtbar dem Benutzer vorgeben, was in den jeweiligen Feldern gesucht werden kann. Deshalb sind alle Einträge in den entsprechenden Feldern der einzelnen Datenbanken in die Klassifikationen aufgenommen worden. Somit enthält eine Klassifikation alles, was über das 'Papyrus Portal' in den einzelnen Datenbanken gefunden werden kann. Darüber hinaus wurden die Einträge in den Klassifikationen und den lokalen Datenbanken vereinheitlicht. (s. Korrektur und Konkordanzen) Dadurch können auch verschiedene Schreibweisen etc. eines Eintrages gleichzeitig gefunden werden. Gleichzeitig wird dem Benutzer die Suche erleichtert, da nun nicht mehr durch falsche Eingabe der Suchtermini falsche bzw. unvollständige Ergebnisse gefunden werden können. Die Klassifikationen sind jederzeit erweiterbar. Neue Einträge in den lokalen Datenbanken, die eine Änderung oder Ergänzung der Klassifikationen des 'Papyrus Portals' zur Folge haben, werden mit den Klassifikationen abgeglichen und führen zu deren Modifizierung und Ergänzung. Dies ist auch notwendig, weil der Datensatz mit den neuen Einträgen ansonsten über das 'Papyrus Portal' nicht gefunden werden kann. Version 1.1.1 Für die Anzeige der Treffer werden die Klassifikationen nicht mehr verwendet. Stattdessen wird immer der komplette Inhalt des entsprechenden Feldes des gefundenen lokalen Datensatzes ausgelesen und angezeigt. 2.10.1 Teilnehmende Sammlungen Dateiname: PapyrusPortal_class_00000001.xml Sammlung Bemerkungen Bonn FileMaker-Datenbank Giessen Allegro C (Hans) - Datenbank Halle Teil der MyCoRe-Datenbank Halle-Jena-Leipzig Heidelberg 3 separate FileMaker-Datenbanken Jena Teil der MyCoRe-Datenbank Halle-Jena-Leipzig Köln FileMaker-Datenbank – nicht online, Daten werden als statische Webseiten präsentiert, Beginn der Eingabe neuer Datensätze in eigenständige MyCoRe-Datenbank Leipzig Teil der MyCoRe-Datenbank Halle-Jena-Leipzig Tier FileMaker-Datenbank Würzburg Eigenständige MyCoRe-Datenbank Tabelle 13: Teilnehmende Sammlungen 2.10.2 Klassifikationsliste Sprache Dateiname: PapyrusPortal_class_00000009.xml Sprache Bemerkungen Arabisch Aramäisch Demotisch Gotisch Griechisch Hebräisch Hieratisch Hieroglyphisch Konkordanz: Hieroglyphen Koptisch Lateinisch Konkordanz: Latein Syrisch unidentifiziert "unidentifiziert" umfasst alles, was nicht identifiziert werden konnte oder keine Sprache ist (z.B. Fälschungen, Zeichnungen). Tabelle 14: Klassifikationsliste Sprachen Sonderfall: Ägyptisch Anstelle der Sprache "Ägyptisch" wurden deren Schriften aufgenommen, da in vielen Sammlungen zwischen Sprache und Schrift nicht unterschieden wird. Da sich eine Version 1.1.1 Konkordanz hier nicht schreiben läßt, sollte "Ägyptisch" nicht mehr als Sprache getragen werden bzw. nur in Verbindung mit der Angabe der Schrift (Doppelkodierung). 2.10.3 Klassifikationsliste Textart Dateiname: PapyrusPortal_class_00000007.xml Textart Bemerkungen dokumentatisch literarisch nicht bestimmbar paraliterarisch Konkordanz: semi-literarisch, halbliterarisch Tabelle 15: Klassifikationsliste Textart 2.10.4 Klassifikationslisten Herkunft Es gibt zwei Klassifikationslisten für die Herkunftsangaben: eine für den Gau und eine für den Ort. Aufgenommen wurde immer nur die griechischen Name, insb. für Attribute (Mikra etc.). Arabischen, koptischen und demotischen Namen wurden nicht berücksichtigt. Sie erscheinen in den lokalen Datenbanken auch nur sehr selten. Die historische Entwicklung wird auch nicht berücksichtigt, da dies einem data-mining gleichgekommen wäre. Das war aber im 'Papyrus Portal' nicht beabsichtigt. Deswegen sollten in zweifelhaften Fällen immer mehrere Namen eingetragen werden, z.B. Theben und Diospolis Magna. Solche Fälle tauchen aber in den lokalen Datenbanken kaum auf. Vorhandene Ortsteile wurden aufgenommen. Da keine data-mining vorgenommen wird, ist es allerdings anzuraten, jeweils den Ortsteilname und den Ortsname anzugeben, z.B. Iuliopolis und Alexandria, damit der Datensatz auch bei einer Suche nach dem Ortsnamen gefunden werden kann. Außer den drei arsinoitischen Merides werden keine weiteren Gauteile aufgenommen. 2.10.4.1 Klassifikationsliste Herkunft Gau Dateiname: PapyrusPortal_class_00000012.xml Gauname Ägypten Bemerkungen "Ägypten" ist aufgenommen worden, weil es in einigen Datenbanken erscheint. Es sollte aber nicht mehr verwendet werden und möglichst durch genauere Angaben ersetzt werden. Außerdem kann man in diesen Fällen immer noch "unbekannt" kodieren. Eine Konkordanz läßt sich hier nicht anwenden. Antaiopolites Antinoopolites Aphroditopolites Apollonopolites Apollonopolites Heptakomias Arkadia Arsinoites Version 1.1.1 Konkordanz: Herakleidu Meris, Polemonos Meris, Themistu Meris Athribites Bubastites Diopolites Mikros Eileithyiopolites Heliopolites Herakleidu Meris Herakleopolites Hermonthites Hermopolites Hypselites Koptites Kynopolites Latopolites Letopolites Lykopolites Memphites Mendesios Oasis Megale (Oasites) Oasis Mikra (Oasites) Oberägypten "Oberägypten" ist aufgenommen worden, weil es in einigen Datenbanken erscheint. Es sollte aber nicht mehr verwendet werden und möglichst durch genauere Angaben ersetzt werden. Außerdem kann man in diesen Fällen immer noch "unbekannt" kodieren. Eine Konkordanz läßt sich hier nicht anwenden. Ombites Oxyrhynchites Panopolites Pathyrites Peri Thebas Polemonos Meris Prosopites Tanites Tentyrites Thebais Themistu Meris Thinites unbekannt gaufrei Konkordanz: Alexandria, Alexandreia nicht zuordenbar "nicht zuordenbar" steht für Orte, die in mehreren Gauen vorkommen und für die keine konkrete Zuordnung getroffen werden kann. Das sollte aber möglichst die Ausnahme bleiben, da man für Orte, wo es nur wenige (z.B. 3 oder 4) Gaue als Möglichkeiten gibt, auch einfach eine Liste dieser Gaue verwenden könnte, so daß diese Datensätze bei einer Suche nach den Gauen gefunden werden können. außerhalb Ägyptens Konkordanz: Iudaea, Griechenland Tabelle 16: Klassifikationsliste Herkunft Gau Version 1.1.1 2.10.4.2 Klassifikationsliste Herkunft Ort Dateiname: PapyrusPortal_class_00000011.xml Ortsname Bemerkungen Akanthon Polis Akoris Alabanthis Alexandria, Hauptstadt Ägyptens Konkordanz: Alexandria, Alexandreia Ammonias Andromachis Ankyron Polis Konkordanz: Ankyron, Ankyronon Antaiupolis Antinoopolis Konkordanz: Antinoupolis Anubias Apa-Apollon Kloster zu Bawit Aphrodites Polis Aphrodito Apias Apollonopolis s. Calderini, Alternative: Apollonos Polis Apollonopolis Heptakomias Apollonopolis Megale Konkordanz: Apollonospolis Magna Apollonopolis Mikra Konkordanz: Apollonospolis Mikra Areos Kome Arsinoe Arsinoiton Polis Athribis Konkordanz: Atribis Babylon Bakchias Berenikis Thesmophoru Konkordanz: Berenike Thesmophoru Bompae Bubastos Bukolon Kome Demetriu Epoikion Konkordanz: Demetriu Dinnis Diokletianupolis Dionysias Diospolis Megale Eileithyias Polis Elephantine Euergetis Euhemeria Version 1.1.1 Konkordanz: Euhemereia Heliu Kome Hephaistias Herakleonos Epoikion Herakleopolis Hermonthis Hermupolis Konkordanz: Hermopolis, Hermu polis Hiera Nesos Hypsele Ibion Itos Iuliopolis Ortsteil von Alexandria, immer auch „Alexandria“ eintragen Kaine Kaisareia Kaminon Kanopos Karanis Kerke Kerkeesis Kerkeosiris Kerkesephis Kerkesucha Kerkesucha Orus Kerkeura Kloster Hathor Konkordanz: Hathor Koba Koptos Krokodilopolis Latopolis Leukogion Leukos Pyrgos Lykopolis Machor Magdola Mire Memnonia Memphis Mendes Mermertha Metne Moeris Moithymis Monimu Mothis Naboo Version 1.1.1 Konkordanz: Krokodilon Polis Nebna Nemaris Nesla Nesoi Neson Kome Nikopolis Ortsteil von Alexandria, immer auch „Alexandria“ eintragen Omboi Ophis Oxyrhyncha Oxyrhynchos Pakerkeesis Pallos Panopolis Papa Papa megale Pathyris Peenno Pekty Pela Pelusion Pentakomia Pesla Petne Pharbaithos Phathor Phebichis Philadelphia Konkordanz: Philadelpheia Philopator alias Theogenes Konkordanz: Philopator-Theogenes Philopator Apiados Konkordanz: Philopator Philoteris Phnebieus Phobou Phys Pois Psenaryo Psenbelakai Psenbelaki Psenbella Psenbelochis Ptolemais Ptolemais Euergetis Ptolemais Hermiu Ptolemais Hormu Version 1.1.1 Samaria Konkordanz: Samareia Seryphis Sesphtha Side Sinary Sinkepha Soknopaiu Nesos Styra Syene Syron Kome Talao Talei Tamais (Tamauis) Tanais Tanis Tanyaithis Tarrhuthis Tebetny Tebtynis Temgenuthis Ortsteil von Oxyrhynchos, immer auch „Oxyrhynchos“ eintragen, Konkordanz: Tegmenuthis Temseu Skordon Tentyra Terenuthis Tertembythis Tertonpsembe Terythis Teslot (Tachlut) Theadelphia Konkordanz: Theadelpheia Theben Konkordanz: Diospolis Megale Theodosiopolis Theogonis Theoxenis Thesmophoriu amphodon Ortsteil von Arsinoe, immer auch „Arsinoe“ eintragen Tholthis Tinteris Tisichis Tou Troia Konkordanz: Tura unbekannt Tabelle 17: Klassifikationsliste Herkunft Ort Version 1.1.1 2.10.5 Klassifikationsliste Material Dateiname: PapyrusPortal_class_00000002.xml Textart andere Bemerkungen "andere" ist die Sammelkategorie, die alle Materialien aufnimmt, die entweder zu selten vorkommen, um einzeln verzeichnet zu werden, oder noch gar nicht aufgenommen wurden. Konkordanz: Stein, Bronze, Leder, Leinen, Rinde, Silber. Blei Hadernpapier Konkordanz: Papier Holz Ostrakon Konkordanz: Ton Papyrus Pergament unbekannt Wachstafel Konkordanz: Wachs Tabelle 18: Klassifikationsliste Material Version 1.1.1 3 Glossar Harvesting Als Harvesting, also eine Ernte, bezeichnet man ein Verfahren bei dem Daten durch ein Leseverfahren von räumlich entfernten Servern eingesammelt werden. Die so gewonnenen Daten werden nun als Dienst Clients zur Verfügung gestellt. Bekanntester Vertreter ist das OAI-Projekt. Metadaten Unter Metadaten sind alle zum eigentlichen Objekt (in diesem Falle Papyri oder Dokumente) gehörenden beschreibenden Daten zu physikalischen und inhaltlichen Angaben zu verstehen. Servlet-Engine Servlets sind Programmteile, welche mit einen Web-Browser kommunizieren können und dynamische Web-Inhalte erzeugen. Die Servlet-Engine steuert den Zugriff auf die darin konfigurierten Servlets. Typische Vertreter sind die Projekte Tomcat und Jetty. Version 1.1.1 4 Anhang 4.1 Projektbeteiligte 4.1.1 Projektleitung Herr Prof. Dr. Reinhold Scholl, Leiter des Projektes Universitätsbibliothek Leipzig, Universität Leipzig [email protected] Herr Dipl.-Inf. Jens Kupferschmidt, IT Verantwortlicher des Projektes Universitätsrechenzentrum, Universität Leipzig [email protected] 4.1.2 Mitarbeiter Herr Marius Gerhardt, M.A., Wissenschaftlicher Mitarbeiter Universitätsbibliothek, Universität Leipzig [email protected] Herr Dipl.-Inf. Stefan Freitag, Informatiker Universitätsbibliothek, Universität Leipzig [email protected] 4.1.3 Design Frau Marianne Schiller, Designerin Thüringer Universitäts- und Landesbibliothek Jena 4.1.4 Hilfskräfte Frau Margit Homann, B.A., Studentische Hilfskraft Universitätsbibliothek, Universität Leipzig Herr Frank Ursin, Studentische Hilfskraft Universitätsbibliothek, Universität Leipzig Herr Abde Ssamad Karmoun, Studentische Hilfskraft Universitätsbibliothek, Universität Leipzig 4.1.5 Antragsteller Herr Prof. Dr. Andreas Mehl, Institut für Altertumswissenschaften, Universität Halle Version 1.1.1 Herr Prof. Dr. Ulrich Schneider, Universitätsbibliothek Leipzig, Universität Leipzig Herr Prof. Dr. Reinhold Scholl, Universitätsbibliothek Leipzig, Universität Leipzig Herr Prof. Dr. Rainer Thiel, Institut für Altertumswissenschaften, Universität Jena Frau Dr. Sabine Wefers, Thüringer Universitäts- und Landesbibliothek Jena Version 1.1.1 4.2 Checkliste für momentane und zukünftige Teilnehmer am 'Papyrus Portal' 1. Technische Anforderungen (s. auch Client Dokumentation) kompatible Datenbank mit JDBC-Schnittstelle (z.B. FileMaker Pro/Server) oder Content Repository System (z.B. MyCoRe) schnelle Internetanbindung (mind. 768kBit/s) offene Kommunikationsstruktur konfigurierbare Firewall keine sonstige Barrieren oder Einschränkungen (z.B. vonseiten vorgeschalteter Institutionen wie Rechenzentrum) Datenbank muß immer online aktiv sein 2. Inhaltliche Anforderungen (s. auch Portaldokumentation) Erstellung eines Feldmappings (Feldzuordnungen) zwischen Datenbankfeldern und Portalfeldern Übernahme der Portal-Klassifikationen für die relvanten Felder – Mitteilung von Ergänzungen (insb. für die Konkordanzen) Normalisierung der Datumsangaben Angabe von Tag, Monat, Jahr oder Jahrhundert Datierungsbeginn und Datierungsende (von ... bis ...) Grundsätzlich ist eine enge Absprache mit Portalbetreiber notwendig. Version 1.1.1 4.3 Client Dokumentation 4.3.1 Zusammenfassung Dieses Programm wurde für die Anbindung einer Filemaker-Datenbank an das MyCoReSystem entwickelt. Über den mitgelieferten JDBC-Treiber der Filemaker-Datenbank werden die Daten über Standard-SQL-Befehle abgerufen. Eine TCP/IP-Verbindung realisiert den Datenaustausch mit der entfernten MyCoRe-Anwendung 'Papyrus Portal'. Dieses Programm kann ausschließlich lesend auf die Datenbank zugreifen. Es werden keine Modifikationen, Updates, Löschungen oder anderweitige datenmanipulierende Zugriffe auf die Datensätze unterstützt oder ausgeführt. 4.3.2 Installation des Clients Das Clientprogramm benötigt für den Betrieb eine Java Virtual Machine (JVM). Bei den meisten Computersystemen ist eine JVM bereits vorinstalliert. Sie können dies über den Befehl „java -version“ in der Kommandokonsole überprüfen. Sollte hier keine Version gefunden werden, so können Sie das Java-Paket aus dem Internet manuell nachinstallieren (http://java.sun.com). Das Clientprogramm selbst kann bequem per Doppelklick auf die entsprechende JAR-Datei installiert werden (client-Sammlungsname-install.jar). Danach erfolgt eine teilautomatisierte interaktive Installation. Hier haben Sie die Möglichkeit einen Installationspfad zu wählen und Entscheidungen über die Installationsauswahl zu treffen (Core Kern, erforderlich; Source Quellcode, nicht erforderlich). 4.3.3 Einstellungen der Filemaker-Datenbank Damit eine Kommunikation zwischen Client und Datenbank stattfinden kann, müssen Einstellungen im Filemaker-Programm getroffen werden. Abbildung 6: Menüauswahl für das JDBC-Sharing Version 1.1.1 Abbildung 6 zeigt den Auswahlpunkt „ODBC/JDBC“ im Menü „Datei“. Die FilemakerDatenbank besitzt die Möglichkeit, Informationen aus einer Datenbank über eine Schnittstelle anzubieten. Diese Option muss allerdings vorher aktiviert werden. Öffnen Sie dazu die Datenbank(en) und rufen Sie das ODBC/JDBC-Menü aus dem Sharing-Bereich auf. Hier finden Sie zunächst die geöffneten Datenbanken im linken Fenster. Wählen Sie nun die Datenbanken aus und stellen Sie den Schalter „ODBC/JDBC-Sharing“ auf „Ein“ (siehe Abbildung 4). Abbildung 7: Sharing-Fenster (ohne geöffnete Datenbank) Für den Betrieb sind zusätzlich die Tabellennamen der Datenbanken relevant (siehe Punkt 4.3.4: Konfiguration des Clients). Abbildung 8: Datenbankverwaltung Um den Tabellennamen zu identifizieren rufen Sie das Menü „Datei“ mit dem Unterpunkt „Verwalten“ auf. Wählen Sie dort den Eintrag „Datenbank“. Sie erhalten dann ein ähnliches Fenster wie inAbbildung 8 zu sehen ist. Im Reiter „Felder“ erscheint oben im Pulldown-Menü der Tabellenname. Er wird zwingend für die Konfiguration des Clients benötigt. 4.3.4 Konfiguration des Clients Die Client-Programme für die jeweiligen Sammlungen sind bereits vorkonfiguriert. Einzig die Angaben für den Benutzernamen, das Passwort und der Datenbank-Tabellenname sind nachzutragen. Nach dem ersten Start des Clients erscheint dafür ein Popup-Fenster mit einer kurzen Beschreibung. Hier lautet die Abfolge: „username“, „password“ und „database“. Für die Sammlung in Heidelberg folgt zudem noch die Abfrage für „database2“ und „database3“. Version 1.1.1 Neben den genannten Einstellungen existiert eine Konfiguration für die Feldnamen innerhalb der Datenbanken. Dies ist bei der Auslieferung bereits fest eingerichtet. Sollte es eine inhaltstechnische Änderung an der Datenbankstruktur geben, so kann hier eine Korrektur durchgeführt werden. Eine detailierte Feldnamenauflistung findet sich unter Punkt 5: Technische Informationen. In der Konfiguration existieren zwei „Joker“-Feldnamen, die momentan keine Belegung besitzen. Sollte im Laufe des Projektes die Notwendigkeit einer zusätzlichen Feldinhaltsausgabe auftreten, so kann mittels eines Jokers die Ausgabe und Abfrage realisiert werden. 4.3.5 Starten des Clients Abbildung 9: Das Popup-Fenster erwartet den Benutzernamen. Im Installationsverzeichnis des Clientprogramms findet sich ein Unterordner „bin“. Über die dortige Datei „clientstart.jar“ kann via Doppelklick der Client aktiviert werden. Achten Sie bitte darauf, dass die Filemaker-Datenbank(en) vor dem Start des Clients arbeiten. Andernfalls informiert Sie das Clientprogramm mit einer Popup-Warnung über die fehlende Datenquelle. Sobald die Datenbank(en) gestartet sind, nimmt der Client dann seine Arbeit wieder auf. Beachten Sie bitte auch, dass der Client manuell nach einem Neustart des Computers gestartet werden muss. Selbstverständlich besteht die Möglichkeit die „clientstart.jar“ automatisiert aufrufen zu lassen. Von der Installation her ist dies aber nicht vorgesehen. Für einen korrekten Betrieb des Clients werden vier offene Ports zum Internet benötigt. In Punkt 4.3.6: Technische Informationen finden Sie die genauen Portnummern. Die Arbeit des Clients können Sie mit Hilfe einer integrierten Monitoring-Anwendung kontrollieren. Nach dem erfolgreichen Start des Clientprogramms kann der Monitor über einen Browser und der Adresse http://localhost:55556 erreicht werden. Sollte hier keine Seite verfügbar sein lässt dies auf eine Fehlfunktion des Clients schließen. 4.3.6 Technische Informationen 4.3.6.1 Zuweisung von Feldern aus der Datenbank Das Papyrusportal erfasst 13 Feldern für die Anzeige von gefundenen Datensätzen. Dazu zählt: - Inventarnummer - Sammlung - Sprache - Textart - Titel Version 1.1.1 (suchbar) (suchbar; kein Feld, wird vom Portal vorgegeben) (suchbar) (suchbar) (suchbar) - Datierung - Herkunft-Gau - Herkunft-Ort - Material - Inhalt - Publikationsnummer - Statischer Link - Weitere Links - Erwerbungsdatum - Erwerbungstext (suchbar) (suchbar) (suchbar) (suchbar) (suchbar) (suchbar, aber standardmäßig nicht anzeigbar) (suchbar, aber standardmäßig nicht anzeigbar) Um über den Client an die Daten zu gelangen, wird über die JDBC-Schnittstelle eine SQLVerbindung aufgebaut. Jedes Datenfeld besitzt eine spezielle Identifikationsnummer, über die dann die Feldinhalte zugreifbar sind. Dabei kann diese ID von Sammlung zu Sammlung unterschiedlich sein, abhängig von dem strukturellen Aufbau der Datenbank. Eine Zuordnung zwischen Feldname und Identifikationsnummer befindet sich in der „config_sammlung.xml“-Datei („sammlung“ steht für die jeweilige Institution), die sich im „config“- Ordner befindet. Diese stellt sich wie folgt dar: <?xml version="1.0" encoding="UTF-8"?> <configuration> <dating params/> <language params/> <inventory_number>value</inventory_number> <collection>value</collection> <type_of_text>value</type_of_text> <title>value</title> <provenance_place>value</provenance_place> <provenance_area>value</provenance_area> <material>value</material> <content>value</content> <publication>value</publication> <joker1>value</joker1> <joker2>value</joker2> <sharpness>value</sharpness> <acquisition_text>value</acquisition_text> <acquisition_text2>value</acquisition_text2> <acquisition_text3>value</acquisition_text3> <acquisition_date>value</acquisition_date> </configuration> Eine besondere Rolle spielen die „acquisition“-Einträge. Generell spezifizieren diese Felder die Erwerbungssuche. Zu beachten ist hier, dass im Client alle vier Felder zu einem Suchstring zusammengefasst bearbeitet werden. So lässt sich die unterschiedliche Informationstiefe der einzelnen Sammlungen ausgleichen. Die gefundenen Informationen werden nur als allgemeiner Datensatz ausgegeben. Sollten Ausgaben zu den gesuchten Erwerbungsfeldern gewünscht werden, so sind diese über die Joker-Felder zu benennen. 4.3.6.2 Einstellen der Suchschärfe Version 1.1.1 In der Datei „config_sammlung.xml“ befindet sich neben den Einträgen für die Suchfelder auch ein Eintrag für die Genauigkeit der Datumssuche. Das Schlüsselwort „sharpness“ definiert die Toleranz, die bei der Suche nach einer Datierung hinzugefügt werden soll. Die Portalbetreiber haben eine Null-Toleranz festgelegt; jede Suche befindet sich damit in exakt den eingegebenen Grenzen. Eine Änderung des voreingestellten Wertes bewirkt eine Grenzverschiebung um die angegebene Zahl in Jahren. Die Einstellung „<sharpness>10</sharpness>“ modifiziert beispielsweise die Suchgrenzen um jeweils 10 Jahre. Das heißt 10 Jahre vor dem eingegebenen Start-Datum und 10 Jahre nach dem eingegebenen End-Datum. 4.3.7 Die Properties-Datei Im „config“-Ordner befindet sich neben der Konfigurationsdatei „config-sammlung.xml“ auch die „properties.xml“-Datei. Diese enthält alle relevanten Informationen über die Datenbankanbindung. Im Einzelnen sind das der Benutzername, das Passwort und der/die Datenbankname(n). <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"> <properties> <comment>Propertylist for database used by client.</comment> <entry key="password">password</entry> <entry key="database3"/> <entry key="database2"/> <entry key="database">UB_Sammlung</entry> <entry key="username">username</entry> </properties> 4.3.8 Datenanbindung zwischen Client und Portal Die Kommunikation zwischen dem Portalserver in Leipzig und den angeschlossenen Clients erfolgt über das Hypertext Transfer Protocol (HTTP) und das Transmission Control Protocol / Internet Protocol (TCP/IP). Für einen reibungslosen Betrieb benötigt das Clientprogramm vier offene Ports auf diesen Protokollen: Port Nutzung Protokoll 55554 Datensatzbereitstellung HTTP 55555 Portal-Datenbank-Zugang TCP/IP 55556 Monitoring HTTP 55557 Debug-Schnittstelle TCP/IP Normalerweise sollten diese Ports standardmäßig offen sein. Durch den Einsatz von Firewalls oder durch die Rechenzentren kann es aber sein, dass kein Zugriff möglich ist. Bitte wenden Sie sich in diesem Fall an das Rechenzentrum Ihrer Institution und/oder prüfen Sie die Einstellung ihrer Firewall. Version 1.1.1 4.3.9 Datenbankzugriffe Filemaker benötigt für eine Datenbereitstellung über JDBC-Schnittstelle einen Benutzernamen und ein Passwort für eine Datenbank, die über den Tabellennamen definiert wird. Diese Informationen werden beim ersten Start des Clients von Ihnen abgefragt und in der Datei „properties.xml“ im „config“-Ordner gespeichert. Sollte eine nachträgliche Änderung vorzunehmen sein, dann löschen Sie bitte die Datei komplett, oder modifizieren Sie die dort befindlichen Einträge. Beachten Sie bitte, dass das Datenbank-Passwort im Klartext in der Datei gespeichert ist. Dies erfolgt aus technischen Gründen. Die Betreiber des 'Papyrus Portals' oder der Entwickler des Clientprogrammes haben jedoch keinerlei Kenntnis oder Möglichkeit, dieses Passwort auszulesen. Der Zugriff auf die Datensätze erfolgt im Client über die Structured Query Language (SQL). Die Suchanfragen werden in Echtzeit mit den Datensätzen abgeglichen. Bei dem Programmstart des Clientprogrammes wird eine Inventarliste erzeugt, die eine Zuordnung zwischen Inventarnummer und Datensatzidentifikationsnummer enthält. Hierüber werden später die Anfragen für die Trefferlisten vom Portal beantwortet. In Abhängigkeit der Anzahl der Datensätze und der Rechnerperformance kann die Erstellung der Liste einige Sekunden beanspruchen. Die Clients können ausschließlich lesend auf die Datensätze zugreifen. Es sind keine Methoden für manipulative Interaktionen mit den Daten integriert. Version 1.1.1 Tabellenverzeichnis Tabelle 1: Beteiligte Papyrussammlungen ..............................................................................................................7 Tabelle 2: Beteiligte Lokationen und die verwendeten Betriebssysteme .............................................................. 12 Tabelle 3: Beteiligte Datenbanktypen ................................................................................................................... 13 Tabelle 4: Beteiligte Datenbanktypen und ihre Anbindung .................................................................................. 17 Tabelle 5: Such- und Anzeigefelder für das 'Papyrus Portal' ................................................................................ 19 Tabelle 6: Mapping der Datenfelder ..................................................................................................................... 23 Tabelle 7: Harmonisierung .................................................................................................................................... 24 Tabelle 8: Konkordanzliste Material ..................................................................................................................... 25 Tabelle 9: Konkordanzliste Textart ....................................................................................................................... 25 Tabelle 10: Konkordanzliste Sprache ................................................................................................................... 25 Tabelle 11: Konkordanzliste Ort ........................................................................................................................... 26 Tabelle 12: Konkordanzliste Gaues ...................................................................................................................... 26 Tabelle 13: Teilnehmende Sammlungen ............................................................................................................... 27 Tabelle 14: Klassifikationsliste Sprachen ............................................................................................................. 28 Tabelle 15: Klassifikationsliste Textart................................................................................................................. 28 Tabelle 16: Klassifikationsliste Herkunft Gau ...................................................................................................... 30 Tabelle 17: Klassifikationsliste Herkunft Ort ....................................................................................................... 34 Tabelle 18: Klassifikationsliste Material ............................................................................................................... 34 Version 1.1.1 Abbildungsverzeichnis Abbildung 1: Allgemeiner Ablauf der Suche ...........................................................................................................8 Abbildung 2: Hauptseite des 'Papyrus Portals' .........................................................................................................9 Abbildung 3: Kurzbeschreibung der Leipziger Papyrus- und Ostrakasammlung .................................................. 10 Abbildung 4: Schema des verteilten Zugriffes ....................................................................................................... 16 Abbildung 5: Schematische Darstellung der Clientanbindung............................................................................... 18 Abbildung 6: Menüauswahl für das JDBC-Sharing ............................................................................................... 39 Abbildung 7: Sharing-Fenster (ohne geöffnete Datenbank)................................................................................... 40 Abbildung 8: Datenbankverwaltung ...................................................................................................................... 40 Abbildung 9: Das Popup-Fenster erwartet den Benutzernamen. ........................................................................... 41 Version 1.1.1
![Papyrus Portal - [svnextern.dl.uni-leipzig.de] Index of](http://s1.studylibde.com/store/data/005821446_1-017866f36a0d0fedc567cfc32ad44542-300x300.png)
