SUCHE NACH OBJEKTEN

Prof. Dr. Clemens H. CapUniversität Rostockclemens .cap (at) uni-rostock (dot) dewww.internet-prof.de

Vortragender: Martin Garbe

GI Fachgruppe Datenbanksysteme und InformationRetrieval8. und 9. Mai 2008, Bamberg

Von den Problemen des Semantic Webzu 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 AkzeptanzLt. Google Scholar

1. Social Web 2.110.0002. Web 2.0 699.0003. 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

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

AusgangspunktBeispiele

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 % derConsumer Queries

Lösungsansatz bisher

Objekte: Von DB via SQL in ein RowsetLogik: Von Rowset via Treiber zu PHP Result-Array

Von Result-Array in ein PHP Business-ObjektTemplate: Von PHP Objekt via Smarty nach HTML + JS

Layout: Von HTML via Parser nach DOM

Lösungsansatz bisher

Rowset

DB

PHP Obj

PHP Array

HTMLJs

DOMJs Obj

HTMLJs

HTTP

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

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)

Lösungsansätze bisherWarum nicht XML?

Rowset

DB

PHP Obj

PHP Array

HTMLJs

DOMJs Obj

HTMLJs

HTTP

Js ObjJs Obj Json RPC

JsBusiness

JsBusiness

UTETemplat

e

JsonDB

Ä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

ÜbersichtBenutzte Technologie-Bausteine

Json-RPC: MiddlewareSchiebt Js Objekte hin und her

UTE: UTE ist eine Template EngineWichtig: Clientseitiges Templating !

Joppa: Object PersistenzJavascript Object Persistent Programming Architecture

ÜbersichtGesamtablauf 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 %& Feelwird 1x geladenDamit: 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

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] }

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)

call ( "get", qbeObject );call ( "get", qbeObject, handler );call ( [ { "get", q1 }, { "put", q2 } ] );

UTEWas ist ein Template?

UTEWas ist ein Template?

Ein Template ist Inhalt mit LöchernLö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 davonliefern Turing

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

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

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

UTEWas 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

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

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>

PersistenzMeta-Prinzip: Schwein ja, Müll nein

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

PersistenzElemente 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

PersistenzSicht des Clients

Erlaubt ist für Attribute

additional zusätzliches Attribut, das der Typ nicht vorsieht

nullable jedes Attribut darf (in DB & Client) fehlenfehlt $OID, dann nicht persistable, nur templatable

pending funktionalwertiges Attribut (Js Funktion)Attribut wäre vorhanden, Wert wurde nicht geladenAufruf 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 aufClient kann beliebig sich und andere betrügenServer muß Client-Daten ohnehin massiv prüfenDem Client ist partial load gestattet (nullable,

pending)Pending load kann fehlschlagen

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

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 nullvs. nicht geladen

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

Cave: array of contentobjects, refs, simple ?!?

person.name.first = "Joe"

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)