Patent Grant
7054854
This application is based upon and claims the benefit of priority from the prior Japanese Patent Application No. 11-330236, filed Nov. 19, 1999, the entire contents of which are incorporated herein by reference.
The present invention relates to a structured document search method for searching based on a search request including a document logical structure, with respect to a structured document database having the logical structure, a structured document search apparatus and a structured document search system.
Keyword designation is one of method for designating a search request with respect to a document database. In this method, when a user requests a search to the document database in a format of keyword string, a group of documents including the keyword string is returned.
Such a simple and primitive search request method is largely applied to the full text search engine or the like; therefore, there is (1) an accuracy problem that a practically unnecessary group of documents is searched, and (2) a granularity problem that the document containing data other the portion to be used is a data unit.
Recently, structured document codes for structured document such as SGML (Standard Generalized Markup Language) or XML (extensible Markup Language) have been proposed, allowing to realize (1) a search more accurate than the conventional keyword search, and (2) a fine search for obtaining data of the portion to be used, through the designation of search request based on the document structure. However, in this case, the document structure should be unified beforehand to a fixed one, and inconveniently, it is impossible to change the document structure afterward, or to change the document structure for each data.
On the other hand, RDB (Relational DataBase) allows to designate a search request based on the table structure by SQL language. “SQL” is a RDB inquiry language standardized in ANSI X3, 1 and ISO/TC97/SC21/WG3 N117 (1987). However, it is difficult to convert a document structure as it is into a table format, and RDB can not be used as it is as a document database.
Further, a method for applying search languages used in OODB (Object Oriented DataBase) for structured document database such as SGML or XML may be devised. As the structured document has a hierarchical structure, it is considered to be highly compatible with OOBD which takes each component as object. Howsoever, in OODB, the document structure should be decided beforehand by the schema, it is difficult to model by object model, such as arbitrary repetition of child element, and an object-oriented database can not be used as it is as document database.
To resolve such inconveniences, for the document repository, it is proposed to equip SQL with a language processing section to which an expanded function appropriate for the structured document is added. The expanded function appropriate for the structured document includes, first, the path specification for specifying a component in a hierarchical structure. Further, functions expanded based on SQL comprise ambiguous path specification including ambiguities such as regular expression in a path for specifying a component in a hierarchical structure, structure pattern for specification for specifying the pattern of a hierarchical structure, or other functions for absorbing the structural fluctuation proper to the structured document.
There are Jpn. Pat. Appln. KOKAI Publication No. 6-203078, Jpn. Pat. Appln. KOKAI Publication No. 6-301721 and Jpn. Pat. Appln. KOKAI Publication No. 11-15843, proposing methods allowing to specify the search request provided with these characteristics, and to process the search.
Jpn. Pat. Appln. KOKAI Publication No. 6-203078 (information search method and apparatus thereof) proposes a method for storing a path assembly wherein the hierarchical structure is fully developed into the RDB as string table. To search for a structured document, a component in the hierarchical structure is specified by issuing SQL for string comparison of a path in the string table with a search statement's ambiguous path. A problem of this method is that the size of the string table fully developing the hierarchical structure becomes huge, when the number of registered document increases.
Jpn. Pat. Appln. KOKAI Publication No. 6-301721 (full text database search method) proposes a method for deciding the component type beforehand, and making that hierarchical structure's parent-child relationship or links to the actual data RDB for each component as structural information. During the structured document search, the search request is converted into SQL statement. A problem of this method is that the computation amount required for a search processing becomes huge, when the number of registered document increases and the depth and width of hierarchy tree increase, because this search processing method begins from the root element, develops from a parent element to a group of child elements and specifies a component in a hierarchical structure. As the development processing is performed by binding RDB, an unimaginable response time is expected for an implementation system. Especially, this trend becomes remarkable, when an ambiguous path is specified.
Jpn. Pat. Appln. KOKAI Publication No. 11-15843 (SGML document search apparatus and SGML document search method) also decides the component type beforehand, and a document table wherein data is string joined for each component type is established. During the structured document search, the search request is converted into SQL statement. A problem of this method is that it can not be specified but the single stage level path, because data is simply string joined for each component type. Another inconvenience is that the document structure should be decided beforehand, and a flexible search request corresponding to the hierarchical structure that a document possesses can not be issued, and the like.
These methods do not limit the computation amount required for the search processing by combining an index for the data and an index concerning the structure conveniently, making the mechanism difficult to adopt the optimization like as RDB.
As described above, in the prior art, it was difficult to meet, at the same time, two requests in trade-off relationship: (1) to specify various searches for the hierarchical structure a document may possess (including ambiguous path), and (2) to restrict the computation amount required for the search processing.
In view of the aforementioned problems, an object of the present invention is to provide a structured document search method allowing to specify various searches for the hierarchical structure including ambiguous paths that a document possesses, without increasing the computation amount required for the search processing, a structured document search apparatus and a structured document search system.
Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out hereinafter.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate presently preferred embodiments of the invention, and together with the general description given above and the detailed description of the preferred embodiments given below, serve to explain the principles of the invention.
An embodiment of the present invention will be described referring to the accompanying drawings.
Structured documents to which the present invention can be applied include, for example, documents described in SGML (Standard Generalized Markup Language) or XML (extensible Markup Language). SGML is a standard specified by ISO (International Organization for Standardization). XML is a standard specified by W3C (World Wide Web Consortium). They are respectively structured document codes allowing to structure the document.
Tag is used for representing the structure of a document using SGML or XML. Tags includes a start tag and an end tag, and sentence ends in a document and the structural assignment of that document to a component are clarified by surrounding the component of document structure information with start tag and end tag. Here, the start tag is an “element name” closed by symbols “<” and “>”, while the end tag is a “element name closed by symbols “<” and “/>”. The component contents following the tag are repetition of texts or child components. Besides, the attribute information such as “<element name attribute=“attribute value”>” can be set in the start tag.
Now, concrete examples shall be described using XML.
As concrete example of database contents, information concerning patent application shall be used and as concrete example of search, information concerning patent application shall be used. Note that the term “patent” in the description using concrete examples shall mean “(those) concerning the patent application”.
This system comprises a request control section 1, a storage processing section 2, a search processing section 3, a data file 4 and an index file 5.
This system configuration can be realized using software. Here, data file 4 and index file 5 are composed, for example, by using external memories.
The request control section 1 is a processing section for processing requests to the structured document database such as search request or storage request from the user, and for delivering the processing to or search processing section 3. Search request or storage request are received as message by the request reception section 11. A request processing section 12 classifies the received message into search request or storage request, and calls the search processing by the search processing section 3 or the storage processing by the storage processing section 2. On the other hand, search results delivered form the search processing section 3 is formatted by a result processing section 13 and returned to the original user.
The search processing section 3 is a processing section for analyzing the search request and generating search results satisfying the search request. A search request syntax analysis section 31 cuts out words and phrases from the search request and extracts the structure of request statement, and a search graph generation section 32 generates search graphs. A search plan generation section 33 generates a search plan from the generated search graphs, and a search plan execution section 34 executes the generated search plan and generates search results satisfying the search request. The search results are delivered to the request control section 1.
The storage processing section 2 is a processing section for analyzing the storage request and storing the structured document. A storage request syntax analysis section 21 cuts out words and phrases from the structured document and extracts the structure of structured document. A data storage section 22 stores structured document data or structure data in the data file 4, and an index storage section 23 stores index of structured document data or structure data in the index file. Index file creation/update may be performed for each input of structured document to be stored or together conveniently (the former is preferable for the search efficiency).
The “name” information surrounded by “name” tags, “applicant” information surrounded by “applicant” tags, “application No.” information surrounded by “application No.” tags, “filed date” information surrounded by “filed date” tags, “abstract” information surrounded by “abstract” tags, and “keyword” information surrounded by “keyword” tags are recorded at a position surrounded by “patent” tags (namely, a pair of <patent> and </patent>; the same meaning for elsewhere).
The “filed date” information is further composed “year” information surrounded by “year” tags, “month” information surrounded by “month” tags, and “date” information surrounded by “date” tags. Here, the “filed date” information may comprise further “era” information. Otherwise, the “year” information may be expressed by the Christian Era.
As “keyword” information, a single or a plurality of them can be specified (in the example of
As this “keyword” information, structured a document such as XML may contain repetition of arbitrary component, or the document structure is not decided beforehand (can not be defined by schema definition of RDB or OODB).
The “patent” information may contain “publication No.” information, “patent No.” information, or other various information.
The example of “concept” information of
The concept hierarchy description example of
The structured document database gathering structured documents specifies to be stored in hierarchy as, for example, UNIX directory structure.
Each node (numbered and indicated by a circle in
The partial hierarchy tree under an arbitrary D node indicates a structured document cut out from the structured document database.
An object ID (described in the circle in
In the example of
In the example of
The “patent information” illustrated in
The partial hierarchy tree under the “#639” D node also corresponds to the “patent” information, however, viewed from the root D node, “#902” D node and “#639” D node are different in the depth of hierarchy depth. Thus, the hierarchy relation form the root D node to the D node corresponding to the “patent” information can be set arbitrarily.
In other words, as shown in
As shown in
Two variables of storage destination “root/IR patent” and storage data “<patent> . . . (middle omitted) . . . </patent>” exist behind the command name “Insert”. This description means that, as storage destination, the storage data “<patent> . . . (middle omitted) . . . </patent>” is inserted into the leading element of the partial hierarchy tree having “IR patent” tag at the leading head, following from the partial hierarchy tree having “root” tag at the leading head. “root/IR patent” is called “document path”.
The partial hierarchy tree under the “#902” D node of the conceptual structure shown in
The storage request having “Insert” command name is received at the request control section 1 of
The example of
“Where” phrase indicates the condition portion, “From” phrase indicates the document path specification portion, and “Select” phrase indicates the information extraction portion. “$1” and “1$2” are data binding variables.
If the fore of an element name begins with “*” like “<*/patent>”, it can match with an arbitrary descendant “patent” of the specified document path. An ambiguous path such as “root/*/patent” corresponds to a ‘search request to search for “patent” information generated at an arbitrary portion of the hierarchy tree’.
For instance, in
This example means a search request ‘to extract “application No.” information about the “patent” information having an element value coinciding with the contents belonging to the concept “document” (concept name attribute value (string), in
In this example, the same variable “$x2” is allocated respectively to “keyword” and “name”, referring to two kinds of information of, “patent” information and “concept” information. This means the coupling processing of two kinds of information.
For instance, in
This example means ‘to extract “application No.”, “information model” axis, and “information operation” axis, by setting two classification axis of the classification in the concept “information model” and the classification in the concept “information operation”, for “patent” information appearing in the structured document database, and search them as “bibliography” information’.
In this example, the same variable “$x2” is allocated respectively to “keyword” and “name”, referring to two kinds of information, “patent” information and “concept” information. This means also the coupling processing of two kinds of information.
A processing to search for “patent” information wherein “keyword” information “$x2” matches with the “concept” information of an arbitrary descendent of the concept “information model” under the document path “root”, and to make “$x3” by substituting with one child concept of the concept “information model” is integrated in the portion of extracting “information model” axis. A processing to search for “patent” information wherein “keyword” information “$x2” matches with the “concept” information of an arbitrary descendent of the concept “information operation” under the document path “root”, and to make “$x4” by substituting with one child concept of the concept “information operation” is also integrated in the portion of extracting “information operation” axis.
For instance, in
The search request shown in
As mentioned before, two classification axis of the classification in the concept “information model” and the classification in the concept “information operation” are set for “patent” information, assembled with “application No.” information, and displayed as “bibliography” information list. For example, in the first “bibliography” information, it means that ‘the patent of “Patent Application HEI 10-xxxxxx” is classified by “document”דsearch”’.
Now, the processing in the search processing section 3 will be described.
As shown in
In
The G node shown by a circle is the G node representing a variable, and has a string beginning with “$_”. G nodes representing a variable can be classified into variables generated inside, and other variables included in Select statement of search request such as “$x1”.
G node shown by a hexagon is composed of G node of “QUERY”, G node of “AND”, G node of “TAG”, G node of “ATT(ribute)” or G node of “ALV(ue)”.
“Query” G node corresponds to the whole Select statement of search request such as in
As an example, the condition ‘arbitrary “patent” information under the specified document path “root”’ is represented by three “TAG” nodes (G node string having “root”, “*”, “patent”). The variable G node linking two “TAG” G nodes (for instance, “$—1” and “$—2”) are variables that can be bound by D node shown in
“ATT” G node and “VAL” G node represent a relation between attribute and element data.
Besides, a plurality of links are connected to the G node shown by a hexagon.
“QUERY” G node has op1 link connected to “AND” and op2 link group connected to “TAG”.
“AND” G node has op1 link connected to “QUERY” and op2 link group connected to “TAG” group.
“TAG” G node has op1 link (left side) connected to rank higher G node, op2 link (under side) connected to data and op3 link (right side) connected to rank lower G node.
“ATT” G node has op1 link (left side) connected to rank higher G node, op2 link (right side) connected to data and op3 link (under side) connected to rank lower G node.
“CON” G node has op1 link connected to “QEUERY” and op2 link group connecting to “TAG”.
“VAL” G node has op1 link (left side) connected to rank higher G node, and op2 link (under side) connected to rank lower G node.
Besides, G nodes representing variable (G node shown by a circle) have link groups connected to the other G node groups.
In the example of
Also, G nodes rank lower than “CON” G node corresponding to Select phrase form a network. “patent” information is composed of “application No.” information, “classification” information whose “axis” attribute is “information model”, and “classification” information whose “axis” attribute is “information operation”. The variable value of variable G nodes such as “$x1”, “$x3” or “$x4” is decided after Where phrase, which is “AND” node is processed, and they are bound to give results shown in
Search graphs as shown in
Now, index files will be described.
Here, an element name occurrence index means an index file created by associating the element name list stored in the structured document database, and the location of structured document whose element name is generated at the leading head.
For instance, if an element name “patent” (corresponding to “patent” information) is generated in the structured document indicated by D node group “#902”, “#639”, . . . , as in the structured document database of
When it is thus indexed by the parent D node, the index file size can be compressed. In other words, when it is indexed by the parent D node, the chain size does not increase even if the child D node attempts to increase, because it is replaced by the parent D node. On the contrary, if the actual D node is indexed, the chain size increases in proportion to the increase of the number of stored “patent” documents.
Here, an data creation index means an index file created by associating the data list stored in the structured document database, and the location of structured document whose data is generated at the leading head.
For instance, if a string data “search” is generated in the structured document indicated by D node group “#912”, “#647”, “#650”, as in the structured document database of
Reverse hierarchical index or other index file may be used. Reverse hierarchical index is one storing the correspondence of a certain node and its parent node (the parent node can be determined from one node).
Now, the search plan generation according to the characteristic point of the present invention will be described.
The plan generation rule 6 shown in
A candidate G node registration section 331 registers the respective G nodes constituting search graphs as illustrated in
A G node rule ignition check section 332 checks the application of plan generation rule to each G node constituting the candidate G node list.
A plan generation application section 333 extracts a pair of least cost G node and plan generation rule, for each G node to which the plan generation rule can be applied, and executes the plan generation rule. An execution plan as a result of executing the plan generation rule is added to the execution plan list 335.
Further, a group of variable G nodes whose value have chance to be materialized by the plan generation rule is registered in a candidate G node list 334 by the candidate G node registration section 331.
The processing mentioned above is repeated until the candidate G node list 334 becomes empty.
As described above, the plan generation rule is applied to each element of the search graph, by using a plan generation rule base 6, and as the result of application, the plan generation rule is applied again to each element of the affected search graph. A more effective search plan can be realized by going round search graphs in propagation like this.
Also, the generated search plan may be executed after the completion of generation of all search plans. Otherwise, the generation of a single search plan and the execution of that search plan can be executed continuously as a block, and the execution may be repeated (namely, the search plan generation and its execution is repeated alternatively).
Now, the detail of plan generation rule will be described.
Each rule includes attributes of rule No, applicable G node class, application cost, application rule (IF) section, and action (THEN) section.
The cost takes for instance a float value equal or less than and equal or more than 1. The magnitude of cost influences extremely the computation cost.
In the application (IF) section, OP1 to 3 represent the aforementioned link. In
The portion “Other” in the application (IF) section indicates the other application conditions. For example, “an element name occurrence index exists in OP2” in the rule number “03” supposes, as application rule, that an element name agreeing with the materialized variable value of that OP2 exists in the element name occurrence index.
The operator in the action (THEN) section indicates the action to be executed by the search plan execution section 34 as described in detail below.
In
In addition, for example, the rule number “02” indicates that it is applicable to “TAG” G node and the cost is 0.5. Moreover, the application condition is that ‘the variable G node of op1 link is materialized, the variable G node (including data) of op2 link is materialized, and the variable G node of op3 link is not materialized’. Also, it indicates that ‘the action is “to generate the execution plan PATHEXPAND1”’.
Now, the execution of a search plan generated by the search plan generation section 33 will be described.
The search plan execution section 34 extracts (fetches) a item from the input execution plan lists one by one (processing 341), executes the fetched plan (processing 342) and obtains the search result 13 by repeating these two steps of processing.
The details of the operator group applied selectively in the execution of fetched search plan are as follows.
[1] PATHINST: fetch the document path “root”.
[2] PATHEXPAND1: obtain D node group matching with the key from rank higher D node group using the specified element name as key.
[3] PATHEXPAND2: obtain parent and child D node group generated in the structured document database, by using the indexed element name as key.
[4] PATHEXPAND3: obtain parent D node from child D node, by using the indexed element name as key.
[5] PATHCHECK: when two D node assemblies are given, obtain a combination of two D nodes in parent-child relationship by the element name specifying them.
[6] JOIN: execute join operation when the materialization progresses from a plurality of G nodes where the variable G node x connects by op link, and are superpose at x.
[7] VALUE: obtain element data candidate of variable G node x.
[8] SELECT: execute comparison operation when element data for variable G node x is selected.
[9] FIND: obtain indexed element data candidate.
First, the candidate G node list 334 and the execution plan list 335 are initialized as empty list (step S1).
All of G nodes constituting the search graph are registered in the candidate G node list 334 (step S2).
Intermediate variable rset is initialized as empty list (step S3).
Terminate the search plan generation (step 41) if the candidate G node list 334 is empty (step S4).
If the candidate G node list 334 is not empty (step S4), repeat Step 51 to Step 54 for each component x of not empty candidate G node list 334 (step S5).
Refer to the plan generation rule 6 composed in the aforementioned table format, and search a group of plan generation rules applicable to the component x (step S51).
Select the plan generation rule group satisfying IF section from the searched plan generation rule group (step S52).
If there exist no plan generation rule group (step S53), delete the component x from the candidate G node list 334 (step S531).
If there exists a group (step S53), apply the step S53 to each plan generation rule r (step S54).
In the step S541, cost c of plan generation rule r is calculated, and <x, r, c> is added to rset.
Next, select element <x1, r1, c1> having the minimum cost c for each element <x, r, c> of rset (step S6). Here, the prescribed items are registered in the execution plan list 335.
Delete the component x1 from the candidate G node list 334 (step S7).
Execute the plan generation rule r to the component x1, add updateable G nodes (connected by op1, op2, or the like) to the candidate G node list 334, and return to the step S3 (step S8).
Now, the procedure from search graph generation, to generation and execution of search plan will be described, with concrete examples of search command to the structured document database.
“$1” variable G node indicates a ‘G node variable for D node equal or less the specified document path “root” and rank higher in hierarchy than “$2” variable G node’.
“$2” variable G node indicates a ‘G node variable for D node existing rank lower in hierarchy than “$1” variable G node, and beginning with “patent” element name’.
“$3” variable G node indicates a ‘G node variable for D node which is a child of a D node beginning with “patent” element name viewed from “$2” variable G node, and beginning with “name” element name’.
“$4” variable G node indicates a ‘G node variable for D node which is a child of a D node beginning with “name” element name viewed from “$3” variable G node, and having G node variable “$x1” for D node indication an element data’.
“$x1” variable G node indicates ‘G node variable for D node indicating an element data viewed from “$4” variable G node, and including a string “search”’.
Thus, G nodes have a polynomial restriction relation of two terms or more among them and resolve by satisfying the restriction the combination of values that these D node groups can take.
The search plan of
For generating this plan, it is supposed as follows as premise of structured document database.
After all G nodes of the search graph are registered in the candidate G node list 334, a simulation is performed following the flow chart of
(First Cycle)
rset={<TAG01, rule 01,1.0>, <TAG03, rule 03,0.2>, <CMP01, rule 31,1.0>, <CMP01, rule 32, 0.1>}
Here, <CMP01, rule 32, 0.1> is selected, and FIND is output.
G node group to be propagated is {$x1}.
(Second Cycle)
rset={<TAG01, rule 01,1.0>, <TAG03, rule 03,0.2>}
Here, <TAG03, rule 03,0.2> is selected, and PATHEXPAND2 is output.
G node group to be propagated is {$—2, $—3}.
(Third Cycle)
rset={<TAG01, rule 01,1.0>, <TAG04, rule 02,0.5>, <TAG03, rule 06,0.6>}
Here, <TAG04, rule 02,0.5> is selected, and PATHEXPAND1 is output.
G node group to be propagated is {$—4}.
(Fourth Cycle)
rset={<TAG01, rule 01,1.0>, <VAL01, rule 21,0.2>, <TAG02, rule 06,0.6>}
Here, <VAL01, rule 21,0.2> is selected, and VALUE is output.
G node group to be propagated is {$x1}.
(Fifth Cycle)
rset={<TAG01, rule 01,1.0>, <$x1, rule 11, 0.5>, <TAG02, rule 06,0.6>}
Here, <$x1, rule 11, 0.5> is selected, and JOIN is output.
G node group to be propagated is {null}.
(Sixth Cycle)
rset={<TAG01, rule 01,1.0>, <TAG02, rule 06,0.6>}
Here, <TAG02, rule 06,0.63> is selected, and NOP is output.
G node group to be propagated is {null}.
(Seventh Cycle)
rset={<CON01, rule 71,1.0>}
Here, <CON01, rule 71,1.0> is selected, and CONSTRUCT is output. Note that the rule of “CON” is not shown in
The meaning of this execution plan list 335 is as follows:
(Step 1)
Search a D node group including the string data, “search”. As the key “search” exists in the data creation index file, this information is used giving priority.
(Step 2)
Fetch child D node groups having the “patent” element name. As the key “patent” exists in the element name occurrence index file, this information is used giving priority.
(Step 3)
Fetch child D node groups having the “name” element name in the D node groups.
(Step 4)
Fetch child D node groups having element data in the D node groups.
(Step 5)
Take join (JOIN) of the D node groups fetched in the step 1 and D node groups fetched in the step 4.
(Step 6)
Do nothing, because the document path rank higher than “patent” is “root/*”.
(Step 7)
Create “bibliography” information using data of the D node groups.
In the step 1, as the key “search” exists in the data creation index file of
On the other hand, as the key “patent” exists in the element name occurrence index file of
Thus, it is understood that the search plan is generated effectively using index.
The search results are also expressed in XML, displayed as a list of “bibliography” information, and include the string “search” such as “information search apparatus”.
Here, for comparison, a case approached by a conventional technique shall be explained.
This conventional technique is a search processing method beginning from the root element and developing from parent element to child element group, for specifying the structural element on the hierarchical structure.
The meaning of this execution plan list is as follows:
(Step 1)
Fetch a D node group corresponding to root.
(Step 2)
Fetch child D node groups of the D node group.
(Step 3)
Fetch child D node groups having the “patent” element name in the D node groups.
(Step 4)
Fetch child D node groups having the “name” element name in the D node groups.
(Step 5)
Fetch child D node groups having element data in the D node groups.
(Step 6)
Select D node groups whose data includes the string data “search” in the D node groups.
(Step 7)
Create “bibliography” information using data of the D node groups.
Thus, the computation amount required for a search processing becomes huge, when the number of registered document increases and the depth and width of hierarchy tree increase.
You can imagine easily that the hierarchy tree development cost becomes huge in the step 2.
Now, an example of GUI (graphical user interface) like display of search results in this embodiment will be described below.
These results are obtained by setting two classification axis of the classification in the concept “information model” and the classification in the concept “information operation” for “patent” information, and searching as “bibliography” information by extracting “application No.” and “information model” axis and “information operation” axis, and “application No.” information is the data corresponding to the cross point of two axis, by setting “information model” axis as abscissas and “information operation” axis as ordinates.
XML has a display format called style sheet, used for displaying XML document on WWW browser, or printing from the printer. As language for style sheet, XSL (eXtensible Style Language) is prepared as standard code, information as shown in
This shows the number of patent application for each year by a line graph, and for this also, information as shown in
Now, a variation of the method to realize the structured document database system of
This system can also be realized to receive search request from the other computer through a network such as Internet or LAN, execute the search, and return the search results to the other computer through the network.
In this case, in place of receiving the search request like as
Besides, request control section 1, storage processing section 2 and search processing section 3 may be implemented on a single computer, or separately on two or three computers.
The program realizing respectively request control section 1, storage processing section 2 and search processing section 3 can be received and delivered by a recording media or communication media. In this case, a program realizing all three of request control section 1, storage processing section 2 and search processing section 3 can be stored in a single or a set of recording medium and received and delivered, or a program realizing only a part of request control section 1, storage processing section 2 and search processing section 3 may be stored in a single or a set of recording medium and received and delivered.
Also, for instance, a system including the search processing section 3 and a system including the storage processing section 2, the data file 4 and the index file 5 may be independent systems each other. A system including search processing section 3 can be composed as server, and implemented in respective client.
Obviously, this system can be realized as a single stand alone system.
Also, this embodiment can be realized as a computer readable recoding media recoding programs for executing a prescribed means by a computer (or for making a computer to function as a prescribed means, or for making a computer to realize a prescribed function).
The present invention allows to search by various search specification for the hierarchical structure that a document (including ambiguous path) has, without increasing the computation amount, by generating and executing an optimal search plan by going round appropriately the search graph generated from the search request, by using effectively information concerning structured document database.
Additional advantages and modifications will readily occur to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details and representative embodiments shown and described herein. Accordingly, various modifications may be made without departing from the spirit or scope of the general inventive concept as defined by the appended claims and their equivalents.
| Number | Date | Country | Kind |
|---|---|---|---|
| 11-330236 | Nov 1999 | JP | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 5173853 | Kelly et al. | Dec 1992 | A |
| 5381523 | Hayashi | Jan 1995 | A |
| 5499331 | Hayashi et al. | Mar 1996 | A |
| 5537593 | Diamond et al. | Jul 1996 | A |
| 5557722 | DeRose et al. | Sep 1996 | A |
| 5669007 | Tateishi | Sep 1997 | A |
| 5694609 | Murata | Dec 1997 | A |
| 5873081 | Harel | Feb 1999 | A |
| 5875441 | Nakatsuyama | Feb 1999 | A |
| 5991751 | Rivette et al. | Nov 1999 | A |
| 6182062 | Fujisawa et al. | Jan 2001 | B1 |
| 6263332 | Nasr et al. | Jul 2001 | B1 |
| 6377946 | Okamoto et al. | Apr 2002 | B1 |
| 6496819 | Bello et al. | Dec 2002 | B1 |
| 6496820 | Tada et al. | Dec 2002 | B1 |
| 6519597 | Cheng et al. | Feb 2003 | B1 |
| 6526410 | Aoyama et al. | Feb 2003 | B1 |
| 6714928 | Calow | Mar 2004 | B1 |
| Number | Date | Country |
|---|---|---|
| 6-203078 | Jul 1994 | JP |
| 6-301721 | Oct 1994 | JP |
| 11-15843 | Jan 1999 | JP |
