Austausch von Katalog-Informationen über Ontologien am Beispiel des OXID Shop-Systems und UBL

Transkript

1 JOHANN WOLFGANG GOETHE UNIVERSITÄT FRANKFURT AM MAIN Fachbereich Informatik und Mathematik Institut für Informatik Datenbanken und Informationssysteme Austausch von Katalog-Informationen über Ontologien am Beispiel des OXID Shop-Systems und UBL Diplomarbeit von Alicja Koppe Erstprüfer: Prof. Dott.-Ing. Roberto V. Zicari Betreuer: Dr. Karsten Tolle Abgabetermin: 01. März 2012

2 2

3 Eidesstattliche Erklärung Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit selbständig verfasst und keine anderen als die angegebenen Quellen, Hilfsmittel und Geräte benutzt habe. Frankfurt am Main, 01. März 2012 Alicja Koppe 3

4 4

5 Danksagung An dieser Stelle möchte ich mich bei allen Personen bedanken, die mich über die gesamte Studienzeit und insbesondere bei der Erstellung meiner Diplomarbeit unterstützt haben. Ein besonderes Dankeschön geht an Herrn Dr. Karsten Tolle, der mich während meiner Diplomarbeit hervorragend betreut hat und mir immer mit wertvollen Hinweisen und Ratschlägen zur Seite stand. Ich danke ganz herzlich meinem Mann Michael Koppe für sein jahrelanges Verständnis und seine großartige Unterstützung und möchte ihm diese Arbeit widmen. Danke, dass Du immer an mich geglaubt hast! Nicht zuletzt möchte ich meinen Eltern danken, die mir das Studium überhaupt erst ermöglicht haben. 5

6 6

7 Inhaltsverzeichnis 1 Allgemeines Motivation Zielsetzung Gliederung der Arbeit 10 2 Grundlagen EDI Electronic Data Interchange XML- basierte Standards OASIS Universal Business Language (UBL) UBL-Katalog Online Shop System OXID Was ist eine Ontologie? Aufbau von Ontologien Ontologiemodellierung und Ontologiesprachen Web Ontology Language OWL Ontologie als Adapter 30 3 Konzeption Modellierung der Ontologie Mapping zwischen Datenbank und Ontologie Mapping zwischen Ontologie und XML 35 4 Erstellung der Ontologie Struktur der OXID- Datenbank Modellierung der Ontologie 41 5 Mapping von einer Datenbank auf eine Ontologie Umwandlung der OXID- Datenbank in eine Ontologie Bewertung von Mapping-Werkzeug IwOnto 53 6 Mapping einer Ontologie auf einen UBL-Katalog Existenz von passenden Mapping-Werkzeugen Prolog vor der Entwicklung des Programms Implementierung Testen von UBL-Katalog auf die Gültigkeit 59 7 Zusammenfassung und Ausblick Zusammenfassung Ausblick 62 7

8 A Die Produkt-Ontologie in RDF/XML Syntax 63 B Schema der OXID-Datenbank 66 C Schema für den UBL-Katalog 67 D Inhaltsbeschreibung der CD 69 Literaturverzeichnis 71 8

9 Kapitel 1 Allgemeines 1.1 Motivation Die Kommunikation zwischen Kunden, Lieferanten oder anderen Geschäftspartnern basiert auf dem Austausch von Geschäftsdokumenten, z.b. Angebot, Bestellung, Lieferschein oder Rechnung. Heutzutage tauschen immer mehr Unternehmen ihre Geschäftsdokumente auf dem elektronischen Wege aus. Damit ein reibungsloser Dokumentenaustausch zwischen jeweiligen Systemen stattfinden kann, müssen die Dokumente ein standarisiertes Datenformat haben. Es gibt viele Standards für den Austausch von Geschäftstransaktionen, die je nach Branche eingesetzt werden, z.b. SWIFT für Banken oder EDITEX in der Textilbranche. Mit der Nutzung vom elektronischen Datenaustausch läuft die Kommunikation schneller und automatisierter ab. Dies führt zur enormen Ersparnis von Zeit und Geld und ist mit hoher Effizienz verbunden. Im elektronischen Handel werden Waren im Internet zum Kauf und Verkauf angeboten. Für die Online- Präsentation und -Verkauf der Waren benutzen viele Händler einen Internet- Onlineshop, der auf einem Shop-System basiert. Auf dem Markt findet man viele verschiedene Shopsysteme, die die Erstellung, Verwaltung und Vermarktung eines Onlineshops ermöglichen. Es gibt kommerzielle Shopsysteme zum mieten bzw. kaufen oder die Open- Source- Shopsysteme zum kostenlosen Runterladen und Installieren. Der Austausch und Abgleich von Kataloginformationen könnte für einen Händler, der mehrere Online-Shops betreibt, von Nutzen sein. Angenommen ein Händler besitzt einen privaten Online-Shop sowie ein Konto auf dem Internetaktionshaus Ebay, die beide auf einem Datenbankartikelbestand basieren. Nach Verkauf eines Artikels in einem Shop müssten dementsprechend die Artikelbestände im zweiten Shop aktualisiert werden. Es ist aber nicht gewährleistet, dass alle Partner alle Dokumente im gleichen Format benutzen. Da dieses Problem unabhängig von der Branche ist, sollte für eine Lösung, um möglichst viele Händler zu erreichen, ein Austauschformat gewählt werden, welches unabhängig von Brachen ist. Mit diesem Ziel brachenunabhängig zu sein, wurde die Universal Business Language (UBL) [UBL] entwickelt. UBL soll den Austausch von Geschäftstransaktionen zwischen Unternehmen aus vertikalen Märkten ermöglichen. 9

10 Sollte sich dies durchsetzen, könnte mittels dann eingebauter UBL-Schnittstellen in den Onlineshops oder dem Ebay-System, die UBL-Dateien aufgenommen und Daten für das entsprechende Konto aktualisiert werden. Da klar ist, dass UBL nicht der einzige Standard sein wird, muss überlegt werden, wie mit einer größeren Anzahl von Standards zu verfahren ist. Hierbei bietet sich eine zusätzliche Abstraktionsebene an, in der eine Konzentration auf die logische Ebene stattfindet. Dies kann z.b. über eine Ontologie geschehen, in der die semantischen Konzepte beschrieben würden. In unserem Fall also Beschreibung der Produkte, wie viele im Lager vorrätig sind und vieles mehr. Soll ein weiterer Standard unterstützt werden, muss so nur eine Abbildung auf die Ontologie stattfinden und nicht auf alle anderen genutzten Standards. 1.2 Zielsetzung Das Ziel dieser Diplomarbeit ist es eine Abbildung von Datenbankinhalten einer relationalen Datenbank auf ein Standardaustauschformat für Geschäftsdokumente durchzuführen. Der Elektronische Shop speichert seine Daten in der vom Shop erzeugten SQL-Datenbank. Mit Hilfe von Softwarewerkzeugen sollen die Artikelinformationen aus der oben genannten Datenbank gelesen und in Form eines Standardaustauschformates für Geschäftsdokumente ausgegeben werden. Dies wird am Beispiel eines kostenlosen, quelloffenen und vorgegebenen OXID eshop Community Edition und eines vorgegebenen Austauschformates für Geschäftsdokumente Universal Business Language (UBL) durchgeführt. 1.3 Gliederung der Arbeit Das Kapitel GRUNDLAGEN (Kapitel 2) ab Seite 13 stellt die grundlegenden Begriffe und Arbeitsmittel vor, die in dieser Arbeit verwendet werden. Insbesondere wird auf die Ontologien eingegangen, sowie auf das Datenaustauschformat Universal Business Language und OXID Shop-System. Im Kapitel KONZEPTION (Kapitel 3) ab Seite 33 werden der Arbeitsablauf der Diplomarbeit und die dazugehörigen Techniken beschrieben, die für das Erreichen des gesetzten Zieles der Arbeit durchgeführt und eingesetzt werden. Im Kapitel ERSTELLUNG DER ONTOLOGIE (Kapitel 4) ab Seite 39 wird eine Ontologie mit Hilfe von einem Ontologie-Editor modelliert und die dazugehörigen Schritte ausführlich dokumentiert. 10

11 Das Kapitel MAPPING VON EINER DATENBANK AUF EINE ONTOLOGIE (Kapitel 5) ab Seite 49 beschreibt den Prozess der Abbildung zwischen der relationalen Datenbank des vorgestellten Shop-Systems und einer Ontologie. Anschließend findet die Bewertung des Mapping-Werkzeugs statt. Das Kapitel MAPPING EINER ONTOLOGIE AUF EINEN UBL-KATALOG (Kapitel 6) ab Seite 55 beschäftigt sich mit der Abbildung der modellierten Ontologie auf den UBL-Katalog. Es werden zu diesem Zweck verschiedene Werkzeuge auf ihre Nützlichkeit geprüft. Da kein geeignetes Werkzeug gefunden wurde, wird ein eigenes Programm implementiert, mit dem das gewünschte Mapping funktionieren wird. Das Kapitel ZUSAMMENFASSUNG UND AUSBLICK (Kapitel 7) ab Seite 61 fasst die Diplomarbeit kurz zusammen. Im Abschnitt Ausblick werden die Vorschläge zur Erweiterung und Verbesserung des entwickelten Programmes gegeben. 11

