Suche nach Objekten Von den Problemen des Semantic Web

Präsentation zum Thema: "Suche nach Objekten Von den Problemen des Semantic Web"—  Präsentation transkript:

1 Suche nach Objekten Von den Problemen des Semantic Web
Prof. Dr. Clemens H. Cap Universität Rostock clemens .cap (at) uni-rostock (dot) 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

2 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

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

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

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

6 Community Akzeptanz Lt. Google Scholar
Social Web Web Semantic Web

7 Community Akzeptanz lt Ikon Teppich

8

9

10 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

11 Ausgangspunkt

12 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"

13 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

14 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

15 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

16 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

17 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)

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

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

20 Ä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

21 Ü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

22 Ü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

23 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)

24 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)

25 UTE Was ist ein Template?

26 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

27 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 . . .

28 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

29 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

30 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

31 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 !!

32 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>

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

34 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

35 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

36 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

37 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

38 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

39 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 ?!?

40 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)

41

42