Patent Grant
7904411
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to any software and data as described below and in the drawings hereto: Copyright© 2004, Accenture, All Rights Reserved.
1. Technical Field
The present invention relates generally to an improved method for obtaining, managing, and providing complex, detailed information stored in electronic form in a plurality of sources. The invention may find particular use in organizations that have a need to discover relationships among various pieces of information in a given field.
2. Background Information
With the advent of the Internet, the Information Age is upon us. Today, one can find vast amounts of information about any given field or topic at the touch of a button. This information may be available from myriad sources in a variety of commonly recognized formats, such as XML, flat-files, HTML, text, spreadsheets, presentations, diagrams, programming code, databases, etc. This information may also be kept in third-party proprietary formats.
Amid this apparent wealth of online information, people still have problems finding the information they need. Online information retrieval may have problems including those related to inappropriate user interface designs and to poor or inappropriate organization and structure of the information. Additionally, the storage of information online in the variety of formats described above also leads to retrieval problems.
The existence of a variety of information sources leads to many problems. First, there is a lack of a unified information space. An “information space” is the set of all sources of information that is available to a user at a given time or setting. When information is stored in many formats and at many sources, a user is forced to spend too much overhead on discovering and remembering where different information is located (e.g., web pages, online databases, etc). The user also spends a large amount of time remembering how to find information in each delivery mechanism. Thus, it is difficult for the user to remember where potentially relevant information might be, and the user is forced to jump between multiple different tools to find it.
The existence of a variety of information sources also leads to information discovery strategies that lack cohesion. Users must learn to use and remember a variety of metaphors, user interfaces, and searching techniques for each delivery mechanism and class of information. Other problems associated with large numbers of information sources include a lack of links between information sources, and poor delivery mechanisms that don't provide a global view of the information space.
To overcome these problems, knowledge discovery tools have been developed. These tools extract information from a plurality of data sources, integrate the information into a common data model, and provide a graphical user interface for viewing the information. While these types of systems have been useful for unifying the information space for a given domain, they still suffer from several limitations.
First, each of these data sources typically includes a large volume of files. Thus, collecting and integrating information from a particular data source consumes both time and resources. However, in order to truly represent the information space for a given domain, these tools must collect data from many data sources. Each data source added to the process becomes an additional strain on both resources and time. Moreover, this information must be processed repeatedly to ensure that the data model includes the most current information. Present systems will process a data source in its entirety each and every time an extraction and integration cycle take place. Accordingly, there is a need for a system that doesn't waste time and resources re-integrating information that has already been integrated into the data model.
Second, integrating information from a plurality of data sources also leads to problems in the consistency of the information contained in the data model. Information in the data model may be overwritten by less reliable data. For example, a particular person's name may be found in both a structured database maintained by the IRS and the text of an email. In present systems, the name sourced from the email may be used to overwrite the name obtained from the IRS if the email is integrated later. Because the information maintained by the IRS is inherently more reliable than the text of an email (because of both source credibility and structured data), there is a need for a system that takes into account the reliability of the information maintained by the data sources before integrating that information into the data model.
Third, the information integrated into the data model is inherently related as that information defines the information space for a given domain. Unfortunately, present systems do not fully realize these interrelationships. Typically, relationships between the data in the knowledge must be defined manually. Manually defining these relationships, however, is a time consuming and expensive process. While systems automatically incorporate those relationships maintained by a particular data source (for example, relationships defined by a database data source), these relationships only represent a fraction of the relationships present among the information contained in the data model. Accordingly, there is a need for a system automatically discovering and generating various types of relationships.
The present invention provides a robust technique for integrating, from a plurality of data sources, only the necessary, most reliable data into a data model, and automatically discovering inter-relationships among the various elements of the data model.
In one embodiment, a system for managing a knowledge model defining a plurality of entities is provided. The system includes an extraction tool for extracting data items from disparate data sources that determines if the data item has been previously integrated into the knowledge model. The system also includes an integration tool for integrating the data item into the knowledge model that integrates the data item into the knowledge model only if the data item has not been previously integrated into the knowledge model. Additionally, a relationship tool for identifying, automatically, a plurality of relationships between the plurality of entities may also be provided. The system may also include a data visualization tool for presenting the plurality of entities and the plurality of relationships.
In another embodiment, a method for determining a relationship between a plurality of entities of a knowledge model is provided, where the knowledge model having a plurality of entity tables, each of the plurality of entity tables including a plurality of records, each of the plurality of records having a plurality of fields. The method may include retrieving a first relationship definition, the first relationship definition defining a relationship between a first field and a second field, retrieving a second relationship definition, the second defining a relationship between a third field and a fourth field, and generating, automatically, a transitive relationship definition based in part on the first relationship definition and the second relationship definition.
These and other embodiments and aspects of the invention are described with reference to the noted Figures and the below detailed description of the preferred embodiments.
Referring now to the drawings, and particularly to
The knowledge discovery system in the embodiment of
Referring now to
Next, the compare tool 330 of the extraction tool 120 compares the records or documents 315a, 315b with those records or documents 315a, 315b that have already been integrated into the knowledge model so that only records or documents 315a, 315b that are new are further processed. As used herein, a new record or document 315a, 315b includes records or documents 315a, 315b that have been integrated into the knowledge model 140, but have since been modified. In other words, previously entered records or documents 315a and 315b may include only those records or documents that have been integrated into the knowledge model 140 and have not changed since their integration. In one embodiment, compare tool 330 will compute a value based on the record or document 315a, 315b . Preferably, the compare tool 330 uses a hash function to generate a hash value for each record or document 315a, 315b . The value may be based on any part of the record or document 315a, 315b , such as the identifier or the information contained therein.
Referring now to
Field-to-field relation tables define the relationships between the fields in the entity tables. In one embodiment, three types of field-to-field relationships exist. A name-to-name relationship relates two name fields from two entity tables. A name-to-attribute relationship relates the name of one entity to an attribute of another entity. An exemplary field-to-field relationship is shown in
Referring now to
The extraction tool 120 extracts relevant information from the various data sources 110. Preferably, the extraction tool 120 is an asynchronous process that begins processing a file as soon as that file is retrieved from a data source 110. Alternatively, the extraction tool 120 may be implemented as a batch process. In one embodiment, each data source has an associated data source type. In one embodiment, each data source may be either an internal data source or an external data source. An internal data source is a data source that is internal to the organization utilizing the knowledge discovery system 100, whereas an external data source is a data source maintained by any other organization. Alternatively, or in addition to, the data source type may define the structure of the data source, such as the underlying directory structure of data source or the files contained therein. Additionally, the data source may be a simple data source consisting of a single directory, or a complex data source that may store metadata associated with each file kept in the data source. In one embodiment, the extraction tool 120 connects to each of the data sources 110 through data source adapters. An adapter acts as an Application Programming Interface, or API, to the repository. For complex data sources, the data source adapter may allow for the extraction of metadata associated with the information.
Exemplary data sources include PUBMED, a service of the National Library of Medicine that includes over 15 million citations for biomedical articles back to the 1950's, SWISS_PROT PROTEIN KNOWLEDGEBASE, which is an annotated protein sequence database established in 1986, the REFERENCE SEQUENCE (RefSeq) collection, which aims to provide a comprehensive, integrated, non-redundant set of sequences, including genomic DNA, transcript (RNA), and protein products, for major research organisms, KEGG, or the Kyoto Encyclopedia of Genes and Genomes, an ongoing project from Kyoto University, LOCUSLINK, a service of the National Library of Medicine that provides a single query interface to curated sequence and descriptive information about genetic loci, MESH, or Medical Subject Headings, the National Library of Medicine's controlled vocabulary thesaurus, OMIM, or Online Mendelian Inheritance in Man, a database catalog of human genes and genetic disorders, and NLM TAXONOMY, a searchable hierarchical index of names of all the organisms for which nucleotide or peptide sequences are to be found in certain data sources. Although each of these data sources constitutes a separate data source, the information in each data source has strong inter-relationships to information in others. Accordingly, the files stored in any particular data source 110 may include information relating the information therein. Referring to
Optionally, the extraction tool 120 may include various parameters used to determine whether a document is relevant. These parameters may be predefined or configurable by a user. For example, a user may configure the extraction tool to only extract files from specified directories. It should be apparent to one of ordinary skill in the art that many other relevance parameters—for example, only certain file types or only files that have changed after a certain date—are contemplated by the present invention.
As stated above, the extraction process 120 retrieves files from the data sources 110. The original files may include large files that are of varying formats. In one embodiment, the extraction tool 120 includes a cut tool 310 that will split the original files into smaller records or documents 315a, 315b, etc. Preferably, the cut tool 310 will process the original files such that each record or document 315a, 315b includes one and only one data item. Alternatively, the cut tool 310 may generate records or documents 315a, 315b that include more than one data item. The original files may also include the information about all items in a single file, separating the information using delimiters. Exemplary delimiters include “///” or a blank line. A configuration file may be provided that details the delimiters used at a particular source. The configuration file may be used by the cut tool 310 to process the original files. In one embodiment, the cut tool 310 may include particularized processor application for processing a particular type of original file, such as an XML processor for cutting XML files or a text processor for manipulating text files. In one embodiment, these particularized processor applications are implemented as C# objects using the C# object-oriented programming language from Microsoft Corporation of Redmond, Wash.
Once the files are split into records or documents 315a, 315b, the extraction tool 120 preferably stores the records or documents 315a, 315b in a file system. Optionally, each record may include an identifier, such as an identifier used by the data source to identify the original file. Exemplary identifiers include a SWISS_PROT ID or a file name. Preferably, the extraction tool 120 also generates a global unique identifier for each record or document 315a, 315b. The global unique identifier is used for tracking purposes, as described below.
The extraction tool 120 may also be provided with a map tool 320. The map 320 functions to standardize the format of each record or document 315a, 315b. In one embodiment, the map tool 320 serves two functions. First, the map tool 320 may create a normalized specification for the records or documents 315a, 315b, such as a standardized XML specification. For example, records or documents 315a, 315b created from flat files may be transformed into xml files, while records or documents 315a, 315b created from XML files may be mapped to the standard XML specification. Second, the map tool 320 may remove information from the record or document 315a, 315b that is unnecessary to maintaining the knowledge model 140. In one embodiment, the map tool 320 outputs a single text string of XML.
Next, the compare tool 330 of the extraction tool 120 compares the records or documents 315a, 315b with those records or documents 315a, 315b that have already been integrated into the knowledge model so that only records or documents 315a, 315b that are new are further processed. As used herein, a new record or document 315a, 315b includes records or documents 315a, 315b that have been integrated into the knowledge model 140, but have since been modified. In other words, previously entered records or documents 315aand 315b may include only those records or documents that have been integrated into the knowledge model 140 and have not changed since their integration. In one embodiment, compare tool 330 will compute a value based on the record or document 315a, 315b. Preferably, the compare tool 330 uses a hash function to generate a hash value for each record or document 315a, 315b. The value may be based on any part of the record or document 315a, 315b, such as the identifier or the information contained therein.
Referring now to
If a match is found in the table at block 402, the record or document 315a, 315b has been previously integrated into the knowledge model 140. The compare tool 330 next compares HashCodeActual to HashCodeCompare for the match. If two values are identical, the record or document 315a, 315b has not been modified since its last integration. Accordingly, the record or document 315a, 315b is not further processed as shown at block 412. If the values are different, the record or document 315a, 315b has been modified since its last integration. In this case, the compare tool 330 updates the HashCodeActual value with the current HashCode value at block 414. The extraction process 120 will continue to process the record or document 315a, 315b at block 416. Once the record or document 315a, 315b is integrated into the knowledge model 140, the HashCodeCompare value will be updated with the HashCodeActual value at block 418.
At this point, the only records or documents 315a, 315b to be processed are new records or documents 315a, 315b that have been properly formatted. However, the information contained therein may contain unnecessary information as a consequence of different data sources using different nomenclatures. For example, an attribute name may be preceded by an asterisk or dash. Alternatively, the record or document 315a, 315b may contain HTML tag information. In one embodiment, the extraction process 120 is provided with a clean tool 340 that removes this unnecessary information from the records or documents 315a, 315b.
Once the record or document 315a, 315b is cleaned, the parse tool 350 of the extraction tool 120 restructures the information of the record or document 315a, 315b. For example, if a record or document 315a, 315b includes an XML attribute tag containing multiple values separated by a delimiter, the parse tool 350 may each value into separate tags. Additionally, the parse tool 350 may unifies the different nomenclatures of the records or documents 315a, 315b so that the information from the different sources is coherent. For example, an Organism name may be listed under a first label in one data source 110 and a second label 110 in another data source. The parse tool 350 may standardize this information.
Finally, the extraction process 120 may store the record or document 315a, 315b to be integrated into the knowledge model. In the embodiment of
Referring now to
In the embodiment of
In one embodiment, the integration tool 130 may receive information to integrate in three ways. First, the integration tool 130 may receive information from the extraction tool 120. For example, the extraction tool 120 may process a record or document 315a, 315b from a data source, insert the record or document 315a, 315b into a database 360, and alert the integration tool 130 of the presence of the new information. In response, the integration tool 130 may retrieve the information from the database 360. Second, the integration tool 130 may receive information from a re-integration batch process. The re-integration batch process may build a message (of a similar format to those generated by the extraction process 130) that alerts the integration process 130 to the presence of a record or document 315a, 315b that could not be integrated into the knowledge model 140 during a previous attempt. Finally, custom applications may be developed to alert the integration tool 130 of information from particular data sources 110 that do not require the full functionality of the extraction tool 120. For example, an internal data source 110 may be provided that includes files that adhere to a particular structure designed to ease the integration process. It should be apparent to one of ordinary skill in the art that any method may be used to introduce a record or document 315a, 315b to the integration tool 130.
The integration tool 130 may be provided with an integrate tool 500. The integrate tool 500 performs four primary processes. First, the integrate tool may retrieve a record or document 315a, 315b from the database 360. Next, the integrate tool 500 may perform a spell check function 510 on the data included in the record or document 315a, 315b to ensure that misspellings in the original data source 110 files do not effect the integrity of the knowledge model 140. Similarly, the integrate tool 500 may perform a synonym function 520 to determine if the current term (as used in the record or document 315a, 315b) is a synonym for a preferred name. Finally, the integrate tool 500 may perform a merge function 530 that integrates the record or document 315a, 315b into a database 540. In one embodiment, the database 540 represents a un-optimized version of the knowledge model 140. A particular embodiment of the integrate tool 500 is discussed in more detail below in reference to
The integration tool 130 may also be provided with various batch-process tools to perform various functions on the information in the database 540. In the embodiment of
Referring now to
As shown, the configuration file includes various attributes that are used in later stages of the integration process. The exemplary configuration file includes five attributes, a Thesaurus attribute, a LookUp attribute, a Compare attribute, an Insert attribute, and an Update attribute. The thesaurus attribute includes information in the record that need to be checked for spelling and/or synonyms. In particular, the thesaurus attributes define a field name to be checked and the values for that field name. This value will appear in ThesaurusSP and SpellingSP attributes if the value needs to be checked for synonyms or spelling, respectively. If both the value needs to be checked for both spelling and synonyms, it will appear in both attributes. The LookUp attribute defines each field in the database 360 and the name of a procedure that can be used to lookup the associated row in the knowledge model 140. The Compare attribute defines the field in the database 360 and its corresponding field in the knowledge model 140. The Insert attribute defines each field in the database 360 and its corresponding confidence value, as described below. Finally, the Update attribute defines each field in the database 360, its corresponding confidence level, the field type, and the corresponding field in the knowledge model 140 and its corresponding confidence value. In one embodiment, two field types are defined. An update type implies that the value of the field should be replaced in its entirety if a new record or document 315a, 315b is to replace an existing entry in the knowledge model 140. An append type implies that the information in the new record or document 315a, 315b should be appended to the current information.
As stated above, each field includes an associated confidence value. The confidence value is used score the reliability of the data sources 110 for each field of the knowledge model 140. For example, multiple data sources 110 may include information for one field of the knowledge model 140. To resolve this conflict, the confidence value is used to determine which data source is more reliable for a given field. The confidence value may reflect an internal view of the reliability of the data sources 110 (i.e. the view of the system developers or the organization utilizing the knowledge discovery system 100) or may reflect an external view of reliability (i.e. the use of a third party reliability standard). In one embodiment, the confidence value is a numerical value from 1-20 where the confidence value increases with the reliability of the data source 110. In one embodiment, each of the plurality of data sources 110 is ranked from 1 to N for each field of the knowledge model, where N is the number of data sources 110. Alternatively, multiple data sources 110 may be equally reliable and therefore have the same confidence value. In such an embodiment, the integration tool 130 may chose the most recent record or document 315a, 315b as controlling. Alternatively, the integration tool 130 may only replace a field if the confidence value of the new record or document 315a, 315b is greater than the current entry.
In one embodiment, a confidence value configuration file is provided. The confidence value configuration file may define a confidence value for each field of the knowledge model 140 and for all data sources 110. Alternatively, a separate confidence value configuration file may be provided for each data source 110. It should be apparent to one of ordinary skill in the art, that various ways of tracking the reliability of a data source 110, as well as various types of configuration files, are contemplated herein. An exemplary XML confidence value configuration file is shown in table 2. In the exemplary confidence value configuration file, each field of each table from each data source 110 is ranked.
Referring now to
Returning to
Referring to
Returning to
Referring now to
Referring now to
Referring now to
Referring to
Referring now to
Returning to
Referring now to
The relationship generation tool 550 may also be configured to derive relationships by analyzing the data of the knowledge model 140. These types of relationships are referred to herein as derived relationships. In one embodiment, the relationship generation tool may include a transitive relationship tool 1420. The transitive relationship tool 1420 determines transitive relationships. As used herein, a transitive relationship is defined as any relationship between two entities that is based on at least two separate relationships. As discussed above, a direct relationship is a relationship that has been determined from information in a data source 110. These direct relationships may be stored in a direct relationship table. In one embodiment, the transitive relationship tool 1420 selects each row in the direct relationship table. For each field referred to in the relationship definition, the transitive relationship tool 1420 may search every other row in the direct relationship table for a match. If a match is found, a new relationship is created to reflect the commonality. For example, if a direct relationship is defined between field A and field B, the transitive relationship tool 1420 may search the other rows of the direct relationship table for a match on field A. If a match is found, for example, relating field A to field C, the transitive relationship tool 1420 may create a transitive relationship relating field B to field C. This is an example of a single hop transitive relationship. Preferably, the transitive relationship tool 1420 uses a search depth algorithm to calculate the transitive relationships across n hops. In one embodiment, the transitive relationship may be stored in a transitive relationship table. Alternatively, the transitive relationship may be stored in the same table as the direct relationships. In one embodiment, the transitive relationship definition includes information detailing each hop from the two related entities.
The relationship generation tool 550 may also include a proximity relationship tool 1430. Similar to the field-to-text relationship tool 1410, the proximity relationship tool 1430 searched the text of either fields in the knowledge model 140 or unstructured files, such as articles. The proximity relationship tool 1430 creates a proximity relationship if two entities appear in the same text. In one embodiment, indexes are created for all the text to be searched (i.e. specific field values or unstructured data items). The indexes are then used to determine if two entities appear in the same text. Alternatively, or in addition to, the proximity relationship tool 1430 may be configured to generate a proximity relationship if the entities appear within a given proximity of each other in the text, for example, within n words of each other. Other criteria, such as each field appearing at multiple instances within each document, each field appearing in the same sentence, and the like, may also be used to define a proximity relationship. It should be apparent to one of ordinary skill in the art that the determination of a proximity relationship may be dependent on the type of file being examined. For example, if a text file is be used, a proximity relationship may be generated if the words fields appear within the same paragraph. If, however, the file being searched is a spreadsheet, the proximity relationship tool 1430 may generate a proximity relationship if the two fields appear in same cell, row, or column. In one embodiment, the proximity relationship tool 1430 stores the proximity relationship definition as well as information detailing the rationale behind the generation of the relationship. For example, to define a proximity relationship between two fields, the proximity relationship tool 1430 may store each field, the criteria used to determine the relationship, and the article or reference in which the use of the fields met the given criteria.
Referring to
In the embodiment of
Referring now to
The ToolTipPanel component 1604, 1704 may include summary and supporting attribute information about an Item. In one embodiment, ToolTipPanel components 1604, 1704 are implemented as pop-up boxes that appear when a user mouses-over an Item. For example, a ToolTipPanel component 1604, 1704 for an Item describing a person might contain their age, level within their company, hire date, email address, and the like. In one embodiment, the ToolTipPanel component 1604, 1704 associated with the active Item may be permanently displayed below the Item name.
The EntityPanel component 1606, 1706 includes information corresponding to an entity of the knowledge model 140. In the embodiment of
Referring now to
As described above, the navigator tool 170 may be implemented as a graphical user interface that allows the user to select a record or item from one of a table of the knowledge model 140 and, in response to the selection, display a set of related items or records. In the embodiment of
The remaining entity components 1832 may be used to display those related items 1840 in the knowledge model 140 related to the active node 1838, for example, by displaying the name of the related item 1840. Optionally, indicia of the link type associating each related item 1840 to the active node 1838 may be included. In the embodiment of
Each entity component 1832 is associated with a particular table of the knowledge model 140. In one embodiment, each entity component 1832 displays all the related items 1840 for the associated table of the knowledge model 140. Preferably, the user will be allowed to select the type of entity being displayed in any particular entity component 1832 by associating that entity component 1832 to any table in the knowledge model 140. In such an embodiment, the user may configure the entity components 1832 to display the tables of interest to that particular user. Preferably, the associations of entity components to knowledge model 140 tables may be stored.
In one embodiment, each entity component 1832 may be configured to display a set number of item 1840 at a given time. In such an embodiment, navigation tools, such as a scroll bar or navigation arrows, may be provided to allow the user to access the entire list of related items 1840. Additionally, the entity component 1832 may include node 1840 count information to inform the user of the additional though not visible items 1840. Preferably, the entity component 1832 also includes information describing which related items 1840 of the set are currently being displayed. For example, the entity component 1832 may show that items 1840 three through nine of eighty-six total items 1840 are currently being displayed. In such an embodiment, a scrollbar or other user-interface control may be included to provide access to the items 1840 not being displayed.
Optionally, the entity component 1832 may include tools to manipulate the related items 1840 contained therein. In the embodiment of
As described above, each entity component 1832 may be associated with an entity type of the knowledge model 140. In one embodiment, the user may change the entity table associated with any entity component 1832 that displays related items 1840. As shown in
In one embodiment, the activation of a particular related item 1840 may cause additional information about that item 1840 and its relationship to the active item 1838 to be displayed. As shown in
Additionally, or alternatively, a relationship line 1852 between the related item 1840 and the active item 1838 may also be displayed upon activation of the related item 1840. In the embodiment of
As shown in
As shown in
Finally, the user may wish to see information on why a particular related item 1840 is considered related to the active node 1838. To do so, the user may select the show link evidence option from the pop-up menu 1854. Depending on the type of link establishing a connection between the active node 1838 and the related node 1840, different link information may be shown. For example, link information for field-to-field links may include the data source from which the link was extracted. Link information for field-to-text links may include a short part or clip of the literature text that surrounds the keyword. In one embodiment, the clip length should user configurable. Preferably, the clip length may be initially set to be N words total, such that (N−1)/2 words preceding the item keyword and (N−1)/2 words following the item keyword are included. For example, if the clip is set to 31 words, the clip may include the 15 words preceding and following the item keyword. For transitive links, the link information may include each field-to-field link information for each hop included in the link. Finally, link information for proximity links may include the title of the article which mentions both items, as well as a clip for showing each item in context.
As described above, the navigator tool 170 may include a navigation toolbar 1810. One embodiment of the navigation toolbar 1810 is shown in
The navigation tool 170 provides basic navigational functions via the navigation buttons. For example, the back button 1910 and forward button 1912 may be provided to allow the user to step through their recent navigation history backwards and forwardly, respectively. Activating the stop button 1914 may cancel the submission of a query to the knowledge model 140. In one embodiment, a command is issued to the knowledge model 140 to abort query processing. Preferably, all current client and server processing activity is stopped. Activating the refresh button 1916 may allow the user to manually refresh their current view (for example, by resending a query to the knowledge model 140) and update the display of related item 1840 based on the new results. A home button 1918 may be provided that takes the user to their home view (i.e. home item). The home view is a set node. The home view may be user customizable.
A history dialog button 1920 may also be provided to launch a history dialog window. One embodiment of a history dialogue window is shown in
Upon selection of the signoff button 1922, the user may be logged out of the navigator tool 170. Upon selection of the help button 1924, the user may be provided access to a help system, as known in the art. In one embodiment, selection of the help button 1924 may cause an html based help system to be launched in a separate window. A window containing information about the knowledge discovery tool 100 or navigator tool 170 may be opened upon selection of the about button 1926. This information may include version information, such as a revision number, intellectual property information, such as copyright, patent and/or licensing information, and the like.
The options button 1944 may launch the master options dialog. One embodiment of the master options dialog 2100 is shown in
The startup view preference 2110 allows the user to select what they want to see upon starting the navigator tool 170. In one embodiment, three options are provided: search, last item visited and home item. If the search option is selected, the navigator tools 170 opens with a search dialog, discussed below in more detail. If the last item visited option is selected, the navigator tool 170 opens with the active node 1838 from when the navigator was last closed. In one embodiment, all filter, confidence, and entity component 1832 association settings may also be preserved. Filter and confidence settings are described in more detail below. Finally, if the home item option is selected, the navigator tool 170 will open with the home item as the active node 1838. Preferably, the home item startup option is the default option and the home view is set to a standard node.
The navigation history preference 2120 defines the number of navigation events stored for the navigation session. In one embodiment, the default value is set to 10. Alternatively, or in addition to, the navigation history preference 2120 may have a maximum value, for example, 30 events. Preferably, the navigation history preference 2120 is implemented as a drop down box.
The related items limit preference 2130 controls the number of records which can be returned to each entity panel 1932 in the navigator tool 170 from a query. In one embodiment, a default value is selected to optimally balance performance and quality of the results returned.
The animations preference 2140 may allow the user to enable or disable animation rendering effects in the user interface. Preferably, the animations preference 2140 is implemented as a checkbox and is selected by default. An ok button 2150 may be provided to accept the currently selected preferences, and a cancel button 2160 may be provided to close the dialog 2100 without changing preferences.
Referring again to
To begin a search, the user may click the find button 2212. In response, the system 100 performs a free-text search against the information stored in the knowledge model 140. When the search is complete, the results are shown in the Search Results field 2230. In one embodiment, the search results include a description 2232 of the item and the entity table 2234 to which it belongs. The user may also be able to view more detailed information in the description field 2240 by selecting the item from the list. In one embodiment, the selection of an item is made via a single click on any of the search results. The results may be sorted by name or by type by clicking on the header of the appropriate fields 2232 and 2234. The user may be able to view the source of a particular search result by clicking the View Web Page button 2250. The Show button 2252 shows the selected item in the navigation window, making it the active node 1838. Alternatively, or in addition to, the user may double-click a particular search result to make that item the active item 1838. The Close button 2254 will close the search dialog box.
Referring again to
Optionally, bookmarks 2312 may be organized into folders much like computer files or internet bookmarks are managed. In one embodiment, the user may create a folder by clicking the right mouse button over the folder under which you want to create your new folder and selecting a “Create folder” option from a popup menu. Folders may also be renamed using a similar procedure as renaming bookmarks 2312 described above. A folder may also be deleted in a similar manner. Once a folder has been created, the user may organize bookmarks 2312 by dragging the bookmark 2312 (i.e., hold the left mouse button over the bookmark and move your mouse) to the folder. Folders may also be hierarchically arranged in a similar manner. In one embodiment, clicking a folder will alternatively show or hide the contents of that folder.
Optionally, bookmarks 2312 may be shared among users. In one embodiment, the system 100 may notify users of a common interest in particular item if one or more colleagues have the same bookmark 2312 by creating a special bookmark that is added to each users list 2310. Selection of this special bookmark may open a shared bookmarks tool. One embodiment of a shared bookmarks tool 2320 is shown in
Referring again to
Exemplary screen shots of a wizard service are shown in
Next, matching terms are searched and allow user to select one or more matching terms to augment or refine search parameters. An exemplary process for determining additional keywords for diseases is shown in
Next, the user may choose to augment the search to include additional keywords from topics such as genes 2430, proteins 2432, and pathways 2434, as shown in
The result of this first stage is a collection of keywords that are related by the knowledge model 140. At this point, the user may be prompted to validate the scope of the search, as shown in
Once all the terms have been finalized, the wizard submits the query and collates the results. In one embodiment, these keywords may be searched against project and literature databases, for example, by submitting search strings to the database search indices to find, for example, projects and literature that match the list of relevant terms. The wizard service may return a set of projects/literature that match the set of query terms. Preferably, the query terms may be ranked and organized by the number of relevant search terms that were found in each search result. Thus, a results list of pointers to projects and literature that mention the keyword combinations within the analysis scope may be created.
Finally, the user reviews the results identified to review potentially applicable projects and literature and compounds, as shown in
Referring again to
Referring again to
An exemplary filters dialog 2600 is shown in
The user may also be able to filter displayed literature items to those items found in particular journals. An exemplary screen shot of a journal fitler options page is shown in
Referring again to
A context drop down list 1942 may be included to provide the user with a list of previously saved, or system provided, stored sets of context. A context represents a set of navigator tool settings. In one embodiment, a context includes filter settings, confidence filter settings, and panel layouts. Alternatively, or in addition to, the context drop down list 1942 may also provide access to personal and group default preferences sets associated with login information. Upon selection of a context set, the navigator tool 170 will update the current display to reflect the newly selected context. Alternate context sets containing various sets of information should be readily apparent to one of ordinary skill in the art. For example, master context information may also be stored in a context set. The context drop down list 1942 may display a list of stored preference sets by name. In one embodiment, a user may save a new context by selecting a “save new” option from the context drop-down list 1942.
It is therefore intended that the foregoing detailed description be regarded as illustrative rather than limiting, and that it be understood that it is the following claims, including all equivalents, that are intended to define the spirit and scope of this invention.
The present patent document is a continuation-in-part of application Ser. No. 11/051,745 filed Feb. 4, 2005 now abandoned, the entire disclosure of which is hereby incorporated by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5265065 | Turtle | Nov 1993 | A |
| 5276805 | Hamaguchi | Jan 1994 | A |
| 5499334 | Staab | Mar 1996 | A |
| 5506984 | Miller | Apr 1996 | A |
| 5535325 | Cattell et al. | Jul 1996 | A |
| 5590250 | Lamping et al. | Dec 1996 | A |
| 5608900 | Dockter et al. | Mar 1997 | A |
| 5619632 | Lamping et al. | Apr 1997 | A |
| 5644740 | Kiuchi et al. | Jul 1997 | A |
| 5659724 | Borgida et al. | Aug 1997 | A |
| 5745895 | Bingham et al. | Apr 1998 | A |
| 5768578 | Kirk et al. | Jun 1998 | A |
| 5794257 | Liu et al. | Aug 1998 | A |
| 5801702 | Dolan et al. | Sep 1998 | A |
| 5949968 | Gentile | Sep 1999 | A |
| 5953723 | Linoff et al. | Sep 1999 | A |
| 5956688 | Kokubo et al. | Sep 1999 | A |
| 5960430 | Haimowitz et al. | Sep 1999 | A |
| 5965688 | Davies | Oct 1999 | A |
| 5983218 | Syeda-Mahmood | Nov 1999 | A |
| 5995959 | Friedman et al. | Nov 1999 | A |
| 5995961 | Levy et al. | Nov 1999 | A |
| 6012055 | Campbell et al. | Jan 2000 | A |
| 6018735 | Hunter | Jan 2000 | A |
| 6031537 | Hugh | Feb 2000 | A |
| 6035300 | Cason et al. | Mar 2000 | A |
| 6037944 | Hugh | Mar 2000 | A |
| 6038668 | Chipman et al. | Mar 2000 | A |
| 6052693 | Smith et al. | Apr 2000 | A |
| 6134559 | Brumme et al. | Oct 2000 | A |
| 6141662 | Jeyachandran | Oct 2000 | A |
| 6166736 | Hugh | Dec 2000 | A |
| 6166739 | Hugh | Dec 2000 | A |
| 6233571 | Egger et al. | May 2001 | B1 |
| 6236994 | Swartz et al. | May 2001 | B1 |
| 6256032 | Hugh | Jul 2001 | B1 |
| 6289353 | Hazlehurst et al. | Sep 2001 | B1 |
| 6330007 | Isreal et al. | Dec 2001 | B1 |
| 6356897 | Gusack | Mar 2002 | B1 |
| 6397231 | Salisbury et al. | May 2002 | B1 |
| 6425525 | Swaminathan et al. | Jul 2002 | B1 |
| 6434556 | Levin et al. | Aug 2002 | B1 |
| 6434558 | MacLeod et al. | Aug 2002 | B1 |
| 6446061 | Doerre et al. | Sep 2002 | B1 |
| 6446076 | Burkey et al. | Sep 2002 | B1 |
| 6460034 | Wical | Oct 2002 | B1 |
| 6487545 | Wical | Nov 2002 | B1 |
| 6499026 | Rivette et al. | Dec 2002 | B1 |
| 6564209 | Dempski et al. | May 2003 | B1 |
| 6581058 | Fayyad et al. | Jun 2003 | B1 |
| 6582474 | LaMarca et al. | Jun 2003 | B2 |
| 6721726 | Swaminathan et al. | Apr 2004 | B1 |
| 6727927 | Dempski et al. | Apr 2004 | B1 |
| 6840442 | Swaminathan et al. | Jan 2005 | B2 |
| 6900807 | Liongosari et al. | May 2005 | B1 |
| 6957205 | Liongosari | Oct 2005 | B1 |
| 6996774 | Liongosari et al. | Feb 2006 | B2 |
| 7000032 | Kloba et al. | Feb 2006 | B2 |
| 7031961 | Pitkow et al. | Apr 2006 | B2 |
| 7047236 | Conroy et al. | May 2006 | B2 |
| 7099854 | Liongosari | Aug 2006 | B2 |
| 7240051 | Imaichi et al. | Jul 2007 | B2 |
| 7321886 | Swaminathan et al. | Jan 2008 | B2 |
| 7383269 | Swaminathan et al. | Jun 2008 | B2 |
| 7499046 | Wright et al. | Mar 2009 | B1 |
| 7502770 | Hillis et al. | Mar 2009 | B2 |
| 20020007284 | Schurenberg et al. | Jan 2002 | A1 |
| 20020046296 | Clubbie et al. | Apr 2002 | A1 |
| 20020065856 | Kisiel | May 2002 | A1 |
| 20030182310 | Charnock et al. | Sep 2003 | A1 |
| 20040015486 | Liang et al. | Jan 2004 | A1 |
| 20040090472 | Risch et al. | May 2004 | A1 |
| 20040122689 | Dailey et al. | Jun 2004 | A1 |
| 20040186824 | Delic et al. | Sep 2004 | A1 |
| 20040186842 | Wesemann | Sep 2004 | A1 |
| 20040267729 | Swaminathan et al. | Dec 2004 | A1 |
| 20050043940 | Elder | Feb 2005 | A1 |
| 20050060643 | Glass et al. | Mar 2005 | A1 |
| 20050065930 | Swaminathan et al. | Mar 2005 | A1 |
| 20050108200 | Meik et al. | May 2005 | A1 |
| 20050149538 | Singh et al. | Jul 2005 | A1 |
| 20060179024 | Bechtel et al. | Aug 2006 | A1 |
| 20060179025 | Bechtel et al. | Aug 2006 | A1 |
| 20060179026 | Bechtel et al. | Aug 2006 | A1 |
| 20060179027 | Bechtel et al. | Aug 2006 | A1 |
| 20060179067 | Bechtel et al. | Aug 2006 | A1 |
| 20060179069 | Bechtel et al. | Aug 2006 | A1 |
| 20070156677 | Szabo | Jul 2007 | A1 |
| 20080147590 | Bechtel et al. | Jun 2008 | A1 |
| 20080281841 | Swaminathan et al. | Nov 2008 | A1 |
| 20090019391 | Bechtel et al. | Jan 2009 | A1 |
| Number | Date | Country |
|---|---|---|
| 0 902 380 | Mar 1999 | EP |
| 0 950 964 | Oct 1999 | EP |
| 0 902 380 | Nov 1999 | EP |
| 0 950 964 | Nov 1999 | EP |
| 1039265 | Sep 2000 | EP |
| 1667034 | Jun 2006 | EP |
| 1667034 | Jun 2006 | EP |
| 1667034 | Feb 2007 | EP |
| WO 9738376 | Oct 1997 | WO |
| WO 9738376 | Dec 1997 | WO |
| WO 9857277 | Dec 1998 | WO |
| 0137120 | May 2001 | WO |
| WO 0137120 | May 2001 | WO |
| WO 0221259 | Mar 2002 | WO |
| WO 02071273 | Sep 2002 | WO |
| WO 03069506 | Aug 2003 | WO |
| WO 03069506 | Aug 2003 | WO |
| WO 02071273 | Nov 2003 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20060179027 A1 | Aug 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11051745 | Feb 2005 | US |
| Child | 11128427 | US |
