nicht angemeldet
Vielleicht durchsuchen Sie auch "schnell" mal das Archiv und sehen nach drei Minuten 97 Fragen und 237 Antworten zu dem viel zu allgemeinen Stichwort, das ihnen eingefallen war.
Deshalb gibt es doch den AND-Operator! Genau *darum* habe ich ihn eingebaut ... weil ich selbst vorher auch 'nichts' gefunden habe.
Und deshalb bemühe ich mich, in meinen Antworten passende Stichworte für eine Suche zu liefern ("LWP::Simple" etc.) - an diese erinnere ich mich ggf. noch, während mir eine explizite Archivsuche für die Beantwortung einer Frage manchmal zuviel Aufwand ist. (Das soll der Suchende dann schon bitte selbst machen. ;-)
Mir ist bewußt, daß meine Antworten mit der steigenden Zahl meiner Postings immer knapper ausgefallen sind - und wenn es wirklich mal zu knapp war, habe ich auch gar nichts gegen eine weitere Nachfrage.
Verdammt nochmal, es steht doch so viel in Selfhtml.
... das nicht im Archiv auftaucht. Zum Beispiel die Auslese. Warum sollte nicht das Suchskript zunächst die Auslese und die Artikel durchsuchen und - als Zwischenergebnis - erste Antworten rauswerfen (Michael, liest du mit?
Ja, ich lese mit. Und ich hatte dieselbe Idee auch schon mal.
Also schnell ein Blick in den Quelltext: Aha. Anpassungaufwand für das Suchskript = NULL.
Das Problem liegt ganz woanders.
Technisch gesehen würde der Trick darin bestehen, den existierenden Schwanzabschneider zu nehmen und seine Eingabeschnittstelle so anzupassen, daß er eben nicht Forumspostings einliest, sondern Selfhtml- oder Auslese-Dateien. Im Archiv-Index stehen nämlich relative Pfadnamen zu den entsprechenden Archivdateien, und da kann man problemlos auch Verweise auf Auslese oder SelfHTML einbauen - notfalls fangen die dann eben mit ".." an, aber um die Umsetzung hat sich gefälligst der Webserver zu kümmern.
(Die Startseite von SelfAktuell müßte sich ja von hier aus auch als <../> beschreiben lassen - na, geht's?)
Wir bräuchten also 'einfach' einen (oder zwei oder drei - die Artikel allerdings sind so unsystematisch aufgebaut, daß mir davor graut, sie zu parsen) neuen Indexer. Dieser müßte den Inhalt des entsprechenden Verzeichnisses lesen (bei SelfHTML und Auslese flach, hier nützt die spartanische Verzeichnisstruktur sogar mal was ;-) und Indexeinträge erzeugen mit folgendem Inhalt (6 Felder pro Artikel):
1. $DieseDatei = relativer Pfadname der Datei in SelfHTML bzw. Auslese. Kein Problem.
2. $DieserAnker = Hm.
Wie fein soll geindext werden? Soll ein SelfHTML-Dokument mit allen Überschriftsebenen ansteuerbar sein? Sind dort auch überall Hypertext-Anker vorhanden, auf die verwiesen werden kann? Nur ein Link auf ein komplettes Kapitel JavaScript-Funktionen wird für den Suchenden furchtbar frustrierend sein, wenn ihn die Information in Zeile 529 bis 534 interessiert hätte (und genau dort auch der Suchtreffer erzielt wurde).
Wir brauchen also ein semantisches Äquivalent zu "Posting" in den genannten Dokumenten.
Bei SelfHTML würde ich vorschlagen: Alles, was in dem Navigationsmenü am Start einer solchen Datei adressierbar ist. Leider sind HTML-Dokumente keine fest strukturierten Datentypen; kann sich der Indexer auf irgendwas verlassen, was diese Struktur angeht, Stefan? Ist SelfHTML "compilierbar"? Wieviele Sonderfälle gibt es? ("So sieht's aus"-Dateien sind gar nicht strukturiert, nicht wahr?)
Bei SelfAktuell wahrscheinlich ganz ähnlich - die Navigationsstruktur ist ja immerhin identisch.
3. $DieserTitel = Inhalt zwischen <H*>...</H*> im ersten <H*-Statement des Dateiabschnitts. Nicht schön (wieder Fließtext parsen), aber irgendwie doch machbar.
Der <title> des Dokuments wäre leichter auszuwerten, aber er nützt nicht viel, wenn pro Dokument einzelne Abschnitte geindext werden sollen (an dieser Stelle ist ja leider auch der Zusatzaufwand für exakte Trefferpositionen besonders hoch) und sollte deshalb nur als Präfixteil von $DieserTitel dienen.
4. $DieserName = bei SelfHTML konstant "Stefan Muenz", bei der Auslese wiederum ... hm. Leider stehen dort nämlich gar keine Namen drin, sondern nur E-Mail-Adressen. Noch dazu oftmals mehrere zu einem Eintrag. Und zudem irgendwo mitten im Text - also wieder mühsam herauszuparsen ...
Was tun? Auch die META-Tags wie "Author" sind leider weder in SelfHTML noch in der Auslese gefüllt - so was aber auch, nein wirklich. Dieses von Menschenhand erstellte Material scheint sich einer automatischen Verarbeitung ja richtig zu widersetzen ... schade eigentlich. ;-)
5. $DieserTag = da könnte man entweder konstant das Erscheinungsdatum von SelfHTML nehmen, oder (besser) das letzte Änderungsdatum der betreffenden Datei abfragen. Kein Problem.
6. $DieserText = der Inhalt dieses Abschnitts, ggf. wie ein Forums-Posting "behandelt" (senkrechte Striche raus, wahrscheinlich auch HTML-tags - oder???). Kein Problem, nur etwas Arbeit; der größte Teil kann aus dem Schwanzabschneider abgeschrieben werden.
Da ich perl nicht kenne, habe ich kein Angst vor der Initiativstrafe.
Nichts von meinen bisherigen Ausführungen hatte mit Perl zu tun.
Es ist vielmehr ein Problem, einen Index zu erstellen, der Verweise auf eine Mischung von Dokumenten verschiedener Struktur enthält. Also erst mal eine Frage der Semantik.
Außerdem haben wir bisher "gleichrangige" Treffer bei einer Suchanfrage. Durch die Erweiterung auf SelfHTML und Auslese kämen aber Treffer in "höherwertigen" Dokumenten hinzu - dies zu berücksichtigen würde ggf. dann doch eine Änderung der Suchmaschine erforderlich machen.
(Triviale Näherung: Bisher erfolgt die Anordnung der Treffer gemäß der Anordnung im Index - wenn man also die Indexdatei einfach in der entsprechenden Reihenfolge "absteigender Qualität" zusammenmischt, dann bekommt man auch die Treffer in dieser Reihenfolge - bei immer noch unverändertem Suchskript.)
Ich denke, mit solchen Problemen dürfte sich heute die Softwareindustrie an vielen Stellen herumschlagen, wenn sie Dokumentationssysteme schreiben (bzw. benutzen) will - das ist eigentlich ein prima Anschauungsbeispiel für das Aufeinandertreffen der Welten "Fließtext" und "Datenbank" ... es liegt normalerweise *nicht* an der Datenbank. ;-)
Ich würde mich aber revanchieren wollen mit einen Beitrag für den fälligen Artikel zum Projektmanagement von Intranet)
Das merke ich mir ... ;-)
Guter Idee. Anschließend wird die Quickbar durchsucht. (Michael, ich hätte da noch ne Idee für einen weiteren Artikel :-) )
Welches Datenformat hat "die Quickbar" - und was finde ich über diese zusätzlich, wenn ich bereits SelfHTML komplett als Volltext geindext habe?
(Wie Du siehst, verwende ich die Quickbar nie - mein Lieblings-Wegweiser in SelfHTML ist das <../../to.htm>, weil ich meistens schon einen Fachbegriff im Kopf habe und dann mit Links prima weiter komme.)
Dasselbe gilt in gewisser Weise auch für die Auslese, welche allerdings überarbeitetes Archivmaterial mit höherer Qualität enthält.