Auf dem Weg zur Integration Factory

Transkript

1 Auf dem Weg zur Integration Factory

2 Joachim Schelp Robert Winter Herausgeber Auf dem Weg zur Integration Factory Proceedings der DW2004 ± Data Warehousing und EAI Mit 166 Abbildungen und 24 Tabellen Physica-Verlag Ein Unternehmen von Springer

3 Dr. Joachim Schelp Prof. Dr. Robert Winter Universitåt St. Gallen Institut fçr Wirtschaftsinformatik Mçller-Friedberg-Strasse 8 CH-9000 St. Gallen ISBN Physica-Verlag Heidelberg Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet çber < abrufbar. Dieses Werk ist urheberrechtlich geschçtzt. Die dadurch begrçndeten Rechte, insbesondere die der Ûbersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfåltigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfåltigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulåssig. Sie ist grundsåtzlich vergçtungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Physica-Verlag ist ein Unternehmen von Springer Science+Business Media GmbH springer.de Physica-Verlag Heidelberg 2005 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wåren und daher von jedermann benutzt werden dçrften. Umschlaggestaltung: Erich Kirchner, Heidelberg SPIN /3130/DK ± Gedruckt auf såurefreiem Papier

4 Vorwort und Einführung Das Motto Auf dem Weg zur Integration Factory rückt den Aspekt der hochintegrierten Informationslogistik in den Vordergrund, der sich bei den beiden Vorgängerkonferenzen DW2000 und DW2002 schon abgezeichnet hat. Operative und analytische Informationssysteme miteinander zu verknüpfen ist die Voraussetzung für weiterreichende Konzepte zur besseren Unterstützung der Geschäftsprozesse im Unternehmen. Aktuelle Diskussionen wie z.b. um die Optimierung (im Sinne einer Verbesserung) der innerbetrieblichen wie der unternehmensübergreifenden Prozesse können ohne eine zuvor erfolgte Integration dieser Bereiche nur selten sinnvoll verwirklicht werden. Angesichts der sich ständig verändernden betrieblichen Applikationslandschaft ist eine einmalige Integrationsanstrengung aber nicht ausreichend. Integration ist Daueraufgabe. Die permanente, evolutionäre Weiterentwicklung der Applikationslandschaft stellt hohe Anforderungen sowohl an die Organisation/IT wie an das methodische Rüstzeug. Vor dem Hintergrund dieser Überlegungen wurde zu Beiträgen für die dritte DW-Konferenz aufgerufen, welche den Stand der Forschung und Praxis im anwendungsorientierten Bereich der analyseorientierten Integration (Data Warehousing), der operativen Integration (Enterprise Application Integration und Enterprise Architecture) sowie der Schnittstelle zwischen diesen Bereichen aufzeigen soll. Die in diesem Buch zusammengefassten wissenschaftlichen Beiträge und Praxisberichte wurden anlässlich der Tagung DW2004 Data Warehousing und EAI: Auf dem Weg zur Integration Factory am 3. und 4. November 2004 verfasst und im Graf-Zepplin-Haus in Friedrichshafen präsentiert. Die Beiträge wurden für dieses Buch jedoch nicht in der Reihenfolge zusammengestellt, wie sie auf der Konferenz präsentiert wurden. So wird z.b. hier die Trennung in Data Warehousing einerseits und Enterprise Application Integration andererseits aufgebrochen, so dass die Schnittstellen der Themenbereiche miteinander besser deutlich werden. Den Auftakt bildet der eingeladene Beitrag Modelle für Semantische Web-Anwendungen von Neuhold/Fuchs/Niederée. Dieser thematisiert über die aktuell dominierende innerbetriebliche Integrationsdiskussion weit hinausgehend diejenigen Aspekte, welche künftig im Kontext des Semantic Web die neuen Integrationsherausforderungen darstellen werden. Der erste Teil der aufgrund des Begutachtungsprozesses angenommenen Beiträge setzt sich mit strategischen Fragestellungen auseinander, die sich im Kontext der integrierten Informationslogistik stellen. Den Einstieg bildet der Beitrag von Schrön/Hafner, der die Integration des Prozessmanagements in eine zukunftsorientierte CIO-Organisation am Beispiel von Siemens ICN thematisiert. Danach wird mit dem Beitrag von Aier eine betriebswirtschaftlich motivierte Diskussion um EAI und Nachhaltigkeit von Architekturen Ergebnisse einer empirischen Studie geführt. Ökonomische Aspekte stehen auch beim Beitrag von

5 VI Vorwort Wegener Die Wertschöpfung des Metadatenmanagements für Unternehmen der Finanzindustrie im Vordergrund. Einen weiteren für die IT-Strategie wichtigen Aspekt behandelt der Beitrag Outsourcing und Offshoring von Business Intelligence-Lösungen Empirische Studie und Praxiserfahrung von Phillipi. Der zweite Teil fasst die Beiträge zusammen, die sich mit einzelnen Gestaltungsaspekten auseinandersetzen. Den Einstieg bieten Tiedemann/Wittig/Rougier mit Die Gestaltung einer unternehmensweiten Software-Architektur auf Basis eines selbst entwickelten Zonen- und Schichten-Modells. Diese Architekturdiskussion wird von Schwinn mit dem Beitrag Entwurfsmuster für die Applikationsintegration fortgeführt. Den Perspektivenwechsel auf Data Warehouse-Systeme vollzieht Brobst mit dem Beitrag Twelve Mistakes to Avoid When Constructing a Real-Time Data Warehouse. Dieser Fokus wird von Goeken mit dem Beitrag Anforderungsmanagement bei der Entwicklung von Data-Warehouse-Systemen Ein sichtenspezifischer Ansatz fortgeführt. Speziell auf ETL-Fragestellungen geht Nonhebel mit dem Beitrag Lösungsansätze aus Data Warehouse-Projekten ein. Schliesslich geben Bange/Schwalm mit ihrem Beitrag XML-Einsatz in Business- Intelligence-Systemen Eine systematische Übersicht einen Ausblick auf nicht nur für Data Warehouse-Systeme relevante Technologien, die bei der weiteren Gestaltung berücksichtigt werden sollten. Im dritten Teil werden neue Umsetzungsszenarien entworfen. Den Anfang machen hier Hahne/Burow/Elvers mit dem Beitrag XML-Datenimport in das SAP Business Information Warehouse bei Bayer MaterialScience. Becker/Serries/ Knackstedt zeigen mit ihrem Beitrag OLAP-Techniken aus Sicht der industriellen Auftragsabwicklung auf, welchen Beitrag OLAP und damit Data Warehousing im Produktionsmanagement leisten können. Stolba/List weisen mit Extending the Data Warehouse with Company External Data from Competitors Websites A Case Study in the Banking Sector auf die Möglichkeiten hin, auch externe Daten in ein Data Warehouse einzubinden. Dieser Aspekt steht auch im Mittelpunkt des Beitrags von Felden, der mit Data Distribution with a Market Data Information System den Schwerpunkt auf Aspekte der verteilten Datenhaltung solcher Systeme legt. Die EAI-Sicht bringen Kupsch/Werth mit ihrem Beitrag Einsatz von Peer-to-Peer-Technologie zur betriebswirtschaftlichen und IT-technischen Unterstützung von EAI-Projekten ein. Praxisberichte, die eine Verbesserung der Prozessunterstützung durch Integrationsprojekte aufzeigen, bilden den vierten Teil dieses Buches. Den Einstieg bieten hier Holten/Laumann mit Integrating Management Views in Supply Chain Environments An arvato (Bertelsmann) Business Case. Einen noch stärkeren Fokus auf die Unterstützung der Geschäftsprozesse legt Grimm mit seinem Beitrag Integrierte Prozesse mit Prozessportalen. Mit dem Fokus auf EAI-Aspekte berichten Kreutzberg/Proft über Planung und Einsatz von EAI am Beispiel eines Projekts in der Wertpapierabwicklung einer Geschäftsbank. Schliesslich zeigen Jarkovich/Böhnlein mit DWH und EAI im Integration Layer der Bank Julius Bär

