[Seeky] (kein Betreff)

[Julian Ganz]

On Sun, 13 Mar 2011 10:13:47 +0100
Niels Dettenbach <nd at syndicat.com> wrote:
> Hallo Julian,
Hi nochmal.
Hier handelt es sich -glaube ich- um ein Missverständnis. Meiner
Auffassung nach sollten MIs Datenzentren sein und PLBs den ersten
Schritt der Analyse durchführen (und pro URI Index-Listen berechnen).
An sonsten könnte der MI auch gleich selbst Crawler spielen. Es macht
keinen Sinn, einen Crawler eine Seite laden und dann fast völlig
unverändert an einen MI senden zu lassen.

> vielen Dank für Deine Stellungnahme / Ideen soweit.
> 
> (aktuell lesen hier noch zwei Hand voll Leute mit - dann gibt's da
> noch ein public archive...).
Gut.

> Nochmal vorab zum Thema "zwei Protokolle":
> Mein Eindruck ist, wir reden auch hier noch z.T. aneinander vorbei.
> 
> SOIF2 dient im Konzept lediglich / vornehmlich als effizientes,
> wohlfefiniertes Austauschformat für Meta-Daten zu URLs - nicht
> als = "Suchprotokoll".
So hatte ich es mir auch vorgestellt. Nur, dass ich schon vorweg nehme,
dass diese Daten in eine äußere Struktur eingebettet werden.
Im Falle eines Dumpfiles oder eines in eine Website eingebetteten PLB
oder MI ergeben sich ohnehin asymetrische Übertragungen (eine Anfrage
via POST oder GET kann direkt einer Antwort zugeteilt werden). Nur bei
UDP muss diese Zuordnung erfolgen und erklärt werden, ob es sich um den
Inhalt um eine Frage oder eine Antwort haltet. Das muss uns aber bei
der Definition eines Übertragungs-Standarts für Harvester noch nicht
hindern (man kann zB ein Bit im Header dafür reservieren, dass im Falle
eines Harvesters immer einen speziellen Status hat).
Man sollte aber im Hinterkopf behalten, dass sich dieses Daten-Format
(SIOF2) auch gleich von den höheren Ebenen mitbenutzen lässt.
> Aus gutem Grund möchte ich  - zumindest in einer ersten Stufe des
> Suchnnetzes - typische Suchanfragen nicht an PLBs realisieren und
> diese auch an der unmittelbaren Abwicklung der Suchanfragen nicht
> bzw. nur optional beteiligen.
Nichts hindet sie daran, Such-Anfragen einfach zu ignorieren
(schließlich mus man nicht davon ausgehen, dass sie etwas damit
anfangen können)
> PLBs machen im Prinzip nichts weiter als MetaDaten nach netloc/URI
> angefordert auszuliefern bzw. als Dumps über die Datensätze ganzer
> Web- bzw. Domainspaces, stehen / befinden sich häufig bei lokalen
> ISPs oder auch direkt an betr. Webservern.
genau. (auch wenn der Satz sich zerhächselt gelesen hat)

> Damit wird u.a. verhindert, das eine stetig wachsende Zahl an
> Suchanfragen / Suchclients - vor allem "unrelevanter" - PLBs direkt
> belasten können - schon gar nicht mit komplexeren (und damit
> ressourcenintensiveren) Anfragen.
PLBs sollten ja auch meiner Meinung nach alle Such-Anfragen (außer evtl
zB direkte Anfragen nach Metadaten einer URI) ignorieren.

> Auf der anderen Seite wird so verhindert, das immer mehr
> eigenständige Crawler die selben Websever nach den selben
> Inhalten durchforsten und redundant, ineffizient Übertragen,
> wobei die Ressourcenverschwendung mit mehr und mehr konkurrierenden
> klassischen Crawlern exponentiell wachsen würde.
Das kann man aber mit solchen Anfragen eigentlich geziehlt verhindern
(Die wahrscheinlichkeit dass zwei Crawler eine Website 5 minuten
hintereinander Durchforsten sinkt, wenn ihnen jemand sagt, wo es sinn
macht zu Suchen) und gleichzeitig die Qualität sichern (wenn zB ein MI
Einträge, deren "Verfallsdatum" abgelaufen ist oder die von einem
einzelnen "non authoritive"-PLBs gemeldet wurde, bei sich findet und bei
PLBs ein Re-Crawling dieser Seiten beantragt).

