Suche nach Objekten Von den Problemen des Semantic Web Prof. Dr. Clemens H. Cap Universität Rostock clemens .cap (at) uni-rostock (dot) de www.internet-prof.de Vortragender: Martin Garbe GI Fachgruppe Datenbanksysteme und InformationRetrieval 8. und 9. Mai 2008, Bamberg Suche nach Objekten Von den Problemen des Semantic Web zu den Chancen der JOPPA Architektur

Probleme des Semantic Web Zu schwergewichtig, weil Relativ komplexe Syntax (XML, Namespaces, vieles explizit) Aufwendiges Reasoning (F-Logik, OWL-*) Viele Co-Technologien (RDF, SparQL, RIF, RDFS, Hohe Anforderung an Meta-Info (Ontologie, Schemata) Daher Erfolge vornehmlich in engeren Spezialbereichen Akzeptanz in "großer" Community geringer als Social Web / Web 2.0

Community Akzeptanz lt. Technorati "Semantic Web" gegen "Web 2.0"

Community Akzeptanz lt Technorati "Semantic Web" gegen "Social Web"

Community Akzeptanz lt Google Trends "Semantic Web" gegen "Web 2.0"

Community Akzeptanz Lt. Google Scholar Social Web 2.110.000 Web 2.0 699.000 Semantic Web 354.000

Community Akzeptanz lt Ikon Teppich

Prognosen für die Zukunft Das aktuelle Web 2.0 ist der letzte große Umbruch im Web mit User Generated Content zum "Socialnet" Anbindung der realen Außenwelt zum "Internet der Dinge" Semantic Web Funktionen werden entstehen durch Socialising und Wisdom of Crowds in den Inhalten: bottom up weniger durch F-Logik, RDFs, SparQL, OWL so schade das wissenschaftlich gesehen ist !! vermutlich eher durch Microformate, Annotationen

Ausgangspunkt

Ausgangspunkt { class: "PKW", age: {min:10, max:20} } Einfache Metadaten: Objekte mit Attributen Kleine Objekte: Bis 20 Attribute, komplett typisch 1kB Einfachste Queries: Nach QBE Ansatz Konjunktion von Value-Queries und Range-Queries auf paarweise verschiedenen Attributen Ggf. noch Bloomfilter Queries (Zugehörigkeit zu Maske) Antwort darf unpräzise sein Liefert zu viel: Client-seitiges nachfiltern Liefert zu wenig: Keine vollständige Abdeckung erwartet Keine Relationen und keine Joins Geringe Tiefe der Klassenhierarchie Most specific class meist bekannt: Suche "PKW" nicht "KFZ"

Ausgangspunkt Beispiele Abdecken von 95 % der Consumer Queries eBay Temporale Restriktion: Beschränkte Gültigkeit Suche auf most specific class Amazon Standard-Buchsuche (nicht komplexes IR) Kinoprogramm / Restaurant / Mietwohnung Lokale und temporale Restriktion Kleine Objektanzahl

Lösungsansatz bisher Objekte: Von DB via SQL in ein Rowset Logik: Von Rowset via Treiber zu PHP Result-Array Von Result-Array in ein PHP Business-Objekt Template: Von PHP Objekt via Smarty nach HTML + JS Layout: Von HTML via Parser nach DOM

DB Rowset PHP Array PHP Obj HTML Js HTML Js DOM Js Obj Lösungsansatz bisher DB Rowset PHP Array PHP Obj HTML Js HTTP HTML Js DOM Js Obj

Lösungsansatz bisher Kritikpunkte Zu viel String Processing – zu aufwendig Zu viel am Server, zu wenig am Client – skaliert schlecht Zu viele Nahtstellen – Impedanz Mismatch Vgl: SQL / PHP / Javascript / HTML – Injection Attacken Zu viele Sprachen – zu hoher Lernaufwand Business Logik in 2 Sprachen Am Client: In Javascript für ein 1. Matching (optional) Am Server: In PHP / (SQL) für ein 2. Matching (mandatory) Zu wenig konzeptuelle Trennung Bsp: CSS / JS / HTML, JS / PHP, Model / View Aber: Struts (schwer !), Spring, Tapestry, Stripes

Lösungsansätze bisher Warum nicht XML? Zu viele Technologien Weitere Nachteile XML, XHTML DTD, Xschema XML Namespaces XPath, Xpointer XForms XSL / XSLT / XSL-FO XQuery, XUpdate XLink RDF Keine uniforme Browser- Unterstützung (XSL, XPath) Zu häufiges Parsen nötig Editoren: Ja, nur für Spezialist Doppelt großer Overhead DB-Mapping problematisch (Attribute, Aufwand, Query)

DB Rowset PHP Array PHP Obj HTML Js HTTP HTML Js DOM Js Obj

Js Obj Js Obj Json RPC Js Business Js Business Json DB UTE Template

Ähnliche Ansätze in der Literatur Parallele Entwicklung ähnlicher Ideen bei anderen Gruppen jsdb: Javascript DB nur Client-seitig Aptana: Pure Js Development Serverside Js in SCRIPT Tag eingearbeitet, somit Spaghettis Keine Objektabtrennung Persistent Javascript und Persevere DB Ansatz stärker traditionell Kein Templating

Übersicht Benutzte Technologie-Bausteine Json-RPC: Middleware Schiebt Js Objekte hin und her UTE: UTE ist eine Template Engine Wichtig: Clientseitiges Templating ! Joppa: Object Persistenz Javascript Object Persistent Programming Architecture

Übersicht Gesamtablauf der Anwendung Client sendet QBE-Objekt Server antwortet mit Daten-Objekt und Template-Funktion Präsentation durch Anwendung der Js Funktion auf Objekt Effekt: Client-side templating, skaliert besser Und: Js Funktionen sind Domänen-weites Look %& Feel wird 1x geladen Damit: Sehr einfaches Skinning möglich Business Logik: Server-side und Client-side in Javascript Kann sogar identischer Code sein ! Geht auch wenn Objekte "Paragraphen" sind Bsp: Wikis, Blogs, Annotationen

Vorteile von Js / Json { fname: "Clemens", lname: "Cap", lectures: ["net", "java", 11] } Vorteile von Js / Json Am Client universell verfügbar Einfache Objektnotation Json – selber Js, daher nur "eval" OO (Prototypen-basiert, keine Typprüfung) Dynamische Attribute flexibler als in C++, Java Kein Mapping Problem wie bei XML: Content vs. Attribut Syntax leichtgewichtig Co-Technologien oftmals trivial (Bsp: JPath) Funktionen sind first class citizens (Speichern in Variable) Interpreter ist Teil des Sprachumfangs Stark steigende Akzeptanz der Community Als RFC 4627 standardisiert Sicher gegen Cross-Site Scripting (a long story told in one PPT bullet)

Json RPC Die Middleware call ( "get", qbeObject ); call ( "get", qbeObject, handler ); call ( [ { "get", q1 }, { "put", q2 } ] ); Json RPC Die Middleware Klassische Middleware, vgl SOAP, Corba, Sun-RPC Client sendet request (Js-Objekt, als Json-Text) Server sendet response (Js-Objekt, als Json-Text) Synchron oder asynchron (dann mit Continuation handler) Multi-request möglich (ein Transport (http) Call hält viele requests - dann single oder stream response) Stream-response möglich (response aus mehreren Chunks)

UTE Was ist ein Template?

UTE Was ist ein Template? Ein Template ist Inhalt mit Löchern Löcher durch Attribute eines Objekts ("Context") gefüllt Wir brauchen also Konstante Templates (Inhalte ohne Löcher) Attribut-Ausdrücke (JsonPath; ctx.person.name) Conditional Templates Benannte Templates Repetitive Templates je 2 davon liefern Turing

UTE Was ist ein Template? Konstantes Template <html> . . . Das ist ein Auto der Marke {$.auto.marke} mit {$.auto.ps} $ repräsentiert Kontext Objekt, Teile in { . . . } sind Js-interpretierbar Conditional Template Joe geht in die {if: $.kid.age > 6, then: "Schule", else: "Kindergarten"} Weitere Entwicklung, wie man sie sich üblicherweise vorstellt . . .

UTE Die Fallgruben im Design Fallgrube 1: Designer muß programmieren Inhalte mit if - then - else - for - while - try usw. angereichert Fallgrube 2: Stringverarbeit. Programm erzeugt Design Programm mit Escapements und string processing x .= "<A href=\"".$url."\">".$text. usw… Fallgrube 3: Imperative Sprache erlaubt Seiteneffekte Ohne Disziplin entsteht M – V – C Mixtur Bsp: Bluthochdruck gehört ins M, nicht ins V Daher: Etwas anders weiterentwickeln

UTE Ideen Stärkere Trennung: Separate Entities (Files, Regions, Sections) {if: $.age > 6, then: "Schule", else: "Kindergarten", id:"Institution"} oder ohne id-Attribut in entsprechender Datei / Objekt (DB) speichen Joe geht in die {apply: "Institution", to: $.kid} Einschränkung im Sprachumfang: Reines Json-Path Optimale Prädikate: Testen ob Wert vorhand oder null Akzeptable Prädikate: Seiteneffektfreie bool. Funktion auf Context Unerwünschte Präd. : Alles andere

UTE Was ist ein Template? Ein Template ist eine Funktion die aus einem Kontext Objekt ein neues Kontext Objekt macht Liefere an den Client Kontext Objekt (Ergebnis der Query) Funktions-Biblio (seit Betreten der Domäne im Cache) Client erzeugt daraus (DOM)-Objekt = HTML-Seite

UTE Basis-Templates Konstantes Template = Konstante Funktion { const: 44 } { const: "Zuse" } { const: john.kid[3].age } { const: { vname:"Konrad", nname:"Zuse" } } Sequentielles Template = Funktor von n Funktionen {seq: [ tmpl1, tmpl2, tmpl3, … ] } { seq: [ {"Konrad"}, {"Zuse"} ] } Kompaktere Notation dazu <html> . . . Er ist {$.john.kid[3].age} alt Wir hatten damals bereits eine Funktion mit const und seq !!

UTE Basis-Templates <html> {$.head} {$.body} </html> Kontext: $.head $.body <h1>{$.heading}</h1> {apply: "articles", $.articles} Kontext: $.articles ist array of articles, diese haben weitere Attribute <h2> {$.titel} </h2> <div> {$.news} </div> <ul> {apply: "links", $.links} </ul> <hr>

Persistenz Meta-Prinzip: Schwein ja, Müll nein

Persistenz Meta-Prinzip: Wissenschaftlicher Kein Anspruch an Anspruch an Algebraische Vollständigkeit Normalformen Effizienz für alle Queries Effiziente Joins Langfristige Archivierung Transaktionale Korrektheit Hoher Recall, hohe Precision Abdeckung genannter Use Cases Chance auf sinnvolle Struktur wird nicht dauerhaft und total versaut Flexibles Schema Do the best you can

Persistenz Elemente des Schemas Klassen Dienen semantischer Gruppierung ( isA, subClass ) Jede Klasse hat generischen Typ zugeordnet Typen string, number, boolean, null array object reference via OID referenziert weak als Substruktur inkludiert Query, Load, Store, Instanziierung & co. nur nach most specific classes Via Use Case Annahmen und GUI gewährleistet

Persistenz Sicht des Clients Erlaubt ist für Attribute additional zusätzliches Attribut, das der Typ nicht vorsieht nullable jedes Attribut darf (in DB & Client) fehlen fehlt $OID, dann nicht persistable, nur templatable pending funktionalwertiges Attribut (Js Funktion) Attribut wäre vorhanden, Wert wurde nicht geladen Aufruf der Funktion ( stub ) lädt Wert dynamisch nach Erlaubt ist für Methoden Alles Dh: Fehlt, Parameter-Signatur falsch, Exceptions, usw. Grund Server bereitet für Client korrekt auf Client kann beliebig sich und andere betrügen Server muß Client-Daten ohnehin massiv prüfen Dem Client ist partial load gestattet (nullable, pending) Pending load kann fehlschlagen

Persistenz Methoden Als Js Text in Schema / Typdefinition enthalten Dynamisch dazugepatched über Js Prototype-Chain über Reflection Methoden __noSuchMethod__ Aus Sicht des Betreibers Am Server korrekt vorhanden Am Client ohnehin nicht zu garantieren

Persistenz Sicht des Servers Instanziieren: oid new ( registeredClassId, [ templateObject ] ) Server generiert OID, speichert Klasse (& Typ), init nach Template Speichern: object.persist ( [ jsonMask ] ) Object kennt eigene OID in $OID Geschriebene Attribute: Alle - außer jsonMaskierte & pending (nicht mit null überschreiben, wenn nicht sicher weiß daß null ist) Laden: object load ( oid, [ jsonMask ] ) Relativ zu opt. Json-Mask Ausdruck als Typ-Filter (Col Liste im SELECT) Was wird eager (ie. sofort) geladen ? Was wird lazy (ie. pending als stub) geladen ? Was wird nicht geladen ? (Attribut null) Cave: null: ist null vs. nicht geladen

Persistenz Implementierungs-Strategien Jede most-specific Klasse wird durch eine Tabelle umgesetzt reference Typen: Durch OID simple Typen: Durch Spalte weak Typen: Durch flattening array Typen: Durch separate Tabelle pending: Durch Js Code Generierung für Client additionals: Durch Json Text Damit nicht mehr (effizient) durchsuchbar person.name.first = "Joe" Cave: array of content objects, refs, simple ?!?

Ergebnis Persistenz-Architektur für Javascript Objekte Homogen: Durchgängig, Client & Serverseitig Javascript-Nutzung Skalierung: Templating-Aufwand am Client, skaliert besser Konzeptuell: Klare, konzeptuelle Trennung eines MVC – Ansatzes Realisierungsstand Json RPC 95% implementiert, PHP Server UTE 60% raw prototype Persistenz 30% proof-of-idea (MySQL, PHP)