6 Vorwort VII Architektur, Anwendungen und Erfahrungen ein gelungenes Beispiel für die kombinierte Betrachtung analyseorientierter und operativer Integration auf. Schliesslich werden im fünften Teil die Praxisberichte zusammengefasst, welche Erfahrungen im Bereich der analyseorientierten Integration wiedergeben. Den Auftakt bilden hier Bauer/Böhnlein/Eckert/Lederer/Munsi mit Einsatz eines Data Warehouse im egovernment-bereich zur Asylsteuerung und Migrationsanalyse. Eicker/Lambertz/Lelke eröffnen im folgenden Beitrag mit ihrer Analyse eines SAP BW-Einsatzes im Controlling am Beispiel der T-Com die industriespezifischen DW-Implementierungen. Die darauffolgenden Beiträge gehen verstärkt auf den Finanzdienstleistungssektor ein. Brändli/Mügeli/Maier/Winter/Klesse/Herrmann berichten in ihrem Beitrag über Customer Investigation Process at Credit Suisse: Meeting the Rising Demand of Regulators. Birkenbach/Kramer zeigen im Anschluss in ihrem Beitrag den Integrationsbedarf einer bankspezifischen Deckungsbeitragsrechnung auf. Den Branchenfokus beschliessen Gehra/ Gentsch/Hess mit dem Beitrag Analytisches Investor Relationship Management Ein innovatives Anwendungsfeld für Data Mining Technologien untersucht am Beispiel der AMP Ltd.. Tagungen und auch Bücher sind immer das Ergebnis eines ideell motivierten Engagements, für das die Herausgeber insbesondere den Mitgliedern des Programmkomitees, die alle eingegangenen Beiträge begutachteten und teilweise auch Sitzungen der Tagung leiteten, sowie den Autoren und Referenten herzlich danken. Ein besonderer Dank gilt auch den Hauptsponsoren IBM, SAS und Sybase sowie allen weiteren Sponsoren, die mit ihrer finanziellen Beteiligung die wirtschaftliche Durchführung dieser Fachtagung ermöglicht haben. Einen ganz wesentlichen Baustein des Erfolgs einer Tagung bilden natürlich die Teilnehmer, die durch ihre Anwesenheit und Diskussionsbereitschaft den Austausch von Wissen und Erfahrungen erst möglich machen. Unser herzlicher Dank gebührt insbesondere den Personen, die an der Organisation der Tagung sowie an der Erstellung dieses Buches unmittelbar mitgewirkt haben. Zu erwähnen sind unsere wissenschaftlichen Mitarbeiter Martin Hafner, Alexander Schwinn, Felix Wortmann sowie alle beteiligten studentischen Mitarbeiter am Institut für Wirtschaftsinformatik. Hervorzuheben ist unter den wissenschaftlichen Mitarbeitern Ronny Fischer, dessen unermüdlicher Einsatz diese Konferenz überhaupt erst möglich gemacht hat, sowie unter den studentischen Mitarbeitern Remo Stieger, der die Redaktion des Konferenzbandes übernommen hat. Schliesslich danken wir Herrn Dr. Werner A. Müller, Frau Barbara Fess und deren Team vom Physica-Verlag für die gewohnt angenehme und professionelle Zusammenarbeit. Joachim Schelp, Robert Winter St. Gallen, im September 2004

7 Inhaltsverzeichnis Vorwort und Einführung...V Modelle für Semantische Web-Anwendungen E. J. Neuhold, M. Fuchs, C. Niederée... 1 Strategische Fragen der integrierten Informationslogistik Integration des Prozessmanagements in eine zukunftsorientierte CIO- Organisation am Beispiel von Siemens ICN B. Schrön, M. Hafner EAI und Nachhaltigkeit von Architekturen Ergebnisse einer empirischen Studie S. Aier Die Wertschöpfung des Metadatenmanagements für Unternehmen der Finanzindustrie H. Wegener Outsourcing und Offshoring von Business Intelligence-Lösungen Empirische Studien und Praxiserfahrung J. Philippi Ausgewählte Gestaltungssaspekte der integrierten Informationslogistik Die Gestaltung einer unternehmensweiten, flexiblen Software-Architektur auf Basis eines selbst entwickelten Zonen- und Schichten-Modells M. Tiedemann, V. Wittig, S. Rougier Entwurfsmuster für die Applikationsintegration A. Schwinn Twelve Mistakes to Avoid When Constructing a Real-Time Data Warehouse S. A. Brobst

8 X Inhaltsverzeichnis Anforderungsmanagement bei der Entwicklung von Data Warehouse- Systemen Ein sichtenspezifischer Ansatz M. Goeken Lösungsansätze aus Data Warehouse-Projekten D. Nonhebel XML-Einsatz in Business-Intelligence-Systemen Eine systematische Übersicht C. Bange, S. Schwalm Neue Umsetzungsszenarien integrierter Informationslogistik XML-Datenimport in das SAP Business Information Warehouse bei Bayer MaterialScience M. Hahne, L. Burow, T. Elvers OLAP-Techniken aus Sicht der industriellen Auftragsabwicklung J. Becker, T. Serries, R. Knackstedt Extending the Data Warehouse with Company External Data from Competitors Websites A Case Study in the Banking Sector N. Stolba, B. List Data Distribution with a Market Data Information System C. Felden Einsatz von Peer-to-Peer-Technologie zur betriebswirtschaftlichen und informationstechnischen Unterstützung von EAI-Projekten F. Kupsch, D. Werth Prozessintegration in der Praxis Integrating Management Views in Supply Chain Environments An arvato (Bertelsmann) Business Case R. Holten, M. Laumann Integrierte Prozesse mit Prozessportalen S. Grimm Planung und Einsatz von EAI am Beispiel eines Projekts in der Wertpapierabwicklung einer Geschäftsbank J. Kreutzberg, U. Proft

9 Inhaltsverzeichnis XI DWH und EAI im Integration Layer der Bank Julius Bär Architektur, Anwendungen und Erfahrungen T. Jarkovich, P. Böhnlein Data Warehousing in der Praxis Einsatz eines Data Warehouse im egovernment-bereich zur Asylsteuerung und Migrationsanalyse A. Bauer, M. Böhnlein, T. Eckert, H. Lederer, K. Munsi Analyse eines SAP BW-Einsatzes im Controlling am Beispiel der T-Com S. Eicker, T. Lambertz, F. Lelke Customer Investigation Process at Credit Suisse: Meeting the Rising Demand of Regulators P. Brändli, T. Mügeli, D. Maier, M. Winter, M. Klesse, C. Herrman Integrationsbedarf einer bankspezifischen Deckungsbeitragsrechnung J. J. Birkenbach, D. Kramer Analytisches Investor Relationship Management Ein innovatives Anwendungsfeld für Data Mining Technologien untersucht am Beispiel der AMP Ltd. B. Gehra, P. Gentsch, T. Hess DW2004 Veranstalter und Programmkomitee Hauptsponsorenverzeichnis Sponsorenverzeichnis Autorenverzeichnis

