[deepamehta-users] Modellierung mit Deepamehta: Such-Properties

[Jörg Richter]

Lieber Jens-Christoph Brendel,

inzwischen hab' ich Deinen ersten Artikel-Entwurf gelesen. Ich finde 
ihn gelungen und kann da schon gut mitgehen. Dein Einstieg über Topic 
Maps und das Musik-Szenario finde ich gut. Daß Du mein Input 
berücksichtigst, und darstellst, daß DeepaMehta mehr ist, als ein Topic 
Map Editor, freut mich. Das eine oder andere Detail möchte ich vor der 
Veröffentlichung gerne ändern.


On 15.06.2009, at 14:03, Jens-Christoph Brendel wrote:

> Am Sonntag, den 14.06.2009, 22:50 +0200 schrieb Jörg Richter:
>>
>> Zunächst: man kann nach Properties suchen!
>
> Ok, das ist ein wichtiger Punkt. Martin hatte mir geschrieben:
> "Ich finde deine Typisierung gut und schon funktional. Allerdings kann
> es helfen wenn man bei 'echten' Einzelinformation wie zum Beispiel 
> einem
> Termin oder einer Person entsprechende relationen zwischen den
> TopicTypes verwendet statt properties. Danach lässt sich dann auch
> suchen und ordnen."
>
> Ich hatte das so verstanden, dass ich erst danach suchen kann, nachdem
> ich die Properties in Topics verwandelt habe. So hätte ich das auch in
> dem Beitrag dargestellt: Erst meine Lösung, die aus einem Artikel-Topic
> bestand, in dessen Typdefinition keine anderen Topics vorkamen. Dazu
> hätte ich gesagt: Intuitiv, aber nicht nach Property-Werten
> durchsuchbar. Dann hätte ich den Vorschlag präsentiert, den mir Martin
> geschickt hatte, mit einem Calendar- und einem Person-Topic anstelle
> vormaliger Properties. Dazu hätte ich gesagt: Komplexer, aber jetzt
> durchsuchbar.
>
> Wenn ich da was missverstanden habe, dann fehlt mir jetzt dieser
> Schritt in der Argumentation: Was ist dann der Vorteil an Martins
> Vorschlag?

Dadrüber habe ich inzwischen geschrieben ("Problem der 
Typ-Property-Dichotomie"). Welche Modellierung angemessen ist, hängt 
vom Anwendungskontext ab. Im Großen und Ganzen aber, ist die 
Typ-Property-Dichotomie, wie beschrieben, aber eher eine Problemquelle, 
die in DeepaMehta 3 abgeschafft wird.

>> 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.
>
> D.h. die Suche nach Properties ist zumindest insoweit nicht einfach
> möglich, als ich mir erst einen speziellen Suchtyp basteln muss, der
> mehr Such-Properties hat als den Namen?

Genaugenommen ist es so:
- Der Suchtyp ist bereits da (legt DeepaMehta zu jedem Typ automatisch 
an).
- Die Properties sind auch bereits da (mitgeliefert oder 
Benutzer-definiert).
- Nur die Assoziationen zwischen Suchtyp und gewünschten 
Such-Properties müssen vom Nutzer angelegt werden.
Somit definiert der Nutzer selbst, in welchen Properties er suchen 
möchte.
- Annahme: Es sind die Poweruser, die ihre Typen selber definieren.
- Das "Verdrahten" der Such-Properties ist Teil der Typ-Definiton, und 
findet im User Interface auf der gleichen Ebene statt.
- Fazit: Wer Typen selber baut, kann auch Such-Properties verdrahten.

Alternative Konzeptionen wären:
1) DeepaMehta macht aus allen Properties automatisch Such-Properties. 
Es wären dann z.B. auch "Passwort"-Properties suchbar.
2) Anstatt die Assoziation manuell knüpfen zu müssen, könnte eine 
Property selbst eine "is Searchable"-Property haben. Diese Einstellung 
würde dann für _alle_ Typen wirken, die diese Property verwenden.
3) Der "Königsweg", der wahrscheinlich in der Großzahl der Fälle 
nützlich ist: Die Such-Filter garnicht auf Property-Ebene defnieren, 
sondern dem Benutzer, a la Google, nur ein -- Property-übergreifendes 
-- Suchfeld anbieten. Die grafische DeepaMehta GUI ermöglicht das 
derzeit nicht, auf API-Ebene hingegen existiert dieser Such-Call, und 
wird von einigen DeepaMehta Web-Interfaces/Anwendungen benutzt.