12 12

13 Kapitel 2 Grundlagen In diesem Kapitel werden die grundlegenden Arbeitsmittel vorgestellt, die in dieser Arbeit benutzt werden. Im ersten Abschnitt wird der elektronische Datenaustausch EDI (Kap. 2.1), mit Fokus auf die XML- basierten Austauschformaten, dargestellt. Es wird dabei näher auf das Austauschformat UBL eingegangen. Dann wird der UBL-Katalog, ein Dokumenttyp von UBL, beschrieben. Im Weiteren wird das Online Shop System OXID (Kap. 2.2) vorgestellt. Anschließend werden Ontologien (Kap. 2.3) beschrieben, die die Darstellung, den Austausch und die Wiederverwendung von Wissen in digitalisierter Form möglich machen. Die Ontologiesprache Web Ontology Language (OWL) wird charakterisiert. 2.1 EDI Electronic Data Interchange Der elektronische Austausch von Geschäftsdokumenten (Elektronic Data Interchange, EDI) wurde Ende der 60er Jahren entwickelt und eingeführt. Die ersten EDI-Lösungen wurden aus dem Grund entwickelt, weil ein Großteil der zwischenbetrieblichen Kommunikation schriftlich über mehrere Stationen erfolgte. Die Dokumente, die per Post oder per Telefax ausgetauscht wurden, müssten zuerst in jeweiligen Unternehmen erstellt, ausgedruckt und an den Geschäftspartner geschickt werden, wo sie erneut in das System eingegeben werden mussten. Die traditionelle zwischen- und innerbetriebliche Kommunikation war somit sehr zeitaufwendig und fehleranfällig [WHB01,6]. Bei EDI handelt es sich um einen schnellen und automatischen Austausch von elektronischen Geschäftsdaten zwischen beteiligten Unternehmen und deren Computersystemen. Es werden Papierdokumente wie Bestellungen, Rechnungen, Zahlungsaufträge usw. elektronisch erstellt und über Computernetze übertragen. Damit der Austausch von diesen Informationen überhaupt stattfinden kann, müssen die Dokumente so formatiert sein, dass das Computersystem eines anderen Unternehmens sie weiterbenutzen kann. Es muss ein gemeinsamer Standard zur Repräsentation der Daten festgelegt werden, dessen Syntax und Semantik [Sch94,15] bekannt ist. Erst dann können die Geschäftspartner miteinander kommunizieren. Mit der Verwendung standarisierter Datenformate müssen die Daten nur einmal in das System eingeben werden, was mit einem Gewinn an Zeit und Geld verbunden ist [WHB01,6]. 13

14 Da beim EDI menschliche Aufgaben im Kommunikationsprozess z.b. das Sortieren, Ablegen und Versand entfallen, wird die Fehlereingabe reduziert, was wiederum zu einer genaueren und zuverlässigeren Information führt [Fis96, C413.04]. Seit der Einführung von EDI wurden im laufe der Jahre viele internationale und branchenübergreifende EDI-Standards entwickelt. Dazu gehören zum Beispiel [EDA]: SWIFT- Standard für Banken, UN/EDIFACT United Nations Electronic Data Interchange For Administration, Commerce and Transport, VDA - Standard der deutschen Automobilindustrie, Extensible Markup Language (XML) - basierte Standards Und andere. Nachfolgend möchte ich näher auf die XML- basierte Standards eingehen XML-basierte Standards 1998 wurde vom World Wide Web Consortium (W3C) die erste Ausgabe von XML- Spezifikation herausgegeben. XML sollte ein Standard zur Beschreibung von Struktur und Inhalt von Dokumenten werden, wobei der Inhalt und Darstellung voneinander getrennt werden sollen [WHB, 3]. Das hat die Möglichkeiten von Hypertext Markup Language (HTML) übertroffen, da HTML keine Informationen über den Inhalt angibt [XML]. XML ist eine textbasierte Metasprache und eine Untermenge von Standard Generalized Markup Language (SGML; deutsch: Normierte Verallgemeinerte Auszeichnungssprache), von der aber große Teile in XML nicht übernommen wurden [WHB, 18]. XML ist beliebig erweiterbar, die Strukturelemente können nach Bedarf definiert und benannt werden [NIE, 14]. Die Struktur und der Inhalt von XML-Dokumenten werden durch ein XML-Schema beschrieben. Das mit XSD (XML Schema Definition) abgekürzte XML- Schema legt fest, aus welchen Elementen das konkrete XML- Dokument bestehen soll, welchen Inhalt und Attribute die Elemente haben und wie sie miteinander verschachtelt sein sollten. Jedem Element wird ein Typ zugeordnet. Es gibt einfache ( simpletype ) und komplexe ( complextype ) Typen. Einfache Typen sind vordefinierte Datentypen, z.b. String oder Integer. Komplexe Typen können weitere Unterelemente oder Attribute enthalten. 14

15 Damit ein XML-Dokument als solches genannt werden kann, muss das Dokument eine Reihe von Regeln erfüllen [Kno03]: Jedes XML-Dokument muss mit einer XML-Deklaration beginnen, die die XML- Version und die Codierung des Dokumentes angibt. Jedes XML-Dokument muss genau ein Wurzelelement (Root-Element) enthalten, das das Dokument einschließt und alle weiteren Elemente enthält. Jedes Element hat ein Start- und ein Ende- tag oder besteht aus leeren Element. Im folgenden Beispiel (Text 2.1) wird ein XML- Schema dargestellt, dessen Struktur der Daten durch die Verschachtelung wiedergegeben wird. 1.<?xml version="1.0" encoding="utf-8"?> 2.<xsd:schema xmlns:xsd=" 3. <xsd:complextype name= Person > 4. <xsd:sequence> 5. <xsd:element name="name" type="xsd:string"/> 6. <xsd:element name="ort" type="xsd:string"/> 7. </xsd:sequence> 8. </xsd:complextype> 9.</xsd:schema> Text 2.1: Beispiel für XML-Schema In der zweiten Zeile werden das öffnende Wurzelelement schema und der Namensraum für XSD definiert. Das Element Person vom komplexen Typ, enthält weitere Elemente Name und Ort, die vom Datentyp String sind. Das Element sequence definiert eine geordnete Struktur mit fester Reihenfolge. Für das oben genannte XML- Schema wird jetzt im Text 2.2 ein XML- Dokumentbeispiel, so genanntes Instanzdokument dargestellt. Das Dokument stellt den Namen und den Wohnort einer Person vor. <?xml version="1.0"?> <Person> <Name>Alicja Koppe </Name> <Ort>Frankfurt</Ort> </Person> Text 2.2: Beispiel für XML- Dokument OASIS Universal Business Language (UBL) Die, von der Organization for the Advancement of Structured Information Standards (OASIS) entwickelte Universal Business Language (UBL), definiert eine Sammlung von 15

16 internationalen branchenunabhängigen XML- basierten Standards für Geschäftsdokumentenaustausch. Das Ziel der UBL-Entwicklung war unter anderem, den Datenaustausch zwischen Unternehmen zu erleichtern, die unterschiedlichen Branchen angehören und daher keinen gemeinsamen, branchenspezifischen Standard besitzen [UBL10]. UBL ist die erste internationale Implementation von Electronic Business XML (ebxml) Core Components Technical Spezifikation (CCTS 2.01, ISO 1500) [OAUBL, Punkt 13]. Die erste, im November 2004 veröffentlichte Version enthielt neun Dokumenttypen [OAUBL, Punkt 3]. Dank der UBL Version 2.0, die Ende 2006 um weitere 23 Dokumenttypen erweitert wurde, existieren momentan mehr als 30 Dokumenttypen [OAUBL, Punkt 3, 17]. UBL Schemas sind modular, wieder verwendbar, und so wie XML leicht erweiterbar. Die kostenfreie UBL Bibliothek basiert auf ebxml CCTS Business Information Entities (BIEs), den so genannten Informationseinheiten oder Bausteinen. Die aus diesen Informationseinheiten zusammengesetzten UBL-Dokumente können in verschiedenen Geschäftsdokumenten verwendet werden [UBL10]. UBL definiert folgende Metamodellierungselemente: Core Components Types (CCT) und Data Types (DT) identifizieren die Typen der Bausteine eines Dokumentes Aggregate Core Components (ACC) definieren zusammengesetzte Geschäftsstrukturen; kann als Objekt oder eine Objektklasse repräsentiert werden und enthält Attribute oder Eigenschaften Basic Core Components (BCC) und Association Core Components (ASCC) definieren einfache und zusammengesetzte Eigenschaften von ACC Core Components (CC) oder Business Information Entities (BIE) definieren Informationseinheiten [NAL05,7]; man unterscheidet drei Arten von CC und BIEs: BBIE = Basic Business Information Entities bezeichnen einzelne Informationen über Objekte auf Elementarebene. Die Informationseinheiten sind nicht mehr zerlegbar, haben also atomaren Charakter, z.b. Zahlen (VerisonID), Vor- und Nachnamen von Personen. ABIE = Aggregate Business Information Entities beschreiben Informationseinheiten auf Aggregatebene, die immer oder oft zusammen vorkommen, z. B. um Adressen oder Kombinationen von Waren- und 16

