YaCy Open Harvesting API: Surrogates

[Orbiter]

mit SVN 5817 steht ein schönes neues Feature bereit, das u.a. auch beim letzen Linuxtag angefragt wurde:
Eine offene Schnittstelle die zum Einpflegen eigener Daten ohne den Weg über den Crawler genutzt werden kann.

Was das heisst: man kann nun eine xml-Datei erzeugen, in ein Übergabeverzeichnis von YaCy kopieren, und dieses wird dann in YaCy eingelesen und indexiert. Kann man beispielsweise gebrauchen wenn man einen Datendump hat und diesen in den Indexierer bekommen will.

Das ganze ist Datensatz-orientiert, d.h. ein 'record' ist etwas, das man über eine URL bekommt. Diese muss immer mitgegeben werden.

Um das mal auszuprobieren, ist in SVN 5817 eine Beispieldatei dabei. Folgendes mal machen:

- YaCy starten
- dann die Datei example/surrogate_dublin_core.xml nach DATA/SURROGATES/in kopieren.
Diese Datei wird dann sofort gelesen und nach DATA/SURROGATES/out geschrieben.
Da drin steht ein Eintrag aus der Wikipedia, mit einem Link in die Wikipedia. Man kann dann nach den Begriffen, die in dem XML standen suchen.

Als Format für das XML kommt Dublin Core zum Einsatz. Das ist ein im Bibliothekswesen weit verbreiteter und anerkannter Standard für die Formalerfassung. Alle Details stehen im Beispiel.

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>
<!-- YaCy surrogate file using dublin core notion -->
<surrogates
  xmlns:dc="http://purl.org/dc/elements/1.1/">

  <record>
    <dc:Title><![CDATA[Alan Smithee]]></dc:Title>
    <dc:Identifier>http://de.wikipedia.org/wiki/Alan_Smithee</dc:Identifier>
    <dc:Description><![CDATA[Der als Filmregisseur oft genannte '''Alan Smithee''' ist ein Anagramm von „The Alias Men“.]]></dc:Description>
    <dc:Language>de</dc:Language>
    <dc:Date>2009-04-14T00:00:00Z</dc:Date> <!-- date is in ISO 8601 -->
  </record>

</surrogates>

Jetzt sind viele neue Anwendungen möglich, denn jeder kann sich seinen Harvester selber schreiben. Jeder kann seinen eigenen Crawler bauen, den laufen lassen, und als Ergebnis einfach so ein XML schreiben, und in YaCys SURROGATE/in Verzeichnis legen.

D.h. hier könnt ihr mitmachen, in eurer Lieblingssprache Harvester bauen und XML erzeugen.

[liebel-lab]

Besten Dank das ist ein wirklich sehr nützliches feature...wir werden das mal mit den 500.000 seiten unseres bioinformatic harvesters testen....report folgt..
danke
urban

[Orbiter]

ich stelle demnächst mal eine Routine zur Verfügung, mit der man aus einem Wikipedia-Dump ein Surrogat-XML machen kann. Dann kann man das schön für Performancetests nehmen, weil da ja dann der Crawler umgangen wird.

[MikeS]

Mal zur Sicherheit, ob ich das richtig verstehe:

Eine XML-Datei mit einem (geht das auch mit mehreren?) Record-Einträgen in DATA/SURROGATES/in wird in den lokalen Index von Yacy übernommen, als ob Yacy die Datei selbst gecrawlt und geparsed hätte? Und dann landet das Ergebnis über die DHT-Verteilung irgendwann im gesamten Yacy-Netzwerk?

Sicher sehr nützlich. Besonders für Daten, die aus irgendwelchen Datenbanken stammen.

[Orbiter]

das hast du richtig verstanden. Natürlich müssen wir aber Mechanismen haben, um den Stall sauber zu halten.

Wir hatten noch nie den Ansatz "Security through obscurity", sondern den Ansatz "wir schützen uns, daher macht es keinen Sinn zu spammen". Das ist ja ähnlich wie bei Wikis, da kann auch jeder Spammen aber jeder kann es wieder raus machen.

Wir brauchen hier 2 Dinge:
- Schutz gegen korrekten Inhalten aus einer falschen Domäne (Intranet in Internet)
- Schutz gegen falsche Inhalte (spam)

