Ontologie-getriebene Metadaten-Syndikation zur Unterstützung von GeoGovernment-Anwendungen

Transkript

1 Ontologie-getriebene Metadaten-Syndikation zur Unterstützung von GeoGovernment-Anwendungen Guntram FLACH, Andreas PAKULAT und Matthias RUST Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als reviewed paper angenommen. Zusammenfassung Ziel dieses Beitrages ist die Vorstellung eines Ansatzes für semantikbasierte GeoGovernment-Dienste zur Unterstützung wissensorientierter Verwaltungsprozesse. Dabei wurden Verfahren umgesetzt, die prozessorientiert komplementäre GIS-, egovernment- und CMS- Systemkomponenten integrieren. Dabei wurde auf eine Ontologie- und metadatengetriebene enge Kopplung zwischen Workflow-Steuerung, OGC- und Assistenz-Komponenten mit dem Ziel einer erhöhten Dienste-Qualität Wert gelegt. Mit dem INGEOS-Framework 1 wurde ein exemplarisches Systems umgesetzt, das die Verwendung unterschiedlicher Mechanismen sowie die flexible Anpassung an die Anforderungen eines kommunalen Anwendungsszenarios (Hansestadt Rostock, Event-Management) erlaubt. 1 Einleitung Die Entwicklung hin zu jeweils serviceorientierten, integrierten Lösungen von egovernment und Geoinformationsystemen (GIS) erfordert eine gesamthafte Integration. Die Vision einer georeferenzierten und erweiterbaren Systemplattform, in der organisationsübergreifend jeder Mitarbeiter eines Unternehmens oder Kommune die für seine Aufgaben und Rolle relevanten Geo-Daten, Fachinformationen, Tools und Transaktionsysteme findet, mit anderen Institutionen interagieren kann (kommunikative und kollaborative Funktionen) und gegebenenfalls interkommunale GeoGovernment-Prozesse aufgabenspezifisch anstoßen kann, verlangt eine Vernetzung von GIS- und egovernment-systemen (STROBL & GRIES- EBNER 2003) Im Rahmen dieses Beitrages werden verschiedene Realisierungsaspekte zur ontologiegetriebenen Metadaten-Syndikation vorgestellt, die den Zugriff und das Retrieval auf raumbezogene, verteilte Datenbestände sowie die Vernetzung der im gleichen Prozess-Kontext stehenden GIS-, egovernment- und CMS-Systemkomponenten erlauben. Dabei wurden aktuelle Spezifikationen des Open Geospatial Consortiums (OGC), der ISO 19115/19119 (VOGES & SENKLER 2005) sowie des W3C (RDF, OWL) innerhalb der INGEOS- Gesamtkonzeption (FLACH 2005) genutzt. Ein Ziel darüber hinaus war die vorgangsgesteu- 1 INGEOS: Integrierte Komponentenplattform für interkommunale GeoGovernment-Systeme. Das Projekt wird unterstützt durch die BMWi-Initiative PROINNO II.