17 Mengenbezeichnungen. Die Informationseinheiten auf dieser Ebene sind aus verschiedenen Einheiten zusammengesetzt, die ihrerseits elementar sind oder selbst Aggregate sein können. ASBIE = Association Business Information Entity beschreiben Informationselemente, die aus verbundenen ABIEs bestehen. ABIEs assozieren miteinander, z.b., eine Käuferadresse, ABIEs: Käufer und Adresse. Die folgende Abbildung 2.1 soll den Zusammenhang zwischen BBIE, ABIE und ASBIE verdeutlichen. Abbildung 2.1: Zusammenhang zwischen BBIE, ABIE und ASBIE [LK07] UBL-Katalog In diesem Teil der Diplomarbeit konzentrieren wir uns auf den Dokumenttyp UBL-Katalog, der fünf verschiedene Dokumententypen enthält. Mit den Dokumenten kann ein neuer elektronischer Katalog angefordert, erstellt oder gelöscht werden. Man kann die enthaltenen Artikel verwalten und aktualisieren. Abbildung 2.2 zeigt die allgemeine Prozesserstellung eines Kataloges und die darin verwendeten Dokumenttypen. Die beteiligten Akteure sind der Kunde und der Lieferant des Kataloges. 17

18 Abbildung 2.2: Allgemeiner UBL-Katalogprozess zwischen Kunde und Lieferant [UBL10] Beispiel: Ein Krankenhaus braucht immer wieder neue Operationsabdeckung und Zubehör, z.b. OP-Masken, OP-Kompressen, OP-Nähten, etc. Das Krankenhaus hat mit einigen Lieferanten Verträge abgeschlossen und erwirbt die Ware bei denen. Bevor der Geschäftsprozess stattfinden kann, treffen sich die beiden Geschäftspartner und legen den Inhalt des UBL-Kataloges fest. Das Krankenhaus muss eine Schnittstelle einbauen, mit deren Hilfe das UBL-Dokument in das System aufgenommen werden kann. Ein Lieferant benutzt das OXID System, was auf der OXID- Datenbank basiert. Ein Krankenhausmitarbeiter aus der Einkaufsabteilung braucht neue Ware, z.b. Spritzen und möchte die bei einem Lieferanten bestellen. Er fordert den UBL-Katalog bei dem Lieferanten an. Die Informationen aus OXID- 18

19 DB werden jetzt mit Hilfe der getesteten Werkzeuge und der eingebauten Ontologie in das Austauschformat UBL umgewandelt und als UBL-Katalog ausgegeben. Der UBL-Katalog in Form eines XML- Dokumentes wird von der integrierten Schnittstelle des Krankenhausbestellsystems (KHBS), das auf der Datenbank basiert, aufgenommen, interpretiert und in der Datenbank mit Artikelinformationen gespeichert (z.b. Spritzen von Lieferant1, Lieferant2 usw.). Ein Mitarbeiter aus der Einkaufsabteilung kann bei Bedarf auf das KHBS eingreifen und somit von dem günstigeren Lieferanten die Waren bestellen. Die folgende Abbildung 2.3 stellt das beschriebene Beispiel graphisch dar. Datenbank von OXID OXID MySQL Ontologie Integrierte Schnittstelle des KHBS UBL-Catalog Spritzen KHBS XML-Dokument INPUT Datenbank mit Artikelinformationen, Z.B. Spritzen von Lieferant 1, Lieferant 2 usw. Krankenhaus Einkauf Abbildung 2.3 Austausch von Geschäftsdaten zwischen Krankenhaus und Lieferanten In der unten stehenden Tabelle 2.1 werden die Elemente des UBL-Kataloges, deren Komponentenart und Definition beschrieben. Der UBL-Katalog besitzt viele Elemente. In dieser Arbeit wird nur auf die notwendigen Elemente für ein UBL-Katalog eingegangen. 19

20 ELEMENT TYPE BESCHREIBUNG ID BBIE Ein Identifikator für den Katalog zugeteilt vom Verkäufer IssueDate BBIE Das Datum, an dem Katalog ausgestellt wurde ProviderParty ASBIE Informationen über Kataloganbieter(Name, Adresse, Kontakt) ReceiverParty ASBIE Informationen über Katalogempfänger (Name, Adresse, Kontakt) CataloqueLine ASBIE Verbindung von Elementen, die gekauft werden können Hier findet man alle Informationen zu den Artikeln Tabelle 2.1 : Die Beschreibung der notwendigen Elemente eines UBL-Kataloges [UBC] Die, in der Tabelle 2.1 beschriebenen Elemente, werden jetzt mit zufälligen Werten in einer Beispielontologie (Text 2.3) dargestellt. Beispiel eines UBL-Kataloges <Catalogue > <cbc:id>cat-ex-1</cbc:id> <cbc:issuedate> </cbc:issuedate> <cac:providerparty /> <cbc:endpointid schemeagencyid="9" schemeid="gln"> </cbc:endpointid> <cac:partyname> // ID oder/und Name <cbc:name>aluras Shop</cbc:Name></cac:PartyName> <cac:postaladdress> <cbc:addressformatcode listagencyid"320" listid="urn:oioubl:codelist:addressformatcode-1.1"> StructuredDE</cbc:AddressFormatCode> <cbc:streetname>vatterstrasse</cbc:streetname> <cbc:buildingnumber>40</cbc:buildingnumber> <cbc:cityname>frankfurt</cbc:cityname> <cbc:postalzone>60386</cbc:postalzone> <cac:country><cbc:identificationcode>de</cbc:identificationcode></cac:country> </cac:postaladdress> <cac:partylegalentity> <cbc:companyid schemeid="de:cvr">de </cbc:companyid></cac:partylegalentity> </cac:providerparty > +<cac:receiverparty > <cac:catalogueline > <cbc:id >SUB </cbc:ID> <cbc:actioncode listschemeuri="urn:oioubl:codelist:catalogueactioncode-1.0 > ADD</cbc:ActionCode> <cbc:orderableindicator >true</cbc:orderableindicator> <cbc:orderableunit>ea</<cbc:orderableunit> //wenn true, dann Unit pflicht <cbc:contentunitquantity unitcode="ea" >1</cbc:ContentUnitQuantity> <cac:requireditemlocationquantity /> //notwendig wegen Preis <cac:price> <cbc:priceamount currencyid="eur">65.00</cbc:priceamount> //Betrag <cbc:basequantity unitcode="ea">1</cbc:basequantity> //65.00 EUR für 1 Artikel <cbc:orderableunitfactorrate>1</cbc:orderableunitfactorrate> //BaseQuantity zu OrdUnit.Wenn beide 1, dann OrdUnitFactorR =1 </cac:price></cac:requireditemlocationquantity> 20

21 <cac:item> <cbc:name >Jeans</cbc:Name> //Name im Katalog eventuell <cbc:description> </ cbc:description> eventuell <cbc:brandname >Lee</cbc:BrandName> //Marke eventuell <cbc:modelname >Botcut</cbc:ModelName> //Modell <cac:sellersitemidentification /> //Beschreibung des Artikels <cbc:id>1234</cac:id> //ArtikelNummer <cac:physicalattribute> //Eigenschaften (Color, Size) <cbc:attributeid>color</cac: AttributeID> <cbc:description>blue</cac:description><cac:physicalattribute> <cac:sellersitemidentification /> <cac:commodityclassification/> // Klassifikationsstandard für Produkte(UNSPSC) <cbc:itemclassificationcode listname="unspsc"listversionid="7.0401"> </cbc:ItemClassificationCode></cac:CommodityClassification> </cac:item> </cac:catalogueline> </Catalogue> Text 2.3: Beispiel für einen UBL-Katalog mit den notwendigen Elementen 2.2 Online Shop System OXID In einem Onlineshop bekommt man Waren und Produkte, die man online erwerben kann. Um ein Onlineshop betreiben zu können, benötigt man ein Shopsystem, also eine Software, die alle Abwicklungen im Hintergrund des Shops ablaufen lässt. Man bekommt auf dem Markt viele verschiedene Shopsysteme, die die Erstellung, Verwaltung und Vermarktung eines Onlineshops möglich machen. Es gibt Miet-, fertige Kauf- und kostenlose Open- Source- Shopsysteme. Um das Ziel dieser Diplomarbeit zu erreichen und die dazugehörige Lösung zu testen, benutzen wir ein kostenloses Shopsystem OXID Community Edition [OCE]. In der Abbildung 2.4 wird die Hauptseite von OXID Community Edition dargestellt. Die Architektur von OXID ist modular, objektorientiert und kann einfach erweitert und individuell angepasst werden. Modulare Architektur bedeutet, dass sich die Software aus Modulen (Bausteinen, Bauelementen) zusammensetzt. Die Objektorientierung hilft bei der Definition von Modulen und der Interaktion zwischen Modulen [OCE]. 21

