cygri’s notes on web data

Noch einmal Elena Paslaru. Wie bei ihrem gestrigen Vortrag betont sie, dass die Annahme ihres Vortrags nichts mit dem Fakt zu tun hat, dass ihr Chef Organisator der Konferenz ist. Hm.

Gemeinschaftsprojekt mit dem Institut für Pathologie der Charité Berlin. Alle histologischen Befunde (medizinische Bilddaten), die im täglichen Betrieb anfallen, sollen digital erfasst werden. Jährlich 75.000 Befundbilder. Übliche Lösungen gehen nicht gut: Image Retrieval allein reicht nicht, da auch Ausschnitte der Bilder annotiert werden sollen. Text Retrieval funktioniert für die Pathologieberichte, aber nicht für die Bilder.

Textfragmente der Berichte werden mit Bildausschnitten verknüpft. Inhalt der Texte wird mit medizinischen Ontologien annotiert, um die Suche zu verbessern. Eine Natural Language Processing-Komponente gibt es auch, die ist aber nicht Teil des Vortrags.

Komplexer Ontology Engineering Prozess.

Evaluierung diverser Editoren, Visualisierungstools, Reasoning Engines, Triple Stores. Gut: Protégé, Jena, RACER, FaCT, Sesame

Reasoning ist zur Zeit noch kaum praktikabel, Rules gar nicht.

Um Jena2 kommt man zur Zeit nicht herum.

Ontologien mit mehr als 100 Konzepten sind performancetechnisch unpraktikabel.

Karsten Tolle, Johann Wolfgang Goethe-Universität Frankfurt/Main

Dieser Vortrag ist interessant für mich, da das Thema recht nahe an Named Graphs ist, woran ich zur Zeit mit Chris Bizer arbeite.

Beim Umgang mit RDF-Informationen ist es wichtig, den Kontext der Informationen zu kennen. Er hilft unter Anderem bei der Beurteilung der Vertrauenswürdigkeit der Aussagen.

Karsten Tolle unterscheidet zwischen externem Kontext (Provenance, Namensräume etc.), internem Kontext (Umgebung im RDF-Graph) und zusätzlichem Kontext (Metainformationen über Tripel etc., leider im Vortrag weitgehend ausgespart).

Die heutigen RDF-Standards bieten keine ausreichende Möglichkeit, um solche Kontextinformationen explizit zu erfassen. Es gibt zwei Ansätze: Quads erweitern die üblichen RDF-Tripel aus Subjekt, Objekt und Prädikat um ein viertes Element, das Quelle oder Kontext bezeichnet. Sehr mächtig, aber nicht besonders kompatibel mit der RDF-Semantik. Die Alternative sind Tripel mit Kontext. Karsten Tolle findet sie besser, da man durch einfaches Weglassen des Kontexts abwärtskompatible RDF-Tripel bekommt.

eRQL (easy RQL) ist eine supereinfache, Google-style RDF-Anfragesprache. Sie soll großmutterkompatibel sein. Beispiele:

bridge sucht das Wort in allen Literalen oder URIs, case insensitive
<bridge;1,2,3> sucht aus Quellen 1,2 und 3
<~~~bridge> sucht mit Graph-Umgebung der Größe 3 (nett!)

Es gibt eine Implementierung.

Mir stellt sich die Frage, ob eine großmuttertaugliche RDF-Abfragesprache nützlich ist. Die Ergebnismenge wäre ein RDF-Schnipsel, der wahrscheinlich voll von URIs und RDF-Datatypes ist. Wie man so etwas für Großmütter aufbereitet, bleibt eine offene Frage.

Mich interessiert das Feld zwischen beiden Extremen. Ein halbwegs intuitives und kompaktes XPath für RDF wäre nett.

Universität Stuttgart & IBM Software Group

Frank Leymann beschreibt IBM’s Vision von Web Services und Grid Computing. Ziel ist die Virtualisierung von Geschäftsressourcen und von Hardware. Es soll möglich werden, Geschäftsanwendungen auf einer sehr hohen Abstraktionsebene zu bauen. Durch Zusammenstecken (Choreography, Flow) von Web Services.

