Bachelor-Arbeit Lichtenstern
Werbung
Technische Universität München Fakultät für Informatik Lehrstuhl für Datenbanksysteme Bachelor-Arbeit Konzeption und Implementierung von Diensten zur Ontologiebereitstellung in Ad-Hoc-Netzen Aufgabenstellerin: Prof. Dr. Birgitta König-Ries Betreuerin: Prof. Dr. Birgitta König-Ries Bearbeiter: Manfred Lichtenstern E-Mail: [email protected] Eingereicht am: Bachelor-Arbeit Lichtenstern 15.10.2004 Seite 1 von 44 Ich versichere, dass ich diese Bachelor-Arbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, 15.10.2004 ………………………………………………. Manfred Lichtenstern Bachelor-Arbeit Lichtenstern Seite 2 von 44 Inhaltsverzeichnis………………………………………………….. 3 1 Einleitung…………………...……………………………………………….... 4 1.1 Projektumfeld...…………………………………………………………… 1.2 Aufgabenstellung……………….…………………………….…………... 4 5 2 Grundlagen…………………..………………………………………………. 6 2.1 Ontologien………………………………………………………………… 2.2 Parser- und Lexer-Werkzeug ANTLR…………………………………..... 2.3 Der Zeichensatz Unicode…………..…….……………………………….. 6 7 11 3 Konzeption…………………..………………………………………………. 3.1 Ontologieschichtung……………………………………………………… 3.2 Arten der Repräsentation….……………………………………………… 3.2.1 G-DSD…………………………………..……………………………. 3.2.2 F-DSD…..……………………………………………………………. 3.3 Ablauf der Verarbeitung…………………………………………………… 12 12 14 17 19 28 4 Implementierung……………………………………………………………. 30 4.1 Datenbankschema………………………………………………………… 4.2 Aufteilung von Dateien mit mehreren Klassen und Instanzen…………… 4.2.1 Rahmenbedingung durch die Grammatik……………………………. 4.2.2 Einfacher Algorithmus… ……………………………………………. 4.2.3 Gewählter Algorithmus………………………….…………………… 30 32 32 33 34 5 Zusammenfassung…………………………………………………………… 35 A Anhang………………………………………………………………………. A.1 Grammatik (F-DSD)...…………………………………………………… A.2 FileIterator……………………………………………………………….. 36 36 42 Quellenverzeichnis…………………………………………………………….. 43 Bachelor-Arbeit Lichtenstern Seite 3 von 44 1 Einleitung Zuerst soll das Projektumfeld kurz beleuchtet werden, bevor dann näher auf Aufgabenstellung eingegangen wird. die 1.1 Projektumfeld Diese Bachelor-Arbeit wurde im Rahmen des Projekts Dienste in Ad-Hoc-Netzen [DIANE] angefertigt. Ein guter Startpunkt um das Projekt kennen zulernen ist die Hompage des Projekts unter http://www.ipd.uka.de/DIANE/de Unter anderem wird auf den Seiten des Projekts folgendes über Aufgaben und Ziele geschrieben: „Ziel von DIANE die Entwicklung und Evaluierung von Konzepten zur integrierten, effizienten und effektiven Nutzung der in einem Ad-hoc-Netz in Form von Diensten bereitgestellten Ressourcen. Von besonderem Interesse sind Informationsdienste, Dienste also, die den möglichst integrierten Zugriff auf digital verfügbare Information ermöglichen. Hierzu schlagen wir Mechanismen zur Dienstbeschreibung, zum Auffinden und zur Auswahl von Diensten sowie zur effizienten Abarbeitung von Anfragen vor. Die entwickelten Konzepte sollen in einem Ad-hoc-Netz für Karlsruher Informatikstudenten zur Prüfungsvorbereitung im Fach Informationssysteme evaluiert werden.“ Zur Notwendigkeit von Ontologie steht dazu folgendes: „Die Beschreibung von Diensten muss ausdrucksstark und gleichzeitig automatisch vergleichbar sein. Vor dem Hintergrund dieses Zielkonfliktes erscheinen ontologiebasierte Beschreibungssprachen wie DAML-S am geeignetsten. Für die Beschreibung von Diensten setzen wir eine geschichtete Dienstontologie ein.“ Im Rahmen des Projekts Diane wurde in der Dreier-Studienarbeit [3sa] „Schaffung einer formalen Grundlage für Dienstbeschreibung in DIANE und Entwicklung von geeigneten Werkzeugen und Beispielen“ die Grundlagen für die Grammatik [A.1] zur Beschreibung der „Formalen Diane Service Description“ (F-DSD) geschaffen. Nach Abschluss der Dreier-Studienarbeit im Juni 2004 wurde die Arbeit an der F-DSD Grammatik von Michael Klein (unter den Namen „xdiane3sa“ ) fortgeführt und dazu der Interne Bericht „Handbuch zur DIANE Service Description“ [DSD] entwickelt, der voraussichtlich bis Ende 2004 erscheint. Während dieser Bachelorarbeit wurde die Studienarbeit „Aktive VISIO-Schablonen zur grafischen Erstellung von DIANE-Dienstbeschreibungen“ von Thomas Herzog angefertigt. Die so genannte G-DSD (für Grafische Diane Service Description) kann damit automatisch in die F-DSD umgewandelt werden. Bachelor-Arbeit Lichtenstern Seite 4 von 44 1.2 Aufgabenstellung Die Dienste zur Ontologiebereitstellung sind zuständig • • • • für das Ablegen von Ontologieschemas für das Ablegen von Ontologieinstanzen für den Zugriff auf Ontologien für Änderungen von Ontologien (Ontologien ergänzen und ändern) Am Anfang der Erstellung der geschichteten Ontologien wurden zur Realisierung der Ontologien nur Java-Dateien manuell erstellt. Diese werden in der Spitze der Ontologiepyramide teilweise immer noch nur manuell erstellt. Da die Ontologiepyramide aber sehr rasch nach unten in der Anzahl der benötigten Definition anwächst, musste dieser Erstellungsprozess unterstützt werden. Dazu wurde die „Formale Diane Service Description“-Sprache (F-DSD) geschaffen. Die F-DSD wird dann mit einem Transformator in J-DSD, also Java-Dateien, die die Ontologie beschreiben, übersetzt. Da im DIANE Projekt CVS zur Versionsverwaltung eingesetzt wird, wurden die ersten Java-Dateien zur Ontologiebeschreibung im Verzeichnis „simulator/src/dsd“ abgelegt. Später, als dann die F-DSD-Dateien hinzugekommen sind, wurde dann ein Verzeichnis „simulator/src/f-dsd“ hinzugefügt. Die Ablage von Ontologieschemas und –instanzen erfolgt also einfach in einem Dateisystem. Die Änderungen werden mit Hilfe des CVSSystems [CVS] auf die einzelnen Rechner des Projekts verteilt. Alle Ontologien liegen also auf allen Rechnern, auf denen die DIANE-Software läuft. Diese Verfahren kann im Verlauf der Softwareentwicklung sehr Vorteilhaft eingesetzt werden, da der Umfang der Erstellten Ontologien sehr klein ist. Aber später bei großen Ontologien wird es nötig sein, ein fortgeschrittenes Ablage- und Zugriffssystem zu verwenden. Im Rahmen dieser Bachelor-Arbeit wurde ein Konzept erarbeitet, und die Basis für dieses Konzept implemntiert, um bei großen und sehr großen Ontologien ein Ablage- und Zugriffssystem zu realisieren, das auch bei der typischer Weise eingesetzten Hardware, einen problemlosen Betrieb ermöglicht. Als Ablage- und Zugriffssystem bietet sich hier sofort ein Datenbanksystem an. In diesem speziellen Anwendung muss aber besonders darauf geachtet werden, das die Lösung auf einen dezentralen und unter umständen verteilten System, auf nicht besonders leistungsfähiger Hardware lauffähig ist. Bachelor-Arbeit Lichtenstern Seite 5 von 44 2 Grundlagen In diesem Kapitel wird auf einige Grundlagen eingegangen, auf die in anderen Kapiteln aufgebaut wird. 2.1 Ontologien Die Dreier-Studienarbeit [3sa] hat auch hier schon einige wichtige Grundlagen wie folgt beschrieben: „Ein wichtiges Konzept der Arbeit sind Ontologien. Ursprünglich stammt der Begriff Ontologie aus dem Bereich der künstlichen Intelligenz. Er wird dafür verwendet, um ein Modell unserer realen Welt zu beschreiben und zu veranschaulichen. Ontologien beinhalten also semantische Informationen über Elemente dieses Weltausschnittes.“ In der Dreier-Studienarbeit [3sa] kann man auch folgendes nachlesen: „Im DIANE Projekt haben sich ontologiebasierte Dienstbeschreibungen als ein geeignetes Mittel zur Beschreibung von Diensten erwiesen. Sie ermöglichen ein hohes Maß an Flexibilität, ohne dabei die Ausdrucksstärke oder die Vergleichbarkeit einzuschränken.“ Im Abschnitt „Eigenschaften einer eigenen Sprache“ wird die Sprache des Projekts DIANE von der Dreier-Studienarbeit [3sa] wie folgt beschrieben: - Rechnerverständliche funktionale Semantik Ein Rechner soll ohne jegliche Sekundärinformation, d.h. allein aus der mit dieser Sprache erstellten Dienstbeschreibung verstehen, was dieser Dienst tut. - Universale Einsetzbarkeit Die Sprache soll also in der Lage sein, alle möglichen Dienste aus allen - Menschenerstellbarkeit Die Dienstbeschreibung muss in einer vertretbaren Zeit durch einen Menschen erstellbar sein. Diese Aussagen fassen den Kern der Motivation für Ontologien im DIANE Projekt zusammen. Bei der Dreier-Studienarbeit [3sa] kann man mehr zu den theoretischen Grundlagen von Ontologien nachlesen. Wie sich bei dieser Bachelor-Arbeit aber gezeigt hat, ist der schnellste und einfachste Weg sich in Ontologien einzuarbeiten, der Weg an hand von konkreten Beispielen. Dadurch werden auch schnell die Schwächen und Stärken der eingesetzten Methoden klar. Deshalb wird im Kapitel Konzeption näher das Kinobeispiel vorgestellt. Bachelor-Arbeit Lichtenstern Seite 6 von 44 2.2 Parser- und Lexer-Werkzeug ANTLR ANTLR [ANTLR] steht für ANother Tool for Language Recognition und ist ein Parserund Lexer-Werkzeug. Dieses Werkzeug bildet seit der Dreier-Studienarbeit [3sa] die Basis für die Verarbeitung der F-DSD. In der Dreier-Studienarbeit [3sa] wird sehr zutreffend wie folgt beschrieben: „ANTLR ist jedoch mehr als nur eine Sprache zur Grammatikdefinition: Die einzelnen unterstützten Tools ermöglichen es, automatisch aus der ANTLRGrammatik einen Lexer, Parser und Tree Parser in entweder Java, C++ oder Sather zu generieren. In dieser Arbeit war nur die Generierung in Java von Bedeutung.“ Folgende Erkärung von [3sa] zeigt warum man sich für dieses Werkzeug entschieden hat: „Neben ANTLR existieren noch andere Werkzeuge die aus einer angegebenen Grammatik den Quellcode für einen Lexer und Parser generieren. Das bekannteste Gespann hierfür sind Lex (ein Lexergenerator) und Yacc. Lex ist dabei wie der Name schon nahe legt für das Aufteilen der Quell – Datei in einzelne Tokens zuständig. YACC, was für Yet Another Compiler – Compiler steht, ist der dazugehörige Parsergenerator. Der größte Unterschied zwischen diesen und ANTLR besteht darin, das ANTLR ein LL(k)-Compiler-Compiler, Lex / Yacc nur LL(1) Compiler-Compiler sind, was bei Lex / Yacc zu relativ komplexen Grammatiken führt.“ In der [3sa]-Arbeit werden auch die folgenden Grundlagen aus dem Compilerbau beschrieben: „Im Compilerbau unterscheidet man zwischen mehreren Phasen, die bei der Umsetzung der jeweiligen Programmiersprache in eine für die Maschine, also für den Computer brauchbare Form, durchlaufen werden. Diese Phasen führen verschiedene Analysen und Operationen mit dem eingegebenen Code durch. Im Einzelnen sind dies: 1. Lexikalische Analyse (Scanning) Bei der Lexikalischen Analyse wird der Quellcode, also der Eingabestrom, in einzelne Symbole (Tokens) zerlegt. Dabei unterscheidet der Lexer (oder auch Scanner und Tokenizer genannt) zwischen den durch den Sprachsyntax vorgegebenen Symbolen, Variablen und Operatoren. 2. Syntaktische Analyse (Parsing) Der in diesem Stadium verwendete Programmteil wird Parser genannt und Bachelor-Arbeit Lichtenstern Seite 7 von 44 liest den vom Lexer in einzelne Token zerteilten Strom ein, prüft diese auf syntaktische Richtigkeit und erstellt daraus Symbol-Gruppen mit hierarchischer Struktur. Die Struktur ist oft ein Baum und wird dann Parse-tree genannt. 3. Semantische Analyse Die auf die Syntaktische Analyse folgende prüft nun die semantische Korrektheit des Programms. Dazu gehören die Prüfung auf korrekte Typisierung, die Einhaltung von Gültigkeitsbereichen und eventuelle Typanpassungen. 4. Erzeugung von Zwischencode 5. Codegenerierung (ggf. Optimierung) Die Schritte 4 und 5 weden nur bei Programmiersprachen benötigt. Als Grundlage für diese Arbeit sind hauptsächlich der Lexer, der Parser, der Tree Walker und deren Umsetzung mit Hilfe von ANTLR in Java von Bedeutung. Es soll deshalb im Anschluss noch etwas genauer auf die Grammatik von ANTLR als auch die Erstellung des Lexers und des Parsers eingegangen werden.“ Zur „Grammatik von ANTLR“ wird von [3sa] folgendes geschrieben: „Für die Erstellung von Lexern und Parsern muss eine Grammatik-Datei erstellt werden, welche die zu implementierende Sprache spezifiziert. Dabei müssen die für ANTLR geltenden Regeln beachtet werden. Im konkreten Beispiel sieht das für ANTLR folgendermaßen aus: Die Umsetzung des Zeichenstroms in Tokens wird im Lexer durchgeführt. Die Regeln hierzu werden in folgender Form notiert. Dabei ist zu beachten, dass die Bezeichner der einzelnen Tokens immer mit einem Großbuchstaben beginnen müssen. TOKENBEZEICHNER : Zeichen; Es können sowohl ein als auch mehrere Zeichen zu einem Token aufgelöst werden. Zur Notation einer Zeichenmenge bestehen mehrere Möglichkeiten. Die wichtigsten sollen hier aufgeführt werden: 1. Einzelne Zeichen: KLEINBUCHSTABEN_ABC : 'a' 'b' 'c' ; 2. Zeichenfolge: KLEINBUCHSTABEN_ABC : "abc“; 3. Zeichenspanne: EINE_ZIFFER_ZWISCHEN_1_UND_7 : '1'..'7'; Bachelor-Arbeit Lichtenstern Seite 8 von 44 Außerdem lassen sich einzelne Zeichenmengen folgendermaßen zu neuen Mengen verknüpfen: (Menge1|Menge2|Menge3) Menge1 oder Menge2 oder Menge3 (Menge) ? Menge einmal oder keinmal (Menge) + Menge einmal oder öfter (Menge) * Menge beliebig oft Bei der Aufstellung der Regeln ist darauf zu achten, dass der Zeichenstrom eindeutig in Tokens zerlegt werden kann. Das heißt es darf keine zwei Tokenregeln geben mit gleichen Teilmengen auf der der rechten Seite. Zum Beispiel: TOKEN1 : "abc"; TOKEN2 : ( 'a' .. 'z' )*; TOKEN2 gilt für alle Wörter aus Kleinbuchstaben. Damit würde die Zeichenfolge „abc“ auf beide Regeln zutreffen und es wäre keine eindeutige Umwandlung des Zeichenstroms in Tokens möglich. Zur Auflösung eines solchen Problems gibt es drei Möglichkeiten, die hier aber nur angesprochen und nicht ausführlich dargestellt werden sollen. Zum einen kann man den so genannten „lookahead“ vergrößern. Dadurch werden mehrere Zeichen eingelesen, bevor entschieden wird welches Token zutrifft. Ein weiteres Hilfsmittel sind die „Semantic Predicates“. Und als letzte Möglichkeit lassen sich noch Literale festlegen, welche als ein Zeichen betrachtet werden und somit Vorrang haben. Damit lassen sich zum Beispiel Schlüsselwörter von Bezeichnern unterscheiden. Nachdem der Zeichenstrom in einen Tokenstrom umgewandelt wurde, wird dieser vom Parser weiterverarbeitet. Die Parserregeln haben eine ähnliche Form wie die Regeln des Lexer, wobei die Bezeichner der Regeln mit einem Kleinbuchstaben beginnen müssen. Auf der rechten Seite können sowohl Tokens als auch weitere Parserregeln vorkommen. Ein Beispiel hierfür könnte folgendermaßen aussehen: expr: (expr PLUS expr) | ziffern; ziffern: (ZIFFER)*; Besonders hervorzuheben ist noch die Angabe der bereits erwähnten Literale. Sie werden durch Hochkommata gekennzeichnet und vor den Tokens aufgelöst. vererbung: BEZEICHNER "extends" BEZEICHNER ; Die Funktion des Parsers ergibt sich aus dem Einfügen von Javacode an der gewünschten Stelle. Der Code muss in geschweifte Klammern gefasst sein und wird ausgeführt, sobald (falls) der Parser an die entsprechende Stelle gelangt. Javacode, der vor dem Doppelpunkt steht, wird sozusagen initial vor der Abarbeitung der rechten Seite ausgeführt und gilt somit auch für alle Alternativen auf der rechten Seite. Zum Informationsaustausch Bachelor-Arbeit Lichtenstern Seite 9 von 44 zwischen einzelnen Regeln lassen sich Objekte übergeben und zurückgeben. Das sieht folgendermaßen aus: regel1 [Object in1, Object in2] returns [Object out] {Javacode optional} : out = regel2[in1]; regel2 [Object in] returns [Object out] {out=null} : LEERZEICHEN {out=in}; In diesem Beispiel wird ein Object von Regel 1 an Regel 2 weitergereicht, könnte hier verändert werden und dann nach dem Einlesen eines Leerzeichens wieder an Regel 1 zurückgegeben werden. Bei Verwendung eines Treewalkers wird vom Parser zusätzlich ein AST erzeugt. In diesem Fall wird der auszuführende Javacode in den Treewalker geschrieben. Zum Erzeugen von ASTs wird die Syntax des Parsers erweitert. TOKEN^ Dieses TOKEN wird zur Wurzel des erzeugten AST. TOKEN! Dieses TOKEN wird nicht in den AST aufgenommen. Die Notation des Treewalkerregeln entspricht denen im Parser. Zusätzlich muss jedoch der AST syntaktisch beachtet werden. Ein AST wird durch eine Raute gekennzeichnet. Nach der Raute kommen, in Klammern gefasst, zuerst die Wurzel und dann die Kinder. Ohne Raute wird ein Token im Treewalker als einelementiger AST betrachtet. regel : #(TOKEN1, regel2,regel3,TOKEN3) ; regel2 : TOKEN3 ; regel3 : TOKEN4 TOKEN5 TOKEN6 ; Zuerst ist die Erzeugung eines Treewalkers ein Mehraufwand, der keine zusätzliche Funktion erfüllt. Allerdings ergibt sich ein Vorteil, wie schon erwähnt, aus der Wiederverwendbarkeit des Parsers. Wenn die zugrunde liegende Grammatik und somit die Sprache gleich bleibt, aber daraus neuer Code zum Beispiel für eine weitere Zielsprache erzeugt werden soll, muss nur der Treewalker neu erstellt werden. In unserem Fall sollten zukünftig weitere Zielsprachen erzeugt werden, daher haben wir uns für die Verwendung des Treewalkers entschieden.“ Der Treewalker wurde nur kurz bis nach Abschluss der Dreier-Studienarbeit im Juni 2004 verwendet. Seit dem die Arbeit an der F-DSD Grammatik von Michael Klein (unter den Namen „xdiane3sa“) fortgeführt wird, wurde entschieden, dass der Treewalker doch nur einen Mehraufwand darstellt und deshalb wird er seitdem nicht mehr verwendet. Bachelor-Arbeit Lichtenstern Seite 10 von 44 2.3 Der Zeichensatz Unicode Auf der Home Page von Unicode [UNICODE] steht unter anderem: “What is Unicode? Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language.” Auch eine gute Quelle zu diesen Thema ist die „UTF-8 and Unicode FAQ for Unix/Linux“ [UTF-8] von Markus Kuhn. Hier kann man unter anderem folgendes lesen: “With the UTF-8 encoding, Unicode can be used in a convenient and backwards compatible way in environments that, like Unix, were designed entirely around ASCII. UTF-8 is the way in which Unicode is used under Unix, Linux, and similar systems. It is now time to make sure that you are well familiar with it and that your software supports UTF-8 smoothly.“ Wie also aus diesen Quellen hervorgeht ist der Unicode der neue Zeichensatz, der das leisten soll, was er ASCII-Zeichensatz schon bei den Standardzeichen erreicht hat, nämlich eine weltweite Standarisierung des Zeichensatzes, aber für wirklich alle Zeichen der Welt. Aber wenn man sich auf den Unicode festgelegt hat, ist erst klar welche Zahl jedem Zeichen zugeordnet wird. Es gibt aber immer noch einige Möglichkeiten der Codierung. Das hat seinen Grund darin, has man versucht beim Übergang von ASCII- oder einen erweiterten ASCII-Zeichensatz möglichst wenige Probleme zu verursachen. Leider werden aber doch einige Probleme verursacht. Das fängt häufig schon bei der Frage der Codierung an. Soll man die UCS-2 oder die UCS-4 Codierung verwenden, die für jedes Zeichen 2 oder 4 Bytes belegt werden? Die meisten Vorteile und die wenigsten Problem werden sich wahrscheinlich mit der üblichen UTF-8 Codierung ergeben. Sie hierzu auch RFC3639 (z.B.http://www.ietf.org/rfc/rfc3629.txt) Aus diesem Grund wurde als Zeichensatz für F-DSD-Dateien Unicode in der UTF-8Codierung gewählt. Wie sich während der Arbeit gezeigt hat, verwenden die meisten Windows- und UnixBenutzer noch nicht den Unicode in UTF-8-Codierung. Bei Text-Editoren wie z.B. JEdit [JEDIT] kann aber auf allen Betriebssystemen problemlos Unicode in der UTF-8Codierung gewählt werden. Bei vielen Programmen und Betriebssystemen wird die Unterstützung für Unicode immer besser, auch in der UTF-8-Codierung. Bachelor-Arbeit Lichtenstern Seite 11 von 44 3 Konzeption Zuerst soll das Konzept der Ontologieschichtung dargestellt werden. Anschließend die verschiedenen Arten der Ontologierepräsentation und Ontologieverarbeitung. 3.1 Ontologieschichtung Im „DSD-Cookbook“ [DSD] wird die folgende „Ontologie-Pyramide“ vorgestellt: S Æ class X, instance y, … Service State1 InfoState State2 InfoState Document Printed Location Address myService Building geb50.34 Room room335 Bachelor-Arbeit Lichtenstern Ontologiebeschreibungssprache (=Metaschema) Sprache zur Definition von Ontologien Æ „DIANE Elements“ I. obere Dienstontologie (=Schema) Aufgabe: allgemeine Struktur einer zustandsbasierten Dienstbeschreibung einheitlich, klein II. Kategorienontologien (=Schemata) wenige Einschränkung der möglichen Vor- und Nachzustände Beispiel: InformationService III. Domänenontologien (= Schemata) zur Beschreibung einzelner Domänen viele, verteilt Beispiele: Room, Paper, Printer Instanzpool (= Instanzen) stehen für Individuen der realen Welt sehr viele, verteilt Seite 12 von 44 Nach dem „DSD-Cookbook“ [DSD] haben die einzelnen Schichten die folgenden Eigenschaften: - Obere Dienstontologie. Diese definiert das Schema für das allgemeine Grundgerüst von zustandsbasierten Dienstbeschreibungen. Hier ist verankert, dass ein Dienst durch die Angabe eines Vor- und eines Nachzustands zu spezifizieren ist und weitere, nichtfunktionale Informationen (wie der Dienstname, der Anbieter, Dienstqualitäten, der technische Zugangsweg etc.) angegeben werden können. Das Schema ist sehr klein und wird einheitlich von DSD für alle Teilnehmer vorgegeben. - Kategorieontologien. Aufgabe dieser Ontologien ist es, den Raum aller möglichen Dienste in Kategorien mit ähnlichen Zustandsübergängen zu unterteilen. Hierzu gibt jede dieser Ontologien im Wesentlichen Einschränkungen an die zu verwendeten Zustände vor. Mögliche Kategorien könnten Informationsdienste sein, die den Zustand eines Dokuments ändern, oder Wissensdienste, die den Zustand von Wissen ändern, oder Realweltdienste, welche den Besitzzustand realweltlicher Gegenstände ändern. Insgesamt sind nur wenige Kategorien zu erwarten, von denen die wichtigsten bereits durch DSD vorgegeben sind. In Absprache mit der Community kann jedoch jeder Benutzer selbst weitere Kategorieschemata erstellen. - Domänenontologien. Diese Ontologien dienen dazu, die unterschiedlichen Anwendungsgebiete zu formalisieren, in welchen die zu beschreibenden Dienste operieren. Hier sind tausende verschiedener Ontologien zu erwarten, die nicht durch DSD vorgegeben werden, sondern von der Community selbst eingebracht werden können. Wichtig ist, dass neben der Definition von Schemata auch Instanzen als Stellvertreter für reale Individuen definiert werden sollten, um eine Domäne vollständig zu beschreiben. Im „DSD-Cookbook“ [DSD] wird auch folgendes Festgestellt: „Insgesamt erreicht man durch diese Dreiteilung der Schemabeschreibung einerseits strukturierte, zustandsorientierte Dienstbeschreibungen, andererseits verliert man durch die Austauschbarkeit der Ontologien nicht die Flexibilität einer gänzlich freien Dienstbeschreibungssprache.“ Bachelor-Arbeit Lichtenstern Seite 13 von 44 3.2 Arten der Repräsentation Aus dem DSD-Handbuch [DSD] ist folgende Einführung in die verschiedenen Formen der Repräsentationsformen: „Für die DSD gibt es nicht die Syntax sondern es existieren mehrere Repräsentationsformen, die jeweils unterschiedliche Vor- und Nachteile bieten und daher in verschiedenen Situationen zum Einsatz kommen.“ Die Abbildung zeigt den Zusammenhang: Bachelor-Arbeit Lichtenstern Seite 14 von 44 Im Handbuch [DSD] werden die verschiedenen Formen wie folgt beschrieben: - Im Mittelpunkt steht die formale Hauptrepräsentation (kurz f-dsd). In Ihr sind die DSD Elements durch eine formale Grammatik definiert, deren Ziel es ist, möglichst kompakte und gut lesbare Beschreibungen zu erhalten. Da die Beschreibungen rein textbasiert sind, können sie leicht im System ausgetauscht werden. Als Hauptrepräsentation strebt die f-dsd nach Vollständigkeit, d.h. in ihr sind in der Regel alle Konzepte und Beschreibunsmöglichkeiten der DSD enthalten und ausdrückbar. Die Syntax der f-dsd hat Anleihen an objektorientierten Programmiersprachen und übernimmt die Darstellung primitiver Werte aus XML Schema. Um eine übersichtliche Darstellung zu erhalten wurde auf Verwendung von XML verzichtet. - Eine anschauliche Darstellung liefert die graphische Nebenrepräsentation (kurz g-dsd). Sie wurde als visuelle Sprache konzipiert, so dass sich menschliche Benutzer in ihr schnell zurecht finden, um so vorhandene Beschreibungen gut verstehen und neue Beschreibungen effizient aufbauen zu können. Weiterhin eignet sich diese Repräsentationsform dazu, Beschreibunden in Vorträgen und Papieren anschaulich präsentieren zu können. Editiert werden g-dsdBeschreibungen mit dem Mircrosoft-Programm VISO, welches durch intelligente Schablonen einem menschlichen Benutzer aktiv bei der Erstellung von Beschreibungen behilflich ist. [G-DSD]. Ein in VISO integrierter Transformator kann eine Beschreibung in g-dsd in f-dsd umwandeln. Die g-dsd ähnelt in ihrem Grundaufbau UML Klassen- und Instanzdiagrammen, wurde jedoch um spezielle Konzepte erweitert. - Um die formale Repräsentation verarbeiten zu können, wird sie zunächst von einem speziellen Parser [ANTLR] eingelesen und als temporäre Repräsentation (kurz t-dsd) nicht-persistent im Hauptspeicher abgelegt. Diese neutrale Zwischenstufe ist im Wesentlichen darauf ausgelegt, in eine der weiteren Nebenrepräsentation persistent ausgegeben zu werden. Auch eigene Spezialrepräsentationen können hieraus leicht abgeleitet werden. - Eine wichtige Repräsentierung ist die Java-basierte Nebenrepräsentation (kurz j-dsd). In ihr wird das Schema zu einem Satz von Java-Klassen, welche durch ihren Quellcode dargestellt sind. Instanzen hingegen sind gewöhnliche JavaObjekte, die durch statische Erzeugungsklassen persistent gemacht werden. Besondere Konstrukte der DSD (wie z.B. Mengen oder Variablen) werden durch spezielle Klassen und Tricks umgesetzt. Diese Darstellungsform hat eine Reihe von Vorteilen: Zunächst können durch Kompilierung des Quellcodes automatisch semantische Fehler entdeckt werden, deren Überprüfung in f-dsd komplexe Zusatzprogramme erfordert hätte. Weiterhin können die übersetzten Klassen direkt in allen Java-Programmen verwendet werden. Dies ist wichtig, da im DIANE-Projekt zur Zeit alle Komponenten, die auf Dienstbeschreibungen angewiesen sind, in dieser Programmiersprache vorliegen. Drittens ist es möglich, Bachelor-Arbeit Lichtenstern Seite 15 von 44 dan bestimmte ontologische Klassen Programmlogik anzuhängen, um somit immer wiederkehrende Verarbeitungsweisen festzuhalten. Beispielsweise hat die Javaklasse zu Umsetzung einer Menge bereits eine Methode, die testet, ob eine bestimmte Instanz zu dieser Menge gehört oder nicht. Aus diesem Grund verarbeitet der Vergleicher Beschreibungen in dieser Darstellung. - Zum Austausch mit anderen Forschungsgruppen eignet sich die OWL-basierte Nebenrepräsentation (kurz o-dsd). Diese stellt alle Konzepte der DSD mit den Mitteln der standardisierten, XML-basierten Web Ontology Language dar. - Neben den vorhandenen Darstellungsformen können auch individuelle Repräsentationen interessant sein. Diese sind häufig verkürzend, d.h. sie stellen nur die Aspekte einer Beschreibung dar, die für den jeweiligen Anwendungszweck von Bedeutung sind und blenden unwichtige Teile aus. Hier sind sowohl persistente als auch nicht-persistente Repräsentierungen denkbar. Zur Ablage in der Datenbank wird in diesem Sinne eine individuelle Repräsentation verwendet (kurz DB-DSD). Das besondere an dieser Repräsentation ist, es sind alle Möglichkeiten vorhanden, die auch die F-DSD bietet und zusätzlich sind noch weitere Information vorhanden, z.B. aus welcher G-DSD die F-DSD erzeugt wurde. Diese Information wird, wie im folgenden Beispiel gezeigt wird, von der G-DSD in die F-DSD eingebracht. //** @G-DSD: /schema/domain.cinema.VSD Klassen {ontology: domain.cinema} Wie man an diesem Beispiel sieht wird ein Kommentar, dem direkt zwei Sterne folgen dazu verwendet, um spezielle Informationen in die F-DSD zu schreiben, die in die DBDSD aufgenommen werden sollen, aber nicht von der Grammatik der F-DSD vorgesehen sind. In diesem Beispiel mit durch das nächsten Token „@G-DSD:“ mitgeteilt, dass in diesem Fall die Information folgt, aus welcher VISO - Datei die F-DSD erzeugt wurde und auf der Name des Arbeitsblattes auf dem die Ontologie steht. Bachelor-Arbeit Lichtenstern Seite 16 von 44 3.2.1 G-DSD Hier wird nun mit der G-DSD das Kinobeispiel vorgestellt. Dieses Beispiel ist etwas größer. Aber der Aufwand zur Einarbeitung in dieses Beispiel rentiert sich auf alle Fälle. {ONTOLOGY: domain.cinema} String name domain.location AddressV Integer address number CinemaPE within HallPE SoundSystemPE domain.movie MoviePE sound within letter String RowE CategoryPE visible category within startTime Integer number SeatE seat Time SeatInShowE date Date free validFor Boolean domain.money CinemaTicketV price currency CurrencyPE amount Double domain.money PriceV definitional property category.realobjectservice TicketE incidental property orthogonal property (is not published) Bachelor-Arbeit Lichtenstern defined in another ontology Seite 17 von 44 ONTOLOGY: domain.movie title MovieEP String genre GenreEP duration Duration country domain.location language mainActor CountryEP domain.location LanguageEP director domain.person PersonEP domain.person PersonEP Bachelor-Arbeit Lichtenstern Seite 18 von 44 3.2.2 F-DSD Das Kinobeispiel wird durch die folgenden F-DSD-Dateien beschrieben: //** @G-DSD: /schema/category.realobjectservice.VSD Klassen {ontology: category.realobjectservice} valueclass RealObjectState extends State at upper.profile [] valueclass Owned extends RealObjectState [ entity: Thing, location : Location at domain.location, begins : DateTime, ends : DateTime ] Bachelor-Arbeit Lichtenstern Seite 19 von 44 //** @G-DSD: /schema/domain.cinema.VSD Klassen {ontology: domain.cinema} valueclass CinemaTicket [ price : Price at domain.money, validFor : SeatInShow, number : Integer ] entityclass SeatInShow [ defprop date : Date, defprop startTime : Time, defprop seat : Seat, visible : Movie at domain.movie, free : Boolean ] entityclass Seat [ defprop number : Integer, defprop within : Row ] entityclass Row [ defprop within : Hall, defprop letter : String, category : Category ] public entityclass Hall [ sound : SoundSystem, defprop number : Integer, defprop within : Cinema ] public entityclass Category [] public entityclass SoundSystem [] public entityclass Cinema [ Bachelor-Arbeit Lichtenstern Seite 20 von 44 defprop name : String, address : Address at domain.location ] {ontology domain.cinema} loge as Category pit as Category mono as SoundSystem dolbyA as SoundSystem dolbySR as SoundSystem dolbyDigital as SoundSystem dolbyEX as SoundSystem thx as SoundSystem zkm_hall1 as Hall [ number = 1, within = zkm, sound = dolbyDigital ] zkm_hall2 as Hall [ number = 2, within = zkm, sound = dolbyDigital ] zkm_hall3 as Hall [ number = 3, within = zkm, sound = thx ] zkm as Cinema [ name = "Filmpalast am ZKM", address = anonymous Address at domain.location [ name = "Filmpalast am ZKM", street = "Brauerstraße 40", zipCode = 76137, city = karlsruhe Bachelor-Arbeit Lichtenstern Seite 21 von 44 ] ] sb_bambi as Hall [ number = 3, within = schauburg, sound = dolbySR ] sb_haupt as Hall [ number = 1, within = schauburg, sound = dolbyDigital ] sb_oben as Hall [ number = 2, within = schauburg, sound = dolbySR ] schauburg as Cinema [ name = "Schauburg", address = anonymous Address at domain.location [ name = "Schauburg", street = "Marienstraße 16", zipCode = 76137, city = karlsruhe ] ] jRow3 as Row [ letter = "J", category = loge, within = zkm_hall3 ] Bachelor-Arbeit Lichtenstern Seite 22 von 44 //** @G-DSD: /schema/domain.movie.VSD Klassen {ontology: domain.movie} public entityclass Movie [ defprop title : String, genre : Genre, duration : Duration, country : Country at domain.location, language : Language at domain.location, mainActor : Person at domain.person, director : Person at domain.person ] public entityclass Genre [] {ontology domain.movie} harryPotter3 as Movie [ title = "Harry Potter und der Gefangene von Askaban", genre = family, duration = <PT141M>, language = de, mainActor = danielRadcliffe, director = alfonsoCuaron ] family as Genre action as Genre thriller as Genre Bachelor-Arbeit Lichtenstern Seite 23 von 44 {ontology domain.location} public entityclass Country extends Location [ locatedIn: Continent ] public entityclass Continent extends Location [] public entityclass Language [] valueclass Address extends Location [ name: String, street: String, zipCode: Integer, city: City ] entityclass City extends Location [ name: String ] Bachelor-Arbeit Lichtenstern Seite 24 von 44 {ontology domain.location} de en fr es as as as as Language Language Language Language usa as Country [ locatedIn = northAmerica ] germany as Country [ locatedIn = europe ] france as Country [ locatedIn = europe ] northAmerica as Continent southAmerica as Continent europe as Continent africa as Continent asia as Continent australia as Continent antarctica as Continent karlsruhe as City [ name = "Karlsruhe" ] Bachelor-Arbeit Lichtenstern Seite 25 von 44 {ontology domain.money} valueclass Price [ amount: Double, currency: Currency ] public entityclass Currency [] {ontology domain.money} eur as Currency usd as Currency sfr as Currency Bachelor-Arbeit Lichtenstern Seite 26 von 44 //** @G-DSD: /schema/domain.person.VSD Klassen {ontology: domain.person} entityclass Person [ name : String, birthdate : Date ] {ontology domain.person} danielRadcliffe as Person [ name = "Daniel Radcliffe" ] alfonsoCuaron as Person [ name = "Alfonso Cuarón" ] Bachelor-Arbeit Lichtenstern Seite 27 von 44 3.3 Ablauf der Verarbeitung An dieser Abbildung wird noch mal der grundsätzliche Ablauf der Verarbeitung dargestellt. Bachelor-Arbeit Lichtenstern Seite 28 von 44 Da aber die „ //**“ – Zeilen nicht mit dem Parser – Lexer – Werkzeug [ANTLR] in die Datenbank eingelesen werden können, sieht das angewendete Konzept wie folgt aus: Graphische Nebenrepräsentation g-dsd Transformator Formale Hauptrepräsentation f-dsd Parser Temporäre Repräsentation t-dsd Import Ontologie Export Ontologie Generatoren Java-basierte Nebenrepräsentation j-dsd Bachelor-Arbeit Lichtenstern Datenbank-basierte Nebenrepräsentation db-dsd Seite 29 von 44 4 Implementierung In diesem Kapitel wird aufgezeigt welche Wege bei der Implementierung beschritten wurden. 4.1 Datenbankschema Dieser wesentliche Ausschnitt aus der Grammatik zeigt die Grundlage für das Datenbankschema: start: GKLAMMERAUF ( "ontology" (DOPPELPUNKT)? paket | … | … ) GKLAMMERZU (klassendefinition | instanzdefinition)* ; klassendefinition: ("public")? ("entityclass" | "valueclass")? GROSSBEZEICHNER (vererbung)? klassendefblock ; vererbung: "extends" klasse ; klassendefblock: KLAMMERAUF ( attributdefinition (KOMMA attributdefinition)*)? KLAMMERZU ; attributdefinition: ("defprop" | "orthprop")? KLEINBEZEICHNER DOPPELPUNKT ("list" "of")? klasse ; paket: KLEINBEZEICHNER ; (PUNKT KLEINBEZEICHNER)* klasse: GROSSBEZEICHNER ("at" paket)? ; instanz: KLEINBEZEICHNER ; ("as" klasse)? instanzdefinition: KLEINBEZEICHNER "as" ((klasse (instanzattributblock)?) | ; declsetdef) instanzattributblock: KLAMMERAUF zuweisung (KOMMA zuweisung)* KLAMMERZU ; Bachelor-Arbeit Lichtenstern Seite 30 von 44 Diese Abbild zeigt das relationale Datenbankschema: (ohne redundante Caching - Tabellen) Line Klasse PK PK OntoName Name Typ ExtendsOnto ExtendsName GDSDFile GDSDPage PK PK PK PK OntoName Name Nr Offset Length String Typ Instanz PK PK OntoName Name isdeclsetdef AsName AsPaket GDSDFile GDSDPage Der Ontologie-Name (OntoName) und der Name der Klasse oder Instanz (Name) bilden immer den Primärschlüssel für die Klassen oder Instanzen. Die Tabelle „Line“ bildet den Inhalt einer F-DSD-Datei Zeile für Zeile ab. Da sehr lange Zeilen entstehen können, und die Länge von String auf einen sinnvollen Wert begrenzt werden muss, besteht mit „Offset“ die Möglichkeit der Aneinanderreihung von einzelnen Zeilenabschnitten. Bei Instanzen gibt „isdeclsetdef“ an, ob es sich ein „declsetdef“ handelt. Durch diese einfache Struktur können alle zukünftigen Erweiterungen an der F-DSD auch in der Datenbank abgelegt werden. Mit SQL kann man, unter Zuhilfenahme des ANTLR – Tools, auch alle nötigen Hilfstabellen für Anfragen die häufiger vorkommen und schnell bearbeitet werden müssen, angelegt werden. Dieser Lösungsansatz ergibt auch eine Unabhängigkeit von der verwendeten Datenbank, ohne Rücksicht ob die Datenbank Unicode unterstützt oder nicht. Es können also alle hängigen Datenbanken wie [DB2], [MYSQL] und [POSTGRESQL] verwendet werden. Die Beispiel-Implementierung wurde mit der SQL Datenbank McKoi [MCKOI] realisiert. Bachelor-Arbeit Lichtenstern Seite 31 von 44 4.2 Aufteilung von Dateien mit mehreren Klassen und Instanzen Die Grammatik einer F-DSD-Datei (siehe Anhang A.1) beginnt bei dem Symbol „start“ mit folgender Regel: start: GKLAMMERAUF ( "ontology" … | … ) GKLAMMERZU (klassendefinition | instanzdefinition)* ; Die Grammatik lässt es zu, dass Klassendefinitionen und Instanzdefinitionen in einer Datei stehen. Es ist aber Notwendig, dass man die Klassendefinitionen in eine Datei mit der Endung „.dsd“ und Instanzdefinitionen in eine Datei mit der Endung „.did“ schreibt. Diese Aufteilung ist nötig, damit der „FileIterator“ (siehe Anhang A.2) zuerst alle Klassendefinition durchlaufen kann. Da in der Datenbank aber jede Klassendefinition oder Instanzdefinition einzeln abgelegt werden muss, besteht die Notwendigkeit der Aufteilung der Ontology-Datei auf einzelne Klassen oder Instanzen. 4.2.1 Rahmenbedingung durch die Grammatik Zur Veranschaulichung einiger typische Fälle, hier ein Beispiel aus der Datei domain.cinema.dsd : {ontology: domain.cinema} public entityclass Hall [ sound : SoundSystem, defprop number : Integer, defprop within : Cinema ] public entityclass Category [] public entityclass SoundSystem [] Bei der Klasse SoundSystem sieht man das leere Klammernpaar. Bei Klassen erzwingt die Grammatik [A.1] immer mindestens ein leeres Klammernpaar. Dafür sind folgende Regeln in der Grammatik [A.1] verantwortlich: Bachelor-Arbeit Lichtenstern Seite 32 von 44 klassendefinition: ("public")? ("entityclass" | "valueclass")? GROSSBEZEICHNER (vererbung)? klassendefblock ; klassendefblock: KLAMMERAUF (attributdefinition (KOMMA attributdefinition)*)? KLAMMERZU ; Bei Instanzen ist das nicht so. Hier kommen folgende Regeln zur Anwendung: instanzdefinition: KLEINBEZEICHNER "as" ((klasse (instanzattributblock)?) | declsetdef); Der „instanzattributblock“ ist also optinal. Häufig wird diese Regeln bei Aufzählunen, wie z.B. in der Datei domain.cinema.did, angewendet. {ontology domain.cinema} mono as SoundSystem dolbyA as SoundSystem dolbySR as SoundSystem dolbyDigital as SoundSystem dolbyEX as SoundSystem thx as SoundSystem Im nächsten Abschnitt „einfacher Algorithmus“ wird zunächst die Grundidee vorgestellt, die vollständig funktionieren würde, wenn nicht dieser Sonderfall (der nicht erzwungenen Klammern bei der Instanzdefinition) vorhanden wäre. 4.2.2 Einfacher Algorithmus Die Grundidee bei Aufteilung der Dateien in einzelne Klassen oder Instanzen ist an den Klammern zu erkennen, wo eine Klasse oder Instanz endet. Da aber Klassen oder Instanzen verschachtelt sein können, wird aber zuerst ein Beispiel einer Verschachtelung vorgestellt. {ontology domain.cinema} schauburg as Cinema [ name = "Schauburg", address = anonymous Address at domain.location [ name = "Schauburg", street = "Marienstraße 16", zipCode = 76137, city = karlsruhe ] ] Bachelor-Arbeit Lichtenstern Seite 33 von 44 Und hier der „einfache“ Algorithmus: static int level = 0; static void doChar(char c) // Datei wird Zeichen für Zeichen { // in c durchlaufen if ( c == '[' ) level++; if ( c == ']' ) { level--; if ( level == 0 ) new_data(); } // Blockende wurde erkannt, // dann rufe Methode new_data() auf } 4.2.3 Gewählter Algorithmus Da beim „einfachen“ Algorithmus der Problem mit den nicht erzwungenen leeren Klammernpaaren bei Instanzen besteht, wurde dieses Problem mit dem „PushbackReader“ bewähltigt. static PushbackReader input_data; input_data = new PushbackReader ( new BufferedReader ( new FileReader ( new File ( absFileName ))), 1024 // Size of Pushback-Puffer ); if (token.equals("at")) at_flag = true; else { for (int i=token.length()-1; i >= 0; i--) { input_data.unread( token.charAt(i) ); } new_data(); } Das Problem wir also dadurch gelöst, in dem das nächste Token geholt und geprüft wird. Sollte sich aber herausstellen, das der Block schon zu ende ist, wird das zuviel gelesene Token mit der Methode „unread“ zurückgegeben und mit der Methode „new_data()“ ein neuer Block angefangen. Damit können nun auch die Instanzen aufgeteilt werden. Bachelor-Arbeit Lichtenstern Seite 34 von 44 5 Zusammenfassung Im Rahmen dieser Bachelor - Arbeit wurde ein Konzept erarbeitet, und die Basis dafür implementiert, wie man mit einem relationalen Datenbanksystem, auf nicht besonders leistungsfähiger Hardware, auch bei großen und sehr großen Ontologien ein Ablage- und Zugriffssystem realisieren kann. Dabei wurde die Standardtechnik der relationalen Datenbanksysteme gewählt, da diese ausgereifte und sichere Technik den meisten Nutzen auf nicht besonders leistungsfähiger Hardware in diesem Umfeld verspricht. Einige Idee, besonders in Bezug auf Optimierung, konnten während der raschen Weiterentwicklung des DIANE - Projekts noch nicht umgesetzt werden, da auf die nötige Flexibilität für zukünftige Änderungen geachtet werden musste. In der Zukunft wir deshalb zu prüfen sein, in wie weit es möglich und sinnvoll ist z.B. mehrfache Übersetzung der gleichen Daten zu vermeiden. Dazu könnte man in Zukunft die JC-DSD auch in der Datenbank mit abspeichern. Bachelor-Arbeit Lichtenstern Seite 35 von 44 A Anhang A.1 Grammatik ( ontology/xdiane3sa/grammar/f-dsd-pure.g ) // GRAMMAR FOR DIANE SERVICE DESCRIPTIONS (F-DSD) start: GKLAMMERAUF ( "ontology" (DOPPELPUNKT)? paket | "offer" | "request" ( KOMMA "invoke" ("all" (GROESSERGLEICH ZAHL)? "best" ZAHL) )? ) GKLAMMERZU (klassendefinition | instanzdefinition)* ; klassendefinition: ("public")? ("entityclass" | "valueclass")? GROSSBEZEICHNER (vererbung)? klassendefblock ; vererbung: "extends" klasse ; klassendefblock: KLAMMERAUF ( attributdefinition (KOMMA attributdefinition)*)? KLAMMERZU ; attributdefinition: ("defprop" | "orthprop")? KLEINBEZEICHNER DOPPELPUNKT ("list" "of")? klasse ; paket: KLEINBEZEICHNER ; (PUNKT KLEINBEZEICHNER)* klasse: GROSSBEZEICHNER ("at" paket)? ; instanz: KLEINBEZEICHNER ; ("as" klasse)? instanzdefinition: KLEINBEZEICHNER "as" ((klasse (instanzattributblock)?) | ; declsetdef) instanzattributblock: KLAMMERAUF zuweisung (KOMMA zuweisung)* KLAMMERZU ; Bachelor-Arbeit Lichtenstern Seite 36 von 44 zuweisung: KLEINBEZEICHNER (PLUS)? GLEICH ( primitiverwert | instanz | LABEL | anonidef | vardef | "one" "from" setdef ) ; anonidef: "anonymous" (l:LABEL)? klasse (instanzattributblock)? ; primitiverwert: ( | | | | | | ) ; STRING ZAHL BOOLEAN DATE TIME DATETIME DURATION vardef: "var" (l:LABEL)? ( RKLAMMERAUF who KOMMA when KOMMA ZAHL RKLAMMERZU )+ "from" setdef ( "default" (primitiverwert | instanz | anonidef) )? ; who: ("in" | "IN" | "out" | "OUT") ; when: ("e" | "E" | "x" | "X") ; setdef: ("lists" "buildable" "from")? ( klasse | enumsetdef | declsetdef ) ; enumsetdef: GKLAMMERAUF ( instanz (KLAMMERAUF ZAHL KLAMMERZU)? (KOMMA instanz (KLAMMERAUF ZAHL KLAMMERZU)?)* | primitiverwert (KLAMMERAUF ZAHL KLAMMERZU)? (KOMMA primitiverwert (KLAMMERAUF ZAHL KLAMMERZU)?)* ) GKLAMMERZU ; Bachelor-Arbeit Lichtenstern Seite 37 von 44 declsetdef: RKLAMMERAUF (l:LABEL)? "set" "of" klasse (typecheckstrategy)? (directcondition)* (propertycondition)* (connectingstrategy)? RKLAMMERZU ; typecheckstrategy: "or" ("fuzzy")? ("supertype" | "subtype") (KLAMMERAUF ZAHL KLAMMERZU)? ; directcondition: "with" "elements" (primitivecondition | instancecondition) ; primitivecondition: (WAVE)? (TAGAUF | KLEINERGLEICH | GLEICHGLEICH | GROESSERGLEICH | TAGZU | UNGLEICH) primitiverwert ; instancecondition: ( (GLEICHGLEICH | UNGLEICH) instanz | "sim" RKLAMMERAUF instanz RKLAMMERZU | "in" enumsetdef ) ; propertycondition: ("where" | "and") (ms=missingstrategy)? KLEINBEZEICHNER ( GLEICHGLEICH primitiverwert | GLEICHGLEICH instanz | GLEICHGLEICH vardef | "in" setdef ) ; missingstrategy: GKLAMMERAUF "when" "missing" ( "ask" | "assume" "failed" | "ignore" | "assume" "fulfilled" | "assume" "value" KLAMMERAUF ZAHL KLAMMERZU ) GKLAMMERZU ; Bachelor-Arbeit Lichtenstern Seite 38 von 44 connectingstrategy: "combine" "by" cexpression ; cexpression: ( KLEINBEZEICHNER | ("exp" RKLAMMERAUF cexpression KOMMA ZAHL RKLAMMERZU) | RKLAMMERAUF cexpression ("and" | "or" | "mul" | "add") cexpression RKLAMMERZU | ("min" | "max") RKLAMMERAUF cexpression (KOMMA cexpression)+ RKLAMMERZU | RKLAMMERAUF ZAHL STERN cexpression (PLUS ZAHL STERN cexpression)+ RKLAMMERZU ) ; // LEXER KLEINBUCHSTABE GROSSBUCHSTABE ZIFFER US KLAMMERAUF KLAMMERZU RKLAMMERAUF RKLAMMERZU GKLAMMERAUF GKLAMMERZU GLEICH GLEICHGLEICH KOMMA PUNKT DOPPELPUNKT STERN SEMI HOCH TAGAUF TAGZU KLEINERGLEICH GROESSERGLEICH UNGLEICH PLUS WAVE DOLLAR : : : : : : : : : : : : : : : : : : : : : : : : : : 'a'..'z'; 'A'..'Z'; '0'..'9'; '_'; '{'; '}'; '('; ')'; '{'; '}'; '='; "=="; ','; '.'; ':'; '*'; ';'; '^'; '<'; '>'; "<="; ">="; "!="; '+'; '~'; '$'; Bachelor-Arbeit Lichtenstern Seite 39 von 44 // Whitespace -- ignored WS: ( ' ' | '\t' | '\f' | ( options : "\r\n" | '\r' | '\n' ) )+ ; // Single-line comments SL_COMMENT: "//" (~('\n'|'\r')) ('\n'|'\r'('\n')?) ; //Built-in types ZAHL: ('-')? (ZIFFER)+ ('.' (ZIFFER)+)? ; BOOLEAN: TAGAUF ("true" | "false") TAGZU ; STRING: '"' (~('"'|'\\'|'\n'|'\r')) '"' ; // <YYYY-MM-DD> DATE: TAGAUF ZIFFER ZIFFER ZIFFER ZIFFER '-' ZIFFER ZIFFER '-' ZIFFER ZIFFER TAGZU ; TIME: TAGAUF ZIFFER ZIFFER DOPPELPUNKT ZIFFER ZIFFER (DOPPELPUNKT ZIFFER ZIFFER (PUNKT ZIFFER ZIFFER ZIFFER)?)? TAGZU ; DATETIME: TAGAUF ZIFFER ZIFFER ZIFFER ZIFFER '-' ZIFFER ZIFFER '-' ZIFFER ZIFFER 'T' ZIFFER ZIFFER DOPPELPUNKT ZIFFER ZIFFER (DOPPELPUNKT ZIFFER ZIFFER (PUNKT ZIFFER ZIFFER ZIFFER)?)? TAGZU ; Bachelor-Arbeit Lichtenstern Seite 40 von 44 DURATION: TAGAUF 'P' (KZAHL ('Y'|'M'|'D'))* ('T' (KZAHL ('.' KZAHL)? ('M'|'S'))*)? TAGZU ; KZAHL: ZIFFER ((ZIFFER) (ZIFFER)?)? ; //Bezeichner GROSSBEZEICHNER: GROSSBUCHSTABE(US|GROSSBUCHSTABE|KLEINBUCHSTABE|ZIFFER); KLEINBEZEICHNER: KLEINBUCHSTABE(US|GROSSBUCHSTABE|KLEINBUCHSTABE|ZIFFER); LABEL: DOLLAR KLEINBEZEICHNER;| Bachelor-Arbeit Lichtenstern Seite 41 von 44 A.2 FileIterator package diane.xdiane3sa.transformer; import java.io.*; public class FileIterator { public static void main(String[] args) { File file=null; try { file= new File(args[1]); } // args[1] übergibt den Namen // des Verzeichnis der Dateien catch(Exception e) { System.out.println(e+ "\nDer angegebene Pfad existiert nicht!");} if (file.isDirectory()) { getFiles(file,".dsd"); getFiles(file,".did"); getFiles(file,".dod"); getFiles(file,".drd"); } // // // // Diane Diane Diane Diane Schema Instance Offer Request Description Description Description Description } //----------------------------------------------------------------static void getFiles(File file, String dateityp) { File[] files = file.listFiles(); for(int i=0;i<Array.getLength(files);i++) { if (files[i].isDirectory()) { getFiles(files[i], dateityp); } String filename = files[i].getName(); if (filename.endsWith(dateityp)) { System.out.println(files[i].getName()); FDSD_Transformer.transform(files[i].getAbsolutePath()); } } } } Bachelor-Arbeit Lichtenstern Seite 42 von 44 Quellenverzeichnis Hinweis: Alle Verknüpfungen (Links) beziehen sich auf dem Stand vom 15.10.2004 [3SA] Frank Schell, Christoph Schaa, Thorsten Höllrigl, Universität Karlsruhe, Schaffung einer formalen Grundlage für Dienstbeschreibungen in DIANE und Entwicklung von geeigneten Werkzeugen und Beispielen, Dreier-Studienarbeit, Juni 2004 http://www.ipd.uka.de/DIANE/docs/3sa.pdf [ANTLR] ANTLR, ANother Tool for Language Recognition http://www.antlr.org [CVS] CVS, CVS Home Page https://www.cvshome.org [DB2] DB2, Universal Database (Don Chamerlin, A COMPLETE GUIDE TO DB 2) http://www.software.ibm.com/data/db2 [DIANE] DIANE-Projekt: Dienste in Ad-Hoc-Netzen, Universität Karlsruhe, http://www.ipd.uka.de/DIANE/de [DSD] Michael Klein, Universität Karlsruhe, DSD-Cookbook: Handbuch DIANE Service Description, Version 0.4.1 http://www.ipd.uka.de/DIANE/docs/DSD-Cookbook.pdf [G-DSD] Thomas Herzog, Universität Karlsruhe, Aktive VISO-Schablonen zur grafischen Erstellung von DIANE-Dienstbeschreibungen http://www.ipd.uka.de/DIANE/de (siehe u.a. bei Mitarbeiter) [JAVA] Java, Java Technology Home Page http://java.sun.com [JEDIT] JEDIT, Home Page des Programmer’s Text Editor Written in Java, so it runs on MacOS X, Unix and Windows. Supports a large number of character encodings including UTF8 and Unicode. http://www.jedit.org [MCKOI] Mckoi, SQL Database An Open Source Java SQL Database http://mckoi.com/database/ Bachelor-Arbeit Lichtenstern Seite 43 von 44 [MYSQL] MySQL, SQL Database “The world’s most popular open source database” http://www.mysql.com [POSTGRESQL] PostgreSQL, SQL Database “The world’s most advanced open source database has supported Unicode since version 7.1” http://www.postgresql.org [UNICODE] Unicode, Unicode Home Page http://www.unicode.org [UTF-8] Markus Günther Kuhn, University of Cambridge, UTF-8 and Unicode FAQ for Unix/Linux http://www.cl.cam.ac.uk/~mgk25/unicode.html Bachelor-Arbeit Lichtenstern Seite 44 von 44