22 Abbildung 2.4: Screenshot von OXID eshop Community Edition [OCE] 2.3 Was ist eine Ontologie? Der Begriff Ontologie wird sowohl in der Philosophie als auch in der Informatik verwendet. Um diesen Begriff in der Informationsverarbeitung zu verstehen, muss zuerst erläutert werden, was die Informationsverarbeitung ist. Die fundamentale Aufgabe von Informationssystemen ist Objekte der realen Welt in einer geeigneten Form darzustellen, so dass diese vom Computer verarbeitet werden können. Diese vorgenommenen Veränderungen, müssen wieder in der realen Welt abgebildet werden [Stu09, 5]. In der Informatik gibt es eine große Anzahl von Definitionen für diesen Begriff. Die bekannteste stammt von T.Gruber, der die Ontologie als an explicit specification of a conceptualization [Gru93] definiert. Auf Deutsch lautet diese Definition: eine explizite Spezifikation einer Konzeptualisierung. Diese Definition wurde später von Studer erweitert, der die Ontologie als eine formale, explizite Spezifikation einer gemeinsam genutzten Konzeptualisierung definiert [Stu09, 22]. Im Gegensatz zu einer klassischen Datenbank beschreibt eine Ontologie detailliert eine Menge von Begriffen eines Weltausschnittes und deren Beziehungen im Bereich einer bestimmten Domäne. Die Regeln über deren Zusammenhang ermöglichen es, die Rückschlüsse aus den vorhandenen Daten zu ziehen, Widersprüche in den Daten zu erkennen und fehlendes Wissen selbstständig aus dem 22

23 Vorhandenen zu ergänzen [ONT]. Die Ontologie soll einen formalen Aufbau haben und keine natürliche Sprache enthalten, um dabei maschinenlesbar sein zu können Aufbau von Ontologien Damit eine Ontologie von Maschinen benutzt werden kann, muss sie eine genau definierte Struktur besitzen. Eine Ontologie besteht aus folgenden Bestandteilen [ONT]: Begriffe auch als Klassen bezeichnet. Beschreiben eine Menge von Objekten der realen Welt mit dazugehörigen Attributen Instanzen repräsentieren Objekte eines Begriffs Relationen beschreiben Beziehungen zwischen Instanzen Vererbung: Relationen und Eigenschaften der Begriffe können vererbt werden, wobei alle Eigenschaften an das abgeleitete Instanz weitergegeben werden. Axiome: Aussagen über Begriffe, die immer wahr sind. Diese repräsentieren Wissen, das sich nicht aus den Begriffen ableiten lassen. Die Abbildung 2.5 zeigt eine Beispielontologie mit ihren Elementen. Aus dieser Ontologie kann man herausfinden, welches Outfit mit passenden Schuhen und dazugehörigen Accessoires die Person gerne trägt. Abbildung 2.5 : Begriffe, Instanzen und Relationen einer Beispielontologie 23

24 2.3.2 Ontologiemodellierung und Ontologiesprachen Man unterscheidet zwischen unterschiedlichen Typen von Ontologien. Ein sehr wichtiges Kriterium ist die Art, in der das Wissen dargestellt wird. Ontologien, die allgemeine, grundlegende und bereichübergreifende Konzepte der Welt beschrieben, werden als Upperlevel, Top-level, Foundational oder allgemeine Ontologien bezeichnet. Zu den Upperlevel Ontologien gehören z.b. die Suggested Upper Merged Ontology (SUMO), Ontologie von Russel und Norvig, SOWA- Ontologie, DOLCE und weitere [NL05,6]. Die Ontologien, die ein spezielles Wissensgebiet beschrieben, bezeichnet man als Low-level- oder Domänen- Ontologien. Zu den weiteren Typen gehören Application- (Anwendungs-) oder Task- (Aufgaben-) Ontologien [Stu09,56]. Es gibt eine Vielzahl von Ontologiebeschreibungssprachen. Dazu gehören unter anderem das RDF- Schema, DAML+OIL, F- Logic, die Web Service Modeling Language (WSML) und das von World Wide Web Consortium (W3C) standardisierte Web Ontologie Language (OWL) als Ontologiesprache für das semantische Web [ONT]. Es gibt verschiedene Ontologie-Editoren, mit denen man Ontologien in der Informatik modellieren kann. Neben den kostenpflichtigen Editoren gibt es auch zahlreiche kostenlose, wie zum Beispiel Protégé [PRO] oder Swoop [SWO]. Unsere Ontologie wird mit dem Ontologie- Editor Protégé modelliert Einer der bekanntesten Ontologie-Editoren ist Protégé der Stanford University. Protégé wird als Open- Source Anwendung zur Verfügung gestellt und kann das Wissen mit den Ontologiesprachen wie OWL und RDF modellieren. Die Wissensmodellierung mit formalen Beschreibungssprachen ist in Protégé auf zwei Arten möglich: mit Protégé-Frames und mit Protégé-OWL. Protege-Frames erlaubt frame-basierte Ontologien zu erstellen und basiert auf dem Open Knowledge Base Connectivity protocol (OKBC). Protege-OWL unterstützt OWL (Web Ontology Language) ist ein Standard zur Ontologie-Erstellung unterhalb des Semantic Web [PRO]. Die detaillierten Gründe für den Einsatz von Protégé entnahm ich der Diplomarbeit von Mario Bachman [Bach11, 24-27]. Der Prozess der Ontologie- Modellierung ist iterativ und setzt sich aus mehreren Schritten zusammen. Bis das perfekte Ergebnis erreicht wird, muss das Modell oft mehrmals überarbeitet oder um neue Klassen ergänzt werden. Ein Designprozesses setzt sich aus folgenden Schritten zusammen: 24

25 1. Umfangbestimmung Im ersten Schritt muss geklärt werden, von wem und für was die Ontologie eingesetzt und angewendet wird. Um den Umfang der Ontologie zu bestimmen und zu begrenzen, muss festgelegt werden, welche Aspekte einer Domäne in der Ontologie beschrieben werden sollen und welche nicht. Eine große Hilfe dabei bieten die so genannten Competency Questions. Competency Questions sind Fragen, die man am Anfang zusammenstellt und die am Ende der Modellierung von der Ontologie beantworten werden sollen [Stu09, 161]. Zum Beispiel im Bereich Wein und Essen soll die Ontologie beantworten, welche Weine zu welchen Essen passen. Beispielhafte Fragen wären: Ist ein Dornfelder ein Rotwein oder ein Weißwein? Passt ein Dornfelder zu dunklem Fleisch? Welche Art von Wein passt am besten zu Schweinefleisch? Die Liste der Fragen kann im Laufe der Erstellung um neue Fragen ergänzt oder verkürzt werden. Je mehr Fragen, desto mehr kann der Ontologieumfang eingeschränkt werden. Mit diesen Fragen wird später die Ontologie auf alle gewünschten Informationen geprüft. Wenn sich alle Fragen vollständig beantworten lassen, weist das auf die korrekte Erstellung der Ontologie hin. 2. Wiederverwendung von bestehenden Ontologien Es ist erlaubt existierende Ontologien entweder komplett oder teilweise wieder zu verwenden. Man spart dabei die Erstellungszeit und nutzt den Vorteil, dass die bestehenden Ontologien bereits auf Fehler getestet worden sind. Im Internet stehen viele verschiedene Quellen für die Suche nach Ontologien zur Verfügung. Es existieren Bibliotheken von Ontologien, die es erlauben nach den Begriffen zu suchen, z.b. Ontolingua Ontology Library [OOL] oder DAML Ontology Library [DOL]. Außerdem gibt es spezielle Suchmaschinen, in denen man nach Begriffen der Ontologie im semantischen Web suchen kann. Zum Beispiel Swoogle [SWO] oder Watson [WAT] [Stu09, 164]. 3. Begriffe auflisten In diesem Schritt wird eine Liste aller Begriffe erstellt, die in der Ontologie vorkommen sollen. Diese Therme, die eine Menge von Objekten mit gemeinsamen Eigenschaften beschreiben, sind gute Kandidaten für gesuchte Begriffe. Als Grundlage für die Identifikation 25

26 von Begriffen können die Competency Questions oder andere Informationsquellen wie Datenbanken dienen. Normalerweise werden Substantive verwendet, da diese wahrscheinlich die Begriffe beschreiben. In der Datenbank sind z.b. die Namen der Tabellen und deren Spalten für die Suche nach Begriffen relevant. Außerdem werden alle Eigenschaften aufgelistet, die diese gefundenen Begriffe beschreiben. Viele dieser Eigenschaften sind Verben und stellen eventuell relevante Relationen zwischen den Begriffen dar [Stu09, 165]. 4. Klassenhierarchie Die aufgelisteten Klassen müssen jetzt so angeordnet sein, dass sie ein einheitliches Modell darstellen. Das bedeutet, dass die in einer Hierarchie aus Ober- und Unterklassen angeordnet werden müssen. Es existieren verschiedene Verfahren für diesen Arbeitsschritt. Die Top-Down Methode bestimmt zuerst die allgemeine Klasse im Ontologiebereich und ergänzt das um die direkten Unterklassen. In der Wein-Ontologie wäre Wein die allgemeine Klasse und Rotwein und Weißwein die Unterklassen. Nachdem diese Ebene fertig gestellt wird, wendet man diese Methode rekursiv auf die nächsten Ebenen an. In der Bottom-Up Methode arbeitet man genau in der umgekehrten Richtung. Man sucht die Blätter der Ontologie ab und bildet nach den gemeinsamen Eigenschaften dafür eine Oberklasse. Wie der Top-Down Ansatz, wendet man Bottom-Up rekursiv auf die weiteren Ebenen an. Es besteht auch die Möglichkeit, eine Kombination aus den beiden Methoden zu benutzen. 5. Klasseneigenschaften Die Klassen aus der Klassenhierarchie werden nun um seine Eigenschaften ergänzt. In einer Wein-Ontologie wären z.b. Farbe, Preis, Herkunft oder Hersteller des Weines die Eigenschaften der Klasse Wein. Es ist auch möglich, die gleichen Eigenschaften mehreren Klassen zu zuordnen. Da die Eigenschaften vererbt werden, werden die bei der obersten Klasse eingefügt. Der nächste Schritt ist die Definition und Beschreibung von Relationen. Die Relationen sind Eigenschaften, die zwei Begriffe miteinander verbinden. Beispielsweise wird ein Wein von einem Hersteller hergestellt oder ein Weinregion liegt in einem Land, wobei hergestellt von und liegt in die Relationen darstellen. 6. Klasseneinschränkungen Als Nächstes können die Eigenschaften der Klassen eingeschränkt werden. Kardinalität einer Eigenschaft besagt, wie viele verschiedene Werte diese Eigenschaft 26

