software-vergleich museumsdokumentation
Transcription
software-vergleich museumsdokumentation
SOFTWARE-VERGLEICH MUSEUMSDOKUMENTATION 1998 Ein Bericht der Arbeitsgruppe Software-Vergleich in der Fachgruppe Dokumentation beim Deutschen Museumsbund Impressum Software-Vergleich Museumsdokumentation 1998 Ein Bericht der Arbeitsgruppe Software-Vergleich in der Fachgruppe Dokumentation beim Deutschen Museumsbund Konzept und Texte: Arbeitsgruppe Software-Vergleich in der Fachgruppe Dokumentation beim Deutschen Museumsbund Klaus Bulle, Oldenburg (Old) Manfred Hartmann, Münster Marion Karls, Lindlar Cordula Peper, Koblenz Viktor Pröstler, München Klaus Ruwisch, Oldenburg (Old) Regine Scheffel, München unter Mitarbeit von Christina Pohl, Münster Veranstaltung Software-Vergleich vom 26.01.1998 bis zum 04.02.1998 in Münster, Westfalen Organisatorische Durchführung: Westfälisches Museumsamt, Münster Landschaftsverband Westfalen-Lippe Manfred Hartmann Christina Pohl Günter Bernhardt Redaktion: Regine Scheffel Marion Karls Manfred Hartmann Christina Pohl Günter Bernhardt Klaus Ruwisch Layout: Klaus Ruwisch Marion Karls Herausgeber: Westfälisches Museumsamt, Münster Landschaftsverband Westfalen-Lippe Institut für Museumskunde, Berlin Staatliche Museen zu Berlin Preußischer Kulturbesitz Materialien aus dem Westfälischen Museumsamt Bd. 2 Alle Rechte vorbehalten © 1998 Landschaftsverband Westfalen-Lippe Westfälisches Museumsamt Schwelingstr. 5 48145 Münster ISBN 3-927204-49-8 Inhaltsverzeichnis Geleitworte.............................................................................................................................................4 Einleitung .............................................................................................................................................. 7 Getestete Programme Kurzbeschreibungen und Protokolle allegro-HANS........................................................................................................................ 12 CMB Storager 2.2.................................................................................................................. 14 Dada 3.0 ................................................................................................................................ 16 Dr.Doc 4.1 .............................................................................................................................18 FAUST 3 ............................................................................................................................... 20 FirstRumos 97.......................................................................................................................22 GOS 3.7 ................................................................................................................................ 24 HiDA3 .................................................................................................................................. 26 ImageFinder Museo 2.0 ...................................................................................................... 28 IMDAS -Pro 1.0.0 ................................................................................................................ 30 M-BOX 2.1.............................................................................................................................32 MOVplus ...............................................................................................................................34 robotron*BIDOK/M ............................................................................................................ 36 Tabellen ...................................................................................................................................... 38 Nicht getestete Programme Kurzbeschreibungen AUGIAS-Museum 3.0.......................................................................................................... 64 DAVID 1.0 ............................................................................................................................ 64 LARS .....................................................................................................................................65 MuseArch 3.0........................................................................................................................65 Museumsverwaltung 3.11 .....................................................................................................65 MUSYS ................................................................................................................................. 66 Tabellen .......................................................................................................................................67 Glossar ............................................................................................................................................... 77 Anhang Kontaktadressen......................................................................................................................... 85 Checkliste.................................................................................................................................... 86 3 Geleitworte Geleitwort der Herausgeber Museen und Museumsberater stehen seit Einführung der EDV für das Sammlungsmanagement vor der Frage nach der geeigneten Software, die möglichst vielen individuellen Anforderungen der unterschiedlichen Nutzer gerecht wird. Dabei sind die Angaben der Hersteller oft so vollmundig wie verwirrend (und einer ernsthaften Nachprüfung nicht immer standhaltend). Auch die Erarbeitung von präzisen und vertraglich nachprüfbaren Nutzeranforderungen in den einzelnen Museen scheint nicht überall optimal gelungen zu sein. Die von der FACHGRUPPE DOKUMENTATION im Deutschen Museumsbund vorgelegte Publikation stellt die Ergebnisse eines kürzlich durchgeführten bundesweiten Softwarevergleichs vor, der seine erste Qualität in der Definition von vergleichbaren Nutzeranforderungen hat. Auf dieser Grundlage wurden Testkriterien entwickelt, die allen Anbietern vorab mitgeteilt worden sind. Das Testverfahren selbst war in jeder Hinsicht objektiv und fair; jeder Anbieter hatte Gelegenheit, sich auf den Softwarevergleich vorzubereiten und in einer Präsentation die Stärken seines Produkts und dessen mögliche Einsatzfelder ausgewiesenen Fachleuten des computergestützten Sammlungsmanagements ausführlich zu erläutern. Die Publikation endet bewußt nicht mit Verkaufsempfehlungen oder einer Hitliste, weil zum einen die Programme inhaltlich und technisch ganz verschiedenen ‘Philosophien’ folgen. Zum anderen muß nach unserer Überzeugung jedes Haus aufgrund seiner individuellen Anforderungen, seiner technischen Möglichkeiten und seiner eigenen Kapazitäten über die jeweils geeignete Software selbst entscheiden. Die nachstehenden Angaben zu den Software-Produkten werden ohne Gewähr der Herausgeber publiziert. Damit ist jede Haftung der Herausgeber für die Richtigkeit der Angaben zu einzelnen Produkten ausgeschlossen. Münster / Berlin 1998 Helmut Knirim Westfälisches Museumsamt Landschaftsverband Westfalen Lippe Bernhard Graf Institut für Museumskunde Staatliche Museen zu Berlin-Preußischer Kulturbesitz 4 Geleitwort Deutscher Museumsbund – FACHGRUPPE DOKUMENTATION Das Angebot an museumsspezifischer Dokumentations-Software ist für die Nutzer sehr schwer einzuschätzen. Nicht alle Anbieter geben in ihren Werbe-Ankündigungen die Informationen, die für eine sachgerechte Entscheidung für die Einführung oder Nutzung einer Software von Bedeutung sind. Die ARBEITSGRUPPE SOFTWARE-VERGLEICH in der FACHGRUPPE DOKUMENTATION hat sich über einen längeren Zeitraum hin intensiv mit der Frage nach geeigneter Software für die Museumsdokumentation beschäftigt. Der hier vorgelegten Publikation ist zu entnehmen, daß sich diese Frage auch mit Hilfe dieses Berichtes nicht sofort beantworten läßt, sondern daß die Entscheidung, welche Software für die jeweiligen Anforderungen die geeignetste ist, doch immer noch selbst getroffen werden muß. Die Publikation soll hierbei Hilfestellung geben. Erst wenn die Museen ihre eigenen Anforderungen ganz klar formuliert haben, ist es den Software-Herstellern möglich, fundierte Angebote zu machen. Es ist mir ein großes Anliegen, den Mitgliedern der ARBEITSGRUPPE SOFTWARE-VERGLEICH für das Engagement, mit dem sie sich dem manchmal mühseligen und immer zeitaufwendigen Vorhaben gewidmet haben, zu danken. Es galt nicht nur, einen Überblick über derzeit im Einsatz befindliche Software für Museumsdokumentation zu gewinnen, sondern auch eine eigene Methode zu entwickeln, mit der über die Zusammenstellung hinaus relevante Beurteilungskriterien gewonnen werden konnten. Dank der Unterstützung durch die Arbeitgeber und dem Einsatz von sehr viel persönlicher Freizeit aller Beteiligten ist dies überzeugend gelungen. Unser Dank gilt aber auch den Software-Anbietern, die sich geduldig und kooperativ diesem Verfahren stellten und damit dabei halfen, einen ersten Schritt in Richtung auf eine größere Markttransparenz zu tun. Ich hoffe, daß der Bericht der ARBEITSGRUPPE SOFTWARE-VERGLEICH den Museen dabei hilft, sachlich begründete Entscheidungen zu treffen, und daß er nicht zuletzt die Software-Anbieter ermutigt, sich noch stärker um museumstypische Anforderungen zu kümmern und geeignete “Werkzeuge“ dann in ihre Programme einzubinden. Monika Hagedorn-Saupe Sprecherin der Fachgruppe Dokumentation im Deutschen Museumsbund Juli 1998 5 Geleitwort der ARBEITSGRUPPE SOFTWARE-VERGLEICH Im Jahre 1994 hat sich unter dem Dach des Deutschen Museumsbundes die FACHGRUPPE DOKUMENTATION gegründet. Der neue organisatorische Rahmen war eine willkommene Aufforderung, die immer drängendere Frage nach der Qualität von Dokumentationssoftware für Museen anzugehen. Deshalb beschlossen einige Mitglieder der Fachgruppe, sich in einer ARBEITSGRUPPE SOFTWARE-VERGLEICH zu engagieren. Wenn wir damals gewußt hätten, welch’ steiniger Weg vor uns lag - wir hätten es hoffentlich dennoch angepackt! Es war ja methodisches Neuland, das da betreten wurde, denn für ein derartiges Unternehmen gab es im deutschen Museumswesen bislang kein Vorbild. Softwarevergleiche beschränkten sich bis dato auf eine kleine Programmauswahl und beruhten in der Regel allein auf den vom Anbieter veröffentlichten Angaben. Die Arbeitsgruppe dagegen erstellte eigenständig ein Testinstrumentarium, auf dessen Grundlage der Vergleich dann durchgeführt wurde. Freudig begrüßte sie dabei manchen neuen methodischen Ansatz - und legte ihn oft nach langer Diskussion wieder ad acta, weil er sich so in der Praxis nicht umsetzen ließ. Viele Ideen aber entpuppten sich als durchaus konsistent und prägen die vorliegende Publikation. Wir alle haben dabei viel gelernt und Lernen macht ja dann am meisten Spaß, wenn das Ziel deutlich vor Augen steht. Geholfen haben uns neben den in der folgenden Einleitung erwähnten Personen auch Thomas Rosemann, HansH. Clemens, Christof Wolters und Carlos Saro, die in der Gründungsphase unserer Gruppe dabei waren. Ohne die freundlichen Gastgeber an den verschiedenen Sitzungsorten hätten wir uns nicht auf die Arbeit konzentrieren können. Dank also an die Landesstelle für die Nichtstaatlichen Museen Bayerns in München, das Bayerische Nationalmuseum in München, das Landesmuseum in Koblenz, das Bergisches Freilichtmuseum für Ökologie und bäuerlich-handwerkliche Kultur, das Landesmuseum für Technik und Arbeit in Mannheim, das Westfälische Museumsamt in Münster, die Landesstelle für Museumsbetreuung Baden-Württemberg in Stuttgart und nicht zuletzt an Klaus Ruwisch in Oldenburg, der uns nicht nur einmal mit seinen Kochkünsten verwöhnte. Gerne bedanken wir uns auch beim Landschaftsverband Westfalen-Lippe in Münster, der der Arbeitsgruppe für die Testveranstaltung vom 26. Januar bis 4. Februar 1998 Räumlichkeiten und Support zur Verfügung stellte. Für den organisatorischen Rahmen sorgten das Westfälische Museumsamt sowie Hans Poplutz und Olaf Schönfeld vom verbandszugehörigen Zentrum für Informationstechnologie. Dankbar sind wir auch dem Westfälischen Museumsamt und dem Institut für Museumskunde in Berlin, die den Druck dieser Publikation realisiert haben. Bei der Fachgruppensprecherin Monika Hagedorn-Saupe haben wir immer große Unterstützung gefunden. Unsere Anerkennung gilt auch den vielen Softwareanbietern, die mit uns zusammengearbeitet haben und von denen viele einen weiten Weg zur Testveranstaltung in Münster auf sich genommen haben. Sollten Sie, liebe Leserin und lieber Leser, Fragen oder Verbesserungsvorschläge haben, wenden sie sich gerne an eine der im Anhang aufgeführten Ansprechpartner. Die ARBEITSGRUPPE SOFTWARE-VERGLEICH in der Fachgruppe Dokumentationdes Deutschen Museumsbundes Juli 1998 6 Einleitung Ausgangslage “Und womit arbeiten Sie? Wir sind nämlich auf der Suche nach einem Programm ...” So oder ähnlich beginnen viele Gespräche über Software für die Museumsdokumentation, in deren Verlauf häufig auch Sätze fallen wie “Im Museum X setzen sie das Programm Y ein. Sie sind damit ganz zufrieden. Wir überlegen, ob wir es auch nehmen.” Im weiteren Gespräch stellt man dann oft fest, daß das Museum, das als Vorbild dient, einen ganz anderen Museumstyp mit abweichenden Fragestellungen und Arbeitsweisen repräsentiert und damit die Übertragbarkeit der “guten” Erfahrungen in Frage gestellt ist. An diesem Punkt stellt sich meist Ratlosigkeit ein, zumal der Überblick über die Angebotspalette fehlt und deshalb auch keine Alternativen in Sicht sind. Seit Jahren wird von Museumsmitarbeitern und mitarbeiterinnen beklagt, daß es zwar Erfahrungsberichte über die Arbeit mit einzelnen Programmen gibt,1 aber keine Publikation, die einen generellen Überblick über vorhandene Dokumentationssoftware bietet. Um diesem Defizit abzuhelfen, hat sich eine Arbeitsgruppe innerhalb der FACHGRUPPE DOKUMENTATION des Deutschen Museumsbundes gebildet. Sie hat es sich zur Aufgabe gemacht, einen solchen Marktüberblick für Museen zu erstellen. Die bisher in den Museen der Bundesrepublik Deutschland entwickelten Lösungswege können wie folgt beschrieben werden: • • • Einige Museen lassen sich eigene Software “maßschneidern”. Es sind dies in vielen Fällen größere Einrichtungen, die sich auf dem deutschen und internationalen Markt umgesehen und kein ihren Bedürfnissen entsprechendes Programm gefunden haben. Aber auch kleine Museen lassen sich oftmals von befreundeten Programmierern eine Anwendung für ihre Zwecke anfertigen. Vor allem kleinere Museen setzen fertige Anwendungen ein und sind froh, wenn sie so wenig Arbeit wie möglich in das Erlernen oder Anpassen des Programms investieren müssen. Die dritte, ebenfalls große Gruppe von Museen setzt auf verbreitete Software, legt jedoch Wert darauf, das Programm den Bedürfnissen der hauseigenen Dokumentation anpassen zu können. Zielsetzung Bei diesem Softwarevergleich geht es nicht darum, eine Empfehlung für das eine oder andere Produkt auszusprechen. Vielmehr wird der Vergleich der Einsatzgebiete, des Leistungsumfangs und weiterer 1 An dieser Stelle sei stellvertretend auf die Erfahrungsberichte über den Einsatz bestimmter Softwareprodukte in der Museumsdokumentation in den Publikationen der EDV-Tage Theuern sowie der Museumsämter und -verbände verwiesen. Merkmale der Programme angestrebt. Die Produkte wurden deshalb unter gleichen Bedingungen nach vergleichbaren Kriterien begutachtet. Damit sollen Mitarbeiter und Mitarbeiterinnen von Museen und museumsnahen Einrichtungen in die Lage versetzt werden, aus der Vielfalt der angebotenen Programme diejenigen auszuwählen, die für den Einsatz in der jeweiligen Einrichtung in Frage kommen. Als Arbeitsinstrument steht ihnen dafür die Checkliste (siehe Anhang) zur Verfügung. Auswahlverfahren und -kriterien Die Auswahl der an diesem Vergleich beteiligten Programme kam durch ein zweigleisiges Verfahren zustande: Zum einen wurde auf die Möglichkeit der Teilnahme in verschiedenen Fachpublikationen im deutschsprachigen Raum hingewiesen,2 zum anderen wurden Anbieter von Programmen, die in den Museen der Bundesrepublik Deutschland im Einsatz sind, gezielt angesprochen. Folgende Kriterien wurden bei der Auswahl zugrundegelegt: • Anwendung in mindestens einem Museum, • deutschsprachige Benutzeroberfläche, • Lauffähigkeit unter den Betriebssystemen DOS oder Windows 3.x, Win95, Windows NT, • kommerzieller Vertrieb oder kostenlose Abgabe, • Vertrieb und Support im deutschsprachigen Raum. Die meisten Museen arbeiten im PC-Bereich unter DOS oder WINDOWS, so daß reine UNIX- oder Macintosh-Programme unberücksichtigt bleiben.3 Darüber hinaus existieren weitere, für die Museumsdokumentation interessante Produkte, die ebensowenig Berücksichtigung finden wie Eigenentwicklungen. Für das Ausklammern dieser Produkte war weniger ihr individueller Zuschnitt ausschlaggebend, als das Fehlen von Vertriebsstrukturen bzw. die durch notwendige Anpassungen doch erheblichen Kosten, die vor allem kleinen und mittleren Museen Probleme bereiten würden. Der für Softwareanwender unverzichtbare Support war auch der Grund, warum nur Programme mit deutschsprachiger Benutzeroberfläche und Ansprechpartnern im deutschsprachigen Raum einbezogen wurden. Der Hinweis auf den Softwarevergleich und die Teilnahmebedingungen wurden folgenden Redaktionen zur Veröffentlichung zugesandt: • DMB-Bulletin • Museum aktuell • Newsletter der Deutschen Gesellschaft für Dokumentation • ICOM-Mitteilungen des Deutschen ICOMNationalkomitees • NIKE-Bulletin (Schweiz) • E-Mail-Liste demuseum 2 3 De facto hat sich kein Anbieter eines derartigen Programmes für die Teilnahme am Softwarevergleich interessiert. 7 Ein Beispiel für individuelle Anwendungen ist das Integrierte Museumsmanagementsystem, IMS. Es wurde am Haus der Geschichte der Bundesrepublik Deutschland in Bonn mit Hilfe von Software entwickelt, die die Kriterien eines offenen Systems erfüllt und Industriestandards anwendet. Dieses auf eine Arbeitsumgebung mit sehr vielen, räumlich weit auseinanderliegenden Arbeitsplätzen (WAN / ISDN) und auf einen Bestand mit mehreren hunderttausend Objekten ausgerichtete System1 soll in absehbarer Zeit auch in einer Version für kleinere Anwendungen von einer Firma vertrieben werden. Daß die in diesem Vergleich vorgestellte Software nicht nur auf kleine und mittlere Museen ausgerichtet ist, sondern auch in großen Museen oder in einem Museumskomplex einsetzbar ist, zeigen die Beispiele des Deutschen Historischen Museums, das GOS benutzt, und der Staatlichen Museen zu Berlin – Stiftung Preußischer Kulturbesitz, in denen GOS, HIDA und MUSYS eingesetzt werden. Verfahren und Durchführung Der Softwarevergleich erfolgte in zwei Stufen: • Zunächst machten die Anbieter in einer von der Arbeitsgruppe zusammengestellten Checkliste Angaben über ihr Produkt. • In der zweiten Stufe wurden diese Angaben in einer Testveranstaltung anhand von Testdaten überprüft. Zum zeitlichen Verlauf ist anzumerken, daß die Ausschreibung für die Teilnahme am Softwarevergleich im Juli 1997 erfolgte. Bis zum 30.September 1997 sollten die Anbieter die ausgefüllten Checklisten zurücksenden und angeben, ob sie beabsichtigen, an der Testveranstaltung teilzunehmen. Doch auch Anbieter, die erst nach diesem Termin von dem Softwarevergleich erfuhren, wurden berücksichtigt. Die Testdaten bestanden aus 22.000 Datensätzen mit einer flachen Datenstruktur, den sogenannten Massendaten (mit Basisinformationen über Museumsobjekte und teilweise sehr langen Beschreibungstexten), die in das jeweilige Programm importiert werden sollten. Bestandteil der Testdaten waren überdies einige Bilddatensätze, die in die Massendaten eingebunden werden sollten. Darüber hinaus gab es eine ausführliche Beschreibung zu zwölf Museumsobjekten mit Verweisen auf Literatur und Personen (den sogenannten komplexen Daten), von denen nicht erwartet wurde, daß sie vollständig durch automatisierte Verfahren in die Programme importiert werden konnten. Anhand dieser Beispiele sollten die Anbieter zeigen, wie ihr Produkt mit komplexen Daten und der Darstellung von mehrteiligen Objekten (z.B. ein Nähkästchen mit Utensilien) umgeht. Teilweise waren hier manuelle Eingaben notwendig, um die Daten der jeweiligen Programmstruktur anzupassen. Die Daten wurden anonymisiert und unter der Näheres zu IMS in der Publikation: Informationstechnologie im Museum. Hrsg. Haus der Geschichte der Bundesrepublik Deutschland. Berlin, 1998 (Museumsfragen). 1 8 Maßgabe zur Verfügung gestellt, daß sie nur für diesen Softwaretest verwendet werden dürfen. Die Fragen der Testveranstaltung sind auf der Grundlage der Checkliste zusammengestellt und – unter Berücksichtigung der zuvor gemachten Anbieterangaben sowie der jeweiligen Programmschwerpunkte – allen Testteilnehmern gleichermaßen gestellt worden. Innerhalb der Arbeitsgruppe war die “Zuständigkeit” für die Programme aufgeteilt worden, so daß jeweils zwei Gruppenmitglieder für den Ablauf eines Tages verantwortlich waren. Sie wechselten sich nach einer Programmvorführung in der Moderation bzw. im Protokollieren des Tests ab. Zur Unterstützung der Protokollführung wurde das Interview der Programmanbieter mit deren Zustimmung auf Tonband aufgenommen. Die anderen Gruppenmitglieder unterstützten die Moderatoren durch Zusatzfragen. Die Testveranstaltung fand in der Zeit vom 26. Januar bis einschließlich 4. Februar 1998 in Münster statt. Gastgeber und Organisator war das Westfälische Museumsamt des Landschaftsverbandes WestfalenLippe (LWL). Die für die Durchführung der Veranstaltung notwendigen Räumlichkeiten sowie die technische Ausstattung wurden ebenfalls vom LWL zur Verfügung gestellt. Die Programmtests nahmen jeweils einen halben Arbeitstag in Anspruch. Teilnehmer an der Testveranstaltung waren neben den Vertretern und Vertreterinnen der Programmanbieter die Mitglieder der ARBEITSGRUPPE SOFTWAREVERGLEICH sowie zeitweise interessierte Mitarbeiter und Mitarbeiterinnen des Zentrums für Informationstechnik sowie der Museen des LWL. Einige Programmanbieter begnügten sich mit der ersten Stufe, dem Ausfüllen der Checkliste. Bei der Durchführung der Testveranstaltung stellte sich jedoch heraus, daß manche Fragen an die Anbieter ein unterschiedliches terminologisches Verständnis offenbarten, so daß die Angaben in der Checkliste in Absprache mit ihnen im Einzelfall geändert wurden. Aufgrund dieser Erfahrung sind die Checklisten, die nicht in der Testveranstaltung überprüft wurden, in einem separaten Teil der vorliegenden Publikation abgedruckt. Die über den Testverlauf erstellten Protokolle wurden den Programmanbietern zusammen mit der entsprechenden Checkliste zur Stellungnahme zugesandt. Sie ergänzen die Angaben der Checklisten und runden sie ab. Für die Publikation wurden die gesamten Unterlagen von allen Arbeitsgruppenmitgliedern überprüft, so daß die vorliegende Veröffentlichung auf einem Gruppenkonsens beruht. Ein weiteres Argument für die Durchführung des Softwarevergleichs in dieser Form war, daß die Anbieter in ihren Updates in der Regel zwar den Leistungsumfang verändern, selten aber ihre Programmphilosophie oder ihre grundlegende Zieldefinition (d.h. Spezialisierung auf Katalogisierung oder auf Objektverwaltung). Die ARBEITSGRUPPE SOFTWARE-VERGLEICH hofft von daher, daß die vorliegende Publikation auch über die Aktualität der getesteten Programmversion hinaus eine Hilfestellung bei der Orientierung über die Art der angebotenen Programme bietet. Die Arbeitsgruppe Die Mitglieder der ARBEITSGRUPPE SOFTWAREVERGLEICH kommen aus sehr unterschiedlichen Einrichtungen der Museumswelt; vertreten sind kleine wie auch große Museen, Museumsämter sowie freie Museumsberater: - Klaus Bulle, M.A., Museumsberatung MUSEUM.HLP - Manfred Hartmann, Diplom-Bibliothekar, Westfälisches Museumsamt - Marion Karls, Landschaftsverband Rheinland, Bergisches Freilichtmuseum Lindlar - Dr. Viktor Pröstler, Landesstelle für die nichtstaatlichen Museen in Bayern - Dr. Cordula Peper, Landesmuseum Koblenz - Dr. Klaus Ruwisch – Museumsberatung - Regine Scheffel, M.A., Wissenschaftliche Dokumentarin, Bayerisches Nationalmuseum Bei der Testveranstaltung wurde die Arbeitsgruppe organisatorisch unterstützt durch Dr. Günter Bernhardt und Christina Pohl, M.A., vom Westfälischen Museumsamt und beobachtend begleitet durch Monika Hagedorn-Saupe, Institut für Museumskunde, Sprecherin der FACHGRUPPE DOKUMENTATION. An der Erarbeitung der Konzeption des Softwarevergleichs und der Checkliste wirkten Johann Marinescu von der Landesstelle für Museumsbetreuung Baden-Württemberg und Dr. Jörn Sieglerschmidt, Landesmuseum für Technik und Arbeit, Mannheim, mit. Zur Entwickung des methodischen Vorgehens Die Arbeitsgruppe hat sich sehr ernsthaft mit der Frage auseinandergesetzt, ob ein solcher Softwarevergleich überhaupt sinnvoll ist, da er beispielsweise nicht die Objektivität von Benchmarktests erreicht, wie sie in Computerzeitschriften veröffentlicht werden. Auch das Projekt des Canadian Heritage Information Network (CHIN), das Marktbeobachtungen und Software-Tests auf nationaler Ebene unter Beteiligung zahlreicher (kritischer) Anwender in einem kontinuierlichen Prozeß durchführt,1 bewegt sich – dank der finanziellen Mittel und des organisatorischen Rückhalts einer Organisation wie CHIN – auf einer anderen Ebene. Und schließlich gab es Bedenken wegen der relativ geringen “Halbwertzeit” der Programminformationen, da der Markt ständig in Bewegung ist und laufend neue Updates erscheinen. Die Arbeitsgruppe hat sich trotz dieser Einwände entschlossen, den Softwarevergleich durchzuführen, da er von Kollegen und Kolleginnen so dringend gefordert wurde und zudem die Möglichkeit bietet, anhand der Canadian Heritage Information Network: Collection Managagement Software – Review. An in-depth Analysis of 21 Collections Management Software Products. Hull, Quebec 1997 1 Checkliste, der Testdaten und des Fragenkatalogs ein Verfahren zu testen, das die Ausgangsbasis für weitere, künftige Softwarevergleiche darstellen kann. Das Problem der geringen “Halbwertzeit” eines solchen Vergleichs stellt sich aufgrund der Marktdynamik immer und ist nur durch die regelmäßige Wiederholung solcher Vergleiche und durch rasches Publizieren der Ergebnisse zu lösen. Die ARBEITSGRUPPE SOFTWARE-VERGLEICH hat ausführlich darüber diskutiert, wie der Vergleich der Softwareprodukte für die Museumsdokumentation methodisch am besten durchzuführen ist. Dabei setzte sie sich mit der Checkliste von Lenore Sarasan2, mit der Marktübersicht über Bibliothekssoftware für Museen in den Niederlanden3 und mit weiteren Vorlagen4 auseinander. Zunächst verfolgte die Arbeitsgruppe das Ziel, allgemeine “Szenarien” zu entwerfen, die prototypisch bestimmte Arbeitsprozesse in der Museumsdokumentation abbilden sollten, und zwar zum einen im Bereich der Inventarisierung und Katalogisierung (schnelle Massendatenerfassung bzw. Abbildung und Recherche komplexer Daten), zum anderen im Bereich der Objektverwaltung. Dies stellte sich aber als nicht realisierbar heraus, weil in den dokumentarischen Arbeitsprozessen der Museen der Bundesrepublik Deutschland (v.a. in den alten Bundesländern) so unterschiedliche Verfahren benutzt werden, daß es schwierig ist, ein “Szenarium” zu entwerfen, das einen Arbeitsvorgang überzeugend und auf verschiedene Arbeitsumgebungen übertragbar abbildet.5 Daher entschied sich die Arbeitsgruppe letztendlich doch dafür, Leistungsmerkmale der Programme zu checken und bei der Frage, ob und wie bestimmte Tätigkeiten (z.B. der Objektverwaltung) unterstützt werden, den Anbietern keine Vorgaben zu machen. Vergleiche die Checkliste in: Sunderland, Jane / Sarasan, Lenore: Was muß man alles tun, um den Computer im Museum erfolgreich einzusetzen? Mit einer Einleitung von Christof Wolters. Berlin 1989 (Materialien aus dem Institut für Museumskunde, H. 30). 2 3 SB – Werkgroep Automatisering / VOGIN Projectgroep Programmatuurvergelijking: Software voor Bibliotheekautomatisering. Een vergelijking. VOGIN 1994. Softwarevergleiche z.B.: Ruwisch, Klaus: Systemanalyse zur EDV-gestützten Bestandserschließung in kleinen und mittleren Museen. Westfälisches Museumsamt Münster. Münster, 1992; Bearman, David (Hrsg.): 1994-95 Directory of software for Archives and Museums. In: Archives and museums informatics. Pittsburgh 1994; Dawson, David / Gill, Tony: The MDA Survey of Information Technology in Museums 1996-97. Cambridge 1997. 4 In Großbritannien gibt es einen Standard für Museumsdokumentation, SPECTRUM, der nicht nur einen Datenstandard umfaßt, sondern auch standardisierte Verfahren für bestimmte Arbeitsvorgänge im Museum. 5 9 Entsprechend wurden die Produktvertreter und vertreterinnen in der Testveranstaltung aufgefordert, die tätigkeitsunterstützenden Funktionen des Programms vorzuführen bzw. zu erläutern. In vielen Fällen ließen sich diese nicht anhand der vorgegebenen Testdaten zeigen, so daß man auf die Vorführung einer bestehenden Anwendung zurückgriff. Dies hatte verschiedene Ursachen: In einigen Fällen wurde eine neue Programmversion vorgeführt, in der die entsprechende Funktionalität noch nicht verankert war, jedoch in der Vorgängerversion bereits im Einsatz war. Zum Teil lag es auch daran, daß die Anbieter konkrete Vorgaben (eine Art “Pflichtenheft”) für die Implementierung einer Funktion benötigt hätten. Hier erläuterten sie oft nur die Funktionsweise einer möglichen Implementierung. Und schließlich verfügten einige Programme zwar über kein spezifisches Objektverwaltungsmodul, jedoch über allgemeine Funktionsmerkmale, die sich zur Unterstützung bestimmter Objektverwaltungstätigkeiten umsetzen lassen. Dies wurde jeweils im Protokoll festgehalten. eine Wiedervorlagefunktion zur Erinnerung an Ausleihfristen oder an turnusgemäße Zustandskontrolle gefährdeter Objekte. Die Arbeitsschwerpunkte und die notwendige Funktionalität eines Programms für die Museumsdokumentation festzulegen, ist von grundlegender Bedeutung. Ohne sorgfältige Bedarfsplanung wird man kein Softwareprogramm finden, das genau die Bedürfnisse des jeweiligen Museums erfüllt bzw. über die notwendigen Funktionen verfügt, so daß es angepaßt werden kann. Nicht paßgenaue Software aber kompliziert die Arbeit, führt unter Umständen zu einer Verfälschung der Angaben und zur Demotivation der Mitarbeiter und Mitarbeiterinnen. Die notwendigen Planungsschritte bestehen aus • • Zur Verwendung des Softwarevergleichs in Museen Am Ausgangspunkt dieser Einführung wurde die Ratlosigkeit der Museumsmitarbeiter und mitarbeiterinnen angesichts der Frage nach geeigneter Dokumentationssoftware thematisiert. Wie können sie die vorliegende Publikation nutzen? Die dort geschilderte Vorgehensweise, sich auf Referenzen zu beziehen, ist wichtig, doch zunächst sind für den Auswahlprozeß geeigneter Produkte andere Fragen grundlegend: • • Was soll mit Hilfe des Programms dokumentiert werden und welchen Schwerpunkt setzt das Museum? Handelt es sich z.B. um ein Kunstmuseum, dessen Dokumentation besonders auf die Unterstützung beim Ausstellungsmanagement zielt oder um eine naturkundliche Sammlung, in der die wissenschaftliche Arbeit am Objekt im Vordergrund steht? Wozu soll es eingesetzt werden? Soll das Programm in der Museumsdokumentation beispielsweise für die Inventarisierung / Katalogisierung der Sammlungsobjekte eingesetzt werden oder Aufgaben im Bereich Leihverkehr, Standortverwaltung, Inventur sowie in der Verwaltung des Fotoarchivs einschließlich Bestellwesen übernehmen? D.h. ist es wichtiger, sehr detaillierte wissenschaftliche Angaben in dem Programm adäquat abbilden zu können? – Dann muß es mit komplexen Datenstrukturen umgehen können. Oder geht es vorwiegend darum, Grunddaten zu verwalten, Sammlungsbewegungen zu dokumentieren und Terminarbeiten zu unterstützen? – Dann sollte das Programm über die “History”-Funktion verfügen, d.h. Informationen über frühere Standorte und Ausstellungen verwalten können. Hilfreich wäre auch 10 der Analyse der Dokumentation, so wie sie zur Zeit exisitiert, also des IST-Zustandes (und nicht eines Wunschbildes der gegenwärtigen Situation), der Festlegung der Dokumentation, wie man sie anstrebt, d.h. des SOLL-Zustandes. Hilfestellungen zum gesamten Planungsprozeß erhält man durch die Publikation von Harald Krämer.1 Zu den Arbeitsschritten, z.B. der Datenerhebung zum IstZustand mit Hilfe von Musterformularen, der Ermittlung konkreter Datenmengen und des gesamten Arbeitsablaufes bietet sich die Lektüre von Ruwisch und Sarasan an.2 Über diese auch für Nichtfachleute gut verständlichen Einführungen3 hinaus gibt es weitergehende Literatur zum Thema..4 Hat man die Ausgangssituation analysiert und die Zielvorgaben geklärt, so muß die Umsetzung des Vorhabens in der Grobkonzeption skizziert und in der Detailkonzeption genau festgehalten werden. In dieser Planungsphase ist die Marktübersicht angebotener Dokumentationssoftware ein Hilfsmittel, um den Kreis der in Frage kommenden Programme kennenzulernen (Grobkonzept) und sich schließlich für das Detailkonzept auf einen Vorschlag festzulegen. Dabei sollte man sich darüber klar werden, daß bei den angebotenen Produkten von sehr verschiedenen Voraussetzungen auszugehen ist. Grundsätzlich muß man zwischen “Werkzeugen” und sofort einsetzbaren Anwendungsprogrammen unterscheiden. Bei den “Werkzeugen” handelt es sich um sogenannte Datenbanksysteme oder auch 1 Krämer, Harald: Euphorie und Ernüchterung. Grundlegendes zu einem Einsatz der EDV und Multimedia. Technologie in Museen und Kunstinstitutionen. In: Rothauer, Doris/ Krämer, Harald (Hrsg.): Struktur und Strategie im Kunstbetrieb. Tendenzen der Professionalisierung. Wien, 1996, S. 62-80. 2 Ruwisch 1992 ; Sunderland / Sarasan 1990. 3 Zur Erläuterung der Fachausdrücke ist im Anhang ein Glossar abgedruckt. Claudel, Anne: Bibliographie zum Einsatz des Computers bei Sammlungsmanagement und -dokumentation. Berlin 1997 (Materialien aus dem Institut für Museumskunde, H. 47). 4 und können deshalb schnell auf neue technische Entwicklungen und Standards reagieren. Für den Vergleich wurden diese Systeme nur im Zusammenhang mit bereits existierenden Anwendungen für den Museumsbereich berücksichtigt (siehe unten). Beispiele: MS-Access, MS-SQL-Server, FileMaker Pro, 4th Dimension. Museo (4th Dimension), IMDAS (beliebiges DBMS), M-Box (RAIMA), MuseArch (MS-SQLServer), Museumsverwaltung (MS-Access), MUSYS (UNI-DATA), robotron*BIDOK/M (ORACLE). Datenbankmanagementsysteme (DBMS), die erst nach entsprechender Programmierung für die konkrete Arbeit im Museum eingesetzt werden können. Das Angebot läßt sich grob in zwei Gruppen unterscheiden: • • DBMS, die besonders in Wirtschaft und Industrie sehr verbreitet sind. Sie werden oftmals von großen Firmen mit entsprechender “manpower” angeboten Spezialisierte Datenbanksysteme, die besonders für die umfangreiche und komplexe Datenerfassung im Dokumentationsbereich entwickelt wurden. Auch hier muß die konkrete Anwendung bzw. ein Datenfeldkatalog noch definiert werden. Sie bieten jedoch standardmäßig Funktionen an, die bei den oben erwähnten DBMS teilweise erst programmiert werden müssen. Beispiele: Dr.Doc, Faust, GOS, HIDA, LARS. Mit diesen Werkzeugen erstellte Anwendungsprogramme lassen sich ebenfalls in verschiedene Gruppen einordnen: • • Programme, die vom Benutzer nicht angepaßt werden können, da dem Anwender die volle Funktionalität des zugrundeliegenden Systems nicht zur Verfügung steht. Ein Vorteil dieser Anwendungen ist, daß sie ohne weitere Programmierung und Anpassung eingesetzt werden können, da sie auf dem Konsens mehrerer Museen basieren. Jedoch muß hier besonders genau geprüft werden, ob sie alle Bedürfnisse des Anwenders abdecken, da Änderungen nicht oder nur sehr eingeschränkt vorgesehen sind. Bei Updates sind keine individuellen Anpassungen notwendig und der Anwender benötigt keine Kenntnisse der Datenbankadministration. Beispiele: FirstRumos (Runtime-Version von MSAccess), MOVplus (Clipper). Anwendungsprogramme, die vom Benutzer angepaßt werden können, da das zugrundeliegende Datenbanksystem mit ausgeliefert oder zusätzlich erworben wird. Damit steht ein sofort einsetzbares Programm zur Verfügung (ohne Programmierung, ohne Kenntnisse der Datenbankadministration); es sind jedoch auch individuelle Anpassungen möglich, die sowohl von den Firmen angeboten werden als auch von einem versierten Benutzer oder Datenbankadministrator im eigenen Haus geleistet werden können. Es ist zu überprüfen, ob die angebotenen Anwendungen den Bedürfnissen des Benutzers entsprechen und welcher Aufwand bzw. welche zusätzlichen Kosten bei gewünschten Anpassungen entstehen. Beispiele: allegro-HANS (allegro), AUGIAS-Museum (MSAccess), CMB Storager (SQL-Server), Dada (FileMaker Pro), David (4th Dimension), Dr.Doc mit Beispielanwendung, Faust mit Beispielanwendung, FirstRumos (mit Vollversion MS-Access), GOS mit verschiedenen Datenfeldkatalogen und Dateiformaten, HIDA mit verschiedenen Datenfeldkatalogen, ImageFinder Ist der Planungsprozeß soweit fortgeschritten, daß man die Programme herausgefiltert hat, die nach Leistungsumfang und sonstigen Merkmalen (nicht zuletzt auch des Preises) in der engeren Wahl sind, kommen wiederum die Referenzen ins Spiel. Um den direkten Kontakt unter Anwendern und Ratsuchenden zu erleichtern, sind im Anhang für jedes Programm einige Referenzadressen genannt.1 Und dies ist dann der Zeitpunkt für die konkrete Frage: “Sie arbeiten doch mit dem Programm Y? Welche Erfahrungen haben Sie damit gemacht?” Zum Aufbau der Publikation Dieser Einleitung folgen die 13 Protokolle zur Testveranstaltung. Am Anfang jeden Protokolls finden sich als Infobox, grafisch abgesetzt, Informationen zum Anbieter. Im laufenden Text stellen die Ziffern in Klammern die Verbindung zu den Übersichtstabellen zu allen Programmen her, welche den Protokollen folgen. Die Numerierung entspricht der Checkliste, die den Anbietern zur Bearbeitung zugeschickt wurde. Die nicht getesteten Programme werden mit Infobox, Kurzbeschreibung und gesonderten Übersichtstabellen abgedruckt. Protokolle gibt es hier selbstverständlich nicht, weil die Anbieter nicht am Test teilgenommen haben. Eine Auswahl von Referenzadressen wird nur angegeben, wenn der Anbieter uns dies freigestellt hat. Die ARBEITSGRUPPE SOFTWARE-VERGLEICH hat die Anbieter darum gebeten, eine kleine Auswahl Referenzadressen zur Verfügung zu stellen, die möglichst aus verschiedenen Anwendungsbereichen kommen sollten. 1 11 Getestete Programme Kurzbeschreibungen allegro-HANS Hersteller/Anbieter: Staats- und Universitätsbibliothek Hamburg Carl von Ossietzky Von Melle-Park 3 20146 Hamburg Tel. 040-4123-5856 Fax 040-4123 3352 E-Mail: [email protected] Ziel von allegro-HANS ist die Unterstützung sammlungsspezifischer Arbeiten und Abfragen mit größtmöglicher Paßgenauigkeit. Analog zur Bibliotheksarbeit soll mit allegro-HANS auch die Museumssammlung formal beschrieben und inhaltlich erschlossen werden, daher unterstützt das Programm die Verwendung von Thesauri und Normdateien. Ansprechpartner: Dr. Jürgen Neubacher Die Testdaten wurden importiert. In den Massendaten wurden die Problemfälle (carriage return / line feed im Textfeld) gefunden und durch eine Zusatzprogrammierung bereinigt, so daß auch der Folgetext importiert werden konnte. Importprobleme gab es wegen der Feldlängenbegrenzungen und der Indexmengengrenzen in allegro-HANS. allegro-HANS ist ein indexorientiertes Anwendungsprogramm, auf dessen Basis bereits mehrere Anwendungen erstellt wurden und das kundenspezifisch angepaßt werden kann. Programmschwerpunkt ist die Katalogisierung. Produktinformation allegro-HANS ist eine Applikation der Bibliothekssoftware allegro nach dem “Regelwerk zur Erschließung von Nachlässen und Autographen”. Es wurde ursprünglich für die Nachlaßerschließung in der SUB Hamburg entwickelt. Wesentliche Impulse für die Weiterentwicklung zur jetzigen Version von allegroHANS (Handschriften, Autographen, Nachlässe und Sondermaterialien) kamen aus dem Stadtmuseum Oldenburg, wo das Programm auf der Basis einer ISTAnalyse eingesetzt wird. Die Weitergabe des Programms erfolgt in Amtshilfe; Anpassungsarbeiten können im Kundenauftrag durchgeführt werden. Das zugrundeliegende Datenbankprogramm allegro zeichnet sich durch große Flexibilität aus und ist vom Anwender mit guten EDV-Kenntnissen nach entsprechender Schulung an die Bedürfnisse des Museums anpaßbar. Diese Parametrierung ist sehr schwierig, ermöglicht aber die Aufbereitung einzelner Arbeitsschritte, so daß anschließend auch PCunerfahrene Anwender diese Arbeiten selbständig durchführen können. Das Programm läuft zur Zeit noch unter DOS, für Ende 1998 ist ein Katalogisierungsmodul angekündigt. Ein WWW-Recherchemodul als Referenz ist seit November 1997 an der Landesbibliothek MecklenburgVorpommern in Betrieb (http://www-db.1bmv.de). Für 1999 ist die Implementierung der Z39.50-Schnittstelle, mit der andere Datenbanken über das Internet abgefragt und Daten in den eigenen Bestand übernommen werden können, geplant. Zum Test Programmfunktionen Die Benutzeroberfläche (4) ist zeichenorientiert und für einen Anwender, der Menüführung gewohnt ist, zunächst irritierend, da die Felder des umfangreichen Datenfeldkatalogs nicht in einer Maske angezeigt werden. Stattdessen wird nach Bestätigung der Eingabe in einem Feld das nächste für diese Anwendung definierte Feld angezeigt. Die Feldkennung besteht aus einer Kombination von Zahlen und Buchstaben ohne Klartext. Nach Aussage des Anbieters kann eine Darstellung in Form eines Formulars auf Kundenwunsch rasch programmiert werden. Auch die Anzeige der Inventarnummer des jeweils bearbeiteten Datensatzes in der Statuszeile ist programmierbar. Die Datenstruktur (5) von allegro-HANS ist vordefiniert, vom geschulten Anwender aber zu ändern. allegro-HANS verfügt über Indexfelder und Volltextfelder, wobei eine Grenze von 500 Indexaten sowie etwa 20.000 Zeichen pro Datensatz besteht. Die Indexate stehen in einem Kreuzindex. Dieser Kreuzindex gestattet es, Einträge rasch zu finden, ohne zu wissen, in welchem Feld sie stehen. Von dem Eintrag im Kreuzindex aus kommt man direkt zu dem Datensatz, in dem der Eintrag steht. Mehrfacheinträge (5.2.1) in den Datenfeldern sind möglich, auch die Gruppenbildung von Datenfeldern (5.2.2) ist abbildbar; zusammengehörige aber getrennt recherchierbare Daten (z.B. “Kiefer” und “genutet”) wurden im Test gefunden. Objekte, die aus mehreren Teilobjekten (5.2.3) bestehen, wie z.B. ein Service und seine Teile, können durch das Anlegen von hierarchisch untergeordneten Datensätzen widergespiegelt werden. Sie enthalten Verweise auf den Haupteintrag, denen man über die Funktionstaste nachgehen kann. Programmphilosophie Die Verknüpfung von Daten innerhalb einer 12 Datenbank (5.3.1) ist möglich, aber umständlich. Zur Beschleunigung von Dateneingabe und bearbeitung (6) ist der Import von Daten möglich, wenn sie im Internformat erfaßt wurden. Anders strukturierte Daten können nur nach eigener Programmierung der allegro-Importschnittstelle eingelesen werden. Dokumentvorlagen (6.3.2) kann man anlegen, indem man einen eigenen Stammdatensatz und eine eigene Maske definiert. In der Vorführung erwies sich das Kopieren eines Datensatzes jedoch als unkomplizierter und schneller. Die Dokumentvorlage wird zudem beim Retrieval als Treffer mit angezeigt. Eine Datenübernahme aus Wortlisten war bislang keine Anforderung, sie ist daher nicht realisiert. Daten aus externen Quellen (6.7) können nach dem Import der Normdatei übernommen werden. Es gibt ein Modul zum Import der SWD, PND und GKD, das aber bislang von keinem Anwender benutzt wird. Im Test wurde das globale Suchen und Ersetzen (6.9) vorgeführt. Das Rückgängigmachen von Änderungen (6.12) ist nur durch Abbrechen der Bearbeitung möglich; gelöschte Datensätze können vom geschulten Anwender mit Hilfe der Protokolldatei wiederhergestellt werden. Beim Einlesen der Testdatenerfolgte keine Dublettenkontrolle der Inventarnummern (7.1.1). Sie ist auch für die Dateneingabe nicht vorgesehen, kann aber, wie der Test zeigte, nachträglich durchgeführt werden. Durch Parametrierung sind besondere Sortieralgorithmen möglich, so daß Inventarnummern (6.4, 9.8), die aus Jahreszahl/Nummer bestehen, bei vorlagegetreuer Eingabe korrekt sortiert werden. Dies ist für Inventarnummern mit nachgestelltem Sortierkriterium oder römischen Zahlen nicht möglich. Das Retrieval (9) ist mit Boole’schen Operatoren, mit Rechtstrunkierung und bei Volltextfeldern auch mit Links- und Mitteltrunkierung möglich. Die Anzeige der Suchergebnisse ist als Kurzliste, im Internformat und im ISBD-Format (DIN 1505) sowie alternativ als Tabelle oder als einzelner Datensatz möglich. Das Speichern von Suchanfragen und Suchergebnissen ist nicht möglich. Das Sortieren des Suchergebnisses nach frei wählbaren Kriterien ist ebenfalls nicht vorgesehen, könnte aber für den Export feldspezifisch definiert werden. Der Datenexport im MAB-Format wird von allegro-HANS unterstützt. Das “Stapeln” von Datensätzen für den Ausdruck (10.1.1) ist nur über eine sukzessive Ergänzung der Ergebnismenge um einzelne Titel zu erreichen. Nach Angaben des Anbieters ist die Einbindung eines Thesaurus (13.1) sowie der Aufbau eines Thesaurus nach DIN 1463 über Stammdatensätze oder ein spezielles Register programmierbar. Die Suche nach einem Vorzugsdeskriptor führt direkt zu dem entsprechenden Objektdatensatz; die Suche nach Synonymen ist umständlicher, aber möglich. In der DOS-Version ist die volle Unterstützung der Recherche über den Thesaurus offenbar nicht gegeben. Für Druckausgaben (10) stehen wenige vordefinierte Formate zur Verfügung (10.1.2). Die Einbeziehung verknüpfter Daten in den Ausdruck konnte im Text vorgeführt werden. Darüber hinaus kann der Datenbankadministrator eigene Druckformate programmieren. Sammlungsverwaltung (12) Viele Funktionen der Sammlungsverwaltung, z.B. Zugangsdokumentation, Leihverkehr, Standortverwaltung, Inventur, Ausstellungsplanung, werden durch entsprechende Felder, durch die Erzeugung von Formularen, Listen etc. sowie durch codierte Felder und interne Vermerke unterstützt. Die verschiedenen Elemente der Datenbank sind untereinander verknüpft. Eine Unterstützung von Bearbeitungsvorgängen – von der passiven Mahnfunktion abgesehen – ist nicht verfügbar. Medieneinbindung (14) Die Einbindung auch mehrerer Bilder ist möglich. Allerdings werden sie in allegro-HANS nur verwaltet. Die Anzeige des Vollbildes erfolgt aus dem Programm heraus in einem externen Viewer. Literatur (Auswahl) • • • • • • Eversberg, Bernhard: allegro-C: Systemhandbuch: Version 15, Universitätsbibliothek der TU Braunschweig. Braunschweig 1996. HANSEATICS. Rundbrief an die Anwender der Datenbank HANS. Staats- und Universitätsbibliothek, Hamburg. Steffens, Monika: Bibliothek im Museum. Bibliothekarisch orientierte Sammlungsverwaltung mit dem Datenbanksystem Allegro/HANS. In: Bibliotheksdienst 29 Jg. (1995), S. 51-57. Weigel, Harald: Autographendatei und Nachlaßrepertorium durch Katalogisierung mit dem Datenbanksystem Allegro-C. In: Der Einsatz der Datenverarbeitung bei der Erschließung von Nachlässen und Autographen. Bearb. von einer Arbeitsgruppe der Deutschen Forschungsgemeinschaft. Berlin 1991 (dbimaterialien; 108), S. 149-162. Weigel, Harald: Das DFG-Projekt “Autographendatenbank und -OPAC”. In: Wefers, Sabine (Hrsg.): Die Herausforderung der Bibliotheken durch elektronische Medien und neue Organisationsformen. 85. Deutscher Bibliothekartag in Göttingen. Frankfurt a.M., 1996 (Zeitschrift für Bibliothekswesen und Bibliographie. Sonderh. 63), S. 282-292. Vorläufige Anleitung zur Katalogisierung und Recherche mit HANS 95. Universitäts- und Landesbibliothek Bonn. (Überarbeitete Fassung als elektronisches Dokument beziehbar über die Homepage der SUB Hamburg: http://www.sub.uni-hamburg.de/dgibin/sub?hans/hans.htm#dokumentation) Referenzmuseen (Auswahl) • Stadtmuseum Oldenburg, Monika Steffens, Am Stadtmuseum 4, D-26121 Oldenburg (Oldb), Tel. 0441-235 2887, E-Mail: [email protected] 13 • Eine Liste der HANS-Anwender ist über die Homepage der SUB Hamburg abrufbar: http://www.sub.uni-hamburg.de/cgi-bin/sub? hans/hans.htm CMB Storager 2.2.1 Hersteller/Anbieter: CMB Informationslogistik GmbH Margaretenstr. 78/2 A-1050 Wien Tel. 0043-1-585 1650 Fax 0043-1-585 1488 E-Mail: [email protected] Internet: http://www.artefact.at Ansprechpartner: Wolfgang Müller CMB Storager ist eine auf einem relationalen Datenbanksystem basierende Anwendung, die ohne weitere Programmanpassung im Museum einsetzbar ist und kundenspezifisch konfiguriert werden kann. Programmschwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung. Zum Test Die Massendaten wurden importiert, wobei die Problemfälle (carriage return / line feed im Textfeld) gefunden und manuell bereinigt wurden. Da Storager für unterschiedliche Datentypen entsprechende Datenfelder vorsieht, wurden numerische und alphanumerische Einträge in getrennten Feldern erfaßt. Das Einlesen der komplexen Daten erfolgte über “Kopieren und Einfügen”, ein aufwendiges aber erfolgreiches Verfahren. Insgesamt wurden die Daten genau geprüft und zum Teil manuell angepaßt. Die Bilder wurden in die Massendaten eingebunden. Vorgestellt wurde die Versionsnummer 2.2 mit einem kurz zuvor fertiggestellten Update. Programmfunktionen Produktinformation Die CMB Informationslogistik GmbH brachte 1991 die erste Version des Storager auf den Markt. Inzwischen wurden andere Software-Angebote (Internet, CDROM) aus der Firma ausgelagert, so daß nur noch an der Weiterentwicklung von Storager gearbeitet wird. Storager wird in Museen (8), Galerien, Archiven und Bibliotheken eingesetzt und ist an zahlreichen EDVProjekten im Kunst- und Kulturbereich beteiligt. Das neueste Update stammt vom Februar 1998. Zur Information der Anwender gibt es einen Newsletter und regelmäßigen E-Mail-Austausch; Anwendertreffen sind geplant. Zur Zeit ist dieses Programm vor allem für große Sammlungen geeignet. Die Firma plant, eine Einzelplatzversion mit einer Limitierung auf 7.500 Datensätze für kleinere Institutionen anzubieten. Programmanpassungen können z.T. vom Anwender selbst vorgenommen werden, darüber hinaus können sie bei der Firma CMB in Auftrag gegeben werden. Der Anbieter versucht, neue Anforderungen der Anwender im Rahmen von Updates und Wartungsverträgen abzudecken. Programmphilosophie Ziel der Firma ist es, den Anforderungen der Inventarisierung, Katalogisierung und Verwaltung verschiedenster Sammlungen aus Kunst und Kultur zu entsprechen. Das bedeutet, Storager soll den notwendigen Standards genügen, aber gleichzeitig flexibel genug sein, um die Wünsche unterschiedlicher Anwender zu erfüllen. Zur Beschleunigung der Dateneingabe und bearbeitung (6) können Dokumentvorlagen (6.3.2) für das Erfassen ähnlicher Datensätze erstellt und unter einem eigenen Gruppennamen abgespeichert werden. 14 Die Benutzeroberfläche (4) ist durch “Karteikarten” mit “Reitern” übersichtlich strukturiert. Umfangreichere Beschreibungsfelder haben einen Rollbalken, so daß die übrigen Angaben zum Objekt weiterhin zu sehen sind. Die Inventarnummer des bearbeiteten Datensatzes wird immer angezeigt. Die Datenstruktur (5) von Storager teilt die Daten in sechs Hauptkategorien auf: Objekte, Ereignisse, Personen, Literatur, digitale Bilder, OLE-Objekte und Windows-Dokumente. Die Datensätze der unterschiedlichen Kategorien sind alle über Relationen verknüpfbar, die der Anwender auswählen kann. Diese sind in jedem Datensatz aufgelistet und auch von dort aus in einem Fenster aufrufbar. Von diesen Fenstern aus kann man dann weitere Verknüpfungen einblenden. Storager enthält Listenfelder, Freitextfelder und sogenannte “dynamische Felder” in einer Box, die der Benutzer frei definieren kann, beispielsweise um zusätzliche Spezialfelder für einen bestimmten Datenbestand anzulegen. Die dynamischen Felder sind nur über die Freitextsuche recherchierbar. Die Mehrfachindizierung von Feldern (3.7.1) ist nicht möglich. Man kann jedoch Mehrfacheintragungen (5.2.1) in einem Feld vornehmen, die über den Operator “enthält” rercherchiert werden können. Die Bildung von wiederholbaren Feldgruppen (5.2.2) ist möglich. Verweise zwischen einem komplexen Objekt (5.2.3) – z.B. einem Service – und seinen Teilobjekten lassen sich über entsprechende Eintragungen in den Nummernfeldern (“Gruppe” und “Sub-Nr.”) herstellen. Je nach Suchanfrage werden diese dann mit angezeigt oder nicht. Beim Speichern tritt eine Verzögerung ein, so daß nicht unmittelbar mit der weiteren Eingabe fortgesetzt werden kann. Beim Duplizieren einer Karteikarte werden die Relationen und dynamischen Felder nach Wahl mitkopiert. Globales Suchen und Ersetzen (6.9) über die gesamte Datenbank ist nicht möglich. Es gibt einen “undo-button” zum Rückgängigmachen (6.12) des letzten Arbeitsschrittes. Gelöschte Daten können vom Administrator wiederhergestellt werden (6.12). Beim Einlesen von Daten erfolgt keine Dublettenkontrolle. Ein nachträgliches Auffinden von Dubletten ist nur über Umwege möglich. Eine Inventarnummer doppelt einzugeben, wird programmseitig verhindert (7.1.1). Die Inventarnummern (6.4, 9.8) bestehen beim Storager aus drei Elementen: Gruppe, Inventar-Nr. und Sub-Nr. So wird beim Ausdruck die korrekte Sortierung der Inventarnummer gewährleistet. Eine vorlagegetreue Eingabe ist nur in dem Textfeld “Zusatz” möglich, nach dem aber nicht korrekt sortiert werden kann. Alte Inventarnummern können in den dynamischen Feldern mitgeführt werden. Beim Retrieval (9) kann man in jedem Feld nach Einträgen suchen. Es gibt programmeigene Operatoren, die für jedes Feld gelten, und feldspezifische Suchbegriffe (z. B. “Kind von” für Unterbegriffe im Thesaurus). Darüber hinaus ist eine Suche mit Rechts- und LinksTrunkierung möglich. Für die Ähnlichkeitssuche in verschiedenen Stufen bedient der Anwender einen grafischen Schieberegler. Suchanfragen und -ergebnisse können gespeichert und Änderungen in den Rechercheergebnissen vorgenommen werden (9.9 - 9.11). Der Anbieter plant die Einbindung beliebig vieler multilingualer Thesauri (den Richtlinien des Getty Information Instituts entsprechend) und ist deswegen mit dem MDA in Kontakt. Der polyhierarchische Thesaurus (13.1) des Programms entspricht nur teilweise der ISO- bzw. DIN-Norm, da u.a. die Synonymverwaltung nicht möglich ist. Der Thesaurus erscheint wie eine vom Benutzer erstellte hierarchische Wortliste, die als eigene Gruppe hinterlegt ist. Der Thesaurus ist vom Datensatz aus aufrufbar. Änderungen der Deskriptoren bewirken auch Änderungen in den Datensätzen. Es gibt keinen reziproken Eintrag bei dem Thesaurusbegriff, auf den ein neuer oder geänderter Deskriptor verweist. D.h. die Konsistenz des Thesaurus wird systemseitig nicht unterstützt. Der Thesaurus ist in die Recherche (9.5) eingebunden; es stehen eigene Operatoren für die Suche von Unterbegriffen zur Verfügung (s.o.). Für die Druckausgabe (10) gibt es mitgelieferte Druckmasken: Objektlisten, ein Karteikartenformat und einen internen Report, der auch die sensiblen Daten und einen externen Report, der nur die wichtigsten Daten enthält. Darüber hinaus ist der Export von Daten über die Windows-Zwischenablage möglich. Sämtliche verknüpften Daten können in den Ausdruck miteinbezogen werden. Sammlungsverwaltung (12) Auf dem Gebiet der Sammlungsverwaltung erweist sich Storager als flexibel, da die einzelnen Vorgänge durch die umfangreichen internen Verknüpfungen und den Export zu Windows-Programmen unterstützt werden. So sind beispielsweise die Adressen von Leihgebern als Personendaten, Restaurierungsberichte oder ähnliches als Word-Dokumente abgelegt. Mittels einer speziellen Recherche können alle relevanten Dokumente vom Objektdatensatz aus aufgerufen werden. Für die Client-Server-Version gibt es darüber hinaus ein zusätzlich zu erwerbendes Modul für den Leihverkehr. Medieneinbindung Es können mehrere Bilder mit einem Datensatz verknüpft werden, für deren Anzeige die Standardfunktionen (vgl. 14.1.5) zur Verfügung stehen. Aus dem Objektdatensatz heraus kann auch ein sogenanntes Leuchtpult aufgerufen werden. CMB liefert mit Storager automatisch drei Bildbearbeitungsprogramme, weitere können auf Wunsch integriert werden. Storager bietet komfortable Möglichkeiten des automatisierten Bildimports. Da die Speicherung von digitalen Bildern großen Einfluß auf die Schnelligkeit des Programms hat, gibt es die Möglichkeit, diese auf externen Speichermedien abzulegen, die dann z.B. über Juke-Boxen verfügbar sind (14.1.4). Die Einbindung von Tondokumenten ist ebenso möglich wie die anderer OLE-Dateien. Special features • Storager kann aus dem Programm heraus versendbare Internet-Seiten erstellen. Referenzmuseen (Auswahl) • • • • • • • • Historisches Museum Wien, Dr. Pohanka, Karlsplatz, A-1040 Wien, Tel. 00431-5058747 Graphische Sammlung Albertina, Dr. Benedik, Albertinaplatz, A-1040 Wien, Tel. 00431-534830 Museumsdorf Cloppenburg, Dr. Meiners, Bether Str. 6, D-49661 Cloppenburg, Tel. 04471-94840 Landesmuseum Emden, Dr. Scheele, Rathaus, D-26721 Emden, Tel. 04921-22855 Artothek, Bundeskanzleramt, Dr. Pichler, A-1010 Wien Museum Moderner Kunst, Dr. Lachnit, Arsenalstr. 1, A-1030 Wien Kupferstichkabinett, Dr. Knofler, Akademiehof, A-1010 Wien Portfolio Kunst AB, Dr. Eisl, Mirthgasse 109, A-1190 Wien Nachtrag Nach Herstellerangaben ist die Synonymverwaltung nun möglich (vgl. Thesaurus nach DIN 1463, 13.1). Dada 3.0 15 Dada ist eine Anwendung, die auf einem relationalen Datenbanksystem basiert. Sie ist ohne weitere Programmierung im Museum einsetzbar und kann kundenspezifisch angepaßt werden. Programmschwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung. Produktinformation Dada (Die assoziative Datenbank) basiert auf dem relationalen Datenbanksystem “File Maker Pro” von Claris, das sich durch besondere Benutzerfreundlichkeit auszeichnet. Dada wurde zunächst von einem Historiker für Arbeiten im Bernischen Historischen Museum entwickelt. Heute wird es in Museen (60), in Archiven, in der Denkmalpflege und in der Forschung eingesetzt. Die erste Version kam 1993 auf den Markt; inzwischen vertreibt eine eigens dafür gegründete Firma das Programm. Neuestes Produkt für kleinere Museen ist das preiswertere Dada-Smal, in dem jedoch nicht alle Informationsdateien zur Verfügung stehen. Ein Systemadministrator mit guten Kenntnissen von FileMaker Pro kann mit Hilfe des Handbuchs (und ggf. Schulungen) z.T. auch kompliziertere Programmanpassungen selbst vornehmen. Sehr weitgehende Änderungen bergen die Gefahr der Inkompatibilität bei Updates. Sie können beim Anbieter in Auftrag gegeben werden. Programmphilosophie Zielgruppe sind prinzipiell alle Museen, die Wert auf die Verknüpfung von Objektdokumentation, Sammlungsverwaltung und Forschung legen. Kleinere Institutionen können sich gegebenenfalls auf das Grundmodul oder Dada-Smal beschränken. Aufgrund der leichten Bedienbarkeit sind für Dada keine besonderen EDV-Kenntnisse erforderlich. Zum Test Etwa die Hälfte der Massendaten wurde importiert, wobei die Problemfälle (carriage return / line feed im Textfeld) gefunden wurden. Die Feldnamen und die Struktur wurden teilweise angepaßt, so daß die Angaben der Checkliste überprüft werden konnten. Die komplexen Daten wurden manuell eingegeben, ebenso wie der Auszug aus dem Materialthesaurus. Die Bilddaten wurden eingebunden. Vorgestellt wurde in der Testveranstaltung die Version 3.0. Programmfunktionen Die Strukturierung der Benutzeroberfläche (4) in “Karteikarten” mit “Reitern”, die weitere “Formulare” enthalten, ist in der ganzen Datenbank einheitlich gestaltet. Der Aufbau des Hauptteils der Objektdokumentation sowie die Feldnamen sind vorgegeben. Jede “Karteikarte” enthält ein Bild sowie eine zentrale Anzeigebox mit einer Kurzbeschreibung des Objektes, die aus den Einträgen in den Datenfeldern und den verknüpften Datensätzen generiert wird. Der restliche Aufbau der Die Dublettenkontrolle, z.B. im Feld 16 Hersteller/Anbieter: Arthist Dokumentation GmbH Kapfsteig 2 CH-8032 Zürich Tel. 0041-1-422 1810 Fax 0041-1-422 1810 Ansprechpartner: Markus Brühlmeier Bildschirmdarstellung kann über ein Menü vom Benutzer verändert werden (4.4). Der aktuelle Status ist stets der Kopfzeile zu entnehmen. Die Datenstruktur (5) des Dada-Grundmoduls gliedert sich in zwei Gruppen: Im Bereich “Dokumentation” werden Gegenstände, Bilddokumente, Beispiele, Quellen und Sekundärliteratur separat aufgenommen. Die Gruppe “Lexika” enthält Informationsdateien mit bibliografischen, personenbezogenen, ausstellungsrelevanten und topografischen Daten sowie Wortschatzlisten. Mit dem Administrationsmodul werden Projektinformationen, Adressen, Korrespondenzen und Leihverkehr verwaltet. Die Datenstruktur ist vorgegeben, aber vom Anwender bzw. Systemadministrator veränderbar. Dada hat indizierte Felder und Freitextfelder, die in bezug auf die Anzahl der indizierten Zeichen Einschränkungen unterliegen (vgl. 3.7.2). Bei Neueingaben oder Änderungen in einem Feld wird der Feldinhalt sofort überschrieben und der Index automatisch aktualisiert. Das Löschen eines Datensatzes muß jedoch bestätigt werden. Es können mehrere getrennt recherchierbare Einträge (5.2.1.) in Indexfeldern gemacht werden. Die Gruppenbildung von Feldern (5.2.2), z. B. Material und Technik, führt bei einer kombinierten Suche nicht zum gewünschten Ziel. Laut Aussage des Anbieters kann ein korrektes Ergebnis erzielt werden, wenn bei der Eingabe die Verschlagwortung mit Prä- und Suffixen genutzt wird, d.h. “Kiefer” wird beispielsweise als Schlagwort eingegeben und “genutet” als Suffix (nicht vorgeführt). Ein Objekt, das aus mehreren Teilobjekten besteht, wird durch eine “Hauptkarte” und weitere davon abhängige “Karten” inventarisiert. Die Verknüpfung ist eindeutig (5.2.3) und übersichtlich gestaltet. Innerhalb einer Datenbank sind sehr viele Verknüpfungen mit weiteren Informationen zum Objekt möglich, die auch vom Datensatz aus angesehen werden können (5.3.1). Zur Beschleunigung der Dateneingabe und bearbeitung (6.) können Dokumentvorlagen (6.3.2.) erstellt werden, die als eigener Datensatz gespeichert und daher bei der Recherche als Treffer mitangezeigt werden. Es ist nicht möglich, beim Kopieren der Dokumentvorlage die Verknüpfungen mitzukopieren. Die Funktion “Suchen und Ersetzen” kann über die gesamte Datenbank erfolgen (6.9). Dabei müssen allerdings vollständige Feldeinträge ausgetauscht werden. “Inventarnummer”, erfolgt immer erst nachträglich, indem eine Suche nach doppelten Eintragungen in einem Feld gestartet wird (7.1.1). Deshalb wurden die doppelten Inventarnummern in den Testdaten gefunden. Eine automatische Kontrolle ist nicht vorgesehen, aber möglich. Die vorlagegetreue Eingabe der Inventarnummer (6.4.) ist nicht möglich, da sie in die drei Felder Präfix, Hauptteil und Suffix aufgesplittet eingegeben werden muß. Inventarnummern mit Jahreszahl/Nummer wurden korrekt sortiert (9.8.) – allerdings dauerte der Vorgang relativ lange. Nummern mit mehr als acht nachgestellten Sortierkriterien sowie römische Zahlen sind nach Herstellerangaben mit Zusatzprogrammierung korrekt sortierbar. Beim Retrieval (9) ist eine gestaffelte Suche nicht vorgesehen; dafür muß das Suchergebnis zwischengespeichert werden. Die Suchanfrage kann nach Herstellerangabe dauerhaft gespeichert werden (9.9). Für die gezielte Recherche bietet FileMaker nur einige Symbole an. Es handelt sich dabei aber nicht um die Boole'schen Operatoren (9.3). Recherchen mit Trunkierungszeichen sowie Ähnlichkeitssuchen sind durchführbar (9.4.1). In den Suchergebnissen können Änderungen vorgenommen werden (9.11). Es ist möglich, die Datensätze nach verschiedenen Feldern zu sortieren und eine beliebige Auswahl an Datensätzen für eine spätere Weiterbearbeitung oder den Export zu markieren. Die Arbeit mit einem Thesaurus (9.5.) unterstützt Dada nicht. Der Anwender kann jedoch über eine entsprechende Maske eine hierarchisch gegliederte Verschlagwortung vornehmen, die auch die Zuweisung zweier Oberbegriffe sowie die Synonymverwaltung erlaubt. Aller-dings müssen die Zuordnungen bei der Eingabe feststehen. Bei nachträglicher Verschlagwortung muß jeder Datensatz gesondert bearbeitet werden (9.5, 13.1). Um die Suche nach Oberbegriffen zu gewährleisten, müssen auch diese in jedem Datensatz extra eingegeben werden. Neben dieser Verschlagwortung gibt es frei wählbare Wortlisten, die für alle Felder und Datensätze innerhalb der Datenbank gelten (6.6). Für die Druckausgabe (10) werden einige Druckvorlagen mitgeliefert, die vom Anwender verändert werden können (10.1.4). Auch verknüpfte Informationen können in den Ausdruck mit einbezogen werden. Der Export von Suchergebnissen kann im DBF-Format erfolgen (10.2). Für Ausstellungsvorbereitungen existiert eine “Präsentationsdatei”, die eine Menge grundlegender Informationen (bis hin zu Montageanleitungen) enthält. In diese spezielle Projektdatei können die Objektdaten – ohne relationale Verknüpfungen – exportiert werden. Wiedervorlage oder Terminverwaltung sind nicht vorgesehen aber programmierbar. Sammlungsverwaltung (12) • Die Verwaltung des Sammlungsgutes erfolgt über einzelne Bausteine, die untereinander verknüpft sind: Für die Zugangsdokumentation steht ein eigenes Provenienzmodul zur Verfügung. Der Leihverkehr wird mit dem Administrationsmodul verwaltet, das Verknüpfungen mit der Adress- und Objektdatei aufweist. Für die Fotoverwaltung kann eine eigene Datei mit einer Liste der Negative eingerichtet werden. Medieneinbindung (14) Es ist möglich, pro Datensatz ein Bild einzubinden, das auch mit ausgedruckt werden kann. Eine Suche nach diesen Bildern ist nicht möglich. Anmerkungen Dada bietet die üblichen Zugriffsbeschränkungen. Möchte man eine differenziertere Zugriffskontrolle, z.B. für einzelne Datenfelder, erfordert dies einen hohen Programmieraufwand. Es sei – so der Anbieter – schon einmal vorgekommen, daß nach einem Systemabsturz oder Stromausfall trotz Reorganisationslauf eine Datei nicht mehr geöffnet werden konnte. In diesem Fall mußte auf die Sicherheitskopie zurückgegriffen werden oder bei der Firma Claris um Hilfe nachgefragt werden (11.4). Special features • • Interne Umsetzung verbaler Datierungsangaben für die numerische Recherche Automatische Generierung der Kurzbeschreibung auf der Haupt“karte” der Objektdokumentation Referenzmuseen (Auswahl) • • • • • • Kunstmuseum Winterthur, Dr. Dieter Schwarz, Christine Jenny, Tel. 0041-52 2675162 Museum Liner Appenzell, Christoph Schenker, Bettina Staub, Tel. 0041-71 7872270 Prinzhorn Sammlung Heidelberg, Dr. Bettina Brand Claussen, Psychiatrische Universitätsklinik, Voßstr. 4, D-69115 Heidelberg, Tel. 06261-546492 Historisches Museum Bern, Peter Jezler, Helvetiaplatz 5, CH-3000 Bern Tel. 0041-31 35 07711 Historisches Museum des Kantons Thurgau, Heinz Reinhart, Tel. 0041-052 7242520 Nidwaldner Museen, Marianne Baltensperger, Marcel Saxer, Tel. 0041-41-6187513 Sammlung A. Klee, Bern / Muri, Stefan Frey, Tel. 0041-31 3022618 Nachtrag Laut Herstellerangaben wurde die Programmfunktionalität erweitert, so daß jetzt Unterstützung bei Inventurarbeiten sowie Terminverwaltung gewährleistet ist. Dr.Doc 4.1 17 Hersteller/Anbieter: Dr. Pfaff GmbH Heinrich-Kley-Str. 2 D-80807 München Tel. 089-3561270 Fax: 089- 35612711 E-Mail: [email protected] Internet: http://www.drpfaff.de Ansprechpartner: Dr. Thomas Pfaff Dr.Doc 4.1 ist ein objektorientiertes Datenbanksystem, auf dessen Basis bereits mehrere Anwendungen erstellt wurden, die im Museum ohne weitere Programmierung einsetzbar sind. Dr.Doc kann kundenspezifisch angepaßt werden. Programmschwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung. Produktinformation Dr.Doc – ehemals Pfaff Archiv – ist 1984 auf den Markt gekommen; das neueste Update, Dr.Doc 5.0, erfolgte im Frühjahr 1998. Dr.Doc 4.1 ist ein Dokumentenmanagementsystem, das die Archivierung und Verwaltung jeglicher Art von digitalen Daten durch Workflow-Management unterstützt. Es ist für die Arbeit im Netz konzipiert, wobei auch Außenstellen an das Intranet angeschlossen werden können. Der Benutzer arbeitet immer mit einer Kopie, so daß das Originaldokument erhalten und die Bearbeitungsschritte nachvollziehbar bleiben. Dr.Doc ist ein Dokumentenarchivierungssystem, das die Programme, in denen die Dokumente erstellt und bearbeitet werden, einbindet (z.B. Winword – aber auch Macintosh-Programme). Die bearbeiteten Dokumente werden im originalen Datenformat intern in Dr.Doc gespeichert. Das System ist vom Anwender völlig frei konfigurierbar. Dr.Doc 4.1 ist kein Datenbankprogramm mit Feldern, hinter denen Indizes liegen, sondern ein System, das erst auf Abruf die jeweils gewünschte Ordnung aufbaut (z.B. Sortierung). Die Recherche erfolgt im ganzen System über Volltext oder über den bei der Suche generierten Index. Programmphilosophie Dr.Doc richtet sich an Museen, bei denen die Unterstützung von Arbeitsprozessen im Mittelpunkt steht und die rasche Suchmöglichkeiten benötigen, ohne sich intensiv mit der Strukturierung der Daten befassen zu wollen. Aus diesem Grund wird auf die Unterstützung der Terminologiekontrolle, der Recherche sowie des Daten-“Handling” durch einen Thesaurus nach DIN 1463 verzichtet. Zur Vereinfachung der Dateneingabe und bearbeitung (6) können Daten im dBase-, ANSI- oder ASCII-Format (im Batchbetrieb) importiert und mittels aller windowsüblichen Textverarbeitungsfunktionen 18 Zum Test Die Massendaten wurden importiert, wobei die Problemfälle (carriage return / line feed im Textfeld) gefunden und nach manueller Überarbeitung auch der Folgetext importiert wurden. Die komplexen Daten wurden manuell eingegeben, der Auszug aus dem “Materialthesaurus” als hierarchische Liste importiert und die Bilder eingebunden. Der Test erfolgte im wesentlichen anhand von Dr.Doc 4.1; einzelne Funktionen wurden mit der Version 5.0 gezeigt. Programmfunktionen Die Benutzeroberfläche (4) bietet eine komfortable Maskengestaltung; Farben, Plazierbarkeit der Datenfelder etc. sind vom Anwender menüunterstützt zu ändern. Die Masken sind mit den Benutzerrechten gekoppelt, die in 62 Benutzerklassen differenziert sind (ab 4/1998 auch Verwaltung von Benutzergruppen). Felder, die besonders viel Text enthalten, werden in einem gesonderten Fenster angezeigt, das entsprechend den Windows-Konventionen veränderbar ist. Nach Herstellerangabe ist die permanente Anzeige der Inventarnummer bei mehreren “Karteikarten” pro Datensatz möglich. Eine Besonderheit, die auch die Datenstruktur (5) betrifft, sind Funktionsknöpfe: “I” mit einem Hyperlink zu einem Informationstext, “T” als Hyperlink zu einen “Thesaurus”, aus dem auch Daten übernommen werden können. Um in einem Feld vorhandene Einträge einsehen und übernehmen zu können, muß dieses mit der Hyperlink-Funktion ausgestattet sein. Dr.Doc 4.1 kennt Feldtypen wie z.B. “string” oder “Datum”, an die bestimmte Sortieroptionen gebunden sind. Über alle Felder und Dokumente kann in Volltextsuche oder über den bei der Suche aufgebauten Index recherchiert werden. Mehrfacheintragungen in Datenfeldern (5.2.1) sind möglich. Die Gruppenbildung von Datenfeldern ist nur durch die Einbindung einer Tabelle in den Datensatz möglich, deren Spalten auf 255 Zeichen begrenzt sind. Die Suche zusammengehöriger, aber getrennt recherchierbarer Informationen, z.B. “Kiefer” und “genutet” (5.2.2), konnte aufgrund eines Programmfehlers nicht gezeigt werden. Die Möglichkeit, “Unter-”Tabellen anzulegen, kann auch zur Dokumentation komplexer Objekte, die aus mehreren Teilobjekten bestehen (5.2.3), genutzt werden. Über die Inventarnummer besteht eine weitere Möglichkeit, den Zusammenhang zwischen dem Gesamtobjekt und seinen Teilen abzubilden. Dazu müssen in den Datensätzen der Teilobjekte die Inventarnummern verteilt auf zwei Felder eingegeben werden, z.B. 1989/147 in das Inventarnummernfeld und 1 bzw. 2, 3,... in das Teilnummernfeld. Für die Verknüpfung von Daten innerhalb einer Dokumentation (5.3.1) kann beispielsweise zwischen einem Objekt- und einem Literaturdatensatz ein Hyperlink gesetzt werden. bearbeitet werden (6.2). Zur Beschleunigung der Dateneingabe können Dokumentvorlagen (6.3.2) als “Muster” im “Grundmusterarchiv” gespeichert werden. Die Dokumentvorlagen bleiben beim Retrieval unberücksichtigt. Das Blättern in Dokumenten (6.8) ist nach frei wählbaren Kriterien möglich; das globale Suchen und Ersetzen (6.9) ist ebenfalls möglich. Das Rückgängigmachen (6.12) ist nur auf Umwegen zu erreichen; gelöschte Datensätze sind mittels der Protokolldatei wiederherstellbar. Im Test wurde vorgeführt, daß die Eingabe doppelter Inventarnummern (7.1.1) vom System verhindert wird, wobei der Anwender voreinstellen kann, was mit den Dubletten geschehen soll (z.B. Ändern, Anhängen). Eine nachträgliche Dublettenkontrolle ist durch erneuten Import der Daten möglich. Die vorlagegetreue Eingabe von Inventarnummern (6.4) ist möglich. Sollen die Nummern korrekt sortiert werden (9.8), ist es aber notwendig, für widersprüchliche Sortierkriterien unterschiedliche Felder einzurichten. Inventarnummern, die aus Jahreszahl/Nummer bestehen, wurden richtig sortiert. Für Nummern mit nachgestelltem Sortierkriterium ist ein entsprechender Algorithmus definierbar; für römische Zahlen offenbar nicht. Wenn die Inventarnummer als Referenz eines Objektes auf seine Teile benutzt werden soll, ist die vorlagegetreue Eingabe der Nummer nicht möglich, da der Stamm der Inventarnummer und die Unternummer der Teilobjekte getrennt eingegeben werden müssen (s.o.). Für das menüunterstützte Retrieval (9) stehen die Boole’schen Operatoren sowie alle Trunkierungsmöglichkeiten zur Verfügung. Besonders erwähnenswert ist das schnelle Ergebnis bei der Suche mit einer Linkstrunkierung. Suchanfragen und Suchergebnisse können gespeichert werden (9.9, 9.10). Suchergebnisse können nach frei wählbaren Kriterien sortiert und wahlweise auf einen “Stapel”, z.B. zum Ausdrucken (10.1.1), gelegt werden. Dr.Doc 4.1 kann eine Vielzahl sogenannter Thesauri verwalten und diese für Dateneingabe, Terminologiekontrolle sowie für die Recherche nutzen. Ein Thesaurus (13.1) ist für Dr.Doc 4.1 ein Archiv gleichgeordneter oder hierarchischer Wortlisten wie z.B. ein Aktenplan. Die “Thesauri” in Dr.Doc entsprechen nicht der DIN 1463. Die Simulation eines Thesaurus nach DIN-Norm ist nur mit Redundanz möglich, da zu jedem “Deskriptor” immer der Oberbegriff angegeben werden muß, was aber automatisch erfolgen kann. Entsprechend war es möglich, den Auszug aus dem “Materialthesaurus” zu importieren, der ebenfalls mit diesen Redundanzen arbeitet. Für Druckausgaben (10) stehen eine Reihe fertiger Druckformate zur Verfügung, darüber hinaus kann der Anwender weitere definieren – mittlerweile nach Herstellerangabe auch unter Einbeziehung verknüpfter Daten. Sammlungsverwaltung (12) Aufgrund der Flexibilität bei der Anlage neuer Dokumentationen, der leichten Verfügbarkeit und der ausgeprägten Workflow-Komponenten ist es für den Anwender möglich, sich eigene Applikationen für die Sammlungsverwaltung zu entwerfen. Templates werden vom Hersteller bereits mitgeliefert. Medieneinbindung (14) In Dr.Doc 4.1. können digitale Daten, gleich welcher Medienart, eingebunden werden. Das Einbinden von digitalen Bildern (14.1.4) ist ohne Vergabe eines Dateinamens möglich. Es stehen die üblichen Anzeigemodi (14.1.5) von Bildern bzw. Bild und Text zur Verfügung. Das Zoomen konnte nicht vorgeführt werden; der Galeriemodus ist nur über den Wechsel der Masken möglich. Special feature • Schnelle Recherchemöglichkeit, besonders auch bei Linkstrunkierung Literatur (Auswahl) • Haasz, Christian: Dr.Doc. In: PC-Shopping (1997), H. 4, S. 136 Referenzmuseen (Auswahl) • • • Verwaltung der Staatlichen Schlösser und Gärten, Herr Dräger, Schloß, D- 61348 Bad Homburg v. d. Höhe, Tel. 06172-926200 Staatliche Museen Kassel, Frau Dr. Heinz, Schloß Wilhelmshöhe, D-34131 Kassel. Tel. 0561-93777 Stadtmuseum Halle, Herr Werner, Große Märkerstr. 10, D-06108 Halle, Tel. 0345-2026243 Nachtrag Dr.Doc ist mittlerweile in der Version 5.0 auf dem Markt. 19 FAUST 3 Hersteller/Anbieter: Land-Softwareentwicklung Martin Behaim Str. 3 D-90522 Oberasbach Tel. 0911-696911 Fax 0911-695173 E-Mail: [email protected] Internet: http://www.land-software.de Ansprechpartner: H. M. Land Faust 3 ist ein Retrievalsystem zur Speicherung und Verwaltung großer Datenmengen. Das Programm enthält eine kleine Musterlösung für Museen, die ohne weitere Programmierung einsetzbar ist und vom Kunden individuell angepaßt, erweitert oder verändert werden kann. Programmschwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung. Produktinformation Faust gibt es seit 1990, die neueste Version, Faust 3, kommt im Mai 1998 auf den Markt. Haupteinsatzgebiete sind Museen (14), Archive, Bibliotheken, Verlage und Informationsstellen. Es gibt einen 6 x jährlich erscheinenden Newsletter, von Kundengruppen organisierte Anwendertreffen sowie Kundeninformation per E-Mail oder über WWWSeiten. Der Anwender kann viele Änderungen menügesteuert selbst vornehmen. Für Änderungen, die tiefer ins System eingreifen, steht dem Datenbankadministrator das Programmiertool Faust Basic zur Verfügung. Anpassungsarbeiten können auch bei der Firma LandSoftwareentwicklung in Auftrag gegeben werden. Programmphilosophie Die Paßgenauigkeit des Informationssystems für die jeweilige Einrichtung – Museen jeder Größe und Sparte – steht bei Faust im Vordergrund. Daher ist das Programm auf die strukturierte und flexible Aufbereitung der Informationen, schnelle und differenzierte Rechercheverfahren und leichte Anpaßbarkeit durch den Benutzer ausgerichtet. Aus diesem Grund ist die Museumsmusterlösung auch so minimal gehalten, daß sie zur Erweiterung und Anpassung auffordert. Um der Vernetzung von Informationen Rechnung zu tragen, können Daten relational und hierarchisch miteinander verknüpft werden. Die terminologische Kontrolle durch die Einbindung eines polyhierarchischen Thesaurus nach DIN 1463 bildet einen Schwerpunkt des Programmes. Zum Test Die Massendaten wurden importiert, wobei die Problemfälle (carriage return / line feed im Textfeld) gefunden und der Folgetext abgeschnitten wurde. Die komplexen Daten und der Auszug aus dem “Materialthesaurus” wurden manuell eingegeben und 20 die Bilder zu den Massendaten eingebunden. Der Test wurde anhand der Programmversion Faust 3 durchgeführt. Nur bei Programmfunktionen, die noch nicht im neuen Update implementiert waren, mußte auf Faust 2.1 zurückgegriffen werden. Programmfunktionen Die verschiedenen Elemente der grafischen Benutzeroberfläche (4) (Farben, Menüleisten, Plazierung von Datenfeldern und Fenstern, Einrichtung eigener Dialogboxen) können flexibel vom Nutzer angepaßt werden. Es gibt in Faust 3 grundsätzlich keine starren Bildschirmmasken, jedoch eine feststehende Statuszeile, in der immer die FaustDatensatz-Nr. (nicht die Inventarnummer) angezeigt wird. Angeboten wird eine vordefinierte minimale Datenstruktur (5) für den Einsatz in Museen, die der Anwender menügesteuert den Bedürfnissen des jeweiligen Museums anpassen kann. Das Indexkonzept von Faust (3.7) unterscheidet zwischen der Indexierung von bis zu 256 Zeichen eines Feldes (von links nach rechts, wobei Trenner definiert und Zusätze von der Indexierung ausgenommen werden können) und der wortweisen Invertierung eines gesamten (Frei-)Textfeldes. Mehrfacheintragungen in Datenfeldern (5.2.1) sind demzufolge möglich, wobei der Anwender selbst die Trenner zwischen verschiedenen Eintragungen definieren kann. Gruppenbildung von Datenfeldern (5.2.2) ist wegen der relationalen Struktur von Faust 3 eingeschränkt möglich, z.B. durch die Definition bestimmter Gruppen von Datenfeldern als Verbünde mittels Programmierung in Faust Basic. Für die Suche zusammengehöriger, aber getrennt recherchierbarer Einträge, z.B. in den Feldern Material und Technik, kann der Anwender entweder eine feldbezogene Volltextrecherche starten oder die Angaben zu Material und Technik in den Verbundfeldern recherchieren. Soll das Feld durch einen Thesaurus kontrolliert werden, so muß der gesamte Inhalt des Verbundes (z.B. “Kiefer, genutet”) als Thesaurus-Terminus aufgenommen werden. Zur Abbildung des Verhältnisses zwischen komplexen Objekten, wie z.B. einem Service und seinen Teilen (5.2.3), steht ein eigener Datentyp “Referenz” zur Verfügung. Mit diesem können auch Kontextinformationen wie z.B. Literaturangaben oder Künstlerinformationen innerhalb der Datenbank und datenbankübergreifend mit den Objektdaten verknüpft werden. Referenzfelder können entweder als automatischer Rückverweis oder als einseitig gerichtete Referenz angelegt werden. Dateneingabe und –bearbeitung (6) werden durch Textverarbeitungsfunktionen unterstützt. Es können auch Dokumentvorlagen (6.3.2) angelegt werden, die jedoch beim Retrieval als Treffer mitangezeigt werden, soweit man dies nicht umständlich umgeht. Globales Suchen und Ersetzen (6.9) ist menüunterstützt in differenzierter Art und Weise möglich. Die Funktion “Rückgängigmachen” (6.12) ist nicht vorgesehen. Inventarnummern (6.4, 9.8) können zwar vorlagegetreu eingegeben werden, aber nur Nummernsysteme wie Jahreszahl/Nummer können korrekt sortiert werden. Inventarnummern mit nachgestelltem Sortierkriterum und römische Zahlen sind auch mit Faust-Basic-Programmierung nicht korrekt sortierbar. Das Retrieval (9) wird durch ein stark ausdifferenziertes Menü gesteuert. Die Suche mit Boole‘schen Operatoren ist möglich. Links-, Mittelund Rechtstrunkierung sowie die Suche nach leeren Feldern (9.4.2) wurden anhand der Testdaten gezeigt. Die Sortierung des Suchergebnisses (9.8) anhand frei wählbarer Kriterien wurde in Faust 2.1 vorgeführt. Faust unterstützt eine terminologische Kontrolle nicht nur durch Wortlisten, sondern auch durch Aufbau und Pflege eines polyhierarchischen Thesaurus nach DIN 1463 (13.1), der bis zu 30 Ebenen enthalten und viersprachig angelegt sein kann. Je Dokumentation können bis zu 31 Thesauri verwaltet werden. Per Mausklick ist es möglich ganze Äste des grafisch aufgebauten Thesaurus umzuhängen. Jede Änderung im Thesaurus wirkt sich automatisch auf den damit verknüpften Datenbestand aus. Der Thesaurus dient zur Eingabekontrolle des entsprechenden Feldes im Datenbestand (z.B. Synonymkontrolle) und steht auch für das Retrieval zur Verfügung. In verschiedenen Arbeitsschritten können beliebige Dokumente wie auf einem Stapel “notiert” und später wiederaufgerufen, weiterbearbeitet oder ausgedruckt werden (10.1.1). Die Gestaltung von Druckausgaben (10) ist sehr komfortabel gelöst. Selbst der Ausdruck von Daten aus verknüpften Referenzdateien (z.B. aus einer Literaturdatenbank oder einem Personenregister) kann vom Anwender menüunterstützt festgelegt werden. Medieneinbindung (14) Faust plus Bildarchiv ist ein komplettes System zur Bildbearbeitung (14), mit dem man Bilder scannen, komprimieren, speichern, bearbeiten, zoomen, drucken und exportieren kann. Es ist möglich, bis zu 1 Million Bilder zu verwalten; dabei werden alle üblichen Speichermedien bis hin zur Juke-Box mit optischen Platten unterstützt. Die Bilder werden direkt, ohne Angabe eines Dateinamens, mit dem Datensatz verknüpft. Nach Suchanfrage ist eine Galerieanzeige möglich. Special features • • • • Referenzmuseen (Auswahl) • • • • • Sammlungsverwaltung (12) Aufgrund der Flexibilität von Faust 3 kann sich der Anwender Module zur Sammlungsverwaltung selbst einrichten. Mit Faust 3 wird eine Musterlösung für die Leihverwaltung mit Wiedervorlage, Terminverwaltung und Mahnfunktion ausgeliefert werden, die vom Museum in bezug auf einen oder mehrere Datenbestände eingebunden werden kann, also z.B. zur Unterstützung des Leihverkehrs oder zusätzlich auch der Fotoverwaltung. Thesaurus nach DIN 1463 Hypertextfunktion zum Navigieren in invertierten Volltextfeldern Unschärfe-Definition und Intervall-Recherche im Datierungsfeld Stufenlos skalierbare Bild- (bzw. Text- und Bild-) anzeige • • Jüdisches Museum der Stadt Wien, Postanschrift: Dorotheergasse 2, A-1010 Wien, Tel. 0043-1 5350431 Deutsches Bergbau-Museum Bochum, Am Bergbaumuseum 28, D-44791 Bochum, Tel. 023458770 Städtisches Museum Eisenhüttenstadt, Löwenstr. 4, D-15890 Eisenhüttenstadt, Tel. 03364-2146 Ruhrlandmuseum, Goethestr. 41, D-45128 Essen, Tel. 0201-8845200 Niedersächsisches Landesmuseum, Hannover, Willy-Brandt-Allee 5, D-30169 Hannover, Tel. 0511-9807620 Landesmuseum für Technik und Arbeit, Museumstr. 1, D-68165 Mannheim, Tel. 062142989 Deutsches Museum, Museumsinsel 1, D-80538 München, Tel. 089-21791 21 FirstRumos 97 Hersteller/Anbieter: Förderverein des Freilichtmuseums am Kiekeberg Am Kiekeberg 1 D-21224 Rosengarten-Ehestorf Tel. 040-79017610 Fax 040-7926464 E-Mail: [email protected] Internet: http://ourworld.compuserve.com /homepages/oliver_rump Ansprechpartner: Oliver Rump, Lars Steinberg, Thomas Overdiek FirstRumos ist eine relationale Datenbank mit einer Anwendung, die ohne weitere Programmierung im Museum einsetzbar ist. Programmschwerpunkte liegen bei der Inventarisierung, der Sammlungsverwaltung sowie der Medien- und Museumsverwaltung. Produktinformation Das Programm war ursprünglich eine Individuallösung für das Freilichtmuseum am Kiekeberg und wurde dann für die allgemeine Verwendung in Freilicht-, Memorial- und kulturhistorischen Museen weiterentwickelt. FirstRumos ist eine Runtime-Version der Datenbank MS-Access und wird in ca. 65 Museen eingesetzt. Eine erweiterte Programmfunktionalität ist gegeben, wenn der Benutzer zusätzlich die Vollversion von MS-Access verwendet. Damit kann er auch größere Veränderungen im Programm vornehmen, gefährdet jedoch die Updatefähigkeit. Die institutionalisierte Form der Programmweiterentwicklung erfolgt über das jährliche Anwendertreffen, auf dem neue Anforderungen in einem Weiterentwicklungskonzept formuliert werden, das von den Herstellern dann im folgenden Jahr realisiert wird. Programmphilosophie FirstRumos will nicht nur die Museumsdokumentation unterstützen, sondern die produzierten Daten im Rahmen eines Managementansatzes möglichst redundanzfrei in allen Arbeitsbereichen des Museums verwenden. Demzufolge ist FirstRumos modular aufgebaut und nicht nur auf die Benutzung durch Dokumentationsexperten, sondern auch auf weniger spezialisierte Mitarbeiter ausgerichtet. Im Zusammenhang mit der erweiterten Datennutzung sind die Schnittstellen zu anderen MS-Produkten (MSWord, MS-Excel etc.) von besonderer Bedeutung. Zum Test Die Massendaten wurden importiert, wobei die FirstRumos arbeitet mit einer eindeutigen laufenden Nummer, die die Funktion der Inventarnummer hat. Durch die automatische Generierung der Nummer beim Anlegen eines neuen Datensatzes wird auch die Dublettenkontrolle gewährleistet (7.1.1). Die Inventarnummern der Testdaten wurden in das Datenfeld “Alt.nummer” importiert. Hier ist nur eine alphanumerische Sortierung möglich. Inventarnummern, die aus Jahreszahl/Nummer 22 Problemfälle (carriage return/line feed im Textfeld) gefunden und nach manueller Überarbeitung auch der Folgetext importiert wurde. Wegen der vorgegebenen Datenfeldstruktur von FirstRumos, kam es beim Import der Testdaten in einigen Fällen zu Problemen (z.B. bezüglich der Länge des Datenfeldes). Die Bilder wurden in die Massendaten eingebunden. Programmfunktionen Der stark modulare Aufbau der Anwendung wird dadurch unterstrichen, daß der Benutzer bei seiner Arbeit immer zu einem Startbildschirm zurückgeführt wird, auf dem die einzelnen Programmbereiche über große Buttons anzuklicken sind. Die Bildschirmmasken der grafischen Benutzeroberfläche (4) sind fix; die Datenfeldlänge ist anwenderseitig veränderbar (s.o.). Die Ansicht der Daten erfolgt im Listenformat, als Datenblatt und als sogenannter “Schlagwort-Kreuzkatalog” mit vernetzten Verweisungen auf alle Datenbankbereiche. Auch eine geschützte Ansicht, die sensible Daten ausspart, steht zur Verfügung. Die Datenstruktur (5) von FirstRumos ist vordefiniert. Mehrfacheintragungen sind möglich (5.2.1). Diese können auch mit Trennzeichen gesucht werden. Eine Gruppenbildung von Datenfeldern gibt es nicht (5.2.2). Bei FirstRumos werden Daten, die als zusammengehörig betrachtet werden (z.B. Material/Technik), in der Regel in ein Datenfeld eingetragen. Die Abbildung von kombinierten Informationen erfolgt somit als String. Das relationale Datenbankkonzept ermöglicht eine Unterstrukturierung nach Gesamt- und Teilobjekt (5.2.3, 5.3.1), die in einem Verweisungsblock im Datensatz verwaltet werden. Dort kann z. B. vom Teilobjekt auf das Gesamtobjekt verwiesen werden und ebenso auf Referenzdateien und andere Datenbankbereiche (z.B. Adressen oder Fotomaterial). Es gibt Index- und Freitextfelder. Laut Anbieter spielte bei der Entscheidung, ob ein Feld indiziert werden soll oder nicht, das Verhältnis von Speicherplatz, Suchzeit und Eingabeverhalten eine entscheidende Rolle (3.7). Eingabeerleichterungen bei der Dateneingabe und bearbeitung (6) werden in MS-Access (oder über den Import aus anderen MS-Programmen) realisiert. Vorlagedokumente gibt es nicht (6.3.2). Die Eintragungen einzelner Datenfelder können in den neuen Datensatz kopiert werden (6.2). Suchen und Ersetzen (6.9) sind in einem Datenbestand möglich, nicht jedoch bestandsübergreifend. Das Rückgängigmachen (6.12) der letzten Eingabe ist möglich; mit dem neuen MS-Access wird dies über weitere Bearbeitungsstufen erfolgen können. bestehen, müssen mit führenden Nullen eingegeben werden. Die Hersteller empfehlen noch eine andere Variante: die Aufsplittung komplexer Nummern auf die beiden Datenfelder “Laufende Nummer/Inventarnummer” und “Alt.nummer” (6.4). D.h., die vorlagegetreue Eingabe und Sortierung von Inventarnummern aus Jahreszahl/ Nummer ist in FirstRumos nicht möglich. Nummernsysteme mit komplizierterer Sortierlogik können nur als Texteintrag verwaltet werden. Ein zentrales Suchinstrument im Retrieval (9) ist der “Schlagwort-Kreuzkatalog”; er vernetzt die Datenbankbereiche über Inventarnummern und Objektbezeichnungen. Die trunkierte Suche erwies sich im Test als sehr schnell (9.4.1); auch ein Suchmodus mit Boole’schen Operatoren ist verfügbar (9.3). Die phonetische Suche (Suchfunktionen der Telekom-Telefonauskunft) führt zu einem relativ großen Ergebnisballast (9.4.4). Sortierkriterien für das Retrievalergebnis lassen sich auf bis zu 256 Ebenen festlegen. Eine Besonderheit ist, daß der Benutzer während eines komplexeren Suchvorgangs am angezeigten Datensatz weiterarbeiten kann. Eine Aufbereitung des Suchergebnisses ist mit verschiedenen LayoutWerkzeugen möglich (Spaltenbreite, Schriftgröße usw.) (9.7.2). Datenänderungen können nur bei der Suche im Eingabe- oder Änderungsmodus vorgenommen werden (9.11). Offene und geschlossene Wortlisten werden nicht aus bestehenden Indizes aufgebaut, sondern müssen vor der Datenaufnahme eingelesen werden (6.6). Ein Thesaurus nach DIN 1463 steht nicht zur Verfügung (13.1), der Benutzer kann aber andere Systematiken einbinden. Hierarchische Strukturen werden dabei im relationalen Datenbankmodell als Verweisungen abgebildet. Für die Druckausgabe (10) stehen verschiedene Optionen zur Verfügung: der Datensatz kann als “Karteikarte” mit zusätzlichem Bemerkungsfeld oder Bild, als “Eingangsbuch” nach Berichtszeit sowie als Liste gedruckt werden (10.1). Hervorzuheben sind die Preview-Funktion, die sehr hilfreich bei der Gestaltung der Ausgabeprodukte ist. Verknüpfte Daten werden nicht automatisch mitausgedruckt. Das Programm hat keinen eigenen Reportgenerator (10.1.4); die Weiterverarbeitung erfolgt über die offene Schnittstelle zu anderen MS-Programmen bzw. über FirstRumosPublisher für die Publikation der Daten im Internet. Verweisungen Datenbestände temporär filtern (12.8). Von der Restaurierungskomponente aus kann FirstRumos auf externe Daten (z.B. Meßwerte) zugreifen (12.9). Das Programm schließt die Module für Bibliothek, Archiv, Tonträger, Fotos und AVMedien ein. Die Programmodule für Adressen, Finanzen, Statistik (12.1-12.11, 13.5) zielen eher auf die allgemeine Museumsverwaltung. Sammlungsverwaltung (12) Referenzen (Auswahl) Aufgrund der Programmintention, alle relevanten Arbeitsbereiche eines Museums zu unterstützen, verzahnt FirstRumos die Inventarisierung/Katalogisierung mit dem Sammlungsmanagement und weiteren Verwaltungsaufgaben. So findet sich ein Leihverkehrsmodul, mit dem Ausleihlisten nach Inventarnummer, Objektbezeichnung und Leihnehmerdaten produziert werden können (12.3). Für die Ausstellungsplanung lassen sich über Medieneinbindung (14) Mit ViewRumos bietet das Programm eine integrierte Bildbearbeitung. Für die Zuordnung des Bildmaterials zu den Datensätzen braucht nur der Name des Datenträgers eingegeben zu werden, auf dem sich die Bilddaten befinden, nicht der Bilddateiname. Vorschaubilder werden auf der Festplatte gespeichert und erlauben somit einen schnellen Zugriff (10.1.4, 10.1.5). Special features • • • • Im- und Exportfunktion für die im HIDAAnwenderverbund der kleinen und mittleren Museen gepflegte Oberbegriffsdatei Nutzung der Adressdaten für die Erstellung einer Geburtstagsliste nach Datum Möglichkeit der Verknüpfung der Adressdaten mit Interviewprotokollen oder mit Aufzeichnungen zu einer Firmengeschichte Unterstützung der parallelen Haushaltsführung per Kostenrechnung und Kameralistik im Rahmen der Finanzverwaltung Literatur (Auswahl) • • • • Machnicki, Kornelia / Overdiek, Thomas / Rump Oliver [u.a.]: FirstRumos. Das Programm zum EDV-gestützten Museumsmanagement. 2. erw. und überarb. Aufl. Ehestorf 1998 (Schriften des Freilichtmuseums am Kiekeberg; 23) Freilichtmuseum an der Glentleiten, Herr Dr. Joosten, An der Glentleiten 4, D-82439 Großweil, Tel.: 08851-1850 Historisches Museum Hannover, Herr Dr. Pfahl, Pferdestr. 6, D-30159 Hannover, Tel. 0511-1682352 Sächsische Schlösserverwaltung Dresden, Frau Wagner, Stauffenbergallee 2, D-01099 Dresden, Tel. 0351-8271824 23 GOS 3.7 Hersteller/Anbieter: Konrad Zuse Zentrum für Informationstechnik Takustr. 7 D-14195 Berlin Tel. 030-841 85 218 Fax 030-841 85 269 E-Mail: saro @zib. de Internet: http://www.zib.de/SIS/infomus.de.html gefunden und per Zusatzprogrammierung bereinigt wurden, so daß auch der Folgetext geladen wurde. Auch die nicht dokumentierten (Mehrfach-) Felder wurden direkt eingelesen. Die komplexen Daten wurden nach Überarbeitung ebenfalls importiert. Der Auszug aus dem “Materialthesaurus” wurde per Programm umgeformt, da dieser nicht der DIN 1463 entspricht. Die Bilder wurden in die Massendaten eingebunden. Ansprechpartner: Carlos Saro Programmfunktionen GOS 3.7 ist eine hierarchische Datenbank, auf deren Basis Anwendungen erstellt wurden, die ohne weitere Programmierung im Museum einsetzbar sind. Programmschwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung. Produktinformation GOS wurde 1979 vom MDA in Großbritannien speziell für die Museumsdokumentation entwickelt und seit 1981 vom ZIB auf die Dokumentation in deutschen Museen angepaßt. Das letzte Update kam 1997 heraus, für 1998 ist die Windows-Version von GOS angekündigt, mit der die Fenstertechnik auf allen von GOS unterstützten Plattformen (DOS, OS/2, verschiedene Unix-Systeme) nutzbar sein wird. GOS enthält verschiedene Module und Programmbausteine, die nach Bedarf in die individuelle Version eingebaut werden können. Um die Diversifizierung von GOSVarianten in Grenzen zu halten, sollten Anwender keine systemverändernden Programmierarbeiten vornehmen. Nichtkommerzielle Anwender erhalten GOS kostenlos; für Weiterentwicklung und Anpassung an die Bedürfnisse des jeweiligen Museums werden in der Regel Kooperationsverträge geschlossen. GOS wird derzeit in etwa 30 Museen (insbesondere mit ethnologischen und kontextorientierten Sammlungen) auf ca. 150 Arbeitsplätzen eingesetzt. Das ZIB ist an dem EG-Projekt MUSoNET zur Implementierung der Z39.50-Schnittstelle in die Museumsdokumentation beteiligt; entsprechend verfügt GOS über ein Internet-Interface. Programmphilosophie Zielgruppe sind Museen unterschiedlicher Größe und Ausrichtung. Nicht kommerzieller Erfolg, sondern der “sanfte Übergang” von konventioneller zu EDVgestützter Museumsdokumentation ist das Ziel des Programms, das vorwiegend im Rahmen von Kooperationsprojekten abgegeben wird. Zur Terminologiekontrolle verfügt GOS über ein Modul zur Erstellung und Pflege eines polyhierarchischen Thesaurus, der DIN 1463 voll unterstützt. Zum Test Die Massendaten wurden importiert, wobei die Problemfälle (carriage return / line feed im Textfeld) Beim Retrieval (9) werden neben den Boole’schen 24 Die Benutzeroberfläche (4) ist zeichenorientiert. Das Menü entspricht dem SAA-Standard; Veränderungen können in gewissem Umfang von den Anwendern oder vom Datenbankadministrator vorgenommen werden. In der Statuszeile kann die Inventarnummer oder wahlweise ein anderes Feld des bearbeiteten Datensatzes angezeigt werden (4.4). Das Programm kann mit verschiedenen Datenfeldkatalogen (Knorr-Projekt, Volks- und Völkerkundemuseen) ausgeliefert werden, die dem CIDOC-Standard entsprechen. Die Datenstruktur (5) wird nach Anforderung an die Bedürfnisse des Anwenders angepaßt. GOS verfügt über maximal 127 Indexfelder und beliebig viele Freitextfelder, in denen eine feldbezogene Volltextrecherche vorgenommen werden kann. Neben Mehrfachfeldern (5.2.1) gibt es auch Feldwiederholgruppen (5.2.2), die ein korrektes Retrievalergebnis in zusammengehörigen, aber getrennt recherchierbaren Datenfeldern (z.B. Material und Technik) gestatten. Die Verknüpfung von Daten zu einem komplexen Objekt (5.2.3), wie z.B. einem Service und seinen Teilen, kann bei Bedarf per rekursivem Verweis hergestellt werden. Ein Defizit von GOS liegt derzeit noch in der Verknüpfung von Referenzdateien mit Kontextinformation zum Objektdatensatz, wie z.B. Literaturangaben etc. (5.3.1). Eine Beschleunigung der Dateneingabe (6) ist sowohl durch die Kopierfunktion (6.3.4) als auch durch den kontrollierten Batchimport von Daten möglich. Zur Übernahme von Daten aus einer externen Quelle muß ggf. ein Importfilter erstellt werden. Dokumentvorlagen (6.3.2) werden in gesonderten Dateien abgelegt und daher beim Retrieval nicht berücksichtigt. Globales Suchen und Ersetzen (6.9) ist möglich, nicht jedoch das Rückgängigmachen (6.12) von Änderungen oder Löschungen. Inventarnummern können vorlagegetreu eingegeben und sortiert werden (6.4, 9.8). Nummernsysteme mit sich widersprechenden Sortieralgorithmen müssen in getrennte Felder eingegeben werden. Die zur Standardausstattung von GOS gehörenden Sortierregeln (Jahreszahl / Nummer; Nummer / Jahreszahl; römische Zahlen) kann der Anwender selbst den jeweiligen Nummernfeldern zuweisen. Im Test konnte dies allerdings nicht vorgeführt werden, da in den Testdaten Nummern mit sich widersprechender Sortierlogik im gleichen Feld standen. Operatoren, der Rechtstrunktierung und Teiltextsuche auch verschiedene Normalisierungen unterstützt. Phonetische Suche ist derzeit nicht vorgesehen, nach Herstellerangaben aber leicht zu programmieren. Die Suche über den Thesaurus ist möglich. Suchanfragen wie auch Suchergebnisse können dauerhaft gespeichert und wieder abgerufen werden (9.9, 9.10). Im Recherchemodus ist die Änderung von Dokumenten nicht möglich. Die Sortierung des Suchergebnisses (9.8) ist frei definierbar. GOS unterstützt Aufbau und Pflege eines polyhierarchischen Thesaurus nach DIN 1463 (13.1) einschließlich Synonymverwaltung. Neue Einträge können manuell permutiert werden, so daß der Terminus im alphabetischen Register unter der Ausgangsbenennung und der permutierten Bezeichnung aufgeführt wird (z.B. “Tonpfeife” auch unter “Pfeife, Ton-”). Bei Neueingabe eines Deskriptors im Thesaurus werden die Rückverweise zwischen Ober- und Unterbegriff (und den anderen Relationen) automatisch gesetzt. Für Druckausgaben (10) stehen eine Reihe von vordefinierten Ausgabeformaten für den direkten Ausdruck wie für die Druckaufbereitung in Textverarbeitungs- oder Satzprogrammen nach dem Export der Daten zur Verfügung. Das Sammeln ausgewählter Dokumente auf einem “Stapel” (10.1.1) ist nicht möglich, man kann aber Inventarnummernbereiche direkt aus dem Programm heraus ausdrucken lassen. Sammlungsverwaltung (12) Viele Funktionen der Sammlungsverwaltung, z.B. Zugangsdokumentation, Leihverkehr, Inventur, Ausstellungsplanung, werden durch entsprechende Felder, Masken oder Dateiformate sowie durch die Erzeugung von Formularen, Listen etc. unterstützt. Zur Standortverwaltung gibt es ein Modul, das bei Neueingabe eines Standortes den vorherigen Eintrag in der Feldwiederholgruppe “früherer Standort” archiviert. Diese History-Funktion kann bei Bedarf auch in andere Sammlungsverwaltungsmodule implementiert werden. Special features: • • • Polyhierarchischer Thesaurus nach DIN 1463 mit der Unterstützung von Permutierungen Interne Umsetzung verbaler Datierungsangaben für die numerische Recherche sowie die Behandlung von Unschärfen in den Datierungsangaben Rekursive Online-Hilfe, mit deren Hilfe der Anwender über die bloße Anpassung der Hilfetexte hinaus Indexfeldern wie z.B. dem Inventarnummernfeld einen der Sortieralgorithmen von GOS zuweisen kann, der dann bei der Programmbenutzung Anwendung findet Literatur (Auswahl) • • Clemens, Hans-H. / Saro, Carlos: Abschlußbericht für das Projekt: Sammlungsmanagement für kulturgeschichtliche Museen in den neuen Bundesländern. Berlin 1998 Saro, Carlos / Schröder Beate / Volkmann, Katrin: GOS-Benutzerhandbuch. Berlin 1997 Referenzmuseen (Auswahl) • • • • • • Deutsches Historisches Museum, Herr Dr. Asmuss, Unter den Linden 2, D-10117 Berlin, Tel. 03020304330 Deutsches Hygiene Museum Dresden, Herr Rüdiger, Lingnerplatz 1, D-01069 Dresden, Tel. 0351- 8304545 Museum für Volkskunde, Frau Dr. Karasek, Im Winkel 6/8, D-14195 Berlin, Tel. 030- 83901288 Museum für Völkerkunde, Frau Dr. Tietmeyer, Lanssstr. 8, D-14195 Berlin, Tel. 030-8301438 (Zentr.) Bayerisches Nationalmuseum, Frau AlbrechtMesser, Prinzregentenstr. 3, D-80538 München, Tel. 089- 21124249 Kunsthistorisches Museum Rostock, Frau Mulsow, Klosterhof, D-18055 Rostock, Tel. 0381-455913 Medieneinbindung (14) Zu jedem Datensatz lassen sich mehrere digitale Bilder (14.1.4) einbinden; GOS bietet reine Bildverwaltung, keine Bildbearbeitung. Die Anzeige in der Datenbank ist auf das Vollbild beschränkt. Für den Ausdruck steht eine große Palette von Druckvorlagen für Text- und Bilddaten zur Verfügung. 25 HiDA3 Hersteller/Anbieter: startext GmbH Kennedyallee 2 D-53175 Bonn Tel.: 0228-050 960 Fax. 0228-959 9666 E-Mail: [email protected] Internet: http://www.startext.de/HiDA3 Ansprechpartner: Robert Denzin HiDA ist eine Kombination aus einer relationalen und einer hierarchischen Datenbank, auf deren Basis Anwendungen programmiert worden sind, die ohne weitere Programmierung im Museum einsetzbar sind. Eine kundenspezifische Anpassung ist möglich. Programmschwerpunkte sind die Inventarisierung und Katalogisierung in Museen, Archiven und Biblio- theken. Produktinformation HiDA (Hierarchischer Dokumentadministrator) gibt es seit 1988; das letzte Update stammt von 1997. HiDA3 wird in 95 Museen und Kunstsammlungen eingesetzt, Vorgängerversionen in weiteren 300 musealen Einrichtungen. Die Anwender werden mit Mailings oder mittels WWW-Seiten über Updates informiert, einen Newsletter gibt es nicht. Das Bildarchiv Foto Marburg organisiert Anwendertreffen im Rahmen des DISKUS-Projektes. Für die weitere Entwicklung (1998) sind u.a. die Netzwerkfähigkeit, der Zugriff auf ORACLEDatenbanken sowie eine Schnittstelle zu WorkflowSystemen geplant. Programmanpassungen kann der geschulte Anwender in der Steuerdatei vornehmen; entsprechende Schulungen werden von den Anwenderverbünden angeboten. Im Kundenauftrag führt auch die Firma startext GmbH Anpassungsarbeiten durch. Programmphilosophie Zielgruppe sind zum einen große Sammlungen mit umfangreichen Bilddatenbeständen (z.B. DISKUSVerbund), zum anderen kleine und mittlere Museen (z.B. Verbund der nichtstaatlichen Museen in Bayern, Sachsen und Westfalen-Lippe). HiDA ist darauf ausgerichtet, die wissenschaftliche Katalogisierung in aller Differenziertheit zu unterstützen und dabei die Nutzung von Normdaten wie AKL, PND oder ICONCLASS zu erleichtern. Zur terminologischen Kontrolle dienen Oberbegriffsdateien; ein Thesaurus, der DIN 1463 entspricht, ist für HiDA3.2 angekündigt. Zum Test Die Massendaten wurden importiert, wobei die Problemfälle (carriage return / line feed im Textfeld) gefunden und der Folgetext abgeschnitten wurde. Die komplexen Daten und der Auszug aus dem “Materialthesaurus” wurden importiert; die Bilder 26 wurden in die Massendaten eingebunden. Die Anbieter führten den Test mit einer Betaversion des zweiten Release von HiDA3 vor. Programmfunktionen Die Hintergrundfarben, die Plazierung der Datenfelder und die Bildschirmmasken (4.4) der grafischen Benutzeroberfläche (4.1) können vom Anwender benutzerspezifisch angepaßt werden. Die Statuszeile zeigt jeweils die Datensatznummer des bearbeiteten Dokuments an, so daß bei längeren Dokumenten auf Folgeseiten die Inventarnummer nicht erkennbar ist. Das Programm kann mit verschiedenen Datenfeldkatalogen (DISKUS, LNM, SLM, WMA, IDM) ausgeliefert werden. Anpassungen der Datenstruktur (5) kann der geschulte Anwender vornehmen. Das Indexkonzept (3.7) von HiDA sieht Indexfelder und Volltextfelder vor. Es findet keine automatische Aktualisierung (3.7.1) der Indizes beim Abspeichern eines Datensatzes statt. Der Invertierungsvorgang wurde in HiDA3 wesentlich beschleunigt, er behindert dennoch die Arbeit, wenn der Anwender bei Recherchen immer auf den aktuellen Index zugreifen möchte. Neben Mehrfachfeldern (5.2.1) gibt es auch Feldwiederholgruppen (5.2.2), die ein korrektes Retrievalergebnis in zusammengehörigen, aber getrennt recherchierbaren Datenfeldern (z.B. Material und Technik) gestatten. Dies konnte nicht vorgeführt werden (s.o). Daten zu einem komplexen Objekt (5.2.3), wie z.B. einem Service und seinen Teilen, können durch Anlegen eines hierarchischen Blockdokuments mit einem Übersichtsdokument für die gemeinsamen Informationen und Unterblöcken für die Teilobjekte verwaltet werden. Ein HiDA3-Dokument kann bis zu 10.000 Teildokumente, hierarchisch in bis zu fünf Ebenen strukturiert, umfassen. Bei Bedarf können Daten aus dem ersten Block auch in den Folgeblöcken angezeigt werden. Diese Funktionalität konnte im Test nicht gezeigt werden, da kein entsprechender Datenfeldkatalog gewählt wurde. Kontextinformationen (z.B. Literatur, geografische Termini etc.) können in verknüpften Dateien (“Seitendateien” oder “Normdateien”) verwaltet und für das Retrieval genutzt werden (5.3.1). Die Gesamtheit der mit einem Objektdatensatz verknüpften “Seitendateien” kann mit der Funktion “Index Normdokumente” angezeigt werden. Es ist auch möglich, aus dem Programm heraus auf externe Normdateien wie AKL, PND oder ICONCLASS zuzugreifen und Einträge über die WindowsZwischenablage in den bearbeiteten Datensatz einzufügen. Dateneingabe und -bearbeitung (6) können durch Batchimport von Daten (mit formaler Prüfung), durch einen Makro-Rekorder und zahlreiche Kopierfunktionen (z.B. von Datenfeldgruppen, den “Verbunddeskriptoren”) beschleunigt werden. Besonders hilfreich ist die Erstellung von Dokumentvorlagen (6.3.2), die bei der Recherche nicht als Treffer angezeigt werden. Die Funktion Globales Suchen und Ersetzen (6.9) ist für HiDA3.2 geplant; innerhalb eines Datensatzes können Einträge jedoch menüunterstützt ersetzt werden. Das Rückgängigmachen (6.12) von Fehllöschungen ist im Datensatz über die Funktion “Bearbeiten-Rückgängig” möglich. Versehentlich gelöschte Dokumente können vom Datenbankadministrator gegebenenfalls mit Hilfe der Protokolldatei wiederhergestellt werden. Inventarnummern (6.4, 9.8) können vorlagegetreu eingegeben werden. Laufende Zahlen sowie Inventarnummern aus Jahreszahl/Nummer werden korrekt sortiert. Das funktioniert allerdings nicht bei Nummernsystemen mit nachgestelltem Sortierkriterium oder bei römischen Zahlen. Die Anbieter schlugen vor, Inventarnummern gegebenenfalls aufgesplittet in drei sortierfähige Felder einzugeben; komplizierte Nummernsortierungen können im Kundenauftrag programmiert werden. Das Retrieval (9) gestattet die Suche mit Boole’schen Operatoren, Rechtstrunkierung sowie kontextbezogene Suche. Verschiedene Suchanfragen können miteinander kombiniert und abgespeichert werden. Von der Trefferliste aus, deren Anzeigeinhalt vom Anwender veränderbar ist, können die einzelnen Datensätze aufgerufen und bearbeitet werden. Es ist nicht möglich, beliebige Datensätze (z.B. für die Druckaufbereitung) auf einen “Stapel” zu legen (10.1.1); durch Export der Datensätze in eine eigene Datei kann diese Funktionalität für Ausdrucke jedoch auch erreicht werden. Zur terminologischen Kontrolle wurde in HiDA bislang mit “Oberbegriffsdateien” gearbeitet. Aufbau und Pflege eines Thesaurus nach DIN 1463 (13.1) sind für HiDA3.2 angekündigt, die derzeitige Funktionalität des Releases, so wie sie im Test vorgeführt wurde, entspricht der Thesaurusnorm noch nicht. Druckausgaben (10) können entweder aus dem Programm heraus gestartet oder nach dem Datenexport extern aufbereitet werden. Eine hilfreiche Funktion ermöglicht es, sensible Daten vom Export auszuschließen. In diesem Zusammenhang ist auch das Zusatzprogramm HiDA-Publisher zu nennen, das die Aufbereitung von exportierten HiDA-Daten für die Publikation von Katalogen, Lexika und Registern ermöglicht. Sammlungsverwaltung (12) Zur Sammlungsverwaltung stehen eine Reihe von Datenfeldern zur Verfügung, um Leihverkehr, Fotoverwaltung, Ausstellungsplanung sowie Restaurierungs- und Konservierungsmaßnahmen zu dokumentieren und durch vordefinierte Ausgabeprodukte wie Listen, Tabellen u.a. zu unterstützen. Feste Programmfunktionen sind in HiDA3 für die Sammungsverwaltung nicht vorgesehen, eine Schnittstelle zu Workflow-Management-Systemen aber geplant (s.o.). Medieneinbindung (14) Zu jedem Dokument lassen sich bis zu 150 digitale Bilder zuordnen, indem man den Dateinamen der jeweiligen Bilddatei oder die Bildnummer der PhotoCD eingibt. Als Anzeigemodi bietet HiDA3 die gemeinsame Text- und Bilddarstellung in einem Formular, die Vollansicht des Bildes und den Galeriemodus an; Bilder können auch gezoomt werden. Über Plug-Ins lassen sich weitere Medien wie Video und Ton einbinden. Special features • • • Knopf zum Ausschließen sensibler Daten vom Export Funktionalität zur Kennzeichnung von Kandidaten für neue Termini in den Indexlisten und zur Einarbeitung dieser Begriffe in das kontrollierte Vokabular Verknüpfung mit externen Normdateien wie der PND oder dem AKL aus einem Feld der HiDADatenbank heraus Literatur (Auswahl) • • • Heusinger, Lutz: Marburger Informations-, Dokumentations- und Administrations-System (MIDAS) Handbuch. 3. Aufl. München [u.a.] 1994 Mohr, Klaus: Foto-Inventarisierung mit HiDA im Niederbayrischen Landwirtschaftsmuseum Regen. In: EDV-Tage Theuern 1993. Kolloquiumsbericht. Theuern 1993, S. 38-44 Pröstler, Viktor: Die Windows-Version der Datenbank HiDA. In: EDV-Tage Theuern 1992. Kolloquiumsbericht. Theuern 1993, S. 34 - 40 Referenzmuseen (Auswahl) • • • Bildarchiv Foto Marburg im Kunstgeschichtlichen Institut der Philipps-Universität, Herr Dr. Brandt, Wolffstr. 2, D-35037 Marburg, Tel. 06421-283600 Spielzeugmuseum Nürnberg, Herr Dr. Schwarz, Karlstr. 13-15, D-90403 Nürnberg, Tel. 09112313260 Mindener Museum für Geschichte, Landes- und Volkskunde, Herr Plöger, Ritterstr. 23-33, D-32423 Minden, Tel. 0571-89659 Nachtrag Nach Herstellerangaben verfügt HiDA jetzt über eine erweiterte Funktionalität: zu jedem Dokument läßt sich eine unbegrenzte Anzahl von Bildern zuordnen und auch die Thesaurusverwaltung und -pflege nach DIN 1463 ist nun möglich. ImageFinder Museo 2.0 27 Hersteller/Anbieter: ImageFinder Systems AG Badenerstr. 338 CH-8040 Zürich Tel. 0041-1 492 42 53 Fax 0041-1 493 44 14 E-Mail: [email protected] Ansprechpartner: Irmgard Meier (Administration) Lothar Hausfeld (Leiter Entwicklung) Folke Wulf (Support) ImageFinder Museo ist eine auf einem relationalen Datenbanksystem basierende Anwendung, die ohne weitere Programmierung im Museum einsetzbar ist und teilweise kundenspezifisch angepaßt werden kann. Programmschwerpunkte sind Inventarisierung, Katalogisierung, Sammlungsverwaltung, Verleih, Bildhandling und –marketing sowie Copyright-Verwaltung. Produktinformation ImageFinder ist eine umfassende Software-Lösung für die elektronische Archivierung, Verwaltung und Distribution von Bildern und Begleitinformationen auf der Basis des Datenbankmanagementsystems 4th Dimension. Das System wurde 1993 für den Einsatz durch Fotografen und Bildagenturen entwickelt. Mittlerweile gibt es für verschiedene Anwendungsbereiche Speziallösungen, die in Zusammenarbeit mit Experten entwickelt wurden, so auch das Programm ImageFinder Museo (eine Weiterentwicklung von ImageFinder Cultura). Haupteinsatzgebiete sind Museen, Archive, Fotoagenturen, Verlage, wissenschaftliche Institute. Programmphilosophie ImageFinder Museo richtet sich an Museen jeder Größe und Sparte, bei denen Bilddokumentation eine zentrale Rolle spielt. Der Hersteller möchte die Museen in die Lage versetzen, ihre Bilder selbst zu vermarkten – unabhängig von Institutionen wie Corbis oder Getty. Aus diesem Grund beteiligt sich ImageFinder an den EU-Projekten ArtWeb (Kommerzielles Anbieten von Fotos) und EISS (Zentraler Copyright-Nachweis), deren Ergebnisse in den Leistungsumfang des Programms einfließen. Aus diesem Ansatz heraus unterstützt ImageFinder Museo die strukturierte Erfassung wissenschaftlicher und verwaltungstechnischer Informationen (Sammlungen, Ausstellungen, Restaurierung, Standorte, Verleih, Verwaltung u.a.) zu Museumsobjekten und schließlich – über die reine Fotoverwaltunghinaus – das Bildmarketing und das Anbieten von Bildern via Internet. Zum Test Die Massendaten wurden importiert, wobei die Problemfälle (carriage return / line feed im Textfeld) gefunden und der Folgetext abgeschnitten wurde. Die komplexen Daten und der Auszug aus dem 28 “Materialthesaurus” wurden mit Hilfe eines Parsers importiert und manuell ergänzt; die Bilder wurden eingebunden. Der Test wurde am Prototypen der Version ImageFinder Museo 2.0 durchgeführt, die im Frühjahr 1998 auf den Markt kommen soll. Da mit den Testdaten keine Felddefinitionen ausgeliefert worden waren, war das Feld “Objektbezeichnung” nicht indiziert worden, weil die meisten Nutzer aus dem Museumsbereich die Objekte als “Keywords” in einem “Multikatalog” suchen; von daher waren manche Suchanfragen nur eingeschränkt zu beantworten. Programmfunktionen Der Bildschirm der grafischen Benutzeroberfläche (4) ist in vier Bereiche gegliedert: links werden die administrativen Daten zum Objekt aufgeführt, rechts die beschreibenden Angaben und Verweise, unten die acht Schlagwort-“Kataloge” und in der Mitte jeweils ein Bild. Die Datenstruktur (5) ist vordefiniert und nur wenige Felder sind vom Anwender veränderbar. Es gibt Indexfelder sowie Volltextfelder, die z.T. wortweise indiziert werden können. Indexfelder können Mehrfacheinträge (5.2.1) enthalten, die auch einzeln recherchierbar sind. Wiederholbare Datenfeldgruppen (5.2.2) stehen nicht zur Verfügung. Für die Suche zusammengehöriger, aber getrennt recherchierbarer Einträge, z.B. in den Feldern Material und Technik, kann der Anwender entweder eine feldbezogene Volltextrecherche starten oder die Angaben zu Material und Technik als eigenen Terminus (z.B. “Kiefer, genutet”) in den “Katalog” aufnehmen. Die Abbildung eines aus mehreren Teilen bestehenden Objektes, wie z.B. einem Service (5.2.3), ist über eine Verweiskategorie möglich, bei der im Objektdatensatz der Hinweis auf “parts” eingetragen wird und in den Datensätzen der Teilobjekte ein Hinweis auf den “parent”. Auch Kontextinformationen können so mit dem Objektdatensatz verknüpft und per Mausklick angesteuert werden. Dateneingabe und –bearbeitung (6) werden unterstützt durch optionalen Batchimport, durch Textverarbeitungsfunktionen und durch Vorbelegung (nicht beliebig) wählbarer Felder. Man kann Dokumentvorlagen (“Templates”) (6.3.2) anlegen; sie werden aber beim Retrieval als Treffer mit angezeigt. Dieser Nachteil soll bei den geplanten “Basistemplates” ausgeräumt werden. Globales Suchen und Ersetzen (6.9) in Indexfeldern wurde vorgeführt. Das Rückgängigmachen (6.12) von Änderungen wird vom Programm nicht unterstützt. Inventarnummern können vorlagegetreu eingegeben (6.4, 9.8), aber nur eingeschränkt korrekt sortiert werden. Inventarnummern aus Jahreszahl/Nummer konnten richtig sortiert werden, andere mit nachgestelltem Sortierkriterium jedoch nicht; römische Zahlen ebensowenig. Die Anbieter schlagen vor, die Inventarnummer bei der Eingabe in drei Sortierfelder einzugeben, die in der Anzeige wie ein Feld erscheinen. Kompliziertere Sortieralgorithmen müßten programmiert werden. Für das Retrieval (9) stehen dem Anwender Volltextsuche, Suche über Schlag- oder Stichworte sowie nach Bildern oder die Kombination dieser Optionen zur Verfügung. Beim Retrieval spielen die übersichtlich angeordneten “Kataloge” eine große Rolle; ein “Keyword” wird immer in allen “Katalogen” gesucht. Für die Suche stehen die Boole’schen Operatoren sowie Links-, Mitte- und Rechtstrunkierung zur Verfügung. Das Abfrageergebnis kann als reine Textliste, als illustrierte Liste – wobei entweder ein großes, drei mittlere oder sieben kleine Bilder mit den wichtigsten Textinformationen angezeigt werden – oder im Galeriemodus (“Lightbox”) eingesehen und bearbeitet werden (9.7.2). Bis zu 30 mehrsprachige monohierarchische Thesauri (13.1) oder gleichordnende Begriffslisten können gleichzeitig eingesehen und benutzt werden. Nach Herstellerangaben erfüllen die Thesauri die ISO(DIN)Norm weitgehend: neben Ober- und Unterbegriffsrelationen können auch Synonyme verwaltet werden; nur Verweise sind nicht vorgesehen. Die systematische Thesaurusanzeige entspricht ebenfalls nicht der ISO(DIN)-Norm. Die Thesaurusbearbeitung wird vom Menü unterstützt (z.B. die Neuaufnahme von Termini oder das “Umhängen” ganzer Zweige). Für die Druckausgabe kann man auch beliebige Dokumente in einem “Sammelkorb” zusammenstellen (10.1.1) und aus der großen Zahl vordefinierter Druckformate die gewünschte Druckgestaltung auswählen. Die Einbeziehung von Daten aus verknüpften Datensätzen kann über den Reportgenerator (im Advanced-User-Modus) definiert werden. Mit dem Zusatzprogramm WebConnect können die erstellten Daten ins Internet gestellt werden. Sammlungsverwaltung (12) Die Sammlungsverwaltung wird durch verschiedene Module unterstützt. So kann man eine Sammlung anlegen, der auch nachträglich Objekte oder Objektgruppen zugewiesen werden können. Bei vielen Sammlungsverwaltungsmodulen steht die History-Funktion zur Dokumentation früherer Vorgänge zur Verfügung. Besonders ausgeprägt ist die Unterstützung des Leihverkehrs durch Terminverwaltung mit Mahnfunktion und Adressenverwaltung. Über die reine Fotoverwaltung hinaus ist auch die Vergabe von Reproduktionsrechten möglich. Bei der Standortverwaltung ist es möglich, Objekte zwischen Standorten zu “verschieben” (analog zum Dateimanager). Durch eine History-Funktion wird jeder Wechsel festgehalten. Medieneinbindung (14) In ImageFinder Museo können Bilder verwaltet, nicht jedoch bearbeitet werden. Die bereits digital vorliegenden Bilder können entweder aus dem geöffneten Datensatz heraus oder im Batchbetrieb eingebunden werden, wobei im letzeren Fall der Dateiname des Bildes dem “Namen” (z.B. Inventarnummer) des jeweiligen Objektdatensatzes entsprechen muß. Die Bildanzeige und das “Handling” der Bilddaten sind komfortabel und bieten vielfältige Möglichkeiten der Anzeige und Auswahl von Datensätzen (“Lightbox”, “Select-Liste”). Anmerkungen ImageFinder Museo bietet vielfältige, durch ein komplexes Menü unterstützte Arbeitsmöglichkeiten. Eine Online-Hilfe zu Programm und Datenfeldkatalog ist nicht vorgesehen; dies erwies sich bei der Vorführung gelegentlich als Defizit. Special features • • Die komfortable Erstellung von Importfiltern Das Textverarbeitungsmodul, das in Textfeldern die Nutzung verschiedener Fonts (griechisch, kyrillisch etc.) ermöglicht. (Leider stehen diese Schriftfonts nicht für Recherchen in Indexfeldern zur Verfügung.) Referenzmuseen (Auswahl) • • • • • IKA Institut für klassische Archäologie, Frau Barbara Kopf, Franz Klein-Gasse 1, A-1190 Wien, Tel. 0043-1 31352242 Museum für Völkerkunde, Herr Manfred C. Kaufmann, Neue Hofburg, A-1014 Wien, Tel. 00431 53430544 Im EU-Forschungsprojekt Artweb: Bildarchiv Preussischer Kulturbesitz, Dr. Karl Heinz Pütz, Märkisches Ufer 16-18, D-10179 Berlin, Tel. 03027879212 Im EU-Forschungsprojekt Artweb: The Bridgeman Art Library, Mr. Lewis Orr, 17-19 Garway Road, GB-London W2 4PH, Tel. 0044-171 7274065 Im EU-Forschungsprojekt Artweb: Réunion des Musées Nationaux, Agence photographique, Mr. Michel Richard, 10, rue de l’Abbaye, F-75006 Paris, Tel. 0033-1 4013 4620 IMDAS-Pro 1.0.0 29 Thesaurus nach der ISO(DIN)-Norm in Vorbereitung. Hersteller/Anbieter: JOANNEUM RESEARCH Forschungsgesellschaft mbH Hans-Sachs-Gassse 14/III A-8010 Graz Tel. 0043-316 811 210 13 Fax 0043-316 811 210 30 E-Mail: [email protected] Internet: http://ima023.joanneum.ac.at Ansprechpartner: Dipl. Ing. Silvia Rußegger IMDAS ist ein Anwendungsprogramm auf der Basis einer relationalen Datenbank, das ohne weitere Programmierung im Museum einsetzbar ist. Schwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung in einer vernetzten Umgebung. Produktinformation Das Einstiegsmodell IMDAS-ELS (Integrated Museum Documentation and Administration System – Entry Level System) auf der Basis des Datenbanksystems MS-Access, ist seit Mai 1996 auf dem Markt. Es ist hauptsächlich für Einzelplatzsysteme vorgesehen und wird in 36 Museen, Archiven und im Kunsthandel eingesetzt. Das Programm wird nicht weiterentwickelt, sondern durch IMDAS-Pro (= Professional) abgelöst werden. IMDAS-Pro setzt mit seiner Client-ServerArchitektur auf einem – vom Anwender zusätzlich zu erwerbenden – relationalen Datenbanksystem (z.B. ORACLE, INFORMIX o.a.) auf. Geplant ist auch eine preisgünstigere Version für kleine Institutionen. Installation und Anpassungsarbeiten werden von der Firma JOANNEUM RESEARCH Forschungsgesellschaft mbH im Kundenauftrag vorgenommen. Die institutionalisierte Form der Weiterentwicklung von IMDAS erfolgt über das jährliche Anwendertreffen, auf dem neue Anforderungen formuliert und in Zusammenarbeit mit der Interessengemeinschaft Niederösterreichischer Museen erarbeitet werden. Die Ergebnisse werden allen Kunden zur Verfügung gestellt. Anpassungsarbeiten für das jeweilige Museum können auch vom Datenbankadministrator vorgenommen werden, der über Kenntnisse der zugrundeliegenden Datenbank und über SQL-Kenntnisse verfügen muß. Programmphilosophie Zielgruppe sind Museen verschiedener Größenordnung. In die Entwicklung fließen Erkenntnisse aus internationalen Museumsprojekten (CIMI, MUSoNET) ein, die am Institut für Informationsmanagement der JOANNEUM RESEARCH Forschungsgesellschaft bearbeitet werden. Entsprechend soll IMDAS-Pro über die Z39.50Schnittstelle zur Abfrage verteilter Datenbanken im Internet verfügen. Zur Terminologiekontrolle ist ein Nur das Blättern im Datenbestand (6.8) in der Reihenfolge der vom System vergebenen Inventarnummern konnte vorgeführt werden. Das 30 Zum Test Nach Aussage des Herstellers wurden die Testdaten problemlos eingelesen. Der Auszug aus dem “Materialthesaurus” wurde als hierarchische Liste importiert, die Bilddaten eingebunden. Gezeigt wurde eine Beta-Version von IMDAS-Pro auf der Basis des Datenbanksystems ORACLE. Da es sich zum Zeitpunkt des Tests noch in der Entwicklung befand, konnten viele Programmfunktionen nicht vorgeführt werden. Laut Aussage des Anbieters werden alle Möglichkeiten des Einstiegsmodells auch in der neuen Version zur Verfügung stehen. Die Programmfunktionen Die grafische Benutzeroberfläche (4.1) ist fest definiert. Für die Gestaltung individueller Bildschirmmasken (4.4) sind Kenntnisse des zugrundeliegenden Programmiersystems erforderlich. Alle Grunddaten zu einem Objekt sind auf einer Bildschirmseite ablesbar. Für die Anzeige weitergehender Informationen müssen gegebenenfalls einzelne Felder “aufgeblättert” werden. Die Datenstruktur (5) von IMDAS-Pro ist vorgegeben. Der Datenfeldkatalog (5.1.1) orientiert sich an internationalen Standards (z.B. CIDOCEmpfehlungen). Für das Einrichten zusätzlicher Datenfelder (5.1.2) sind Kenntnisse des Datenbanksystems erforderlich. Wie der Test zeigte, sind mehrere Eintragungen in einem Datenfeld getrennt recherchierbar (5.2.1). Inhaltlich zusammengehörige Felder wie Material und Technik können in Form einer Tabelle beliebig oft wiederholt werden, bei der Recherche führte die fehlende Eindeutigkeit in der Beziehung der Felder zueinander jedoch zu einem falschen Suchergebnis (5.2.2). Nicht vorgeführt wurde die Verknüpfung eines komplexen Objektes mit seinen Teilobjekten (5.2.3), wie z.B. einem Service. Verknüpfungen der Objektdaten (5.2.3) mit Spezialdateien wurden am Beispiel der Literaturangaben gezeigt, wobei eine komfortable Bedienung über einen Button fehlte. Extern erstellte Referenzdateien (5.3.2) lassen sich – wie der “Materialthesaurus” – in IMDAS einspielen, sofern die Datenstrukturen deckungsgleich sind. Zur Erleichterung der Dateneingabe- und bearbeitung (6) gleichartiger oder sich wiederholender Daten kann ein Datensatz (ohne die verknüpften Informationen) als Kopiervorlage unter einer Pseudo-Nummer abgespeichert werden. Diese Vorlage wird jedoch bei einer Recherche als Treffer mitangezeigt (6.3.3). Sind Felder mit festen Wortlisten verknüpft (z.B. Künstler, Material, Standort), so kann nur ein Begriff aus diesen Listen übernommen werden. Die Erweiterung einer festen Wortliste hängt vom Benutzerrecht ab. Wenn ein Thesaurus mit dem Feld verknüpft wird, kann der Benutzer ebenfalls einen Eintrag in den bearbeiteten Datensatz einfügen (6.6). Globale Suchen und Ersetzen (6.9) über mehrere Datensätze ist bewußt dem Datenbankadministrator vorbehalten, da die Gefahr von Fehlern hier recht groß ist. Änderungen, Löschungen oder Neuaufnahmen können durch eine Abfrage beim Speichern des Datensatzes rückgängig gemacht werden. Die laufende Bearbeitung kann durch die Funktion “Rückgängig” abgebrochen werden (6.12). Um eine richtige Sortierung der Inventarnummern (9.8) zu gewährleisten, bietet IMDAS die automatische Generierung einer laufenden Nummer durch das System an. Die Problematik alphanumerischer Inventarnummern wird bei IMDAS standardmäßig nicht berücksichtigt und müßte gegebenenfalls programmiert werden (6.4). Die Inventarnummern der Testdaten wurden in ein Feld für alte Nummern importiert. Dort ist die vorlagegetreue Eingabe von Inventarnummern möglich, nicht aber die korrekte Sortierung. Das bedeutet, IMDAS-Pro konnte mit den unterschiedlichen Nummernsystemen der Testdaten nicht korrekt umgehen. Für das Retrieval (9) stehen dem Anwender die logischen Operatoren zur Verfügung. Die Recherche mit dem Operator “und nicht” konnte nicht vorgeführt werden. Der Administrator hat zudem über die SQLAbfragesprache Zugriff auf das Datenbanksystem. Eine Suche ist in allen Datenfeldern über Indizes oder Volltextretrieval (wortweise Indizierung) möglich, wobei neben der voreingestellten Rechtstrunkierung auch Mittel- oder Linkstrunkierung vorgesehen sind. Die Suche mit einer Linkstrunkierung wurde im Test abgebrochen, da sie mehrere Minuten in Anspruch nahm. Das Retrieval unter Einbeziehung eines Thesaurus konnte nicht vorgeführt werden. Rechercheergebnisse werden in einer Liste mit Trefferquote angezeigt (9.7.2), von der aus der Anwender einzelne Objektdatensätze aufrufen und ändern kann. Andere Anzeigeformate müssen vom Administrator definiert werden. Das Suchergebnis kann nur nach der automatisch vergebenen Inventarnummer sortiert werden (9.8). Ein Speichern der Suchergebnisse (9.10) ist nur über die Exportfunktion realisierbar, die nicht vorgeführt wurde. IMDAS unterstützt eine Thesaurusfunktion (13.1), die es erlaubt, einen separat zu erstellenden monohierarchischen Thesaurus mit den Feldern in der Erfassungsmaske zu verknüpfen. Dabei kann ein Thesaurus auch mit mehreren Feldern verbunden sein. Bei der Erstellung und Bearbeitung eines Thesaurus wird der Anwender durch eine Erfassungsmaske unterstützt, in der er Unter- und Oberbegriffe zuordnet und auch ganze Zweige verschieben kann. Die Vorteile eines Thesaurus nach DIN 1463, mit dem es möglich ist, über Oberbegriffe, Synonyme oder verwandte Begriffe zu suchen, konnten im Test nicht vorgeführt werden. Die verschiedenen Möglichkeiten, Druckausgaben (10) in vordefinierten Formaten auszugeben oder für die Druckaufbereitung in ein externes Programm zu exportieren, wurden im Test nicht gezeigt. Auch der Ausdruck miteinander verknüpfter Datensätze konnte nicht gezeigt werden. Sammlungsverwaltung (12) Alle Daten zur Sammlungsverwaltung und -pflege (Erwerbungsdaten, Ausleihdaten, Wertangaben, Erhaltungszustand etc.) werden in Feldern des Objektdatensatzes erfaßt. Darüber hinaus können die Daten für die Druckaufbereitung in anderen Programmen exportiert werden. Einige häufig benötigte Anzeige- und Ausgabeformate (z.B. Inventurliste, Standortliste, Zustandsliste, Registrierbeleg u.a.) sollen jedoch auch standardmäßig mitgeliefert werden, wie dies in der alten Version bereits der Fall war. Besonders erwähnenswert ist die Standortverwaltung: Bei der Eingabe eines neuen Standortes wird die vorherige Eintragung automatisch der Liste der ehemaligen Standorte hinzugefügt (History-Funktion). Medieneinbindung (14) Aus IMDAS-Pro heraus kann man Bilder mit einer digitalen Kamera aufnehmen. Bilder werden in IMDAS als eigenständige Dokumente behandelt (also extern und nicht in der Datenbank verfügbar gehalten) und über Relationen recht komfortabel mit den Objekten verknüpft. Auf diese Weise können auch beliebig viele Bilder mit einem Objekt verknüpft und direkt von IMDAS aus mit zusätzlicher Software bearbeitet werden. Für die Anzeige der Bilder stehen dem Benutzer die üblichen Darstellungsmöglichkeiten zur Verfügung; geplant ist die Einführung eines Leuchtpultes. Alle sonstigen Medien (z.B. Ton, Video), die in digitalisierter Form vorliegen, können auf die gleiche Weise wie Bilder in die Datenbank einbezogen werden. Special features • • History-Funktion im Datenfeld der Objektbezeichnung zur Dokumentation früherer Benennungen und Zuschreibungen des Objekts History-Funktion im Datenfeld der Standortangaben zur Dokumentation früherer Standorte Literatur (Auswahl) • • • Vernetzung von Datenbanken im Bereich des kulturellen Erbes – Einsatz internationaler bibliothekarischer und dokumentarischer Standards. Informationstag “Telematikanwendungen für Bibliotheken”; Wien, Jänner 1997 Museum informatics and global access to cultural heritage databases. 48th Conference and Congress – Globalization of Information – The Networking Information Society; Graz, 1996 Artikel in Zeitschriften: Neues Museum, Nr. 3 u. 4/1995; Stellwand, 2-3/1996, Museum Aktuell, Nr. 10, Juni 1996 Referenzmuseen (Auswahl) • Heeresgeschichtliches Museum, Militärhistorisches Institut, Herr Ulrich Zenker, Arsenal Objekt 1, A-1032 Wien, Tel. 0043-1 79561590 31 • Museumsagentur Dr. Christian Müller-Straten, Kunzweg 3, D-81243 München, Tel. 089- 830770 Hanns-Schell-Collection, Österreichisches Museum für Schloss-Schlüssel-Kästchen, Kassetten und Eisenkunstguss, Frau Pall, Wienerstr. 10, A-8020 Graz, Tel. 0043-316 71565638 • M-Box 2.1 Hersteller/Anbieter: DATEN UNLIMITED Freundsberg 48 A-6130 Schwaz Tel. 0043-5242 72 717 Fax 0043-5242 74 080 E-Mail: [email protected] Internet: http://www.mbox.at Ansprechpartner: Rudolf Wiener M-Box 2.1 ist ein Anwendungsprogramm auf der Basis einer relationalen Datenbank, das kundenspezifisch angepaßt werden kann. Programmschwerpunkte liegen bei der Katalogisierung und Inventarisierung. Produktinformation M-Box wurde 1989 im Auftrag des Tiroler Geschichtsvereins als DOS-Anwendung ursprünglich zur Fotoarchivierung programmiert und steht seit 1997 unter Windows zur Verfügung. Die Portierung auf UNIX oder MAC ist jederzeit möglich. Es ist netzwerkfähig unter Novell und Windows NT. Es gibt gegenwärtig ca. 30 Einzelplatz- und sieben Netzwerkanwendungen. Programmanpassungen können vom Anwender selbst oder im Kundenauftrag durch die Firma DATEN UNLIMITED ausgeführt werden. Programmphilosophie Das Programm unterstützt die Dokumentation heterogener Sammlungsbestände. M-Box wird in Museen, Archiven und Forschungsinstituten eingesetzt. Als Zielgruppe werden insbesondere Anwender gesehen, die sich nicht häufig mit der Inventarisierung beschäftigen; daher legt der Hersteller Wert auf schnelle Erlernbarkeit und einfache Bedienung. Nach Herstellerempfehlung sollte ein Museum vor dem Einsatz von M-Box eine Systematik für die Katalogisierung formuliert haben. Die Anwender sollten mit dieser Systematik und mit den Katalogisierungsrichtlinien des Museums vertraut sein. Der Schwerpunkt des Programmes liegt bei der Dokumentation des Sammlungsgutes; die gezielte Unterstützung der Sammlungsverwaltung ist für die Zukunft geplant. Die Massendaten wurden importiert, wobei die Problemfälle (line feed / carriage return im Textfeld) gefunden wurden. Bei der Analyse der Felder durch den Anbieter wurden die “unsauberen” Einträge z.B. im Datierungsfeld als Problem empfunden, aber nicht bearbeitet. Zudem war es nach Herstellerangaben bisweilen schwierig, die Eigenschaften für die Testdatenfelder festzulegen, ohne den Testablauf zu kennen, da der Datenbankaufbau von M-Box vorher konfiguriert werden mußte. Der Auszug aus dem “Materialthesaurus” wurde importiert, die komplexen Datensätze eingegeben und die Bilddateien eingebunden. Programmfunktionen Bestimmendes Element der grafischen Benutzeroberfläche (4) ist die “Karteikarte”, in die die Daten eingetragen werden. Die individuelle Gestaltung durch Anwender erfolgt über “Musterkarten”, die pro Objektart (z. B. Exponate, Literatur, Personen etc.) anzulegen sind (4.4). Auf ihnen werden über Eigenschaftsfelder die spezifischen Datenfelder und ihre Struktur bestimmt (5.1.2). Das äußere Format der zu definierenden “Karteikarte” bleibt dabei immer gleich: in der Mitte der “Vorderseite” gibt es ein großes Fenster, in dem der “Suchbegriffskatalog” (s.u.) zu sehen ist, auf der “Rückseite” werden Verweise angegeben. Die Datenstruktur (5) ist nicht vorgegeben; es gibt unterschiedliche Datenfeldtypen mit spezifischen Eigenschaften, die der Anwender auf den “Musterkarten” festlegt. Neben dem “Suchbegriffskatalog” gibt es zwei indizierte Beschreibungsfelder und zwölf frei zu definierende Felder. Diese können auch zu Datumsfeldern gemacht werden, denen außergewöhnlich viele, sehr weitgehende Sortieralgorithmen hinterlegt werden können (numerische Datierungen, Texteinträge, CircaAngaben). Die Indizes werden beim Abspeichern eines Datensatzes automatisch aktualisiert. Mehrfacheintragungen in einem Feld sind über Substring-Suche recherchierbar (5.2.1). Gruppenbildung von Datenfeldern (5.2.2) ist nicht vorgesehen. Um zu erreichen, daß zusammengehörige Datenfelder, wie z.B. Material, Technik, getrennt recherchierbar sind, plant der Hersteller, das erste Feld als Deskriptor in den Suchbegriffskatalog aufzunehmen (z.B. “Kiefer”) und das zweite als Variante (z.B. “genutet”) zu definieren. Zum Test Objekte mit mehreren Teilobjekten werden jeweils mit 32 einer “Karteikarte” erfaßt und über das Datenfeld “Weitere Objekte” miteinander verknüpft. (5.2.3). Auf die gleiche Weise können zusammengehörige Daten (z. B. Personen) in Beziehung gesetzt werden. Der Datensatz, auf den verwiesen wird, kann per Mausklick angesteuert werden. Es läßt sich jedoch nicht darstellen, in welcher Beziehung die verknüpften Objekte zueinander stehen (z.B. Teil/Ganzes). Dateneingabe und -bearbeitung (6) können beschleunigt werden, indem die “Musterkarten”, die für jede Objektart angelegt werden, als Dokumentvorlage (6.3.2) benutzt werden; sie wurden im Test bei einer Suche korrekterweise nicht als Treffer mitangezeigt. Die Übernahme von Eintragungen aus Wortlisten (offene und geschlossene) konnte im Test demonstriert werden (6.6); sie werden in der “Musterkarte” für das Datenfeld festgelegt. M-Box ermöglicht dabei auch die Eingabe von Abkürzungen, die beim Abspeichern automatisch durch den Volleintrag ersetzt werden (6.3). Auf externe Dateien kann nicht zugegriffen werden – entsprechende Daten müßten vorher in die Datenbank importiert werden (5.3.2). Die Vergabe von doppelten Archivnummern (= Inventarnummer) wird systemseitig verhindert (7.1.1). Die Inventarnummer (6.4, 9.8) ist intern in einen obligatorischen Hauptteil, sowie optionale Vor- und Zusätze gegliedert; auf der “Karteikarte” erscheint sie als ein Datenfeld (6.4). Die Struktur der Inventarnummer definiert der Anwender auf der Musterkarte menüunterstützt selbst. Im Test zeigte sich, daß M-Box Inventarnummern mit voran- und nachgestellten Jahreszahlen bzw. laufenden Nummern problemlos sortieren kann, nicht jedoch römische Zahlen. Ein zentrales Instrument des Retrieval (9) ist der “Suchbegriffskatalog”, der auf der “Vorderseite” einer “Karteikarte” angezeigt wird und bei der Recherche wie ein facettierter Thesaurus benutzt werden kann. Die Recherche kann auch über mehrere Objektarten erfolgen. Während des Tests führte die kombinierte Suche mit Operatoren in einem Fall zu einem fehlerhaften Ergebnis (9.3). Das Problem ist laut Herstellerangaben inzwischen behoben (Brief vom 24.02.1998). Eine Besonderheit ist die “fuzzy logic”-Komponente, durch die der Anwender mittels eines grafischen Schiebereglers den Abweichungsgrad zwischen Suchbegriff und -ergebnis definieren kann. Bei der Benutzung muß allerdings u.U. mit Ergebnisballast gerechnet werden. Eine weitere Besonderheit ist das Retrieval über die Datumsfelder mit dem sehr leistungsstarken programminternen Suchalgorithmus (s.o.). Suchergebnisse lassen sich in Datensatz- und Listenform darstellen (9.7.2). Die Liste führt pro Objekt die Archivnummer und die Beschreibung auf; die Objektart bzw. die Objektbezeichnung fehlt leider. Suchfragen kann der Anwender als Profil speichern und bei Bedarf wieder laden (9.9). Suchergebnisse können nicht gespeichert, aber als gesonderter Datenbestand ausgelagert werden (9.10). Auf einen “Stapel” gelegt, kann man sie dann ausdrucken (10.1.1). Solange der Suchfilter aktiv ist, lassen sich Suchergebnisse auch ändern (9.11). Der “Suchbegriffskatalog” erfüllt die Anforderungen an einen polyhierarchischen Thesaurus (13.1) nach DINbzw. ISO-Norm weitgehend: Neben Ober- und Unterbegriffsrelation werden auch Synonyme verwaltet und für das Retrieval zur Verfügung gestellt; Verweise fehlen allerdings. Für die Neueingabe eines Terminus steht eine Maske zur Verfügung, in der auch Definitionen und Scope Notes festgehalten werden können. Bei der Erfassung eines neuen Unterbegriffs erfolgt der Rückverweis auf den Oberbegriff automatisch. Die Anzeige erfolgt in hierarchischer Form in alphabetischer Reihenfolge der Deskriptoren (wie Verzeichnisstruktur eines grafisch dargestellten Dateimanagers). Vor jedem Suchbegriff zeigen farbige Symbole an, ob es sich um einen Unterbegriff, Oberbegriff oder ein Synonym handelt. In dieser Form der Anzeige können die Schreibweise eines Deskriptors für alle Eintragungen geändert und außerdem ganze Suchzweige bei Änderungen der Hierarchie verschoben werden. Ungewöhnlich ist das Nebeneinander von Deskriptoren, die sich auf die Sachsystematik der Objekte, auf Orte, Personen etc. beziehen. Damit trägt der “Suchbegriffskatalog” jedoch Kennzeichen eines facettierten Thesaurus. M-Box verfügt über keinen eigenen Reportgenerator für Druckausgaben (10). Die Druckaufbereitung erfolgt in der Regel durch einen Export in Windows-95Anwendungen. Ein RTF-Filter ist vorhanden, so daß formatierte Texte erhalten bleiben. Mit einem Objekt verknüpfte Datensätze werden nicht automatisch mit ausgedruckt. Sammlungsverwaltung (12) Für die Sammlungsverwaltung könnten auch “Musterkarten” angelegt werden, doch der Hersteller betrachtet dies noch nicht als tätigkeitsunterstützende Funktion; diese sind für künftige Versionen von M-Box geplant. Medieneinbindung (14) Die Einbindung von digitalen Bildern erfolgt entweder integriert in die Datenbank oder als externe Datei. Neben der Bildverwaltung bietet M-Box auch die üblichen Bildbearbeitungsfunktionen sowie die Standard-Darstellungsformen (14.1.5). Auf der “Karteikarte” läßt sich nicht erkennen, ob ein Bild vorhanden ist. Wenn man parallel zur “Karteikarte” das Bild ansehen will, muß das Bildfenster geöffnet sein. Der Aufruf der Bilder erfolgt über Einzelbild oder Leuchtpult. Die Einbindung weiterer Medien wie Video und Ton ist geplant. Special features • • • Einbindung der im HIDA-Anwenderverbund der kleinen und mittleren Museen gepflegten Oberbegriffsdatei als spezieller “Suchbegriffskatalog” Innerhalb des Beschreibungsfeldes kann der Text formatiert und auch formatiert ausgegeben werden grafischer Schieberegler zur Bestimmung des zulässigen Unschärfengrades bei 33 Rechercheanfragen Interne Umsetzung verbaler Datierungen in numerische Angaben für die Recherche • Referenzen (Auswahl) • • • • • • Tiroler Landesmuseum Ferdinandeum, Dr. Claudia Sporer, Museumstr. 15, A-6020 Innsbruck, Tel. 0043-512 597439 Österreichisches TheaterMuseum Wien, Herr Haris Balic, Lobkowitzplatz 2, A-1010 Wien, Tel.: 0043-1 512 880038 Dr. Karl Renner-Institut Wien, Dr. Maria Mesner, Tel. 0043-1 80 46501 Stadtmuseum und Stadtarchiv Dornbirn, Mag. Werner Matt, Tel. 0043-5572 33 077 Tourismusmuseum Schloß Traunmannsdorf, Meran, Dr. Paul Rösch, Tel. 0039-473 220 221 Universität Innsbruck, Institut für Alte Geschichte, MOV plus 3.2 Hersteller/Anbieter: Sonnabend EDV-Beratung Im Eichsfeld 8 D-65428 Rüsselsheim Tel.: 06142-63644 E-mail: [email protected] Ansprechpartnerin: Sigrid Philipps, M.A. MOV plus 3.2 ist ein relationales Datenbanksystem, auf dessen Basis eine Anwendung erstellt wurde, die ohne weitere Programmierung im Museum einsetzbar ist. Programmschwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung. Produktinformation MOV gibt es seit 1988; das letzte Update stammt von 1996. MOV plus wird hauptsächlich in Museen (30) eingesetzt. Es gibt keinen Newsletter, aber vom Anbieter organisierte Anwenderkreise. Das Programm ist unter Novell netzwerkfähig. Programmanpassungen werden von der Firma Sonnabend EDV-Beratung in Kooperation mit FOKUS im Kundenauftrag durchgeführt. Programmphilosophie Zielgruppe sind kleine Museen mit geringer personeller und finanzieller Ausstattung, daher wird Wert auf die Abwärtskompatibilität zu älteren Rechnergenerationen gelegt. Aus dem gleichen Grund bietet MOV plus neben den Modulen für Inventar und Leihverkehr weitere für Adressverwaltung, Schriftverkehr und Bibliotheksverwaltung. Zum Test Beim Import der Massendaten wurden die Problemfälle (carriage return / line feed im Textfeld) gefunden und der Folgetext abgeschnitten. Die 34 • Institut für Geschichte, Literatur und Dokumente, Diathek, Forschungsinstitut für Alpine Vorzeit, Mag. Wolfgang Meixner, Tel. 0043-512 5074379 Verein für Geschichte der Arbeiterbewegung, Wien, Mag. Christian Stadelmann, Tel. 0043-1 5457870 4 Nachtrag Laut Herstellerangaben ist die Einbindung von Video und Ton jetzt realisiert. komplexen Daten und der Auszug aus dem “Materialthesaurus” wurden wegen Strukturunverträglichkeit nicht importiert bzw. eingegeben. Auch die Bilddaten wurden nicht eingebunden. Aus technischen Gründen konnten die Massendaten nicht geladen werden, deshalb wurde der Test nur anhand von 1.000 Datensätzen durchgeführt. Da die Testdaten nur auszugsweise zur Verfügung standen, war die Vollständigkeit der Treffer nicht zu ermitteln und die Angaben der Checkliste konnten in vielen Punkten nicht überprüft werden. Programmfunktionen Die Benutzeroberfläche (4.1) ist vordefiniert; einzelne Feldnamen können vom Anwender jedoch umbenannt werden. Die festen Bildschirmmasken (4.4) enthalten auf der ersten Seite “Katalog”-Informationen über das Objekt. Die drei Folgeseiten enthalten weitere, z.T. sensible Daten und können gegen Zugriff geschützt werden. Die Statuszeile enthält eine Vielzahl von Informationen zur Orientierung in der Datenbank und im Arbeitsmodus. Darüber hinaus zeigt sie die Inventarnummer des bearbeiteten Datensatzes an. Die Datenstruktur (5) ist vordefiniert; allerdings können Projektdateien, z.B. für Ausstellungsvorhaben, vom Benutzer eingerichtet werden. Es gibt automatisch indizierte Felder und Volltextfelder, in denen eine sequentielle Suche möglich ist. Die Liste der ca. 45 Indizes weist bei zentralen Feldern auch die Option “leeres Feld” (9.4.2) auf. Die Indizes werden beim Abspeichern eines Datensatzes automatisch aktualisiert. Gruppenbildung von Feldern (5.2.2) ist nicht vorgesehen. Daher müssen die entsprechenden Informationen (z.B. zu Material/Technik) zusammen in Mehrfachfelder (5.2.1) eingegeben werden. Wegen begrenzter Feldanzahl (z.B. ca. sechs Materialfelder) ist es aber gegebenenfalls notwendig, die “restlichen” Angaben in das Beschreibungsfeld zu setzen. Um die Dateneingabe (6) zu beschleunigen, lassen sich Datensätze kopieren. Dokumentvorlagen (6.3.2) können erzeugt werden, indem man einen Datensatz unter geänderter Inventarnummer (z.B. mit “$”) als “Arbeitsblatt” abspeichert und zum Überschreiben benutzt. Die Datensätze mit der veränderten Inventarnummer muß man beim Retrieval dann explizit ausschließen, wenn sie nicht als Treffer angezeigt werden sollen. “Globales Suchen und Ersetzen” (6.9) wird aus Sicherheitsgründen nicht ermöglicht. Die Funktion “Rückgängigmachen” (6.12) von Bearbeitungsschritten ist ebenso wie “Löschen” von Daten(sätzen) zweistufig angelegt und bietet zusätzlichen Schutz durch Kennwortabfrage. Eingeschränkt wird das “Rückgängigmachen” durch die Zahl der nachfolgenden Neuaufnahmen. Inventarnummern können vorlagegetreu eingegeben, laufende Nummern auch problemlos sortiert werden (6.4, 9.8). Bei Inventarnummern aus Jahreszahl/Nummer müssen führende Nullen eingefügt werden, um die richtige Sortierung zu gewährleisten. Inventarnummern mit nachgestelltem Sortierkriterium oder römische Zahlen können in MOV plus nicht korrekt sortiert werden. Für das Retrieval (9) werden Suchanfragen in “Filtern” gespeichert, die man (bis zu 500 Zeichen) übereinanderlegen und z.B. bei Routineanfragen abrufen kann. Mit den Filtern kann man auch nacheinander Recherchen in verschiedenen Datenbeständen abarbeiten (9.6). Die Tabellendarstellung des Suchergebnisses (9.7.2) beinhaltet z. B. Inventarnummer, Objektbezeichnung, Verweise etc. Die freie Sortierbarkeit des Suchergebnisses (9.8) konnte nicht vorgeführt werden. Die Inventarnummer ist immer als weiteres Sortierkriterium voreingestellt. In der Tabellenanzeige des Suchergebnisses können Standort, Foto-Nr., Versicherungs-Nr. und konservatorische Angaben geändert werden. Andere Änderungen müssen direkt in den einzelnen Datensätzen vorgenommen werden. Man kann zwar keinen “Stapel” (10.1.1) anlegen, um z.B. Datensätze auszudrucken, aber man kann diese durch ein zweckmäßiges Schlagwort kennzeichnen. Ein Thesaurus (13.1) zur terminologischen Kontrolle kann in MOV plus nicht eingebunden werden. Für die Druckausgaben (10) stehen eine Reihe vordefinierter Formate zur Verfügung (z.B. Karteikarte, Inventurlisten, Standortlisten, Zustandslisten). Diese Druckformate sehen keine Verknüpfung von Daten aus verschiedenen Programmodulen vor. Objektdatensatz kann man entweder eine vierteilige Standortangabe oder vier aufeinanderfolgende Standorte eintragen. Die Einträge werden jeweils überschrieben. Für Inventurarbeiten (12.7) existiert im Objektdatensatz ein Feld “Da/Nicht da”. Der Programmteil Restaurierungsverwaltung (12.9) ist noch in Arbeit. Es gibt im Objektdatensatz einige Felder für Restaurierungsangaben und die Möglichkeit, Zustandslisten auszudrucken. Für Ausstellungsvorhaben u.a. kann man Projektdateien einrichten. Es gibt punktuelle Verknüpfungen der Sammlungsmodule untereinander (12.10) sowie mit der Inventarisierung (12.11): vom Objektdatensatz aus kann man die Vorbesitzeradresse aus dem Adressmodul übernehmen; Bibliotheksmodul und Objektdatensatz sind nur über gemeinsam benutzte Schlagworte verbunden – es besteht keine Verknüpfung mit dem Literaturfeld im Objektdatensatz; vom Ausleihdatensatz aus wird im Inventurfeld des Objektdatensatzes die Anzeige “Nicht da” erzeugt. Medieneinbindung (14) Es können bis zu acht digitale Bilder zu einem Objektdatensatz eingebunden werden (nicht vorgeführt). Außerdem ist der Anschluß eines Microfiche-Gerätes möglich. Anmerkungen Es gibt ein Programmhandbuch und eine Kurzanleitung; eine Online-Hilfe zum Programm und zum Datenfeldkatalog (15.1, 15.2) werden angeblich von den Anwendern nicht verlangt, da das Programm selbsterklärend sei. In der Vorführung erwies sich dies als Defizit. Special features • • • • Anlegen von Projektdateien (für Ausstellungsvorhaben, Erwerbungsvorbereitung, Zugangsdokumentation etc.) Automatischer Standorteintrag (“Nicht da”) in dem Objektdatensatz beim Abspeichern eines Ausleihdatensatzes mit der gleichen Inv.Nr. Rückgängigmachen des Löschbefehls mit Kennwortschutz Einbindung eines Microfichegerätes Literatur (Auswahl) Sammlungsverwaltung (12) • Die Sammlungsverwaltung wird durch eine Reihe von Feldern, Funktionen und Ausgabeprodukten unterstützt: Es gibt ein Ausleihmodul (12.3), das auch zur Ausstellungsvorbereitung genutzt wird. Es verfügt über eine Terminplanung mit Mahnfunktion und ist an die Adressverwaltung angeschlossen. Änderungen in Datensätzen des Ausleihmoduls werden bewußt nicht in die Objektdatensätze zurückgeschrieben. In die vierteilige Kategorie “Standort” (12.6) im Referenzmuseen (Auswahl) • • Inventarisation mit dem Datenbanksystem Museum-Objekt-Verwaltung. In : Brandenburgische Museumsblätter (1995), S. 6067 Stadtmuseum Tübingen, Kornhausstr., D-72070 Tübingen, Tel. 07071-204711 Magdeburger Museen, Direktion, Otto-von 35 Guericke-Str. 68-73, D-39104 Magdeburg, Tel. 0391-5432645 robotron*BIDOK/M Hersteller/Anbieter: Robotron-Datenbank-Software GmbH Heidelberger Str. 14 01189 Dresden Tel. 0351-4021629 Fax 0351-4021699 E-Mail: [email protected] Internet: http://www.mpz.de Ansprechpartner: Holm Brendler robotron*BIDOK/M ist ein relationales Datenbanksystem, auf dessen Basis bereits eine Anwendung erstellt wurde, die ohne weitere Programmierung im Museum einsetzbar ist. Eine kundenspezifische Anpassung ist möglich. Programmschwerpunkte sind Inventarisierung, Katalogisierung und Sammlungsverwaltung. Produktinformation Die Firma RDS entwickelt als Partner von ORACLE Deutschland GmbH im Kundenauftrag Dokumentations- und Verwaltungs-Software. Dem Programm robotron*BIDOK/M liegt eine, vom Anwender zusätzlich zu erwerbende, ORACLEDatenbank zugrunde. robotron*BIDOK/M wurde nach einer Marktanalyse vom Stadtmuseum Meißen in Auftrag gegeben; es basiert auf der Analyse der Daten und Geschäftsprozesse dieses Museums und wird dort eingesetzt. Finanziert wurde die Programmentwicklung mit Fördermitteln aus einem Europa-Fonds. robotron*BIDOK/M wird seit 1996 durch RDS, abgestimmt mit dem Stadtmuseum Meißen, vertrieben und wurde in seiner neuesten Version von 1997 vorgeführt. robotron*BIDOK/M ist für die Arbeit in einem Netzwerk konzipiert und unterstützt verteilte Arbeitsprozesse durch Workflow-Management. Änderungen an der vordefinierten Anwendung können z.T. vom Datenbankadministrator durchgeführt werden, der über SQL- und ORACLE-Kenntnisse verfügen muß. Weitergehende Änderungen nimmt die Firma RDS im Kundenauftrag vor. Programmphilosophie Zielgruppe sind vor allem Museen, die ihre Dokumentation und Sammlungsverwaltung nach dem System von Knorr aufgebaut haben. robotron*BIDOK/M bildet den Knorr’schen Dokumentationsstandard ab und kombiniert ihn mit arbeitsteiligen Verfahren der Sammlungsverwaltung und -pflege für Einrichtungen mit unterschiedlich qualifizierten Mitarbeitern. Zum Test Beim Import der Massendaten wurden die 36 • Württembergisches Landesmuseum Stuttgart, Altes Schloß, Schillerplatz 6, D-70173 Stuttgart, Tel. 0711-2793400 Problemfälle (carriage return / line feed im Textfeld) gefunden und nicht importiert. Der “Materialthesaurus” wurde, da er mehr als die im Programm vorgesehenen fünf hierarchischen Stufen enthielt, als alphabetische Schlagwortliste importiert. Die komplexen Daten waren nicht eingelesen bzw. eingegeben worden, so daß ein großer Teil der Testfragen nicht überprüft werden konnte. Da die Testdaten ohne Datenfelddefinition ausgeliefert wurden, konnten manche Funktionen nicht vorgeführt werden, weil die “views” anders hätten definiert werden müssen (z.B. “Material” als Indexfeld). Programmfunktionen Die grafische Benutzeroberfläche (4) entspricht dem Knorr'schen Karteikartensystem. Datenfelder und Bildschirmdarstellung sind fest vorgegeben; besondere Wünsche müßten programmiert werden. Die Datenstruktur (5) von robotron*BIDOK/M ist vordefiniert: ein Datensatz wird durch vier Erfassungsmasken für Zugangsdokumentation, Objektdaten, Leihverkehr und Magazinierung abgebildet. Darüberhinaus gibt es einen Künstlerkatalog, einen bibliographischen Index sowie eine Adressdatei. Der Datenbankadministrator kann die Datenstruktur durch Änderung der “views” anpassen, indem er bestimmten Feldern einen anderen Datentyp und damit eine andere Funktionalität zuweist (z.B. “Material” als Text- oder Indexfeld). Es gibt Indexfelder und auf 2000 Zeichen begrenzte recherchierbare Freitextfelder. Sind längere Datenfelder nötig, müssen sogenannte “long rows” definiert werden. Ein solches, nicht recherchierbares, z.B. als Word-Dokument abgelegtes Feld (max. 2 Gigabyte), müßte extra programmiert werden. Bei Mehrfacheinträgen (5.2.1) in einem Datenfeld ist mit einer trunkierten Volltextsuche jede Eintragung einzeln recherchierbar (nicht vorgeführt). Wiederholbare Datenfeldgruppen (5.2.2) sind nicht vorgesehen. Bei der Aufnahme eines Objektes, das aus mehreren Einzelteilen besteht (5.2.3), muß der Anwender sich entscheiden, ob das gesamte Konvolut (“Metaobjekt”) als Datensatz erfaßt werden soll – dann werden die Einzelobjekte in einem nicht recherchierbaren Textfeld aufgeführt. Werden dagegen die Teilobjekte jeweils in einem Datensatz dokumentiert, so geht die Information über die Zusammengehörigkeit verloren, da Bezüge zwischen den Datensätzen nicht herzustellen sind. Verknüpfungen, beispielsweise von Adress-, Literaturund Objektdaten, sind möglich (5.3.1). Dateneingabe und -bearbeitung (6) sind in robotron*BIDOK/M so konzipiert, daß die Erfassung eines Objekts in mehreren Arbeitsschritten von Mitarbeitern mit unterschiedlichen Qualifikationen erfolgen kann. Dieser arbeitsteilige Prozeß wird dadurch unterstützt, daß die Wiedervorlagefunktion auf noch zu bearbeitende Einträge hinweist. Dokumentvorlagen (6.3.2) zur schnelleren Erfassung ähnlicher Objekte sind nicht vorgesehen. Auch das Kopieren eines Datensatzes ist nicht möglich, da das Programm doppelte Inventarnummern nicht zuläßt. Die Erleichterung der Dateneingabe ist über sogenannte “Wertelisten” (geschlossene Wortlisten, deren Bearbeitung dem Datenbankadministrator vorbehalten ist) möglich, aus denen Einträge in den bearbeiteten Datensatz kopiert werden können. Über einen kompletten Datenbestand hinweg die Funktion “Suchen und Ersetzen” (6.9) auszuführen, ist ebenfalls dem Datenbankadministrator vorbehalten. Die Datensätze werden durch eine eindeutige, vom Programm vergebene “Zählnummer” verwaltet, die in der gezeigten Anwendung zugleich die Funktion der Inventarnummer (6.4, 9.8) hat. Daneben gibt es ein Feld “alte Inventarnummer”, in das die Inventarnummern der Testdaten importiert wurden. Es ist so definiert, daß ein Feldeintrag nicht mehrfach auftreten darf – entsprechend wurden die in den Testdaten vorhandenen Dubletten (7.1.1) beim Einlesen entdeckt. In dieses Feld können Inventarnummern vorlagegetreu eingegeben werden, jedoch nur alphanumerisch sortiert. Die Effizienz des Retrieval (9) ist in starkem Maße davon abhängig, wie die “view”, die Zusammenstellung recherchierbarer (oder nur anzeigbarer) Datenfelder definiert ist. Die umfassendste Form des Retrievals, die “komplexe Recherche”, war für die Testdaten nicht definiert worden (s.o.) und wurde am Beispiel einer anderen Anwendung gezeigt. Die Maske für Suchanfragen ist identisch mit der Eingabemaske. Die Suchkriterien sind (abhängig von der “view”) nicht frei wählbar. Die Suche mit Operatoren (9.3) und Trunkierungen (9.4.1) konnte aufgrund des fehlenden Materialthesaurus nicht erfolgreich gezeigt werden. Die Anzeige der Trefferzahl konnte nicht vorgeführt werden. Suchergebnisse werden in Form (9.7.2) der vorhandenen Bildschirmmasken oder einer Liste (Report) angezeigt. Änderungen im Suchergebnis sind möglich (9.11). Die Sortierung des Retrievalergebnisses (9.8) wird im Report vorgenommen. Die Kriterien sind zwar über ein Menü ansteuerbar, geordnet wird aber stets nach der Zählnummer. Lediglich der Aufbau der Liste kann beeinflußt werden. In robotron*BIDOK/M kann ein monohierarchischer Thesaurus (13.1) mit fünf Hierarchiestufen geführt werden, der die Thesaurusnorm DIN 1463 nicht vollständig erfüllt. Bei der Dateneingabe können Eintragungen aus dem Thesaurus übernommen werden (nicht vorgeführt). Gezeigt wurde die Thesaurusfunktion am Beispiel einer eingebundenen Sammlungssystematik, in der beim Retrieval über eine Thesaurusstufe absteigend gesucht werden kann. Zugleich kann die obligatorische Zuordnung eines neuerfaßten Objektes zu einer Thesaurusstufe dazu genutzt werden, um abgeschlossene Sammlungen für Neueingaben zu sperren. Der Import von Normdateien oder Wortlisten (6.7) im ASCII-Format ist möglich. Terminologische Kontrollen (7.2) sind nicht vorgesehen. Für Druckausgaben (10) stehen sowohl vordefinierte als auch frei definierbare Formate zur Verfügung. Sensible Daten, z.B. Versicherungswerte, Adressen etc. werden nicht automatisch ausgedruckt. Sammlungsverwaltung (12) Ein großer Teil der Sammlungsverwaltung (12) wird durch die vier “Erfassungskarten” des Programms abgedeckt: Die Zugangsdokumentation erfolgt auf der “Inventarkarte”. Der Leihverkehr – mit der Adressverwaltung verknüpfbar – wird durch eine eigene “Karteikarte” dokumentiert. Die Geschichte der Ausleihvorgänge wird auf der “Magazinkarte” festgehalten. Fotobestellungen erfolgen über den “Leuchttisch”. Darüber ist zugleich eine Zuweisung an das Archiv möglich (“work flow”). Für eine andere Anwendung wurde ein hier implementierbares Modul entworfen, das die Abwicklung einer via Internet erfolgten Fotobestellung unterstützt. Die Lager- und Standortverwaltung erfolgt ebenfalls über die “Magazinkarte”; Angaben zum aktuellen und ständigen Standort werden jeweils überschrieben. Die Inventur erfolgt über den Sammlungsbericht. Angaben zu Restaurierungsmaßnahmen können als Dokumentationstext auf der “Karteikarte” (max. 2000 Zeichen) abgelegt oder als externes Dokument mit der “Karteikarte” verknüpft werden. Medieneinbindung (14) Die Zahl der Bilder pro Datensatz ist unbegrenzt; sie wird auf der “Karteikarte” angezeigt. Die Bilderfassung kann durch eine Videokamera und einen Scanner direkt vom Programm aus erfolgen. Zu dem digitalen Bild können auch Textdaten erfaßt und eine “Karteikarte” einem Künstler, einem Werk etc. zugeordnet werden. Hier kann auch die komplexe Recherche (s.o.) gestartet werden. In die “Fotothek” ist auch der “Leuchttisch” eingebunden, mit dem verschiedene Varianten der Bildanzeige möglich sind. Special features • • Unterstützung arbeitsteiliger Inventarisierung / Katalogisierung durch Wiedervorlagefunktion (Workflow-Management) Unterstützung des Leihverkehrs durch die Terminverwaltung mit Mahnfunktion, Adreßverwaltung und History-Funktion Referenzmuseen (Auswahl) • • • Stadtmuseum Meißen, Herr Neumann, Domplatz 4, D-01662 Meißen, Tel. 03521-453312 Staatlicher Mathematisch-Physikalischer Salon, Herr Dr. Blaßmeyer, Sophienstr., D-01067 Dresden, Tel. 0351-4951364 Staatliches Museum für Völkerkunde, Frau Martin, Palaisplatz 11, Japanisches Palais, D-01097 Dresden, Tel. 0351-8144852 (Zentr.: -801) 37 Glossar Das Glossar führt wichtige Begriffe und Abkürzungen auf, die in dieser Publikation verwendet werden, sowie einige Termini, die den Einstieg ins Thema erleichtern sollen. Neben allgemeinen Nachschlagewerken, Fachzeitschriften und Begriffsklärungen der Arbeitsgruppe, wurde auch ein an der Stuttgarter Hochschule für Bibliotheks- und Informationswesen zusammengestelltes WWWAngebot herangezogen: • http://www.uni-stuttgart.de/UNIuser/hbi/glossa r /glhome_d.htm Berücksichtigt wurden zudem Erläuterungen aus: • Ruwisch, Klaus: Systemanalyse zur EDVgestützten Bestandserschließung in kleinen und mittleren Museen. Westfälisches Museumsamt Münster. Münster, 1992 • Saro, Carlos: Glossar. In: Wolters, Christof: Computereinsatz im Museum. Normen und Standards und ihr Preis. Berlin, 1994 (Mitteilungen und Berichte aus dem Institut für Museumskunde; Nr. 1), S. 123ff 4th Generation Language Programmiersprache der vierten Generation, bekanntester Vertreter: SQL. 4th Dimension Relationales Datenbankmanagementsystem der Firma ACI. Access Von der Firma Microsoft entwickelte relationale Datenbank. Adobe-Photo-Shop Bildverarbeitungsprogramm. ANSI-Zeichensatz Genormter Zeichsatz des “American National Standards Institute”, wird von Windowsprogrammen zur Zeichendarstellung verwendet. Äquivalenzrelation Die Äquivalenzrelation dient der begrifflichen Kontrolle innerhalb eines Thesaurus nach DIN 1463. Sie bildet die Beziehung zwischen Synonymen ab. Vom Nicht-Deskriptor wird mit BS= “Benutze Synonym” auf den Deskriptor verwiesen. Vom Deskriptor wird mit BF= “Benutzt für” auf den Nicht-Deskriptor verwiesen. ASCII-Zeichensatz “American Standard Code for Information Interchange”, ein in den USA entstandener, inzwischen weltweit verbreiteter Standard für den Datenaustausch. Barcode Code, gebildet aus senkrechten Strichen mit unterschiedlichen Abständen, die von einem Barcode-Lesegerät abgetastet und digitalisiert werden. BASIC “Beginners All Purpose Symbolic Information Code”, 38 Programmiersprache. Benchmarktest Objektiver Test der Leistungsfähigkeit eines Computers, insbesondere der Schnelligkeit. Bildschirmmaske, Maske Bildschirmaufbau ähnlich eines Formulars zur Dateneingabe. Die Stelle, an der die Daten eingetragen werden können, wird mit dem Cursor angesteuert. BLOB “binary large object” (= großes Binärobjekt). Von Borland entwickelte Technik in Bitfeldern nicht nur Daten, sondern auch Bilder und Klänge zu speichern. BMP “Bitmap Picture”, Dateinamenserweiterung für einen Bilddateityp im Pixelformat. Boole’sche Operatoren Die von dem englischen Mathematiker George Boole (1815-1864) begründete Boole’sche Algebra ist logische Grundlage für die Entwicklung von Suchstrategien beim Retrieval in elektronischen Datenbanken. Mit Hilfe der Boole’schen Operatoren UND, ODER, NICHT werden logische Verknüpfungen von Suchbegriffen vorgenommen. Durch die Verknüpfung von zwei Suchbegriffen mit: 1. UND (AND) werden diejenigen Dokumente gefunden, in denen die beiden Suchbegriffe gemeinsam vorkommen (Schnittmenge). 2. ODER (OR) werden diejenigen Dokumente gefunden, in denen entweder der eine oder der andere Suchbegriff oder beide gemeinsam vorkommen (Vereinigungsmenge). 3. NICHT (NOT) werden diejenigen Dokumente gefunden, in denen nur der erste, nicht aber der andere Suchbegriff vorkommt (Restmenge). C++ Weiterentwicklung der Programmiersprache C. Sie unterstützt objektorientierte Programmiertechniken. Carriage return / line feed Zeilenvorschub. CD-ROM “Compact Disc Read-Only Memory”, optische Speicherplatte für ca. 640 MB Daten; Daten sind für den Anwender nur lesbar. CGM “Computer Graphics Reference Model”, Referenzmodell für die graphische Datenverarbeitung. CIDOC “Comité International pour la Documentation, International Committee for Documentation”, Kommittee des internationalen Museumsverbandes ICOM für die Museumsdokumentation. CIMI “Consortium for the Computer Interchange of Museum Information”, Zusammenschluß von museumsnahen Organisationen zur Entwicklung und Verbreitung von Standards für Datenaustausch und Zugriff auf verteilte (Museums-)Datenbanken über Client-Server-Modell Netzwerkmodell, bei dem es Arbeitsstationen (clients) gibt, die Dienste eines zentralen Servers benutzen können. Clipper Datenbankentwicklungssoftware. COLD “Computer Output to Laser Disc”, Ausgabe auf mit Laser beschreibbarem Speicher. Datei Eine Einheit zusammengehöriger Daten, die unter einem eindeutigen Namen vom Betriebssystem verarbeitet wird. Der Begriff wurde in Analogie zu “Kartei” gebildet. Datenbank Eine Sammlung von inhaltlich zusammenhängenden Daten. Daten wiederum repräsentieren Informationen oder Wissen aus der Anwendungswelt. Aus dokumentarischer Sicht handelt es sich bei einer Datenbank also um recherchefähige und auf einem Rechner installierte Dateien, die zusammengehörig sind und inhaltlich (oder auf andere Weise) verknüpft sind. Diese Verknüpfung geschieht strukturiert, weil die Datenbank darauf angelegt ist, die in ihr gespeicherten Daten suchbar zu machen. Datenbankmodell Grundlage jeder Datenbank ist ein theoretisches Konzept, das sogenannte Datenbankmodell, das die formale Beschreibung der Daten sowie ihre Beziehungen zueinander definiert. Die beiden wichtigsten Konzepte sind das hierarchische und das relationale Datenbankmodell. Darüber hinaus gibt es das Netzmodell, das objektorientierte und das hybride Modell. Datenbasis Eine Sammlung von Dokumenten in maschinenlesbarer Form. Datenfeld Ein Datenfeld ist Bestandteil eines Datensatzes. In gleichen Datenfeldern werden stets Informationen derselben Art gespeichert, analog zu einer Kategorie auf einer Karteikarte. Datensatz Zusammenfassung von Datenfeldern zu einer inhaltlich abgrenzbaren Einheit; entspricht ungefähr einer Karteikarte. DB Abkürzung für “Datenbank”. dBase Von der Firma Asthon-Tate entwickeltes relationales Datenbankprogramm. DBF “Data Base File”, häufig verwendete Dateinamenserweiterung für Datendateien einer Datenbank. DBMS Nichthierarchische Klassifikation, bei der es nur koordinierte, nicht aber untergeordnete Merkmale gibt. Die den Sachinhalt des Dokuments ausmachenden wesentlichen Begriffe werden durch das Internet. “Data Base Management System” (= DatenbankManagementsystem). Bezeichnung für ein Programm zum Aufbau, zur Verwaltung, Strukturierung und Pflege einer Datenbank. DDE “Dynamic Data Exchange”, von der Firma Microsoft entwickeltes Datenaustauschformat. Deskriptor a) Im engeren Sinn bezeichnet “Deskriptor” ein Klassenelement in einem Thesaurus nach DIN 1463 mit Vorzugsbenennung, d.h., alle anderen Elemente haben den Status von Nicht-Deskriptoren. Nicht-Deskriptoren bilden einen Bestandteil des Zugangsvokabulars, können aber selbst nicht zur Indexierung und Recherche verwendet werden, sondern verweisen auf den entsprechenden Deskriptor. Der Deskriptor sollte den Begriff möglichst umfassend, zweifelsfrei, genau darstellen und am Sprachgebrauch des jeweiligen Fachgebietes orientiert sein. b) Im weiteren Sinn bezeichnet “Deskriptor” in der EDV-Sprache ganz allgemein einen Eintrag aus einem beliebigen Index. DIF “Data Interchange Format”, Datenaustauschformat im Bereich des CAD (Computer-Aided-Design). DIN 1463 Î Thesaurus. DIN 1505 DIN-Norm für bibliographische Zitierstile. DISKUS “Digitales Informations-System für Kunst- und Sozialgeschichte”, ein vom Bildarchiv Foto Marburg koordinierter Dokumentationsverbund. Dokumentarische Bezugseinheit z B. das Museumsobjekt, s.a. Objekt. Dokumentationseinheit z. B. die Informationen auf einer Karteikarte oder in einem Datensatz, s.a. Objekt. DVD “Digital Versatile Disc”, neuer Standard für Massenspeicher mit bis zu 25facher Kapazität einer CD-ROM. DXF “Data Exchange Format”, Datenaustauschformat. EPSF Encapsulated Postscript-File, Dateiformat. Ethernet Netzwerkprotokoll der Firmen Xerox, DEC und Intel, dient dem Aufbau lokaler Netze. Excel Tabellenkalkulationsprogramm der Firma Microsoft. Externe Informationsquellen Î Informationsquellen, externe. Facettenklassifikation Inhaltsanalyse festgestellt. Jeder dieser Begriffe wird in den Klassifikationstafeln (Facetten) aufgesucht. Fachsystematik, Klassifikation, Systematik Die geordnete Gesamtheit der Klassen einer der 39 Ordnung von Begriffen dienenden Systematik in Form eines schriftlich fixierten Verzeichnisses. Die Beziehung der Klassifikation zu den zu ordnenden Objekten (z.B. Bücher, Museumsobjekte) charakterisiert ihren Anwendungsbereich. Die Fachsystematik wird in der Regel im Vorfeld des Dokumentationsprozesses erarbeitet. FlashPix Das FlashPix-Dateiformat wurde gemeinsam von den Firmen Kodak, Live Picture, Hewlett-Packard und Microsoft zur Bearbeitung von Bildern auf Standard-PCs entwickelt. FoxPro Datenbankprogramm der Firma Microsoft. Freitextsuche Suche, die nicht über einen Index erfolgt. Bei der Freitext-Suche können Mehrdeutigkeiten der natürlichen Sprache auftreten und sowohl zu Verlusten an relevanten Informationen als auch zu Ballast führen. Daher wird oft zusätzlich mit kontrolliertem (normierten) Vokabular gearbeitet (s. a. Terminologische Kontrolle). Fuzzy logic “Unscharfe Logik”, im Gegensatz zur mathematischen Logik sind bei der “fuzzy logic” auch Aussagen möglich, die bis zu einem gewissen Grad wahr und falsch zugleich sind. Bei einer Recherche würde “Meier” auch gefunden, wenn “Meyer” eingegeben wird. GEM “Graphics Environment Manager”, fensterorientierte Benutzeroberfläche, entwickelt von der Firma Digital Research. GKD Gemeinsame Körperschaftsdatei (GKD). Bibliothekarisches Hilfsmittel zur regelgerechten Ansetzung von Körperschaftsnamen. Geschlossene Wortliste Î Wortliste, offene oder geschlossene. GIF “Graphic Interchange Format”, Dateinamenserweiterung für Pixelgrafiken, die insbesondere für den Austausch von Bilddaten über das Netz entwickelt wurden. Gruppenfeld, Gruppendatenfeld Gruppenfelder fassen inhaltlich zusammengehörige Datenfelder ( z.B. Material,Technik etc.) zusammen. Die Gruppe wird vom Programm als Einheit angesprochen, d.h., sie kann komplett als Gruppe kopiert oder gelöscht werden. Gruppenfelder sind stets wiederholbar (s.a. Wiederholgruppe). HDD “Hard Disk Drive”, Festplatte. Hierarchisches Datenbankmodell Datenbankmodell, bei dem die Datensätze in einer Art Baumstruktur abgebildet werden, um eine Überund Unterordnung zwischen den Daten deutlich zu machen. History-Funktion “International Standard Bibliographic Description” Weltweite Norm für den Austausch bibliographischer 40 Bei der History-Funktion werden ältere Eintragungen nicht überschrieben, sondern mit abgespeichert. Homonym Homonyme Ausdrücke verfügen über eine gleiche Ausdrucksform hinsichtlich Orthographie und Aussprache bei unterschiedlicher Bedeutung und verschiedener etymologischer Herkunft, z.B. Ton, Kiefer, Mark. HTML “Hypertext Markup Language”, Programmiersprache zur Erstellung von WWW-Seiten. Hybrid. Hier: unterschiedliche Datenbankmodelle vereinigend. Hyperlink, Link Verweis innerhalb eines Dokuments (z. B. in einer HTML-Datei ) auf eine andere Stelle desselben oder eines anderen Dokuments. Hyperlinks bauen vernetzte Strukturen auf, ohne daß sich die Dokumente dabei an einer Stelle befinden müssen. ICONCLASS International angewandte Klassifikation zur inhaltlichen Erschließung im Bereich der Bildenden Kunst. IMG “Image Format”, Dateiformat der Firma Digital Research. Index a) allgemeine Bezeichnung für Register ganz unterschiedlicher Art b) In Datenbanken werden Indizes verwendet, um Datensätze nach bestimmten Kriterien (z. B. dem Personennamen) zu sortieren und schnell auf die einzelnen Datensätze zugreifen zu können. Dabei wird im Index die Position der einzelnen Datensätze gespeichert. Da bei einem Wechsel des Indexes nicht der gesamte Datenbestand umgeordnet wird, sondern nur die Abfolge der Positionseinträge im Index, geht eine solche Umsortierung verhältnismäßig schnell. Information-Retrieval Î Retrieval. Informationsquellen, externe Relevante Informationen, die nicht schon in der Datenbank vorhanden sind. Intranet Firmen- oder institutioneninternes Computernetz, das auf der gleichen Technologie wie das Internet aufbaut, mit dem es auch verbunden sein kann. Invertierte Liste, invertierte Tabelle (engl. : inverted) Als invertierte Liste werden die Tabellen bezeichnet, in denen die Adressen aller Datensätze einer Datenbank vorhanden sind. IPX “Internet Packet Exchange”, Netzwerkprotokoll von Novell. ISBD Daten. ISDN “Integrated Services Digital Network”, schnelles Digitalnetz, über das Telefongespräche, Fax und Datenfernübertragung abgewickelt werden können. JPEG “Joint Photographics Experts Group”, Bildkomprimierungsformat. Juke-Box Wechselgerät für den kombinierten Gebrauch mehrerer CD-ROMs, Festplatten etc. Klassifikation Î Fachsystematik. Knorr Verfassername des verbindlichen Regelwerks zur Inventarisierung in Museen der DDR: Knorr, Heinz Arno: Inventarisation und Sammlung in den Heimatmuseen. Hrsg.: Fachstelle für Heimatmuseen. Halle a.d. S., 1958. Kreuzkatalog Der Kreuzkatalog ist ein alphabetisch geordneter Katalog, der zugleich der formalen und der sachlichen Bestandserschließung dient. Er vereinigt formale Merkmale wie Personennamen, Stichwörter usw. mit sachlichen Merkmalen wie Schlagwörter, Systematik in einem (!) Alphabet. LAN “Local Area Network”, lokales Netzwerk. Line feed Î Carriage return / line feed. Link Î Hyperlink. Lotus 1-2-3 Tabellenkalkulationsprogramm der Firma Lotus. MAB Maschinelles Austauschformat für Bibliotheken in Deutschland (Katalogdaten). MAC Standard-Bitmap-Grafikformat der Firma Macintosh. Mailings Informationsverbreitung über E-Mail. MARC Maschinelles Austauschformat für Bibliotheken international (Katalogdaten). Maske Î Bildschirmmaske. Maskierung Î Trunkierung. MBSF-Funktion “Magic Button Support Feature”, ein Druckknopf an der Zentraleinheit des Computers, dessen Bedienung sämtliche Probleme mit dem Computer und bei der Dokumentation löst – der Traum aller Anwender! MDA Museum Documentation Association. Bekannte englische Institution für das Objektorientiert Eigenschaft im Bereich der EDV, die Daten, Prozeduren und Funktionen gemeinsam als “Objekt” behandelt (Kapselung) und neue Objekte durch die Informationsmanagement in Museen. Mehrfacheintragung Bei einer Mehrfacheintragung in ein Datenfeld, können mehrere Deskriptoren verwendet werden. Dieses ist sinnvoll, wenn nach allen Eintragungen auch gesucht werden kann. Monohiercharchie In einer Monohierarchie hat ein Deskriptor nur einen Oberbegriff. MPEG “Moving Pictures Experts Group”, Datenformat zur Übertragung von bewegten Bildern. MS Abkürzung für die Firma Microsoft (s. a. die entsprechenden Produktnamen). MS SQL Server “Microsoft SQL Server“, Datenbankmanagementsystem, welches speziell für Client/Server-Systeme entwickelt wurde; ein Einsatzschwerpunkt ist die Industrie. Multimedia DV-gestützte Integration von Informationen aus verschiedenen Medien, z.B. Standbild, bewegten Bildern, Ton, Text usw. MUSoNET “Museum on the Net“, ungarisch-österreichischdeutsches Projekt zur Entwicklung und Verbreitung von Standards für Datenaustausch und Zugriff auf verteilte (Museums-)Datenbanken über das Internet. Novell Softwarehersteller, bekannt durch sein Netzwerkbetriebssystem. Oberbegriff, Unterbegriff Der Begriffsinhalt des engeren Begriffs (Unterbegriff) schließt den Begriffsinhalt des weiteren Begriffs (Oberbegriff) ein, wobei sich der Unterbegriff in mindestens einem zusätzlichen Merkmal von dem Oberbegriff unterscheidet. Ober- und Unterbegriffe werden immer in Beziehung zueinander gesehen; es ist ein relatives und kein absolutes Verhältnis, Oberbegriffe können nämlich in einer anderen Beziehung Unterbegriffe sein. Oberbegriffsdatei Eine in einem Anwenderverbund des Datenbankprogramms HIDA gepflegte Systematik für Museumsobjekte. Objekt Auf dem Feld der Museumsdokumentation ist das Museumsobjekt die zentrale dokumentarische Bezugseinheit. Es gibt aber auch noch andere: Personen, geographische Einheiten, Vorgänge, Literatur usw. Die Merkmale des Objektes (der dokumentarischen Bezugseinheit also), werden während des Dokumentationsprozesses strukturiert beschrieben. “Vererbung” (von Eigenschaften) eines Quellobjektes generiert. OCR “Optical Character Recognition”, optische 41 Zeichenerkennung, Verfahren zur Texterkennung nach dem Einscannen. ODBC “Open Database Connectivity”, Softwareschnittstelle für den Datentausch zwischen Datenbank und anderen Anwendungen. Offene Wortliste Î Wortliste, offene oder geschlossene. OLE “Objekt Linking and Embedding”, Verknüpfen und Einfügen unterschiedlicher Objekte in Anwendungsprogrammen (z.B. Tondateien in die Textverarbeitung). Online-Retrieval Î Retrieval. ORACLE Relationales Datenbanksystem der gleichnamigen Firma. OS/2 “Operating System NR.2 “, IBM-Betriebssystem. ÖS Abkürzung für Österreichischer Schilling (ca. 7 Schilling = 1DM / Stand: 1. Mai 1998). Parser Programm zur Überprüfung der Struktur eines Dokuments hinsichtlich seiner inneren Logik. PCD “Photo Compact Disc”, Foto-CD. PCX Dateiformat zur Speicherung von Bitmap-Grafiken. Peer to Peer Netzwerkkonfiguration, bei der jeder Rechner sowohl Client- als auch Server-Funktion übernimmt. Permutation Unter Permutation versteht man das Vertauschen der Glieder einer Schlagwortkette untereinander, die Mehrfacheintragungen in einem Register erzeugt, z.B. “Österreich / Küche“ u. “Küche / Österreich”. Personennamennormdatei (PND) Im Bibliothekswesen ist die PND ein normiertes Verzeichnis mit für die Katalogisierung benutzten Personennamen. PIC “Picture Image Compression”, komprimiertes Dateiformat für Standbilder. PICT Dateiformat im Bereich der grafischen Datenverarbeitung. PL ”Programing Language”, Programmiersprache. PND Î Personennormdatei (PND). Sacherschließung, Inhaltserschließung Methoden und Verfahren zur inhaltlichen Beschreibung von Dokumenten. Schlagwort, Schlagwortkatalog Benennung des sachlichen Inhalts. Die Schlagwortvergabe kann “frei” (z.B. nach 42 Polyhierarchie In einer Polyhierarchie kann ein Deskriptor mehrere Oberbegriffe haben. Polysem Polyseme sind Wörter mit verschiedener Bedeutung aber gemeinsamem Bedeutungsanteil, aufgrund gleicher sprachlicher Herkunft, z.B. Flügel (Instrument und Vögel), Schloß (Türschloß und Gebäude). PostScript Programmiersprache zur Seitenbeschreibung für PostScript-fähige Laserdrucker und Belichter. QbE Î Query by Example. Query by Example Abfragemethode, bei der das gesuchte Element in eine Maske eingetragen wird. Bei dieser Art der Suche muß der Anwender keine formale Abfragesprache (s. Query Language) erlernen. Query Language Formale Abfragesprache, mit der Anwender sich in der Regel vor der Suche vertraut machen muß. (s. a. SQL). Quicktime Programm für Multimedia-Anwendungen, von der Firma Apple entwickelt, inzwischen auch für Windows-Anwendungen. RAM “Random Access Memory”, Arbeitsspeicher. RDBS Relationales Datenbank-Mangementsystem, s.a.: DBMS. Relationales Datenbankmodell Datenbankmodell, dessen Konzept eine tabellenartige Struktur ist, über die Beziehungen zwischen Daten abgebildet werden. Report-Generator Funktion zur Unterstützung der Druckaufbereitung von Daten in Listenform. Reports Zusammenstellung von Daten aus einer Datenbank. Retrieval Das Retrieval (Online-Retrieval, InformationRetrieval) ist die Methode, mit der die gezielte Suche nach und das Wiederfinden von Informationen in einer Datenbank ermöglicht wird. Es bietet die Möglichkeit, Suchfragen mit Hilfe formaler und inhaltsbeschreibender Elemente und unter Verwendung spezieller logischer Operatoren (z.B. Boole’sche Operatoren) durchzuführen. SAA System Application Architecture. Gruppe von Software-Schnittstellen, Protokollen und anderen Konventionen (von IBM definiert). individuellen Hausregeln unter Beachtung der bereits vergebenen Schlagworte ) oder aufgrund eines Schlagwortregelwerks (z.B. den “Regeln für den Schlagwortkatalog - RSWK”) erfolgen. Der Schlagwortkatalog ist ein Katalog, der nach sachlichen Gesichtspunkten erschließt. Schlagwortnormdatei (SWD) Im Bibliothekswesen ist die SWD ein normiertes Verzeichnis mit den nach den “Regeln für den Schlagwortkatalog (RSWK)” vorgegebenen Schlagwörtern. Scope Note In der Thesaurusnorm DIN 1463 schriftliche Erläuterung zu einem Deskriptor und seinem Gebrauch. SCSI “Small Computer System Interface”, Schnittstelle mit einer relativ hohen Übertragungsrate. Server Rechner, der Dienste in einem Netzwerk bereitstellt. SFr Abkürzung für Schweizer Franken (0,83 Schweizer Franken = 1 DM / Stand: 1. Mai 1998). SPX “Sequenced Packet Exchange Protocol”, erweitertes IPX-Protokoll von Novell, das für eine verbindungsorientierte vollständige Übertragung sorgt. SQL “Structured Query Language”, Ende der 1970erJahre von der Firma IBM entwickelte Abfragesprache für Datenbanken. SWD Î Schlagwortnormdatei (SWD). Synonyme Synonyme sind Wörter derselben Sprache von gleicher oder ähnlicher Bedeutung, die bei der Sachkatalogisierung, speziell der Schlagwortkatalogisierung, sowie bei der Erarbeitung von Thesauri beachtet werden müssen. Syntaktische Indexierung Grundprinzip der Regeln für den Schlagwortkatalog. Einzelne Schlagwörter werden zu einer Schlagwortkette, die den Dokumenteninhalt wiedergibt, verbunden. Systematik Î Fachsystematik. TCP/IP “Transmission Control Protocol/Internet Protocol”, Übertragungsprotokoll für das Internet. Templates Bausteine in Softwareprojekten, die immer wieder verwendet werden. Terminologische Kontrolle Alle Verfahren innerhalb der Dokumentation, die das Auffinden von Informationen dadurch unterstützen, daß der verwendete Wortschatz einer Kontrolle bzw. Unter Trunkierung – auch Maskierung genannt – versteht man das Ersetzen von Buchstaben oder Wortbestandteilen durch Verwendung von Universalzeichen (z.B. $, ?). Verwandte Schreibweisen oder verschiedene Wortanfänge bzw. -endungen sollen dabei im Suchergebnis berücksichtigt werden. Man unterscheidet zwischen Trunkierung am Wortanfang (Linkstrunkierung), z.B. ?baum -> Apfelbaum, Birnbaum... , in der Wortmitte (Mitte, oder -Innentrunkierung), z.B. Do?umentation Normierung unterzogen wird. Mehrdeutigkeiten und Unschärfen der natürlichen Sprache wird dadurch begegnet, daß nur bestimmte Termini zugelassen sind und von den nicht als Deskriptor gebrauchten verwiesen wird. (s.a.: Thesaurus nach DIN 1463, Wortliste, offen oder geschlossen). TeX Name eines Textsatzsystems. Diese Software ist frei verfügbar. TGA “Targa Format”, Bitmap-Format für die professionelle Bildbearbeitung. Thesaurus (nach DIN 1463) a) Ein Thesaurus im Bereich der Information und Dokumentation ist eine geordnete Zusammenstellung von Begriffen und ihren (vorwiegend natürlichsprachigen) Bezeichnungen, die in einem Dokumentationsgebiet zum Indexieren, Speichern und Wiederauffinden dient. Seine Merkmale sind in der DIN-Norm 1463 festgelegt: Begriffe und Bezeichnungen werden eindeutig aufeinander bezogen (“terminologische Kontrolle”), indem Synonyme möglichst vollständig erfaßt und Homonyme und Polyseme besonders gekennzeichnet werden und für jeden Begriff eine Bezeichnung (Vorzugsbenennung, Begriffsnummer oder Notation) festgelegt wird, die den Begriff eindeutig vertritt. Die Beziehungen zwischen Begriffen (repräsentiert durch ihre Bezeichnungen) werden dargestellt. Man unterscheidet drei Typen von Beziehungen (Relationen): Äquivalenzrelation: Bezeichnungen, die bedeutungsähnlich sind, werden ein und demselben Begriff zugeordnet. Es wird mit BS = Benutze / BF =Benutzt für verwiesen. Hierarchierelation: Überund Unterordnungsverhältnis der Begriffe wird mit OB = übergeordneter Begriff / UB = untergeordneter Begriff gekennzeichnet. Assoziationsrelation: Relationen, die weder in hierarchischer noch in äquivalenter Beziehung zueinander stehen, werden mit VB = verwandter Begriff gekennzeichnet. b) Die Bezeichnung “Thesaurus” wird in der EDVSprache im weiteren Sinne sehr unterschiedlich verwendet – von einem einfachen alphabetischen Wortindex bis hin zu mehr oder weniger systematischen Wortlisten. Diese Bedeutung ist deutlich von der unter a) beschriebenen abzugrenzen! Thumbnails “Daumennagel”, verkleinerte Darstellung von Bildern. TIF, TIFF “Tag Image File Format”, Bildformat, das speziell für Scanner entwickelt wurde. Trunkierung, Maskierung -> Documentation oder Dokumentation - am Wortende (Rechtstrunkierung), z.B. Dokument? -> Dokumentation, Dokumente. UNIX Betriebssystem, stellt die Entwicklungsumgebung für die Programmiersprache C bereit. Unterbegriff Î Oberbegriff. URL 43 “Uniform Resource Locator”. Adresse im WWW, z.B. http://www.spiegel.de. Visual Basic Objektorientierte Programmiersprache, basierend auf BASIC. WAN “Wide Area Network”, Netz über große Entfernungen. Wiederholfeld, Wiederholdatenfeld Ein einzelnes Datenfeld, das wiederholt werden kann und in das dann weitere Eintragungen vorgenommen werden können. Es kann an verschiedenen Stellen im Datensatz vorkommen. Wiederholgruppe Eine Zusammenstellung von in der Regel inhaltlich zusammengehörenden Datenfeldern (z.B. Materialund Technikangaben), die als Gruppe wiederholt werden kann. Windows 3.x Grafische Benutzeroberfläche der Firma Microsoft, die noch auf dem Betriebssystem MS-DOS basiert. Windows 95 Grafische Benutzeroberfläche der Firma Microsoft, echtes 32Bit-System. Windows NT “Windows New Technology,” grafische Benutzeroberfläche der Firma Microsoft, ursprünglich eine gemeinsame Entwicklung mit IBM, basierend auf OS/2, dann aber selbständig weitergeführt. WKS “Work Sheet Files”, Dateiaustauschformat für die Tabellenkalkulation. Word Textverarbeitungsprogramm der Firma Microsoft. Workflow-Funktionen Programmfunktionen, die das Nacheinander verschiedener Abläufe in der Arbeitswelt unterstützen, z.B. den geregelten Geschäftsgang eines Museumsobjekts. Wortliste, offene oder geschlossene Liste, aus der der Anwender Deskriptoren beziehen kann (z.B. eine Liste aller deutschen Ortsnamen als Terminologiebasis bei Datenfeldern, in denen topographische Bezeichnungen eingetragen werden sollen). Offene Wortlisten können vom Benutzer erweitert werden, geschlossene hingegen nicht. Wortlisten dienen der terminologischen Kontrolle. WPG Grafikdateiformat des Textverarbeitungsprogramms WordPerfect. WWW “World Wide Web”, bekanntester Dienst im Internet, der die Angebote durch Hyperlinks verknüpft. Z39.50 Z39.50 ist eine weltweite Normierung für das Auffinden und das Retrieval von Datenbankinformationen im Internet. 44 Anhang Kontaktadressen Fachgruppe Dokumentation beim Deutschen Museumsbund Sprecherin: Monika Hagedorn-Saupe Institut für Museumskunde In der Halde 1 14195 Berlin Tel. 030-8301 460 Fax 030-8410 7862 E-Mail: [email protected] Westfälisches Museumsamt Schwelingstr. 5 48145 Münster Ansprechpartner: Dr. Günter Bernhardt Tel. 0251-591 4695 Manfred Hartmann Tel. 0251-591 3296 Fax 0251-591 3335 46