Showing posts with label search engines. Show all posts
Showing posts with label search engines. Show all posts

Monday, July 28, 2008

Google findet mehr als 1 Billion(!) Web-Adressen...

Ich hatte es ja schon immer gewusst, dass der Gogle Suchindex "ziemlich" gross ist. Die letzten "offiziellen" Zahlenangaben, die mehr oder minder indirekt gemacht wurden, besagten, dass Google im Jahr 2005 einen Datenbestand von 24 Milliarden Webseiten im Index verwaltet [1]. Aber die Zeit bleibt ja nicht stehen und das Web wächst beständig....und jetzt schreibt der "official Google Blog" am Wochenende, das der Google-Suchindex die magische Marke von 1 Billion (!) Webseiten überschritten hätte.....[2]

Natürlich muss man bei US-amerikanischen Zahlenangaben stets vorsichtig sein. "One billion" steht ja lediglich für unsere "Milliarde". "Eine Billion" dagegen sind tatsächlich 10^12 (1.000.000.000.000), im Englischen "one trillion", also eine ganze Menge. Jetzt stellen wir uns einmal vor, wir haben diese Billion Indexeinträge, die zudem noch untereinander verlinkt sind. Würde man diese Datenstruktur klassischerweise als Matrix speichern, bräuchte man 10^24 Einträge, von denen die allermeisten ja leer wären. Also speichert man eine derartige Datenstruktur doch besser auf effizientere Weise. Allerdings muss man dabei bedenken, dass der Zugriff auf Links immer noch sehr schnell erfolgen muss, da die iterative PageRank-Berechnung ja auch nicht ohne ist [3]. Ich wäre wirklich einmal daran interessiert, wie lange jetzt eigentlich eine komplette Berechnung des PageRanks für den Gesamt-Datenbestand heute dauert....

[NACHTRAG:]
Tja...man soll ja den Tag nicht vor dem Abend loben...
Der San Francisco Chronicle setzte heute einen Nachtrag zu o.a. Google Meldung, in der es hieß, dass der GoogleBot zwar mehr als 1 Billion Webseiten gefunden hätte, von diesen aber lediglich 30 - 50 Milliarden im Google-Suchindex verwaltet werden [4]. Naja, immerhin haben wir jetzt einen Anhaltspunkt, wie groß das WWW sein könnte.....und dass tatsächlich auch nicht alles bei Google gefunden werden kann.


References:
[1] TNL Blog: Google has 24 billion items index, considers MSN search nearest competitor, September 2005.
[2] The Official Google Blog: We knew the Web was Big....., Juli 25, 2008.
[3] Sergey Brin and Lawrence Page: The anatomy of a large-scale hypertextual Web search engine, Computer Networks and ISDN Systems30(1-7):107--117(1998).
[4] SFGate: New Search Enging challenges Google, July 28, 2008.

Friday, April 11, 2008

Alive and Kicking... Google 2084

Yep...after several months of abstinence, I'm back, finally.
During the last few months, a lot has happened, in science, in business, and also in private. Thus, there is a lot to talk about and a lot of forthcoming posts. Probably the most complex thing during the last months was to handle two large EU-FP7 proposals as being one of the proposal's core partners, with writing, discussing, conferencing, travelling, conferencing, discussing, and writing again, etc....
Also in my genuine research areas a lot has happened. You might be looking forward to several blog posts on information retrieval, semantic web, semantic search, multimedia retrieval, web of trust, e-Learning, and many more.

Today I just wanted to show you a funny 'screenshot' of what might Google look like in 2084.

Ok. The image is not really new. Actually it was published by Randy Siegel back in 2005. You might also find it in the New York Times. The question is not, if Google would be capable to offer these services, but rather when. Anyway, I guess theese services could be offered much earlier......and (at least) also with a much better user interface.

Tuesday, March 04, 2008

Aus Osotis wird yovisto - Web 2.0 Video Suchmaschine

Gemäß dem Motto "aus Raider wird Twix" stellt sich die Videosuchmaschine yovisto (vormals "Osotis") auf der diesjährigen CeBIT 2008 im neuen Gewand vor. Was ist neu, außer dass es einen neuen Namen und ein neues Layout gibt? Einiges!

