[Seeky] (kein Betreff)

[Niels Dettenbach]

ernet - Entwicklerliste" <seeky at seeky.org>
Subject: AW: Re: [Seeky] Draft
Date: Sun, 13 Mar 2011 10:06:11 +0100
Message-ID: <lNBKQ4wX49Rw.T74S2Gls at syndicat.com>
X-Mailer: EPOC Email Version 2.10
MIME-Version: 1.0
Content-Language: i-default
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hallo Julian,


vielen Dank f=C3=BCr Deine Stellungnahme / Ideen soweit.

(aktuell lesen hier noch zwei Hand voll Leute mit - dann gibt's da noch ein =
public archive...).

Bin diese Woche durchweg zu einer Schulung - komme daher erst am kommenden =
WE wieder zur Weiterarbeit am Konzept wie damit auch zu einer =
ausf=C3=BChrlicheren Antwort auf Deine Punkte bzw. ggf. zur Einarbeitung =
nun bestehender gemeinsamer Punkte.

Wie ich lese, sprechen wir inzwischen eine in vielen Punkten =
=C3=A4hnliche bis gleiche Sprache, bei anderen Punkten bestehen noch =
Mi=C3=9Fverst=C3=A4ndnisse - wohl auch mangels konkreter Darlegung im =
Konzept. Ich nehme an das sich mit der fortf=C3=BChrenden Dokumentation / =
Darlegung / =C3=9Cberarbeitung / Konkretisierung der bisherigen =
Konzeptideen dort noch einiges erhellen wird, was dann auch besser im =
Detail debattieren l=C3=A4sst. So =C3=BCberlege ich u.a. den Term Primary =
Level Broker" in einen anderen zu =C3=BCberf=C3=BChren, da sonst die z.B. =
im Harvest Project =C3=BCbliche Nutzung dieses Terms zu Verwirrung =
f=C3=BChren k=C3=B6nnte und wohl auch f=C3=BChrt (da mu=C3=9F ich =
aufr=C3=A4umen).

Meine Aufgabe...

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=C3=BCr Meta-Daten zu URLs - nicht als =
"Suchprotokoll". Aus gutem Grund m=C3=B6chte 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. PLBs machen im Prinzip nichts weiter =
als MetaDaten nach netloc/URI angefordert auszuliefern bzw. als Dumps =
=C3=BCber die Datens=C3=A4tze ganzer Web- bzw. Domainspaces, stehen / =
befinden sich h=C3=A4ufig bei lokalen ISPs oder auch direkt an betr. =
Webservern.

Damit wird u.a. verhindert, das eine stetig wachsende Zahl an Suchanfragen =
/ Suchclients - vor allem "unrelevanter" - PLBs direkt belasten k=C3=B6nnen =
- schon gar nicht mit komplexeren (und damit ressourcenintensiveren) =
Anfragen.

Auf der anderen Seite wird so verhindert, das immer mehr eigenst=C3=A4ndige =
Crawler die selben Websever nach den selben Inhalten durchforsten und =
redundant, ineffizient =C3=BCbertragen, wobei die Ressourcenverschwendung =
mit mehr und mehr konkurrierenden klassischen Crawlern exponentiell wachsen =
w=C3=BCrde.

Meine Idee war und ist es demnach NICHT, ein Netz aus vielen kleinen =
"Mini-Suchmaschinen" zu bauen, die alle quasi gleichzeitig befragen - =
sondern den Prozess der Erfassung und Indizierung zu konsolidieren und klar =
von der Bearbeitung wie Beantwortung typischer wie erdenklicher =
Suchanfragen getrennt zu bearbeiten.

In der Suche (verallgemeinert / abstrahiert) steht eine Liste an URLs nicht =
zwingend am Anfang der Bearbeitung eines Suchauftrages, wom=C3=B6glich 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 =
mu=C3=9F aber nicht zwingend Ziel der Suchbetrachtung sein.

Lediglich z.B. bei der Datenrepr=C3=A4sentation der Resultate bestimmter =
Suchauftr=C3=A4ge - z.B. mit "erzwungener Aktualit=C3=A4t" auf Kosten eines =
oder weiterer "Abfragezyklen" am SER k=C3=A4me in Betracht, das ein SER =
oder gar SFE gezielt einzelne Teildatens=C3=A4tze aus einem "beteiligten" =
PLB direkt abfragt (=C3=BCber URL->FeldIDa,FeldIDb...FeldIDn oder =
gelegentlich gar ganzen Datensatz am St=C3=BCck).

Allerdings gebe ich Dir Recht, das es in der SRR<->MI Kommunikation in der =
Praxis immer wieder auch =C3=A4hnliche (!) 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. =
Allerdings ist die denkbare Vielfalt an Datentypen/-strukturen  hier um ein =
Vielfaches h=C3=B6her und in den Anforderungen anwendungsspezifischer, so =
das man max. f=C3=BCr ein Subset wie z.B. dem f=C3=BCr SOIF2 einheitliche =
Konventionen schaffen k=C3=B6nnte - z.B. indem die FeldIDs zur =
Verf=C3=BCgung stehen k=C3=B6nnen (was dann wiederum SLBs entspr=C3=A4che, =
denn ein MI kann - mu=C3=9F aber gar keine Metadaten nach URIs =
haben!).

Am besten ich mal das mal mit Beispielen auf...

