[deepamehta-users] Beitrag über Deepamehta

[Jörg Richter]

Lieber Jens-Christoph,

danke für Deine Mail!
Dein geradliniges Vorgehen und Deine konkrete Planung sind hilfreich 
für uns.

Hier möchte ich auf die Thematik der Properties in DeepaMehta eingehen.


On 11.06.2009, at 17:15, Jens-Christoph Brendel wrote:

> Hallo Martin, hallo Jörg
>
> bis jetzt haben wir ja keinen Termin verpasst. Nun haben wir den 
> Beitrag
> aber für die übernächste Ausgabe (09/09) vorgesehen und werden ihn in
> 08/09 wahrscheinlich vorschauen. Das setzt uns dann schon ein wenig 
> mehr
> unter Zugzwang :).
>
> Ich denke, es wäre nicht entscheidend, dass wir eine umfangreiche Map
> oder ein langes Listing drucken können. Das Wäre möglich, wenn es sich
> anbietet, andererseits kann man auf vier, fünf Magazinseiten sowieso
> nicht alles bis ins Letzte erklären. Für die erreichbare Tiefe scheint
> mir auch so ausreichend Material verfügbar. Wir hätten dann eine Map in
> Gestalt dieser Themenkarte für das LTR. Wir könnten zeigen, wie man
> einen Topic-Typ anlegt und zwar
>
> 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.

Zunächst: man kann nach Properties suchen!

Zu jedem Topic-Typ erzeugt DeepaMehta automatisch einen individuellen 
Such-(Topic-)Typ, um nach Topics suchen zu können. Es sind die 
Suchtonnen, die von diesem Such-Typ sind. Suchen (im Interface: Tonnen) 
sind also typisierte Topics, und haben ihrerseits Properties. Die 
Properties der Such-Typen dienen als Eingabefelder für Suchbegriffe. 
Standardmäßig hat jeder Such-Typ nur eine "Name"-Property. Diese 
ermöglicht die Suche anhand des Topic-Namens.
=> Der (Power-)Anwender kann zu einem Such-Typ weitere Properties 
hinzufügen, um z.B. Personen anhand ihres Geschlechts (eine Property) 
zu suchen.

Datenmodell: Ein Typ ist per Aggregation (rote Assoziation) mit seinem 
Such-Typ verbunden.

Beispiel: Erweitern der Personensuche um Geschlecht-Filter:
1) Decke den "Person"-Typ auf (Search -> Type Builder -> Topic Type).
2) Decke vom Person-Typ aus die "Gender"-Property auf (What's Related 
-> Properties)
3) Decke vom Person-Typ aus den zugehörigen Such-Typ, "Person Search", 
auf (What's Related -> by Association Type / Aggregations)
4) Ziehe eine Assoziation vom Such-Typ zur Gender-Property und 
typisiere diese als Composition (Retype -> Composition)
5) Update den Such-Typ (Update)
=> Ab jetzt steht allen Personen-Suchen (auch die bereits vorhandenen!) 
ein Gender-Filter zu Verfügung.

Hinweis: wie generell bei Properties kann auch bei den Such-Typen die 
Reihenfolge der Properties (wie sie im Interface erscheinen) definiert 
werden. Wenn z.B. im Interface der Gender-Filter _nach_ dem 
Personen-Filter angezeigt werden soll, gebe der Composition (die in 
Schritt 4 erzeugt wurde) eine Ordinal Number von "110" und Update den 
Typ "Person Search" erneut (der standardmäßige Name-Filter hat eine 
Ordinal Number von 100).

Bei dieser Gelenheit noch ein Hinweis zu den Suchtonnen: Vom Konzept 
her entspricht eine Suchtonne einem "Smart Folder", d.h. einer 
Suchanfrage + der Ergebnismenge. In DeepaMehta setzt sich die 
Suchanfrage zusammen aus:
- Typ-Filter
- Topicname-Filter
- Property-Filter
- Assoziations-Filter
Um die einer Suchtonne zugrundeliegenden Suchanfrage erneut zu triggern 
und die Ergebnismenge zu aktualisieren, doppelklicke die Suchtonne.

> 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.
Ich möchte darauf ausführlich antworten, schaffe das aber im Moment 
nicht.
Morgen möchte ich das nachholen.
Und dann auch auf Deine nächste Mail eingehen ("weg von den Dateien").
Zum Textkasten: ich übernehme das! Ich werde den Textkasten schreiben.

Vielen Dank für Deine Impulse!

Grüße
Jörg Richter

www.deepamehta.de


> Aber um konkret weiterzukommen würde ich vorschlagen: Ihr liefert die
> Antworten und den Kasten, lasst mich schreiben und dann diskutieren wir
> nochmal, wenn ich ein vorzeigbares Ergebnis habe, was man vielleicht
> daran besser machen könnte.
>
> beste Grüße
>
> Jens-Christoph
> -- 
> 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