2 152 G. Flach, A. Pakulat und M. Rust erte und wissensbasierte Anwendungsgestaltung sowie deren Integration in logisch geschlossene Prozess-Ketten (BPEL). 2 Anwendungsszenario Die Problemstellung wurde im Rahmen eines exemplarischen Systems gelöst, das die Verwendung unterschiedlicher Mechanismen und die Anpassung an spezifische Anforderungen aus dem kommunalen Bereich (Hansestadt Rostock, Event-Management) erlaubt. Dem Anwendungsszenario Event-Management liegt die Idee zugrunde, in der Hansestadt Rostock ein zentrales Dienstleistungsbüro Veranstaltungen einzurichten, das die Anmeldung und Genehmigung von Veranstaltungen vereinfacht. Im Rahmen des komplementären BMWi-Projektes VESUV 2 (Verbindliche Entscheidungen für sichere, universelle Verfahren und Anwendungen mittels mobiler Agenten) wurde der entsprechende Prozessablauf analysiert, optimiert und im Rahmen einer BPEL-Prozess-Umgebung instanziiert (Antrag auf Sondernutzung und Festsetzungsbescheid). Im Rahmen dieses Prozesses treten an mehreren Stellen geobezogene Entscheidungen auf (z.b. Lageplan-Prüfung, Eigentümer-Analyse). Weiterhin sind verschiedene Ämter in den Prüfungs- Prozess einbezogen, die Auflagen auch unter Nutzung von GeoDaten erteilen (z.b. Amt für Umweltschutz, Stadtamt, Bauamt sowie Amt für Stadtgrün, siehe auch Abb. 5). Um diese Prozesse durch eine elektronische Verfahrensabwicklung ohne Medienbrüche effektiver gestalten zu können, muss die Geodateninfrastruktur es erlauben, relevante Geodaten an jedem Punkt im Prozess schnell und einfach zu finden. Es muss möglich sein, dem Sachbearbeiter mit sehr wenigen prozess-bezogenen, unter Ausnutzung des gespeicherten Wissens alle zur Entscheidung nutzbaren Informationen zur Verfügung zu stellen. Hierzu müssen bestehende Metadaten und Katalogdienste mit Ontologien gekoppelt werden, um die Suchanfrage u.a. unter Auswertung der Beziehungen in den Ontologien zu erweitern. Damit ist es dann möglich, diese semantisch erweiterten GeoDienste dynamisch in den GeoGovernment-Prozess zu integrieren und den Sachbearbeitern aufgabenbezogene Assistenzfunktionen für relevante geobasierte Entscheidungen anzubieten. 3 Systemarchitektur Die INGEOS-Systemarchitektur basiert auf der VESUV-Rahmenarchitektur (AUDERSCH & FLACH 2005), welche um zusätzliche Komponenten erweitert wurde. Einen Überblick über die Systemarchitektur liefert Abbildung 1, die alle wesentlichen Komponenten, wie die BPEL-Workflow-Engine, den Proxy-Service, den INGEOS-Client, den INGEOS-Catalog, das Metadaten-Repository sowie den INGEOS-Integrator, darstellt. Im Nachfolgenden werden diese Systemkomponenten und ihre Aufgabe innerhalb der Architektur genauer beschrieben. 2

