1 / 42

Suche nach Objekten

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

otto
Télécharger la présentation

Suche nach Objekten

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 AkzeptanzLt. Google Scholar • Social Web 2.110.000 • Web 2.0 699.000 • Semantic Web 354.000

  7. Community Akzeptanz lt Ikon Teppich

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

  9. Ausgangspunkt

  10. { class: "PKW", age: {min:10, max:20} } Ausgangspunkt 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"

  11. AusgangspunktBeispiele Abdecken von 95 % der Consumer Queries eBay • Temporale Restriktion: Beschränkte Gültigkeit • Suche auf mostspecificclass Amazon • Standard-Buchsuche (nicht komplexes IR) Kinoprogramm / Restaurant / Mietwohnung • Lokale und temporale Restriktion • Kleine Objektanzahl

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

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

  14. Lösungsansatz bisherKritikpunkte 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

  15. Lösungsansätze bisherWarum 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)

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

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

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

  19. ÜbersichtBenutzte 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

  20. ÜbersichtGesamtablauf 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-sidetemplating, 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 JavascriptKann sogar identischer Code sein !Geht auch wenn Objekte "Paragraphen" sindBsp: Wikis, Blogs, Annotationen

  21. { 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)

  22. call ( "get", qbeObject ); call ( "get", qbeObject, handler ); call ( [ { "get", q1 }, { "put", q2 } ] ); Json RPCDie 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)

  23. UTEWas ist ein Template?

  24. UTEWas 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

  25. UTEWas 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 . . .

  26. UTEDie 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

  27. UTEIdeen 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-PathOptimale Prädikate: Testen ob Wert vorhand oder nullAkzeptable Prädikate: Seiteneffektfreie bool. Funktion auf ContextUnerwünschte Präd. : Alles andere

  28. UTEWas 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

  29. UTEBasis-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 !!

  30. UTEBasis-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>

  31. PersistenzMeta-Prinzip: Schwein ja, Müll nein

  32. PersistenzMeta-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 wirdnicht dauerhaft und total versaut Flexibles Schema Do the best you can

  33. PersistenzElemente des Schemas Klassen Dienen semantischer Gruppierung ( isA, subClass ) Jede Klasse hat generischen Typ zugeordnet Typenstring, 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

  34. PersistenzSicht 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

  35. PersistenzMethoden 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

  36. PersistenzSicht 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

  37. PersistenzImplementierungs-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 ?!?

  38. 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% rawprototype • Persistenz 30% proof-of-idea (MySQL, PHP)

More Related