27 annehmen kann. Dabei kann es zwischen minimaler Kardinalität mit höchstens einem Wert und maximaler Kardinalität mit beliebig vielen Werten unterschieden werden. Z.B. Ein Wein kann nur von einem Hersteller hergestellt werden (minimale Kardinalität) oder mehrere Weine werden in einer Winzerei hergestellt (maximale Kardinalität). Werte der Eigenschaft sind Werte, welche eine Eigenschaft annehmen darf. Mögliche Wertetypen sind Zeichenfolge (String) z.b. für Namen, Zahlen für Preise oder andere spezifische Werte, wie z.b. um den Geschmack des Weines zu beschrieben. Domain und Range Man kann für die Eigenschaften die Domain und Range festlegen. Die Domain ist die Menge aller Klassen, die diese Eigenschaft anwenden können. Range stellt den Wertebereich für diese Eigenschaft dar. Die Instanzen aus der Domain können mittels Eigenschaft mit den Instanzen aus Range verbunden werden. Zum Beispiel die Eigenschaft hatbelag aus der Pizza-Ontologie verbindet die Klasse Pizza mit der Klasse PizzaBelag. In diesem Fall hat die Eigenschaft hatbelag Klasse Pizza als Domain und Klasse PizzaBelag als Range, woraus man beliebige Beläge kombinieren kann [HO11, 33]. 7. Instanzen Im letzten Schritt der Ontologie- Erstellung müssen die denkbaren Instanzen für Klassen festgelegt werden. Man nimmt eine Klasse und dazugehörigen Eigenschaften und bestimmt dafür die realen Werte. Wir schauen uns die Abbildung 2.3 an und schreiben für die Klasse Bekleidung eine beispielhafte Instanz Jeans. Der Begriff Bekleidung besitzt Eigenschaften Name, Marke, Preis und Größe. Die Instanz Jeans bekommt jetzt Werte für die Eigenschaften: Bluejeans (Name), Diesel (Marke), 100 Euro (Preis) und 38 (Größe). So für alle Klassen erstellten Objekte schließen die Modellierung der Ontologie ab Web Ontologie Language OWL Für diese Diplomarbeit ist die Ontologiesprache OWL relevant und wird als einzige in dieser Arbeit untersucht. OWL ist eine formale Beschreibungssprache zur Erstellung von Web Ontologien. Technisch basiert OWL auf der RDF- Syntax, wobei OWL um zusätzliche Relationen erweitert ist und historisch auf DAML+OIL. Es gibt drei Versionen von OWL, die an die Bedürfnisse von verschiedenen Benutzern angepasst werden: 27

28 OWL Lite als eine einfache Untersprache, OWL DL (Description Logics) als eine eingeschränkte Version von OWL Full, OWL Full als ausdruckstärkste Version von OWL Untersprachen ohne Einschränkungen von OWL DL, wobei für uns die OWL Lite von Bedeutung ist. OWL Lite beinhaltet alle grundlegenden Funktionen von OWL und ist leicht verständlich, jedoch ohne verschiedene Sprachkonstrukte aus OWL DL. Mit der OWL Lite kann der Bau von einfachen Klassifikationshierarchien möglich sein [OWL]. Zu den OWL-Sprachkonstrukten gehören: 1. Klasse (Begriff) wird durch die Tags <owl:class>,<owl:oneof>, <owl:unionof>, <owl:intersectionof> in Verbindung mit dem Attribut rdf:id definiert <owl:class rdf:id= Tier /> 2. Instanzen von OWL-Klasse heißen OWL-Individuen und werden durch den Tag <owl:sameas> definiert, der ermöglicht, dass zwei Individuen unter mehreren Namen bekannt ist, z.b.: < Mensch rdf:id= Student /> <Mensch rdf:id= Rudolf /> <owl:sames rdf:resource= #Student /> </Mensch> 3. Eigenschaften werden durch die Tags <owl:objektproperty>, <owl:dataproperty>, <owl:restriction>, <owl:allvaluesfrom> oder <owl:somevaluesfrom> definiert. <owl:objektproperty> können Domain- und Rangeinformationen enthalten und verbinden Instanzen mit anderen Instanzen. Im Text 2.4 werden die Instanzen der Klasse Person mit der Instanzen der Klasse Geschlecht in Verbindung gebracht. <owl:datatypeproperty> können auch Domain- und Rangeinformationen enthalten, wobei die letzten aus XML Schema Datentypen oder RDF- Literalen bestehen. In der untenstehenden Ontologie werden die Begriffe Geschlecht, Person und Mann beschrieben. Ein Mann ist als eine Unterklasse der Klasse Person definiert und hat für die Eigenschaft Geschlecht den Wert männlich. Die Mitglieder der definierten Klasse Person 28

29 sind die Individuen und lassen sich mit den Namen und Vornamen beschreiben, z.b. die Instanz MKoppe. <rdf:rdf xmlns:rdf=" xmlns:rdfs=" xmlns:owl=" xmlns=" xml:base=" <owl:ontology rdf:about=""/> <owl:class rdf:id="geschlecht"/> <owl:class rdf:id="person"/> <owl:class rdf:id="mann"> <rdfs:subclassof rdf:resource="#person"/> <owl:equivalentclass> <owl:restriction> <owl:onproperty rdf:resource="#geschlecht"/> <owl:hasvalue rdf:resource="#männlich" rdf:type="#geschlecht"/> </owl:restriction> </owl:equivalentclass> </owl:class> <owl:objectproperty rdf:id="geschlecht" rdf:type=" <rdfs:range rdf:resource="#geschlecht"/> <rdfs:domain rdf:resource="#person"/> </owl:objectproperty> <owl:datatypeproperty rdf:id="nachname" rdf:type=" <rdfs:range rdf:resource=" <rdfs:domain rdf:resource="#person"/> </owl:datatypeproperty> <owl:datatypeproperty rdf:id="vorname" rdf:type=" <rdfs:range rdf:resource=" <rdfs:domain rdf:resource="#person"/> </owl:datatypeproperty> <Person rdf:id="mkoppe" firstname="michael" name="koppe"> <Gender rdf:resource="#männlich"/> </Person> </rdf:rdf> Text 2.4: Beispiel einer OWL- Ontologie [OWL] 29

30 2.3.4 Ontologie als Adapter Die Abbildung 2.6 stellt die Schritte dar, die man durchgehen muss, um das Ziel der Arbeit zu erreichen. In der Mitte, zwischen der Datenbank (wie der von OXID) und XML Schema (wie die von UBL-Katalog), soll eine Ontologie, als universal Adapter eingebaut werden. Die Abbildung 2.6: Ziel der Arbeit und die Zwischenschritte Aufgabe der eingebauten Ontologie wäre die Datenbankinformationen eines Online- Shop Systems in Form eines Standardaustauschformates für elektronische Daten in Geschäftsverkehr darzustellen. In diesem Fall handelt es sich um Universal Business Language (UBL), das bereits im Kapitel erklärt wurde. Der Vorteil dieses universalen Adapters wäre deutlich zu sehen, bei Benutzung von mehreren Online Shop Systemen, die in viele verschiedene Austauschformate überführt werden sollen. Angenommen, wir hätten drei Online- Shops Systeme, die auf verschiedenen Datenbanken basieren. Diese Datenbankinformationen möchten wir in drei verschiedene Austauschformate für Geschäftsdokumente überführen. Abbildung 2.7: Arbeitweise der Ontologie 30

31 Würde der Informationsaustausch ohne Ontologie stattfinden, bräuchte man 9 Abbildungen. Jeder Datenbankinhalt müsste jeweils in alle drei Austauschformate abgebildet werden, also insgesamt 3 x 3 Abbildungen. Abbildung 2.8: Anzahl der Informationsabbildungen ohne Einsatz von Ontologie Es gibt eine Vielzahl von vordefinierten Werkzeuge, die man für die Ontologieentwicklung benutzen kann. Diese Werkzeuge wurden entwickelt, um das Wissen zu sammeln, zu strukturieren und wieder verwenden zu können. Ontologien ermöglichen den Austausch von Daten zwischen verschiedenen Systemen. Mit dem Einbau von Ontologie, wären nur 3 Abbildungen nötig. Die Ontologie würde als Adapter die Datenbankinformationen empfangen, speichern und exakt in das gewünschte Austauschformat überführen.. Abbildung 2.9: Anzahl der Informationsabbildungen mit Einsatz von Ontologie 31