3 Metadaten-Syndikation zur Unterstützung von GeoGovernment-Anwendungen 153 Workflow-Engine Die Workflow-Engine ActiveBPEL 3 wurde eingebunden, um Prozesse und Verarbeitungsreihenfolgen abzubilden und behördliche Vorgänge in einen formalen Ausführungsrahmen einzugliedern. Die Workflow-Engine erlaubt das Einbinden von beliebigen Web Services zur Steuerung des Workflows, so können komplexe Funktionen aus der Workflow-Engine ausgelagert und in einem separaten Web Service gekapselt werden. Für das Anwendungsszenario Event-Management in der Hansestadt Rostock wurde eine BPEL-basierte Workflow-Instanz umgesetzt, die zum Beispiel eine Fallunterscheidung nach der Art der Veranstaltung erlaubt sowie die Prüfung der veranstaltenden Person(en) auf Zuverlässigkeit. Abb. 1: INGEOS-Systemarchitektur Proxy-Service Die Hauptaufgabe des Proxy-Service ist die zentrale Ablage aller Vorgangsdaten und der Zugriff auf bereits abgewickelte Vorgänge, um eine historienbezogene Entscheidungsunterstützung für gleichliegende Vorgänge zu ermöglichen. Dies erlaubt zum Beispiel die korrekte Auswahl des Veranstaltungstypen bei wiederkehrenden Veranstaltungen (z.b. HanseSail, 3

4 154 G. Flach, A. Pakulat und M. Rust Weihnachtsmarkt). Eine weitere Aufgabe des Proxy ist die Benachrichtigung der Clients, falls ein Vorgang nicht automatisiert ablaufen kann und die Interaktion durch den Sachbearbeiter erfordert (z.b. Zuverlässigkeitsprüfung). Schließlich implementiert der Proxy- Service eine GIS-Schnittstelle, um neben dem direkten Zugriff auf die Vorgangsdaten eine geobezogene Anfrage nach vergangenen oder laufenden Vorgängen zu ermöglichen. INGEOS-Client An bestimmten Prozess-Schritten können einzelne Organisationseinheiten und Sachbearbeiter unterstützt werden. Zu diesem Zweck ermöglicht der INGEOS-Client in einer formularbasierten Ansicht die Eingabe und die Visualisierung der für den Vorgang relevanten Informationen, die sich aus den Bearbeitungsdaten oder beteiligten geographischen Datenbasen ergeben. Er ist somit die Schnittstelle zwischen dem Sachbearbeiter, dem Proxy-Service und der Workflow-Engine (siehe auch Abb. 5). Metadaten-Repository Das Metadatenrepository enthält alle wesentlichen Metadaten, die für die Abarbeitung des Workflows und zur Entscheidungsunterstützung notwendig sind. Hierzu gehören unter anderem eine juristische Ontologie, domänenspezifische Ontologien (Gewerbewesen 4, Event- Management) sowie eine Ontologie, die die Organisations- und Funktionseinheiten der Hansestadt Rostock abbildet (siehe Abb. 4). Darüber hinaus werden Metadaten zu Fachverfahren und Schnittstellen vorgehalten. Für die Umsetzung des Metadata Repository wurde das Jena-Framework 5 ausgewählt, da es über eine Java API für RDF und OWL zur Verarbeitung von Ontologien verfügt. Zur Auswertung von Regeln auf Basis der ontologischen Daten enthält Jena eine Rule Engine sowie eine Inference-Engine. Die genannten Ontologien wurden mit Protege 6 umgesetzt. INGEOS-Catalog Der Katalogdienst erlaubt durch eine wissensgestützte Suche nach Geodiensten und Geodaten die Darstellung der für den Sachbearbeiter wichtigen Geodaten im Client. Die Verknüpfung der egovernment-prozess-schritte mit den jeweils relevanten Geodiensten und Geodaten erfolgt dabei dynamisch mittels verschiedener Ontologien. Der eigentliche Katalogdienst besteht dabei aus dem Basiskatalog und einer Komponente zur semantischen Anreicherung (siehe Abschnitt 4.1). 4 Realisierungsaspekte Die für den Lösungsansatz notwendigen Überlegungen werden im folgenden Abschnitt durch eine Auswahl verschiedener Realisierungsaspekte vorgestellt Basiert auf DIN-PATH 1035 XML-Datenaustausch von Gewerbemeldungen (XGewerbe). http.//jena.sourceforge.net.

