There is a lot of token information available in a web page: the tokens occurring in that web page, the URL for that web page, and so on. Here, for each web page, we tried to extract tokens accord­ing to the following schemes. Local tokens (Local) : the tokens occurring in the local sentences in a given webpage; Full tokens (Full) : the tokens occurring in a given webpage; URL tokens (URL): the tokens occurring in the URL of a given webpage. URL tokenization works as follows: split a URL at ":" and ".", and then filter out stop words that are very common in URLs, such as "com," "http," and so on; Title tokens in root page (TTRP) : the title tokens occurring in the root page of a given webpage. Here, we define the root page of a given webpage as the page whose URL is the first slash-demarcated element (non-http) of the URL of the given webpage. For example, the root page of "http://www.leeds.ac.uk/calendar/court.htm" is "www.leeds.ac.uk". We do not use all tokens in the root page because there may be a lot of noisy information.

Although Local tokens and Full tokens often provide enough information for name disambigua­tion, there are some ambiguity cases that can be solved only with the help of information beyond the given web page, such as URL tokens and TTRP tokens. For example, in the web page "Alexander Markham 009," there is not sufficient information to identify the "Alexander Markham." But from its URL tokens ("leeds ac uk calendar court") and the title tokens in its root page ("Uni­versity of Leeds"), it is easy to infer that this "Alexander Markham" is from the University of Leeds, which can totally solve the name ambigu­ity.

Because of the noisy information in URL to­kens and TTRP tokens, here we combine them with Local tokens, using the following policy: for each URL token and TTRP token, if the token is also one of the Local tokens of other web pages, add this token into the Local token list of the cur­rent webpage. We do the same thing with Full tokens.

Except URL tokens, the other three kinds of tokens—Local tokens, Full tokens and TTRP to­kens—are outputted from the Penn Treebank to-kenization, filtered by a stop-word dictionary, and represented in their morphological root form. But tokens in web pages have special characteristics and need more post-processing. In particular, a token may be an email address or a URL that may contain some useful information. For example, "charlotte@la-par.org" indicates the "Charlotte Bergeron" who works for PAR (the Public Affairs Research Council) in LA (Los Angeles). To cap­ture the fine-grained information in an email ad­dress or a URL, we do deep tokenization on these two kinds of tokens. For a URL, we do deep to-kenization as URL tokenization; for an email ad­dress, we split the email address at "@" and ".", then filter out the stop words as in URL tokeniza-tion.

So far, we have developed two token-based fea­ture vectors: a Local token feature vector and a Full token feature vector. Both of them may con­tain URL and TTRP tokens. Given feature vectors, we need to find a way to learn the similarity ma­trix. Here, we choose the standard TF-IDF method to calculate the similarity matrix.

Since considerable information related to the am­biguous object resides in the noun phrases in a web page, such as the person's job and the per­son's location, we attempt to capture this noun phrase information. The following section briefly describes how to extract and use the noun phrase information. For more detail, see Chen & Martin (2007).

Contextual base noun phrase feature: With the syntactic phrase chunker, we extract all base noun phrases (non-overlapping syntactic phrases) occurring in the local sentences, which usually include some useful information about the am­biguous object. A base noun phrase of interest serves as an element in the feature vector.

Document named-entity feature: Given the EXERT system, a direct and simple way to use the semantic information is to extract all named entities in a web page. Since a given entity can be represented by many mentions in a document, we choose a single representative mention to repre­sent each entity. The representative mention is selected according to the following ordered pref­erence list: longest NAME mention, longest NOMINAL mention. A representative mention phrase serves as an element in a feature vector.

Given a pair of feature vectors consisting of phrase-based features, we need to choose a simi­larity scheme to calculate the similarity matrix. Because of the word-space delimiter in English, the feature vector comprises phrases, so that a similarity scheme for phrase-based feature vectors is required. Chen & Martin (2007) introduced one of those similarity schemes, "two-level SoftTFIDF". First, a token-based similarity scheme, the standard SoftTFIDF (Cohen et al., 2003), is used to calculate the similarity between phrases in the pair of feature vectors; in the sec­ond phase, the standard SoftTFIDF is reformu­lated to calculate the similarity for the pair of phrased-based feature vectors.

maxvgT dist(w; v). Then the standard SoftTFIDF is computed as where TFw,S is the frequency of substrings w in S, and IDFw is the inverse of the fraction of docu­ments in the corpus that contain w. To compute the similarity for the phrase-based feature vectors, in the second step of "two-level SoftTFIDF," the substring w is a phrase and dist is the standard

SoftTFIDF.

So far, we have developed several feature mod­els and learned the corresponding similarity matrices, but clustering usually needs only one unique similarity matrix. In the results reported here, we simply combine the similarity matrices, assigning equal weight to each one.

Clustering

Although clustering is a well-studied area, a re­maining research problem is to determine the op­timal parameter settings during clustering, such as the number of clusters or the stop-threshold, a problem that is important for real tasks and that is not at all trivial. Because currently we focus only on feature development, we choose agglomerative clustering with a single linkage, and simply use a fixed stop-threshold acquired from the training data.

Performance

Our system performs very well for the Semeval Web People corpus, and Table 1 shows the performances. There are two results in Table 1: One is gotten from the evaluation of Semeval Web People Track (SemEval), and the other is evaluated with B-cubed evaluation (Bagga and Baldwin, 1998). Both scores indicate that web personal name disambiguation needs more effort.

Table 1 The performances of the test data

Conclusion

Our experiments in web personal name disam­biguation extend token-based information to a web corpus, and also include some noun phrase-based information. From our experiment, we first find that it is not easy to extract a clean text document from a webpage because of much noisy information in it. Second, some common tools need to be adapted to a web corpus, such as sen­tence segmentation and tokenization. Many NLP tools are developed for a news corpus, whereas a web corpus is noisier and often needs some spe­cific processing. Third, in this paper, we use some URL information and noun phrase information in a rather simple way; more exploration is needed in the future. Besides the rich feature extraction, we also need more work on similarity combination and clustering.