suche nach objekten

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 AttributenKleine Objekte: Bis 20 Attribute, komplett typisch 1kBEinfachste 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 erwartetKeine Relationen und keine JoinsGeringe 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 classAmazon 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

RowsetDB

PHP Obj

PHP Array

HTMLJs

DOMJs Obj

HTMLJs

HTTP

Lösungsansatz bisherKritikpunkte

Zu viel String Processing – zu aufwendigZu viel am Server, zu wenig am Client – skaliert schlechtZu viele Nahtstellen – Impedanz Mismatch

Vgl: SQL / PHP / Javascript / HTML – Injection AttackenZu viele Sprachen – zu hoher Lernaufwand

Business Logik in 2 SprachenAm Client: In Javascript für ein 1. Matching (optional)Am Server: In PHP / (SQL) für ein 2. Matching (mandatory)

Zu wenig konzeptuelle TrennungBsp: CSS / JS / HTML, JS / PHP, Model / ViewAber: 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?

RowsetDB

PHP Obj

PHP Array

HTMLJs

DOMJs Obj

HTMLJs

HTTP

Js ObjJs Obj Json RPC

JsBusiness

JsBusiness

UTETemplat

eJsonDB

Ä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-ObjektServer antwortet mit 1. Daten-Objekt und 2. Template-FunktionPräsentation durch Anwendung der Js Funktion auf ObjektEffekt: Client-side templating, skaliert besserUnd: Js Funktionen sind Domänen-weites Look %& Feel

wird 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-RPCClient 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?


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


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ß programmierenInhalte mit if - then - else - for - while - try usw. angereichert

Fallgrube 2: Stringverarbeit. Programm erzeugt DesignProgramm mit Escapements und string processingx .= "<A href=\"".$url."\">".$text. usw…

Fallgrube 3: Imperative Sprache erlaubt SeiteneffekteOhne Disziplin entsteht M – V – C MixturBsp: 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


Ein Template ist eine Funktiondie 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 anAlgebraische VollständigkeitNormalformenEffizienz für alle QueriesEffiziente JoinsLangfristige ArchivierungTransaktionale KorrektheitHoher Recall, hohe Precision

Abdeckung genannter Use Cases

Chance auf sinnvolle Struktur wirdnicht dauerhaft und total versaut

Flexibles SchemaDo the best you can

PersistenzElemente des Schemas

Klassen Dienen semantischer Gruppierung ( isA, subClass )Jede Klasse hat generischen Typ zugeordnet

Typen string, number, boolean, nullarrayobject 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 ClientsErlaubt ist für Attributeadditional zusätzliches Attribut, das der Typ nicht vorsiehtnullable jedes Attribut darf (in DB & Client) fehlen

fehlt $OID, dann nicht persistable, nur templatablepending funktionalwertiges Attribut (Js Funktion)

Attribut wäre vorhanden, Wert wurde nicht geladenAufruf der Funktion ( stub ) lädt Wert dynamisch

nachErlaubt ist für MethodenAlles Dh: Fehlt, Parameter-Signatur falsch, Exceptions, usw.Grund Server bereitet für Client korrekt auf

Client 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 enthaltenDynamisch 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-NutzungSkalierung: Templating-Aufwand am Client, skaliert besserKonzeptuell: Klare, konzeptuelle Trennung eines MVC – Ansatzes

Realisierungsstand Json RPC 95% implementiert, PHP Server UTE 60% raw prototype Persistenz 30% proof-of-idea (MySQL, PHP)

suche nach objekten

Documents