[Seeky] (kein Betreff)

[Julian Ganz]

On Sat, 5 Mar 2011 13:35:27 +0100
Niels Dettenbach <nd at syndicat.com> wrote:

> 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. ;)
Ah, die zweite Addresse muss wohl _deine_ sein. Sry

> > Listen
> Ja und nein,
> "Listen" im strikten Sinne relationaler Daten / Datenbanken (SQL
> usw.) eignen sch nur bedingt bzw. Teilanwendungen in
> Web-/Internet-Suchkonzepten.
Ich habe hier über die _Kommunikation_ zwischen den einzelnen Teilen
des Gesammtprojekts geschrieben, nicht über die Suche selbst.

> 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...
Schmeißt du hier nicht Formate und Algos durcheinander?

> 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. 
Weil selbst Basis-Strukturen sich ändern können. Mann kann zB auf die
Idee kommen, statt nach URLs nach Geo-Koordinaten einer Stadt zu fragen.

> 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.
Ja, nur bin ich da zB eher ein Freund von Strings.^^

> 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).
Hier fügt sich zusammen, wo du mich missverstanden hast.

> 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.
Dazu sage ich nur "Hashtables" (und Verknüpfungen der einzelnen Items
über Hashes). Ist aber meine Sache bzw werde ich darüber evtl später
schreiben -vorraussichtlich nach Abschluss einer momentan noch nicht
gestarteten Analyse.

> Oder bist Du auf einer anderen Spur?
Sollte sich erlegigt haben.

> 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.
Wie schon impliziert, sollte man erst an der Kommunikation arbeiten bzw
sich _genau_ überlegen, was für Daten wie von A nach B wandern.

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