nicht angemeldet
Erfahrungen mit interner Suchmaschine
Hallo!
Mich würden Erfahrungen mit diverser freier Software für eine interne Suchfunktion interessieren. Im Moment fühle ich mich von der riesigen Anzahl von Suchscripts ziemlich erschlagen und wüsste gar nicht recht, wo ich beim Testen anfangen sollte.
Wichtig wären mir folgende Aspekte:
- (halbwegs) einfache Möglichkeit zur Konfiguration, verständliche Dokumentation
- individuell einstellbare Suchfelder, z.B. nach bestimmten Metatags
- individuell einstellbare Sektionen der Site
- zeitliche Eingrenzbarkeit der Suche
- diverse Sortierparameter (nach Datum, nach Treffergenauigkeit, Anzahl der angezeigten Suchtreffer, mit oder ohne Beschreibung)
- einstellbare Kriterien zum "Pagerank"
- Boolesche Operatoren, Phrasensuche
- Volltextsuche über Indexdatei, möglichst keine Datenbank
Das Script sollte also eine ganze Menge können; ich weiß nicht, ob es das als freie (oder preislich günstige) Software gibt. Die Programmiersprache ist mir eigentlich egal.
Beim Suchen bin ich immer wieder auf die folgenden drei Suchprogramme gestoßen:
Swish-e: http://swish-e.org/
ht://Dig: http://www.htdig.org/
Perlfect Search: http://www.perlfect.com/freescripts/search/
Hat jemand damit Erfahrungen? Gibt es gute (bessere) Alternativen?
Für alle Rückmeldungen schon mal vielen Dank!
Beste Grüße
Bertold Bernreuter
-
Hi,
Mich würden Erfahrungen mit diverser freier Software für eine interne Suchfunktion interessieren. Im Moment fühle ich mich von der riesigen Anzahl von Suchscripts ziemlich erschlagen und wüsste gar nicht recht, wo ich beim Testen anfangen sollte.
Na, soviele gibt es da eigentlich gar nicht. Zumindest nicht, wenn Du etwas vollständiges haben möchtest.
Wichtig wären mir folgende Aspekte:
- (halbwegs) einfache Möglichkeit zur Konfiguration,
Nunja, aufgrund der verlangten Mächtigkeit dürfte das schwierig werden. Aber die mir bekannten Configs sind durch die Bank halbwegs logisch aufgebaut und daher mit relativ wenig Mühe zu konfigurieren.
verständliche Dokumentation
Nicht nur Dokumentation möchtest Du sondern auch auch verständlich? Bei FOSS? >;->
Aber die bekannten Suchmaschinen sind eigentlich recht gut dokumentiert.- individuell einstellbare Suchfelder, z.B. nach bestimmten Metatags
Das funktioniert mal mehr oder weniger aber leider nirgendwo wirklich komplett. Ist ja auch kein Wunder, da es einfach viel zu viele Protokolle für Metaangaben gibt.
- individuell einstellbare Sektionen der Site
- zeitliche Eingrenzbarkeit der Suche
- diverse Sortierparameter (nach Datum, nach Treffergenauigkeit, Anzahl der angezeigten Suchtreffer, mit oder ohne Beschreibung)
- einstellbare Kriterien zum "Pagerank"
- Boolesche Operatoren, Phrasensuche
Nun, das dürften sie alle haben. mir fällt zumindest jetzt auf Anhieb keine ein, die da deutliche Schwächen zeigen würde.
- Volltextsuche über Indexdatei, möglichst keine Datenbank
Tja, das dürfte ein Problem werden, die wirklich guten arbeiten alle mit DB da sie sonst nicht recht skalieren würden.
Das Script sollte also eine ganze Menge können; ich weiß nicht, ob es das als freie (oder preislich günstige) Software gibt.
Eine Angabe habe ich aber noch vermißt: wofür wird's eigentlich gebraucht? Die Punkte oben sind leider zu allgemein und außer der Google Suchmaschine kann keiner alles aber die dürfte das Budget sprengen (die Kisten gibt's AFAIK ab ~1200 US$)
Die Programmiersprache ist mir eigentlich egal.
Oh? Darf's also auch Javascript sein? ;-)
Beim Suchen bin ich immer wieder auf die folgenden drei Suchprogramme gestoßen:
Swish-e: http://swish-e.org/Hat eine recht flexible Konfiguration und ist selber auch recht flexibel durch die Einsatzmöglichkeit externer Filter.
ht://Dig: http://www.htdig.org/
Ist "der Standard". Ist jedoch keine freie Software! Interessiert zwar normalerweise nicht, aber es fällt nicht weiter auf und lieber einmal zuviel gewarnt ... ;-)
Perlfect Search: http://www.perlfect.com/freescripts/search/
Ist zwar nicht schlecht, aber ob's den Ansprüchen genügt wage ich zu bezweifeln.
Gibt es gute (bessere) Alternativen?
Selbermachen?
Nein, kein Scherz! Swish-e würde sich dafür z.B. als Basis anbieten. Da die Möglichkeit besteht externe Programme zu nutzen kann da auch mit marginalen Programmierkenntnissen gearbeitet werden. Deren _sehr_ vorsichtiger Hinweis "Swish-e is ideally suited for collections of a million documents or smaller" ist nicht sehr ernst zu nehmen, so schlecht skaliert das Dingen auch wieder nicht. Außerdem soll ja auch nicht mit einer DB gearbeitet werden (warum auch immer).Ansonsten kann man noch die Suche von http://freshmeat.net/ und http://sourceforge.net/ nutzen und sich da näher umschauen.
Kenntnisse über den genauen Einsatzzweck könnten aber hilfreich sein.
so short
Christoph Zurnieden
-
Hi Christoph,
ht://Dig: http://www.htdig.org/
[...] Ist jedoch keine freie Software!merkwürdig – wenn ich hier auf meinem Rechner auf „License Information“ klicke, erscheint die GPL-2.
Viele Grüße
Benjamin-
Hi,
ht://Dig: http://www.htdig.org/
[...] Ist jedoch keine freie Software!merkwürdig – wenn ich hier auf meinem Rechner auf „License Information“ klicke, erscheint die GPL-2.
Es gibt Dinge, die sind schon mehr als peinlich und dies ist eine davon:
"As decided by the HtDig Board Members and ratified by the HtDig Membership
in October of 2002 the HtDig codebase is now licensed under the LGPL."
Immerhin schon seit fast 3 Jahren. Autsch!Ich entschuldige mich hiermit bei allen Beteiligten.
so short
Christoph Zurnieden
-
-
Hallo Christoph!
Erst mal vielen Dank für deine ausführliche Rückmeldung!
Die Suchfunktion soll auf http://www.polylog.org/ zum Einsatz kommen, das ist eine internationale philosophische Zeitschrift, mit Diskussionsforum, Maillistenarchiv, Linklisten usw. Bislang behelfen wir uns noch mit dem kostenlosen Service von Atomz; das funktioniert allerdings nur noch, da wir schon ganze Site-Bereiche ausgeklammert haben, um nicht über die Höchstgrenze von 750 durchsuchten Seiten zu kommen.
Das Projekt hat jetzt vielleicht knapp 3.000 Dateien, auch in ein paar Jahren werden es kaum über 10.000 sein. Daher dachte ich auch, dass der Einsatz einer Datenbank bei der Suche überdimensioniert ist, aber natürlich sperre ich mich nicht dagegen.
Zu den individuell einstellbaren Suchfelder:
Wir haben konsequent Metatags gesetzt à la:
<meta name="author" content="Name, Vorname">
<meta name="date" content="JJJJ-MM-TT">
<meta name="polylog.rubric" content="Sektion|Rubrik">
<meta name="DC.Title" content="Titel...">
<meta name="DC.Language" content="de">
Keywords und Description sowieso.
Die sollten im Idealfall gänzlich verarbeitbar sein, also z.B. eine Suche innerhalb einer bestimmten Rubrik möglich sein.An Dateiformaten kommt bislang fast ausschließlich reines HTML zum Einsatz. Das soll sich mittelfristig allerdings ändern und ein Großteil der Texte in eine Datenbank verfrachtet werden. (Im Moment bin ich für sowas allerdings noch zu blöd, zumal das Layout der Zeitschrift nicht ganz trivial ist.) Weiterhin soll das Projekt um eine Textanthologie im OpenAccess Standard erweitert werden, wahrscheinlich also PDF-Texte (obwohl ich mit diesem propietären Zeug nicht wirklich glücklich bin).
Ich erwähne das u.a. auch deshalb, weil es dann mit der bisherigen Einheitlichkeit der Dokumente vorbei sein wird. Dann wird's wohl ein Nebeneinander von HTML, XML und PDF geben, teilweise in Datenbanken, teilweise nicht, vermutlich auch (leicht) unterschiedliche Standards bei den Metaangaben. Das sollte das Suchscript idealerweise bewältigen können. Man müsste ihm also sagen können: Schau hier nach UND da UND dort.
Wie du schon hörst, bin ich programmiermäßig vollkommen unbeleckt und schaffe es gerade so, ein Perlscript anzupassen und ein wenig an den Einstellungen zu drehen. Echtes Programmieren jedoch komplett Fehlanzeige. Gegebenenfalls müssten wir uns halt Hilfe von außen holen.
polylog ist ein so unkommerzielles Projekt, wie man's sich nur gerade vorstellen kann. Insofern sollte es bei ht://Dig mit der GNU GPL 2 eigentlich keine Probleme geben.
Ich hoffe, es ist ein bisschen klarer geworden, was ich will.
Beste Grüße
Bertold Bernreuter-
Hallo!
Was ich bislang ganz vergessen hatte, ist der Aspekt der Internationalisierung. Im Idealfall wäre das Suchscript also voll unicode-fähig und könnte auch auf Farsi, Arabisch, Thai oder Mandarin indexieren und suchen. (Das wäre vor allem für das erwähnte Textarchiv wichtig.) Doch diese Funktionalität scheint zurzeit wohl noch absoluter Wunschtraum zu sein. (Oder doch nicht?) Wo wäre am ehesten zu erwarten, dass in diese Richtung nachgerüstet wird? Christoph, du meintest, Swish-e ließe sich am ehesten und einfachsten individuellen Bedürfnissen anpassen. Auch dahingehend? Mir erscheint das als ein ziemlicher Brocken. (ht://Dig scheint ja momentan noch nicht einmal PDFs lesen zu können.)
Beste Grüße
Bertold Bernreuter -
Hi,
Das Projekt hat jetzt vielleicht knapp 3.000 Dateien, auch in ein paar Jahren werden es kaum über 10.000 sein.
Wenn ihr archiviert würde ich die Schätzung die eine oder andere Null nach oben korrigieren. Aber auch dann ist keine der gängigen Suchmaschinen auch nur ausgelastet.
Daher dachte ich auch, dass der Einsatz einer Datenbank bei der Suche überdimensioniert ist, aber natürlich sperre ich mich nicht dagegen.
Eine gute DB kostet heutzutage nicht mehr viel. Geld gar keines mehr und auch die Pflege ist recht preiswert zu haben, für das DB-Backend einer Suchmaschine dürften ein Stündchen oder zwei Einarbeitung reichen. Es gibt auch eine Menge HOWTOs im Netz, mit ein wenig Glück kann dann die Einarbeitung der Abarbeitung weichen.
Wichtig ist ein DB aber auch für Volltextsuchen, das ist dann deutlich einfacher.Zu den individuell einstellbaren Suchfelder:
Wir haben konsequent Metatags gesetzt à la:
<meta name="author" content="Name, Vorname">
<meta name="date" content="JJJJ-MM-TT">
<meta name="polylog.rubric" content="Sektion|Rubrik">
<meta name="DC.Title" content="Titel...">
<meta name="DC.Language" content="de">
Keywords und Description sowieso.
Die sollten im Idealfall gänzlich verarbeitbar sein, also z.B. eine Suche innerhalb einer bestimmten Rubrik möglich sein.Das ist z.B. mit swish-e möglich, die werben sogar damit.
An Dateiformaten kommt bislang fast ausschließlich reines HTML zum Einsatz. Das soll sich mittelfristig allerdings ändern und ein Großteil der Texte in eine Datenbank verfrachtet werden. (Im Moment bin ich für sowas allerdings noch zu blöd, zumal das Layout der Zeitschrift nicht ganz trivial ist.) Weiterhin soll das Projekt um eine Textanthologie im OpenAccess Standard erweitert werden, wahrscheinlich also PDF-Texte (obwohl ich mit diesem propietären Zeug nicht wirklich glücklich bin).
Für Textanalysen gibt es jede Menge. Meist funktioniert es recht gut die passenden englischen Fachbegriffe in die Sourceforge- und Freshmeatsuchen einzugeben.
Ich erwähne das u.a. auch deshalb, weil es dann mit der bisherigen Einheitlichkeit der Dokumente vorbei sein wird. Dann wird's wohl ein Nebeneinander von HTML, XML und PDF geben, teilweise in Datenbanken, teilweise nicht, vermutlich auch (leicht) unterschiedliche Standards bei den Metaangaben.
Wenn sowieso eine Überarbeitung der Website ansteht würde ich darum Sorge tragen, die Protokolle nicht allzusehr divergieren zu lassen. Drei bis vier Stück lassen sich noch gut pflegen, aber das kann sehr schnell ausufern und ist dann nur noch durch schmerzhafte Schnitte wieder in einen beherrschbaren Zustand zu bekommen. Meiner Erfahrung nach beginnt das Chaos im Schnitt bei etwa 8 verschiedenen Protokollen, hängt aber auch etwas von den artistischen Fähigkeiten des Admins ab und dessen Jonglagekünsten.
Man müsste ihm also sagen können: Schau hier nach UND da UND dort.
So etwas wie Googles "filetype", "site" usw?
Wie du schon hörst, bin ich programmiermäßig vollkommen unbeleckt
Das war jeder irgendwann einmal. Nicht nur programmiermäßig.
und schaffe es gerade so, ein Perlscript anzupassen und ein wenig an den Einstellungen zu drehen. Echtes Programmieren jedoch komplett Fehlanzeige. Gegebenenfalls müssten wir uns halt Hilfe von außen holen.
Dafür müßte dann aber feststehen, was genau benötigt wird und vor allem: in welcher Wichtung. Ansonsten wird's teuer.
polylog ist ein so unkommerzielles Projekt, wie man's sich nur gerade vorstellen kann. Insofern sollte es bei ht://Dig mit der GNU GPL 2 eigentlich keine Probleme geben.
Ja, streu' nur Salz in meine Wunden, ich hab's ja auch verdient.
Jedoch ist bei der GPL die kommerzielle Benutzung gar kein Problem, das wäre es nur bei vielen anderen Lizenzen. Problematisch wäre es nur, wenn Du den Code änderst und die geänderte Software verkaufen würdest ohne dem Käufer die Möglichkeit zu bieten den geänderten Code zu beziehen.
So alles in allem dürfte Dein Bedarf tatsächlich in Höhe einer ausgewachsenen Suchmaschine liegen, da wird die Luft natürlich etwas dünner. Ob nun htdig oder swish-e ist fast schon Geschmacksache, ich persönlich finde swish-e etwas komfortabler.
Irgendwo habe ich doch noch ... ah, da ist es.
Ich hatte mal einiges für Selflinux geschrieben, aber da es da einige Merkwürdigkeiten gab nicht mehr veröffentlicht (das Teil über Paßwörter hat es reingeschafft, würde ich heute aber auch kräftig revidieren oder gar komplett neu schreiben)
Eines davon war eine kurze Abhandlung über das Suchen allgemein, da ist ein eine Übersicht über swish-e drin, htdig habe ich jedoch abgebrochen als man mich über die Schwierigkeiten bei Selflinux informierte.Was steht da in Deinem Nachtrag? Ah, ja, Unicode. Tja, dann hat swish-e leider verloren, denn das wäre eine Heidenfummlei. Htdig scheint da wohl auch noch nicht komplett zu sein.
Aber dafür habe ich glücklicherweise noch einen Tip in der Hinterhand: Estraier bzw Hyperestraier.so short
Christoph Zurnieden
-
Hallo Christoph!
Nochmals vielen Dank für deine Anmerkungen.
Den Links werde ich nachgehen.Beste Grüße
Bertold Bernreuter
-
-