Search (5 results, page 1 of 1)

0.015326426 = product of:
  0.030652853 = sum of:
    0.030652853 = product of:
      0.061305705 = sum of:
        0.061305705 = weight(_text_:web in 4657) [ClassicSimilarity], result of:
          0.061305705 = score(doc=4657,freq=2.0), product of:
            0.17002425 = queryWeight, product of:
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.052098576 = queryNorm
            0.36057037 = fieldWeight in 4657, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.078125 = fieldNorm(doc=4657)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.007663213 = product of:
  0.015326426 = sum of:
    0.015326426 = product of:
      0.030652853 = sum of:
        0.030652853 = weight(_text_:web in 4885) [ClassicSimilarity], result of:
          0.030652853 = score(doc=4885,freq=8.0), product of:
            0.17002425 = queryWeight, product of:
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.052098576 = queryNorm
            0.18028519 = fieldWeight in 4885, product of:
              2.828427 = tf(freq=8.0), with freq of:
                8.0 = termFreq=8.0
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.01953125 = fieldNorm(doc=4885)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Content

"Stellen Sie sich vor, ein Fremder bittet Sie in seiner Sprache um Hilfe. Sie verstehen: "Drink" und "Bier". Wenn Sie in München leben, schicken Sie den Mann auf dem schnellsten Weg ins Hofbräuhaus. Google würde ebenso handeln: Die meisten Suchenden, die "Drink Bier" von sich geben, suchen das Hofbräuhaus (Popularitätsprinzip). Aber vielleicht wollte er wissen, wo er eine Flasche Bier kaufen kann oder ob Sie ein Bier mit ihm trinken möchten? Sie haben ihn Schlichtweg nichtverstanden. So geht es den Suchmaschinen auch. Umso erstaunlicher ist es, wie präzise deren Antworten oft sind. Wenn man aber etwas sucht, was nicht dem Popularitätsprinzip entspricht, was also vom Suchen der Vielen abweicht, so steht man vor Zehntausenden von Treffern. Besser wäre es, wenn die Suchmaschine versteht, was man sucht. Wenn sie etwas von der Bedeutung der Sucheingabe und der Bedeutung der Webseiten wüsste. Aber die steht in den Seiten nicht drin. Eine komplette Bedeutungshierarchie müsste dem jetzigen Web hinzugefügt werden. Im Kleinen gibt es Ansätze dazu unter dem Namen Semantic Web (www w3. org/2001/sw; in der Sprachwissenschaft beschäftigt sich die Semantik mit der Bedeutung). Der Autor fügt HTML-Dokumenten die Bedeutung in Form von XML-Metatags zu. Ein Beispiel für RDF ist RDF Site Summary (RSS). Eine RSS-Webseite (z.B. www.pc-magazin .de) bietet Nachrichten. Im Gegensatz zu einer normalen Nachrichtenseite sind über XML-Tags Bedeutungen zugefügt. <title> bedeutet: Hier folgt eine Überschrift, <description>: Hier folgt die Inhaltsangabe. Ein RSS Reader (z.B. Thunderbird) kann nun ganz klar erkennen, was eine Überschrift ist, und muss sie nicht über Standardelemente (<b>, <h1>) erraten. Eine andere semantische Anwendung könnte ein Musiker-Netz sein mit Bedeutungs-Tags für Instrumente, Konzerte, Terminen, Downloads etc. Hier könnte man mit entsprechenden Programmen (Browser-Extensions) sehr viel präziser suchen. Eine Besonderheit ist, das RSS auch über Hyperlinks arbeitet. Metainformationen müssen sich nicht auf der Seite selbst finden, sondern eine andere Seite kann sie aufführen. So erschließt sich eine Interessensgruppe fremde Ressourcen und bringt sie in einen eigenen Bedeutungszusammenhang, der vom Autor einer Seite vielleicht nicht gesehen oder nicht einmal gewollt wurde.
Mehr Intelligenz Semantik bedeutet bislang Handarbeit. Das ist lästig und kostspielig. Der Computer soll die Bedeutung bitte selbst verstehen! Im Forschungsbereich der Künstlichen Intelligenz (KI) arbeiten Wissenschaftler auch an derVerbesserung der Suche. Die Forscher vom Fraunhofer Institut für Integrierte Publikations- und Informationssysteme unter der Leitung von Prof. Thomas Hofmann haben ein Verfahren vorgestellt, das Konzepte von Texten extrahiert. "Konzepte bilden eine Brücke zwischen der Ausdrucksweise in einem Dokument und der in der Anfrage", erläutert Hofmann seinen Ansatz. So findet der Suchende alle relevanten Dokumente, selbst wenn die Suchbegriffe nicht direkt vorkommen. Das funktioniert derzeit nur in einem thematisch begrenzten Raum, z.B. einem Webauftritt über Medizin, Handel, Hardware... Bevor die Suchmaschine die Dokumente indiziert, errechnet sie die Konzepte aus einer begrenzten Sammlung an Dokumenten. Diese hat der Betreuer des Systems so ausgewählt, dass sie für das Themengebiet und den Webauftritt charakteristisch sind. Mit Methoden der Statistik und Wahrscheinlichkeitsrechnung (Probabilistic Latent Semantic Analysis; kurz pLSA) extrahiert der Roboter einige hundert bis tausend Konzepte. Die bestehen aus Begriffen und deren Art, gemeinsam in Dokumenten aufzutreten (Häufigkeit, Ort, Beziehung etc.) Für das Beispiel Handel gibt es etwa ein Konzept für Import oder eines für Buchhaltung. Stehen die Konzepte fest, erstellt die Suchmaschine den Index, indem sie alle Dokumente der Domäne den Konzepten zuordnet. Wenn der Anwender nun sucht, so versucht die Suchmaschine, die Anfrage ebenfalls Konzepten zuzuordnen, und wählt dementsprechend die Ergebnisse aus. Hoffmanns System ist auf der Webseite www.medlineplus.com im Einsatz. Gibt der Anwender z.B. +bird +flu ein, so sucht die Suchmaschine genau die Worte - ohne +, jedoch mit Konzept. Die Frage, ob eine konzeptbasierte Suchmaschine für das ganze Web möglich ist, bezweifelt Hofmann derzeit: "Das ist eine Frage der Skalierbarkeit. Die statistische Analyse ist nicht ganz trivial und braucht eine entsprechende Rechenleistung. Auf lange Sicht wird das aber kommen.
Im Web müsste die KI-Suchmaschine Hunderttausende von Konzepten bewältigen. Das ist kostspielig. Eine intelligente Suche wäre pro Anfrage vielleicht zehnmal teuerer als eine jetzige, bei vielen Millionen täglichen Anfragen ist das ein erheblicher Kostenfaktor. Dennoch laufen bei Google Entwicklungen in diese Richtung. Der Marktführer muss Technologieführer bleiben, um zu überleben. Mehr Sprache Die KI arbeitet daran, die Sprache immer besser zu verstehen, bis hin zur Möglichkeit, Fakten ausSätzen zu extrahieren. Das erfordert eine genaue gramma tikalische und semantische Analyse. Auch da haben sichstatistische Verfahren durchgesetzt, die eine große Menge an Sätzen auswerten. Das öffnet auch Wege zum automatischen Übersetzen von Sprachen, was wieder für die Suche relevant ist. An die Grenzen kommt die KI dann, wenn sie Fakten aus mehreren Dokumenten zusammensetzen soll- also Bedeutung im synthetischen Schluss aus verschiedenen Quellen extrahieren. Ebenso wenig kann die KI etwas über die Glaubwürdigkeit einer Quelle sagen. Das schaffen wir als Menschen ja oft kaum. Es gibt auch Methoden, mit denen Suchmaschinen den Suchenden besser verstehen. Sucht er z.B. nach Flügel, so weiß das Tool erst einmal nicht, ob ein Instrument, ein Gebäude, ein Vogel oder ein Flugzeug gemeint ist. Das könnte die Suchmaschine aber vermuten, wenn sie den Anwender besser kennt: Ist er Musiker oder Flugzeugkonstrukteur? Mit KI könnte sie das lernen, z.B. aus seinen bisherigen Suchanfragen (Orchester oder Triebwerke?). Sie könnte auch die Festplatte des Anwenders durchsuchen, um anhand der Dokumente festzustellen, womit der Suchende sich beschäftigt und was ihn interessiert. Das interessiert aber auch das Finanzamt und Adresshändler. Viele Anwender werden Probleme mit der Vertraulichkeit ihrer Daten sehen. Bei einer Internet-Suchmaschine müssten die Informationen als Profile auf dem Server liegen. Wer will das schon?"