Mittlerweile sind gut 3000 Videos akademischer Lehrveranstaltungen in deutscher und englischer Sprache in yovisto verzeichnet und durchsuchbar. Im Gegensatz zu anderen Videosuchmaschinen bietet yovisto die Möglichkeit, in den Videos selbst nach Inhalten zu suchen, d.h. wenn man z.B. nach dem Suchbegriff "Buchdruck" sucht, bekommt man nicht nur Videos als Ergebnis, die sich primär mit dem Thema Buchdruck befassen, sondern man wird punktgenau an die betreffende Szene im Video geführt, ohne lange selbst im Video danach suchen zu müssen.

Neu ist vor allem das übersichtlichere, durchdachte Layout. Insbesondere die Informationsseiten zu den Videos, die sich von den Benutzern selbst in Form eines Wikis erstellen lassen, bieten vielfach Möglichkeiten, Zusatzinformationen, Zusammenfassungen und sogar themenbezogene Werbung mit einzustellen. Am Auffälligsten aber ist die Darstellung der VIdeoinformation als 'Cover Flow', wie wir es ja schon von Apple's iPhone oder vom Leopard Betriebssystem her kennen (siehe unten)



yovisto ist auf der CeBIT 2008 in Halle 9, Stand D04 vom 4. - 9. März in Hannover und natürlich jederzeit im Netz unter www.yovisto.com zu sehen. Wer uns auf der CeBIT am Stand besucht, bekommt exklusiv einen Original yovisto-Button (limitierte Auflage) geschenkt!

P.S. Beitrag mit yovisto im Thüringen Journal (via mdr.de), vom 4.März 2008, 19 Uhr

Wednesday, August 29, 2007

Combining Social Networking and Traditional Web Search

We are already waiting quite a while for Google (or Yahoo) to incorporate social networking technology into their web search services. Personalization of search results (as already being offered -- of course in some limited way) as a very first step towards the right direction has become part of traditional web search. The next step should include not only search results from personal resources but also from resources being available within your personal social network. Seems to be straight forward...?!

First thing, include all resources that I have tagged (you can also distinguish between resources that are yours and resources owned by others that you have tagged). In addition to the traditional hyperlink graph of the web (as it is used by the PageRank algorithm), new (weighted and labelled) arcs have to be inserted connecting your homepage (site/blog or whatever) with all the resources (own and foreign) that have been tagged by you.
Ok, now let's consider that everybody's tag-links are inserted into the hyperlink webgraph. Next thing is to insert (weighted and labelled) arcs from your homepage to the homepages of all your friends (according to your personal social network).
You will end up with a graph that includes (a) traditional hyperlinks, (b) personal tagged + weigthed links to resources, and (c) personal tagged + weigthed links to other users. This composite social webgraph should be sufficient for extending the traditional PageRank algorithm to include social networking information.
Of course (and I'm pretty sure of that and I don't go into details now) a lot of adjustments concerning the weights and the use of tags/labels for indexing have to be considered. But, I think it should be possible...

To some extend, a similar approach has been implemented by lijit. lijit is a personalized search engine that makes use of all your available social networking information. At registration, besides your homepage (or blog ... unfortunately you can not manage several different blogs) you pass over your username for several bookmarking/social networking services as well as the URLs of (a) content provided by you and (b) websites (blogs) of your friends. lijit creates a searchable webgraph covering all the resources and networking information that you have provided. Therefore, searching with lijit comes close to a rather personal variant of searching your very own web-universe.

