SNS. Umweltbundesamt Integration in gein

Transkript

1 3.2.4 Integration in gein Aus Sicht des SNS ist gein zunächst ein Client unter vielen. Daher erfolgt die Einbindung vollständig über dieselben Methoden, die allen potentiellen Nutzern angeboten sind. Es zeigte sich als erstes, dass die direkte Einbindung über die Java API nicht ohne weiteres möglich ist: die Application Server der beiden Systeme sind nicht miteinander kompatibel, daher konnten sie nicht auf demselben Rechner implementiert werden. gein verwendet die JServ ( SNS das modernere Tomcat ( Eine Umstellung von gein auf Tomcat war im gegebenen Projekt nicht zu leisten, und eine Integration von SNS mit JServ kann nicht empfohlen werden, da JServ heute nicht mehr weiter entwickelt wird. Da jedoch bis Juni 2003 eine Portierung von gein auf TomCat durch die Koordinierungsstelle UDK/GEIN (KUG) zu erwarten ist, kann diese Option gegebenenfalls später aufgegriffen werden. Eine Lösungsmöglichkeit aus der Sicht einer Java API wäre in dieser Situation eine Verteilung auf zwei Rechner, die mit Java Remote Procedure Calls kommunizieren, wie es z.b. im virtuellen UDK implementiert ist. Dieses Verfahren hätte jedoch keine zwingenden Vorteile gegenüber einer Verwendung der ohnehin implementierten Web Services. Daher wurden gein und SNS ausschließlich über Web Services integriert. gein selbst ist daher das lebende Beispiel für jeden potentiellen Anwender des SNS Übersicht Abbildung 21 zeigt eine Übersicht der funktionalen Module beider Systeme und die Pfade ihrer Integration. Gegenüber dem bestehenden gein Broker kann man die neuen Module von SNS in drei Klassen einteilen: Module, die entsprechende Funktion in gein ersetzen sollen (Indexierung, integrierte Topic Map), Module, die optional genutzt werden können (Dokumentenindex, parallel indexing), Module, die in gein überhaupt nicht vorhanden sind (Topic Map Pflege) (v.62)

2 gein SNS Rechercheoberfläche Indexierung (alt) Index-Management Dokumentenindex UmThes GeoThesaurus Umweltkalender W E B S E R V I C E Indexierung (neu) parallel indexing Dokumentenindex (optional) Topic Map Pflege integrierte Topic Map Administration Webseitengenerierung künftig nicht genutzt mögliche Variante POST-Schnittstelle Abbildung 21: Integration von gein und SNS Indexierung (neu) Dieses SNS-Modul implementiert die Textanalyse und automatische Verschlagwortung eines einzelnen Dokuments und ersetzt die Indexierung (alt). Es ist ausführlich beschrieben in Kap Diese Funktionalität wird vom gein Broker an zwei Stellen benötigt: 1. aus der Rechercheoberfläche zur Verschlagwortung einer Suchbedingung, und 2. bei der automatischen Verschlagwortung der Informationsangebote, gesteuert vom Index-Management. In beiden Fällen werden im gein Broker die bisherigen lokalen Methodenaufrufe in gein umgelenkt und über die Web Services abgedeckt. Hierzu werden die Client-Stubs wie in beschrieben verwendet. Zwischen den Client-Stubs und den bestehenden Methodenaufrufen wurde eine dünne Schicht eingezogen, die die erforderlichen Abbildungen vornimmt, z.b. vom neuen Java Bean KTAbstactTopic zur bisherigen Klasse Keyword Topic Map / Thesauri Die bestehenden Thesauri (UmThes, GeoThesaurus, Umweltkalender) in der Datenbank des gein Brokers werden vollständig durch die Topic Map in SNS ersetzt. Das bedeutet auch, dass die Rechercheoberfläche beim Navigieren im Wortgut gezielt auf einzelne Topics (v.62)

3 zugreift über den Web Service sns:getpsi. Ebenso wie für die Indexierung werden dabei die Client-Stubs und eine Anpassungsschicht benutzt, um zwischen Topic und Keyword zu konvertieren Index-Management und parallel indexing Das Index-Management des gein Brokers umfasst verschiedene Aspekte wie Aufbau der URL-Listen (Gesamtindex und Aktuelles ) in unterschiedlichen Zyklen, sequentielles Abarbeiten der URL-Liste mit der Indexierungsfunktion, Überprüfung der URL des Dokumentenindex auf Erreichbarkeit, usw. Dieses Management bleibt grundsätzlich unberührt. Allerdings beinhaltet SNS zum Abarbeiten von URL Listen eine parallel indexing engine, welche die Maschinenleistung voll ausnutzt, um mehrere Dokumente in einzelnen Threads parallel zu verschlagworten. Damit kann die Gesamtlaufzeit einer Aktualisierung des Dokumentenindex deutlich reduziert werden. Dies ist angesichts der stark gewachsenen Dokumentenmengen (und der wesentlich aufwändigeren Textanalyse) eine wünschenswerte Verbesserung. Allerdings lässt sich diese Parallelisierung nicht ohne weiteres über Web Services anbieten. Eine Integration des parallel indexing war im Projekt bisher nicht vorgesehen. Hier drei mögliche Verfahren: 1) gein übergibt die URL Liste per Web Service Request an SNS. SNS arbeitet diese parallel ab und gibt alle neu erstellten Verschlagwortungen zurück. Dazu müsste geprüft werden, welche Anteile des Index-Managements von SNS übernommen werden müssten. Doch in jedem Falle stoßen wir hier an die Grenzen des oben beschriebenen Request-Response Verhaltens ( ). Auch parallel beschleunigt treten hier je nach Dokumentenmenge Laufzeiten zwischen Request und Response auf, die für das Request-Response Modell nicht mehr vertretbar sind. Der Broker könnte jedoch in einem ersten Request die URL-Liste übergeben, was von SNS lediglich quittiert wird. Ist die Liste abgearbeitet, startet SNS einen zweiten Request, welcher den erstellten Dokumentenindex (oder nur eine URL des eigentlichen Index) übergibt. Damit entsteht jedoch Kommunikation in beiden Richtungen: der gein Broker träte hier erstmals in der Rolle eines Servers auf. Der Service besteht zwar lediglich daraus, den Dokumentenindex entgegenzunehmen, aber implementierungstechnisch bedeutet dies einen Unterschied, der zu beachten wäre. 2) Das Modul für das parallel indexing wird direkt in den gein Broker eingebaut. Bei dieser Lösung reduziert sich die Kommunikation auf die Einbindung der SNS Indexierung über sns:autoclassify. Durch die Parallelität würden hier stets mehrere Web Service Requests nebeneinander offen sein, was aber nach den bisherigen Erfahrungen unproblematisch ist. 3) wie in 1), aber SNS speichert den Dokumentenindex selbst und wird über die POST- Schnittstelle in die Suche eingebunden. In diesem Fall müsste natürlich im SNS die POST Schnittstelle implementiert werden wie bei jedem anderen Teilnehmer auch. Das ist für das einfache g2k:resultset nicht allzu aufwändig. Da SNS aber keine eigene Oberfläche zur Anzeige von Ergebnismengen besitzt, kann g2k:metaresult nicht ohne weiteres angeboten werden. Die Nutzung des parallel indexing durch gein ist im Projekt nicht enthalten. Empfehlenswert ist vor allem die Variante 2), dies wurde bereits für die Weiterentwicklung von gein vorgeschlagen (v.62)