5 Metadaten-Syndikation zur Unterstützung von GeoGovernment-Anwendungen Semantische Anreicherung Wie in Abbildung 2 dargestellt, ist der INGEOS-Catalog eine Erweiterung eines existierenden OGC-konformen Katalogdienstes. Für das Experimentalsystem wurde hier das deegree- Framework ausgewählt (FITZKE 2003), da es bereits eine funktionierende Implementierung eines Katalogdienstes bietet. Außerdem erlaubt es bei der Gestaltung der Metadatenspeicherung eine größere Flexibilität, so ist es einfacher Referenzen auf die Wissensbasis in die Metadaten zu integrieren. Abb. 2: Aufbau des INGEOS-Catalog Die in einer PostGIS-Datenbank gespeicherten Daten werden nun in das deegree- Framework eingebunden. Da der deegree-katalogdienst für die Anfragebearbeitung selbst einen WFS nutzt, müssen die Metadaten aus der Datenbank zunächst als Geo-Features beschrieben werden. Dies geschieht bei deegree über die Definition eines XML-Schemas, das die Struktur der Featuretypen beschreibt und das Mapping auf die Datenbankattribute festlegt. Der hier vorgestellte Basiskatalog ist nur eine mögliche Implementierung. Der INGE- OS-Catalog Wrapper kann über jedem Metadatenkatalog aufgesetzt werden, der Schnittstellen nach NEBERT (2004) mit HTTP-Protokollbindung bereitstellt. Somit ist die nachfolgende beschriebene semantische Anreicherung von Kataloganfragen völlig unabhängig vom eigentlichen Metadatenkatalog nutzbar und kann in verschiedensten Infrastrukturen eingesetzt werden. Die wesentliche Aufgabe des INGEOS-Catalog Wrappers ist die Anreicherung der Suchanfrage unter Ausnutzung von gespeichertem Wissen. Um eine semantische Anfrageerweiterung zu ermöglichen, müssen die vorhandenen Geo-Metadaten mit Konzepten aus einer Ontologie verknüpft werden. Für diese Aufgabe wurde im Rahmen des INGEOS-Projektes ein semantischer Metadateneditor entwickelt, der es erlaubt, Metadaten von Geodiensten oder aus anderen Metadatenkatalogen (z.b. Umweltdatenkatalog, UDK) zu importieren und sie mit Hilfe eines Konzeptbrowsers mit der Ontologie zu verbinden. Der Konzeptbrowser ist eine Komponente zur visuellen Darstellung und Suche von Konzepten in einer Ontologie, er erlaubt eine einfache Navigation innerhalb der Ontologie und erleichtert so die korrekte Anreicherung der Geo-Metadaten. Der semantische Metadateneditor kann die so angereicherten Geo-Metadaten dann direkt in die genutzte Metadaten-Datenbank ablegen (siehe Abb. 2).

6 156 G. Flach, A. Pakulat und M. Rust Abb. 3: Architektur des Basiskatalogs Die gespeicherten Metadaten werden vom INGEOS-catalog Wrapper über eine Katalogschnittstelle nach OGC CAT 2.0 Standard (VOGES & SENKLER 2005) bereitgestellt. Hierbei implementiert der INGEOS-catalog Wrapper lediglich die Anreicherung mit Hilfe des in den Ontologien gespeicherten Wissens und reicht die so erweiterten Anfragen an einen Katalogdienst weiter (siehe Abb. 3). Abb. 4: Ausschnitt aus der Aufgaben-Ontologie (Hansestadt Rostock, HRO) Zur Auswertung der erweiterten Anfragen an den Katalogdienst werden neben den gespeicherten Metadaten Ontologien herangezogen. Es wurde im Rahmen des INGEOS-Projektes u.a. eine Ontologie erarbeitet, die die Struktur der Aufgaben in der Hansestadt Rostock sowie die Verknüpfung von Aufgaben und Organisationseinheiten darstellt (siehe Abb. 4).

7 Metadaten-Syndikation zur Unterstützung von GeoGovernment-Anwendungen Workflow-Integration Grundlage der Integration ist die Implementierung eines Katalog-Clients, der mit Hilfe von GetRecords-Anfragen an den Geo-Metadatenkatalog Geodienste und Geodaten finden kann. Dieser Katalog-Client kann dann in einem entsprechenden Intelligenten Webservice zur Anwendung kommen, um zu einem aus der Workflow-Engine gelieferten Prozessstatus Geodienste und Geodaten zu suchen. In Abbildung 5 ist dargestellt, wie diese Integration durch die Aufgaben-Ontologie (siehe Abb. 4) unterstützt wird. Des Weiteren werden vom Intelligenten Webservice (siehe Abb. 1) alle notwendigen Informationen an den INGEOS- Client übermittelt, dazu gehören unter anderem Informationen über den Status des Prozesses, zugehörige Rechtsgrundlagen und die Empfehlung, die die automatische Auswertung ergeben hat. Weiterhin werden Informationen zu den Geodiensten, die bei der Entscheidung helfen können, übertragen. Dies sind vor allem WMS-Dienste, die z.b. die Grünflächen, Bäume oder Spielplätze darstellen, sowie der WMS-Dienst, der den zur Veranstaltung gehörenden Lageplan speichert. Abb. 5: Workflow-Integration