70% aller Softwareausgaben in großen Unternehmen liegen im EAI-Bereich.

“Web Services haben in Wirklichkeit kaum etwas mit Web zu tun; Web Services sind Hardcore-EAI-Technologie”

Frank Leymann gibt eine Tour durch einige der WS-Standards. Es gibt viele, aber sie sind nötig, und modular. Schon die Kombination weniger Standards löst echte Probleme. WS-* kann scheibchenweise implementiert/eingeführt werden.

WS-* sieht aus wie CORBA, warum sollte es diesmal klappen? „Keine Ahnung …“ Aber es gibt breite Unterstützung für WS-* quer durch die Industrie.

Ich sehe WS-* mit Skepsis. Ja, damit soll ein echtes Problem gelöst werden. Die Ziele sind valide. Die Architektur scheint gut durchdacht zu sein. Es wäre toll, wenn wir so arbeiten könnten.

Es ist aber sehr weit entfernt von der heutigen Realität. Ich glaube nicht, dass man ein derart komplexes System top-down bauen kann. Ich glaube, hier gilt Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked.

Niemand will mehr 17″-Laptops kaufen, schreibt der Inquirer. 15″- und 12″-Modelle hingegen erfreuen sich weiterhin steigender Beliebtheit.

Wen überrascht’s? Mich nicht. Seit Jahren verwunderen mich Leute, die freiwillig solche Dinger kaufen und mit sich rumschleppen (oder dann eben zu Hause stehen lassen). Ein Laptop muss klein und leicht sein. Wenn ich ihn nicht komfortabel überall hin mitnehmen kann, dann ist die Investition relativ sinnlos. Selbst mein 12″-Laptop ist noch zu sperrig. Ein noch kleinerer Formfaktor würde leider zu Lasten der Tastatur gehen.

(via Engadget)

Der Vortrag ist Teil des Doktorandenworkshops der Berliner XML-Tage 2004.

Alexandru Berlea, TU München. Er zeigt, dass XML-Schemasprachen zu EBNF-artigen Grammatiken äquivalent sind, und dass Produktionen solcher Grammatiken als Abfragen auf XML-Bäumen dienen können. Er hat Abwandlungen von XPath und XSLT implementiert (Fxgrep und Fxt), die sehr effizient arbeiten und einige neue mächtige Abfragekonstrukte bereitstellen. Fxgrep riecht nach regulären Ausdrücken. Ich kenne leider XPath kaum, und der recht theoretische Vortrag war der letzte des Tages, so dass ich teilweise nicht mehr ganz folgen konnte.

Der Vortrag gehört zum Doktorandenworkshop der Berliner XML-Tage 2004.

Elena Paslaru, Freie Universität Berlin, arbeitet in der Gruppe von Prof. Robert Tolksdorf.

„Ich habe extra auf die Torte verzichtet …“ (Danke!)

Evaluation, Austausch und Wiederverwendung von Ontologien sind ungelöste Probleme. Ontologien können mehr oder weniger formal sein, wurden vielleicht nur für eine bestimmte Aufgabe entworfen, enthalten implizite Annahmen über die Welt und eine implizite Sicht auf die Domäne. Beispiel Medizin: Mehr als 100 Ontologien existieren, aber wer soll die für ein Projekt evaluieren, und wie?

Ansatz, um Vergleichbarkeit herzustellen: Kontext explizit machen. Für welchen Zweck wurde die Ontologie entworfen? Welche Anwendung hat sie zuerst benutzt? Wie (manuell, Text Processing?) und von wem wurde sie erstellt? Mit welcher Sprache (Gerade im Medizinbereich gibt es nicht nur OWL)? Welchen Sachbereich deckt sie ab? Das alles soll als RDF/OWL erfasst werden.

Natürlich gibt es da wieder das klassische Metadatenproblem: Wer erfasst diese Informationen? Frau Paslaru legt den Schwerpunkt auf automatische Verfahren, die für viele, aber nicht alle dieser Fragen funktionieren könnten.

