Hi Philipp,
Ja, da gebe ich dir recht. Ein kleines "aber": Die Suche ist noch immer eine Stichwort-
suche. Dazu komme ich noch...
hm. "Die Suche" war schon immer eine Volltextsuche. Wäre sie eine reine Stichwortsuche, dann wäre der Ansatz, sie über mySQL-FULLTEXT zu reimplementieren, sehr viel erfolgreicher gewesen.
Durch eine bessere Anforderung steigt die Qualität natürlich, die Anzahl gefundener
Elemente wird deutlich kleiner (Recall) aber das ändert nichts an der Tatsache, dass
auch völlig themenfremde und/oder sinnlose Postings vor anderen ausgegeben/gefunden
werden. Wirklich precision-verbessernde Verfahren wäre z.B. die von dir genannte
Kennzeichnung von relevanten Postings, einer Klassifikation oder der Indexierung von
Schlagwörtern. Teilweise könnten auch statistische Verfahren zum Einsatz kommen.
Aber die jetztige Suche ist nicht precision orientiert und wird es nie sein, egal wie
gut die Anfrage ist, denn der Inhalt wird nicht gewertet (Gewichtung).
Mir kommt gerade eine ganz wilde Idee.
Wir hatten über Jahre hinweg immer mal wieder darüber nachgedacht, eine Ranking-Funktion zu implementieren.
Heute, da Googles "link popularity"-Ansatz bekannt und erfolgreich ist, müßte man sich mal fragen, ob eine vergleichbare Idee innerhalb des Archivs (Postings, auf welche viele andere Postings verlinken, sind "wertvolle" Postings) zu einem erfolgversprechenden Ansatz führen könnte ... das hätte nämlich den lustigen Nebeneffekt, daß jeder, der ein Posting kompetent (durch Setzen eines Link - er muß also die FAQ gelesen haben ;-) beantwortet, diesen Datenbestand pflegt, ohne jede zusätzliche Dialog-Software! Und wenn nur die Anzahl der Links _auf_ ein Objekt relevant sind, dann kann man diese während des Archivierungsvorgangs inkrementell erhöhen ...
Aber ich gebe dir recht, dass man natürlich durch gute Suchanfragen die Qualität steigern
kann. Aber wenn es nur darum geht, können wir auch nur einen Feature Artikel über die
intelligente Suchanfrage schreiben.
Wer liest den? Sicherlich nicht derjenige, der schon jetzt nicht liest, was alles direkt unterhalb des Suchformulars steht ...
Mir geht es eben nicht um dies, sondern die
precision zu verbessern, mein Vorschlag wäre hier eben eine Klassifizierung mit einer
Indexierung (Schlagwörter) zu kombinieren.
Das nützt aber nur dann etwas, wenn die Schlagwörter
a) bekannt sind und
b) einheitlich vergeben werden.
Letzteres wird durch die vom Datenvolumen bedingte wahrscheinlich größere Anzahl an Redakteuren vermutlich stark behindert.
Die Kennzeichnung wichtiger Archivbeiträge
halte ich jedoch im Preis/Leistungsverhältnis sogar für besser, nur halte ich es für
sinnvoll den Preis ausser acht zu lassen und die Leistung zu verbessern,
Ich nicht. Matzes wiederholte Erwähnung, daß er selbst ja gar keine Zeit habe, limitieren den Preis sehr stark nach oben.
In meinen Überlegungen gehe ich eigentlich davon aus, dass jeder gute Anfragen
stellen kann.
Kann mal bitte jemand die Statistik veröffentlichen, wieviele Suchbegriffe mit welcher Wahrscheinlichkeit verwendet werden? (Es müßte so ein Skript von CK1 geben - ich glaube, ich habe mit Daniela mal per Mail darüber diskutiert.) Ich denke, diese Statistik würde Dich widerlegen.
Tut er dies nicht, ist er selber schuld.
Yep, und das trifft 9x% aller Besucher hier, behaupte ich mal. Entsprechend sehen die Threads aus ...
Wenn du mit der Suche besser zurecht kommst, verwende sie. Anfänger werden sich damit
erstmal herzlich schwer tun.
Das mag sein. Dann tun sie sich im WWW aber mit _allem_ schwer.
Etablierte GUIs leben von der Idee, im Wesentlichen bedienungskompatibel zu anderen etablierten GUIs zu sein, damit der Aufwand des Umlernens überschaubar bleibt. Vom Bedienungskonzept her (ursprünglich an AltaVista angelehnte) ist die in diesem Portal eingesetzte Suchfunktion derjenigen von Google relativ ähnlich (die <keyword>:<string>-Syntax gibt es dort z. B. identisch).
Du wirst mir _keine_ Suchanfrage angeben können, die alle Postings zum Thema Datenbank
ausgibt und zwar so, dass sie alle auch wirklich relevanten Inhalt haben.
Wahr, denn diese Aufgabe wäre http://www.jargon.net/jargonfile/a/AI-complete.html.
Eine weitere Möglichkeit der Aufbereitung wäre auch das menschliche Indexing, wo einigen
Postings ein Schlagwort zugeordnet wird. Diese Schlagwörter sind dann wirklich
charakteristisch für das Posting.
Und die Person, welche das Indexing durchgeführt hat. Leider.
Das wiederum erfordert aber nicht nur die Auswahl von Qualität, sondern noch dazu eine über alle beteiligten Redakteure einheitliche (!) Richtlinie für die Vergabe solcher Schlagworte.
Eben. Und das ist das Problem: Wenn die Aufgabe AI-complete ist, wie erzwingst Du dann diese Einheitlichkeit? KÖnntest Du sie erzwingen, dann wäre die Aufgabe nicht ... QED.
der sollte im Optimalfall die Indexausdrücke gar nie zu Gesicht bekommen. Die Suchanfrage
würde zuerst über einen Thesaurus oder inverted Index laufen, bis die Suchanfrage in eine
Reihe Schlagworte transformiert wurde (ja, ich weiss, dass dies beim SelfServer zum
Problem wird).
Ein gut geindexter Thesaurus saugt wesentlich weniger Kraft aus dem Server als eine stupide Volltextsuche über 500 MB.
- Postings werden zu Klassen zusammengetragen, falls deren Inhalt mit der
Klassenthematik übereinstimmen.
In welcher Hinsicht unterscheiden sich "Klassen" von den bereits unterstützten Kategorien?
Eine Klassifikation ist eine _hierarchische_ Anordnung von Klassen (Sachverhalten).
Nimmst du z.B. die Dewey-Klassifikation (Decimal Classification System), so wird das
gesamte Wissen der Menscheit in 10 Hauptklassen (manchmal auch mehr) unterteilt. Diese
Hauptklassen enthalten wiederum 10 Klassen und jede wieder 10 Sektionen. In ähnlicher
Weise wäre dies für das Wissen im Forum denkbar.
Damit habe ich genau das Problem, das ich auch bei den Feature-Artikeln habe: Ich muß den gesamten Baum auswendig gelernt haben, um den Lagerungsort eines Artikels zu finden, wenn _mir_ die Klassifikation auf oberster Ebene nicht _vollständig_ transparent ist.
Viele Grüße
Michael
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.