0.004411649 = product of:
  0.008823298 = sum of:
    0.008823298 = product of:
      0.017646596 = sum of:
        0.017646596 = weight(_text_:22 in 3221) [ClassicSimilarity], result of:
          0.017646596 = score(doc=3221,freq=2.0), product of:
            0.18244034 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.052098576 = queryNorm
            0.09672529 = fieldWeight in 3221, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.01953125 = fieldNorm(doc=3221)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

22. 1.2005 17:11:04

0.0038316066 = product of:
  0.007663213 = sum of:
    0.007663213 = product of:
      0.015326426 = sum of:
        0.015326426 = weight(_text_:web in 4730) [ClassicSimilarity], result of:
          0.015326426 = score(doc=4730,freq=2.0), product of:
            0.17002425 = queryWeight, product of:
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.052098576 = queryNorm
            0.09014259 = fieldWeight in 4730, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.01953125 = fieldNorm(doc=4730)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Content

Komplett vermisst in allen Tools haben wir die Unterstützung von Access. Ein Sprecher von X1 beteuerte, das Tool verstehe Access bis zur Version 2. Das haben wir nicht nachgeprüft (nur Access 2003). Oft stellten wir Probleme mit Umlauten fest. Blinkx verzichtet komplett auf alles, was nicht Englisch ist. Früher gab es eine deutsche Version, und eine Sprecherin versicherte, es soll bald eine internationale folgen, die auch Deutsch beherrscht. Die vorliegende 3.5 ist hierzulande jedenfalls nicht zu verwenden. Copernic versteht keine Umlaute in HTML-Seiten, da diese als &xyz; vorliegen: K&uuml; statt Küche. Auch hier soll die nächste Version Abhilfe schaffen. In unserem letzten Test hatte Google ähnliche Probleme, das ist aber nicht mehr der Fall. Dafür filtert es HTML-Tags nicht richtig: z.B. Fe<b>tt<lb> findet es nicht als Fett sondern F ett. Der Anwender sollte sich genau klar machen und prüfen, in welchen Formaten seine Daten vorliegen. Das Suchtool sollte alle unterstützen. In den Index Nach der Installation stellt derAnwenderbei den meisten Tools ein, welche Ordner und Mail-Programme es in den Index einbeziehen soll. Dann beginnt der Indexer mit derArbeit, was je nach Größe einige Stunden dauern kann. Der fertige Index ist sozusagen eine Karte der Daten. Erenthält alle suchbaren Begriffe und den zugehörigen Dateinamen, wie ein Register der Festplatte. In diesem findet sich ein Suchbegriff viel schneller, als wenn das Tool jede Datei öffnen müsste. Google macht es sich besonders einfach: Es bricht die Indizierung bei etwa lOOk ab. Das konnten wir bei mehreren Dateiformaten (RTF, DOC, HTML) feststellen. Die erste Hälfte ist suchbar, die zweite nicht. Dieses Verhalten macht im Web sicher Sinn, den die ersten Seiten eines Dokuments geben Aufschluss über den Inhalt, nach dem der Anwender später sucht. Auf seinem Desktop sucht der An wender oft aber anders. Er hat eine ganz bestimmte Info, deren Ort erfin den möchte. Dazu müssen die Dokumente im Indexvollständig abgebildet sein. Google gab keine Stellungnahme dazu ab.