> Meine Idee war und ist es demnach NICHT, ein Netz aus vielen kleinen
> "Mini-Suchmaschinen" zu bauen, die alle quasi gleichzeitig befragen -
Das wäre ineffizient und unlogisch. Das will ich auch nicht.
> sondern den Prozess der Erfassung und Indizierung zu konsolidieren
> und klar von der Bearbeitung wie Beantwortung typischer wie
> erdenklicher Suchanfragen getrennt zu bearbeiten.
Das bedeutet aber nicht, dass man sich nicht Gedanken machen sollte,
wie diese Strukturen vereinheitlicht werden können und wie Anfragen bzw
Antworten von Level zu Level transportiert werden können. Klar sind
PLBs bei einer Such-Anfrage nicht direkt betroffen. MIs bilden hier die
"unterste Ebene". Aber die Antworten eines MIs auf eine SRE-Anfrage
ist zB prinzipiell die selbe (die Form der einzelnen Datensätze kann
sogar identisch sein und wird dies aller wahrscheinlich keit auch).
Der einzige Unterschied besteht darin, dass der MI von den PLBs
"willkürliche" Daten empfängt während MIs diese ausgewählt nach
Thematik bzw Such-Worten an SREs liefern. Das ist die einzige Funktion
von MIs, die sie möglichst schnell zu erledigen haben und hier hilft
es, parallel zu arbeiten und mehrere MIs zu befragen, die hoffentlich
möglichst unterschiedliche Antworten liefern.

> In der Suche (verallgemeinert / abstrahiert) steht eine Liste an URLs
> nicht zwingend am Anfang der Bearbeitung eines Suchauftrages,
> womöglich auch erst ganz am Ende oder es sind sogar Abfragen
> denkbar, bei denen URLs selbst gar keine Rolle spielen bzw. nicht
> Teil der betrachteten Daten sind. Wir sind es heute noch gewohnt,
> das eine Anfrage an eine "Suchmaschine" eine Liste (genauer
> Arrays / bzw. Datenstruktur) nach URLs rauswirft. Das muss aber
> nicht zwingend Ziel der Suchbetrachtung sein.
Darauf habe auch ich schon mehrfach in Beispielen hingewiesen.


> Lediglich z.B. bei der Datenrepräsentation der Resultate
> bestimmter Suchaufträge - z.B. mit "erzwungener Aktualität" auf
> Kosten eines oder weiterer "Abfragezyklen" am SER käme in Betracht,
> das ein SER oder gar SFE gezielt einzelne Teildatensätze aus einem
> "beteiligten" PLB direkt abfragt (über URL->FeldIDa,FeldIDb...FeldIDn
> oder gelegentlich gar ganzen Datensatz am Stück).
Hier muss ich wiedersprechen. Ein SRE empfängt wie schon gesagt genau
das, was ein MI empfängt. Nur dass es sich hier um eine auswahl
handelt. Eine erneute Anfrage bei einem PLB macht hier keinen Sinn
-zumal ein SRE dann wohl tiefgründigere Analysen durchführt. Es macht
in diesem Beispiel mehr Sinn, dass ein SRE zB die Seite selbst aufruft,
"höheren" Analysen unterzieht und evtl -bei starken Diskrepanzen- den
MI benachrichtigt bzw ihm das gewonnene Index-Material liefert. (sich
also als Crawler betätäigt)