10 Modelle für Semantische Web-Anwendungen Erich J. Neuhold, Michael Fuchs, Claudia Niederée Fraunhofer IPSI Im Kontext des Semantic Web werden die inzwischen etablierten Web-Anwendungen mit neuen Herausforderungen konfrontiert. Um die neue Umgebung effektiv zu nutzen und das neue Klientel Software-Agenten adäquat zu bedienen, sind einige Erweiterungen der traditionellen Web-Anwendungen notwendig. Dieses Papier diskutiert Ansätze, um mit diesen neuen Herausforderungen umzugehen, insbesondere die Einführung von zwei zusätzlichen Modellen, einem konzeptuellen Benutzungsschnittstellenmodell und einem semantischen Domänenmodell. 1 Einleitung Web-basierte Anwendungen oder kurz Web-Anwendungen, d.h. Anwendungen, welche die Internet-Infrastruktur und Web-Technologien, wie z.b. HTML verwenden, sind inzwischen ein etablierter Architekturansatz inbesondere im Bereich der Informationssysteme. Wichtige Gründe hierfür sind sicherlich die systematische Nutzung existierender Infrastrukturen und die hohe Literacy weiter Nutzergruppen in Bezug auf die zugehörigen Benutzungsschnittstellen (Browser, formularbasiete Schnittstellen). Die Aktivitäten im Kontext des Semantic Web und das Web Service-Paradigma, als eine erfolgreiche Umsetzung der Idee des Service-Oriented Computing (Austin et al. 2004), sind zur Zeit die bedeutensten Trends auf dem Weg zur nächsten Generation des Internets. Deren Umsetzung schafft einen neuen Kontext für Web- Anwendungen, der neue Chancen, aber auch zusätzliche Herausforderungen mit sich bringt. Das Web Service-Paradigma, das neue föderative Modelle für die Diensterbringung eröffnet, kann in der Entwicklung von Web-Anwendungen genutzt werden, um dynamisch neue Dienste (Web Services) in die Anwendungen zu integrieren. Damit kann flexibel sowohl auf neue Anforderungen als auch auf das Aufkommen verbesserter Dienste reagiert werden. Wichtige offene Herausforderungen sind hier die adäquate Unterstützung bei der Orchestrierung und die semantische Beschreibung von Diensten, um das Auffinden geeigneter Dienste zu erleichtern. Die Aktivitäten im Bereich des Semantic Web versprechen vielfältige und flexible

11 2 E.J. Neuhold, M. Fuchs, C. Niederée neue Anwendungen im Web sowie eine verbesserte Unterstützung für die Kooperation zwischen Menschen und die Interaktion zwischen Computern und Menschen (Berners-Lee et al. 2001). Für die Entwicklung einer semantischen Web-Anwendung (Semantic Web Application, SWA), d.h., von Web-Anwendungen, die den Kontext Semantic Web effektiv nutzen, ergeben sich jedoch verschiedene Herausforderungen: 1. Die Zielgruppe der Web-Anwendungen erweitert sich vom menschlichen Nutzer zu einer gemischten Nutzergemeinde aus menschlichen Nutzern und Software-Agenten. Daraus ergeben sich neue Anforderungen für SWA Benutzungsschnittstellen (UIs). 2. Ein wichtiger Baustein des Semantic Web, die automatische Interpretation von Inhalten, basiert auf dem Verbinden von lokalen Modellen zu global definierten Modellen, wie zum Beispiel öffentlichen Vokabularen oder Ontologien. Diese Anforderung muss bei den Domänenmodellen, die einer SWA zugrunde liegen, berücksichtigt werden. In diesem Papier werden Beiträge vorgestellt, um mit diesen Herausforderungen umzugehen. Dazu zählen die Einführung von zwei zusätzlichen Modellen, einem konzeptuellen UI-Modell und einem semantischen Domänenmodell, von geeigneten Abbildungen zwischen diesen Modellen, sowie die Entwicklung eines exemplarischen Frameworks (SWAN Framework), um SWAs basierend auf den Modellen zu erstellen. Der SWAN-Ansatz verbindet semi-automatisch extrahierte, RDF-basierte Domänenmodelle mit XForms-basierten konzeptuellen UI-Modellen und mit Web Service-kodierter Anwendungslogik. In diesem Framework werden die Definition und Verwaltung von Modellen sowie von Abbildungen zwischen den Modellen durch SWAN-Autorenwerkzeuge sowie durch UI-Entwurfsmuster unterstützt. Der Rest dieses Papiers ist wie folgt strukturiert: Abschnitt 2 diskutiert den Weg von traditionellen zu semantischen Web-Anwendungen. Die Abschnitte 3 und 4 diskutieren die beiden neuen Modelle für SWAs, konzeptuelle UI-Modelle und semantische Domänenmodelle sowie deren geeignete Repräsentation. Abschnitt 5 präsentiert die weiteren Bausteine auf dem Weg zu den SWAs: geeignete Abbildungen zwischen den Modellen, eine mögliche Operationalisierung solcher Abbildungen, sowie den SWAN Framework zur Entwicklung von SWAs. Das Papier schliesst mit einer Liste offener Forschungsaspekte im Kontext der SWAs.

12 authors id name 1 Rudar 2 Best 3 Glue 4 Hollow authors id name 1 Rudar 2 Best 3 Glue 4 Hollow authors id name 1 Rudar 2 Best 3 Glue 4 Hollow 5 Rudar 6 Best 7 Glue 8 Hollow 9 Rudar 10 Best 11 Glue authors id name 1 Rudar 2 Best 3 Glue 4 Hollow authors id name 1 Rudar 2 Best 3 Glue 4 Hollow 5 Rudar 6 Best 7 Glue 8 Hollow 9 Rudar 10 Best 11 Glue authors id name 1 Rudar 2 Best 3 Glue 4 Hollow authors id name 1 Rudar 2 Best 3 Glue 4 Hollow authors id name 1 Rudar 2 Best 3 Glue 4 Hollow 5 Rudar 6 Best 7 Glue 8 Hollow 9 Rudar 10 Best 11 Glue authors authors id name id name 1 Rudar 1 Rudar 2 Best 2 Best 3 Glue 3 Glue 4 Hollow 4 Hollow 5 Rudar 6 Best 7 Glue 8 Hollow 9 Rudar 10 Best 11 Glue Modelle für Semantische Web-Anwendungen 3 2 Von der Web-Anwendung zur semantischen Web-Anwendung Web-Anwendungen verwenden typischerweise eine Drei-Schichten-Architektur bestehend aus einer Persistenzschicht (Storage Layer), einer Schicht für die Anwendungslogik (Application Layer) und einer Schicht für das UI (User Interface Layer). Traditional SWA User Interface JSP, ASP, Application ODBC, JDBC, Web User Interface Agent Interface Conceptual UI Model Semantic Domain Model Layer Layer User Interface Application Storage Layer Abb. 1: Traditionelle und semantische Web-Anwendung: Schichten-Architekturen im Vergleich Die Persistenzschicht verwendet meist relationale oder objektrelationale Datenbanken zur persistenten Speicherung der Anwendungsdaten, auf die über ein herstellerunabhängiges Protokoll, wie z.b. JDBC oder ODBC, zugegriffen wird. Die mittlere Schicht realisiert die über die Speicherung der Daten hinausgehende Anwendungslogik. Für die Verbindung zwischen der Anwendungslogik und der UI, die typischerweise in HTML plus Erweiterungen wie Javascript realisiert ist, stehen verschiedene Technologien zur Verfügung, wie z.b. JSP, ASP. Diese Architektur 1 dient als Ausgangspunkt für die Diskussion des Übergangs zur Semantischen Web-Anwendung. Insbesondere wird betrachtet, wie systematisch zu einer Benutzungsschnittstelle übergegangen werden kann, die für eine gemeinsame Nutzung von Mensch und Software-Agent geeignet ist, und wie sematische Annotation in geeigneter Weise in die Anwendung integriert werden kann. 1 Es gibt auch noch einige alternative Technologiebausteine wie z.b. Java Applets, XML Datenbanken, etc., die aber hier nicht weiter betrachtet werden.

