an overall architecture diagram of the job search system 100 in accordance with an embodiment of this disclosure is shown in fig1 . the system 100 can be thought of as having three sections : an external input section 101 , a data handling section 103 , and an output handling section 105 . basically the data handling section reaches to the external input section 101 for job data , processes the data , organizes and verifies validity of the data , categorizes the job data , and provides the data to the output section which may be accessed eventually by a job seeker 107 via the internet 110 . the external input section 101 includes the job postings that may be accessed by the data handling section from such sources as corporate and company career sites and a number of other job boards 102 . these corporate career sites and job boards 102 currently consist of several thousand company career sites . also providing input to the data handling section 103 are systems operations personnel 104 , listing reviewers 106 and categorization experts 108 . these entities provide various input via an intranet 109 through suitable web browser interfaces such as internet explorer marketed by microsoft corporation utilizing administrator user interfaces appropriate to their purpose . the data handling section 103 comprises a series of modules that together assimilate job information scraped from the sites 102 into an orderly configuration generally described as follows . a scraping module 112 in the data handling section 103 has one or more job scraping engines 114 . these job scraping engines are software routines that are used to query each of the several thousand sites and job boards 102 for new job postings and job information data sets . such job information data sets include parameters unique to the job posting such as title , company , city , state , salary , hours , skills , qualifications , experience etc . and a detailed job description that describes , in paragraph form , the duties , experience and tasks to be performed in the job . the scraping module 112 comprises one more scraping engine farms 114 that typically use different scraping technologies and methodologies which may be developed as a matter of design choice but are preferably specifically directed in a preferred embodiment herein for searching over a global electronic network such as the internet 110 , with each engine 114 being optimized for either a particular type of scraping task or particular type or set of corporate sites . for example , the kelkoo scraping engine farm , developed by kelkoo , inc . in europe , now a subsidiary of yahoo , inc ., is optimized to thoroughly scour a predetermined known corporate site or listing site . the kelkoo scraping engine is optimized to follow internal links within the site to specific internal locations to extract job information data sets . however , it does not follow external links . the café / kelsa scraping engine farm , developed by yahoo , inc ., and described in u . s . patent application ser . no . 11 / 064 , 278 , filed feb . 22 , 2005 and entitled techniques for crawling dynamic web content , is optimized to systematically examine a seed url and follow every link within the site and follow every internal and external link that may be provided on that url as well as links it finds on its “ crawl .” preferably , a scraping agent is created for each career site 102 that is desired to be searched for job postings / listings and corresponding job information . the scraping agent uniquely has a url address for its particular destination site , and essentially is a file that provides the parameters to the kelkoo scraping farm as to what areas on a particular site can be searched , how often , and when for each particular site so that the individual sites are not overused and overscraped . in contrast , the scraping agent for the cafe kelsa scraping engine farm preferably simply contains the site url and scraping frequency requirement information . once the scraping module 112 performs a scrape of the desired career sites , the results of the scraping exercise are passed to a scraping management process module 118 and stored in a raw database 122 . this scraping management process module 118 performs functions such as scrape scheduling , error handling , recovery in the event of software failures , error logging and reporting , and monitoring of the scraping process . thus , for example , scraping management process module 118 may perform objective tests against the raw data to identify gross errors such as non - delivery of information from a site designed to be scraped , garbled data , or data that is comprised of fewer than a predetermined number of bytes , which would be indicative of a failed scraping exercise . scraping management module 118 is administratively operated externally by operators 120 via an internet 110 connection into the module 118 in a known manner . the resulting output of the scraping management module 112 is fed back to and updates the raw database 122 . this database 122 contains the raw data as received by the scraping process performed by the scraping module 112 , and as corrected in the scraping management module 118 . the output of module 118 is also collected in a cooked , i . e . modified , database 126 . the scraping management process module 118 communicates with the scrape listing quality manager module 124 . the scrape listing quality management module 124 instructs the scraping management process module 118 when to transfer a job information data set to the cooked database 126 and then this module 124 preferably begins examination of that data set . the scraped listing quality management module 124 pulls scraped data from the cooked database 126 and performs further quality management tests on the scraped job information received as part of the scraping exercise in module 112 . for example , the listing quality management module 124 performs a high level of quality management such as collecting byte count or job count information from the scraping exercise , performs site comparisons , checks for required fields , compares with previously encountered listings from the same job site to compare data formatting and also to delete duplicates , i . e . “ de - dupe ,” data to avoid redundant listings . this module also detects and removes dead links and filters profanity and offensive text . the scrape listing quality management module 124 then updates the data set and returns it to the cooked database 126 . again , this module 124 is administered and operated by operations via an intra 109 connection via a suitable web browser . if , in examining a job information data set in module 124 , it is determined that the quality does not meet predetermined criteria , for example , a manual review quality flag can be set in that data set when it is returned to the cooked database 126 by the listing quality management module 124 . a scrape listing quality manual review interface module 128 permits an operator to periodically examine the cooked database 126 for data sets having these set flags . this module 128 indexes these data sets and then utilizes the services of human listing reviewers 130 to perform the highest level of quality management on the scraped job listings to ensure the highest level of quality or to review listings that automated modules 118 and 124 were unable to pass as quality listings . depending on the nature and scope of the quality issues presented by a particular listing , the job listing ( job information data set ) may be passed to the cooked database 126 through the scraped listing quality management module 124 . this cooked database 126 contains job listings that have undergone a satisfactory level of quality management . thus , modules 118 and 124 all have the ability to pass approved job listing data sets to the cooked database 126 as well as job listings that have been manually reviewed as part of the manual review process module 128 . a job categorization control process module 132 then reviews the job information data sets that pass the quality reviews in the cooked database 126 in order to accurately categorize each job listing . it is important that a job listing be placed in the proper job category , such as for example , information technology , healthcare , accounting , etc . the job categorization control process module 132 preferably is automated . in addition , a manual review interface module 134 is available to review job information data sets that the module 132 flags for manual review . this module permits categorization experts 136 to verify categorization data via an intranet connection 109 and update content of a manual categorization “ mancat ” database 138 and the dcp service 140 . however , the function of the experts 136 may alternatively , as is the case with listing reviewer entities discussed earlier , be automated routines in the future as such systems become more sophisticated . the job categorization control process module 132 is preferably automated , while the manual review process module 134 provides a manual check on quality , thus providing a high degree of accuracy in job categorization . the results of this categorization process are stored in “ mancat ” database 138 , which is a contraction name for the manual categorization database . the job categorization process module 132 and the manual review interface 134 both feed job categorization information to a document categorization platform ( dcp ) service module 140 , identified herein as dcp 140 . the dcp service module 140 looks at the jobs and analyzes the entire text of each job description in each job information data set for comparison to a database of other text to determine a confidence value . thus , the dcp service module 140 is an automated process that , over a time period , can be “ trained ” to accurately characterize job information data sets scraped and passed through various levels of quality management . the dcp service module 140 functionality is described in more detail in u . s . patent application ser . no . 10 / 920 , 588 , mentioned above , along with the related u . s . patent applications referred to therein . the dcp service module 140 preferably compares the text of a newly submitted job description with existing job information data sets in the same category , and look for specific characteristics such as education , use of similar terminology , length , companies worked for , etc ., to arrive at a particular level of confidence that the categorization is accurate . failure to achieve a particular level of confidence through this text matching , for example , a 70 % match or less would result in job information being held and placed into the manual characterization database 138 for manual review . a 90 % match , would result in job information having a high degree of confidence . this information is attached , or otherwise associated with job information that is stored in the cooked database 126 . similarly , a job description that has been manually characterized can be identified to cooked database 126 as a job description with a high degree of confidence that has been correctly characterized or categorized . for archival storage purposes , periodically the contents of the cooked database 126 are placed in the archive database 142 . similarly the content of the other databases 138 and 122 may be periodically rotated and dumped for archival purposes to the database 142 . another component in the data handling section 103 is an extractor module 144 . this extractor module 144 works in conjunction with and interfaces directly to a scraped job search bank 146 in the output section 105 of the system 100 . the extractor component or module 144 takes cleansed and categorized job information data sets from the cooked database 126 . it reformats them into a format for use by the scraped search bank 146 and transfers the reformatted data sets to the search bank 146 . the server cluster 148 , for example , in reaction to search terms provided by a job seeker 107 through the internet 110 , accesses the search bank 146 , searches the database 126 , and passes identified scraped job search listings to the cluster 148 and then to a job seeker 107 through the internet 110 for depiction on a search result user interface screen such as is shown in fig2 . the extractor module 144 preferably also periodically queries the cooked database 126 to provide new scraped job postings to the scraped search bank 146 so that this scraped search bank 146 maintains a current bank of listing data sets . the data output section 105 comprises the job search web server / client cluster 148 and a number of data source modules to this cluster 148 . the scraped search bank 146 is one of these . an ad system premium listing module 150 , a paid search bank 152 , an overture system content match module 154 and a link builder module 156 are queried by the job search web server / client cluster 148 . the ad system premium listing module 150 organizes and provides the cluster 148 with advertisements from specific employers or recruiters that have a paid premium account with the host of the system 100 . these premium advertisements may be displayed to the job seeker in a special box , bannered , highlighted , or otherwise set off from the other listings that may be presented to a job seeker 107 in response to a particular search request . the paid search bank module 152 is a special search bank for which an employer member 160 may access upon a fee payment to the host of the system 100 . this paid search bank module 152 identifies , stores , and tracks job listings from those job recruiter employer or corporations who pay a fee to ensure that their posted job listings receive a higher or emphasized placement on a user interface presented to the job seeker 107 . thus the paid postings are provided directly into the search bank 152 by the member company via a member desktop 162 or gateway 164 . paid search bank 152 contains information provided by job listing entities that have paid a premium to the operator of the system 100 described herein to push listings in connection with certain desired search categories provided by a user , so that such search results are provided in a prominent position to the user via the user interface 200 in exchange for a premium payment . the overture system content match module 154 queries whether there are any advertisements that match the job searcher &# 39 ; s search criteria . these advertisements are previously stored in or linked to a paid database for use by the host of the system 100 . examples of such advertisements are shown in the search results user interface screen shot shown in fig3 . the link builder module 156 provides linkage cookies and addresses to link to other sources of jobs that match the search terms provided by the job seeker 107 . in some instances , in order for a job description to be viewed , the job seeker must be passed to a particular website to see the listing . in such circumstances the site might require a particular security element such as cookie , password etc . before the job information may be viewed . accordingly , link builder module 156 provides the necessary interface characteristics in the case where a site needs a particular cookie or other identifier . the link builder module 156 manages the process to build a url which includes the necessary information required by the site such as for example , a session cookie to access the job listing . the result of the link builder module 156 may be provided to the job seeker 107 in addition to the particular jobs of interest from his / her search request . with continued reference to fig1 , the web server cluster 148 acts as a gateway interface to a job seeker 107 seeking to utilize the system 100 described herein . the job seeker 107 , in order to initiate a search request on the system 100 , is preferably presented with a user interface similar to that shown in fig3 . the cluster 148 then searches to obtain information from the system search banks 152 , 154 , 146 and 150 and presents it in an easy to use and efficient manner to the querying job seeker 107 such as in the exemplary results interface shown in fig2 . a job seeker 107 entering a search request 302 into a user interface 300 such as that depicted in fig3 interfaces with the server cluster 148 , which in turn presents an aggregated result to the job seeker 107 as shown in fig2 . thus the user would see , as described below , premium listings through the provision of listings identified by the ad system premium listing module 150 , job search bank 152 , the banks 154 , 150 , 146 and crawled jobs from bank 156 . turning now to fig2 , an exemplary screen shot of a user query result interface 200 is shown . this user interface 200 gives the job seeker an opportunity to review all of the job information that match his query . in addition , it permits the job seeker to submit a different or more refined query . display portion 202 gives the user an opportunity to review all of the job information that would match a particular search criteria , for example , in fig2 , a software developer position in illinois . the job seeker may review all of the job information available as a result of the search for software developer positions , or may review only those descriptions that have been updated in the past 24 hours , 7 days , or other preselected time period . also the job seeker may structure his or her search by experience level , location , or other characteristic or subcategories within a job description . the interface 200 also displays result segments separated by multiple preferable result groupings . thus the system 100 may present a segment for premium listings 204 obtained from ad system premium listing module 150 , which permits the host of the system 100 to utilize the system 100 as a revenue enhancing tool by providing the opportunity for business seeking employers to pay premium to have their job listings obtain a more prominent position in the result portion of the user interface 200 presented to the job seeker 107 . the user interface 200 also preferably includes a second subsection 206 which presents results of the search from the paid job search bank 152 . a third subsection 208 presents non - premium algorithmic search results which is a direct result of searching the scraped search bank 146 . a fourth section 210 provides more general paid links from the overture system content match module 154 . finally , a number of advertisements 209 may be displayed from a search of the ad system premium listing module 150 . with reference to fig4 , a simplified functional flow diagram 400 of the scraping performed by the system 100 is shown . this scraping process begins at operation 402 where career sites 102 are scraped . control then passes to operation 402 where the scraped listings are fed to storage in the raw database 122 . once stored , control passes to operation 404 . in operation 404 , the scraped listings are submitted to quality assurance / quality management processes described above and further herein with reference to modules 124 and 128 . control then passes to operation 406 . in operation 406 the clean scraped listings are fed into storage in cooked database 126 . control then passes to operation 408 . here the clean scraped listings are categorized in modules 132 and 134 . control then passes to operation 410 . in operation 410 the clean and categorized scraped listings are fed to storage again in the cooked database 126 . control then passes to operation 412 . in operation 412 , the cleaned and categorized scraped listings are indexed and formatted in the extractor module 144 for use by the semi - structured search engine described herein . control then passes to operation 414 . in operation 414 the indexed listings are stored and compiled in the scraped search bank 146 for use . control then passes to return operation 416 . scraping involves the following components 500 shown in fig5 : the kelkoo “ sniffer ” and café / kelsa crawlers in scraping engine 114 , a series of agents 502 to scrape web sites 102 for jobs , preferably a mysql database such as raw database 122 to store the scraped jobs and agent logs , and runner scripts 504 to launch the agents 502 . the following is a summary of how data flows preferably through the scraping farm 112 in the system 100 . at the beginning of the scraping cycle the “ job_current ” table 500 is truncated and its contents are copied to an archive table ( not shown ). archives of scraped jobs are preferably stored for a limited period only ( e . g . 7 days ). the kelkoo “ sniffer ” in the scraping engine 114 is a java program that is used to launch adapters ( a . k . a . agents 502 ). the scraping engines 114 scrape the job boards 102 , via the agents 502 . each agent 502 preferably consists of three text files : agent . info , agent . props , and agent . sql . a single agent is used to scrape a single web site . the agent files are stored in an agent specific directory . then the agents 502 dump the scraped job information sets into a “ job ” table ( note that there can be several job tables ) 506 , two of which are shown in fig5 . the runners 504 copy the job information sets , or records , from the “ job ” table ( s ) 506 to the “ job_current ” table 510 . components downstream from the runner 504 , such as the quality manager module 124 and the categorizer modules 132 and 134 pull copies of the job records from the cooked database 126 and perform quality management and categorization operations on the records in the job_current table 510 , which is preferably part of the cooked database 126 . the results are then passed back to the cooked database 126 shown in fig1 . the kelkoo sniffer search engine 114 thinks about agents 502 as virtual sql tables . the schema of the virtual table is defined in the agent . sql file . the agent . info file is a select statement against the virtual table that the sniffer search engine 114 runs . the agent . props file contains the scraping logic that is used to fill the virtual table . the scraping logic is a sequence of steps that are carried out by various filters . filters are java classes that make up an adapter development kit ( adk ). filters are executed sequentially and can read and write variables to a common context . there are filters to : find a string or a pattern in an html page and save it , manipulate variables of the context , loop over a re - occurring pattern and execute other filters in a loop , go to a page identified by a url and retrieve its content , etc . the output of an agent 502 is a text file that contains sql insert statements for each scraped job . the sniffer search engine 114 uses this data file to load the scraped job information data sets or records into a mysql table , called “ job ” ( the actual table name is a configuration parameter ) 506 . the sniffer 114 is configured via various command line parameters and an arbitrary number of property files that are passed in on the command line . the most important configuration parameters of the sniffer search engine 114 are : name of the mysql database , database user and password , name of the table to dump the scraped records to ; and the path to the agent request files and the directory that contains the agents 502 . the sniffer search engine 114 is preferably single threaded : it loads and runs one agent 502 at a time . after running an agent 502 the sniffer search engine 114 inserts a record to the “ report ” table 508 with information about : the time of the run , the name and path of the agent 502 , the number of scraped records ( jobs ), and possible errors . the agent files are stored in a cvs repository . the version of the agent 502 that has passed qa is tagged with a special cvs tag . this scheme allows agent developers , testers and the production system to work on the same tree , yet to avoid running un - tested agents in production . the agent runner 504 is a perl script that is developed for the system 100 . the runner 504 requires that the agent files be available on the local file system . before the runner 504 is started the local cvs tree is synced to the production tag to download all the agent files that should be run . 1 . it reads its configuration file . this contains the list of agents 502 to run . each runner has an id that is passed in as part of the configuration . 2 . it generates configuration files for the sniffer 114 based on its own configuration . 3 . it deletes all the records from the job_current table 510 that belong to the agents 502 to be run ( this in most cases is unnecessary , since preferably the job_current table is truncated every day ). 4 . it launches the sniffer search engine 114 that runs the agents 502 . 5 . it preferably processes each record in the job table to strip the job information from html tags . each runner has its “ own ” job table 506 whose name is generated using the runner &# 39 ; s id ( e . g . “ job 1 ”). 6 . it dumps all the records from the job table 506 to the job_current table 500 . the job records contain the id of the runner , which helps downstream components to easily identify records that came from a particular runner 504 . 7 . it writes a summary of the agents run to its log file . this information is retrieved via queries to the job , job_current and the report tables 506 , 500 and 508 respectively . 8 . finally , it invokes the quality manager management process module 124 via a secure shell such as ssh , so it can execute on a separate machine . the id of the runner 504 is passed to the quality manager module 124 , so it knows which records to process from the job_current table 500 . the system 100 is primarily designed to handle scraped jobs in addition to listings provided from standard sources that generally have standardized formats and categorizations . these scraped jobs typically may not have category assignments such as accounting , banking , engineering , medical , dental , etc . in order to support a “ browse by category ” feature that jobseekers are most familiar with , we could have many human categorizers spend a great deal of time to manually classify jobs as they are scraped . however , this has substantial drawbacks . it is a very time consuming process . by the time the jobs are manually classified , they may be outdated already . such a process requires a lot of human resources . further different categorizers may not categorize in the same consistent manner . for this reason , an exemplary automatic job categorization system 600 that may be used is shown in fig6 . this system 600 is capable of categorizing a job in a fraction of a second . it is substantially faster than human categorizer , and , it is consistent . this job categorization system 600 contains several modules . a job categorization ( job cat ) service module 602 which carries out the actual categorization routine . the job categorization control process module 132 is one example , which is described with fig1 , which manages communication between the job_current table 510 in the cooked database 126 , the mancat database 138 , and the dcp 140 . the dcp 140 corresponds to one example of a job cat service module 602 . the categorization training process , which is used to enhance or maintain the accuracy level of the job cat service 602 . this categorization training process involves the use of the job categorization manual review interface 134 and categorization experts 136 shown in fig1 . as described above , the jobs scraped are added to a mysql job_current table 510 . then the job categorization process 600 will take each job from the job_current table 510 , and send it through the job categorization control process module 132 to the job cat service module 602 to get a category and confidence assignment . then the scraped job is sent back to the categorization control process module 132 and returned to the job_current table 510 . however , if a job falls below a predetermined confidence threshold it will be flagged , i . e . a flag set , and when it passes through the categorization control process module 132 a copy is also sent to the mancat database 138 for manual review via the manual review interface module 134 . the results of the manual review process performed in review module 134 are then used by the categorization training process 606 to tune a new job cat service value to replace the old one . the result of classification is written back to job_current table 510 and sometimes the mancat table 138 . the manual review module 134 provides a ui to review both jobs in job_current and mancat tables . fig7 is an operational flow diagram of an implementation of the job categorization process 600 . the process begins in operation 702 when a sequence of job scrapings has been performed . control transfers to operation 704 . in operation 704 the job attributes for the next job are retrieved from the job_current table 510 and the job information is properly formatted . the job attributes are then transferred to the job cat service 602 to find a proper category . control then transfers to operation 706 where the job category and confidence level for that categorization are paired with the job . control then transfers to query operation 708 . query operation 708 asks whether there is a matching url existing in the mancat table for the latest particular job information . if there is , then control transfers to operation 710 . if not , the job is a new job , and control transfers to operation 716 . in operation 710 , a string compare routine is performed on the last job with the same url . control then transfers to query operation 712 . query operation 712 asks whether the listing in the mancat table 138 is the same as the current job being examined . if the job string compare is equal , then the answer is yes , and control transfers to operation 714 since it appears that the job is the same job . on the other hand , if the answer is no , the job is new , and control again transfers to operation 716 . query operation 714 asks whether the dcp_cat matches the man_cat of the latest job with the same url . if the answer is yes , then the man_cat and dcp_cat are set equal and the dcp_cat confidence is set equal to 1 . the job parameters back to the job_current table 510 , and control transfers to query operation 718 . query operation 718 asks whether there are more scraped jobs in the job_current table to be categorized . if not , control transfers to return operation 720 . if there are more scraped jobs to be categorized , control passes back to operation 704 and the job parameters for the next job are retrieved and formatted . returning to query operation 708 , if the url does not exist in the mancat table , then control transfers to operation 716 . in operation 716 , the dcp_cat and dcp_confidence are set , the confidence value is checked against the threshold that has been predetermined , and if the threshold is greater than the confidence value , the review_flag is set equal to 1 . the job parameters are then passed to the job_current table 510 and again , control passes to query operation 718 . returning to query operation 714 , if the current jog has a url in the mancat table 510 , the job is the same as the last job with the same url , but the dcp_cat and an_cat of the latest job do not match , then something may be wrong or missing , and the job parameters are passed to both operations 724 and 726 . operation 724 sets the dcp_cat , the dcp_confidence values , sets the expert_review flag = 1 and feeds this data to the job_current table 510 . operation 726 sets the expert_review flag = 1 and sends a copy of this job &# 39 ; s parameters to the mancat database 138 so that manual review will be performed . in parallel , control again passes to the query operation 718 as described above . thus , for each job , the job categorization control process take job attributes from the job_current table , formats them , and sends them over to job cat service managed by a well known public domain routine called apache , method = post ), gets back a category and confidence score , goes through a chain of decision questions , and writes results back to the tables . the job cat service 602 also provides a web ui that allows administrators and system operators in a job ( at least the job description ) and submit the job to the job cat service for categorization separately from the normal operation of the system 100 . such an exemplary user interface 800 is shown in fig8 . the job cat service 602 depends on apache , a well known management routine to manage the training process 606 shown in fig6 . the jobcat service 602 contains a binary package that is a shared library of php extensions and also includes a categorization library . building the job cat service 602 first requires a set of basic definitions i . e . a taxonomy 608 , of job categories and associated unique id numbers . an exemplary set is shown in table 1 below . an exemplary table of training job information , training data 610 , is associated with each of the categories in table 1 . this set of descriptions , plus the content of the mancat database 138 , is used to teach the service to recognize classifications from the provided job information parameters that are preclassified . an example of this table is shown in table 2 below . for new training sessions , it is preferable to use both jobs from this table and those in the mancat table . as more and more manual reviewed jobs become available , it is preferable to eventually drop the original training set from the hotjob &# 39 ; s read - only database . in a preferred embodiment the columns of this table 2 and the mancat table are different , and this difference will remain , and the script that creates the training file will do all necessary mappings . the training process 606 consists of several pearl scripts . a “ create - training - file . pl ” script takes jobs from both the mancat table 138 and a train data table 610 , and writes out a file containing all jobs in a dcp accepted format to generate the merged training data 612 . a “ train - hj - dcp . pl ” script is used to tune a few of the most useful parameters for classification . each of the configurations specified will leave an output directory containing all the parameters that are needed to build a job cat service data package , and a log file . a “ parse - training - log . pl ” script reads each of the log files generated by the train - hj - dcp . pl script and generates a report on accuracy for each configuration . an “ archive - training - results . pl ” script is used to archive the training results for that configuration after a configuration is used for deployment . the training process 614 is basically a manual process that draws from the training data 612 , the taxonomy 608 , and sets of rules and schema 616 . various dictionaries and tuning parameters 618 may also be utilized . the results involve optimization of new classifier parameters 620 with the results being provided into the job categorization service 602 as shown in fig6 . since the training process 614 is mostly manual , it is preferable to train on a few parameters , manually check the results , e . g . detail pages of classification , term weights , etc , and change some of the rules and dictionaries by hand , and repeat the process with different configurations in order to find the optimal settings for deployment . when such an optimal configuration is achieved , the new classifier parameters 620 are passed to the job categorization service 602 . once the job categorization service is built up and running , scraped jobs can then be processed as described above . the screen shot of the exemplary user interface 800 is presented to an administrator , operator or categorization expert 136 through the internet 110 using a web browser . the interface 800 provides three different modes 802 via a pull down menu as shown . the “ all categories ” mode lists all categories and their corresponding confidence values , sorted in descending order by confidence . the “ detail statistics ” mode shows the details on why a particular category is chosen . this mode is useful for an operator who tunes the system 100 . the “ best category ” mode shows only the top category for the job and its confidence . this is equal to the first result shown in “ all categories ” mode , except here we show the category id number , not a string . this mode is intended for automatic classification of jobs in the database , where the category id number is preferred over the category name . an operational flow diagram of the job categorization manual review process 900 that takes place in the job categorization manual review module 134 is shown in fig9 . operational flow begins when an administrative operator or a categorization expert 136 logs in via backyard in operation 902 . when the administrator logs in , he or she is presented in operation 904 with a user interface 1000 as shown in fig1 . this user interface 1000 permits the administrator or expert reviewer choices of job category 1002 , company 1004 , and selection of a type of review 1006 to conduct . control then transfers to operation 906 . in operation 906 , a first / next job information is retrieved from the mancat database 138 or the job - current file 510 in the cooked database 126 , depending on the administrator &# 39 ; s prior selections in operation 904 . the administrator is presented with a user interface such as the exemplary interface 1100 shown in fig1 . this user interface 1100 displays the first / next job information 1102 along with the category confidence level s determined for each category . in this example , the job is a post - doc position at ibm corp . the confidence levels are zero for all but engineering_architecture and pharmaceutical_biotech , and none of the levels match 100 %. this position has been categorized as engineering architecture , but the confidence level is only 0 . 657 , so it was flagged for manual review . referring back to fig9 , when the job information is retrieved in operation 906 , control transfers to operation 908 where the administrator analyzes the categorization based on the full job information . the administrator then has three choices of action . first , he can invalidate the job in query operation 910 . second , he can get more job details in query operation 912 by clicking on the job url 1110 to enhance his review . third , he can update a category definition or insert a new category in query operation 914 . if his decision is to invalidate the job in query operation 910 , then control transfers to operation 916 where the job is removed from the database 126 and from the mancat database 138 . control then transfers to query operation 918 . query operation 918 asks whether there is another job information in the queue of the mancat database 138 or job_current table 510 that has its expert_review flag = 1 set . if so , control transfers back to operation 906 where the next job is retrieved for review . however , if the decision in operation 910 is not to invalidate the job , control resets the expert_review flag = 0 , returns the job to the job_current table 510 and control transfers to query operation 918 . if the choice in operation 908 is to get more job details , control transfers to operation 920 , where the details are retrieved and control transfers back again to operation 908 . if the administrator then chooses not to get more details , the job listing record is again returned to the job_current table 510 after resetting the expert_review flag = 0 and control passes again to query operation 918 . if the choice in operation 908 is to update the category in query operation 914 , then control passes to operation 922 . in operation 922 the category of the job listing is changed or a new one added , and saved . the expert_review flag is set = 0 and the job listing information is then transferred to the job_current database 510 and control transfers to query operation 918 . if there are no more job listings with expert_review flags set = 1 , control transfers to return operation 924 and the review session is complete . although functional components , modules , software elements , hardware elements , and features and functions described herein may be depicted or described as being fixed in software or hardware or otherwise , it will be recognized by persons of skill in the art that the features and functions described herein may be implemented in various software , hardware and / or firmware combinations and that the functions described herein may be distributed into various components or subcomponents on the network and are not fixed to any one particular component as described herein . thus the databases described may be separated , unified , federated , or otherwise structured to best suit the preferences of the implementer of the features and functions described herein . also , the functions described herein as preferably being performed manually may be performed manually or may be divided into subtasks which may be automated and ultimately performed by intelligent subsystems which mimic human operator interaction such as artificial intelligence systems which may be trained by human operations and ultimately function autonomously . further features , functions , and technical specifications are found in the attached descriptions further below as well as the figures contained therein . while the apparatus and method have been described in terms of what are presently considered to be the most practical and preferred embodiments , it is to be understood that the disclosure need not be limited to the disclosed embodiments . it is intended to cover various modifications and similar arrangements included within the spirit and scope of the claims , the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structures . the present disclosure includes any and all embodiments of the following claims .