[Seeky] Draft

[Julian Ganz]

On Sun, 13 Mar 2011 00:55:07 +0100
Julian Ganz <Julian.Ganz at student.kit.edu> wrote:

> On Mon, 7 Mar 2011 13:06:48 +0100
> Niels Dettenbach <nd at syndicat.com> wrote:
> > 2.)
> > Typische Suchanfragen gegen die Indizes wiederum nutzen "andere"
> > Protokolle gegenüber jeweils spezialisierten MIs, deren Protokolle
> > vielfältig sein können / dürfen (allerdings muß sich auch darum
> > jemand Gedanken machen, wenn er erste MIs implementieren will). Ein
> > Basis Set der wichtigsten / "primären" MIs allerdings wird noch
> > benötigt (z.B. MIs mit Zuordnung Keyword (Kombination) <-
> > > Domain wie z.B. -''- -> URIs) bzw. kann von vereinheitlichten 
> > Basiskonventionen stark profitiertieren (soweit habe ich noch nicht
> > gedacht). Erlaubt wie denkbar wären auch mehrebige MIs (welche nach
> > außen als ein MI erscheinen / nutzbar sind).
> Das wäre die "Frage". Wahrscheinlich werde ich diesen So noch einen
> groben Überblick über "Frage" verfassen. Dann sollte alles klarer
> werden.
Nun, wie versprochen, ein überblick über meine persönliche Vorstellung
einer Such-Anfrage.

1) Die erste Frage, die man sich stellen sollte, ist ironischer weise
was geantwortet werden sollte, was also als Feld in einer Antowrt
auftauchen sollte, falls die Gegenstelle etwas damit anfangen kann. Das
lässt sich in Klassen einteilen:
1.1) Content-Referenze (URIS)
1.2) Metadata (zB Atime, Größe, aber auch ID3-Tags)
1.3) Rank (Ranking-Information)
1.4) Index (Indices und -strukturen)
1.5) Ports (Addressen anderer PLBs, MIs oder SREs, vor alles für SRRs
und P2P interessant)
In einer Such-Anfrage sollte mindestens eine dieser Klassen auftauchen,
optional mehrere. Die Klasse "Ports" exkludiert alle anderen. Jede
Klasse beinhaltet Keywords/IDs, welche später Feld-Typen entsprechen,
welche geliefert werden, evtl pro Klasse zusammengefasst werden (zB
im Falle von Inhalts-Referenzen).
2) Die zweite Frage ist, nach was gesucht werden soll. In einigen
Fällen entfällt dieser Teil bzw wird ignoriert (wenn zB der erste Teil
die Kategorie "Ports" enthält).
Dieser kann wie schon gesagt als Baum aufgebaut sein. Hier kann man
auch komplexere Frage-Strukturen in Betracht ziehen, die zB Keywords in
Beziehung mit einander setzen. Die einsetzbaren Funktionen hängen dann
von den verwendeten Antwort-Klassen, also der Art der Anfrage ab.
3) Optinal könnte man noch spezifizieren, wie viele Antworten man (pro
Node) maximal haben will. Eine Timeout-Funktion wäre auch nicht
schlecht. Diese Werte sollten dann aber praktisch eher als Hinweise
oder Richtwerte angesehen und behandelt werden.

Da ich zu Faul bin, alles in EBNL zu schreiben und zu erläutern, gebe
ich ein paar Beispiele in textualer Form in einer Pseudo-Syntax.

Ein SFE fragt bei einem SRE nach...

...einer Seite über Heinrich Herz:
Content-Reference: http, https, gopher & Rank: algo1,
experimenteller_algo2 WITH keyword="heinrich" AND keyword="herz"

...den Metadaten für ein nicht korrekt gtaggtes Stück:
Metadata: name, artist, album, lengh, music-brainz-... WITH
music-brainz-id NEAR hex-hexel AND music-brainz-album-id NEAR ...

Der SRE fragt bei MIs nach...

...Seiten über Heinrich Herz:
Content-Reference: http, https, gopher & Index: wordcount, ... WITH
keyword="heinrich" AND keyword="herz" AND (lang="de" OR lang="en" )

...den Metadaten eines Stückes:
Metadata: name, artist, album, lengh, music-brainz-... WITH
music-brainz-id NEAR hex-hexel AND music-brainz-album-id NEAR ...
In diesem Fall kann die Anfrage gleich weiter geleitet werden, falls
sich nichts hilfreiches im Cache befindet.
Allgemein wird klar, dass prinzipiell nur einige Klassen und evtl
einzelne Items im Ausdrucks-Baum ausgetauscht werden müssen, wenn eine
Anfrage erst einmal delegiert werden muss (was bei einer verteilten
Suche meist geschieht). Das spart Rechenzeit und Code-Zeilen.

Ein MI fragt bei einem PLB nach Index-Datensätzen...

...über eine Seite ("abgelaufen" oder vom Vorgänger-PLB nicht
ausreichend analysiert), die dieser zu irgendeinem Zeitpunkt in der
Zukunft erwartet:
Index: ... WITH URI=...

... eines Dumps (weil gerade nicht zu tun ist):
Index: ...

Ein SRE fragt einen "Kollegen" nach...

...zusätzlichen MIs:
Ports: MI

...MIs für den Deutschsprachigen Raum:
Ports: MI WITH lang=de
Wobei "lang=de" evtl ignoriert wird und die Anfrage wie die obige
behandelt wird.

Ein SFE fragt einen SRR nach MIs für P2P-Verkehr im Deutschsprachigen
Raum:
Ports: MI WITH P2P=True AND lang=de

Einen Punkt, den ich hier nicht erwähnt habe, der sich aber in's Schema
einbauen ließe, wären Wortergänzungs-Anfragen, welche von SFEs
eingeholt werden. Auch hier wird schnell klar, wie praktisch es ist,
wenn man Anfragen einfach durchreichen kann, ohne sie nochmals neu zu
Kodieren.

Grüße
Julian