Algorithm-TicketClusterer
view release on metacpan or search on metacpan
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
_clustering_fieldname => $args{clustering_fieldname},
_unique_id_fieldname => $args{unique_id_fieldname},
_stop_words_file => $args{stop_words_file},
_misspelled_words_file => $args{misspelled_words_file},
_min_word_length => $args{min_word_length} || 4,
_add_synsets_to_tickets => $args{add_synsets_to_tickets} || 0,
_want_stemming => $args{want_stemming} || 0,
_how_many_retrievals => $args{how_many_retrievals} || 5,
_min_idf_threshold => $args{min_idf_threshold},
_max_num_syn_words => $args{max_num_syn_words} || 3,
_want_synset_caching => $args{want_synset_caching} || 0,
_stop_words => {},
_all_tickets => [],
_column_headers => [],
_good_columns => [],
_tickets_by_ids => {},
_processed_tkts_by_ids => {},
_stemmed_tkts_by_ids => {},
_misspelled_words => {},
_total_num_tickets => 0,
_synset_cache => {},
_vocab_hash => {},
_vocab_idf_hist => {},
_idf_t => {},
_vocab_size => undef,
_doc_vector_template => {},
_tkt_doc_vecs => {},
_tkt_doc_vecs_normed => {},
_query_ticket_id => undef,
_inverted_index => {},
_debug1 => $args{debug1} || 0, # for processing Excel
_debug2 => $args{debug2} || 0, # for modeling tickets
_debug3 => $args{debug3} || 0, # for retrieving similar tickets
_wn => WordNet::QueryData->new( verbose => 0,
noload => 1 ),
}, $class;
}
############################# Extract info from Excel #######################
sub get_tickets_from_excel {
my $self = shift;
unlink $self->{_raw_tickets_db} if -s $self->{_raw_tickets_db};
unlink $self->{_processed_tickets_db} if -s $self->{_processed_tickets_db};
unlink $self->{_synset_cache_db} if -s $self->{_synset_cache_db};
unlink $self->{_stemmed_tickets_db} if -s $self->{_stemmed_tickets_db};
unlink $self->{_inverted_index_db} if -s $self->{_inverted_index_db};
unlink $self->{_tkt_doc_vecs_db} if -s $self->{_tkt_doc_vecs_db};
unlink $self->{_tkt_doc_vecs_normed_db} if -s $self->{_tkt_doc_vecs_normed_db};
unlink glob "$self->{_tickets_vocab_db}.*";
unlink glob "$self->{_idf_db}.*";
my $filename = $self->{_excel_filename} || die("Excel file required"),
my $clustering_fieldname = $self->{_clustering_fieldname}
|| die("\nYou forgot to specify a value for the constructor parameter clustering_fieldname that points to the data to be clustered in your Excel sheet -- ");
my $unique_id_fieldname = $self->{_unique_id_fieldname}
|| die("\nYou forgot to specify a value for the constructor parameter unique_id_fieldname that is a unique integer identifier for the rows of your Excel sheet -- ");
my $workbook;
if ($filename =~ /\.xls$/) {
my $parser = Spreadsheet::ParseExcel->new();
$workbook = $parser->parse($filename);
die $parser->error() unless defined $workbook;
} elsif ($filename =~ /\.xlsx$/) {
# use Text::Iconv;
my $converter = Text::Iconv->new("utf-8", "windows-1251");
$workbook = Spreadsheet::XLSX->new($filename, $converter);
} else {
die "File suffix on the Excel file not recognized";
}
my @worksheets = $workbook->worksheets();
my $which_worksheet = $self->{_which_worksheet} ||
die "\nYou have not specified which Excel worksheet contains the tickets\n";
my ( $row_min, $row_max ) = $worksheets[$which_worksheet-1]->row_range();
my ( $col_min, $col_max ) = $worksheets[$which_worksheet-1]->col_range();
my @good_columns;
my $col_headers_row;
my $col_headers_found = 0;
my $col_index_for_unique_id;
my $col_index_for_clustering_field;
for my $row ( $row_min .. $row_max ) {
last if $col_headers_found;
@good_columns = ();
for my $col ( $col_min .. $col_max ) {
my $cell =
$worksheets[$which_worksheet-1]->get_cell( $row, $col );
next unless $cell;
my $cell_value = _get_rid_of_wide_chars($cell->value());
push @good_columns, $col if $cell_value;
if ($cell_value eq $unique_id_fieldname) {
$col_index_for_unique_id = $col;
$col_headers_row = $row;
$col_headers_found = 1;
}
if ($cell_value eq $clustering_fieldname) {
$col_index_for_clustering_field = $col;
}
}
}
$self->{_good_columns} = \@good_columns;
print "\nThe unique id is in column: $col_index_for_unique_id\n"
if $self->{_debug1};
print "The clustering field is in column: " .
"$col_index_for_clustering_field\n\n" if $self->{_debug1};
my %Column_Headers;
foreach my $field_index (0..@good_columns-1) {
my $key = "field_" . $field_index;
$Column_Headers{$key} = "";
}
my @col_headers = map {
my $cell =
$worksheets[$which_worksheet-1]->get_cell($col_headers_row, $_);
$cell ? _get_rid_of_wide_chars($cell->value()) : '';
} @good_columns;
$self->{_column_headers} = \@col_headers;
$self->_display_column_headers() if $self->{_debug1};
my $unique_id_field_index_in_good_columns =
_find_index_for_given_element( $col_index_for_unique_id, \@good_columns );
my $clustering_field_index_in_good_columns =
_find_index_for_given_element( $col_index_for_clustering_field,
\@good_columns );
die "Something is wrong with the info extracted from Excel " .
"as the index for the column with unique IDs is not one of " .
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
# Meant only for an un-nested hash:
sub _deep_copy_hash {
my $ref_in = shift;
my $ref_out = {};
foreach ( keys %{$ref_in} ) {
$ref_out->{$_} = $ref_in->{$_};
}
return $ref_out;
}
# from perl docs:
sub _fisher_yates_shuffle {
my $arr = shift;
my $i = @$arr;
while (--$i) {
my $j = int rand( $i + 1 );
@$arr[$i, $j] = @$arr[$j, $i];
}
}
sub _vec_scalar_product {
my $vec1 = shift;
my $vec2 = shift;
die "Something is wrong --- the two vectors are of unequal length"
unless @$vec1 == @$vec2;
my $product;
for my $i (0..@$vec1-1) {
$product += $vec1->[$i] * $vec2->[$i];
}
return $product;
}
sub _vec_magnitude {
my $vec = shift;
my $mag_squared = 0;
foreach my $num (@$vec) {
$mag_squared += $num ** 2;
}
return sqrt $mag_squared;
}
1;
__END__
=head1 NAME
Algorithm::TicketClusterer - A Perl module for retrieving Excel-stored past
tickets that are most similar to a new ticket. Tickets are commonly used
in software services industry and customer support businesses to record
requests for service, product complaints, user feedback, and so on.
=head1 SYNOPSIS
use Algorithm::TicketClusterer;
# Extract the tickets from the Excel spreadsheet and subject the
# textual content of the tickets to various preprocessing and doc
# modeling steps. The preprocessing steps consist of removing markup,
# dropping the words in a stop list, correcting spelling errors,
# detecting the need for antonyms, and, finally, adding word synonyms
# to the tickets in order to ground the tickets in a common
# vocabulary. The doc modeling steps consist of fitting a standard
# vector space model to the tickets.
my $clusterer = Algorithm::TicketClusterer->new(
excel_filename => $excel_filename,
clustering_fieldname => $fieldname_for_clustering,
which_worksheet => $which_worksheet,
unique_id_fieldname => $unique_id_fieldname,
raw_tickets_db => $raw_tickets_db,
processed_tickets_db => $processed_tickets_db,
stemmed_tickets_db => $stemmed_tickets_db,
inverted_index_db => $inverted_index_db,
tickets_vocab_db => $tickets_vocab_db,
idf_db => $idf_db,
tkt_doc_vecs_db => $tkt_doc_vecs_db,
tkt_doc_vecs_normed_db => $tkt_doc_vecs_normed_db,
synset_cache_db => $synset_cache_db,
stop_words_file => $stop_words_file,
misspelled_words_file => $misspelled_words_file,
add_synsets_to_tickets => 1,
want_synset_caching => 1,
max_num_syn_words => 3,
min_word_length => 4,
want_stemming => 1,
);
## Extract information from Excel spreadsheets:
$clusterer->get_tickets_from_excel();
## Apply cleanup filters and add synonyms:
$clusterer->delete_markup_from_all_tickets();
$clusterer->apply_filter_to_all_tickets();
$clusterer->expand_all_tickets_with_synonyms();
## Construct the VSM doc model for the tickets:
$clusterer->get_ticket_vocabulary_and_construct_inverted_index();
$clusterer->construct_doc_vectors_for_all_tickets();
# Of the various constructor parameters shown above, the following two
# are critical to how information is extracted from an Excel
# spreadsheet: `clustering_fieldname' and `unique_id_fieldname'. The
# first is the heading of the column that contains the textual content
# of the tickets. The second is the heading of the column that
# contains a unique integer identifier for each ticket.
# The nine database related constructor parameters (these end in the
# suffix `_db') are there in order to avoid repeated parsing of the
# spreadsheet and preprocessing of the tickets every time you need to
# make a retrieval for a new ticket. The goal here is that after the
# ticket information has been ingested from a spreadsheet, you would
# want to carry out similar-ticket retrieval in real time. (Whether
# or not real-time retrieval would be feasible in actual practice
# would also depend on what hardware you are using, obviously.)
# After the above preprocessing and doc modeling steps, you can
# extract the most similar past tickets for a new query ticket with a
# script in which the constructor call would look like:
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
processed_tickets_db => $processed_tickets_db,
stemmed_tickets_db => $stemmed_tickets_db,
inverted_index_db => $inverted_index_db,
tickets_vocab_db => $tickets_vocab_db,
idf_db => $idf_db,
tkt_doc_vecs_db => $tkt_doc_vecs_db,
tkt_doc_vecs_normed_db => $tkt_doc_vecs_normed_db,
min_idf_threshold => 1.8,
how_many_retrievals => 5,
);
my $query_tkt = 1393548;
$clusterer->restore_ticket_vectors_and_inverted_index();
my %retrieved = %{$clusterer->retrieve_similar_tickets_with_vsm($query_tkt)};
foreach my $tkt_id (sort {$retrieved{$b} <=> $retrieved{$a}} keys %retrieved) {
$clusterer->show_original_ticket_for_given_id( $tkt_id );
}
# Of all the parameters shown above in the constructor call, the
# parameter min_idf_threshold plays a large role in what tickets are
# returned by the retrieval function. The value of this parameter
# depends on the number of tickets in your Excel spreadsheet. If the
# number of tickets is in the low hundreds, this parameter is likely to
# require a value of 1.5 to 1.8. If the number of tickets is in the
# thousands, the value of this parameter is likely to be between 2 and
# 3. See the writeup on this parameter in the API description in the
# rest of this documentation.
=head1 CHANGES
Version 1.01 of the module removes the platform dependency of the functions used for
reading the text files for stop words, misspelled words, etc.
=head1 DESCRIPTION
B<Algorithm::TicketClusterer> is a I<perl5> module for retrieving
previously processed Excel-stored tickets similar to a new ticket. Routing
decisions made for the past similar tickets can be useful in expediting the
routing of a new ticket.
Tickets are commonly used in software services industry and customer
support businesses to record requests for service, product complaints,
user feedback, and so on.
With regard to the routing of a ticket, you would want each new ticket to
be handled by the tech support individual who is most qualified to address
the issue raised in the ticket. Identifying the right individual for each
new ticket in real-time is no easy task for organizations that man large
service centers and helpdesks. So if it were possible to quickly identify
the previously processed tickets that are most similar to a new ticket, one
could think of constructing semi-automated (or, perhaps, even fully
automated) ticket routers.
Identifying old tickets similar to a new ticket is made challenging by the
fact that folks who submit tickets often write them quickly and informally.
The informal style of writing means that different people may use different
colloquial terms to describe the same thing. And the quickness associated
with their submission causes the tickets to frequently contain spelling and
other errors such as conjoined words, fragmentation of long words, and so
on.
This module is an attempt at dealing with these challenges.
The problem of different people using different words to describe the same
thing is taken care of by using WordNet to add to each ticket a designated
number of synonyms for each word in the ticket. The idea is that after all
the tickets are expanded in this manner, they would become grounded in a
common vocabulary. The synonym expansion of a ticket takes place only after
the negated phrases (that is, the words preceded by 'no' or 'not') are
replaced by their antonyms.
Obviously, expanding a ticket by synonyms makes sense only after it is
corrected for spelling and other errors. What sort of errors one looks for
and corrects would, in general, depend on the application domain of the
tickets. (It is not uncommon for engineering services to use jargon words
and acronyms that look like spelling errors to those not familiar with the
services.) The module expects to see a file that is supplied through the
constructor parameter C<misspelled_words_file> that contains misspelled
words in the first column and their corrected versions in the second
column. An example of such a file is included in the C<examples>
directory. You would need to create your own version of such a file for
your application domain. Since conjuring up the misspellings that your
ticket submitters are likely to throw at you is futile, you might consider
using the following approach which I prefer to actually reading the tickets
for such errors: Turn on the debugging options in the constructor for some
initially collected spreadsheets and watch what sort of words the WordNet
is not able to supply any synonyms for. In a large majority of cases,
these would be the misspelled words.
Expanding a ticket with synonyms is made complicated by the fact that some
common words have such a large number of synonyms that they can overwhelm
the relatively small number of words in a ticket. Adding too many synonyms
in relation to the size of a ticket can not only distort the sense of the
ticket but it can also increase the computational cost of processing all
the tickets.
In order to deal with the pros and the cons of using synonyms, the present
module strikes a middle ground: You can specify how many synonyms to use
for a word (assuming that the number of synonyms supplied by WordNet is
larger than the number specified). This allows you to experiment with
retrieval precision by altering the number of synonyms used. The retained
synonyms are selected randomly from those supplied by WordNet. (A smarter
way to select synonyms would be to base them on the context. For example,
you would not want to use the synonym `programmer' for the noun `developer'
if your application domain is real-estate. However, such context-dependent
selection of synonyms would take us into the realm of ontologies that I
have chosen to stay away from in this first version of the module.)
Another issue related to the overall run-time performance of this module is
the computational cost of the calls to WordNet through its Perl interface
C<WordNet::QueryData>. This module uses what I have referred to as
I<synset caching> to make this process as efficient as possible. The
result of each WordNet lookup is cached in a database file whose name you
supply through the constructor option C<synset_cache_db>. If you are doing
a good job of catching spelling errors, the module will carry out a
decreasing number of WordNet lookups as the tickets are scanned for
expansion with synonyms. In an experiment with a spreadsheet that
contained over 1400 real tickets, the last several hundred resulted in
hardly any calls to WordNet.
As currently programmed, the synset cache is deleted and then created
afresh at every call to the function that extracts information from an
Excel spreadsheet. You would want to change this behavior of the module if
you are planning to use it in a production environment where the different
spreadsheets are likely to deal with the same application domain. To give
greater persistence to the synset cache, comment out the C<unlink
$self->{_synset_cache_db}> line in the method C<get_tickets_from_excel()>.
After a few updates of the synset cache, the module would almost never need
to make direct calls to WordNet, which would enhance the speed of the
module even further.
The textual content of the tickets, as produced by the preprocessing steps,
is used for document modeling and the doc model thus created used
subsequently for retrieving similar tickets. The doc modeling is carried
out using the Vector Space Model (VSM) in which each ticket is represented
by a vector whose size equals the size of the vocabulary used in all the
tickets and whose elements represent the word frequencies in the
ticket. After such a model is constructed, a query ticket is compared with
the other tickets on the basis of the cosine similarity distance between
the corresponding vectors.
My decision to use the simplest of the text models --- the Vector Space
Model --- was based of the work carried out by Shivani Rao at Purdue who
has demonstrated that the simpler models are more effective at retrieval
from software libraries than the more complex models. (See the paper by
Shivani Rao and Avinash Kak at the MSR'11 Conference.) Although tickets, in
general, are not the same as software libraries, I have a strong feeling
that Shivani's conclusions would extend to other domains as well. Having
said that, it is important to mention that there remains the possibility
that automated ticket routing for some applications may respond better to
more elaborate text models.
The module uses three mechanisms to speed up the retrieval of tickets
similar to a query ticket: (1) It uses the inverted index for all the words
to construct for each query ticket a candidate pool of only those tickets
in the database that have words in common with the query ticket; (2) Only
those query-ticket words are used for retrieval whose
inverse-document-frequency values exceed a user-specified threshold; and
(3) The module uses stemming to reduce the variants of the same word to a
common root in order to limit the size of the vocabulary. The stemming
used in the current module is rudimentary. However, it would be easy to
plug into the module more powerful stemmers through their Perl interfaces.
Future versions of this module may do exactly that.
=head1 THE THREE STAGES OF PROCESSING
The tickets are processed in the following three stages:
=over
=item B<Ticket Preprocessing:>
This stage involves extracting the textual content of each ticket from the
Excel spreadsheet and subjecting it to the following steps: (1) deleting
markup; (2) dropping the stop words supplied through a file whose name is
provided as a value for the constructor parameter C<stop_words_file>; (3)
correcting spelling errors through the `bad-word good-word' entries in a
file whose name is supplied as a value for the constructor parameter
C<misspelled_words_file>; (4) replacing negated words with their antonyms;
and, finally, (5) adding synonyms.
=item B<Doc Modeling:>
Doc modeling consists of creating a Vector Space Model for the tickets
after they have been processed as described above. VSM modeling involves
scanning the preprocessed tickets, stemming the words, and constructing a
vocabulary for all of the stemmed words in all the tickets. Subsequently,
the alphabetized list of the vocabulary serves as a vector template for the
tickets. Each ticket is represented by a vector whose dimensionality equals
the size of the vocabulary; each element of this vector is an integer that
is the frequency of the vocabulary word corresponding to the index of the
element. Doc modeling also involves calculating the inverse document
frequencies (IDF) values for the words and the inverted index for the
words. The IDF values are used to diminish the importance of the words
that carry little discriminatory power vis-a-vis the tickets. IDF for a
word is the logarithm of the ratio of the total number of tickets to the
number of tickets in which the word appears. Obviously, if a word were to
appear in all the tickets, its IDF value would be zero. The inverted index
entry for a word is the list of all the tickets that contain that word.
The inverted index greatly expedites the retrieval of tickets similar to a
given query ticket.
=item B<Similarity Based Retrieval:>
A query ticket is subject to the same preprocessing steps as all other
tickets. Subsequently, it is also represented by a vector in the same
manner as the other tickets. Using the stemmed words in the query ticket,
the inverted index is used to create a candidate list of ticket vectors for
matching with the query ticket vector. For this, only those query words
are chosen whose IDF values exceed a threshold. Finally, we compute the
cosine similarity distance between the query ticket vector and the ticket
vectors in the candidate list. The matching ticket vectors are returned in
the order of decreasing similarity.
=back
=begin html
<br>
=end html
=head1 METHODS
The module provides the following methods for ticket preprocessing and for the
retrieval of tickets most similar to a given ticket:
=over
=item B<new()>
A call to C<new()> constructs a new instance of the C<Algorithm::TicketClusterer>
class:
my $clusterer = Algorithm::TicketClusterer->new(
excel_filename => $excel_filename,
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
This is obviously the name of the Excel file that contains the tickets you want to
process.
=item I<how_many_retrievals:>
The integer value supplied for this parameter determines how many tickets that are
most similar to a query ticket will be returned.
=item I<idf_db:>
You store the inverse document frequencies for the vocabulary words in a database
file whose name is supplied through this constructor parameter. As mentioned
earlier, the IDF for a word is, in principle, the logarithm of the ratio of the total
number of tickets to the DF (Document Frequency) for the word. The DF of a word is
the number of tickets in which the word appears.
=item I<inverted_index_db:>
If you plan to create separate scripts for the three stages of processing described
earlier, you must store the inverted index in a database file so that it can be used
by the script whose job is to carry out similarity based ticket retrieval. The
inverted index is stored in a database file whose name is supplied through this
constructor parameter.
=item I<max_num_syn_words:>
As mentioned in B<DESCRIPTION>, some words can have a very large number of synonyms
--- much larger than the number of words that may exist in a typical ticket. If you
were to add all such synonyms to a ticket, you run the danger of altering the sense
of the ticket, besides unnecessarily increasing the size of the vocabulary. This
parameter limits the number of synonyms chosen to the value used for the parameter.
When the number of synonyms returned by WordNet is greater than the value set for
this parameter, the synonyms retained are chosen randomly from the list returned by
WordNet.
=item I<min_idf_threshold:>
First recall that IDF stands for Inverse Document Frequency. It is calculated during
the second of the three-stage processing of the tickets as described in the section
B<THE THREE STAGES OF PROCESSING TICKETS>. The IDF value of a word gives us a
measure of the discriminatory power of the word. Let's say you have a word that
occurs in only one out of 1000 tickets. Such a word is obviously highly
discriminatory and its IDF would be the logarithm (to base 10) of the ratio of 1000
to 1, which is 3. On the other hand, for a word that occurs in every one of 1000
tickets, its IDF value would be the logarithm of the ratio of 1000 to 1000, which is
0. So, for the case when you have 1000 tickets, the upper bound on IDF is 3 and the
lower bound 0. This constructor parameter controls which of the query words you will
use for constructing the initial pool of tickets that will be used for matching. The
larger the value of this threshold, the smaller the pool obviously.
=item I<min_word_length:>
This parameter sets the minimum number of characters in a word in order for it to be
included for ticket processing.
=item I<misspelled_words_file:>
As to what extent you can improve ticket retrieval precision with the addition of
synonyms depends on the degree to which you can make corrections on the fly for the
spelling errors that occur frequently in tickets. That fact makes the file you
supply through this constructor parameter very important. For the current version of
the module, this file must contain exactly two columns, with the first entry in each
row the misspelled word and the second entry the correctly spelled word. See this
file in the C<examples> directory for how to format it.
=item I<processed_tickets_db:>
As mentioned earlier in B<DESCRIPTION>, the tickets must be subject to various
preprocessing steps before they can be used for document modeling for the purpose of
retrieval. Preprocessing consists of stop words removal, spelling corrections,
antonym detection, synonym addition, etc. The tickets resulting from preprocessing
are stored in a database file whose name you supply through this constructor
parameter.
=item I<raw_tickets_db:>
The raw tickets extracted from the Excel spreadsheet are stored in a database file
whose name you supply through this constructor parameter. The idea here is that we
do not want to process an Excel spreadsheet for each new attempt at matching a query
ticket with the previously recorded tickets in the same spreadsheet. It is much
faster to load the database back into the runtime environment than to process a large
spreadsheet.
=item I<stemmed_tickets_db:>
As mentioned in the section B<THE THREE STAGES OF PROCESSING>, one of the first
things you do in the second stage of processing is to stem the words in the tickets.
Stemming is important because it reduces the size of the vocabulary. To illustrate,
stemming would reduce both the words `programming' and `programmed' to the common
root 'program'. This module uses a very simple stemmer whose rules can be found in
the utility subroutine C<_simple_stemmer()>. It would be trivial to expand on these
rules, or, for that matter, to use the Perl module C<Lingua::Stem::En> for a full
application of the Porter Stemming Algorithm. The stemmed tickets are saved in a
database file whose name is supplied through this constructor parameter.
=item I<stop_words_file:>
This constructor parameter is for naming the file that contains the stop words, these
being words you do not wish to be included in the vocabulary. The format of this
file must be as shown in the sample file C<stop_words.txt> in the C<examples>
directory.
=item I<synset_cache_db:>
As mentioned in B<DESCRIPTION>, we expand each ticket with a certain number of
synonyms for the words in the ticket for the purpose of grounding all the tickets in
a common vocabulary. This entails making calls to WordNet through its Perl interface
C<WordNet::QueryData>. Since these calls can be expensive, you can vastly improve
the runtime performance of the module by caching the results returned by WordNet.
This constructor parameter is for naming a diskfile in which the cache will be
stored.
=item I<tickets_vocab_db:>
This parameter is for naming the DBM in which the ticket vocabulary is stored after
it is subject to stemming.
=item I<tkt_doc_vecs_db:>
The database file named by this constructor parameter stores the document vector
representations for the tickets. Each document vector has the same size as the
vocabulary for all the tickets; each element of such a vector is the number of
occurrences of the corresponding word in the ticket.
=item I<tkt_doc_vecs_normed_db:>
The database file named by this parameter stores the normalized document vectors.
Normalization of a ticket vector consists of factoring out the size of the ticket by
dividing the term frequency for each word in the ticket by the number of words in the
ticket, and then multiplying the result by the IDF value for the word.
=item I<unique_id_fieldname:>
One of the columns of your Excel spreadsheet must contain a unique integer identifier
for each ticket-bearing row of the sheet. The head of this column, a string
obviously, is supplied as the value for this constructor parameter.
=item I<want_stemming:>
This boolean parameter determines whether or not the words extracted from the tickets
would be subject to stemming. As mentioned elsewhere, stemming means that related
words like `programming' and `programs' would both be reduced to the root word
`program'. Stemming is important for limiting the size of the vocabulary.
=item I<want_synset_caching:>
Turning this boolean parameter on is a highly effective way to improve the
computational speed of the module. As mentioned earlier, it is important to ground
the tickets in a common vocabulary and this module does that by adding to the tickets
a designated number of the synonyms for the words in the tickets. However, the calls
to WordNet for the synonyms through the Perl interface C<WordNet::QueryData> can be
expensive. Caching means that only one call would need to be made to WordNet for any
given word regardless of how many times the word appears in all of the tickets.
=item I<which_worksheet:>
This specifies the Excel worksheet that contains the tickets. Its value should be 1
for the first sheet, 2 for the second, and so on.
=back
=begin html
<br>
=end html
=item B<apply_filter_to_all_tickets()>
$clusterer->apply_filter_to_all_tickets()
The filtering consists of dropping words from the tickets that are in your stop-list
file, fixing spelling errors using the `bad-word good-word' pairs in your spelling
errors file, and deleting short words.
=item B<construct_doc_vectors_for_all_tickets()>
$clusterer->construct_doc_vectors_for_all_tickets()
This method is used in the doc modeling stage of the computations. As stated
earlier, doc modeling of the tickets consists of representing each ticket by a vector
whose size equals that of the vocabulary and whose elements represent the frequencies
of the corresponding words in the ticket. In addition to calculating the doc
vectors, this method also constructs a normalized version of the doc vectors. The
normalization for a ticket consists of multiplying the word frequencies in the
vectors by the IDF values associated with the words and dividing the result by the
total number of words in the ticket.
=item B<delete_markup_from_all_tickets()>
$clusterer->delete_markup_from_all_tickets()
It is not uncommon for the textual content of a ticket to contain HTML markup. This
method deletes such strings. Note that this method is not capable of deleting
complex markup that may include HTML comment blocks, may cross line boundaries, or
when the textual content includes angle brackets that denote "less than" or "greater
then". If your tickets require more sophisticated processing for the removal of
markup, you might consider using the C<HTML::Restrict> module.
=item B<display_all_doc_vectors()>
=item B<display_all_normalized_doc_vectors()>
These two methods are useful for troubleshooting if things don't look right with
regard to retrieval.
=item B<display_inverse_document_frequencies()>
$clusterer->display_inverse_document_frequencies()
As mentioned earlier, the document frequency (DF) of a word is the number of tickets
in which the word appears. The IDF of a word is the logarithm of the ratio of the
total number of tickets to the DF of the word. A call to this method displays the
IDF values for the words in the vocabulary.
=item B<display_inverted_index()>
=item B<display_inverted_index_for_given_word( $word )>
=item B<display_inverted_index_for_given_query( $ticket_id )>
The above three methods are useful for troubleshooting the issues that are related to
the generation of the inverted index. The first method shows the entire inverted
index, the second the inverted index for a single specified word, and the third for
all the words in a query ticket.
=item B<display_tickets_vocab()>
$clusterer->display_tickets_vocab()
This method displays the ticket vocabulary constructed by a call to
C<get_ticket_vocabulary_and_construct_inverted_index()>. The vocabulary display
consists of an alphabetized list of the words in all the tickets along with the
( run in 2.060 seconds using v1.01-cache-2.11-cpan-5735350b133 )