Los seguros privados

In this section we discuss some implementation details that are important to the system.

The system is deployed as shown in Figure 4.3. On the user side, the web browser will

specific data that is dependent on the KB except for the total number of instances in

the KB, and the number of instances filtered by the current context (since these two

requests can be completed in milliseconds and the results are used at multiple places in the

page). Then the javascript code will initiate a few different kinds of AJAX (Asynchronous

JavaScript and XML)3 requests to the web server. These AJAX requests will respectively

interact with some back-end JSP. Those JSP will never be directly seen by normal users,

but instead return some JSON (JavaScript Object Notation)4 objects to the frame JSP,

where some javascript code will modify the content to the page, such as rendering the

data into a tag cloud. When processing the AJAX requests, those back-end JSP do not

run any real computation tasks, but instead call functions to compiled Java classes on

the web server. Also the Java classes on the web server side only act as a data client,

who actually communicates with another server, the data server via our customized socket

protocol. The data server is in fact the part that runs all the algorithms that we discussed

in Section 4.2. We separate the data server from the web server based on the fact that our

online computation requires significant computational resources and that the web server

usually supports other services that we do not wish to be adversely affected by the Tag

Cloud Browser. Meanwhile such separation also make things easy for debug and system

maintenance. Now we shall discuss in details how the tag cloud is shown via various

requests.

For the contextual tag cloud page, after the frame is loaded, two AJAX requests will

3_{AJAX Wikipedia page: http://en.wikipedia.org/wiki/Ajax_(programming)} 4_{Introduction to JSON: http://json.org/}

Web Browser JSP JS Web Server JSP Java Data Client HTTP Request HTTP Response AJAX JSON Data Server Java Proxy Request Proxy Response

Figure 4.3: System architecture and major techniques for contextual tag cloud system.

first be issued. One will fetch the context information, which also include the change in the

number of instances if any one tag is removed from the context. The other will start the

computation of the tag cloud for the current page. Then two more repeated requests will

follow the start request. One will fetch whatever data is currently available for the current

page to display, and decide whether to repeat itself by checking from the result whether

the complete flag for the current page is set. Also the next page button is enabled after

this flag is set and a “more” flag is set. The other request following the start request will

check the status for all pages, i.e. it will check whether all the candidates have been used

to issue a fR query, and based on the progress, report information (such as the estimated

time to finish) in the result. Similarly there is a flag indicating whether all pages are

completed. If they are completed, the sort-by-frequency option will be enabled; otherwise

we will repeat this status request after a short interval (which we set as 1-3 seconds).

Meanwhile on the data server side, we simplify the context in the request and use that

as the key to interact with the cache. We implement the cache in two layers. The first layer

is the LRU (Least Recently Used) in-memory cache, i.e. when the cache is full (the number

Then the second layer, i.e. the disk based cache is used when an item is removed from

memory: we extract the list of tag-frequency pairs, which is the most time consuming part

of the results, as one array of tag ids and another array of their corresponding frequencies

and serialize these two integer arrays into a file. When a start request is received, the data

server will first check if its result is in-memory, if not then it will check if it is available

in disk. If neither exists, we will create an in-progress cache item and put it in memory

cache. A thread is then started to process this request and push any tag with non-zero

frequency to the cache. So when there is a request for a specific page of the tag cloud,

we can directly find the in-progress cache item, and compute the beginning index and

the end index in the array (since we have a fixed number of tags per page), and return

any available⟨tag, frequency⟩ pair in that range. Meanwhile we maintain a queue for the candidates (CL in Figure 4.2), the queue’s initial size, and the start time of the request,

and by using these records, we are able to estimate the percentage of the progress, time

to finish, etc. in order to answer the status request.

Theoretically we can provide the same paging feature for the search tag cloud. However

currently in our implementation we do not use cache for the search feature, which means

we do not have the streaming or paging feature on the search results. Instead, a keyword

query will only return the result page with up to 500 matched tags, after the page is

complete. We find this limit is quite enough for most queries because we sort the results

by relevance score, and usually the results become very irrelevant after 100 tags. This is

keyword search, we only consider the rdfs:label, rdfs:comment and the local names of

the classes and properties. We implement a parser for the local names to deal with the

camel case (e.g. d:SoccerPlayer has capital letters “S” and “P” for writing compound

words “Soccer Player”), which is frequently seen in them. Then we index the stemmed

words from these labels, comments or local names. Each word in the index has a posting

list of tag ids, which are the same as we use in the instance index. Thus for any search

request, we first get a list of tag ids from the keyword match, and then a candidate list

from the Co-Occurrence Matrix approach. We go through the first list and ignore any tag

that is not in the second, until we reach the end of the first list or we reach the page limit

of the search result page.