In der Diskussion wurden Parallelen zwischen Ontologien und e-Learning-Materialien gezogen. Bei beiden stellt sich das Problem, dass Evaluierung, Anpassung und Einarbeitung so aufwändig sein können, dass sich Wiederverwendund nicht lohnt, und bei beiden entstehen ist Verallgermeinerung sehr teuer. Das ist eine interssante Analogie. Aber man muss sehen, dass es bei Ontologien Netzwerkeffekte gibt, die Wieververwendung nicht einfacher, aber attraktiver machen.

Der Vortrag ist Teil des Doktorandenworkshops der Berliner XML-Tage 2004.

Lutz Maicher ist Promotionsstudent an der Universität Leipzig. Er befasst sich mit Topic Maps und diskutiert das Problem der Assoziation zwischen Topics und ihrer Entsprechung in der realen Welt. Eine scharfe 1:1-Zuordnung ist in der Praxis nicht möglich. Außerdem gibt es das (auch in der RDF-Welt viel diskutierte) Problem, dass eine URI sowohl ein Lokator als auch ein Name sein könnte, also z.B. sowohl die Homepage von Herrn Meyer als auch Herr Meyer selbst bezeichnen könnte. Weiterhin das Problem des Merging: Wie stellt man fest, dass zwei URIs das gleiche Thema beschreiben (Siehe owl:InverseFunctionalProperty et al. in RDF-Land).

Sein Lösungsansatz nennt sich Subject Indentity Measure (SIM). Es ist eine Heuristik zur Ermittlung der Ähnlichkeit zwischen Themen. Anhand der Ähnlichkeit kann entschieden werden, ob verschiedene Topics das gleiche Subject bezeichnen. Wichtigstes Merkmal der Heuristik ist die String-Ähnlichkeit der Topic Names.

Sein Algorithmus erzielt sehr gute Resultate bei Topic Maps, die aus Bibliothekskatalogen erzeugt wurden. Mit anderen Maps hat er bisher nicht getestet (MP3-Sammlungen?).

Er erwähnt mögliche Verbesserungen: Eineziehung der Typen der Topics, Anaylse der Nachbarschaft der Topics.

Eine nicht diskutierte Problematik ist auch, dass das Konzept der „Identität“ stark vom Kontext abhängt. Ein Restaurant zieht in neue Räume um, eine neue Bewirtung übernimmt die alten Räume. Ist es noch das gleiche Restaurant? Kommt darauf an, ob man der Vermieter oder ein Stammgast ist.

Oliver Hinz, Johann Wolfgang Goethe-Universität Frankfurt/Main.

Mikroökonomie: Verschiedene Konsumenten sind bereit, verschieden viel für ein Produkt zu bezahlen. Ziel des Anbieters: möglichst viel davon abschöpfen, indem an jeden Konsument zum maximalen Preis verkauft wird, den er zu zahlen bereit ist.

Reverse Pricing heißt, dass Konsumenten selbst den Preis festlegen. Im einfachsten Fall darf er nur ein mal bieten. War sein Preis zu niedrig, dann bekommt er nichts. In anderen Varianten darf der Käufer mehrfach bieten. Im Gegensatz zu Auktionen gibt es keine Konkurrenz zwischen den Käufern.

Hinz stellt eine Implementierung von Reverse Pricing vor: die Handelsplattform uPrice. Für meinen Geschmack zu wenig verwertbare technische Details.

Postulat: Gängige Standards (ebXML usw.) müssen erweitert werden, da sie nur Fixpreise unterstützen.

Interessantes Thema. Mal wieder einer dieser kurzen Momente, in denen ich denke, ich hätte BWL studieren sollen.

Kay-Uwe Schmidt, Fraunhofer Institut für Offene Kommunikationssysteme.

Groupware ist entscheidend für die Zusammenarbeit in verteilten Arbeitsgruppen. Groupware wird aber nur selten erfolgreich in Organisationen eingereicht. Teammitglieder haben ihre eigenen PIMs (Kalender, Aufgabenlisten, Adressbuch usw.), und sind in der Praxis kaum bereit, alle Informationen nochmals in einer separaten Groupware einzupflegen.