4 Dokumentenindex Outsourcing? Die XML Topic Map Engine besitzt einen eigenen Dokumentenindex, der nach den bisherigen Konzepten von gein jedoch nicht genutzt werden sollte, da gein bereits einen eigenen Dokumentenindex hat. Wenn SNS als allgemeiner Service für Umweltinformationssysteme von Bund und Ländern gesehen wird, dann muss die Frage allgemeiner gestellt werden: Soll SNS als weiteren Service das out-sourcing von Dokumentenindizes und folglich einen Rechercheservice bieten? Natürlich wäre das technisch ohne weiteres machbar. Die Frage ist, ob der Betreiber und die Nutzer dies wünschen und ob entsprechende Datenbank-Kapazitäten usw. verfügbar gemacht werden können Webseitengenerierung Die Generierung der gein Webseiten des Umweltkalenders erfolgt nun aus den Event- Topics des SNS, auf welche der gein Broker über den Web Service sns:findtopics zugreift G2K Profil ( POST-Schnittstelle ) und G2k-Deskription Das G2K Profil, Version 1.1 vom 14. Februar 2000, ist seit 2000 von neun an gein angeschlossenen Datenbanken implementiert worden (GISU,ULIDAT, UFORDAT, GSBL, UPB, UOK, FloraWeb, WebDIM und UDK) und trägt damit wesentlich zu einem stabilen und umfangreichen Informationsangebot bei. Es handelt sich um einen Satz von XML Formaten zum Austausch von Nachrichten zwischen gein und Teilnehmern mit Datenbankanschlüssen. In diesem Schema sind sechs Nachrichten kodiert (G2k, 2000): Nachricht Inhalt Kontext Gesendet von simplesearch Suchbedingung Textsuche gein request simpleresultset Ergebnisliste Textsuche Teilnehmer response detailedquery Suchbedingung Detaillierte Suche gein request detailedresultset Ergebnisliste Detaillierte Suche Teilnehmer response metaresult Ergebnisverweis Text- und Detaillierte Teilnehmer response Suche exception Fehlermeldung Generell Teilnehmer response Die beiden Nachrichten der Detaillierten Suche enthalten Verweise auf das gein - Wortgut, welches nun in SNS integriert wurde. Die SNS-Feinspezifikation hat hierfür ein neues, erweitertes Profil vorgeschlagen, welches auf dem Occurence-Paradigma der Topic Map aufbaut und alle Topic Typen verwenden kann (FS-SNS, S.43). Die genauere Betrachtung und die Art der Realisierung in SNS hat ergeben, dass die Formate nicht geändert werden müssen, da für den Dokumentenindex in der abschließenden Realisierung das Occurrence Element der Topic Map nicht verwendet wurde (vgl ) und alle implementierten Topic Typen im bestehenden Profil kommuniziert werden können. Insbesondere sieht <g2k:time> bereits als Option die Übergabe einer Ereignis-ID vor auch wenn dies bisher nicht genutzt wurde. Allerdings existierte für das Profil zwar ein Dokument mit erläuterten Beispielen, aber keine formale Definition, also weder eine Dokumenttypdefinition (DTD) noch ein XML Schema. Der Austausch erfolgt bis heute formlos als Textkonstante im Body eines HTTP POST Requests bzw. der zugehörigen Response (v.62)

