Verschiedene Möglichkeiten bei der Erstellung einer Typologie

In der Tabelle ist eine zeitliche Abschätzung zu den verschiedenen Wegen zur Erstellung einer Typologie gegeben.

Methode	Realisation	Standardisierung-Konsistenz	Vollständigkeit	Bild-Daten	Transparenz	Dynamische Typologie	Zeitverbrauch für Referenz-Datenbank, in h.
1) Beschreibung in Katalog	Volltexteingaben	nein	selten	nein	nein	nein	500
2) Definition von Merkmalen	An –oder Abwesenheit/ oder Messung von metrischen Daten	nein	selten	nein	nein	nein	500
3) „Thesaurus -System“	Eingabe mit unserem (obsoleten) Programm InputMachine	ja	vielleicht	nein	nein	nein	200
4) „Typen Tafeln“	Physisches Ausschneiden und anordnen auf Typentafeln	ja	selten	ja	ja	nein-schwierig	3000
5) Bilddatenbank  „Montelius “ + Bildbrowser ACDSee	Typologie   mit “Drag n’ Drop"	ja	ja	ja	ja	ja	100
6) Bilddatenbank  „Montelius “+ ”MonteliusEntry ” + Bildbrowser ACDSee	Typologie   mit “Drag n’Drop“	ja	ja	ja	ja	ja	30
7) Bilddatenbank  „Montelius “+ ”MonteliusEntry ” +integrierter Bildbrowser+MonteliusImageAnalyzer	Alle Korrekturen nur mit Bildbrowser Typologie "  mit “Drag n’Drop“	ja	ja	ja	ja	ja	20

1)       Beschreibungen in Form eines Katalogs: Das kennt man wohl aus den meisten Publikationen. Durch Verwendung von Volltexteingaben wird die weitere Brauchbarkeit reduziert. Nur selten werden standardisierte Begriffe verwendet. Auch die anderen Kriterien in der Tabelle werden nicht erfüllt.

2)       Definition von Merkmalen: Die An- oder Abwesenheit von Merkmalen aber auch Messergebnisse können zur Definition von Typen herangezogen werden. In diesem Fall werden die Merkmale aus der Kenntnis des Materials vorgegeben und die Maße ausgewählt und erfasst. Alle Gegenstände werden sukzessive durch diese Merkmale und Maße definiert, ohne dass dabei der Überblick über die Gesamtheit gewahrt bleibt. Jeder kennt die so genannten Merkmalslisten aus Publikationen, oft noch begleitet von einer Kartierung der Verteilung. Eine Überprüfung ist nur möglich, wenn man die Zitate bis in die Originalpublikationen verfolgt, eine mühsame Arbeit, der sich kaum jemand unterzieht. Somit kann kaum eine Standardisierung erreicht werden. Da aktuell keine Bilddaten vorliegen, ist auch die Transparenz nicht gewährleistet. Insgesamt ist das Verfahren sehr zeitaufwändig. Ein historisches Beispiel ist der „Mährische Code“ für die MOG-Gruppe der Lengyelkultur. Podborský Vladimir, Kazdová Eliska, Košturík Pavel, Weber Zdeněk 1977, Numerický kod moravské malované keramiky. Problémy deskripce v archeologii. Brno. Für die damalige Zeit war das ein großartiger Schritt vorwärts. Dieser „Mährische Code“ wurde auch – ohne Verwendung einer Bilddatenbank – von Michael Doneus – in seiner Dissertation benutzt. Heutzutage wäre es möglich, den „Mährischen Code“ als Bilddatenbank zu benutzen, aber noch niemand hat es getan. Daher ist es besser, dass man aus einer mit Methode 2) oder weitere erstellten Datenbank einen Katalog automatisch ausdrucken lässt. Siehe z. B. DONEUS Michael 2001, Die Keramik der mittelneolithischen Kreisgrabenanlage von Kamegg, Niederösterreich. Ein Beitrag zur Chronologie der Stufe MOG I der Lengyelkultur. MPK 046, 471p. Der Vorteil eines solchen Kataloges ist, dass er leichter gelesen werden kann als der Zahlenfriedhof einer kodierten Tabelle.

3)       Benutzung eines Thesaurussystems: Dadurch ist gewährleistet, dass im Falle von Texteingaben diese standardisiert sind. Außerdem können die Eingaben beschleunigt werden, wenn Texteingaben nicht getippt werden müssen, sondern einfach nur in einem Dropdown-Menü ausgewählt werden. Wir hatten dieses System in unserem Programm InputMachine realisiert. Mit Hilfe dieses Programms konnten die Eingaben zur gesamten Sammlung der Prähistorischen Abteilung in etwa 3 Jahren getätigt werden, obwohl mehr als 100.000 Einträge notwendig waren. Schon von Anfang war klar, dass das nur ein Werkzeug zur Inventarverwaltung nicht aber für wissenschaftliche Fragestellungen sein würde. Eine gewisse Vollständigkeit der Eingabe war damit erreichbar, niemals aber konnten die für eine Typologie notwendigen Kriterien erfüllt werden. In diesem Fall könnte die Textdatenbank durch eine Bilddatenbank ergänzt werden. STADLER Peter 1997b, Die Sammlungsdatenbank der Prähistorischen Abteilung des Naturhistorischen Museums in Wien.

