[Seeky] (kein Betreff)

[Niels Dettenbach]

Hallo Julian,

> reply to
nein, die Liste ist derart konfiguriert, das Antworten auch an die Liste zurückgehen sollten. Allerdings macht mein Handy-Mailer z.T. was er möchte und nicht was Standard ist. Header seh ich grad leider nich - nehme aber an meine Aw ist korrekt. ;)

> Listen
Ja und nein,
"Listen" im strikten Sinne relationaler Daten / Datenbanken (SQL usw.) eignen sch nur bedingt bzw. Teilanwendungen in Web-/Internet-Suchkonzepten.

Aber möglicherweise reden wir auch noch aneinander vorbei. Hast Du Dir mal das "alte" SOIF angeschaut? Im Prinzip ein listen- bzw. hash-basiertes "Datenformat" (hat sich aus div. Gründen nicht so durchgesetzt, wird aber in abgewandelter, proprietärer Form immer noch innerhalb von Suchmaschinen benutzt.). Ein Blick ins klassische Harvest NG kann auch nicht schaden...

sOIF ist im Prinzip ein ASCII basiertes Datenformat, welches numerischen IDs bestimmte Inhalte / Felder / (in NG auch komplexe Strukturen) zuordnet. Simples Beispiel (k.A. ob ich das richtig treffe, hab nicht nachgeschaut) ist z.B. Feld 1 ist die URL eines Objektes, Feld 5 ist der HTML Titel, Feld xyz ist die Liste der Links im Dokument usw.

Es gibt im klassischen SOIF / Harvest einen Satz per Konvention definierter Basisstrukturen (z.B. Feld-IDs < 1024) Feld IDs darüber können (ähnlich Ports im TCP/IP) "frei" belegt werden. Das klingt vielleich zu simpel als effizient, aber ich sehe keinen Grund warum diese Datenstruktur als Schnittstelle ungeeignetsein sollte - vor allem wenn man einzelne Feld-IDs oder Setsan Feld IDs abfragbar macht. 

Die Zuordnung der Feld IDs zu neuen, anwender wie anwendungsspezifischen Datenfeldern, kann in ähnlicher Form über zentrale, öffentliche Listen wie z.B. der Ports beim TCP/IP erfolgen.

Flache, relationale Strukturen werden gerade in großen Webanwendungen immer häufiger verdrängt (prominente Beispiele wie Amazon, Facebook, Google zeugen davon) und durch "realititsnahere" komplexere wie auch simplere NoSQL Datenstrukturen verdrängt. Dennoch wird es - so meine Vorstellung jedenfalls - einen Gutteil Meta-Indizes geben, die mit rein relationalen Datenstrukturen agieren wie hantieren. Da gibt es enorme "Betätigungsfelder"... ;)

Auf PLBs hingegen sind SQL-Datenstrukturen nur bedingt verwendbar und reichen allein jedenfalls nicht zur effizienten Abbildung/Verwaltung der Datenstrukturen (siehe z.B. Projekte wie Lucene u.a.) - daher nahm und nehme ich an, das Du (gem. meinem Strukturvorschlag) MIs wie ggf. etwas ähnliches wie SOIF in Kopf hattest. Möchte man z.B. eine klassische Suchinfrastruktur mit SQL bauen, wird man prinzipbedingt schnell an seine Grenzen stoßen - Teile der Infrastruktur hingegen können von SQL / RDBMS sehr profitieren.

Wie gesagt unterscheidet mein Konzept zwischen der Daten-Kommunikation zwischen primär PLBs und MIs (SOIF per UDP wie TCP) und zwischen Suchanwendung (SRR und SFE), welche mit quasi beliebigen Datenstrukturen (auch relationalen) kommunizieren können (sei es per JSON, XML-RPC, DNS, LDAP, SQL oder was auch immer zum jeweiligen MI am besten passt). 

Die Anforderungen an die Datenstrukturen (Performance, Rechenressourcen) im Verhältnis Suchanwendung / MI sind prinzipbedingt anders gelagert als MI - PLBs.

Wenn Du z.B. von einem durchweg relationalen Konzept überzeugt bist, steht es Dir frei ein solches zu realisieren - im Kontext Seeky MIs -> SFE oder als Summarizer-Modul am PLB.

Oder bist Du auf einer anderen Spur?

Btw:
Ich suche Leutz die mit mir Harvest NNG (new new generation) bauen wollen - z.B. auf freshmeat oder SF und gem. klassischem Harvest NG in Perl. Interesse? Ein paar Dinge habe ich schon erweitert - z.B. einzelne neue Summarizer usw. Dank Perl ist das System recht übersichtlich wie lesbar geblieben - eine gute Basis für eine funktionierende Referenzimplementierung, die man wohl nur noch in punkto Performance durch C toppen kann.


Beste Grüße,

Niels.
http://seeky.org