13 4 E.J. Neuhold, M. Fuchs, C. Niederée Die Markup-Sprache HTML 2 kann semi-strukturierte Texte mit Layout-Optionen darstellen und beinhaltet ebenfalls ein Vokabular zur Repräsentation von einfachen Eingabeformularen. In Kombination mit JavaScript können mit HTML, relativ komfortable UIs für menschliche Benutzer erstellt werden. HTML besitzt jedoch einige wohlbekannte Schwächen, die sich im hier betrachteten Kontext besonders stark bemerkbar machen. Hierzu zählen: die Mischung aus Struktur- und Layout-Elementen in HTML, die im Design von HTML begründet liegt, sowie die inkonsistente Nutzung der Elemente zum Erreichen bestimmter Layouts; die mangelnde Erzwingung syntaktischer Regeln durch Fehlertoleranz und Anzeigerobustheit der Browser (z.b. keine Erzwingung schließender Tags oder der wohlgeformten Schachtelung von Elementen), die zu einer weiten Verbreitung unsauber strukturierter Dokumente führt; die starke Ausrichtung auf die Nutzung im Web-Browser, die für die Bedienung anderer UI-Agenten, wie z.b. Mobiltelephone und PDAs, aber auch Software-Agenten die Erzeugung neuer UIs notwendig macht; die mangelnde Erweiterbarkeit (HTML ist nicht selbstbeschreibend) durch die Beschränkung auf ein fixes Vokabular; Für den Übergang zu SWAs müssten HTML-Seiten auch von Software-Agenten zu bedienen sein. Die aufgeführten Schwächen von HTML machen eine automatische Identifizierung bestimmter strukureller Teile eines HTML Dokuments für einen Software-Agenten jedoch schwierig. So ist es z.b. nur schwer möglich, die relevanten Eingabefelder innerhalb einer HTML-Seite ausfindig zu machen. Die im Moment sehr populäre Markup-Sprache XML besitzt die genannten Schwächen von HTML nicht mehr. Insebesondere ist XML selbstbeschreibend und somit erweiterbar. XML ist jedoch anwendungsunabhängig und bietet daher keine spezielle Unterstützung für die Beschreibung von UIs, d.h., es wird zusätzlich noch ein spezielles XML Vokabular für UIs benötigt. Ein solches Vokabular, nämlich XForms, wird in unserem Ansatz zur Beschreibung von UIs verwendet (siehe Abschnitt 3.2.1). Um mit der UI sowohl unterschiedliche Arten von Nutzern (Mensch und Maschine) bedienen zu können, als auch unterschiedliche Arten von UI-Agenten, wie dies im Semantic Web Kontext notwendig sein wird, empfiehlt sich die Einführung einer zusätzlichen Ebene, eines konzeptuellen UI-Modells. Dieses beschreibt die UI auf einer konzeptuellen Ebene, unabhängig von der Art des Nutzers und des UI-Agenten. Die Idee eines konzeptuellen UI-Modells wird in Abschnitt 3 genauer betrachtet. 2 HTML Hyper Text Markup Language (Le Hors, Jacobs 1999).

14 Modelle für Semantische Web-Anwendungen 5 Der zweite wichtige Aspekt beim Übergang zu semantischen Web-Anwendungen ist die explizite Repräsentation des Domänenmodells, die eine Reflektion über das Domänenmodell erlaubt. Eine solche Repräsentation zusammen mit einem Bezug zu global definierten Ontologien ist eine wichtige Voraussetzung für eine automatische (partielle) Interpretation der von einer Web-Anwendung angebotenen Information durch einen Software-Agenten. Durch einen klaren Bezug zum Domänenmodell, weiß der Agent, worüber in der UI gesprochen wird, zumindest, wenn eine Ontologie als gemeinsamer Bezugspunkt für die Interpretation existiert. Eine explizite Modellierung der Domäne findet bei Web-Anwendungen im Wesentlichen nur während des Entwurfsprozesses statt, z.b. bei der Erstellung von UML-Klassendiagrammen für die jeweilige Anwendung. Zur Laufzeit der Web- Anwendung liegt das Domänenmodell nur noch implizit und teilweise redundant vor, zum einen in den Klassen des Programmcodes und zum anderen im Datenmodell der Datenbank. Beim Übergang zur SWA wird also zusätzlich ein semantisches Domänenmodell benötigt, das in einer geeigneten Repräsentation und für den Software-Agenten zugreifbar vorliegen muss. Neben diesen beiden zusätzlichen Modellen müssen für SWAs natürlich auch geeignete Abbildungen zwischen diesen Modellen und zu den anderen Modellen einer Web-Anwendung, wie z.b. dem Datenmodell der Datenbank definiert werden. Weiterhin werden Werkzeuge benötigt, welche die Definition und Verwaltung der Modelle und der Abbildungen systematisch und benutzerfreundlich unterstützen. 3 Konzeptuelle Modelle für Benutzungsschnittstellen In Web-Anwendungen sind dialogorientierte (meist formularbasierte) UI-Modelle aktuelle Praxis auf dem Gebiet der Unterstützung von Interaktionen mit Benutzern. Die Anforderungen einer SWA, Interaktionen sowohl mit menschlichen Benutzern als auch mit Software-Agenten zu unterstützen, wird durch UI-Modelle auf konzeptueller Ebene erfüllt. Diese Modelle können dynamisch in die für den jeweiligen Benutzer (Mensch oder Software-Agent) adäquate Schnittstellensprache 3 übersetzt werden. In diesem Abschnitt werden Anforderungen und vorhandene Ansätze für konzeptuelle UI-Modelle diskutiert. 3 Z.B. HTML/WML für Mensch+Browser/Handy und SL 0 für Sofware Agenten.