32 32

33 Kapitel 3 Konzeption In diesem Kapitel wird zunächst das Ziel dieser Arbeit vorgestellt. Darauffolgend werden in die Schritte und die Strategien zum Umsetzung des Vorhabes dieser Arbeit erläutert und beschrieben. Die Hauptaufgabe besteht darin, die Datenbankinhalte einer relationalen Datenbank in ein vorgegebenes Standardaustauschformat UBL abzubilden. Dieser Informationsaustausch kann direkt zwischen der Datenbank und UBL durchgeführt werden. Da es aber viele verschiedene Austauschformate gibt, müsste diese Informationsabbildung jeweils in das gewünschte Format neu überführt werden, was Kosten- und Zeitaufwendig wäre. Als eine Lösung für dieses Problem bietet sich, wie im Kapitel bereits dargestellt wurde, eine Einbindung der Ontologie als Adapter. Der Vorteil der Einbindung der Ontologie zwischen der OXID-Datenbank und dem UBL-Dokument wäre besonders beim Betreiben von mehreren Online Shop Systemen vorteilhaft. Die Datenbankinformationen würden zuerst auf die Ontologie abgebildet und in dieser gespeichert werden. Die gespeicherten Daten könnten anschließend unproblematisch in das gewollte Austauschformat überführt werden. Die Realisierung dieses Zieles setzt sich aus mehreren Arbeitsschritten zusammen, die jeweils mit Hilfe von geeigneten Techniken erreicht werden können. Am Ende der Diplomarbeit sollen die Datenbankinformationen aus der Shop-Datenbank in Form des oben genannten Standardaustauschformates für Geschäftsdokumente ausgegeben werden. Die folgende Abbildung 3.1 stellt die einzelnen Arbeitsschritte in der nummerierten Reihenfolge dar. Abbildung 3.1: Arbeitsschritte für die Umsetzung des Ziels der Diplomarbeit 33

34 Die Arbeitsschritte werden in der Reihenfolge 1, 2 und 3 abgearbeitet, da diese dem Vorgehen meiner Diplomarbeit entspricht. In den folgenden Abschnitten werden diese 3 abgebildeten Punkte und die dazugehöringen Techniken kurz erläutert. Eine detailllierte Beschreibung zu den oben genannten Punkten wird in den Kapiteln 4, 5 uns 6 presäntiert. 3.1 Modellierung der Ontologie. Das Ziel des 1. Schrittes der Abbildung 3.1 ist es eine Ontologie zu erstellen. Mit Hilfe von Ontologien können Informationen gesammelt und zwischen verschiedenen Systemen ausgetauscht werden. Die Konstruktion und das Editieren einer Ontologie erfolgt mit einem Ontologie-Editor. Es existieren viele verschiedene Ontologie-Editoren, die die Erstellung und Visualisierung von Ontologien unterstützen. Zu den bekannten quellfreien und kostenlosen Ontologie-Editoren gehören u.a. Protégé und Swoop [SWE]. Für unsere Ontologiemodellierung nutzen wird den kostenlosen Editor Protégé. Protégé wird zurzeit weltweit am häufigsten eingesetzt und ist leicht und intuitiv zu benutzen. Durch den Bekanntheitsgrad, gibt es eine große Community, die bei Problemen Unterstützung bietet und viele Beispiele zur Verfügung stellt. Die detaillierten Gründe für den Einsatz und Beschreibung von Protégé entnahm ich der Diplomarbeit von Mario Bachman [Bach11, 24-27]. In dieser Diplomarbeit soll die Ontologie die Rolle des Adapters zwischen zwei veschiedenen Strukturen: der OXID-Datenbank und dem UBL-Katalog übernehmen. Als Grundlage für die Ontologieerstellung dienen die gemeinsamen Felder der OXID-Datenbank und des UBL- Kataloges. Um diese gemeinsame Schnittmenge zu bestimmen, müssen zuerst alle Pflichtfelder sowohl in der OXID Datenbank als auch im UBL-Katalog festgelegt werden. Bei den gemeinsamen Feldern handelt es sich um Lieferanten-, Kunden- und Produktinformationen. Im Kapitel 4.1 wird die Struktur und somit die notwendigen Elemente der OXID-Datenbank genauer betrachtet und erläutert. Die erforderlichen Elemente des UBL- Kataloges wurden bereits in den Grundlagen (Kapitel ) festgelegt und beschrieben. Mit den erforderlichen Informationen kann die Modellierung der Ontologie erfolgen, die detailliert im Kapitel 5 erklärt wird. Die Informationen, die zwar im UBL-Katalog aber nicht in der OXID-Datenbank vorhanden sind, müssen mittels eines geeigneten Werkzeugs zu der Ontologie eingefügt werden. Es handelt sich dabei um Elemente ID und das IssueDate 34

35 (Ausstelldatum) des Kataloges. Dieser Schritt wird kurz im Kapitel 3.3 und deteilliert im Kapitel 6 erläutert. 3.2 Mapping zwischen Datenbank und Ontologie. Der 2. Schritt der Abbildung 3.1 beschreibt das Mapping zwischen OXID- Datenbank und der Ontologie, deren Erstellung und deteillierte Beschreibung im Kapitel 4 erfolgen wird. Das Mapping wird mit einem Softwarewerkzeug Integration with Ontologies, kurz IwOnto, realisiert, das im Rahmen der Diplomarbeit von Mario Bachman implementiert wurde [Bach11]. Die DBIS-Professur hat mir das Werkzeug vorgegeben und zur Verfügung gestellt. IwOnto ist ein Programm, das einerseits eine relationale Datenbank und andererseits eine Ontologie voraussetzt, um das Mapping erfolgreich durchzuführen. Es handelt sich dabei um eine relationale Datenbank und ihre Relationen (Tabellen) und eine Ontologie mit dazugehörigen Objektklassen. Das Mapping erfolgt manuell und schrittweise, was bedeutet, dass jede Objektklasse der Ontologie auf jede Join-Tabelle der Datenbank getrennt gemappt wird. Die eigentliche Abbildung wird zwischen den Eigenschaften der Objektklasse und den Attributfeldern der angesprochenen Tabellen dürchgeführt. Vor dem Mapping enthält die im Kapitel 4 modellierte Ontologie nur die Objekte, die als Beispiel definiert wurden. Nach der erfolgreichen Anwendung von IwOnto zwischen der OXID-Datenbank und der Ontologie, soll die Ontologie mit den Informationen aus dieser Datenbank gefüllt sein. Eine detaillierte Beschreibung des Mappings zwischen der OXID- Datenbank und der Ontologie erfolgt im Kapitel Mapping zwischen Ontologie und XML. Der Inhalt vom Kapitel 6 beschreibt wie die Ontologie auf das XML-basierte UBL- Dokument abzubilden ist. Zuerst muss ein geeignetes Werkzeug gefunden werden. Nach erfolglosen Suchen und Testen von verschiedenen Werkzeugen, habe ich mich für das Implementieren eines eigenen Programmes entschieden. Als Input für das Programm wird die Ontologie verwendet, die im Kapitel 4 erstellt und im Kapitel 5 mit den Datenbankinformationen gefüllt wurde. Mittels dieses Programms sollen die Ontologieinformationen in einen XML-basierte UBL-Katalog überführt werden, der als Output des Programms erwartet wird. Um die Ontologie bearbeiten zu können muss diese zuerst geladen werden. Im nächsten Schritt werden die zugehörigen Inhalte ausgelesen und in ein neu erzeugtes XML-Dokument 35

36 geschrieben. Die Ontologieinhalte müssen so bearbeitet werden, dass das XML-Dokument in einem validen Format vom UBL-Katalog ausgegeben und abgespeichert wird. Für die Implementierung des Programmes muss eine kompatible Programmiersprache und Entwicklungsumgebung gewählt werden. Im Kapitel 5 wurde für das Mapping das von Mario Bachman entwickelte Werkzeug IwOnto benutzt. Da er in seiner Diplomarbeit [Bach11] eine ausführliche Erklärung für die Auswahl der Programmiersprache und der Entwicklungsumgebung gegeben hat, entnehme ich diese Entscheidungen dieser Arbeit und benutze Java und Eclipse für mein Konsolenprogramm. Für das Erzeugen, Manipulieren und Laden von OWL Ontologien eignet sich unter anderem die Java-basierte, frei-verfügbare, open-source Programmierschnittstelle OWL API. Mit dieser Begründung wurde für die Implementierung von IwOnto die objektorientierte Programmiersprache Java verwendet. [Bach11, 78]. Als geeignete Programmumgebungen zur Entwicklung von Java Programmen kamen Eclipse SDK [ECL] und NetBeans IDE [NB] in Frage. Die Entscheidungsgründe wurden in Mario Bachmans Diplomarbeit aufgelistet [Bach11, 84]. Das zu entwickelnde Programm wird kein GUI-Programm sein, sondern ein Konsolenprogramm. Aus Zeitmangel wird keine grafische Oberfläche für dieses Programm entwickelt. Das bedeutet, dass die Kommunikation mit dem Anwender nicht wie bei IwOnto über eine grafische Benutzeroberfläche erfolgen wird, sondern über eine Konsole. Um in meinem Konsolenprogramm eine Ontologie laden und bearbeiten sowie ein XML- Dokument erstellen zu können werden Pakete und Klassen aus folgenden Bibliotheken importiert: OWL API unterstützt das Erzeugen, das Laden und das Manipulieren von OWL Ontologien. Java API for XML Parsing (JAXP) erlaubt unter Java auf XML zu zugreifen. JAXP umfasst unter anderem die im Programm verwendete Schnittstelle DOM (Document Objekt Model). DOM-API hat folgende Funktionalitäten: -Erzeugen und Verarbeiten von XML-Dokumenten -Zugriff auf XML-Dokumente -Darstellen von XML-Dokumenten in einer Baustruktur 36