Der erste Fall war ja schon dadurch gesichert, dass es eine Trennung in verschiedene Netze gibt. Damit man nun nicht versehentlich Inhalte in ein ungeeignetes Netz einspielt, gibt es einen Fix in SVN 5837. Einen Schutz, dass solche Inhalte nicht per RWI-Versand in den eigenen Index kommen, gab es schon bisher. Ich habe das aber nochmal gecheckt und gesehen dass man den Vorgang noch verbessern kann. Fix ist ebenfalls in SVN 5837.

Den zweiten Fall wurde schon immer durch den Snippet-Fetch abgefangen.

[Orbiter]

es gibt jetzt eine einfache Methode, um aus Wikipedia-Dumps Surrogate-Files für YaCy zu machen. (SVN 5851 ) Dazu muss man sich erst einen Wikipedia-Dump holen, beispielsweise die Datei dewiki-20090311-pages-articles.xml.bz2 von http://download.wikimedia.org/dewiki/20 ... es.xml.bz2
Die Datei habe ich bei mir mal einfach unter DATA/HTCACHE/ abgelegt. Nicht mit bz2 entpacken! Der Konvertierer entpackt das.

Dann kann man den Konvertierer starten. Das kann man auch machen, wenn YaCy währenddessen läuft:

Code: Alles auswählen

java -Xmx2000m -cp classes:lib/bzip2.jar de.anomic.tools.mediawikiIndex -convert DATA/HTCACHE/dewiki-20090311-pages-articles.xml.bz2 DATA/SURROGATES/in/ http://de.wikipedia.org/wiki/