15 6 E.J. Neuhold, M. Fuchs, C. Niederée 3.1 Anforderungen Für die die Nutzung von konzeptuellen UIs in SWAs ergeben sich die folgenden Anforderungen. Ein konzeptuelles UI-Modell sollte: 1. den Entwurf der UI auf einer abstrakten Ebene repräsentieren, d.h. unabhängig vom UI-Agenten (Handy, PDA oder Computer), 2. eine reiche Auswahl von UI-Komponenten und deren Kombination unterstützen, 3. ein mächtiges clientseitiges Interaktionsmodell beinhalten, um hinreichend flexible UI gestalten zu können und serverseitige Aktionen zu reduzieren, 4. dem Model-View-Controller (MVC) Paradigma (Krasner, Pope 1988) folgend Struktur, Layout und Abbildung zur Domänenschicht klar trennen und 5. maschinenlesbar sein. Diese Anforderungen resultieren im Wesentlichen aus dem Kontext des Semantic Web sowie dem Wunsch, komfortable und wartbare UIs für eine breite Palette von Anwendungsdomänen entwerfen zu können. 3.2 Konkrete Ansätze Dieser Abschnitt diskutiert XForms und andere Ansätze im Zusammenhang mit konzeptuellen UI-Modellen und stellt sie den im vorherigen Abschnitt identifizierten Anforderungen gegenüber XForms Formularbasierte Schnittstellen der nächsten Generation Der neue Internet-Standard XForms (Dubinko et. al 2003) für die nächste Generation von formularbasierten UIs ist ein gutes Beispiel für ein konzeptuelles UI- Modell. XForms bietet ein Modell und eine formale Sprache (XML-Syntax Anforderung 5) zur Definition von formularbasierten Dialogen auf einer konzeptuellen Ebene (siehe Anforderung 1). Das XForms-Modell folgt dem MVC-Paradigma.

16 Modelle für Semantische Web-Anwendungen 7 Abb. 2: UML Klassendiagramm des XForms-Modells Wie man dem UML-Klassendiagramm in Abb. 2 entnehmen kann, ist das XForms-Modell entlang der drei Blöcke des MVC Paradigmas strukturiert: Model: Der Modell-Block repräsentiert die Abbildung zum Domänenmodell und dessen Instanzen (Data Object). View: Das Erscheinungsbild wird duch das View-Element im Sichten-Block (View) umgesetzt. Dies geschieht im Idealfall durch CSS (Cascading Style Sheets), welche Layout-Regeln für Kontrollelement-Klassen festlegen. Control: Interaktionen zwischen Benutzer und Datenobjekten werden durch die Kontrollelemente im Kontroll-Block gewährleistet. Aus den Kontrollelemente lassen sich auch komplexe Strukturen aufbauen (Gruppierung, Verschachtelungen, Verzweigung, wahlweise Umschaltung, Wiederholung etc.) und die Strukturen sind zur Laufzeit dynamisch erweiterbar. Diese Vielfalt trägt zur Erfüllung der Anforderung 2 bei. Die XForms Kontrollelemente sind abstrakte Kontrollelemente, die noch unabhängig von der Implementierung in der UI sind. So repräsentiert das Kontrollelement Select1 die Auswahl eines Elements aus einer Menge von mehreren Elementen, ohne festzulegen, ob dies eine Aufklappliste, eine Menge von Radiobuttons oder die Auswahl über eine Telefontastatur ist.

17 8 E.J. Neuhold, M. Fuchs, C. Niederée Diese abstrakten Kontrollelement-Definitionen werden durch einen geeigneten Prozessor (meist zur Laufzeit) in konkrete UI-Elemente umgesetzt. Zum Beispiel kann in einem Internet-Browser die Metapher Auswahl eines Elementes aus einer Menge von mehreren Elementen durch eine expandierende Auswahlliste dargestellt werden. Die Aufspaltung des XForms-Modells in die einzelnen Blöcke erfüllt Anforderung 4. Weiterhin können Datenobjekte mit Bedingungen verknüpft werden (z.b. Datentypen zur Typüberprüfung). Interaktionen und das Nichterfüllen von Bedingungen können vordefinierte Ereignisse hervorrufen, auf welche mit geeigneten Aktionen reagiert werden kann. Dieses Bedingung- Ereignis-Aktions-Modell deckt, zusammen mit der Möglichkeit die Benutzungsschnitttstelle dynamisch zu verändern, schliesslich Anforderung 3 ab Weitere Ansätze Im Bereich der modellbasierten Ansätze zur Entwicklung von UIs finden sich weitere Beispiele für konzeptuelle UI-Modelle (Foley et al. 1998, Puerta 1997, Paterno 2000), die jedoch alle nicht so weit ausgereift sind wie XForms. Das Haystack Rahmenwerk (Quan et al. 2003) beinhaltet z.b. als konzeptuelles UI-Modell eine erweiterbare UI-Ontologie mit dem Namen Ozone. Diese Ontologie besitzt folgende Eigenschaften: Sie besteht aus einem RDF Vokabular für UIs mit der Ausdrucksmächtigkeit von HTML. Durch die XML-Syntax von RDF ist Anforderung 5 erfüllt. Es können Layout-Regeln erstellt und sowohl auf einzelne Kontrollelemente als auch auf Kontrollelement-Klassen angewandt werden. RDF Resourcen werden über eine RDF Sichtendefinition ins UI integriert. Durch die Trennung der einzelnen UI-Modellkomponenten auf konzeptueller Ebene sind die Anforderungen 1 und 4 erfüllt. Jedoch gibt es keine vordefinierten Modellierungsmöglichkeiten für UI-spezifische Mechanismen wie Ereignisse, über HTML hinausgehende Typen von Kontrollelementen, Überprüfung von Eingaben über Bedingungen etc. Dadurch bleiben die Anforderung 2 und 3 für Ozone im Wesentlichen unerfüllt. 4 Semantische Domänenmodelle Die explizite, maschinenlesbare Repräsentation von Domänenmodellen wird in Abschnitt 2 als ein Baustein für SWAs identifiziert. Dieser Abschnitt diskutiert die besonderen Anforderungen an ein Domänenmodell in diesem Kontext und unter-

