In diesem Kapitel werden die im MuSE-Tool zum Einsatz kommenden Taxo-nomien beschrieben. Sie werden in die Bereiche Basiselemente, Beschaffenheit und Sonstige unterteilt.
3.4.1 Basiselemente
Die Basiselemente sind die Grundbausteine der Kost¨ume und umfassen alle kost¨umrelevanten Arten von Bekleidungsteilen und Accessoires (z.B. M¨utze, Hose, Schuhe). Die erstellten Taxonomien k¨onnen aber niemals die Gesamt-heit aller m¨oglichen Basiselemente erfassen, da mit jedem neuen Film oder Modeerscheinung die Liste verl¨angert werden m¨usste. Die gegenw¨artige Taxo-nomie baut auf einem Bekleidungslexikon4, sowie einer lexikalen Recherche auf den Webseiten Bergfashionlibary 5, Amazon6, Zalando7 und Otto8 auf (vgl. [Bar13]).
3.4.2 Beschaffenheit
Um die Basiselemente exakt beschreiben zu k¨onnen, werden Taxonomien ben¨otigt, welche die einzelnen Basiselemente genauer beschreiben. Unter die-sen Taxonomien nehmen die Teilelemente eine besondere Stellung ein. Sie beschreiben die einzelnen Elemente aus denen das Basiselement aufgebaut ist und k¨onnen jeweils durch weitere Teilelemente beschrieben werden. Z.B.:
besitzt eine Hose (Basiselement) eine Ges¨aßtasche (Teilelement) mit Knopf (Unterteilelement).
Die weiteren Taxonomien sind Form, Material, Farbe, Design, Zustand, Tra-geweise, Funktion und K¨orpermodifikation. Ihre Aufgabe ist es, die Basis-und Teilelemente in ihrer jeweiligen Auspr¨agung genauer zu spezifizieren, damit sp¨ater Abfragen ¨uber die Eigenschaften gemacht werden k¨onnen und somit Gemeinsamkeiten oder Unterschiede sichtbar werden. Eine m¨ogliches Beispiel ist eine Hose, welche durch die Form kurz, das Material Baumwolle, Farbe blau, Design modern, Zustand abgetragen, Trageweise hochgekrem-pelt, Funktion Sportbekleidung und die K¨orpermodifikation Muskelbetonung beschrieben wird.
4W. Schierbaum (Hg.): Bekleidungslexikon. Mode, Formgestaltung, Schnittkonstrukti-on, Gradierung, Ausstattung, Zuschnitt, Verarbeitungstechnik, B¨ugeln, Management und Marketing, Berlin 1993.
5www.bergfashionlibrary.com
6www.amazon.de
7www.zalando.de
8www.otto.de
3.4.3 Operatoren
Eine weitere notwendige Taxonomie bilden die Operatoren. Durch sie kann angegeben werden, wie die verschiedenen Basiselemente zu einander angeord-net sind. Durch sie werden aus den einzelnen Basiselementen komplett zusam-menh¨angende Kost¨ume komponiert. Ein Beispiel ist die Beziehung zwischen T-Shirt und Pullover, der Pullover wird ¨uber dem T-Shirt getragen.
3.4.4 Sonstige
Alle weiteren Taxonomien besch¨aftigen sich nicht mit Basis- oder Teilele-menten, sondern beschreiben Spielorte und -zeiten an welchen die Kost¨ume getragen werden, die Charaktereigenschaften und Alter der Rolle sowie Gen-re, Produktionsort und Farbkonzept des Films. Verschiedene M¨oglichkeiten sind z.B. Spielort London, Spielzeit mittags, Charaktereigenschaft b¨ose, Alter jung, Genre Kom¨odie, Produktionsort USA sowie Farbkonzept schwarz/weiß.
3.4.5 Probleme
Bei der Entwicklung des MuSE-Tools zeigten sich zwei Probleme.
Um die erstellten Taxonomien im Werkzeug verwenden zu k¨onnen, m¨ussen diese zun¨achst in einer Datenbank abgelegt werden. Die Taxonomien von Hand einzupflegen w¨urde eine sehr große Zeit in Anspruch nehmen (ca. 5400 Eintr¨age). Da s¨amtliche Taxonomien jedoch bereits in elektronischer Form als Freemind-Dateien gespeichert vorliegen, wurde ein Taxonomy-Parser ent-wickelt. Dieser extrahiert die Taxonomien und deren Zusammenh¨ange und erstellt ein MySql-Script, mithilfe dessen die Taxonomien in einer Sql-Daten-bank gespeichert werden k¨onnen.
Ein weiteres Problem ist die Eingabe. Bei kleineren Taxonomien, wie zum Beispiel den K¨orperteilen (8 Eintr¨age) kann der Benutzer relativ leicht al-le M¨oglichkeiten vergleichen und den geeignetsten Eintrag ausw¨ahlen. Bei gr¨oßeren Taxonomien wie zum Beispiel Basiselemente mit ¨uber 1000 Ein-tr¨agen ist dies jedoch nicht mehr m¨oglich und eine Auswahl ¨uber eine Li-ste sehr ineffizient. Auch eine Suchfunktion w¨urde nur geringe Vorteile bie-ten. Der Benutzer kann zwar die gew¨unschten Eintr¨age leichter finden, je-doch kann er nicht alle Eintr¨age mit einander vergleichen. Dies f¨uhrt da-zu, dass der Benutzer auf bereits verwendete Eintr¨age zugreift und eventu-ell zutreffendere Eintr¨age ¨ubersieht. Wird zum Beispiel ein Hemd mit Kra-gen beschrieben, w¨urde ein unwissender Benutzer eventuell den Stehkragen ausw¨ahlen, statt den pr¨aziseren Ausdruck ”Kollar” oder ”Vaterm¨order”. Aus
diesem Grund wurde ein TreeSelector entwickelt, in welchem die Taxonomien baumartig dargestellt werden und der Benutzer durch Anklicken die einzel-nen Unterb¨aume ¨offnen, an- oder abw¨ahlen kann.
4 L¨ osungen der Taxonomieprobleme
Hier werden L¨osungskonzepte zur Speicherung der Taxonomien und der ver-besserten Auswahl und Selektierung vorgestellt.
4.1 Konzept des MuSE-Tool-Taxonomy-Parsers
Der MuSE-Tool-Taxonomy-Parser arbeitet in mehreren Schritten. Zun¨achst wird die Freemind-Datei mithilfe einer ”Sax-Builder”-Bibliothek eingelesen.
Anschließend werden die Daten nach den gew¨unschten Informationen gefiltert und schließlich als MySql-Script in einer Datei oder in der Zwischenablage ausgegeben.
4.1.1 Benutzung des Parsers
Der Benutzer gibt in einer Eingabemaske die Quelldatei, den Tabellen-, Element- und ¨Uberelementname an, sowie die Ausgabedatei. Sollte die Aus-gabe in die Zwischenablage des Betriebssystems erfolgen, ist die letzte Ein-gabe nicht notwendig. Alle anderen Felder m¨ussen ausgef¨ullt werden, da das Programm sonst entweder die Eingabedatei nicht findet oder das MySql-Script unvollst¨andig wird. Anschließend wird der Parser mit Knopfdruck ge-startet.
4.1.2 Aufbereitung der Daten
Die eingelesenen Daten des Freemind-Tools m¨ussen erst bereinigt werden.
Dies bedeutet, dass unn¨otige Daten entfernt, sowie die restlichen in ein ein-heitliches Format gebracht werden, damit anschließend die eigentliche Kon-vertierung stattfinden kann. Der Parser verarbeitet das XML-Dokument li-near und pr¨uft die XML-Struktur sowie die Speicherung der Daten. Dabei wird ein Listenbaum mit den Elementen erstellt.
Im folgenden Listing bezeichnet Vater den Wurzelknoten, Kind das Blatt.
Listing 1: XMLReader.java 1 MyNode XMLRekursion ( Node node ) {
2 s w i t c h ( node . getNodeName ( ) ) { 8 MyNode KindNode = XMLRekursion ( Kind )
9 i f ( Kind != n u l l ) Vater . addKind = KindNode ;
Der Parser verarbeitet den erstellten Listenbaum rekursiv und erstellt da-bei die SQL-Scripte. Im folgenden Codeabschnitt wird der rekursive Abstieg abstrakt dargestellt.
Listing 2: SQLParser.java 1 BaumRekursion ( Vater ) {
2 f o r ( Kinder von Vater ) {
3 e r s t e l l e S Q L S c r i p t ( Vater . Text , Kind . Text ) ; 4 BaumRekursion ( Kind ) ;
5 }
6 }
4.1.4 Abbildung in der Datenbank
Es wurden verschiedene M¨oglichkeiten in Erw¨agung gezogen die Baumstruk-tur in der Datenbank relational abzubilden.
Bei dem ”Nested Sets” Prinzip behilft sich das Modell mit einem einfachen System: Jedes Element des Baumes erh¨alt zwei Werte - einen linken und einen rechten - , die fortlaufend durch die gesamte Struktur bei jedem Schritt um eins erh¨oht werden. Zur Veranschaulichung kann man sich einen Wurm
vorstellen, der - an der Wurzel beginnend - den gesamten Baum durchwan-dert. Der Wurm hinterl¨asst bei jedem Knoten, den er besucht, eine Nummer und erh¨oht anschließend seinen Z¨ahler um eins. Dabei wird zun¨achst im-mer erst der linke Wert gesetzt. Gelangt der Wurm an das Ende eines Astes (Blatt), springt der Wurm von der linken auf die rechte Seite und wandert von dort weiter zur linken Seite des n¨achsten Knotens. Folgen keine weiteren Bl¨atter oder ¨Aste, geht er wieder zur¨uck zum letzten ¨ubergeordneten Kno-ten, bis er schließlich wieder an der Wurzel des Baumes ankommt (vgl. [Kle]).
Das Problem hierbei liegt jedoch in der fehlenden Flexibilit¨at des Baumes.
W¨ahrend das ¨Andern eines Blattes kein Problem darstellt, gestaltet sich das Hinzuf¨ugen oder Entfernen als eine aufw¨andige Prozedur. Wird ein Knoten hinzugef¨ugt, oder gel¨oscht, m¨ussen alle nachfolgenden Knoten angepasst wer-den, da ihre Werte nicht mehr korrekt sind.
Eine weitere M¨oglichkeit w¨are den Baum mithilfe von 2-Wertepaaren zu spei-chern. Dabei wird jeder Eintrag einzeln und jede Beziehung als Vater-Kind-Tupel gespeichert. Allerdings ist hier mit großer Redundanz zu rechnen, da die meisten Eintr¨age mehrfach vorkommen, sowohl als Knoten und in der Vater-Kind-Beziehung.
Die Redundanz kann jedoch einfach verringert werden, indem anstatt Vater-Kind-Beziehungen zu jedem Kind der Vater gespeichert wird. So fallen Ein-tr¨age f¨ur Werte und f¨ur die Beziehungen zusammen und der Speicheraufwand verringert sich um ca. 30% im Vergleich zu den Vater-Kind-Beziehungen.