4) Ab dem Jahr 1999 begannen wir dann mit dem Scannen der Abbildungen aus der Literatur und der Erfassung der Bilder in der Publikations- und Fundkomplexhierarchie der Bilddatenbank Montelius mit gleichzeitiger Eingabe von beschreibenden Elementen in einer einfachen Excel-Tabelle. Große Probleme machten hier zunächst diskrepante Eingaben zwischen Bildstruktur und Informationen in der Excel-Tabelle. Diese Fehler mussten langwierig korrigiert werden. Danach jedoch konnten die erfassten Gegenstände in die typologische Anordnung gebracht werden, von wo aus mittels Bildbrowser ACDSee eine dynamische Typologie durch „Drag ‘n Drop“ möglich wurde. Diese Veränderungen in der Bildstruktur der Typologie konnten nun ausgelesen werden und automatisch auf das Excel-File übertragen werden. Durch diese Vorgangsweise konnte die Erstellung oder Bearbeitung einer Typologie gegenüber Methode (3) etwa auf das hundertfache beschleunigt werden.

5) Der nächste, nahe liegende Schritt war nun die Entwicklung von MonteliusEntry.  Mit Hilfe dieses Programms, derzeit bereits durch das „Feedback“ der zahlreichen Mitarbeiter bereits in Version 7.1.1 wird gewährleistet, dass die Bilder an die richtige Stelle in der Hierarchie gespeichert werden, gleichzeitig aber auch konsistente Eingaben in der Excel-Tabelle vorliegen. Eventuelle Fehler können mit der einfachen Bearbeitungsmöglichkeit im Edit-Mode korrigiert werden. Alle beschreibenden Elemente wie Rohtypologie, Angaben zum Fundort etc. können einfach durch Auswählen aus einem Thesaurussystem eingegeben werden. Damit ist es nun möglich, dass die Mitarbeiter im Schnitt pro Stunde etwa 60 Eingaben oder mehr machen können. Bis jetzt konnten so an die 1.3500.000 Eingaben realisiert werden. Die dynamische Typologie ist nun genauso wie bei (4) weiterhin gegeben, dieser Schritt (5) spielte also vor allem für die Beschleunigung der Eingaben eine Rolle.

6)       Die nächste  Weiterentwicklung war die Entwicklung eines eigenen Bildbrowsers und Editors, der direkt in Montelius integriert wurde. Damit wurde eine Schwachstelle von Montelius beseitigt. Wurden mit der alten Version Korrekturen in der Bildstruktur der Fundkomplexe gemacht, dann musste man derzeit dieselben Änderungen im Excel-File durchführen, also eine redundante Arbeit. Alle Änderungen werden nun mit dem MonteliusEditor mit eigenen Bildbrowser gemacht, wodurch die Korrekturen automatisch im internen Excel-File präsent sind. Das bedeutet vor allem für den Hauptverwalter der Bilddatenbank noch einiges an Zeitersparnis. Mussten früher alle Bilder sowohl in der Komplex- als auch in der Typologie-Struktur abgespeichert werden, so befindet sich jetzt jedes Bild nur einmal auf der Festplatte. Alle anderen beliebig vielen Ansichten auf die Bilddatenbanken sind somit nur mehr virtuell.

7) MonteliusImageAnalyzer erlaubt es, die Bilder direkt auszuschneiden statt mit PaintShopPro. Dabei war es möglich diesen Vorgang noch wesentlich weiter zu beschleunigen, da alle Gegenstände auf einmal ausgeschnitten werden können.

8) MonteliusImageAnalyzer soll dieses Ausschneiden weitgehend automatisieren unter Benutzung der Concave Hull. Dann wäre es möglich eine Tafel mit 30 Objekten in 10 Sekunden oder weniger auszuschneiden entgegen dafür 2-3 Minuten zu benötigen. Das wäre ein weiterer enormer Zeitgewinn.

9) Die Weiterentwicklung von MonteliusImageAnalyzer in Richtung automatischer Erkennung der funktionellen Typen ist einstweilen noch Zukunftsmusik. Der derzeit erkennbare Weg führt dabei eventuell genauso wie bei der O(ptical)C(haracter)R(ecognition) über die Neuronale Netzwerkanalyse. Dann müsste der Bearbeiter nur mehr kontrollieren, ob der Computer den Gegenstand richtig „erkannt“ hat.

letzte Bearbeitung 21.10.2019