Workshop "Web Services", Tübingen, 27-29 April 2009

Zusammenfassung

Hauptziele dieses Workshops waren a) die Abstimmung zwischen den Webservice und Workflow-bezogenen Arbeiten in CLARIN und D-SPIN b) Erstellung eines gemeinsamen CLARIN Dokuments für CLARIN Workpackage 2, (erster Teil des Workshops) sowie c) die Abstimmung über das weitere Vorgehen bei der Einbindung von Tools und Ressourcen als Webservices in Workflows innerhalb des D-SPIN-Projekts (zweiter Teil).

Der erste Teil erstreckte sich auf den ersten Tag und die erste Hälfte des zweiten Tages, der zweite Teil über den zweiten Teil des zweiten Tages und den dritten Tag.

Teilnehmer

Tag 1:

Tag 2:

Tag 3:

Dokumente

Erster Tag / Zweiter Tag

Am ersten Tag wurden Fragen der Infrastruktur besprochen, die über die konkrete Implementierung der D-SPIN Webservices hinausgehen. Nahziel von CLARIN Seite ist es, die Anwesenden in die kollaborative Erstellung eines Spezifikationsdokumentes einzubeziehen (s. dazu oben, Dokument "Requirements Specification Web Services and Workflow Systems"). Ein wichtiger Punkt ist die Einbeziehung eines Service-Bus, der zwischen dem Benutzer bzw. der GUI und den konkreten Webservices steht. Marco Büchler wird weitere Informationen zu verfügbaren Servicebus-Tools sammeln und zur Verfügung stellen. Im Rahmen von CLARIN wird ein solcher Servicebus in Nijmegen implementiert werden. Das vor allem von Helmut Schmid definierte Textformat für die Interaktion von textuellen Daten mit Webservices wird von allen Seiten gutgeheißen, die Weiterentwicklung um weitere Datentypen (z.B. Named Entities) und die Erstellung weiter Pivot-Formate, z.B. für lexikalische Ressourcen wird beschlossen. Des weiteren werden Fragen der Metadaten für a) Webservices b) für Daten, die Eingabe in Webservices und Ausgabe von Webservices sind, besprochen. Die Ergebnisse fließen in das o.g. Spezifikationsdokument ein.

Dritter Tag

Tagesordnung

:

  1. LRT Summit Mannheim
  2. Integration weiterer Webservices
  3. Aspekte der Evaluation
  4. Ad 1. Es wird abgesprochen, welche Partner Demos in Mannheim geben werden, parallel zur Postersession. Webservices spielen dabei verschiedene Rollen: entweder als primäres Objekt der Demo oder als Teil der Maschinerie im Hintergrund (z.B. Berliner Demo). Mannheim sichert denen, die Demos geben, technische Hilfe zu und wird die Partner weiter über die technische Infrastruktur in Mannheim auf dem Laufenden halten.

    Ad 2. BBAW arbeitet an Wrappern für ihre Webservices, von denen momentan ein Tokenizer, eine eingeschränkte Form des NER-Tools und einige kleinere Werkzeuge angeboten werden können (Soundex, ?Meinten-Sie?). TZ merkt an, dass dies sie Möglichkeit von parallelen, vergleichenden Analysen auf der Ebene der Tokenisierung erhöht. NE ist eine neue Annotationsebene, die im D-SPIN TextCorpus-Format berücksichtigt werden muss. Darüber werden sich JD und Helmut Schmid verständigen.

    Lpzg hat ca. 50 Datenservices und einen Tokenizer für das Altgriechische (eAqua) anzubieten.

    Mannheim ist im Moment noch nicht so weit, wird aber im Wesentlichen Datenservices anbieten. Stgt wird den Tokenizer und den Treetagger sowie eine Chain für die Extraktion von Kollokationen anbieten und das TextCorpus-Austauschformat weiterentwickeln.

    Deadline für die Integration neuer Tools in die D-SPIN WS/WF-Infrastruktur sollte Ende Mai sein. LL wird von Tübingen aus am 2. Oder 3. Juni eine virtuelle Konferenz aller beteiligten Parteien initiieren.

    Anmerkung von MB: seiner Erfahrung nach sind es die ?einfachen? Services wie Tokenisierung und Grundformenreduktion, die von GWern nachgefragt bzw. akzeptiert und genutzt werden.

    REST vs. SOAP: TZ berichtet, dass der Tübingen UIMA-Kontakt zu REST geraten hat. MB berichtet aus seiner Erfahrung, dass für eine Infrastruktur mit einer überschaubaren Zahl von Services REST die bessere Wahl ist. Es wird deshalb bei der REST-Architektur bleiben

    Es ist noch zu klären, wie PIDs für REST-Servicecalls aussehen könnten. Dies ist mit den CLARIN-Spezialisten zu klären.

    Zum Thema ServiceBus soll die enge Absprache mit dem MPI bzw. Vorgaben aus CLARIN WP2.6/7 abgewartet werden. MB wird nach dem 9. Mai eine Liste von Experten für dieses Thema erstellen sowie eine Liste von ServiceBus-Anbietern erstellen. Das Problem der Aufblähung von Dateien durch das reiche und möglicherweise redundante XML-Format soll erstmal nicht angegangen werden.

    Ad 3.

    JD schlägt benutzerzentrierte Tests der Webservices und Chains vor, Aufgabe von AP3, das von Berlin geleitet wird.

    MB: interessante Aspekte ? auflisten, was da ist und bereitgestellt werden kann. Genaue Dokumentation des Entwicklung s- und Deploymentaufwandes; Fokus auf den Chaining-Aspekt legen.

    Es gibt also drei Aspekte der Evaluierung, die angegangen werden sollten:

    • Entwicklungsaufwand für die Integration von Services (Wrapper etc)
    • Performance der Services und Chains
    • Usability

    MB: wenn man Webservices bereitstellt, muss man mit einer hohen Last rechnen, sobald die Existenz dieser Services bekannt ist, mehrere Millionen Anfragen am Tag sind in Lpzg keine Seltenheit.

    Was für das Projekt wichtig wäre, ist die Darstellung des Mehrwertes von kombinierten Webservices gegenüber einer Stand-alone-Arbeitsplatz-Lösung, wie sie jetzt üblich ist.

    LL merkt an, dass man vom typischen ?Kunden?, also GWern nicht erwarten kann, dass sie Tools installieren und mittels Skriptsprachen verknüpfen. Die reine Existenz von bedienbaren Webservices könnte also schon ein Mehrwert sein.

    KB schlägt vor, das Feedback von Benutzern über Feedbackformular und/oder Bugtracker zu erfassen und in einen Dialog mit den Entwicklern einzubringen.