>> 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.
>
> OK, dieses Beispiel konnte ich so nachvollziehen. Ohne Hilfe wäre ich
> aber nicht so schnell darauf gekommen - obwohl ich die Dokumentation
> gelesen habe :)

Die Dokumentation ist in der Tat nicht vollständig. Wünschenswert wäre 
auch ein "Best Practice"-Abschnitt mit Hinweisen zur Modellierung. Die 
Dokumentation ist fast ausschließlich von den Anwendern erstellt. Jeder 
Anwender ist eingeladen, die Dokumentation zu verbessern.

>> 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.
>
> Ich glaube, Du brauchst mich nicht zu agitieren, was die Nützlichkeit
> der Idee angeht. Hätte ich immer gleich alle Informationen zur Hand, 
> die
> ich in einem bestimmten Kontext brauche, wäre das sehr hilfreich. Etwas
> skeptisch bin ich, was die Umsetzbarkeit betrifft. Und ich glaube, 
> dass der
> herkömmliche Stil bei allen Nachteilen auch seine Vorteile hat: Ein 
> Ordner
> macht seinem Namen nämlich alle Ehre indem er ordnet, d.h. die 
> Komplexität
> vermindert. Ich habe zum Beispiel in einer Ausgabe so um die 20 
> Beiträge und
> tausche mit jedem Autor in der Regel um die zwei Dutzend Mails aus, 
> bis alles
> fertig ist.  Macht wenigstens 500 Mails pro Ausgabe, die ich aber in 
> meinem
> Mailclient in einer Ordnerhierarchie speichere: Titel/Ausgabe/Beitrag. 
> Auf der
> obersten Ebene ufern mir die Einträge nicht aus und mit drei Klicks 
> bin ich
> immer im richtigen Mail-Ordner. Ich fände es vermutlich nicht 
> intuitiver, würde
> ich mit 500 grafischen Elementen konfrontiert, die kreuz und quer 
> verbunden
> sind. Andererseits ist schon klar: Hätte ich neben den Mails auch 
> gleich die
> Texte der Artikelversionen und die Planvorgaben aus dem 
> Redaktionssystem
> und meine Korrespondenz vom letzten Mal wegen des Honorars  in einer
> Ansicht, wäre das zweifellos praktisch.
>
> Aber diesen Punkt lasse ich ja weitgehend aus und Du kannst mich und 
> vor
> allem die Leser sehr gerne in Deinem Kasten restlos überzeugen.

Vielen Dank für das anschauliche Szenario!
Das ist eine gute Beschreibung für den Alltag eines 
Informationsarbeiters!

Ja, im Kasten werde ich versuchen deutlich machen, warum DeepaMehta in 
einem solchen Szenario Vorteile bringt.

> Ich wage mich mal aus der Deckung :) und hänge hier einen allerersten
> Entwurf des Beitrags an (HTML-formatiert). An dem bastle ich sicher 
> noch
> rum, aber ich denke, man kann schon sehen, wie ich mir das Ganze
> vorstellen könnte.
>
> Ich nehme jeden Hinweis dazu gerne entgegen und überlege mir, ob ich 
> ihn
> berücksichtigen kann. Was ich ohne Wenn und Aber korrigiere, sind
> eventuelle sachliche Fehler. Meine Meinung als Autor lasse ich mir 
> nicht
> so schnell abkaufen, was aber nicht heißt, dass ich guten Argumenten
> nicht aufgeschlossen wäre.

On 12.06.2009, at 07:46, Jens-Christoph Brendel wrote:

> Wenn Du den Kasten schreiben würdest, hätte es für mich den Charme, 
> dass
> wir damit so etwas wie einen O-Ton hätten. Der bringt noch einmal eine
> eigene Authentizität mit und eine zusätzliche Farbe ins Spiel, was dem
> Beitrag sicher gut täte. So riesig viel Arbeit ist es auch deshalb
> nicht, weil die Kunst darin bestände, sich auf rund 3000-3500 Zeichen 
> zu
> beschränken. Allerhöchstens 4500, aber das wäre schon eine komplette
> Seite und damit kein eigentlicher Kasten mehr. Der Termin steht fest:
> Heute in vier Wochen geht der Text in die Druckerei, etwas eher muss er
> also in der Redaktion sein.

Danke für die Eckdaten!
Ich werde Dir meinen Text für den Kasten in der Woche ab 6. Juli 
zukommen lassen.

Grüße
Jörg

www.deepamehta.de



> freundliche 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
>
> <Deepamehta-Artikel.tar.gz>