Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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.

Ähnliche Präsentationen


Präsentation zum Thema: "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."—  Präsentation transkript:

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

13 Ausgangspunkt Beispiele 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 Abdecken von 95 % der Consumer Queries

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 Lösungsansatz bisher Rowset DB PHP Obj PHP Array HTML Js DOM Js Obj HTML Js HTTP

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 Zu viele TechnologienWeitere 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) Lösungsansätze bisher Warum nicht XML?

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

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

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 1. Daten-Objekt und 2. 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 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) { fname: "Clemens", lname: "Cap", lectures: ["net", "java", 11] }

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

25 UTE Was ist ein Template?

26 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... 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.= " ".$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 1. Kontext Objekt(Ergebnis der Query) 2. 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... Er ist {$.john.kid[3].age} alt Wir hatten damals bereits eine Funktion mit const und seq !!

32 UTE Basis-Templates {$.head} {$.body} Kontext: $.head $.body {$.heading} {apply: "articles", $.articles} Kontext: $.articles ist array of articles, diese haben weitere Attribute {$.titel} {$.news} {apply: "links", $.links}

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

34 Persistenz Meta-Prinzip: Wissenschaftlicher Kein Anspruch anAnspruch 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 KlassenDienen semantischer Gruppierung ( isA, subClass ) Jede Klasse hat generischen Typ zugeordnet Typenstring, number, boolean, null array object referencevia OID referenziert weakals 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 additionalzusätzliches Attribut, das der Typ nicht vorsieht nullablejedes Attribut darf (in DB & Client) fehlen fehlt $OID, dann nicht persistable, nur templatable pendingfunktionalwertiges 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 AllesDh: Fehlt, Parameter-Signatur falsch, Exceptions, usw. GrundServer 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 Cave: array of content objects, refs, simple ?!? person.name.first = "Joe"

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 RPC95% implementiert, PHP Server UTE60% raw prototype Persistenz30% proof-of-idea (MySQL, PHP)

41

42


Herunterladen ppt "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."

Ähnliche Präsentationen


Google-Anzeigen