Das ganze läuft so: die Artikel werden as dem Dump extrahiert, der Wiki-Code aus dem XML extrahiert; der Wiki-Code dann mit YaCys Wiki-Parser geparst, das ganze als YaCy-Dokument behandelt, und dann als Surrogat-Eintrag im Dublin-Core Format in eine XML geschrieben. Dabei wird ein künstlicher Link erzeugt, indem der im Konvertierungsprozess angegebene URL-Rumpf (http://de.wikipedia.org/wiki/) um den Titel des Eintrags ergänzt wird. So heissen ja auch die Artikel und haben diese URL.

Nach 10000 Einträgen wird die Export-Datei geschlossen, und eine neue geöffnet. Es entsteht also eine Folge von Export-Dateien. Sobald die Datei geschlossen wird, wird sie von xml.tmp nach xml umbenannt, und wenn ein YaCy läuft, sieht das die xml und liest sie in den Indexer ein.

[Huppi]

Oh, das klingt ja genial!

[Orbiter]

mit SVN 5985 gibt es nun das erste content api in YaCy, das surrogate erzeugt: eine direkte Verbindung zu mysql Datenbanken kann aus phpBB3 tabellen die Posts auslesen und surrogate direkt erzeugen.
http://localhost:8080/ContentIntegrationPHPBB3_p.html

ein Beispiel eines solchen Surrogates hänge ich hier mal als attachment an.

[itgrl]

Ist das MySQL allgemein oder speziell für phpBB? Eigentlich müsste man ja nur per Schablone die Felder zuordnen um dann eine einheitliche XML-Ausgabe zu erhalten. Dann hätten wir sehr sehr viele Anwendungen zum direkt auslesen. Wenn wir das noch mit einer Suche kombinieren die der Webmaster intern nutzen kann, MySQL ist da überfordert bei vielen Benutzern, dann setzen die das auch gerne ein. Hast du dir ioff mal angesehen? Das is ein recht breit gestreutes Themengebiet abseits von Technik mit vielen externen Verlinkungen.

EDIT: Ich habs schon entdeckt, wie ich das sehe muss man da nur eine Auswahl für verschiedene Datenbanken einbauen und entsprechende Vorlagen, dann reicht ein Menüpunkt für flexibel erweiterbare Client-Datenbanken. Es gibt übrigens auch diese MySQL-Dumps aus MySQLAdmin, die wohl jeder erzeugen kann falls er seine Datenbank nicht öffnen mag für fremde Peers.

[Orbiter]

das mit einer einheitlichen Schablone geht bestimmt nicht, ich musste schon für das Auslesen der phpbb DB zwei Tabellen auslesen, eine für die Postings und eine andere für die User. Da gibt es eine ganz bestimmte Verknüpfung, für die ich eine Logic mit entsprechendem Caching gebaut habe. Ich glaube nicht das sich die Vorgehensweise generalisieren liesse.

Interfaces für andere Foren baue ich natürlich auch gerne, ich bräuchte nur entsprechende Dumps um zu sehen wie die Datenbank aufgebaut ist. Das ganze lässt sich dann auch weiter treiben, mit Exportfunktionen für Wikis, Blogs und Connectoren zu anderen APIs, wie beispielsweise twitter (die haben doch sowas) etc. Überall wo viele Daten sind.

ioff habe ich mir angesehen, und mit der Suche wenig Glück gehabt. Entweder darf man nur ein mal in der Minute suchen wegen überlastung, oder es ist ganz abgeschaltet. Wenn die eine neue Suche suchen, arbeite ich da gerne dran das es mit YaCy geht.

[dulcedo]

das mit einer einheitlichen Schablone geht bestimmt nicht, ich musste schon für das Auslesen der phpbb DB zwei Tabellen auslesen, eine für die Postings und eine andere für die User. Da gibt es eine ganz bestimmte Verknüpfung, für die ich eine Logic mit entsprechendem Caching gebaut habe. Ich glaube nicht das sich die Vorgehensweise generalisieren liesse.

Das Problem hatte ich gemeint als ich sagte meine Lösung damals war zu speziell, dürfte dir jetzt auch klar sein.
Das lässt sich aber lösen indem man sich auf die paar wenigen grossen MySQL-Systeme beschränkt, die kleinen crawlt man. Dort hat es eh keinen Sinn eine Unterscheidung vorzunehmen ob man für Inhalte auf die DB selbst verweist oder mit Suchergebnissen direkt verlinkt.
Diese paar wenigen grossen System kann man aber insoweit standardisieren dass man Vorlagen baut um nicht direkt Java programmieren zu müssen, das kann man bei Bedarf in späteren Schritten immer noch. Beispiel:
User<->Post<->Thread ist in allen Beziehungen relational, als XML auf ein Posting aufgelöst müsste man also für jedes Posting Thread- und Userinformationen fest als Werte übernehmen, mehr nicht. Dieses Schema funktioniert auch bei allen anderen CMS-Systemen die ich kenne, ein Forum ist nur eine Spezialform. Das kann ich wiederum in XML beschreiben und deinem Java als Vorlage präsentieren. Die Vorlage für die Umsetzung relationales SQL in nicht relationales XML kann prinzipell jeder für seine Datenbank erstellen.

[Orbiter]

ja.. prinzipiell ist das die richtige Vorgehensweise, und dazu gibts wiederum einen Standard: Hibernate. Da könnte ich mich jetzt auch noch einarbeiten und uns noch ein paar Megabyte hibernate libraries ans Bein binden, aber ich finde das viel zu überorganisiert. Momentan mache ich das nach der 'alten' Methode: man generalisiert sich selbst den Datenzugang mit einem Interface, und implementiert DAOs (Database Access Objects) dazu. Das ist für dieses Feature auch so gemacht, in de.anomic.content.dao. Das ist einfach und leicht anzupassen, ohne großen Overhead. Ich würde sagen, man sollte sowas wie Hibernate verwenden wenn man so 500 Tabellen hat und das in einem größeren Rahmen wie die, die es im Kontext mit Qualitätssicherung in kommerzieller Software gibt. Hier lese ich ja mal gerade 2 Tabellen aus, da überwerfe ich mich nicht mit so viel Organisation.

[lulabad]

Wie ist das hier eigentlich mit der Recrawl Option / doppelte URLs.
Überschreibt der Import immer das was schon im Index vorhanden ist, oder werden die Wörter zu den bereits vorhandenen hinzugefügt?

[Orbiter]

auf RWI-Ebene gibts einen Doppelcheck, da sollte bei einer Re-Indexierung die doppelten raus fliegen. Wenn die Dinger aber in getrennten BLOB dumps landen erst mal nicht. Erst bei einem Merge fallen die doppelten dann auf.

Doppelte URLs gibts nicht, wenn man eine Referenz erst mal in der URL-DB hat (heisst ja jetzt 'METADATA'), dann kommt das auch nur ein mal da rein.

[Orbiter]

das ganze YaCy-Forum als Surrogat gibts jetzt hier: viewtopic.php?p=15291#p15291

[lulabad]

Kann es sein dass das

Recommendation 4. The property names for the 15 DC elements should be all lower-case. For example, use

<dc:title>Dublin Core in XML</dc:title>

rather than

<dc:Title>Dublin Core in XML</dc:Title>

was bei den Guidelines steht nicht funktioniert?
Oder hab ich schon wieder Mist gebaut?

[Orbiter]

ja, du hast Recht. Ich weiss nicht wie ich auf die Großschreibung gekommen bin, da muss ich irgendein blödes Beispiel gehabt haben, das falsch war, und von dem ich abgeschrieben habe. Na dann baue ich das um. Ich machs aber so, dass die Groß- Kleinschreibung keine Rolle spielt, von daher sollten die Beispielfiles dann auch noch gehen.

[Orbiter]

fix ist nun in SVN 5998

[lulabad]

Du hast bei deinem Forumsdump ja viele kleine xml Dateien.

Hat es einen besonderen Grund dass es viele kleine sind?
Ist es besser viele kleine zu haben als eine Grosse?
Ist die Grösse einer xml Datei begrenzt?
Was passiert mit xml dateien, die (Syntax.-) Fehler beinhalten (fehlende Tags ...)? Werden die auch nach out verschoben oder bleiben die in in?

[Orbiter]

wich hab die Dateien so klein gemacht, damit man einfacher eine dieser Dateien als Beispiel rumschicken kann. Ansonsten würde ich da eher das zehnfache oder mehr in eine Datei machen. Der Indexierer frisst die ja ohne Probleme. Die xml-Größe ist ansonsten nicht begrenzt, die werden beim Verarbeiten auch nicht erst geladen, sondern durch den Parser gestreamt.
Syntax-Fehler: kommt drauf an was der Parser daraus macht, wenn er völlig abstürzt ist der Rest futscht, ansonsten wirken sich Fehler nur pro DC-Record aus. Wenn eine Datei bearbeitet ist, mit Fehler oder ohne werden die nach out verschoben. Muss ja so sein, sonst gäbs Endlosschleiffen. Denkbar wäre aber ein verzeichnis 'err' wo dann Dateien mit Fehler rein kommen.

[apfelmaennchen]

Heute ist nicht mein Tag....

Also ich hab jetzt mal aus DMOZ den Ast Top/World/Deutsch nach Surrogates XML konvertiert.
YaCy gestartet, das XML nach DATA/SURROGATES/in kopiert und gewartet und länger gewartet und YaCy interessiert das nicht die Bohne....
YaCy neugestartet, dann wird zwar das XML nach DATA/SURROGATES/out kopiert, am Index ändert sich aber nichts.

Mach ich was falsch bzw. stimmt was mit dem XML Format nicht?

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>
<surrogates xmlns:dc="http://purl.org/dc/elements/1.1/">
<record>
   <dc:title><![CDATA[Pinguhuhn]]></dc:title>
   <dc:identifier><![CDATA[http://www.pinguhuhn.de/]]></dc:identifier>
   <dc:creator><![CDATA[dmoz]]></dc:creator>
   <dc:description><![CDATA[Bietet eine kategorisierte Sammlung von Texten zu verschiedensten Computerthemen, Registrierung erforderlich.]]></dc:description>
   <dc:subject><![CDATA[Top,World,Deutsch,Computer,Anleitungen,_Hilfen_und_FAQs]]></dc:subject>
</record>
<record>
   <dc:title><![CDATA[Online Tutorial]]></dc:title>
   <dc:identifier><![CDATA[http://www.online-tutorial.de/]]></dc:identifier>
   <dc:creator><![CDATA[dmoz]]></dc:creator>
   <dc:description><![CDATA[Online Datenbank für Tutorials, Workshops und Anleitungen. Gegliedert nach Themenbereichen.]]></dc:description>
   <dc:subject><![CDATA[Top,World,Deutsch,Computer,Anleitungen,_Hilfen_und_FAQs]]></dc:subject>
</record>
.
.
.
</surrogates>

Gruß!
apfelmaennchen

[Orbiter]

na das war ich wohl schuld, beim Fixen des lowercase-bugs oben habe ich einen insensitive collator eingeführt, und den DCEntry.poison verschoben. Dabei gab es eine merkwürdige Konstellation von static initializers, die eine NPE geworfen hat, die man aber nicht gesehen hat, aber zu einem Scheitern des Threads geführt hat, der die Surrogate parst. Fix ist in SVN 6032, hab dein xml probiert und geht auch.

[apfelmaennchen]

Vielen Dank!
Es funktioniert....

Wird eigentlich <dc.subject> auch ausgewertet?

Gruß!
apfelmaennchen

[apfelmaennchen]

Also was mir nicht gefällt ist, dass die anschließend angezeigten Snippets meist nur den Titel anzeigen. Gerade im Zusammenhang mit den DMOZ Daten würde es aber extrem viel Sinn machen, die im Surrogates gelieferte Description (menschliche Handarbeit) zu verwerten. Falls die so nicht gespeichert werden kann, wäre eine Möglichkeit den Snippet-Fetch zuerst die Bookmarks checken zu lassen, bevor das Snippet online generiert wird.

Und ich wiederhole nochmal meine Frage in Bezug auf <dc:subject> (oder jedes andere Dublin Core Tag), wird das von Surrogates mit ausgewertet?
Da hab ich nämlich die DMOZ Kategorie zerlegt als Tags reingepackt, ebenfalls eine sehr wertvolle Info zur Suche - zur Not hänge ich das aber auch an die Description mit an.

Ich teste damit ein Konzept, wie man die Bookmarks "schmerzfrei" in den Index einfließen lassen kann. Bei Bookmarksammlungen von >200.000 URLs (nichts anderes ist DMOZ) macht es nämlich Sinn, auf bestehendes zurückzugreifen und nicht das Rad neu zu erfinden.

Immerhin greifen auch die großen Google, Yahoo und AOL gelegentlich auf die DMOZ Daten - insb. die Decsriptions - zurück! Ich würde das für YaCy zumindest gerne anbieten können. Wenn das dann auch mit den YaCy-eigenen Bookmarks richtig geht, habe ich ein Beispiel, dass YaCy auch einen großen Katalog verwalten kann (und diesen in die normale Suche integrieren kann), damit erschließen wir eine weitere Zielgruppe...

Gruß!
apfelmaennchen

[Orbiter]

die dc:subjects weden (noch) nicht gelesen. Das Problem ist, das diese vergleichbar sind mit den Keywords, die man in html-meta tags einbauen kann, und die von SEOs kaputtenhanced wurden. Meiner Meinung nach sind keywords in Dokumenten Betrug, wenn die keywords nicht auch im Text selber vorkommen. Wenn die Wörter aber sowieso im Text vorkommen, dann sind sie eh im Index, d.h., wenn man sich vor Betrug schützen will muss man die keywords ignorieren und verliert dabei noch nicht mal Information, denn diese ist ja auch im Text vorhanden, und dort sogar durch die Position (Überschrift, Textstelle) in ihrer Wichtigkeit annotiert.

Somit ergibt sich ein ähnlicher Fall für die dc:subjects. Ich denke man sollte hier nur eine Ausnahme machen, wenn die keywords im Subject derart organisiert sind, dass sie gegenüber dem dc:description eine höherwertige Aussagekraft haben. Das haben sie aber nur dann, wenn man Klassifikationsmethodiken nutzt, und die subject-Keywords sich mit Hilfe der Klassifikation ausdrückt. Hierzu bräuchten wir aber noch einen Formalismus.
http://dublincore.org/documents/dces/
sagt dazu: "Recommended best practice is to use a controlled vocabulary". Da wird aber nirgendwo angegeben, wie man die controlled vocabulary spezifiziert. Aus meiner Arbeit bei der Deutschen Nationalbibliothek weiss ich, dass man die DC oft kritisiert hat weil sie in vielen Fällen so mehrdeutig ist und nicht durchgängig konsistent und konsequent ist. Das hier ist auch so ein Fall. Ich schlage vor, das wir uns eine eigene Methode der Klassifikation überlegen, und sowas wie ein Zusatztag machen, in dem wir ausdrücken wie Keywords in einer Klasse eingeordnet werden kann.

Ein Hinweis wie so eine Klassifikation ausgedrückt werden kann sieht man bei OWL (http://www.w3.org/TR/owl-ref/). Ein passendes Beispiel suche ich noch..

Fürs erste würde ich vorscghlagen, die dc:subject erst mal einfach mit einer Klassifikationsproperty auszustatten, damit hier mehr Klarheit herrscht wie die Keywords zustande kommen. Also sowas:
<dc:subject class="DDC">001</dc:subject>
würde ausdrücken dass das keyword 001 der Dewey-Klassifikation angehört.
Du kannst hier ja einfach "DMOZ" auch als Klassifikation benutzen, wenn du ein kontrolliertes Vokabular für keywords von dort bekommst.

Was dann damit im Index geschehen soll ist wieder eine ganz andere Frage. Das hier würde beispielsweise bedeuten, dass keywords nicht normale Textindexe füttern, sondern Navigatorenindexe, und dafür muss ich mir wieder was neues ausdenken.

[apfelmaennchen]

Dafür gibt es dcterms: <dc:subject xsi:type="dcterms:DDC">062</dc:subject>
Dort sind neben DDC auch andere Klassifikationen bereits definiert.
http://dublincore.org/documents/dc-xml-guidelines/

Auf selbige Art könnten wir DMOZ Kattegorien einbauen...

Gruß!
apfelmaennchen

[Orbiter]

ah, wusste ich nicht, das ist eine gute Sache.

Hab jetzt nochmal im Code nachgeschaut: keywords und tags werden aus einem plasmaParserDocument in die Metadaten zu einer URL gespeichert, aber das DCEntry-Objekt, das beim Parsen der Metadaten verwendet wird, hat das Feld nicht. Es müsste also eigentlich recht einfach sein das dc:subject - Feld nachzuziehen, ich würde dann aber alle Tags mit ihrer Klassifikation annotiert dort einstellen, d.h. es kommt dann sowas wie "DDC:062" in das subject-Feld (das dort 'tags' heisst) in der Datenbank. Dann kann man das als Navigator nutzen, so wie die autoren-Navigation an der ich gerade baue.

Wäre ein DDC:062 in den dc:subject-Feldern ok? Man könnte da dann auch mischen, sowas wie
"DDC:001,DMOZ:Computers/Open_Source/Software/Internet/Search_Engines"
wäre dann möglich

wie wäre dann der Wert für xsi:type= bei DMOZ?
<dc:subject xsi:type="dcterms: DMOZ">Computers/Open_Source/Software/Internet/Search_Engines</dc:subject> ?

[apfelmaennchen]

Einen xsi:type dcterms:DMOZ hab ich noch nicht gefunden, scheint es auch nicht zu geben
Aber wer hindert uns yterms:DMOZ als xsi:type zu definieren
http://www.w3.org/TR/xmlschema-1/#xsi_type

Immerhin kennt DMOZ auch eine Zahlenkodierung der Kategorien (catid), so dass wir nicht auf die Pfaddarstellung "Computers/Open_Source/Software/Internet/Search_Engines" angewiesen wären.

Alternativ ist die Darstellung <dc:subject xsi:type="dcterms:URI">http://www.dmoz.org/Computers/Open_Source/Software/Internet/Search_Engines/</dc:subject> eine korrekte Darstellung des Sachverhaltes.

Gruß!
apfelmaennchen

[Seitenreiter]

Naja DMOZ.org liefern ja die DB als RDF ab http://rdf.dmoz.org , könnte einer einen Harvester für das Format schreiben? Oder reicht es die Datei kontinuierlich zu crawlen?

[Seitenreiter]

http://www.gutenberg.org/wiki/Gutenberg:Feeds liefert auch RDF im Core Dublin Format, mag das mal einer testen?

Gibt es ansonsten eine Möglichkeit sowas den Crawlern bekannt zu machen z.B. in der Robots.txt? Sitemap.xml ist doch dafür nicht unbedingt gedacht oder?

[apfelmaennchen]

Naja DMOZ.org liefern ja die DB als RDF ab http://rdf.dmoz.org , könnte einer einen Harvester für das Format schreiben? Oder reicht es die Datei kontinuierlich zu crawlen?

Ich hab schon einen Direkt-Import für das DMOZ RDF in den YaCy-Index geschrieben....hab das nur noch nicht im SVN, da ich das persönlich hauptsächlich zum Testen der Bookmarks benutzt habe.

Gruß!
apfelmaennchen

[Seitenreiter]

dann fehlt noch http://www.archive.org, http://www.ibiblio.org , ....

[itgrl]

Ich versuche als Volltext gescannte Dokumente zu indexieren, dabei beisse ich mir an diesem Format die Zähne aus:
http://pds.lib.harvard.edu/pds/view/5070929?id=5070929
YaCy müsste nur den Volltext im linken Frame indexieren, das Interface liefert über den Link dann alle Informationen zurück die ich wieder für den Aufruf aller Frames brauche, oder es leitet schon beim Aufruf um. YaCy indexiert ihn aber einfach nicht, nur die nutzlosen Frames darüber. Jemand eine Idee warum? Wäre schade weil Surrogate bieten die nicht an.

[Orbiter]

ahem .. jetzt gibts einen Film über 'Surrogates' http://www.surrogates-derfilm.de/

[Quix0r]

Code: Alles auswählen

Surrogates

Die Website erfordert die neuste Version des Flash Players. Du bentigst eine neuere Version des Players, um die Seite anzusehen.Get Flash

Na, das nennt sich ja mal interessanter Film...