[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