37 Eine ausführliche Beschreibung der Implementierung findet im Kapitel 6 statt. Es werden dort die einzelnen Schritte angefangen beim Programmaufruf bis hin zu der Ausgabe des UBL- Katalogs erläutert. 37

38 38

39 Kapitel 4 Erstellung der Ontologie In deisem Kapitel wird die Erstellung einer Ontologie beschrieben. Die Modellierung erfolgt mit dem kostenlosen und quellfreien Ontologie-Editor Protégé, was bereits im Abschnitt 3.1 des Kapitels Konzepion begründet wurde. Mit Hilfe von Ontologien können Informationen gesammelt und zwischen verschiedenen Systemen ausgetauscht werden. In dieser Diplomarbeit soll die Ontologie die Informationen aus der OXID- Datenbank aufnehmen und in Form eines vorgegebenen Standardaustauschformates UBL-Katalog ausgeben. Die Ontologie als Adapters wird sich aus der gemeinsamen Schnittmenge der Pflichtelemente der OXID-Datenbank und des UBL- Kataloges zusammensetzen. Um diese Menge zu bestimmen, müssen zuerst alle Pflichtfelder sowohl in der OXID Datenbank als auch im UBL-Katalog gefunden und aufgelistet werden. Die Elemente, die im UBL-Katalog als Pflichtfelder aufgelistet wurden aber nicht in der OXID-Datenbank vorhanden sind, müssen mittels eines geeigneten Werkzeugs zu der Ontologie eingefügt werden. Im ersten Abschnitt wird die Struktur der OXID- Datenbank auf deren Pflichtelemente untersucht. Die notwendigen Elemente für den UBL-Katalog wurden bereits in der Tabelle 2.1 in Kapitel aufgelistet. Anschließend wird die Erstellung der Ontologie vorbereitet, durchgeführt und deteilliert beschrieben. 4.1 Struktur der OXID- Datenbank In diesem Abschnitt wird die Struktur der OXID- Datenbank analysiert und geprüft, welche Daten in der enthalten sind. Wie in der Abbildung 4.1 zu erkennen ist, speichert OXID die Daten in den 63 Tabellen. Die einzelnen Tabellen enthalten wiederum verschiedene Anzahl von Attributfeldern, z.b. ein Ausschnitt der Struktur der Tabelle oxarticles, der in der Abbildung 4.2 dargestellt wird. Alle Daten und die Beziehungen zueinander werden in dem OXID-Datenbank-Schema dargestellt. Die veschiedenen Versionen von Datenbank-Schema findet man auf der Seite von OXID eshop [OCE]. Die aktuelleste Version befindet sich im Anhang B. 39

40 Abbildung 4.1: Ausschnitt aus der OXID-Datenbank Wir betrachten die Daten bzw. die Tabellen aus der DB, die für die Beschreibung eines Artikels notwendig sind. Auf der UBL-Seite suchen wir die Daten aus, die für einen UBL- Katalog erforderlich sind. Die notwendigen Elemente für den UBL-Katalog wurden bereits in der Tabelle 2.1 in Kapitel aufgelistet. Abbildung 4.2: Ausschnitt aus der OXID- Datenbank: Attributfelder der Tabelle oxarticles Zu den Anforderungsfeldern der OXID-Datenbank gehören Tabellen: -oxarticles: Informationen über Artikel, z.b. Artikelnummer, Artikelname, Preis, Verfügbarkeit und andere 40

41 -oxattribute: Modell, Größe, Farbe, Marke, -oxmanufactures: Hersteller -oxshops: Lieferanteninformationen -oxusers: Kundeninformationen Die folgende Abbildung 4.3 stellt die Pflichtfelder in der OXID- Datenbank grafisch dar. Diese sollten auf jeden Fall im UBL-Katalog enthalten sein. Abbildung 4.3: Für einen Artikel verbindlichen Informationen 4.2 Modellierung der Ontologie Vorbereitung Im Kapitel wurden in der Tabelle 2.1 die Pflichtelemente eines UBL-Kataloges und deren Typen aufgelistet. Die Informationselemente ASBIE setzen sich aus weiteren Pflichtund nicht-pflicht-elementen zusammen. Die Aufgabe besteht darin, alle relevanten Artikelinformationen und Elemente sowohl in der OXID Datenbank als auch im UBL- Katalog zu finden. Im UBL-Katalog findet man Informationen zu den Artikeln, z.b. Name, Artikelnummer, Preis und andere im Element CataloqueLine unter folgendem Pfad: Element Catalogue/CatalogueLine/Item [UBC]. Diese Informationen müssen auch in der OXID- 41

42 Datenbank vorhanden sein. Der Umfang des Kataloges kann nach Bedarf beliebig um weitere Elemente ausgebaut werden. Nachdem die Pflichtfelder von OXID- Datenbank und UBL-Katalog gefunden und aufgelistet wurden, muss jetzt für deren gemeinsame Schnittmenge eine Ontologie erstellt werden. Die Elemente, die im UBL-Katalog enthalten sein sollten, die aber nicht in der OXID- Datenbank vorhanden sind, müssen mittels eines Werkzeugs zu der Ontologie eingefügt werden. Es handelt sich dabei um Elemente ID und das Ausstelldatum (IssueDate) des Kataloges. Erst dann kann der UBL-Katalog mit allen notwendigen Informationen ausgegeben werden. Diese Vorgehensweise wird in der Abbildung 4.4 dargestellt. Jedes neu erstellte Katalogdokument muss eindeutig identifiziert werden und bekommt eine ID- Nummer und wird um das Erstelldatum (Element IssueDate) ergänzt. Abbildung 4.4: Zusammensetzung der notwendigen Elemente für einen UBL-Katalog Modellierungsprozess Bei unserer Ontologie handelt es sich um eine Ontologie mit der allgemeinen Klasse Produkte, damit sie von jedem Online Shop-System mit beliebigen Produkten angewendet werden kann. Die Erstellung der Ontologie erfolgt im Protege-OWL Editor. Die Abbildung 4.5 zeigt das User-Interface von Protege-OWL. Standardmässig sind folgende Tabs geöffnet: Entities, Classes, Object Properties, Data Properties, Individuals. Hier ist der OWLClasses Tab ausgewählt. Es ist möglich weitere Tabs zu öffnen, um zum Beispiel die Ontologie in Form eines Graphen anzuschauen. Dazu nutzt man ein Protege Plugin OWLViz. Wir nennen unsere Ontologie die Produkt-Ontologie, da darin der Prozess der Bestellung und Lieferung der Produkte abgebildet wird. 42

43 Ontologie-Klassen. Die leere Ontologie enthält am Anfang nur eine vordefinierte Klasse owl:thing. Abbildung 4.5: User-Interface von Protege-OWL Im ersten Schritt müssen Klassen der Produkt-Ontologie angelegt werden. Es werden die Klassen Produkt, Kunde und Lieferant angelegt, wobei die Klasse Produkt die Unterklasse Krankenhaus-Produkt (KH-Produkt) besitzt. Das Ergebnis nach der Erstellung der Klassen ist in der Abbildung 4.6 zu sehen. 43

44 Abbildung 4.6: Angelegte Klassen der Produkt-Ontologie Der untenstehende Text 4.1 zeigt einen Ausschnitt der Ontologie mit angelegten Klassen im RDF/XML- Syntax. /////////////////////////////////////////////////////////////////////////////////////// // // Classes // /////////////////////////////////////////////////////////////////////////////////////// --> <! > <owl:class rdf:about=" <rdfs:subclassof rdf:resource="&owl;thing"/> </owl:class> <! > <owl:class rdf:about=" <rdfs:subclassof rdf:resource="&owl;thing"/> </owl:class> <! > <owl:class rdf:about=" <rdfs:subclassof rdf:resource="&owl;thing"/></owl:class> <! > <owl:class rdf:about=" <rdfs:subclassof rdf:resource=" </owl:class> Text 4.1: Quellcode-Ausschnitt der Produkt-Ontologie: Klassen Klassen-Eigenschaften. Um die Klassen weiter benutzen zu können, müssen sie jetzt mit Eigenschaften beschrieben werden. Man benutzt dafür hauptsächlich zwei Arten von Eigenschaften: Object Properties und Data Properties. Jede Klasse darf beide Arten der Eigenschaften haben. Die erste Schwierigkeit bei der Erstellung der Ontologie stellt sich jetzt heraus. Es ist für eine Person, die eine Ontologie zum ersten Mal erstellt nicht sofort klar, ob 44