> Allerdings gebe ich Dir Recht, das es in der SRR<->MI Kommunikation
> in der Praxis immer wieder auch Ähnliche (!) Abfragen geben kann, wie
> diese auf PLB<->MI Ebene erforderlich sind - z.B. ein MetaDatum oder
> einen Satz Metadaten zu ein oder mehreren Netlocs/URIs/URLs zu
> transportieren.
Hier wurde mir dann klar, was du dir unter einem PLB vorstellst. Ich
halte diesen Ansatz für ineffizient.
> Allerdings ist die denkbare Vielfalt an Datentypen/-strukturen hier
> um ein Vielfaches höher und in den Anforderungen
> anwendungsspezifischer, so das[s] man max. für ein Subset wie z.B.
> dem für SOIF2 einheitliche Konventionen schaffen könnte - z.B. indem
> die FeldIDs zur Verfügung stehen können (was dann wiederum SLBs
> entspräche, denn ein MI kann - muss aber gar keine Metadaten nach
> URIs = haben!).
Genau. Zudem können so mehrere Index-Arten für alle URLs (in
unterschiedliche Felder gepackt) übertragen werden, was aus Sicht eines
SREs mehr Daten zur (schnellen und präzisen) Beurteilung liefern kann.


> Dennoch sehe ich bisher einen weitaus geringeren
> "Standardisierungsdruck" bei der Datenformatierung/-modellierung als
> im Segment "Erfassung", denn nur ein Standard ermöglicht den
> verteilten, dezentralen/dezentralisierten Aufbau wie die Aktualität
> von MIs - und damit der für alle typischen Suchaufträge notwendige
> "Datenbestand".
Nach meinem Modell würde sich fast alles mit der PLB->MI-Kommunikation
klären.

> ABER:
> Etwas, was auf allen Ebenen des Suchnetzwerkes hilfreich bis
> erforderlich ist (min.) ein kapselndes UDP-Protokoll (in etwa so
> wie von Dir bisher beschrieben), mit dem zeit- wie auch lastkritische
> Datenübertragungen realisiert werden können (von der z.T.
> hochparallelen Abwicklung von Suchanfragen bis hin zum Massenabgleich
> einer Reihe MIs gegen Änderungen in PLBs usw.).
Ja. Siehe Oben.

> Thema XML an PLBs:
> Mein bisheriger Stand dazu - am kommenden WE dann mehr Konkretes:
> 
> Webmaster können entweder selbst PLBs aufsetzen / anbieten oder
> externe damit "Öffentlich beauftragen" bzw. diese "autorisieren"
> - z.B. per DNS, robots.txt oder z.B. auch HTML (Meta) tags (z.B.
> auch Aktualität usw.).
Es gibt aber durchaus Webmaster, die lokal keine PLBs laufen lassen
können oder wollen und bei denen es einfach effizienter ist, lokal zu
Crawlen (weil eben direkt eine Datenbank durchgearbeitet werden kann,
anstatt nochmals HTML zu parsen und die Hälfte zu verwerfen)

> In anderen Fällen ist dies bereits auch bereits als Teil des
> betr. Webservers realisiert / konfiguriert (z.B. als HTTP
> Capability).
Das muss sich aber erst durchsetzen. Und einen Plan B zu haben ist da
immer besser, bevor man große "weiße Flecken" hat, die nicht
berücksichtigt werden. ;)

> Denkbar wäre auch, das SLBs Indizedaten aus p2p Strukturen (z.B.
> browser) beziehen - allerdings dann nicht autoritiv, da der
> Webmaster keinen mittelbaren Einfluss hat.
Genau. Siehe oben.
> Zudem sehe ich dabei erhebliche Missbrauchspotentiale, da eine
> Sicherung der Authentizität der erfassten Inhalte leicht
> beschädigt werden kann - von defekten Browserimplementierungen
> bis hin zu vorsätzlichen Manipulationen - insgesamt wohl auch
> eines der erheblichen Probleme bei heutigen p2p "Suchmaschinen".
Wie schon weiter oben und in anderen Mails beschrieben, sehe ich hier
bei angepasster Implementierung von MIs keine Probleme. Es wäre
schlicht dähmlich, Daten zu einer URI gleich zu verwerfen, wenn für
diese neues Datenmaterial aus dritten Quellen ankommt. Generell sollten
für eine URI für eine Index-Art jeweils mehrere Versionen vorliegen,
die alle (gewichtet) herangezogen werden können. Aber das betrifft
schon MI-Implementierungen.