8 158 G. Flach, A. Pakulat und M. Rust 4.3 INGEOS-Integrator Die grundlegende Anforderung an den INGEOS-Integrator ist, nicht oder schwach georeferenzierte Daten 7 in eine Geodateninfrastruktur zu integrieren (AUDERSCH 2005). Als Beispiel sei eine Fotodatenbank in einem proprietären Datenbanksystem gegeben, die neben den eigentlichen Bildern auch Metadaten wie Erstellungsdatum, fotografierende Person, Straße und Hausnummer aufnimmt. Um die Bilder innerhalb einer Karte visualisieren zu können, müssen in erster Linie scharfe Geo-Referenzen vorliegen. Dies ist für gängige Bilddatenbanken oder auch Content Management Systeme nicht gegeben. Es ist also nötig die Georeferenz für die Objekte abzuleiten. Dies kann mit Hilfe der vorhandenen Geodaten und weiteren Geodiensten erfolgen. Im Beispiel kann mit Hilfe eines Gazeteer- Services für eine Kombination aus Straße und Hausnummer eine Georeferenz berechnet werden und diese kann dann den dort aufgenommenen Bildern zugeordnet werden. Der INGEOS-Integrator soll an dieser Stelle dabei helfen passende Geodienste aufzufinden und die Verknüpfung von Datenfeldern mit Informationen eines Geodienstes zu verknüpfen. Abb. 6: Architektur des INGEOS-Integrators Eine entsprechende Umsetzung ist in Abbildung 6 dargestellt. Ein als Geodienst bereitzustellendes CMS wird im INGEOS-Integrator registriert und dabei werden die Datenfelder, die schwach georeferenzierte Daten enthalten, mit bestimmten vordefinierten Konzepten verknüpft. Im Beispiel einer MPEG-7-Bilddatenbank würden die Felder für Straße und Hausnummer mit dem Konzept Adresse verknüpft. Mit Hilfe einer entsprechenden Ontologie, die diese Konzepte mit Geodiensten verknüpft, und dem INGEOS-Catalog kann der INGEOS-Integrator nun einen passenden Geodienst, z.b. einen Gazetteer Service, finden. Die Verknüpfung der beiden Datenbestände wird dann automatisch für jede WMS oder WFS Anfrage durchgeführt, auf diese Weise können bestehende Datenbestände transparent als Geodienst in eine Geodateninfrastruktur eingebunden werden. 7 Fehlende eindeutige Geo-Koordinaten.

9 Metadaten-Syndikation zur Unterstützung von GeoGovernment-Anwendungen Prototyp Der bereits im VESUV-Projekt entwickelte Client (Behörden-Client) wurde für das INGE- OS-Projekt um zusätzliche GIS-Komponenten (semantisch angereicherte Geo-Dienste) erweitert. Hierzu gehört eine Komponente, die es erlaubt, mehrere Karten von verschiedenen WMS-Diensten darzustellen (siehe Abb. 7). Die Hauptaufgabe des Clients ist es, alle zum Vorgang gehörenden Informationen, die den Mitarbeiter unterstützen können, aus dem Prozess-Kontext heraus darzustellen. Es sind also neben den Antragsformularen und eingereichten Dokumenten Informationen zu den Rechtsgrundlagen (Juristische Ontologie) vorhanden und ebenso eine Darstellung des Workflow-Status. Die MapPanel-Komponente wird mit den vom Intelligenten Webservice gelieferten Informationen vorkonfiguriert und kann nicht nur auf bestimmte Karten eines oder mehrerer WMS-Dienste beschränkt werden, sondern es können auch bestimmte Teilebenen der Karte angezeigt werden. Die Konfiguration des MapPanels erfolgt über eine Liste von URL's, an denen das MapPanel die WMS-Capabilities-Informationen abrufen kann, und einer optionalen Liste der darzustellenden Kartenebenen. Diese Informationen werden vom Intelligenten Webservice mittels XML-kodierten Requests angefordert, um so die Präsentation relevanter Entscheidungsgrundlagen und Vorschläge zu ermöglichen. Abb. 7: Behörden-Client Die hier vorgestellte Überlappungsprüfung (liegt eine Veranstaltung auf einer Grünfläche) ist nur einer der Prozessschritte im Event-Management, in der Geo-Informationen im Behörden-Client helfen, eine Entscheidung zu treffen. Eine weitere Prüfung ist z.b. die Eigentümer-Analyse zu Beginn des Prozesses, bei der der INGEOS-Client entsprechende Informationen mit Raumbezug zur Verfügung stellt.