45 die Eigenschaften einer Klasse zu ObjectProperties oder zu DataProperties gehören. Ich habe meine Ontologie mehrmals umgeändert, bevor ich die Eigenschaften richtig zugeordnet habe. Object Properties beschreiben eine Relation zwischen zwei Individuen. Zum Beispiel ein Individuum X aus der Klasse Lieferant liefert das Individuum Y aus der Klasse Produkt, wobei liefert das Object Property ist. Die Abbildung 4.7 zeigt ein Ausschnitt mit den Object Properties der Ontologie. Es muss für jede Eigenschaft die Domain und Range festgelegt werden. Die Domain ist die Menge aller Klassen, die diese Eigenschaft anwenden können. Range stellt den Wertebereich für diese Eigenschaft dar. Ausgewähle Eigenschaft liefert hat die Klasse Lieferant als die Domain, und Klasse Produkt als Range, da Lieferant liefert das Produkt Abbildung 4.7: Ausschnitt aus der Produkt- Ontologie: Object Properties Die Objekt-Eigenschaften dürfen Inverse-Eigenschaften haben. Inverse-Eigenschaften haben die Domain und Range umgekehrt als die Objekt Eigenschaft. Beispielweise hat die Eigenschaft geliefert_von als Domain die Klasse Produkt und als Range die Klasse Lieferant. 45

46 Auf diese Weise geht man auch bei den anderen Eigenschaften vor. Eine Liste der Object Properties der Produkt-Ontologie findet man im Anhang A. Data Properties sind Eigenschaften eines Individuums und nehmen einen konkreten Wert eines bestimmten Datentyps an. Beispielweise hat das Individuum aus der Klasse Produkt die Eigenschaft hatproduktname, die mit einem Wert belegt werden muss. Man legt wie bei Object Property die Domain der Eigenschaft fest, damit die einer oder mehreren Klassen zugeordnet werden kann. Als Range wählt man einen Datentypen aus, also den Wertebereich für die Individuen der Klasse. Die folgende Abbildung 4.8 zeigt die Data Eigenschaften der Klasse Kunde. Die ausgewählte Eigenschaft hatkundenname hat die Klasse Kunde als Domain und als Range den Datentyp string. Abbildung 4.8: Ausschnitt aus der Produkt- Ontologie: Data Properties der Klasse Kunde Die Vorgehensweise wird für die weiteren Eigenschaften der Klasse Kunde und den ausgeblendeten Eigenschaften der Klassen Lieferant und Produkt angewendet. Eine Liste mit den Data Poperties der Klasse Kunde findet man im Anhang A. Individuen. Nachdem die Klassen und deren Eigenschaften definiert wurden, müssen jetzt Individuen angelegt werden. In der Abbildung 4.9 wurde für die Klasse Lieferant ein Objekt definiert: Aluras_Shop. Man kann beliebig viele Objekte hinzufügen oder auch löschen. 46

47 Weiter rechts in der Abbildung in Description: Aluras_Shop wird die Klasse ausgewählt, zu der das Individuum Aluras_Shop gehört. In der rechten Spalte der Abbildung befinden sich alle Eigenschaften der Klasse Lieferant, die jetzt bestimmte Werte für das Objekt Aluras_Shop angenommen haben. Genauso legt man jetzt Objekte für die Klasse Kunde und die Klasse Produkt und deren Belegungswerte für die Eigenschaften an. Damit ist unsere Produkt-Ontologie fertig erstellt. Man hat die Möglichkeit die Ontologie in verschiedenen Syntaxen abzuspeichern. Wir speichern unsere Ontologie im RDF/XML-Syntax ab. Abbildung 3.9: Ausschnitt aus der Produkt- Ontologie: Individuen und deren Werte der Klasse Lieferant Der Text 4.2 auf der nächsten Seite zeigt einen Ausschnitt der Ontologie mit angelegtem Individuum der Klasse Lieferant im RDF/XML- Syntax. 47

48 /////////////////////////////////////////////////////////////////////////////////////// // // Individuals // /////////////////////////////////////////////////////////////////////////////////////// --> <! > <owl:namedindividual rdf:about=" <rdf:type rdf:resource=" <hatlieferantenplz rdf:datatype="&xsd;string">60386</hatlieferantenplz> <hatlieferantenshopname rdf:datatype="&xsd;string">aluras Shop</hatLieferantenShopName> <hatlieferantenstaatid rdf:datatype="&xsd;string">de</hatlieferantenstaatid> <hatlieferantenuid rdf:datatype="&xsd;string">de </hatlieferantenuid> <hatlieferantenstadt rdf:datatype="&xsd;string">frankfurt</hatlieferantenstadt> <hatlieferantenstrasse rdf:datatype="&xsd;string">vatterstrasse</hatlieferantenstrasse> <liefert rdf:resource=" <liefert_an rdf:resource=" </owl:namedindividual> Text 4.2: Quellcode-Ausschnitt der Produkt-Ontologie: Individuum Aluras_Shop mit Eigenschaften 48

49 Kapitel 5 Mapping von einer Datenbank auf eine Ontologie Das Kapitel 5 beschreibt das Mapping der OXID- Datenbank auf die Ontologie. Für die Durchführung dieser Aufgabe eignet sich ein Mapping-Werkzeug Integration with Ontologies, kurz IwOnto [IWO], das im Rahmen der Diplomarbeit von Mario Bachman entwickelt wurde. Dieses Werkzeug wurde mir von der DBIS- Professur vorgegeben und zur Verfügung gestellt. Abbildung 5.1: Mapping zwischen OXID-Datenbank und der Produkt-Ontologie Das Mapping findet zwischen Schemata der Quellstruktur und Schemata der Zielstruktur statt. Eine relationale Datenbank OXID und ihre Relationen (Tabellen) dienen hier als Quelle und die Ontologie mit ihren Objektklassen als Ziel der Abbildung. Das Mapping erfolgt manuell und schrittweise, was bedeutet, dass jede Individuenklasse der Ontologie auf jede Join-Tabelle der Datenbank getrennt gemappt wird. Ich nutze im Mapping die Ontologie, die bereits im Kapitel 4 mit Ontologie-Editor Protege erstellt wurde. Als Resultat dieser Abbildung soll die Ontologie mit den Instanzen aus der Datenbank befühlt sein. Die Abbildung 5.1 zeigt die Lösung für das Mapping zwischen Datenbank und Ontologie. 5.1 Umwandlung der OXID- Datenbank in eine Ontologie Das Mapping setzt sich aus mehreren Schritten zusammen. Folgend werden die 4 Schritte ausführlich erläutert. 1. Das Starten vom Program IwOnto. 49

50 Nach dem Ausführen von iwonto.jar- Datei öffnet sich ein Hauptfenster (Abbildung 5.2), in dem wir unsere Produkt- Ontologie laden und die Verbindung zu der oxid-datenbank aufbauen können. Abbildung 5.2: Anmeldemaske von IwOnto Beim erfolgreichen Laden bzw. Datenbankverbindung, gelangt man beim Wählen von Mapping-Fenster - Knopf zum nächsten Schritt: dem eigentlichen Mapping-Fenster. 2. Auflistung aller Ontologieklassen und der nötigen Tabellenattribute im Mapping Fenster Die Abbildung 5.3 zeigt in der linken Spalte die Produkt-Ontologie mit Objektklassen in der Form eines Klassenbaumes sowie Klassen-Eigenschaften. Es werden jeweils die Eigenschaften der ausgewählten Klasse angezeigt. Zuerst wird die Klasse Produkt ausgewählt. Die rechte Spalte mit Datenbanküberschrift zeigt ein Angabefenster, in dem man SQL-Anfrage an die OXID-Datenbank stellen kann. Man wählt nur diese Tabellen aus der Datenbank aus, in denen sich die Mapping-Kandidaten für die Eigenschaften der Klasse befinden und bildet daraus eine Join-Tabelle. Für die Klasse Produkt bildet man einen Join aus den Tabellen oxarticles und oxmanufacturers, da dort sich die passenden Mapping- Kandidaten befinden. Als Ergebnis der SQL-Anfrage bekommen wir die Attribute der angesprochenen Tabellen, die im unteren Fenster Attribute des Join-Table geladen wurden. 50

51 Abbildung 5.3: Mapping-Fenster der Produkt-Ontologie und oxiddb 3. Auswahl der passenden Mapping-Kandidaten Das eigentliche Mapping wird zwischen den Eigenschaften der Objektklasse und den Attributfeldern der angesprochenen Tabellen dürchgeführt. Wie in der Abbildung 5.4 zu sehen ist, werden sowohl Object Properties als auch Data Properties der Klasse Produkt gemappt. Man wählt ein Data Property aus und sucht auf der Datenbank-Seite ein passendes Attribut. Beide haben einen Datentyp. Mit diesem Schritt hatte ich meine Schwierigkeiten, da sich nicht alle Data Properties sich auf Attribute sofort mappen liessen. Ich habe in meiner Ontologie die Datentypen von Data Properties mehrmals ändern müssen, um zu sehen, welche Kombinationen von Datentypen kompatibel sind. 51

52 Abbildung 5.4 Das Mapping zwischen Attributen der Objektklasse und Attributfeldern der Tabellen Erst wenn die beiden Typen der Mapping-Kandidaten kompatibel sind (<-kompatibel-> leuchtet grün in der Abbildung 5.4), dürfen diese gemappt werden und erscheinen im Ergebnisfenster (Abbildung 5.5). Abbildung 5.5: Das Mapping-Ergebnisfenster 52