18 Modelle für Semantische Web-Anwendungen 9 sucht, inwiefern diese Anforderungen von existierenden Ansätzen zur konzeptuellen Modellierung von Wissen über eine Anwendungsdomäne erfüllt werden. 4.1 Anforderungen Es lassen sich folgende Anforderungen für ein semantisches Domänenmodell identifizieren. 1. Unterstützung der Modellierungsprimitiven: Das Domänenmodell sollte die Definition von Konzepten, von Beziehungen zwischen Konzepten, und von einfachen Eigenschaften von Beziehungen unterstützen; 2. Flexible Definition von Beziehungen zu globalen konzeptuellen Modellen: Interpretation im globalen Sinne erfordert die Möglichkeit auf globale konzeptuelle Modelle zu verweisen. Somit sollten im Domänenmodell definierte Konzepte in Beziehung zu existierenden, gemeinsam genutzten Konzeptualisierungen gesetzt werden können. 3. Repräsentation von Konzepthierarchien: Konzepthierarchien sind ein wichtiges Medium, um Semantik zu repräsentieren (Ausnutzung von is-a Beziehungen) und bilden die Kernstruktur von Ontologien. 4. Systematische Unterstützung von Datentypen: Zusätzlich zu den oben genannten Modellierungsprimitiven ist es wünschenswert, Bedingungen/ Einschränkungen formulieren zu können. Eine wichtige Form solcher Einschränkungen ist die Definition von Datentypen. 5. Repräsentation von zusätzlichem Domänenwissen und Bedingungen: Die Repräsentation von zusätzlichen Bedingungen/Einschränkungen reichern das Domänenmodell an. Als Beispiel sind zu nennen: Transitivität von Beziehungen, Disjunktheit von Klassen, etc. Neben den vorherigen Anforderungen, die sich im wesentlichen auf die Modellierungsmächtigkeit beziehen, spielt auch die konsistente Unterstützung von Domänen- und Ontologie-Evolution eine wichtige Rolle (6. Anforderung). Domänen und somit auch Domänenmodelle und Ontologien entwickeln sich mit der Zeit weiter. Folglich sind Methoden und Ansätze erforderlich, um mit solchen Veränderungen adäquat umzugehen. 4.2 Konkrete Ansätze Die Modellierung von Wissen über die jeweilige Anwendungsdomäne spielt in unterschiedlichen Bereichen und Ansätzen eine Rolle. Wichtige Beispiele sind die Erstellung konzeptueller Modelle im iterativen Software-Entwurf und die Verwendung von Domänenmodellen im modellbasierten Ansatz zur Entwicklung von UIs. Für das Verbinden von global definierten Konzepten mit lokalen Domänen-

19 10 E.J. Neuhold, M. Fuchs, C. Niederée modell-konzepten ist das Resource Description Framework (RDF Lassila, Swick 1999) eines der populärsten Modelle. Konkrete Ansätze aus diesen drei Bereichen werden in diesem Abschnitt kurz zusammengefasst und in Bezug auf mögliche Beiträge zu den oben identifizierten Anforderungen hin analysiert Konzeptuelle Modelle im Software-Entwurf Abb. 3: UML Beispieldiagramm Die durch die OMG Gruppe spezifizierte Unified Modeling Language (UML Rumbaugh et al. 1999) definiert eine Familie von Diagrammtypen, die in den unterschiedlichen Phasen der objektorientierten Analyse und des objektorientierten Entwurfs für Softwaresysteme eingesetzt werden können. Das UML Klassen-Diagramm dient unter anderem der Erstellung von konzeptuellen Domänenmodellen. In Bezug auf die in Abschnitt 4.1 definierten Anforderungen lässt sich zu den UML Klassendiagrammen folgendes sagen: Anforderung 1 wird erfüllt. Die Repräsentation von Konzepten/Klassen und deren Beziehungen, stehen im Mittelpunkt des UML Klassendiagramms. Im UML Beispieldiagramm in Abb. 3 repräsentieren Travel, BusTravel, etc. Klassen, während name und number Attribute von Objekten dieser Klassen darstellen. Beziehungen können zwischen Klassen definiert und benannt werden ( contains, start, destination ). Dabei kann zwischen verschiedenen Arten von Beziehungen (z.b. Komposition, Aggregation) unterschieden werden. Zur genaueren Spezifikation von Beziehungen lassen sich Kardinalitäten angeben (im Beispiel, 0..*, 1 ). Anforderung 3 kann in UML ohne Einschränkung abgedeckt werden. Ein Beispiel für eine einfache Konzepthierarchie ist in Abb. 3 die Klasse Travel mit ihren Unterklassen. In Bezug auf Anforderung 4, unterstützt UML nur eine kleine Menge von grundlegenden Datentypen. Datentypen, die über die UML-Standard-Typen hinausgehen, können aus der jeweiligen Zielumgebung des Entwurfs wie z.b.

20 Modelle für Semantische Web-Anwendungen 11 aus der Programmiersprache Java oder aus dem DB Modell importiert werden (Anforderung 4 nur teilweise erfüllt). Anforderung 5 wird von UML nur in rudimentärer Weise erfüllt. Weitergehende Einschränkungen für das Domänenmodell können nur in textueller Form ausgedrückt werden. Die Anforderungen 2 und 6 werden von UML Klassendiagrammen nicht erfüllt. Eine ähnliche Modellierungsmächtigkeit findet sich auch in anderen konzeptuellen Modellierungsansätzen für den Software-Entwurf, wie z.b. beim Entity-Relationship-Model (Chen 1976). Dieses unterscheidet sich im wesentlichen durch die eigene Art von Entitäten für die Darstellung von Beziehungen (Relationship Type) und enthält durch seine Entstehung vor der objekt-orientierten Ära erst in seiner erweiterten Form (EERM) Bausteine für die Darstellung von Konzepthierarchien (isa Beziehungen) Domänenmodelle im modell-basierten Entwicklungsansatz Ein weiterer Bereich, in dem Domänenmodelle zu finden sind, ist die modellbasierte Entwicklung von UIs. Da die hierbei verwendeten Domänenmodelle in ihrem Modellierungsansatz den UML Klassendiagrammen und anderen konzeptuellen Modellen sehr ähnlich sind, wird darauf verzichtet wiederum die einzelnen Anforderungen durchzugehen.vielmehr soll die unterschiedliche Rolle der Domänenmodelle im modell-basierten Ansatz betont werden, da diese Ähnlichkeiten mit der Verwendung des semantischen Domänenmodells in SWAs aufweist und auch unser SWAN Framework an den modell-basierten Ansatz angelehnt ist. Ziel des modell-basierten Ansatzes zur Schnittstellenentwicklung ist es, einen stärker deklarativen Ansatz für die Entwicklung zu realisieren. Im Wesentlichen werden dabei unterschiedliche Modelle definiert (z.b. Präsentationsmodell, Domänenmodell, Dialogmodell, Task-Modell, etc.) und Abbildung zwischen Komponenten der unterschiedlichen Modelle spezifiziert, wobei Domänenmodelle eine zentrale Rolle spielen. Ergebnis dieser Aktivitäten ist eine formale Repräsentation des Entwurfs der UI (Puerta 1997). Diese Repräsentation kann mithilfe benutzerfreundlicher Autorenwerkzeuge entwickelt und angepasst werden (siehe z.b. Fuchs et al. 2002) und bildet die Grundlage für die Generierung von UIs (siehe z.b. Foley et al. 1998) Resource Description Framework Der Resource Description Framework (RDF) ist im Rahmen der Semantic Web Aktivitäten entstanden und definiert ein einfaches aber mächtiges Datenmodell zur (semantischen) Beschreibung von Ressourcen im Web. Bei den Ressourcen kann