10 160 G. Flach, A. Pakulat und M. Rust 6 Zusammenfassung und Ausblick Mit der fortschreitenden Bereitstellung von Geoinformationen in öffentlichen Verwaltungen wird der Bedarf an der Integration dieser Informationen in bestehende, elektronisch geführte Verwaltungsprozesse immer größer (GeoGovernment). Darauf folgt die Notwendigkeit, in bestimmten Teilprozessen anwendbare Geoinformationen leicht auffindbar und zugreifbar zu machen. Im vorgestellten Anwendungsszenario Event-Management sind derartige geoorientierten Teilprozesse zu finden, für die eine Möglichkeit geschaffen wurde, entsprechende Geo-Dienste direkt in den Verwaltungsprozess zu integrieren. Hierzu wurde die bestehende VESUV-Architektur um einen ontologiebasierten Geo-Metadatenkatalog (ISO 19115, 19119) erweitert. Die wichtigsten Anforderungen an das zu entwickelnde System waren eine möglichst umfangreiche Beschreibung der Geoinformationen mit Metadaten, die Verknüpfung mit einer Wissensbasis und die Integration einer Such- und Assistenz- Funktionalität in den Prozess (Intelligenter Web Service). Die prozess-bezogene Bereitstellung von Geoinformationen im Client für den Sachbearbeiter realisiert eine geo-orientierte Assistenzfunktion bei der Bearbeitung von Verwaltungsprozessen. Gegenstand aktueller Entwicklungsarbeiten ist die Spezifikation relevanter Ontologie- Erweiterungen zur verstärkten Kopplung zwischen Workflow, Domänen-Wissen und Kontext-Bezug (Aufgaben-Assistenz) sowie die Integration von juristischen Regelwerken (Gesetze, Verordnungen) zur wissensbasierten Ablaufsteuerung der Teilprozesse mit Raumbezug. Literatur AUDERSCH, S. & FLACH, G. (2005): egovernment Interoperable Services in distributed administrative processes. COMPUTER GRAPHIC Topics, 2/2005. AUDERSCH, S. (2005): Universeller Gateway-Ansatz auf der Basis semantisch angereicherter Web Services im Rahmen heterogener egovernment-anwendungen. In Tagungsband: 16. Workshop über Grundlagen von Datenbanken. FITZKE, J. (2003): deegree Catalog Service Freie Software an der GDI-Basis. In: Internationales Symposium Geodateninfrastruktur, INPSIRE Infrastruktur for Spatial Information in Europe. FLACH, G. (2005): Integration von GIS und egovernment-lösungen. In Tagungsband: 1. GeoForum Mecklenburg-Vorpommern, Rostock-Warnemünde. NEBERT, D. (2004): OpenGIS Catalogue Services Specification. Technical Report, Open Geospatial Consortium. STROBL, J. & GRIESEBNER, G. (2003): geogovernment Öffentliche Geoinformationsdienste zwischen Kommune und Europa. Wichmann-Verlag. Heidelberg. VOGES, U. & SENKLER, K. (2005): OpenGIS Catalogue Services Specification 2.0 ISO 19115/ISO Application Profile for CSW 2.0. Technical Report, Open Geospatial Consortium.