5 Die Feinspezifikation hat hierzu vorgeschlagen, diese sogenannte POST-Schnittstelle künftig durch SOAP bzw. einen Web Service zu ersetzen. Dieser Service müsste allerdings bei den Informationsanbietern eingerichtet werden, denn der gein Broker ist hier in der Rolle des Clients. Derzeit braucht diese Umstellung nicht angegangen werden, denn sie würde in der bestehenden Kommunikation keine erkennbaren Veränderungen erbringen. Von Interesse ist ein Web Service an dieser Stelle für künftige neue Teilnehmer, die mit dieser Technik arbeiten wollen. Von Vorteil wären die größere strukturelle und semantische Kontrolle sowie die Verfügbarkeit standardkonformer Open-Source Bausteine. Um dies zu ermöglichen, wurde zunächst ein XML Schema entwickelt, welches exakt das bestehende G2k-Profile Version 1.1 definiert, so dass die unveränderten Nachrichten mit diesem Schema als Web Service aufgesetzt werden können. Die Nachrichten müssten dazu allerdings doch in ihrer Kopfzeile in einem Punkt angepasst werden: Sie müssen einen Verweis auf das Schema enthalten, damit der Parser wie gewünscht validieren kann. Ausschließlich aus diesem Grund unterscheiden sich die Nachrichtenformate, und daher muss formell eine neue Version 1.2 eingeführt werden. Die bisherige Kennzeichnung lautete: <g2k:g2k xmlns:g2k=" Dies muss nun durch eine xsi:schemalocation ergänzt werden. Ausschließlich dadurch ändert sich das XML-Format. Die Kennzeichnung lautet nun: <g2k:g2k xmlns:xsi=" xmlns:g2k= xsi:schemalocation= > ist der Namespace-Name der Version 1.2, und ist die URL der zugehörigen Schema-Definition. Für die bestehenden Schnittstellen ist dies ohne Bedeutung. In diesen Fällen ist die Gültigkeit der verwendeten Formate durch praktische Tests nachgewiesen bzw. hergestellt. Künftige Teilnehmer können mit dem Schema nun allerdings ihre Formate zunächst gegen einen validierenden Parser testen, und die Implementierung als Web Service wird so ermöglicht. Bei der Entwicklung des Schemas wurde entschieden, ein einziges Schema für alle Nachrichten zu schreiben. Da jeder Request und jede Response aber nur eine einzige Nachricht enthalten kann, wurden die Nachrichten mit <xs:choice> gruppiert, was genau dies abbildet. Die <description> wurde mit einer gewissen Toleranz definiert, um sowohl die Ergebnisse der Freitextsuche als auch der Detaillierten Suche abzubilden. Elemente und Attribute, die nicht von allen heutigen Teilnehmern verwendet werden, sind optional definiert und können weiterhin weggelassen werden. Bekannte Probleme tauchten auf bei der Wahl des Datentyps für Zeitangaben. Das G2K- Profil folgt hier ISO 8601 (vgl. G2k, 2000, Kapitel 2.2 Zeitangaben) und ist zugleich konform zu W3C Note Date and Time Formats ( Das Besondere dieses Zeitformats ist seine Toleranz gegenüber der gewählten Genauigkeit. Gültig sind beispielsweise 1999", " ", " ", " T23", " T23:59. Bereits bei der Implementierung in Java im Jahre 1999 fiel auf, dass es keinen dem exakt entsprechenden Datentyp gibt. Leider bestätigte sich dies auch für die eingebauten Datentypen in XML Schema hier existieren lediglich verschiedene Datentypen für jeweils exakte Genauigkeiten, also z.b. Jahr, Datum, Datum mit Uhrzeit. Eine einfache Lösung fand (v.62)

6 sich in den Recommendations for XML Schema for Qualified Dublin Core (UKOLN, 2002). Hier wurden die verschiedenen exakten Datentypen durch eine Union integriert: <xs:union membertypes="xs:gyear xs:gyearmonth xs:date xs:datetime" /> ( Damit sind alle vorgesehenen Genauigkeiten für Zeitangaben einzeln aufgeführt und zulässig. Diese Lösung wurde in das G2k-Schema übernommen Abbildungen zwischen g2k:time und topic.event In die Recherche-Oberfläche wurde die Indexierung von SNS (sns:autoclassify) so integriert, dass diese Oberfläche selbst dadurch unberührt bleibt. Das bedeutet: die Ereignisse und ihre Assoziationen zu Deskriptoren und Orten werden vom gein Broker hier noch ignoriert. Es ist von gein aus noch nicht geklärt, in welcher Weise auf die Ereignistypen und ihre Assoziationen eingegangen werden soll. In der gesamten bisher beschriebenen Kommunikation kommt zum Tragen, dass gein den Ereignistyp topic.event nicht semantisch gleichberechtigt verarbeitet. Zwar werden die Ereignisse im Umweltkalender aufgelistet, und man kann mit jedem Ereignis eine Recherche initialisieren. Jedoch werden Ereignisse von der Textanalyse nicht erkannt und auch nicht im Dokumentenindex verzeichnet. Das bisher in gein verwendete g2k:time beinhaltet eine Zeitangabe (Zeitpunkt oder Zeitraum). Die Indexierung erkennt und verarbeitet Zeitangaben im analysierten Text, geht dabei jedoch nicht auf die Ereignisse ein. Dies ist erst in SNS implementiert. Dort ist ein Event-Topic völlig gleichbehandelt, d.h. es wird auch von der Indexierung und im optionalen Dokumentenindex verwendet. Wenn also gein die SNS-Indizierung (oder auch den SNS-Dokumentenindex) nutzt, dann muss zwischen g2k:time und topic.event konvertiert werden. Von topic.event nach g2k:time scheint dies leicht: alle in den gewählten Events vorkommenden Zeitangaben werden so behandelt, als wären sie in einem gemeinsamen Dokument vorgekommen. Heraus kommt immer ein Zeitpunkt oder Zeitraum. Die Semantik des Events geht dabei allerdings verloren und kann auch schon bei der Umsetzung in Zeitangaben fehlinterpretiert worden sein. Daher kann der Vorgang auch nicht sicher umgekehrt werden. Hier muss versucht werden, mit den Zeitangaben aus g2k:time und den Assoziationen zwischen infrage kommenden Events und anderen Topics des aktuellen Kontexts zu entscheiden. Es sollte unbedingt angestrebt werden, gein durch eine volle Integration des Ereignis-Typs aufzuwerten. Dies erfordert allerdings grundlegende Eingriffe und kann auf verschiedene Weise gelöst werden. Dies konnte im hier abgeschlossenen Projekt nicht mehr geleistet werden (v.62)