Die vorgestellte Lösung ist, die PIMs mit Web Services lose zu koppeln. Die Entwicklung einer einheitlichen Webservice-API ist aber in der Praxis schwierig. Statt dessen sollen verschiedene Webdienste über eine „Matchmaking Engine“ kommunizieren. Das wird ermöglicht, indem die einzelnen Dienste mit OWL-S beschrieben werden.

Das Ganze wurde für zwei PIMs implementiert, darunter Outlook. Bisher ist nur der Austausch von Terminen implementiert. Die Implementierung dauerte einen Monat.

Es wurde der OWL-Reasoner von Jena benutzt. Der ist wohl nicht so toll. Langsam und speicherfressend, nicht praxistauglich.

Frage von Matthias Rust: Wie wird übersetzt, wenn z.B. ein Dienst Vor- und Nachname getrennt haben will, und ein anderer zusammen? Antwort: Geht nicht.

Ich habe nach wie vor Verständnisschwierigkeiten mit den Ideen hinter Semantic Web Services. Es geht prinzipiell darum, deklarativ zwischen inkompatiblen APIs zu übersetzen. Aber scheinbar funktioniert das nur in trivialen Fällen. Wie übersetzt man zwischen verschiedenen syntaktischen Ausprägungen eines Datums? Wie zwischen km/h und m/s? Alles im Matchmaker vorzuprogrammieren, kann ja auch nicht die Lösung sein.

Ich bleibe skeptisch. Standardisierte Datenformate und leichtgewichtiger „glue code“ scheinen mir sinnvoller zu sein.

Chris Hübsch versucht, das Dokumentenmanagement der TU Chemnitz zu XMLisieren, um den Dschungel aus Word, PDFs, HTML, AmiPro und verwandten Technologien zu beseitigen. Das Projekt heißt FOBERON (Forschungsbericht Online).

Ein CMS anzupassen, ist ihm zu aufwändig. LAMP mag er nicht. Relationale Datenbanken hält er für unangebracht für sein Problem, da seine Daten semistrukturiert sind und die Schemata sich zu oft ändern.

Seine Lösung ist technisch minimalistisch: eine einzige XML-Datei dient als Datenspeicher (dürfte in 10 Jahren 120 MB groß sein, mit libxml in 10 Sekunden im RAM). Alles wird als DOM-Baum im RAM gehalten, eine SOAP-Schnittstelle dient zur Manipulation, XPath zum Finden.

Allerdings kann man einen solchen DOM-Baum nicht mehr in Echtzeit per XSLT manipulieren. HTML-Seiten werden aus Templates (HTML mit Zusatztags) generiert. Aus URL-Parametern werden XPath-Ausdrücke, die Teile des DOM-Baums zurückliefern, welche dann per XSLT transformiert werden.

Statische HTML- und PDF-Versionen gibt es ebenfalls. Für PDF wird XSL:FO via Apache FOP benutzt.

Die Bearbeitung der Daten erfolgt über eine Webschnittstelle, in Python implementiert. Der Dienst kopiert den zu bearbeitenden Teil des DOM-Baums in einen temporären Speicher, die Manipulation erfolgt dort. Die Formulare selbst werden per XSLT aus dem Teilbaum erzeugt. Zusätzlich gibt es XML-Fragmente als Templates für neue Knoten.

8000 Zeilen Code, davon 6400 XSLT. Je ein Drittel für Output-HTML, XSL/FO, und HTML-Formulare. Alles sehr stark entkoppelt, dadurch robust und halbwegs skalierbar. Schlecht: 80% der Verarbeitungszeit geht für TCP und HTTP drauf. Daher nicht für viele Kunden geeignet.

Eine Python-Klasse lässt sich mit zwei Zeilen Code zu einem Webservice machen (SOAPpy).

Demo: Alles läuft flott, einigermaßen reiche Navigation. Von jeder Stelle der Navigation kann ein PDF erstellt werden. Die Bearbeitungsschnittstelle ist aus Usability-Sicht bedenklich, aber das war sicher kein Schwerpunkt.

Recht beeindruckend. Interessante, pragmatische Lösung, die anscheinend den 80/20-Punkt trifft.