Social Graph Based Search is also the topic of a video podcast from Scobleizer. Although I can't follow his argument that the social networking companies will kick Google's butt in four years (he states that Google's PageRank algorithm cannot be adapted to include social networking information...at least not in a way scalable for Google's purposes and also not with the current business modell of today's SEOs [=Search Engine Optimizers]), I agree to the way how to include social networking information into traditional web search.

Tuesday, May 15, 2007

Next Generation Search Engines revisited...

As reader of my blog for sure you know that one of the main topics is (semantically enhanced) searching the web. Recently I was rereading Andrei Broder's short paper on 'A taxonomy of web search'[1], where he was also referring to the three generations of web search engines. His article dates back to 2002. Environment and technology in the web are rapidly changing. So, what about this three generations? Do we already need a 'next generation'? And what about the discussion about 'Search 2.0'?...
But first, let's recall the three generations according to Broder:

  • First generation: search engines are useing almost only on-page data such as text and formatting information to compute result ranking (1995-1997, cf. Alta Vista, Excite, etc...).

  • Second generation: search engines are using off-page, web-related data such as link analysis, anchor-texts, and click-through data (1998-..., cf. Google).

  • Third generation: search engines try to blend data from multiple, heterogeneous sources trying to answer 'the need behind the query'. The computed results are customized according to the user's information needs, taking into account the user's personal data background, context, and intention (now? - ...).

Clearly, search engines of the third generation include social networking information, tagging, user feedback, semantic analysis, recommendations, and trustworthyness of information (according to its source).
In read/write web the topic is also addressed as comparison of traditional search technologies with what they call 'Search 2.0' [2]. As usual, I don't like the 2.0-term. What is discussed there, refers to Broder's definition of 'Third generation' and adds nothing significant new to it (besides the marketing term). But, the article is definitely worth reading, because a lot of recent search engines are referenced and discussed (and also because of the interesting discussion that follows). They distinguish between 'Finding' information and 'Discovering' information, while relating the second term to 'Search 2.0'.

Broder distinguishes different sorts of web search queries:

  1. Navigational: intented use is to reach a particular web page (similar to 'known item' search in classical information retrieval). Therefore, navigational queries usually do have only one 'right' result.

  2. Informational:
  3. intended use is to acquire information assumed to be present on one or more web pages (as in classical information retrieval).
  4. Transactional:
  5. intended use is to find a web page, where further transactions (e.g. shopping) will take place.

If we take social bookmarking services, navigational queries can be computed simply by using the user's personomy (i.e. the set of all tags used by a distinct user). If the goal is to find a web page, which has been already accessed in the past, the page might be found quickly, if the user has registered the page within the bookmarking service (which comes to 'Finding' information). But, the query might also be resolved by using other people's tags, if somebody has tagged the page (with objectively descriptive tags).
Social bookmarking services are also usefull for the other two purposes. In addition, if the page is found, the social networking information can be utilized for 'discovering' new, previously unkown, but related (similar) information (which comes to 'Discovering' information). Hotho et al. present an adaptive ranking algorithm (FolkRank) for social bookmarking systems and discuss the problems that arise for tag-based search engines [3].

But, to answer the 'need behind the query' as Broder states in his definition of 'Third generation search engines', further personalization is mandatory. Only, if the search engine is able to find out the context of a query w.r.t. a given user and a given situation (i.e. even the same user might have different information needs in different situations), then it is possible to grasp the actual context of the query, and thus, also the 'need behind the query'...
[to be continued]

References:
[1] Andrei Broder: A taxonomy of web search, SIGIR Forum 36, pp. 3-10, 2002.
[2] Ebrahim Ezzy, Richard MacManos: Search 2.0 vs. Traditional Search, read/write web, June 20th, 2006.
[3] Andreas Hotho, Robert Jäschke, Christoph Schmitz and Gerd Stumme: Information Retrieval in Folksonomies: Search and Ranking, in Proceedings of the 3rd European Semantic Web Conference, pp. 411-426, 2006.

Tuesday, May 01, 2007

veni, vidi, emi ... according to Google


Two weeks ago, Google bought Double Click for an incredible amount of money. But for what reason, you might ask....well, to become the dominant internet advertiser. But that is too simple and too short-sighted, as pointed out last week by the German newspaper 'Die Zeit'. According to an article of Götz Hamann, everybody who is worrying about Google to become No. 1 internet advertiser is as short-sighted as this famous Gaulic chief 2000 years ago complaining about Julius Caesar having defeated the entire Gaul. But, Julius Caesar's primary ambition was not only to conquer Gaul, but to become the leader (cesar) of the Roman world empire. And the Google managers .... they also have something else in mind than just becoming the dominant internet advertiser.
They want to preveil their rules in the global advertising market....against the tv networks and also against the newspapers. In relation to the attention that the newspapers get, they receive way too much advertising. This is because of the brokers distributing advertising for the big corporations. These brokers are one of the reasons, why Google is not able to grow as fast as it possibly could. Thus, Google will continue to buy...and who knows, what company will be next....
Alas, and again we will hear: veni, vidi, emi....

(I came, I saw, and I bought..... freely adapted from H.C. aka Gaius Julius Caesar)

Friday, April 13, 2007

Tag search vs. keyword search......substitution or complement


As you know, collaborative tagging systems (CTS) have become rather popular Web 2.0 applications (although I don't like the term 'Web 2.0'...please use 'Social Web' instead). A CTS allows each registered user to maintain her own tags that add semantic annotation to corresponding web links. Today, 'tags' are simple unformatted text data. Tags are transporting meaning, i.e. semantics. Because the user is free to choose any text string (symbol) for a certain semantics (concept) related to a given resource (web page or object). To communicate this semantics, two or more users have to agree upon using the same symbols denoting an object (remember the semiotic triangle [1]).

First difficulty is syntax: there are several posibilities to write a word (of course not all of them are necessarely correct or not all of them belong to the same language). The problem becomes even worse, if one tries to combine several words in a single string (how to separate words?...use CamelCase, underscores, blanks, ...).
Next comes language dependent problems such as polysemy (homonyms or synonyms). For homonyms we have the same symbol but different meanings, and for synonyms vice versa.

Syntax and language dependent problems alone cause tag based search to be more difficult to handle than traditional keyword based approaches (by keyword based approach we refer to full text search or keywords assigned to the resource by the resource author or by some designated expert). For full text search, a query string given by the user (or at least its word stem) has to match some string being part of the searched resource. Keywords given to a resource by some designated expert should meet some level of objectivity and thus, a user might be able to 'guess' the keyword while thinking of a well suited query string. Keywords provided by the author refer to her specific point of view (same with tagging). These 'subjective' keywords are much harder to guess for the arbitrary user, because she does not necessarely share the same context with the (tag) author.
In CTS we distinguish several distinct categories of tags [2]. Among others, there are two fundamental different tag categories: descriptive tags and functional tags. Descriptive tags refer to more objective tags, tags that are used to describe a resource in some general maner. Functional tags on the other hand do include an intended functional use esp. for the tag author and thus, are more subjective. While descriptive tags serve better for general web search, functional tags are useful most for their authors, but not for other users.
To analyse the benefit of tagging for web search, we have to take into account that many users are providing tags for a specific resource. Depending on the distribution of the tags attached to a specific resource, one can observe a power law (see also [2]). Few tags are used very often, while most of all the tags attached to a resource do occur only scarcely. Those few tags rather often can be identified with descriptive tags, while the so called 'long tail' of the other tags often belong to the category of functional tags.
So, how can we make use f that fact?
In [3] the authors propose to use tags for search query refinement. For that reason, they distinguish between two defferent categores of tags (that do not necessarely correspondent with descriptive and functional tags). They distinguish search keywords as being the most popular tags assigned to a resource, which can help to increase the hit rate if being used for query refinement, and exploration keywords, which cannot. Because exploration keywords reflect the personalized search context and information need of an individual user they are supposed to be helpful for the exploration process.

Saturday, March 24, 2007

A short note on Semantic Search Engines


Lars featured an article on Hakia, a 'semantic search engine' in his blog today.
Contrarywise to Google, Hakia uses natural language processing (NLP) to 'understand' search queries given in natural language (and not as plain keywords). Ok, this is now new.
Just remember AskJeeves, a.k.a. Ask.com. But, in difference to that search engine, Hakia claims to perform a 'semantic search' (and not a keyword based search). If you read a little bit further in their technical description at Hakia labs you will find thet they are using a parser called 'OntoSem', which as they claim is able to perform a 'deep semantic analysis' of sentences. This parser is used for query string analysis and also for the generation of the search index. But, their search index is different to that we are used from 'traditional' search engines.
Just remember, traditional keyword based search engines extract so called 'descriptors' from web pages that are used to describe the content of those pages. These descriptors are managed within an inverted index. Thus, by accessing the inverted index with a descriptor (=keyword in query string), a list of web pages will be returned together with some weights indicating the relevance of the descriptor for the page.
So, how does the index work in Hakia? They clain, that their parser is analyzing all web pages to be indexed sentence by sentence. In effect, all possible questions that can be posed for each sentence are generated, forming what they call the 'QDEX data'. All possible questions for all sentences in all pages have to be stored in an index-like data structure (simply for fast and efficient access). If now a query string contains a question, this question is mapped against the index, resulting in a large number of 'relevant' (questions, sentences and in the end...) web pages. Now they apply a 'smart' algorithm called 'Semantic Rank' which orders the resulting list of documents according to their relevance wrt. the question given in the query string. More details about the technique is not published (at least not to my knowledge).

Thus, the only way to find out about the quality of their approach is to try out their search engine. A nice feature is that they have included small example applications where you may try out OntoSem or QDEX interactively by yourself. I have only tried OntoSem (because for QDEX you have to sign up a request) and the result was not really different from any standard NLP-Parser (and thus not really convincing. I will sign up and give QDEX a try..and of course I will post the result).

If I compare their approach to Google's, the problem is that Google is also claiming to incorporate semantic technology altogether. So, again I can only compare the results of my queries. I have tried several queries and have come to the following results:

  • in general the results from hakia do look very promising!

  • in comparison to Google results, they are not really that different this may come because of my 'queries' and thus, my results are probably not really objective).
    Let me give you an example: I was asking both (Google and Hakia) the question 'When did the Semantic Web start?'. Ok, it's not so easy to understand at all. First, it didn't really start (as an being implementation), but the topic itself startet several years ago...and so I was curious about the results:

Ok, as stated before, this is not representative at all, but I will keep an eye on Hakia anyway. As soon as I have more representative experiences (and hopefully some comments or other interesting comparisons), I will write about.

One thing in the end. After all, what I have read about Hakia and on their web site, they seem to have a completely different notion of 'Semantic Search'. What they do is to apply (enhanced) information retrieval techniques based on natural language processing. They do NOT evaluate any additional given semantic annotation (RDF, OWL, etc...), which might be addid into the web pages or connected to them. They claim (same as Peter Norwig) that the average user is much too stupid to supply semantic annotation (because for doing that he needs to be a linguist as they say).
Of course, if you are following the PLAIN trail of the W3C and encode everything by hand (HTML, XML, RDF, OWL, SWRL, etc...) then you have to be some real expert. But today, you (at least most of you) don't encode HTML by your own. Remember, there are lots of real nice WYSIWYG editors for doing that AND (even more) there are several simplifications (just think of writing your blog). In the same way there will be smart user interfaces and editors providing help in generating semantic annotations for your texts. First and most simple step is providing labels and keywords (just 'tags') for your blog posts. Most people do that...just because (1) they want to put some order into the set of their postings and (2) they want their posting to be found.

Thursday, March 15, 2007

OSOTIS ...winning an iPod...and the CeBIT rumble starts again


I have already talked about the video search engine OSOTIS, but it has again improved over the time. First at all, what does 'OSOTIS' mean? No, it's not some sort of ancient egyptian god. It's just derived from the botanical name for 'forget-me-not', which is greek 'Myosotis'. So, the name already gives some hint for the offered service:
(1) OSOTIS offers search within videos
(2) right now, most videos available at OSOTIS are academic lecture recordings, ranging from short viseo sequences from the famous Solvay conference in 1927 (where Einstein replied to Bohr that God does not throw dice...) up to lectures from Berkeley, MIT, Stanford, Oxford, or also my lectures at the Friedrich-Schiller-University in Jena (Germany).
(3) OSOTIS does not host the videos (as youTube or Google does). They only provide links to your resources. Nevertheless, OSOTIS downloads the offered video stream for post processing and for generating timed annotations for the video serch.
(4) You can register at OSOTIS (btw if you register before April 15th you have the chance to win an iPod 30GB) and maintain your own video collections, maintain an own user profile, make friends, choose your favourite videos, and (!) you can tag videos.
(5) You can even tag inside video streams. This means that the tagging information also includes time information and that the search is able to replay the video exactly from the right position.
(6) OSOTIS is a social networking tool.
And OSOTIS is at the CeBIT computer fair that has just opened its gates. Visit us at hall 9, D04!
Yes...and tomorrow I will be at CeBIT in Hannover for the next three days. So just stay tuned, because I will write about everything interesting that comes into my way.

Monday, February 19, 2007

LEARNTEC, Karlsruhe February 13-15


This year, we participated at the LEARNTEC Fair in Karlsruhe (February 13-15). LEARNTEC is focussed of e-learning technology integrating universities and industries together within an exhibition and a congress. As officially being the advisor of an ESF/BMBF funded startup company called OSOTIS, I was visiting my students who took part at this exhibition. OSOTIS is also the name of the 'Academic Video Search Engine' that serves as a testbed for our research in semantic web and multimedia search technology.

The setting of OSOTIS is the following: We are dealing with lecture recordings and offer a search service over and also inside those lecture recordings. The main advantage of OSOTIS is that most of the video post processing that is necssary for implementing a search is done in a completely automated way. Many other video search systems depend on cost intensive post processing, such as segmenting the videos into short 'learning objects', manually annotating the video segments, etc.
OSOTIS is different:
It makes use of additional information resources such as desktop presentation (e.g. powerpoint or pdf slides or simply desktop recordings) that can be synchronized with the video recording in different ways. If there is only a lecture video without any additional information source, even speech recognition technology is able to provide keywords that can be used for the video annotation. In this way, the video can be automatically segmented and the segmants can be annotated with keyword descriptors. Additionally, if there is no way to determine the content of the video, OSOTIS offers manual annotation and social tagging services to all registered users. Thus, there is always some way to search inside each lecture recording, no matter if additional information resources are available or not.
You just enter a keyword and OSOTIS will display a list of lecture recordings that are related to that keyword. By selecting one of the results, the video will start at exactly that point in time that is directly related to the user query. OSOTIS does not host the video resources on its own server, but offers only links to the original streaming servers (for streaming resources) or origin servers with podcast/videocast recordings. Thus, also all kind of video formats can be maintained, as e.g., real media, mpeg, mp4, flash video, and others.
Up to now, the main part of hosted video lectures is in given in German (and thus being hosted by german speaking universities, as also Austria or Switzerland). But, the number of lecture recordings in English will be increased soon.

Tuesday, January 23, 2007

SOFSEM 2007 - Day 3

Today started with a keynote given by Ricardo Baeza-Yates from Yahoo! Research on 'Mining Web Queries'. In particular he showed how to identify categories of user queries and how to use this information to create an appropriate ranking of the search results. Besides the already identified 'coarse' categories, such as, e.g., queries being 'informational', 'navigational', or 'transactional' (which means that the user wants to have (a) information about a specified topic, (b) a starting point for further research, or (c) a homepage related to the resource for transactional purposes (e.g. shopping)...), he addressed several graphs that can be compiled out of the search engine logfile, as e. g., URL cover graph, URL link graph, session graph...These graphs can be used for identifying polysemic expressions, similar or related queries, clusterings of queries, or even a (pseudo)taxonomy of queries.
Besides web query mining, he mentioned some interesting numbers concerning Yahoo, as e.g. that Yahoo administrates about 20 PetaBytes of Data with more than 10 TeraBytes of data traffic per day. But, on the other hand, he gave an estimation of the actual world knowledge and related it to the ammount of data managed by Yahoo today: given that a person creates about 10 pages of data concerning a distinct event, and if we estimate the number of events of about 5000 in a lifetime, and if we multiply that number by the world's population....we will end up with about 0,0057% of the 'world knowledge' currently being represented in Yahoo...

Thursday, December 21, 2006

Semantic Search ... confusion ahead


When I was attending a talk of Thilo Götz on UIMA, the word came to 'Semantic Search'. Up to that point in time, I was quite sure about the meaning of this term. But, I had to realize that several people think in different ways about it.
As far as I have understood the meaning of that term, 'Semantic Search' refers to all techniques and activities that deploy semantic web technology on any stage of the search process. Thilo Götz (and he's not alone with that) refered to 'Semantic Search' as a 'traditional' search engine that is using a semantically enriched search index (i.e. a search index that incorporates ontologies or information/relationships infered from ontologies).

From my point of view the later definition refers only to a part of the whole process. Let's take a brief look at search engine technology: You have to consider the index generation (including the crawling processes, information retrieval for creating descriptors, inverse indexing, overall ranking, clustering, ...) as well as the user interaction (including query string evaluation, query string refinement, visualization of search results, navigation inside the search domain), not to forget personalization (concerning a personalized ranking of the search results including some kind of 'pre-selection' according to the personal information needs of the user, a personalized visualization, etc.) -- which will become of much more importance in the nearby future.

But, to generate a semantic search index there are several possibilities to consider:

  • Using unstructured web-data (html, etc. ...) in combination with information retrieval techniques to map the information represented in the web-data to (commonly agreed) ontologies of well defined semantic.

  • Using semi-structured web-data that already include links to well defined ontologies (being commonly agreed upon or at least being mapped to som standard ontologies).


For both steps, the generation of a semantic index requires more than just compilation of the retrieved data. Although the index might contain unstructured web-data including ontologies of well defined semantics, the main purpose of the index is to provide fast access to the information being represented in it. To generate the answer for a query, the search engine simply does not have enough time for performing logical inferences to deduce knowledge (a.k.a. answers) online. Of course, this (logical inference) has to be deployed beforehand (i.e. offline), just in a similar way as the computation of today's pageRank.

So, what is the use of machine processible semantics in a search engine's index data structure? The following possibilities can be considered (the list is open for additional suggestions...):

  • to add new cross-references between single index entries (associations),

  • to find similarities between index entries ( = web data) w.r.t. their content, and

  • to discover dependencies between single index entries to enable
    • better visualization of the retrieved domain of information, and also

    • efficient navigation to better fulfill the users information needs.


  • of course also to disambiguate and to cluster web-data for better precision and recall (this is already done with current IR techniques).


To compile a semantic index, also the crawling process has to be considered. While the primary goal of a web crawler is to gather as much web-data as possible as fast as possible (and of course to maintain its level of consistency), a 'semantic' web crawler besides unstructured web-data also has to look for semantic data, as e.g., RDF and OWL files, and also for possible connections between unstructured web-data and semantic data. For crawling RDF or OWL, a traditional crawler has to be modified. While the traditional crawler just analyzes the HTML data for link tags, RDF and OWL don't contain link tags but they often include several namespaces that determine new input for the crawler. Besides mere data gathering, the crawler should also preprocess data for being included within the index. This task often is implemented as a separate step (and denoted as 'information retrieval'). But, it influences the crawlers direction and crawling strategy and thus, also has to be considered here.
Web crawlers often are implemented in a distributed way to increase their efficiency while working in parallel. New URLs found in the web pages being crawled can be arranged according to the location of their domain (geographically). In this way, an instance of the distributed crawler receives only new URLs to be crawled that are located in the same (or a nearby) domain. The same argument holds for the resources that are to be crawled by semantic web crawlers. But, for semantic crawlers, also the (semantic) domain of the crawled data might be of importance, e.g., an instance of the distributed crawler might be responsible for crawling a specific domain (=topic) or only domains that are (semantically) closely related to the domain of interest.


For the semantic search engine the compilation of an index from the web pages being delivered by the crawler differs from the compilation process of the traditional search engine. Let us first recall the traditional index compilation process (for text related data, i.e. this does not hold for multimedia data such as images or video clips):

  1. resource normalization, i.e. all resources that contain explicit textual content have to be transformed into text files

  2. word stemming, i.e. transform all terms of a retrieved and normalized web-document to their word stems

  3. stop word removal, i.e. cut out all terms that are not well suited for identifying the processed text file (i.e. that are not suitable as descriptors). Often only nouns are taken as descriptors (this can partly be achieved by applying pos-stemmers (=part-of-speech stemmers).

  4. black list processing, i.e. terms that for some reason do not qualify as descriptors are cut out.


This process results in a list of descriptors that describe the web-document being processed. For each descriptor a weight according to its descriptive value for the text file has to be calculated (e.g., by term frequency - inverse document frequency (tf-idf) or other weigth function). The table resulting from combining the weighted descriptors with their underlying web-documents constitutes the index. By inverting this index a descriptor delivers all related web-documents in combination with their pre-calculated weight function (that determines how well a given descriptor is suited to describe the content of the according web-document). To increase precision and recall, the general relevance of the web-documents can be computed beforehand (i.e. nothing else but the Google PageRank).

For a 'semantic index', metadata (such as, e.g., ontologies) have to be taken into account and be combined with the traditional index...

...to be continued

Tuesday, November 21, 2006

Document Retrieval vs. Fact Retrieval - In Search for a Qualified User Interface


Today, if you are looking for information in the Web, you enter a set of keywords (query string) into a search engine and in return you will receive a list (= ordered set) of documents that are supposed to contain those keyword(s) (or their word stem). This list of documents (therefore 'document retrieval') is ordered according to the document's relevance with respect to the user's query string. 'Relevance' - at least for Google - refers to PageRank. To make it short, PageRank reflects the number of links referring to the document under consideration, each link weighted with its own relevance being adjusted by the number of total links starting at the document that contains this link (in addition with some black magic that is still under copyright restriction, see U.S. Patent 6285999).
But, is this list really what the user expects for an answer? O.k. meanwhile, we - the users - have become used to this kind of search engine interface. In fact, there exist books and courses about how to use search engines in order to get the information you want. Interesting fact is that it is the user, who has to get adapted to the search engine interface....and not vice versa.
Instead it should be the other way around. The search engine interface should get adapted to the user - and even better to each different user! But, how then should a search engine interface should look like? In fact, there are already search engines that are able to give the answer to simple questions ('What is the capital of Italy?'). But, they stil fail in answering more complex questions ('What was the reason for Galileo's house arrest?').

In real life - at least if you happen to have one - if you are in need for information, you have different possibilities to get it:

  1. If there is somebody you can ask, then ask.
  2. If there is nobody to ask, then look it up (e.g. in a book).
  3. If there is nobody to ask, and if there is no way to look it up, then think!

Let's consider the first two possibilities. Both do also have their drawbacks: Asking somebody is only helpful, if the person being asked does know the answer. (O.k., there is also the social aspect that you might get another reward just by making social contact...instead of getting the answer). If the person does not know the answer, maybe she/he knows, whom to ask or where to look it up. But we might consider this fact as being a kind of referential answer. On the other hand, even if the person does know the answer, she/he might not be able to communicate the answer. Maybe you speak different languages (not necessarely different languages in the sense of 'English' and 'Suaheli', but also consider a philosopher answering the question of an engineer...). Sometimes you have to read in between the lines to understand somebody's answer. At least, in some sense we have to 'adapt' to the way the other person is giving the answer to understand the answer.
Considering the other possibility of looking up the information, we have the same situation as if asking the www search engine. E.g., if we look up an article in an encyclopedia, we use our knowledge of how to access the encyclopedia (alphabetical order of entries, reading the article, considering links to other articles...being able to read...).
Have you realized that in both cases we have to adapt ourselves to an interface. Even when asking sombody, we have to adopt to way this person is talking to us (her/his level of expertise, background, context, language, etc.). From this point of view, adapting to the search engine interface of Google seems not to be such a bad thing at all....

If it comes to fact retrieval, the first thing to do is to understand the user's query. To understand an ordinary query (and not only a list of interconnected query keywords), natural language processing is the key (or even as they say the 'holy grail'). But even, if the query phrase can be parsed correctly, we have to consider (a) context and (b) the user's background knowledge. While the context helps to disambiguate and to find the correct meaning of the user's query, the user's background determines its level of expertise and the level of detail in which the answer is best suited for the user.

Thus, I propose that there is no such thing as 'the perfect user interface'. Anyway, different kind of interfaces might serve for different users in different situations. No matter how the interface will look like, we - the users - will adapt (because we are used to do that and we learn very quickly). Of course, if the search engine is able to identify the circumstances of the user (maybe she/he's retrieving information orally with a cell phone or the user is sitting in front of a keyboard with a huge display) the search engine may choose (according to the user's infrastructure) the suitable interface for entering the query as well as for presenting the answer...

WebMonday 2 in Jena - Aftermath


Yesterday evening the 2nd WebModay took place in Jena Intershop Tower. I thought that the number of participants that happend to come by the last time could not be surpassed (we had almost 50 people up there), but belief it or not, I counted more than 70 people this time! Lars Zapf moderated the event and we had 4 interesting speakers this evening.
For me, the most interesting talk was the presentation of Prof. Benno Stein from the Bauhaus-University Weimar about Information Retrieval and current projects. He was addressing the way how we are using the web today for retrieving information. Most current search engines are only offering 'document retrieval', i.e. after evaluating the keywords given in the user's query string the search engine presents an ordered list of documents that the user has to read in order to get the information. Instead, the more 'common' way to get information would be to ask a question and to receive an 'real' answer (= fact retrieval). I will discuss these different types of 'user interfaces' in an upcoming post. Interesting thing to mention is that Weimar is so close to Jena and both our research really seems to have some interconnections (thus, this new contact might be considered to be another WebMonday's networking success).
After that, Matthias Leonhard was giving the first part of a series of talks related to Microsoft's .NET 3.0.
Then, Ryan Orrock addressed the problem of 'localisation' and translation of applications. If translating an application into another language, simple translation of all text parts is not sufficient. There are also different units of measure to consider as well as the adaption of screen design, if texts in different languages have diferent sizes.
In the last presentation Karsten Schmidt was addressing networking with openBC/Xing, an interesting social networking tool that is supposed to make business contacts.(At least, now I know that I need some other tool to store (physicaly) my (and other people's) business cards :) ).
Even more interesting was - as always - the socializing part after the presentations. Markus Kämmerer made some photos .

Here you can find other blog articles on the 2nd WebMonday: