Suche nach objekten
Download
1 / 42

Suche nach Objekten - PowerPoint PPT Presentation


  • 113 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Suche nach Objekten' - otto


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 Web 2.110.000

  • Web 2.0 699.000

  • Semantic Web 354.000



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



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


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

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


Persistenz sicht des clients
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


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 Text Damit 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 RPC 95% implementiert, PHP Server

  • UTE 60% rawprototype

  • Persistenz 30% proof-of-idea (MySQL, PHP)