> Ein weiterer Nachteil ist, das es keine harte Zuständigkeit wie z.B.
> nach Webspace/Domainspace gibt und so "ausgefranste" Capabilities
> entstehen
"P2P-PLBs" werden wohl erst aktiv (in Bezug auf "Daten zu einem MI
senden"), wenn für die Domain kein integrierter PLB vorhanden ist.
Wenn doch kann der MI diese ja immer noch ignorieren oder den Daten
weniger Gewicht geben. Die Gruppe ohne "Domain-PLB" wird aber extrem
groß sein und hier _brauch_ man Dritte Crawler.
> ein solcher Index / SLB "kann" ein Dokument haben, muss es aber nicht
> und weiß auch nicht, was ggf. noch fehlt.
Allein "Verfallsdaten" helfen hier sehr viel weiter. Zudem ist es gut
denkbar, verlinkte URIs -falls releveant- mit abzulegen. Falls diese
nicht im Index auftauchen, wurden sie noch nicht von einem Crawler
bearbeitet und können dann an andere PLBs mitgeteilt werden.

> Demnach könnten derartige p2p PLBs eine Suchstruktur maximal optional
> "ergänzen" (ev. gibt es da ja zukünftig noch bessere Ideen).
Genau das sehe ich nicht so. Zumindest nicht, so lange PLBs nicht bei
den Hosts selbst betrieben werden. Die Datenmengen sind einfach zu
enorm.

> Zur noch gezielteren Steuerung der Erfassung sollte ein PLB (oder
> auch ggf. SLBs) auch per z.B. XML"steuerbar" sein - z.B. per
> sitemap.xml Standard (passiv) oder ev. noch weitere XML basierte
> Verfahren - z.B. eine Art = "priority qeue" - ev. auch z.B. als
> Erweiterung von sitemap xml realisierbar (müsste man mal genauer
> anschaun)?
All das würde sich in meinem Schema erledigen. (Durch Anfragen von
PLBs an MIs: "wo soll ich weiter machen?")

> Generell aber sollten Ressourcen über eindeutige netlocs/URLs/URIs
> adressiert und von PLBs selbst erfasst werden, um weitgehend
> sicherzustellen, das an der betr. URL auch der betr. Inhalt
> reproduzierbar anliegt.
Vollkommen
> Hier kommt der Anwendungsnetwickler nicht umhin für eine konsistente
> Adressierung zu sorgen - die er dem PLB / den PLBs/SLBs dann ggf.
> geeignet "beibringt" (sprich Über Listen von URIs/URLs).
In den meisten Fällen lässt sich so etwas von Dritten sehr einfach
sicherstellen. Bei Host-Seitigen PLBs entfällt das Problem eventuell
ganz.

> Die in PLBs erfassten Datenbestände sind m.E. nur in SOIF2 abgebildet
> abrufbar und ggf. über mehrere wahlweise Verfahren gegen MIs
> synchronisierbar (aktiv/passiv/pull/push). Ob man hierzu XML zuhilfe
> nehmen sollte/müsste, lass ich vorerst mal offen.
Wie schon angedeutet. Lässt sich alles in einem einfachen UDP
Kapsel-Protokoll regeln. So verrennt man sich nicht in das basteln von
hunderten einzelner Protokolle, die man über genau so viele Sockets
verteilt.

> Darüberhinaus wäre auch hier ggf. eine Push/Pull-Qeue / Liste
> hilfreich (ggf. auch XML), über die MIs gezielt und vorab/"früher"
> von inzwischen geänderten URIs/URLs "aktiv erfahren" (passiv wäre ein
> ev. gesetztes Timeout) um sich dann die relevanten Datensätze in
> SOIF2 früher als z.B. vorgesehen holen/senden zu lassen.
Ja. Siehe oben.

> Am besten ich bringe als nächstes mal Struktur in die Doku wie die
> bisherigen Ideen zur Ebene PLB - sonst bleiben Missverständnisse
> schlicht vorporogrammiert.

> Beste Grüße,
> Niels.
Grüße,
Julian