21 12 E.J. Neuhold, M. Fuchs, C. Niederée es sich sowohl um digitale als auch physikalische Objekte, wie z.b. Personen, handeln. Mit RDF können Aussagen über Ressourcen formuliert werden, die sich wiederum verifizieren lassen und damit Aussagen über Aussagen erlauben. In Bezug auf die in Abschnitt 4.1 definierten Anforderungen lässt sich zu RDF folgendes sagen: Von einer datenorientierten Sicht betrachtet ordnet eine RDF Aussage einer Eigenschaft (Property) einer Ressource einen Wert zu, der wiederum eine Ressource sein kann. Es lassen sich mit RDF also sowohl Beziehungen zwischen Ressourcen als auch Eigenschaften von Ressourcen darstellen. Mit RDF Schema steht außerdem eine Möglichkeit zur Verfügung, bestimmte Arten von Ressourcen zu unterscheiden (durch die Definition von Klassen) und die möglichen Eigenschaften solcher Klassen einzuschränken. Abbildung 4 zeigt einen Beispiel-RDF-Graph, wobei sowohl die Schemaebene als auch die Instanzebene dargestellt sind. 4 Entscheidender Unterschied zu anderen konzeptuellen Modellen ist, dass RDF Schema nicht klassenzentriert, sondern eigenschaftszentriert ist, d.h. Eigenschaften sind Objekte erster Klasse, über die selbst auch wieder Aussagen gemacht werden können. Über die vordefinierten Eigenschaft rdfs:domain wird eine Eigenschaft einer Klasse zugeordnet, z.b. die Eigenschaft destination der Klasse Flight; über die vordefinierte Eigenschaft rdfs:range kann ihr Wertebereich eingeschränkt werden (hier City). Damit ist die Anforderung 1 im Wesentlichen erfüllt. Allerdings bietet RDF alleine keine Möglichkeit die Kardinalitäten von Beziehungen einzuschränken. Mit RDF können zwar spezielle Arten von Eigenschaften/Beziehungen selbst definiert werden, aber im Kontext der automatischen Interpretation sind nur global vereinbarte Definitionen wirklich hilfreich oder solche für die lokal auch eine (auf globale Definitionen rückführbare) Semantik definiert wird. Dies ist aber in RDF nicht möglich. Durch die systematische Einführung von Uniform Resource Identifiers (URIs Berners-Lee et al. 1998) erleichtert RDF das Verbinden von global definierten Konzepten mit lokalen Domänenmodell-Konzepten und erfüllt damit Anforderung 2. Es können Konzepte in globalen Vokabularen und Ontologien, welche beispielsweise in OWL (Web Ontology Language) definiert sind, direkt wiederverwendet werden (Referenz) oder global definierte Konzepte können als Superklassen angegeben werden. Anforderung 3 ist erfüllt, da die in RDF Schema vordefinierten Eigenschaft rdfs:subclassof die Definition von Klassenhierarchien ermöglicht. Zusätzlich können mit Hilfe der Eigenschaft rdfs:subpropertyof auch Hierachien zwischen Eigenschaften definiert werden. 4 Die Eigenschaft rdf:type verbindet die Schemaebene mit der Instanzebene.

22 Modelle für Semantische Web-Anwendungen 13 Datentypen (Anforderung 4) werden in RDF auf der Schema-Ebene nicht unterstützt. Es ist jedoch möglich, auf Instanz-Ebene typisierte Literale ( typed literal ) zu definieren, d.h. dem Wert einer Eigenschaft einen Typ zuzuordnen. Dabei wird in der Regel auf einen XML Schema-Datentypen (Fallside 2000) zurückgegriffen. In RDF und RDF Schema stehen keine Konstrukte zur Beschreibung weiteren Domänenwissens und weiterer Bedingungen zur Verfügung. Auch die Evolution von Domänenmodellen und Ontologie-Evolution wird nicht systematisch unterstützt. Anforderungen 5 und 6 sind also nicht erfüllt. Die Nutzbarkeit von RDF zur Darstellung des semantischen Domänenmodells wird durch die Tatsache, dass es für RDF eine XML-Serialisierung gibt, weiter erhöht. Dieses RDF/XML Format vereinfacht die Nutzung und den Austausch von Domänenmodellen im Web-Kontext. Abb. 4: Beispiel-Graph für RDF und RDF Schema

23 14 E.J. Neuhold, M. Fuchs, C. Niederée OWL Die Web Ontology Language (OWL) basiert auf RDF und wurde zur Repräsentation von Vokabularen entwickelt. Sie ist RDF sehr ähnlich und verwendet einen Teil der in RDF definierten Sprachkonstrukte wie z.b. rdfs:range und rdfs:domain wieder. In SWAs kann OWL sowohl zur verfeinerten Darstellung von Domänenmodellen verwendet werden als auch zur Definition der Ontologien, die als Bezugspunkte für diese Domänenmodelle (siehe Anforderung 2) dienen. OWL ist eine ganze Sprachfamilie mit drei Sprachvarianten OWL Lite, OWL DL und OWL Full, die sich in Bezug auf ihre Ausdrucksmächtigkeit unterscheiden. Dabei besitzt OWL DL 5 die maximale Ausdrucksfähigkeit, ohne auf eine Zusicherung von Eigenschaften wie Berechenbarkeit und Entscheidbarkeit für die Inferenz zu verzichten. Die Aussagen, die hier gemacht werden, beziehen sich auf OWL DL. Da sich RDF und OWL sehr ähnlich sind, beschränkt sich die Analyse in Bezug auf die Anforderungen aus Abschnitt 4.1 auf die Unterschiede zwischen OWL und RDF: OWL ist wie RDF eigenschaftszentriert. Zusätzlich kann jedoch zwischen Eigenschaften unterschieden werden, deren Wert ein Literal ist (owl:datatypeproperty), und solchen, deren Wert eine Ressource (Instanz einer Klasse) ist (owl:objectproperty). Die zweite Option dient im wesentlichen der Darstellung von Beziehungen zwischen Ressourcen. Weiterhin bietet OWL Sprachkonstrukte an, um Kardinalitäten für Beziehungen zu definieren und um Beziehungen mit speziellen Eigenschaften zu kennzeichnen (owl:transitiveproperty, owl:symmetricproperty, owl:functionalproperty, owl:inversefunctionalproperty). OWL bietet also gegenüber RDF eine erweiterte Unterstützung für Anforderung 1. Zwischen OWL Klassen lassen sich neben der einfachen Subklassenbeziehungen noch weitere Beziehungen definieren (Disjunktheit, Vereinigung, Schnittmenge, Äquivalenz, etc.). Dies kann sowohl zur Verfeinerung des Domänenmodells verwendet werden, als auch um die Art der Beziehung zu Konzepten eines globalen Modells genauer darzustellen (Beitrag zu den Anforderungen 1 und 2). Ein Teil der im vorherigen Punkt genannten Konstrukte können auch zur Verfeinerung von Konzepthierarchien eingesetzt werden (Anforderung 3), für die OWL außerdem ein vordefiniertes oberstes Element (owl:thing) und unterstes Element (owl:nothing) zur Verfügung stellt. Im Gegensatz zu RDF lassen sich in OWL auch auf der Schemaebene Aussagen zur Typisierung von Eigenschaften machen, nicht nur auf der Ebene der 5 DL steht für Description Logic.