0.0038316066 = product of:
  0.007663213 = sum of:
    0.007663213 = product of:
      0.015326426 = sum of:
        0.015326426 = weight(_text_:web in 1797) [ClassicSimilarity], result of:
          0.015326426 = score(doc=1797,freq=2.0), product of:
            0.17002425 = queryWeight, product of:
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.052098576 = queryNorm
            0.09014259 = fieldWeight in 1797, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.2635105 = idf(docFreq=4597, maxDocs=44218)
              0.01953125 = fieldNorm(doc=1797)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Content

Der Autorenkasten zeigt die Berufsbezeichnung der Autorin, weitere Artikel von ihr, zum Thema passende Artikel und eben die Google-Werbung. Außerdem hat sich die Autorin dafür entschieden, den Artikel unter die Creative-Commons-Lizenz (CCL) zu stellen, so dass andere Autoren das Material unter bestimmten Einschränkungen, zum Beispiel die Nennung des Urhebers, weiter verwenden können. Ein Knot-Artikel könnte so auch bei Wikipedia landen. Ob die CCL eine Google-Vorgabe für alle Texte im Lexikon wird, ist noch nicht bekannt. Die Suche Die Wiki-Konkurrenz zu Google heißt Wikia-Search. Der Namensbestandteil Wikia verrät den Urheber des Projekts, denn es handelt sich nicht um die gemeinnützige WikimediaFoundation, die Betreiberin von Wikipedia, sondern um Wikia Inc., ein gewinnorientiertes Unternehmen des Wiki-Gründers Jimmy Wales. Die Anwender, die die Suchergebnisse von Wikia-Search verbessern, arbeiten also auch unbezahlt am Gewinn des Firmengründers mit. Seit YouTube ein weit verbreitetes Web-2.0-Phänomen. Die Wikia-Suche soll sich in erster Linie durch Offenheit zu Google unterscheiden. Das heißt, der Such- und Ranking-Algorithmus ist Open Source. Jeder kann wissen, warum seine Seite an welcher Position landet. Außerdem soll es Programmierschnittstellen (APIs) geben. Das ist nicht nur für die ehrlichen Webmaster gut, sondern auch für Spammer, denen Wikia die Manipulation erleichtert. Wie der Betreiber dagegen vorgehen will, dazu gibt es noch keine Aussagen. Eine gewisse Kontrolle werden die Anwender ausüben, die die Ergebnisse bewerten können. So wandert Spam schnell nach unten und die guten Resultate nach oben.