Suche nach objekten
This presentation is the property of its rightful owner.
Sponsored Links
1 / 42

Suche nach Objekten PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

zu den Chancen der JOPPA Architektur


Probleme des semantic web

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 "Web 2.0"


Community akzeptanz lt technorati semantic web gegen social web

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


Community akzeptanz lt google trends semantic web gegen web 2 0

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


Community akzeptanz lt google scholar

Community AkzeptanzLt. Google Scholar

  • Social Web2.110.000

  • Web 2.0 699.000

  • Semantic Web 354.000


Community akzeptanz lt ikon teppich

Community Akzeptanz lt Ikon Teppich


Prognosen f r die zukunft

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


Ausgangspunkt1

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


Ausgangspunkt beispiele

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


L sungsansatz bisher

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


L sungsansatz bisher1

Lösungsansatz bisher

DB

Rowset

PHP Array

PHP Obj

HTML

Js

HTTP

HTML

Js

DOM

Js Obj


L sungsansatz bisher kritikpunkte

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


L sungsans tze bisher warum nicht xml

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)


Suche nach objekten

DB

Rowset

PHP Array

PHP Obj

HTML

Js

HTTP

HTML

Js

DOM

Js Obj


Suche nach objekten

Js Obj

Js Obj

Json RPC

Js

Business

Js

Business

Json

DB

UTE

Template


Hnliche ans tze in der literatur

Ä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


Bersicht benutzte technologie bausteine

Ü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


Bersicht gesamtablauf der anwendung

Ü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 %& 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

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


Json rpc die middleware

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)


Ute was ist ein template

UTEWas ist ein Template?


Ute was ist ein template1

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


Ute was ist ein template2

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


Ute die fallgruben im design

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


Ute ideen

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


Ute was ist ein template3

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


Ute basis templates

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


Ute basis templates1

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>


Persistenz meta prinzip schwein ja m ll nein

PersistenzMeta-Prinzip: Schwein ja, Müll nein


Persistenz meta prinzip wissenschaftlicher

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


Persistenz elemente des schemas

PersistenzElemente 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


Persistenz sicht des clients

PersistenzSicht des Clients

Erlaubt ist für Attribute

additionalzusätzliches Attribut, das der Typ nicht vorsieht

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

pendingfunktionalwertiges Attribut (Js Funktion)Attribut wäre vorhanden, Wert wurde nicht geladenAufruf 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 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


Persistenz methoden

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


Persistenz sicht des servers

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


Persistenz implementierungs strategien

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 TextDamit nicht mehr (effizient) durchsuchbar

person.name.first = "Joe"

Cave: array of content

objects, refs, simple ?!?


Ergebnis

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% rawprototype

  • Persistenz30% proof-of-idea (MySQL, PHP)


  • Login