Seeky ist das alternative, Open-Source- und Open-Standard basierte Suchkonzept für das ganze World Wide Web wie das Internet.
Seeky is the alternative, fully open source and open standard based search concept for the whole WWW and the Internet.
Dieses Dokument befindet sich im Aufbau - siehe Historie! These document is under construction!Seeky ist weder klassische Suchmaschinen-Software noch eine traditionelle "Suchmaschine", sondern ein Projekt das sich die Standardisierung und Konsolidierung der Internet-Suche zum Ziel gesetzt hat um neue und offene Suchkonzepte zu realisieren.
Das Konzept klassischer, zentralisierter Suchmaschinen von Harvest, Altavista bis Google stösst heute an seine Grenzen. Eine Alternative zu den heute nur noch wenigen "etablierten" Grossen wie "Google" oder "Bing" scheint nicht in Sicht, u.a. da diese Dienste inzwischen exorbitante Ressourcen benötigen wie beanspruchen, was zu einem straffen Verdrrängungswettbewerb zwischen den Suchlösungen führte und führt.
Komplett freie Suchkonzepte scheinen nach bisherigen Kriterien und Betrachtungen kaum Aussicht auf Erfolg zu haben. Klassische, straff zentralisierte Suchkonzepte sind nur mit enormen Aufwand wettbewerbsfähig realisierbar - strikt dezentralisierte wie z.B. P2P Konzepte hingegen sind quasi kaum gegen Mißssbrauch sicherbar noch bieten sie zuverlässig die erforderlichen Ressourcen wie freie Skalierbarkeit. Der Ausweg aus diesem Dilemma kann demnach nicht sein, mit noch grösseren Infrastrukturen die klassischen Strukturen weiter auszureizen. Eine neue Suchmaschinengeneration erfordert auch neue, revolutionäre Lösungsansätze und Grundkonzepte.
Seeky als ein neues, revolutionäres Grundkonzept greift die bisherigen Ideen unter Beachtung der bekannten wie auch zu erwartenden Probleme auf und möchte nicht einfach eine freie, alternative "Suchmaschine" im klassischen Sinne realisieren, sondern die bis heute bestehenden, bekannten Grundprobleme aller traditionellen "Suchmaschinen" sukzessive oder prinzipiell eliminieren. z.B:
Ein ausführlicheres Designkonzept (insbesondere mit Diagrammen) folgt in den kommenden Tagen auf der Mailingliste zur allgemeinen Diskussion.
Basis der Suchinfrastruktur sind teils klassische Komponenten, allerdings in weithin neuer Konstellation und Konventionen, basierend auf einem Set freier bestehender wie z.T. auch neuer / erweiterter Internet RFC-Standards. Ein Kernziel ist, mit geringsten ressourcentechnischen Aufwänden - damit also auf Basis bestehender, etablierter Infrastrukturen - zu arbeiten.
Einzelne Komponenten können dabei von beliebigen Anbietern, Dienstleistern oder vom Anwender selbst betrieben werden - ebenso applikationsspezifische Kombinationen oder Erweiterungen. Keine Instanz benötigt auch nur annährend derart umfangreiche Ressourcen wie heutige, zentralisierte Suchmaschinenanbieter.
Ein Gatherer ist ein Prozess, der Inhalte von Websites einsammelt und in alternativen, vereinfachten Datenstrukturen bereitstellt. Während ein Harvester ("Ernter") in der Form eines klassischen "Crawlers" selbsttätig Websites rekursiv durchgeht und deren Inhalte samt Aktualität erfasst, kann ein "Gatherer" im Sinne Seekys Daten auch direkt aus den betr. Servern (z,B. Webservern) beziehen. Z.B. kann ein solcher "Gatherer" als Webserver-Modul (natürrlich auch als FTP-Server, News-Server- oder gar Datenbankserver-Modul) realisiert sein. Vorteil dieser Lösung ist, das bereits Rechte und Zugriffskonventionen des Webservers berücksichtigt werden können. Zudem können Webmaster weitaus genauer bestimmen, welche Inhalte wie zu erfassen sind bzw. erfasst werden können. Gerade dynamische Anwendungen wie Anwendungen mit komplexen Berechtigungen sind damit gezielt publizierbar. ein Gatherer kann z.B. - je nach Konfiguration - Seiten / Websites bei Anfrage/Seitenabruf analysieren oder auch (auml;hnlich einem klassischen Crawler - aktiv erfassen (oder beides). Webmaster können zudem gezielt bestimmen, wie und was zu erfassen ist. Über einen modularen Aufbau des Gathers können auch spezielle Erfassungsszenarien gezielt wie effizient realisiert werden - z.B. per sitemap.xml usw..
Ein Harvester kann dort zum Einsatz kommen, wo Websites oder ISPs (noch) keinen Gatherer-Dienst bereitstellen. In der Arbeitsweise ist er mit klassischen Crawlern der klassischen, grossen Suchdienste vergleichbar - allerdings ist es nicht mehr zwingend, das jeder Crawler alle Websites, crawlt, sondern z.B. nur einen mehr oder weniger grossen Teil des Webs oder auch z.B. nur Domains..
Harvester wie Gatherer halten die selben Datenstrukturen und bieten dem Suchnetzwerk die selben Schnittstellen an. Die Datenhaltung selbst erfolgt anwendertransparent. Zum Einsatz eignen sich vornehmlich NoSQL- oder objektorientierte Datenspeicher.
Summarizer sind Module für Gatherer und Harvester, die nach verschiedensten Kriterien die erfassten Inhalte "destillieren" bzw. in diverse Datenstrukturen, die für die Suchabfragen erforderlich bzw. hilfreich sein können.
Module sind standardisiert (API) und Harvester wie Gatherer können statisch wie dynamisch um Summarizer-Module erweitert werden. Denkbar wären auch zentrale-offene Kataloge für Module wie automatisierte Update-Services, ueber die Harvester wie Gatherer-Betreiber automatisch oder gezielt neue Summarizer-Module / Modulversionen beziehen und in Betrieb nehmen können. Wer - abgesehen z.B. einem Basisset - welche Module nutzen möchte oder nicht, ist jedem selbst überlassen. Die Module erweitern die "Intelligenz" der Datenerfassung wie die angebotene SOIF-NG Datenstruktur.
Erweiterungsmodule können z.B. auch direkt von MIs / SLBs entwickelt und bereitgestellt werden um eine geeignete "Destillation" für den jeweiligen MI bereitzustellen..
SOIF ist ein klassisches, rfc-definiertes Datenaustauschformat innerhalb / zwischen "Suchmaschinen" und es umschreibt ein Set typischer Metadaten zu einem Dokument plus per numerischer Konvention identifizierbarer erweiterter Datenfelder. Denkbar wäre einerseits eine Erweiterung des Standards um komplexere Array Strukturen (z.B. JSON in SOIF Feldern) wie eine globale Konvention, über die neuen Strukturen noch freie Feld-IDs zugeordnet werden können (vgl. z.B. IP Ports / Services). So können Summarizer z.B. auch Informationen wie Versionsstände, "Screenshots" usw. rendern oder detailliertere Informationen zur Aktualität der Inhalte bereitstellen. Per Feld-ID Konvention wissen MI / SLB wo/wie sie bestimmte Datenstrukturen an einem PLB erreichen.
Zu bedenken wäre auch, ob und wie weit ein gem. RFC vorgesehener IANA-Registrierungsprozess erforderlich ist oder dezentrale, autonome Zuordnungsstrukturen realisierbar sind.
mehr siehe: Primary Level Broker
Über Primary-Level-Broker (PLB) stellen Harvester / Gatherer Dokumentinformationen in einem derart einheitlichen Format externen Diensten wie Meta-Indizes, Meta-Brokern (bzw. Second-Level-Broker) oder auch SRRs direkt an. MB wie PLBs stehen demnach idealerweise (aber nicht zwingend) den betr. Webservern "nahe" bzw. sind als Erweiterungen dieser realisiert. MI / SLBs holen so nur die Daten ("Essenzen"), die sie für ihre jeweilige Arbeit ben&oouml;tigen, was auch wiederum wesentlich Ressourcen spart.
Meta Indizes (MI) übernehmen - unterstützt von Second-Level-Brokern - eine wichtige, koordinierende Rolle zwischen Datenerfassung und Datenabfrage. Meta-Inidizies "wissen" z.B. auf welchen Hosts bzw. Resssourcen welche Daten zu welchen Domains wie aktuell und glaubwürdig erfasst sind - ebenso ordnen einzelne Meta-Indizes z.B. flach Stichworte Subindizes bzw. PLB-Quellen zu. Ebenso gibt es Metaindizes, die Drittinformationen wie z.B. Vertrauenswerte, Nutzungsvolumina usw. anbieten. Welche Indizes eine Suche wie ein Suchender nutzt und wichtet, ist so offen gelöst..
mehr siehe: Meta-Indizes (MI)
Meta Broker / Second-Level-Broker (MB / SLB) können Daten von Brokern (PLBs) cachen oder um eigene, anwendungsspezifische Datenstrukturen erweitert per SOIF-NG anbieten.
Während MB / SLB ebenso wie die PLB Daten per SOIF-NG bereitstellen, bieten MIs Daten per einer modular erweiterbaren Abfragesprache - z.B. auf Basis einfach zu erlernender Scriptsprachen wie Python und/oder Perl. Die Nutzung der Indizes erfolgt über von den Indizes bereitgestellte, vereinheitlichte Python oder/und Perl Module. Denkbar wären auch anwendungsspezifische kombinierte Dienste aus MB / MI, die auf beiden Schnittstellentypen Daten anbieten oder gar anwendungsspezifisch effizientere Protokolle wie z.B. DNS oder LDAP Verzeichnisse.
Ebenso können "Such"-Module auch von Dritten entwickelt Zugriff auf mehrere oder verschiedene MIs / SLBs wie auch PLBs realisieren.
Während klassische Suchmaschinen i.d.R. auf geheime / "obscure" Ranking-Mechanismen setzen, können Meta-Indizes darüberhinaus z.B. auch dynamisch agieren, z.B. diverse soziale Komponenten nutzen und z.B. social media Dienste einbeziehen (und vice versa). Es steht den Anbietern der MIs frei, welche Datenquellen, Algorithmen usw. sie nutzen bzw. wie sie diese implementieren, was einen freien Wettbewerb realisiert.
Vor allem heutige, aktuelle NoSQL Datenbankl&oouml;sungen bieten hier eine breite "Spielwiese" für vielfätigste Indizes, Kataloge und Listen. Von reinen Volltext-Indizes bis hin zu Kategorisierungen oder gar einem "WWW-Filesystem" - einer in der Art eines typischen Netzwerk-Filesystems zugänglichen Sicht auf das Web bzw. Teilaspekte, welches mit frei konfigurierbaren Datenquellen "gemounted" um weitere Metadaten, Parameter wie Inhalte "erweitert" bzw. ebenenweise übereinandergelegt werden kann.
Ein Search-Request-Router nimmt Suchanfragen von Suchfrontends (SF) inkl. Parametern entgegen und konstuiert einen "Plan" (Script) zur Ermittlung der relevanten Abfragen an die Meta-Indizes. Je nach Abfragetypus oder Suchanwendung kann aus den Antworten der Indizes ein Set weiterer Abfragen an weitere Meta-Indizes (MI) oder gar direkt an Broker (PLBs / SLBs - z.B. zur Beschaffung von "Screenhots" oder "Content-Cache", Querverweise u.s.w.) generiert werden.
Der SRR sammelt die eingehenden Antworten und bereitet sie gem. Abfrage in der angeforderten Datenstruktur (z.B. JSON o.äa.) af und leitet diese an das Suchfrontend durch.
mehr siehe: Search Request Router
Ein Suchfrontend (SFE) bietet Suchenden ein spezifisches GUI / Frontend zur Konfiguration / Spezifikation einer Suchabfrage. Dabei kann quasi jeder Webmaster oder auch versierte Webanwender selbst ein eigenes Suchfrontend definieren / konstruieren - nach verschiedensten Anwenderinteressen, Bedürfnissen und Kenntnissen oder auch mit Limitierungen oder Zusatzdiensten. Zudem Können Frontends wie Suchende selbst bestimmen, wie sie welche Daten aus welchen Indizes gegeneinander wichten, filtern usw..
mehr siehe: Search Frontends
Zum Erreichen einer akzeptablen bis optimalen Performance der Abarbeitung der Suchaufträge wie zur Einsparung von Traffic und Rechenressourcen macht es Sinn, zwischen PLB <-> MI/SLB <-> SRR neben TCP vor allem UDP Protokolle einzusetzen / anzubieten.
Denkbar wä:re (nur ein Beispiel) auch eine Time-to-Live als Abfrageparameter - je nach Anwendung / Abfrage ist dem Suchenden entweder Genauigkeit oder Präzision wichtiger. Z.B. könnte ein Suchfrontend z.B. eine Art Schieberegler anbieten, mit dem der Suchende die Genauigkeit - und damit potentielle "Wartezeit" angeben kann aber auch den Ressourcenverbrauch seiner Suche mitbestimmt.
SEO-Spam / Missbrauch ist ein Kernproblem in jedem Suchkonzept. Das offene Suchkonzept löst dies auf vielfältige Weise nach Konzepten der Selbsthygiene wie sozialen Qualitätssicherung.
So kännen z.B. spezialisierte Indizes (MIs) ein Trust-Ranking fuer Domains wie Harvester/Gatherer ermitteln. Ebenso können RBLs (z.B. DNS (SRV, TXT) basiert) Informationen zur Zuständigkeit wie Vertrauenswürdigkeit von beteiligten Hosts wie Zieldomains ermitteln und bereitstellen, welche bei Abfragen bzw. bei anderen Meta-Indizes (Ranking-Indizes) einfliessen. So können Nutzer nicht zuletzt selbst entscheiden, was sie als "Spam" empfinden und was nicht - webmaster flexible verteilte Strukturen von Harvestern / Gatherern / Brokern realisieren.
Das SEEKY Projekt stellt ein Set aus freien Protokollen, Formaten wie als Open Source Software communitygetrieben zu entwickelnde referenzimplementierungen einzelner Komponenten oder einer Komponentenkette als "Referenzimplementierung".
Auf jeder der Ebenen des offenen Suchnetzwerkes bieten sich vielfältige Optionen zur kommerziellen Verwertung wie Vermarktung der angebotenen Teiledienste, zumal sich Unternehmen weniger oder mehr spezialisieren können statt die gesamte Kompetenz eines Suchsystems vorhalten zu müssen.
Achja, das Konzept ist selbstverständlichnicht nur auf Web, Mailinglisten usw. Beschrä:nkt, sondern fü quasi alle Internetdienste adaptier bzw. auf diese erweiterbar. schliesslich ist Internet nicht nur Web.
Die denkbare Anwendungsvielfalt eines SEEKY Suchnetzwerkes ist heute quasi kaum erschöpfend überschaubar und der Kreativitä der Anwender wie Anbieter sind kaum Grenzen gesetzt.
Die Potentiale für die Internetanwender wie die freie Wirtschaft sind exorbitant und vielfä:tig, wo heute Suchdienste vornehmlich mit Anzeigenwerbung und verkauften Anwenderdaten Geld verdienen (und darauf ihr Business konzentrieren) eröffnet das Seeks Konzept dem Internet ganz neue Anwendungsdimensionen für freie wie kommerzielle Dienste - inkl. der damit verbundenen gesellschaftlichen wie wirtschaftlichen Potentiale.
Basis für den Erfolg einer alternativen Anwendung sind unmittelbare ehrwerte in Funktion, Qualität und Komfort. Und hier gibt es - vor allem in der Internetdienste- wie Anwendungsbranche vielfältigsten dringenden Bedarf.
Ich selbst halte eine sukzessive, schrittweise Realisierung für real und aussichtsreich und würde wie folgt ansetzen:
Schon diese Dienste sind vielfätig anwendbar und in vielen Anwendungsszenarien erheblicher Gewinn für die Website-Betreiber wie Spezialanbieter.
sSpätestens hier werden die MI Strukturen interessant und geldwert fuerviele Anwender wie die breite Anbieterschaft im Web. damit dürfte dem Ausbau wesentlich weiterer Vorschub gelingen. Bereits relativ kleine Anbieter sind in der Lage effizient spezialisierte bis sogar umfassende Kataloge / Indizes zu betreiben wie anzubieten.
(im Aufbau / under construction)
Bei Interesse am Projekt besuche bitte unsere Mailingliste
Bisherige Beiträge dauf der Liste findest Du im Archiv.