24 Modelle für Semantische Web-Anwendungen 15 Instanzen. Hierzu wird für Eigenschaften des Typs owl:datatypeproperty ein Typ als Wertebereich angegeben (rdfs:range), meist ein XML Schema Typ. In OWL wird die Anforderung 4 also systematischer unterstützt als in RDF. In OWL werden sogenannte Eigenschaftsbeschränkungen (property restrictions) verwendet, für die spezielle Konstrukte zur formalen Formulierung weiterer Einschränkungen für ein Domänenmodell (oder eine Ontologie) zur Verfügung stehen. Durch die systematische Kombination dieser Konstrukte lassen sich recht komplexe Bedingungen zur genaueren Beschreibung von Klassen und Eigenschaften formulieren. Dies ist ein wichtiger Beitrag zur Anforderung 5. Anforderung 6 (systematische Unterstützung von Evolution) wird von OWL nur rudimentär unterstützt. Zum einen läßt sich in dem vordefinierten Metadatenformat von OWL eine Versionskennungen angeben und Ontologien können importiert werden. Zum anderen können die oben erläuteten Konstrukte zur Definition von Beziehungen zwischen Klassen plus die spezielle Beziehung owl:backwardcompatiblewith verwendet werden, um Aussagen über die Beziehung zwischen Klassen in unterschiedlichen Versionen eines Domänenmodells oder einer Ontologie zu machen. Insgesamt sind die Anforderungen durch OWL (in Kombination mit RDF) gut erfüllt, außer Anforderung 6, die nur rudimentär berücksichtigt wird. Da zusätzlich RDF und OWL wichtige Formate im Kontext der Semantic Web Aktivitäten sind, bietet es sich an, RDF und OWL zur Repräsentation des sematischen Domänenmodells in SWAs zu verwenden. 5 Von den Modellen zur semantische Web-Anwendung In den vorherigen Abschnitten wurden im Wesentlichen die beiden zusätzlichen Modellarten für SWAs motiviert und mögliche Ansätze zu ihrer Repräsentation diskutiert. Zusätzlich zu den Modellen werden jedoch für die effektive Entwicklung von SWAs noch weitere Bausteine benötigt. Dazu zählen unter anderem: Abbildungen zwischen den unterschiedlichen Modellen in einer SWA (Datenmodell, semantisches Domänenmodell, konzeptuelles UI-Modell, konkretes UI) Werkzeuge zur Definition der Modelle und der Modellabbildungen für die jeweilige Anwendung In diesem Abschnitt werden anhand des SWAN Frameworks, das an unserem Institut entwickelt wurde, konkrete Ansätze für diese beiden Aspekte vorgestellt.

25 authors id name 1 Rudar 2 Best 3 Glue 4 Hollow authors id name 1 Rudar 2 Best 3 Glue 4 Hollow authors id name 1 Rudar 2 Best 3 Glue 4 Hollow 5 Rudar 6 Best 7 Glue 8 Hollow 9 Rudar 10 Best 11 Glue authors authors id name id name 1 Rudar 1 Rudar 2 Best 2 Best 3 Glue 3 Glue 4 Hollow 4 Hollow 5 Rudar 6 Best 7 Glue 8 Hollow 9 Rudar 10 Best 11 Glue 16 E.J. Neuhold, M. Fuchs, C. Niederée Zusätzlich wird die ebenfalls im Framework realisierte Idee der Entwurfsmuster für UIs, die das Erstellen von SWAs weiter erleichtert, kurz aufgegriffen. 5.1 Abbildung zwischen den Modellen Software Agent Conceptual UI Model Semantic Domain Model Web User Interface Agent Interface Conceptual UI Model User Interface Layer Semantic Domain Model Application Layer Data Model Abb. 5: Systemschichten, mit deren Modellen und Abbildungen Die beiden zusätzlich eingeführten Modelle müssen in adäquater Weise in die Architektur einer SWA integriert werden. Dazu müssen die weiterhin existierenden Modelle traditioneller Web-Anwendungen, das UI-Modell, das Datenmodell der Datenbank und/oder der Anwendung mit den neuen Modellen in Beziehung gesetzt werden. In unserem Ansatz werden dazu Abbildungen zwischen den Modellen definiert, welche flexible Kopplungen zwischen den Modellen etablieren. Diese Abbildungen sichern einen nahtlosen Informationsfluß sowohl der gespeicherten Daten in die Benutzungsschnittstellen als auch der vom Benutzer eingegebenen Daten in die Anwendungslogik bzw. direkt in die Datenbank. Zusätzlich zu den semantischen Domänenmodellen arbeitet der SWAN Ansatz noch mit der Einschränkung auf relevante Domänenmodellsichten. Die Operationalisierung der Abbildung und die Art der Kopplungen hängt von den jeweiligen Modellen ab: Das Datenmodell bietet den Ausgangspunkt für die automatische Generierung des Domänenmodells, das manuell verfeinert werden kann. Dabei wird eine bidirektionale Abbildung zwischen Datenmodell und Domänenmodell etabliert. Ausgehend vom Domänenmodell werden die Domänenmodellsichten manuell vom Benutzer festgelegt und mit Elementen des konzeptuellen UI-Modells verbunden. Die Abbildung zwischen dem konzeptuellen UI- Modell und dem konkreten UI-Modell ist eine automatische Transformation durch

26 Modelle für Semantische Web-Anwendungen 17 einen geeigneten Prozessor. Dabei ist zu beachten, dass die semantische Information des Domänenmodells in das UI für den Software-Agenten propagiert wird. Die durch den Benutzer eingegebenen oder veränderten Daten können über die Kopplung zwischen UI-Modell, Domänenmodell und Datemodell direkt zurückgeschrieben werden. Alternativ erlaubt das SWAN Framework auch eine Kopplung mit der Anwendungslogik durch eine Abbildung zwischen der Domänenmodellsicht und den Schnittstellen zu aktivierender Web Services. 5.2 Autorenwerkzeuge für Modelle und Modellabbildungen Das SWAN Framework folgt dem modellbasierten Ansatz und der Idee eines partizipatorischen Enwicklungs- und Evolutions-Prozesses, der es erlaubt auch Domänenexperten in den Entwicklungsprozess mit einzubinden (vgl. Fischer, Scharff 2000). Aus diesem Grund stellt das Framework eine Reihe von Autorenwerkzeugen zur Verfügung, die es erlauben, die im vorigen Abschnitt diskutierten Modelle und Modellabbildungen in benutzerfeundlicher Weise zu definieren, zu verfeinern und zu modifizieren. Hierzu zählt insbesondere ein Werkzeug zur Definition von konzeptuellen UI-Modellen auf der Grundlage des XForms-Standards und für die Kopplung von UI-Komponenten mit Elementen von Domänenmodellsichten. Weitere Werkzeuge ermöglichen unter anderem die Definitionen von Domänenmodellsichten, die Verfeinerung von extrahierten Domänenmodellen und die Definition von Navigationsstrukturen für SWAs. Eine genauere Beschreibung der übrigen Komponenten des SWAN Frameworks befindet sich in (Fuchs et al. 2002, Fuchs et al. 2003). 5.3 Entwurfsmuster für Benutzungsschnittstellen Auch mit den Autorenwerkzeugen stellt die Entwicklung und Anpassung einer semantischen Web-Anwendung immer noch eine anspruchsvolle Aufgabe dar. Aktuell evaluieren wir den Einsatz von Entwurfsmustern für UIs in den Autorenwerkzeugen (Fuchs et al. 2004). Die zugrundeliegende Annahme ist, dass es bei der Erstellung von UIs und deren Kopplung an die unterliegenden Domänenmodelle häufig wiederkehrende Muster gibt, für die auf bewährte abstrakte Lösungen in Form von UI Entwurfsmustern zurückgegriffen werden kann (vgl. Borchers 2000). Ziel ist es, dass diese Entwurfsmuster die Grundlage für Komponenten bilden, die aktiv in den Erstellungs- und Abbildungsprozess eingreifen und die Rolle eines spezialisierten Beraters/Qualitätssicherers übernehmen.