[deepamehta-users] DeepaMehta: das Problem der Typ-Property-Dichotomie
Jörg Richter
jri at deepamehta.de
Di Jun 16 02:20:39 CEST 2009
Lieber Jens-Christoph,
hier möchte ich endlich auf das von Dir angesprochene Thema "Typ vs.
Property" eingehen.
On 11.06.2009, at 17:15, Jens-Christoph Brendel wrote:
> [...]
>
> a) intuitiv, alle Eigenschaften sind Properties
> b) wie von Euch gezeigt: einige Eigenschaften sind ihrerseits Topics
> und
> deshalb einfach suchbar
>
> Damit landet man dann allerdings bei dem Problem, vor dem wir zuletzt
> standen. Property-Topics vergrößern die Menge der Elemente in der Map
> und machen sie ab einer bestimmten Größe unübersichtlich. Wenn man
> dasselbe mit Eigenschaften von Topics abbildet, hat man eine
> zusätzliche
> Ebene, die die Komplexität der Map vermindert, indem sie einen Teil der
> Details verdeckt. Optimal wäre, wenn man nach dien Eigenschaften suchen
> könnte, ohne dass sie selbst Topics sind - jedenfalls nach meiner
> persönlichen Meinung.
Wie man in Properties suchen kann, habe ich in meiner letzten Mail
beschrieben.
> Man muss das sicher nicht unbedingt breit treten. Aber es würde mich
> auch persönlich interessieren. Auf meinem Notebook befinden sich
> beispielsweise mehrere Hunderttausend Files. Wären das alles Topics und
> zusätzlich auch die Dateigröße, die Zugriffsrechte, etc. dann käme ich
> auf eine Menge, von der ich mir nicht vorstellen kann, wie man sie in
> einer grafischen Darstellung verwalten wollte. Nicht zu reden, dass das
> dann auch noch leichter bedienbar sein soll als meine Ordner und
> Unterordner jetzt.
>
> [...]
Hier sprichst Du einen wichtigen Punkt an: die Typ-Property-Dichotomie.
Um es vorweg zu sagen: daß es in DeepaMehta sowohl (typisierte) Topics
als auch Properties gibt, ist nicht optimal und führt zu erheblichen
Usability-Problemen. Der Grund, warum DeepaMehta diesen Weg gegangen
ist, ist daß damals eine einfache/pragmatische Lösung für ein komplexes
Darstellungsproblem gefunden werden mußte: wie können die
fein-granulierten Objekte eines semantischen Informationsspeichers
(Straße, Hausnr, PLZ, Stadt, Geburtsort: alles sind separate Objekte)
im User Interface zu handhabbaren, d.h. für den Anwender nützlichen,
Einheiten aggregiert werden?
Die DeepaMehta-Lösung ist bekannt: die linke Bildschirmhälfte zeigt
eine Topic Map, ein Netzwerk aus typisierten Topics und Assoziationen.
Klickt man einen Topic (oder Assoziation) an, erscheinen in der rechten
Bildschirmhälfte die Detail-Informationen des Topics. Die
Bildschirmdarstellung der Detail-Informationen richtet sich danach,
welche Properties zum jeweiligen Topic-Typ definiert sind. Dies ist
eine einfache Lösung des erwähnten Darstellungsproblems.
Übrigens: das Konzept der Bildschirm-Zweiteilung löst ein verwandtes
Interface-Problem: Wie kann zwischen Informations-Kontext und
Informations-Detail gewechselt werden? In DeepaMehta wird sogar eine
Gleichzeitigkeit erreicht: ohne Arrangieren von Fenstern sind links
immer der Kontext sichtbar und rechts sind immer die Details sichtbar.
Innerhalb eines Kontexts ist jedes Detail nur einen Klick entfernt.
(Andererseits bringt diese starre 2-Teilung auch Probleme mit sich. Es
ist z.B. nicht möglich, gleichzeitig 2 Details sichtbar zu haben, etwa
für einen Vergleich.)
Zurück zur Typ-Property-Dichotomie: ein praktisches Problem ist, daß
der Anwender beim Modellieren immer abwägen muß: modelliere ich eine
Information als Topic-Typ oder als Property? Welches sind die
Konsequenzen?
Als Topic-Typ:
- die Infomation erscheint in der Topic Map als Knoten eines
semantischen Netzwerks, d.h. die Information wird innerhalb ihres
Kontexts visualisiert.
- die Information ist addressierbar, d.h. sie kann in anderen Kontexten
wiederverwendet/visualisiert werden.
Als Property:
- die Information ist zusammen mit den anderen Detail-Informationen
eines Topics auf einen Klick sichtbar.
- die Information ist nicht addressierbar und stellt keinen eigenen
Knoten in einem semantischen Netzwerk dar.
Es gibt keine eindeutige Antwort darauf, ob man in DeepaMehta eine
Information besser als Topic-Typ oder als Property modelliert. Topics
sind First-Class Objekte, Properties eher untergeordnet. Eine Heuristik
bzw. Daumenregel ist: je zentraler die Information innerhalb der
Anwendungsdomäne ist, desto eher würde man sie als Topic-Typen
modellieren. In einer Kontaktverwaltung z.B., würde man eine Jahreszahl
(Geburtsjahr) eher als Property modellieren, in einer
Geschichts-Wissensbasis hingegen wahrscheinlich als Topic-Typ.
An den oben beschriebenen Eigenschaften von Topic-Typen und Properties
wird ein Designproblem, bzw. ein Designfehler, sichtbar: Datenmodell
und Bildschirmdarstellung sind miteinander verwoben! Daher ist der
Anwender gezwungen ein Kompromiß zu finden, zwischen
a) Feingranularer semantischer Modellierung, und
b) Handhabbaren Interface-Objekten.
Viele DeepaMehta-Anwender beklagen sich z.B. über folgende Situation:
sie klicken eine Person an, und wollen auf einen Blick alle relevanten
Angaben zu dieser Person sehen (Email-Adresse, Telefonnr., ...). In
DeepaMehta müssen sie dazu erst, mühsam mit vielen Klicks, alle
assoziierten Topics aufdecken. Daher benutzen viele Anwender die
mitgelieferten Topic-Typen (Email Address, Webpage, Phone Number, ...)
garnicht und definieren stattdessen entsprechende Properties zum
Topic-Typ "Person" hinzu. Der Gewinn: alle Person-Informationen auf
einen Blick. Der Verlust: die Features die an die mitgelieferten Typen
gekoppelt sind, z.B. Emails schreiben, Webseiten aufrufen.
Fazit: So würde ich das nicht nochmal designen. Aber wie heißt es so
schön: Umwege vergrößern die Ortskenntnis :-)
Zukunftsperspektive: In DeepaMehta 3 wird es keine
Typ-Property-Dichotomie mehr geben. Alles sind Typen. Die Darstellung
ist vollkommen getrennt vom Datenmodell. Das Problem der handhabbaren
Interface-Objekte wird durch eine weitere Schicht gelöst: "View
Prescriptions" sind Regeln, die beschreiben, wie aus einem
Topic-Aggregat eine Detail-Darstellung erzeugt wird (ähnlich dem
MIT-Projekt "Haystack").
Grüße
Jörg Richter
www.deepamehta.de
> --
> Jens-Christoph Brendel
>
> = Editor-in-Chief Linux Technical Review =
> Linux New Media AG | Phone: +49 89 9934 1146
> Putzbrunner Str. 71 | Fax: +49 89 9934 1199
> 81929 München, Germany | Mobile: +49 163 356 2561
>
> jbrendel at linuxnewmedia.de - http://www.linuxnewmedia.de
>
> Linux New Media Lawrence - Malaga - Manchester
> The Pulse of Linux München - Sao Paulo - Warszawa
>
> Vorstand: Brian Osborn, Hermann Plank
> Aufsichtsratsvorsitzender: Rudolf Strobl
Mehr Informationen über die Mailingliste users