Ob und wie weit man bereits zu Beginn auch die Kommunikation im Suchsystem =
(SFE,SRE,MI) in irgend einer Form "standardisieren" sollte oder =
m=C3=B6chte, wei=C3=9F ich nicht - ich pers=C3=B6nlich sehe da =
verschiedenste denkbare MIs mit u.U. sehr verschiedenen beteiligten =
Datenstrukturen, aber auch sehr verschiedenen Anforderungen an Timings, =
Aktualit=C3=A4t, Zuverl=C3=A4ssigkeit usw. so das ich =C3=BCberzeugt bin, =
das sich hier sehr wahrscheinlich immer auch anwendungspezifische =
Protokolle wie APIs beteiligt sein k=C3=B6nnen.

Falls Du da / da jemand dennoch konkrete Vorschl=C3=A4ge hat  (hast Du ja =
schon begonnen wie ich lese) - w=C3=A4re es hilfreich diese auch zu =
debattieren wie zu publizieren.=20

Dennoch sehe ich bisher einen weitaus geringeren "Standardisierungsdruck"  =
bei der Datenformatierung/-modellierung als im Segment "Erfassung", denn =
nur ein Standard erm=C3=B6glicht den verteilten, =
dezentralen/dezentralisierten Aufbau wie die Aktualit=C3=A4t von MIs - und =
damit der f=C3=BCr alle typischen Suchauftr=C3=A4ge notwendige =
"Datenbestand".

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=C3=BCbertragungen =
realisiert werden k=C3=B6nnen (von der z.T. hochparallelen Abwicklung von =
Suchanfragen bis hin zum Massenabgleich einer Reihe MIs gegen =
=C3=84nderungen in PLBs usw.).

Thema XML an PLBs:
Mein bisheriger Stand dazu - am kommenden WE dann mehr Konkretes:

Webmaster k=C3=B6nnen entweder selbst PLBs aufsetzen / anbieten oder =
externe damit "=C3=B6ffentlich beauftragen" bzw. diese "autorisieren" - =
z.B. per DNS, robots.txt oder z.B. auch HTML (Meta) tags (z.B. auch =
Aktualit=C3=A4t usw.).=20

In anderen F=C3=A4llen ist dies bereits auch bereits als Teil des betr. =
Webservers realisiert / konfiguriert (z.B. als HTTP Capability).

Denkbar w=C3=A4re auch, das SLBs Indizedaten aus p2p Strukturen (z.B. =
browser) beziehen - allerdings dann nicht autoritiv, da der Webmaster =
keinen mittelbaren Einflu=C3=9F hat. Zudem sehe ich dabei erhebliche =
Mi=C3=9Fbrauchspotentiale, da eine Sicherung der Authentizit=C3=A4t der =
erfassten Inhalte leicht besch=C3=A4digt werden kann - von defekten =
Browserimplementierungen bis hin zu vors=C3=A4tzlichen Manipulationen - =
insgesamt wohl auch eines der erheblichen Probleme bei heutigen p2p =
"Suchmaschinen".=20

Ein weiterer Nachteil ist, das es keine harte Zust=C3=A4ndigkeit wie z.B. =
nach Webspace/Domainspace gibt und so "ausgefranste" Capabilities entstehen =
- ein solcher Index / SLB "kann" ein Dokument haben, mu=C3=9F es aber nicht =
und wei=C3=9F auch nicht, was ggf. noch fehlt. Dennoch steht es jedem =
offen, Seeky um ein solches Konzept praktisch zu erg=C3=A4nzen (und hat =
damit bereits allein mehr als genug zu tun ;)

Demnach k=C3=B6nnten derartige p2p PLBs eine Suchstruktur maximal optional =
"erg=C3=A4nzen" (ev. gibt es da ja zuk=C3=BCnftig noch bessere =
Ideen).

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=C3=BCsste man mal genauer anschaun)?

Generell aber sollten Ressourcen =C3=BCber 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. Hier kommt der Anwendungsnetwickler nicht umhin f=C3=BCr eine =
konsistente Adressierung zu sorgen - die er dem PLB / den PLBs/SLBs dann =
ggf. geeignet "beibringt" (sprich =C3=BCber Listen von URIs/URLs).

Die in PLBs erfassten Datenbest=C3=A4nde sind m.E. nur in SOIF2 abgebildet =
abrufbar und ggf. =C3=BCber mehrere wahlweise Verfahren gegen MIs =
synchronisierbar (aktiv/passiv/pull/push). Ob man hierzu XML zuhilfe nehmen =
sollte/m=C3=BCsste, lass ich vorerst mal offen.

 Dar=C3=BCberhinaus w=C3=A4re auch hier ggf. eine Push/Pull-Qeue / Liste =
hilfreich (ggf. auch XML), =C3=BCber die MIs gezielt und =
vorab/"fr=C3=BCher" von inzwischen ge=C3=A4nderten URIs/URLs "aktiv =
erfahren" (passiv w=C3=A4re ein ev. gesetztes Timeout) um sich dann die =
relevanten Datens=C3=A4tze in SOIF2 fr=C3=BCher als z.B. vorgesehen =
holen/senden zu lassen.=20

Am besten ich bringe als n=C3=A4chstes mal Struktur in die Doku wie die =
bisherigen Ideen zur Ebene PLB - sonst bleiben Mi=C3=9Fverst=C3=A4ndnisse =
schlicht vorporogrammiert.



Beste Gr=C3=BC=C3=9Fe,

Niels.