JP3910901B2 - Document structure search method, document structure search apparatus, and document structure search program - Google Patents

Description

[0001]
[Technical Field]
The present invention relates to a document structure search method and a structured document search apparatus for searching for a desired document structure from different document structures of a plurality of structured documents stored in a database having a hierarchical structure.
[0002]
[Prior art]
As a database for storing structured documents such as documents described in XML (Extensible Markup Language), each of a plurality of structured documents having a hierarchical structure and different document structures is a partial document on one large tree structure. Some are stored and managed as
[0003]
A document structure of a structured document such as a document described in XML (hereinafter also referred to as XML document, XML data, etc.) is called a schema. Schemas can also be specified by data creators explicitly using a schema language (XML-SCHEMA, Relax NG, etc.) (a schema document that describes a schema is called a schema document, which is also structured) However, it is generally troublesome to describe a schema in a schema language. Furthermore, unlike SGML, XML does not require a schema to be defined for data by a schema language, and is merely an optional position.
[0004]
Unlike the XML database having the hierarchical structure as described above, there is also an XML database having a flat (non-hierarchical) data structure for storing each XML document in folder units. The schema is stored in folder units and is not managed in a hierarchical manner.
[0005]
In the case of an XML database having a hierarchical structure and managing XML documents in one large tree structure (hereinafter referred to as a hierarchical XML database), the document structure of each structured document is managed as a part of the hierarchical structure. It will be.
[0006]
Although it is not always necessary to determine the schema in advance, if all the XML documents stored in the hierarchical XML database have different document structures, it cannot be denied that they are difficult to manage. From the viewpoint of efficiently managing stored documents, it is desirable that XML documents that are similar in content (belonging to the same category) have the same document structure rather than completely different document structures.
[0007]
When an XML document creator creates an XML document with a disjoint document structure, the document structure overflows, and the hierarchy or the XML database cannot be used more than a simple search engine, and the merits of XML may be lost.
[0008]
In other words, in the hierarchical XML database, it is desirable to suppress the flooding of the schema as much as possible. For this reason, it is conceivable that before creating an XML document, a schema of XML documents having similar contents in the hierarchical XML database is searched, and data is created using the schema.
[0009]
However, the conventional hierarchical XML database has the following two problems.
[0010]
The first problem is that there is no effective means for searching only the desired document structure in the hierarchical XML database. If schemas are defined for all stored documents in the schema language, the schema search can be facilitated by managing them in the database, but this is the case because the schema language is optional. Only the registered schema language is searched.
[0011]
Another method is to specify an ambiguous structure and examine the XML data as a result of searching the data with XQuery, etc., and extract the structure with the eyes of the user, but the cost in this case is also high . I want a schema, not data.
[0012]
For example, an arbitrary element name is designated as a search condition, and DTD (Document Type Definition) information that the document conforms to is returned as a search result (see, for example, Patent Document 1). However, according to this method, information cannot be obtained for a document that does not comply with DTD, and the granularity is also a document unit, and only the components of the DTD are returned (only the partial document schema is returned). (Return) is not possible.
[0013]
Also, there is a technique for searching similar documents from seed documents and displaying them (for example, see Patent Document 2). In the method disclosed here, it is necessary to visually determine which schema the acquired document follows, and since the search result is also a document unit, the schema included in the partial document is extracted. However, there remain problems such as low similarity.
[0014]
Furthermore, there is a technique for managing newly registered element names and attribute names in a table (see, for example, Patent Document 3). However, this method is effective only with a database that manages XML documents in a flat manner, and does not consider a hierarchical XML database in which the document structure is managed hierarchically.
[0015]
The second problem is that the search target is ambiguous and vague, such as how the search should be performed and what results should be obtained when the user tries to search the document structure. Since there are many cases, there is no method for specifying a search condition for a document structure including ambiguity so as to cope with such a case.
[0016]
In terms of what kind of search is performed, for example, when a schema of “book” information is to be searched, a schema element that defines an element called a book is generally searched. However, there is a case where it is not precisely defined as “book” and a search is made with a schema defining “book” or “book”.
[0017]
In addition, there is a request to search a schema that can be summarized only from keywords, vaguely. In this case, it is not only possible to determine whether what this keyword means is an element, an attribute, or a value, but the intention is to search for any schema that stores vague data. It has been.
[0018]
In this way, the user is vague at the time of searching the schema, is not fixed, and should be structured so that it can be absorbed.
[0019]
In a conventional search method (see, for example, Patent Document 2), a search is not output unless the tag name completely matches. If DTD is specified in advance, the structure according to the DTD is shown, but it is out of the main point of the present invention to search the schema.
[0020]
For any result, information that the user wants to use should be added instead of simply returning the schema language.
[0021]
Even if the schema is not defined by the schema language, when the user wants to manage data as an XML document, the user implicitly assumes the schema and creates a document accordingly. Furthermore, there is a strong tendency for data having similar schemas to be managed in the same path in a hierarchical database. These can be regarded as implicit schema definitions, and a management method is required in the same way as explicit schema definitions in the schema language.
[0022]
In addition, there are mainly two types of use of schema search (document structure search) depending on the user's intention.
[0023]
The first is a case where a schema to be searched to some extent can be predicted. For example, when searching for “patent-related schema”, the schema to be extracted is searched for a schema similar to the schema that defines the XML document of “patent” information.
[0024]
The second is that even though the data exists but the structure and how it is put together is not yet determined, we want to search for a similar schema. In this case, the main point is how to present a useful schema to the user from the data to be stored.
[0025]
Even in the search result, it is assumed that the database is a hierarchical database and the schemas are also arranged hierarchically.
[0026]
[Patent Document 1]
JP 2000-200266 A
[0027]
[Patent Document 2]
JP 2001-14326 A
[0028]
[Patent Document 3]
JP 2002-7439 A
[0029]
[Problems to be solved by the invention]
Thus, conventionally, there has been no method for efficiently searching only the document structure from the XML database having a hierarchical structure while taking into account the ambiguity of the search condition.
[0030]
Accordingly, an object of the present invention is to provide a document structure search method, a document structure search apparatus, and a program that can efficiently search a document structure from an XML database having a hierarchical structure based on a vague search condition.
[0031]
[Means for Solving the Problems]
The present invention is for retrieving a desired document structure from among different document structures of a plurality of structured documents stored in a database having a hierarchical structure, and the hierarchical structure includes the different document structures. When at least one keyword is input as a search condition for searching the document structure, each keyword is searched for a similar word of the keyword, and the keyword is searched from the hierarchical structure. And a similar element are included in the element name or element value, and a document structure including the searched element is output as a search result.
[0032]
According to the present invention, by simply inputting at least one keyword, it is possible to efficiently obtain a document structure including a component having an element name or an element value that is one of the keywords and a word in the similar range. it can.
[0033]
The present invention is also for retrieving a desired document structure from among different document structures of a plurality of structured documents stored in a database having a hierarchical structure, wherein the hierarchical structure includes the different documents. Each of the components constituting each of the structures. When at least one first keyword and at least one second keyword are input as a search condition for searching the document structure, A similar word of the first keyword is obtained, a first component including either the first keyword or the similar word in an element name or an element value is searched from the hierarchical structure, and the second And search for a second component that includes any one of the second keyword and the similar word in the element name from the hierarchical structure, and at least Among the document structure to the top of the second component, and outputs the document structure comprising the first component as a search result.
[0034]
According to the present invention, by simply inputting at least one first keyword and at least one second keyword, any one of the first keyword and a word in the similar range is selected as an element name or element value. It is possible to efficiently obtain a document structure including a constituent element having a constituent element having the element name of any one of the words in the similar range to the second keyword.
[0035]
DETAILED DESCRIPTION OF THE INVENTION
First, before describing an embodiment of the present invention, a basic configuration and processing operation of a structured document management system will be described.
[0036]
(Description of structured document management system)
Examples of structured documents include documents described in XML, SGML, and the like. SGML (Standard Generalized Markup Language) is a standard defined by ISO (International Organization for Standardization). XML (extensible Markup Language) is a standard defined by W3C (World Wide Web Consortium). These are structured document standards that allow documents to be structured.
[0037]
Hereinafter, description will be given by taking a document described in XML as a structured document. Data defining the document structure of a structured document (document structure definition data) is called a schema. In XML, schema languages such as XML-Schema and XDR (XMLData Reduced) have been proposed to define a schema. Here, for example, a case where a schema is described in XDR will be described as an example.
[0038]
The schema is also a structured document to be managed by the structured document management system, and may be referred to as a schema document here. A structured document other than a schema document, which has various miscellaneous contents such as patent specifications, mails, weekly reports, and advertisements, may be referred to herein as a content document.
[0039]
In the structured document management system, the schema document, the content document, and a query describing a search request from a user as will be described later, that is, a query document is also managed, and these are collectively referred to as “document”. .
[0040]
Hereinafter, when there is no special notice, when referring to “document”, it means all content documents, schema documents, and query documents.
[0041]
First, XML will be briefly described before describing the embodiment.
[0042]
FIG. 3 shows an example of “patent” information as an example of a structured document described in XML. In XML and SGML, tags are used to express the structure of a document. Tags include a start tag and an end tag. Each component of the document structure is surrounded by a start tag and an end tag. The start tag is the element name of the constituent element closed with “>”, and the end tag is the element name closed with the symbols “</” and “>”. The content of the component following the tag is a text (character string) or a repetition of a child component. Also, attribute information such as “<element name attribute =“ attribute value ”>” can be set in the start tag. A component that does not include text, such as “<patent DB></ patent DB>”, can also be expressed as “<patent DB />” as a simple notation.
[0043]
The document shown in FIG. 3 has an element starting from a “patent” tag as a root and elements starting from “title”, “application date”, “applicant”, and “summary” tags as its child elements. For example, one text (character string) such as “XML database” exists as an element value for an element starting from a “title” tag.
[0044]
In general, a structured document such as XML repeatedly includes arbitrary constituent elements, and further, the document structure is not predetermined.
[0045]
In order to logically express the structured document as shown in FIG. 3, a tree expression as shown in FIG. 4 is used. The tree is composed of nodes (numbered and indicated by circles), arcs (line with data connecting the circles representing the nodes), and text surrounded by a rectangle.
[0046]
One node corresponds to one component, that is, one document object. A plurality of arcs with labels corresponding to tag names and attribute names appear from the nodes. The destination of the arc is a character string (text) as a node value or element value. Alphanumeric characters (for example, “# 0”, “# 49”) described in the node are object IDs for identifying each document object.
[0047]
The tree structure shown in FIG. 4 is called the document object tree of the structured document shown in FIG.
[0048]
FIG. 1 shows an example of the structure of a structured document management system according to this embodiment. In FIG. 1, the structured document management system is roughly composed of a request control unit 1, an access request processing unit 2, a search request processing unit 3, a data access unit 4, a document storage unit 5, and an index storage unit 6. Yes. The document storage unit 5 and the index storage unit 6 are composed of, for example, an external storage device.
[0049]
The system configuration of FIG. 1 can be realized using software.
[0050]
The request control unit 1 includes a request reception unit 11 and a result processing unit 12. The request reception unit 11 receives a request from the user such as document storage, document acquisition, and document search, and calls the access request processing unit 2. The result processing unit 12 performs processing for returning the result processed by the access request processing unit 2 to the requesting user.
[0051]
The access request processing unit 2 includes a plurality of processing units corresponding to various requests from the user such as document storage, document acquisition, and document deletion. That is, the document storage unit 21, the document acquisition unit 22, and the document deletion unit 23 are configured.
[0052]
The document storage unit 21 performs processing for storing a document in a specified logical area in the document storage unit 5.
[0053]
When a logical area in the document storage unit 5 is specified, the document acquisition unit 22 performs processing for acquiring a document existing in the specified area.
[0054]
The document deletion unit 23 performs a process of deleting a document existing in a designated logical area in the document storage unit 5.
[0055]
The document storage unit 5 is a structured document database. For example, as shown in FIG. 8, documents are hierarchically stored in a tree structure like a UNIX directory structure.
[0056]
As shown in FIG. 8, the structured document database can be expressed in the same manner as the tree structure of one structured document as shown in FIG. That is, a partial hierarchical tree (partial tree) below an arbitrary node is a structured document cut out from the structured document database, and here, this is called a document object tree. Each node is assigned an object ID. The object ID is a unique numerical value in the structured document database.
[0057]
It is assumed that an object ID “# 0” for specifying that the node is the root node is assigned to the node serving as the root of the hierarchical tree.
[0058]
A link is made from the root node, that is, the node of “# 0” to the node of the object ID “# 1” having the “root” tag at the head. A link from an “# 1” node to a node with an object ID “# 2” having a “patent DB” tag at the head is provided. From the “# 2” node, links to a node with an object ID “# 42”, a node with “# 52”, and a node with “# 62” having a “patent” tag at the head are provided.
[0059]
The “patent” information shown in FIG. 3 corresponds to the partial tree below the “# 42” node in FIG. From this node, a link is made to a node having “title” tag, “applicant” tag, “summary” tag, etc. at the head, and from the end node, “XML database”, “T company”, “XML” A link to a character string (element value) such as “Provide a unified database” is provided.
[0060]
In FIG. 8, the partial tree below the node with the object ID “# 52” and the partial node below the node with the object ID “# 62” are also document object trees corresponding to one “patent” information.
[0061]
By the way, for example, the element value “XML database” linked to the “# 43” node is connected to the “# 43” node by a special tag name “#value”. Since this tag name starts with “#”, it cannot be used as a standard tag name in the XML standard.
[0062]
A structured document path is used to designate a specific node of such a structured document database. The structured document path is a character string that starts with “ux: /// root”. uix (Universal Identifier for XML) is a character string indicating a structured document path.
[0063]
For example, when “uix: // root / patent DB” is expressed as a structured document path, a logical area in the document storage unit 5 indicated by the structured document path is from a “# 1” node in FIG. The node indicated by the arc to which “patent DB” is assigned, that is, the “# 2” node.
[0064]
Similarly, the structured document path “uix: // root / patent DB / patent” points to the “# 42” node in FIG. 8, and the structured document path “uix: // root / patent DB / application date / “Year” indicates the “# 45” node in FIG.
[0065]
For example, in FIG. 8, in the case where a plurality of “patent” information is stored below the “# 2” node, that is, in the component “patent DB”, in order to identify each “patent” information, An index may be added to the name (eg, “patent” in this case).
[0066]
If it is the first “patent” information of “patent DB”, it will be “uix: // root / patent DB / patent [0]”, which is the same as “uix: // root / patent DB / patent” It is considered. If it is the second “patent” information of the “patent DB”, it is “uix: // root / patent DB / patent [1]”, and if it is the fifth “patent” information of the “patent DB”, it is “uxix”. // root / patent DB / patent [4] ”.
[0067]
The index storage unit 6 stores an element name occurrence index and a data occurrence index used at the time of retrieval.
[0068]
The element name occurrence index is an index file that associates the element name stored in the structured document database with the position of the structured document (document object tree) having the element name component at the head. For example, in the structured document database of FIG. 8, a structured document whose element name “patent” (corresponding to “patent” information) is a node below “# 42” node, a structured document below a node “# 52”, “ As shown in FIG. 9, the element name occurrence index includes the “# 42” node, the “# 52” node, and the parent node of the “# 62” node, as shown in FIG. , “# 2” node is stored linked to the element name “patent”.
[0069]
Thus, when indexing is performed at the parent node, the index file can be compressed. In other words, if indexing is performed at the parent node, the number of nodes to be linked to the element name does not increase because the parent node substitutes even if the number of child nodes increases.
[0070]
A data occurrence index is an index file that associates character string data stored in a structured document database with the position of a structured document (document object tree) in which the character string data exists. For example, in the structured document database of FIG. 8, the character string “XML” exists in the structured document under the “# 43” node and the structured document under the “# 49” node. In this case, in the data occurrence index, as shown in FIG. 10, the “# 43” node and the “# 49” node are linked to the character string “XML” and stored.
[0071]
The designated logical area in the document storage unit 5 is a storage location of the document designated by the user using the structured document path. The structured document path is an expression that can be recognized by the user.
[0072]
Returning to the description of FIG.
[0073]
The data access unit 4 performs various processes for accessing the document storage unit 5. The data access unit 4 includes a document object tree storage unit 41, a document object tree deletion unit 42, a document object tree acquisition unit 43, a document character string acquisition unit 44, a document parser unit 46, a composite document creation unit 47, and an index update unit 48. Composed.
[0074]
The document object tree storage unit 41 performs processing for storing a document object tree in a designated physical area in the document storage unit 5.
[0075]
The document object tree deletion unit 42 performs processing for deleting the document object tree existing in the designated physical area in the document storage unit 5.
[0076]
The document object tree acquisition unit 43 performs a process for acquiring a document object tree existing in a designated physical area (by a structured document path or the like) in the document storage unit 5.
[0077]
The document character string acquisition unit 44 performs processing for converting the document object tree into a structured document (XML document).
[0078]
The document parser unit 46 reads a structured document input by a user and inspects the document structure. Further, if there is a schema that is definition data of the document structure, it is verified whether or not the document structure of the input structured document conforms to the schema. The output result is a document object tree. A document parser can usually be constructed by combining a lexical analyzer (lexical analyzer generator) such as lex (performing lexical analysis and decomposing it into tokens) and a parser generator such as yacc (heteroother compiler).
[0079]
The composite document creation unit 47 must check whether it conforms to the schema when storing a document or deleting a document, but creates data necessary for this check.
[0080]
The index updating unit 48 updates the element name occurrence index and the data occurrence index shown in FIGS. 9 and 10 every time the stored contents of the structured document database are updated due to document storage or document deletion.
[0081]
The physical area in the document storage unit 5 is internal data indicating the location of unique document data in the structured document database such as file offset and object ID. The data cannot be recognized by the user.
[0082]
The search request processing unit 3 performs processing for searching for a document stored in the document storage unit 5 using each processing function unit provided in the data access unit 4. When the request receiving unit 11 of the request control unit 1 receives a document search request from the user, the search request processing unit 3 receives a query document described in the query language from the request receiving unit 11. Then, the index storage unit 6 and the document storage unit 5 are accessed through the data access unit 4, a set of documents that match the search request is acquired, and the result is output via the result processing unit 12.
[0083]
FIG. 2 shows one use form of the structured document management system shown in FIG. 1. In FIG. 2, the structured document management of the configuration shown in FIG. 1 is performed on the back end of the WWW (World Wide Web). The case where the system 100 is operating is shown.
[0084]
The WWW browser 103 is operating in each of a plurality (for example, three) of client terminals (for example, personal computers, portable communication terminals, etc.) 102. The user can access the structured document management system 100 by accessing the WWW server 101 from each client terminal. The WWW browser 103 and the WWW server 101 communicate with each other using HTTP (Hyper Text Transfer Protocol). Further, the WWW server 101 and the structured document management system 100 communicate with each other via CGI (Common Gateway Interface) or COM (Component Object Model).
[0085]
Requests from users, such as document storage, document acquisition, and document search, are transmitted from the WWW browser 103 and accepted by the structured document management system 100 through the WWW server 101. The result processed by the structured document management system 100 is returned to the requesting WWW browser 103 through the WWW server 101.
[0086]
The (1) storage function and (2) search function of the structured document management system in FIG. 1 will be described in detail below.
[0087]
(Storage function)
The storage system commands in the structured document management system of FIG.
[0088]
insertXML (path, Nth, XML): document storage
appendXML (path, XML): document storage
getXML (path): Document acquisition
removeXML (path): Delete document
setSchema (path, schema): Schema storage
getSchema (path): Schema acquisition
“InsertXML” is a command (hereinafter simply referred to as an insert command) that inserts a document at the Nth position below the structured document path specified in ().
[0089]
“AppendXML” is a command for inserting a document at the end of the structured document path specified in () (hereinafter simply referred to as an add command).
[0090]
“GetXML” is a command for retrieving a document below the structured document path specified in () (hereinafter simply referred to as an acquisition command).
[0091]
“RemoveXML” is a command (hereinafter simply referred to as a delete command) for deleting a document below the structured document path specified in () (a document other than a schema document, mainly a content document).
[0092]
“SetSchema” is a command (hereinafter simply referred to as a schema storage command) for setting a schema in the structured document path specified in ().
[0093]
“GetSchema” is a command for retrieving the schema set in the structured document path specified in () (hereinafter simply referred to as a schema acquisition command).
[0094]
Among the above commands, processing for the insert command, addition command, and schema storage command is executed by the document storage unit 21 of the access request processing unit 2, and processing for the acquisition command and schema acquisition command is executed by the document acquisition unit 22. Processing regarding the delete command is executed by the document deletion unit 23.
[0095]
With reference to FIG. 5, the case where an additional command is executed in the initial state of the structured document database (see FIG. 5A) will be described.
[0096]
As shown in FIG. 5A, with respect to the initial state in which the “# 0” node and the “# 1” node are connected by the “root” arc,
As a result of executing “appendXML (“ uix: // root ”,“ <patent DB /> ”)”, a “# 2” node and a “patent DB” arc are created as shown in FIG. .
[0097]
A case where an acquisition command is executed on the structured document database in the state shown in FIG.
[0098]
For example, when “getXML (“ uix: // root ”)” is executed, the document object tree below the “# 0” node indicated by the “root” arc in FIG. 5B is extracted and converted to an XML document. To do. As a result, a character string “<root><patent DB /></root>” is extracted and converted into an XML document as shown in FIG. The processing of the acquisition command is executed by the document acquisition unit 22 of the access request processing unit 2.
[0099]
Next, when an additional command for storing “patent” information as a content document (XML document) as shown in FIG. 3 is executed for the structured document database in the state shown in FIG. Will be described. That is, in this case, “appendXML (“ uix: // root / patent DB ”,“ <patent>... </ Patent> ”)” is executed. In this command, ““ <patent>... </ Patent> ”” corresponds to the “patent” information XML document shown in FIG.
[0100]
When the processing of the additional command is executed, as shown in FIG. 7, a document object tree (corresponding to FIG. 4) with the “# 42” node at the top is added below the “# 2” node.
[0101]
Assume that the following additional command is repeatedly executed three times for the structured document database in the state shown in FIG.
[0102]
"AppendXML (" uix: // root / patent DB ","<patent> ... </ patent>")"
In the above command, “<patent>... </ Patent>” corresponds to a content document having the same document structure as the XML document shown in FIG.
[0103]
Then, as shown in FIG. 8, a document object tree with “# 42” node, “# 52” node, and “# 62” node at the top is added below the “# 2” node.
[0104]
Next, a case where an acquisition command for extracting three pieces of “patent” information is executed on the structured document database in the state shown in FIG. 8 will be described. In this case, “getXML (“ uix: // root / patent DB ”)” is executed. Then, the document object tree below the “# 2” node indicated by the “patent DB” arc is extracted. As a result, as shown in FIG. 11, an XML document “<patent DB><patent> ... </ patent><patent> ... </ patent><patent> ... </ patent></ patent DB>” is acquired. it can.
[0105]
In the structured document database, data defining the document structure of the content document (XML document) such as the “patent” information, that is, the schema, is also managed.
[0106]
FIG. 12 shows an example of a schema that defines the document structure of an XML document. Here, XDR (XML-Data Reduced), which is one of XML document structure definition languages, will be taken up. Of course, other document structure definition languages such as XML-Schema may be used.
[0107]
The schema shown in FIG. 12 defines the document structure of the “patent” information shown in FIG. 3 in XDR. As can be easily seen from FIG. 12, the schema is also a structured document in the XML format. There is an element set that starts with a component starting with a “Schema” tag and starts with an “ElementType” tag as its child elements.
[0108]
A case where a schema storage command for storing the schema document shown in FIG. 12 is executed on the structured document database in the state shown in FIG. 8 will be described. In this case, “set Schema (“ uix: // root / patent DB ”,“ <Schema>... </ Schema> ”)” is executed. In this command, ““ <Schema>... </ Schema> ”” corresponds to the schema document shown in FIG.
[0109]
By executing the above command, as shown in FIG. 13, a “#schema” arc is added below the “# 2” node, and a document object tree having the “# 3” node as a top node is added to the “# 3” node. The Since the schema itself is expressed as an XML document, the tree is expanded as shown in FIG.
[0110]
In FIG. 13, arcs that start with “@” like “@name” correspond to attributes. Since the tag name “#schema” also begins with “#” and “@”, it cannot be used as a standard tag name in the XML standard.
[0111]
Since the schema document shown in FIG. 12 is stored below the “# 2” node, the document structure of the document stored below the “# 2” node is defined by the schema document shown in FIG. It may be required to conform to the document structure. That is, in this case, the schema shown in FIG. 12 is set below the “# 2” node.
[0112]
When the schema shown in FIG. 12 is set below the “# 2” node, for example, as shown in FIG. 14, each node (file) of the document object tree below the “# 2” node has the schema. An attribute value indicating that it exists is set.
[0113]
After the schema shown in FIG. 12 is set below the “# 2” node, the “patent” information document shown in FIG. 3 that matches the document structure defined in this schema is shown in FIG. As described above, when the document object tree is stored in the structured document database, an attribute value indicating that the schema shown in FIG. 12 exists in the document structure of this document is set in each document object constituting the document object tree. Is done. For example, “1” is set to an attribute value (for example, “schema conformity presence / absence”) indicating that a schema exists for each document object file constituting the document object tree. In FIG. 14, each document object (node) conforming to the schema is indicated by a double circle. Each document object indicated by a double circle has a document structure definition corresponding to the document object.
[0114]
FIG. 15 conceptually shows the contents of a file of each document object. For example, a file of a document object whose object ID is “# 42” relates to another document object linked to the document object. The attribute value is described together with information (for example, an arc or a pointer value to a linked document object). Note that when there is no schema to be applied to the document object, the value of “existence of schema conformance” is “0”.
[0115]
FIG. 16 and FIG. 17 show the structure of the concept hierarchy, which is the result of hierarchically classifying words used as keywords used as search conditions as needed from the semantic content in the structured document management system of FIG. An example expressed in a document is shown. The “concept” information shown in FIGS. 16 and 17 is a content document described in XML.
[0116]
The example of “concept” information shown in FIG. 16 represents an “information model” used as one classification axis for classifying the contents of a patent document in a so-called patent search in a concept hierarchy. “Concept” information surrounded by “concept” tags has a document structure with a nested structure. That is, in the example of FIG. 16, there are a concept “document”, a concept “relation”, and a concept “object” as child concepts of the concept “information model”. Further, as a child concept of the concept “document”, there are a concept “structured document” and a concept “unstructured document”. Furthermore, as a child concept of the concept “structured document”, there are a concept “XML” and a concept “SGML”.
[0117]
The description example of the “concept” information illustrated in FIG. 17 represents a classification axis “information operation” different from that in FIG. In the example of FIG. 17, there are a concept “search”, a concept “store”, a concept “processing”, and a concept “distribution” as child concepts of the concept “information operation”.
[0118]
The “concept” information as shown in FIGS. 16 and 17 can also be stored in the structured document database in the same manner as the “patent” information described above. That is, for example, first, “appendXML (“ uix: // root ”,“ <concept DB /> ”)” is executed on the structured document database in the state shown in FIG. Thus, a “# 201” node and a “concept DB” arc are created. In this state, when “concept” information shown in FIG. 16 is stored, “appendXML (“ uix: // root / concept DB ”,“ <concept name>... </ Concept> ”)” is executed. . In this command, ““ <concept name>... </ Concept> ”” corresponds to the “concept” information shown in FIG.
[0119]
When the processing of the addition command is executed, as shown in FIG. 19, a document object tree with the “# 202” node at the top is added below the “# 201” node.
[0120]
As described above, in the structured document management system in FIG. 1, a large number of XML document groups (content documents, schema documents, query documents, etc.) having different document structures registered in the structured document database are displayed. 18. As shown in FIG. 19, it is handled as one large XML document in the form of a tree having a “root” tag at the head. Therefore, to access a partial XML document, it is possible to search and process a wide range of XML documents by using a unified access means that does not depend on the document structure, which is a path to a large XML document. Become.
[0121]
In addition, by setting a schema in a part of the structured document database, the validity of whether or not the document structure of the document to be stored matches the document structure defined by the schema is automatically checked. You may make it carry out.
[0122]
(Search function)
The search commands in the structured document management system of FIG.
[0123]
query (ql)
“Query” is a command (hereinafter referred to as a search command) that executes the query ql in () as a parameter and acquires the resulting XML document.
[0124]
For example, as shown in FIG. 20, the query is an XML document having a document structure in which a search position, a search condition, an information extraction part, and the like are described in a language similar to SQL (Structured Query Language). The query document is also a management target of the structured document management system.
[0125]
The element starting from the “kf: from” tag has a description for associating a variable with the specification of the search position and the value of the document element, and the element starting from the “kf: where” tag has a description of conditioning regarding the variable , The output format of the search result is described in the element starting from the “kf: select” tag.
[0126]
Search includes simple search and concept search. Simple search searches and extracts information that satisfies the search conditions specified in the query, and concept search uses the concept information specified in the query to search specified in the query. It searches and extracts information that satisfies the conditions.
[0127]
FIG. 21 shows an example of a simple search query. The query shown in FIG. 21 corresponds to, for example, “1999” in the “patent” information document group stored below the node indicated by the “patent DB” arc for the structured document database shown in FIG. In addition, a description example of a search request “enumerate“ titles ”of a document (“ patent ”information) having an element“ summary ”having a content such as“ PC ”) is shown.
[0128]
Document elements of “Title”, “Year”, and “Summary” of “Patent” information are respectively added to the variables “$ t”, “$ y”, and “$ s” by the description of the element that starts with the “kf: from” tag. The value of is assigned.
[0129]
The variable “$ y” = “1999” is compared based on the description of the element starting from the “kf: where” tag. The component “MyLike” is a function for detecting the variable “$ s” having a value similar to “PC” with the variables “$ s” and “PC” as arguments.
[0130]
The variable “$ t” is used as the output value by the description of the element starting from the “kf: from” tag.
[0131]
The “kf: star” tag is an ambiguous expression of the structure. For example, “<patent><kf:star><year>” exists as a descendant element of an element whose tag name is “patent”. And an element whose tag name is “year”.
[0132]
FIG. 22 shows a search result using the simple search query of FIG. This search result is also an XML document.
[0133]
FIG. 23 shows an example of a query for concept search. For example, the query in FIG. 23 is performed on the “patent” information document group stored below the node indicated by the “patent DB” arc with respect to the structured document database in the state illustrated in FIGS. 18 and 19. A description example of a search request for searching using “concept” information stored below the node indicated by the “concept DB” arc is shown. Here, the values of the child elements of the tag having the value of the concept “peripheral device” include the concepts “SCSI”, “memory”, “HDD”, and the like. Further, although not shown in FIG. 18, it is assumed that elements of each “patent” information include elements starting from “keyword” tags.
[0134]
That is, the query of FIG. 23 is a description example of a search request “list enumeration of“ titles ”of“ patent ”information having any one of the concepts below the concept“ peripheral device ”as an element value of a component“ keyword ”. Is shown.
[0135]
By the description of the element starting from the “kf: from” tag, the values of the elements “title” and “keyword” of the “patent” information are substituted into the variable “$ t” and the variable “$ k”, respectively. The variable “$ x” is substituted with the values of tag child elements (“SCSI”, “memory”, “HDD”, etc.) having the value of “peripheral device” as “concept” information.
[0136]
A comparison of “$ k” = “peripheral device” or “$ k” = “$ x” is made based on the description of the element starting from the “kf: where” tag.
[0137]
Next, the document search processing operation of the structured document management system of FIG. 1 will be described with reference to the flowchart shown in FIG.
[0138]
On a predetermined display device of the client terminal, a screen as a user interface as shown in FIG. 25 provided by the structured document management system 100 (for example, the request control unit 1) is displayed.
[0139]
When the user selects “XML search Win” using a pointing device such as a mouse on the screen shown in FIG. 25, a screen as a user interface for performing a document search shown in FIG. 26 is displayed. .
[0140]
In the search screen of FIG. 26, in the area W1, element names (tag names) of the components of the current tree structure of the structured document database are displayed in a simplified manner so that the user can understand them. In FIG. 26, only the element names of the upper hierarchy are displayed, but it is possible to display up to the end element names.
[0141]
The area W11 is an area for inputting a search target range (a search range on the tree structure), a search condition, and the like. In the area W12, the search result is displayed.
[0142]
For example, among the documents having “patent” under “uix: // root” as the first tag, the element value of the component having the “title” tag includes the character string “document”, and “1998” In the case of a search request “search for a document created thereafter”, “root” is selected from the area W1 with a mouse or the like, and a structured document path is input as a search target range. In the area W11, first, “patent” is input as the top node (in this case, “patent” may be input from the area W1 by selecting with a mouse or the like). Further, the contents of “the element value of the component“ title ”includes the character string“ document ”” and “the element value of the component“ year ”is“ 1998 ”or more” as the search condition are stored in advance. What is necessary is just to input into the provided data input area.
[0143]
Thereafter, by selecting the “search” button B21, for example, a query as shown in FIG. 27 is transmitted to the structured document management system together with an additional command for storing the query on the structured document database. The storage location of the query is predetermined, and the system side automatically sets the parameter of this additional command. For example, when the structured document database is in the state shown in FIG. 18, the structured document path as a parameter indicating the storage location of the query is “uix: // root / query DB”. The other parameter of the additional command is the query document.
[0144]
When receiving the query (step S100), the request receiving unit 11 passes the query to the search request processing unit 3. Then, the parameter of the additional command for storing the query document is passed to the document storage unit 21. The document storage unit 21 performs an additional command process, and the query is stored in the document storage unit 5 (step S101).
[0145]
On the other hand, the search request processing unit 3 accesses the index storage unit 6 and the document storage unit 5 through the data access unit 4 based on the received query, acquires a document set that matches the search request, etc. The requested information is extracted and output via the result processing unit 12.
[0146]
For example, in the case of the above query, first, it is efficient to narrow down the search target by searching for items that match the condition that the element value of the component having the “title” tag includes the character string “document”. Good. Therefore, the object ID of the node (document object) linked to the character string “document” is obtained using the data occurrence index as shown in FIG. Then, for each of them, the document object tree is moved up one upstream, and when the tag name “title” is reached, further upstream is reached. When the tag name “patent” is reached, the node The following document object tree Ot11 is extracted.
[0147]
Next, a document object tree Ot12 whose component value “year” is “1998” or more is further extracted from the extracted document object trees Ot11.
[0148]
This document object tree Ot12 is a document that matches the contents of the query. Further, according to the request contents of the query, a structured document path to the top node of each document object tree Ot12 is obtained (step S102).
[0149]
The search process is not limited to the above-described method, and various efficient search methods using index information are possible.
[0150]
The search request processing unit 3 integrates the results obtained in step S102 and creates an XML document as a search result (step S103).
[0151]
For example, the XML document of the search result is
<Out>
<Result>
ux: // root / patent DB / patent [0]
</ Result>
<Result>
ux: // root / patent DB / patent [2]
</ Result>
</ Out>
It becomes.
[0152]
The search request processing unit 3 returns the XML document together with the style sheet to the requesting client terminal via the search result processing unit 12 (step S104).
[0153]
In the client terminal, the XML document shown in FIG. 11 is converted into HTML data using a style sheet, and displayed in the area W12, for example, as shown in FIG. Here, for example, since the number of structured documents obtained as a search result is large, the structured document path of the searched structured document is displayed as the search result. In this case, for example, it is assumed that a desired one of the search result structured document paths displayed in the region W12 of FIG. 26 is selected by the user. For example, it is assumed that the first one of the structured document paths displayed in the area W12 in FIG. 26 is selected. In this case, an acquisition command may be transmitted as a document acquisition request from the client terminal to the structured document management system in order to acquire a structured document specified by the selected structured document path.
[0154]
The document acquisition processing operation of the structured document management system of FIG. 1 when the acquisition command is received by the request reception unit 11 of the structured document management system will be described with reference to the flowchart shown in FIG.
[0155]
For example, an acquisition command “getXML (“ uix: // root / patent DB / patent [0] ”)” is transmitted to the structured document management system.
[0156]
Here, for example, when the structured document database is in the state shown in FIG. 8, an acquisition command “getXML (“ uix: // root / patent DB / patent [0] ”)” is received as an example I will explain to you.
[0157]
When receiving the acquisition command, the request reception unit 11 passes the structured document path “uix: // root / patent DB / patent [0]”, which is a parameter in the acquisition command, to the document acquisition unit 22 (step S31). ).
[0158]
The document acquisition unit 22 passes the structured document path to the document object tree acquisition unit 43. The document object tree acquisition unit 43 specifies a physical area in the document storage unit 5 from the structured document path, and thereby displays a node (document object Ox5) represented by the structured document path existing in the area. Take out (step S32). If the structured document path is specified correctly, the object ID of the document object Ox5 can be acquired (step S33). In this case, the process proceeds to step S35.
[0159]
For example, in the case of the above acquisition command, since the “# 42” node becomes the document object Ox5, “# 42” is acquired as the object ID, and the document object tree Ot5 (“##” below this “# 42” node is acquired. 42 "node to"# 49 "node) are acquired (step S35).
[0160]
In step S32, if the corresponding document object Ox5 is not found from the designated structured document path, an error occurs (step S33), and the document acquisition unit 22 and the result processing unit 12 notify the client terminal that “document acquisition failed. Is returned (step S34).
[0161]
The document object tree Ot5 acquired in step S35 is converted into an XML document by the document character string acquisition unit 44. For example, in the case of the above acquisition command, the acquired XML document is an XML document of “patent” information as shown in FIG.
[0162]
The document acquisition unit 22 returns the XML document as shown in FIG. 3 (for example, with a predetermined style sheet such as XSL (extensible Style Language)) to the client terminal via the result processing unit 12 (step S37).
[0163]
The client terminal converts the XML document shown in FIG. 3 into HTML data using a style sheet, and displays it in the area W13 as shown in FIG. 29, for example.
[0164]
Using XSL, XML documents can be converted into various forms. It can be converted into an XML document with a different syntax, and an HTML page can be generated from the XML document.
[0165]
Similarly, a schema can be searched.
[0166]
For example, in the case of a search request “search for a schema having tag names“ patent ”and“ summary ”from documents having“ schema ”below“ uix: /// root ”as the first tag, As shown in FIG. 30, “root” is selected from a region W1 with a mouse or the like, and a structured document path is input as a search target range. Then, “#schema” is input as the top node. In addition, as a search condition, the contents of “include the character string“ patent ”in the attribute name of the component” and “include the character string“ summary ”in the attribute name of the component” are input in the data input area provided in advance. do it.
[0167]
Thereafter, by selecting a “search” button B21, a query describing the search request, for example, as shown in FIG. 31 is structured with an additional command for storing the query on the structured document database. Sent to the document management system.
[0168]
In the case of the above query, for example, a search is made that matches the condition of “having“ #schema ”as the first tag”. Therefore, using the element name occurrence index as shown in FIG. 9, the object ID of the (document object) of the node linked to the element “#schema” is obtained. Then, for each of them, the arc is traced downstream in the document object tree, and when the attribute name reaches an element of “patent” and “summary”, the document object tree having “#schema” as the first tag Extract Ot21. This document object tree Ot21 is a document that matches the contents of the query. Further, according to the request content of the query shown in FIG. 31, a structured document path to the top node of each document object tree Ot21 is obtained.
[0169]
If there are a plurality of document object trees Ot21, the search request processing unit 3 collects structured document paths to the respective top nodes, creates an XML document as a search result, and passes the search result processing unit 12 through the search result processing unit 12. The XML document is returned to the requesting client terminal together with the style sheet.
[0170]
In the client terminal, the XML document received as the search result is converted into HTML data using a style sheet, and displayed in the area W12 as shown in FIG. 26, for example.
[0171]
In the client terminal, when one schema in the search result is selected and displayed, for example, the “patent” information is displayed in the area W3 together with a screen for storing / deleting a document as shown in FIG. The data input area is set and displayed for each element.
[0172]
The user can easily create a stored document having a document structure defined by the schema by inputting data in the data input area.
[0173]
For example, when “patent DB” is selected in the area W1 using a mouse or the like as the storage destination of the “patent” information input in the area W3 in FIG. 32, the structured document path in the area W2 is “uix: /// root”. / Patent DB ”is displayed. Thereafter, when the “Register” button B1 is selected, an additional command “appendXML (“ uix: // root / patent DB ”,“ <patent>... </ Patent> ”)” is transmitted to the structured document management system. .
[0174]
As described above, in the structured document management system in FIG. 1, a large number of XML document groups (content documents, schema documents, query documents, etc.) having different document structures registered in the structured document database are displayed. 18. As shown in FIG. 19, it is handled as one large XML document in the form of a tree having a “root” tag at the head. Accordingly, it is possible to easily search for a document that matches the search condition from among a large number of documents having different schemas and different schemas.
[0175]
Further, since the query used for the search is also a structured document, an application that reuses a past query can be easily constructed by storing the query in the structured document database as a log.
[0176]
(Document structure search)
The configuration and processing operation for document structure (schema) search according to the embodiment of the present invention will be described below in addition to the basic configuration and processing operation of the structured document management system described above. .
[0177]
As illustrated in FIG. 1, the structured document management system 100 includes a schema search processing unit 303 and a template processing unit 306 in the data access unit 4 for performing a schema search, and further includes a template storage unit 404. And a semantic network storage unit 405.
[0178]
The template processing unit 306 creates a template tree representing the logical structure in order to manage the hierarchical logical structure of the structured document database (hereinafter also referred to as an XML database). This template tree is updated each time a new XML document is stored.
[0179]
The template tree created here is stored in the template storage unit 404.
[0180]
The client terminal 102 transmits a schema search request statement (query) to the structured document management system 100. This schema search request statement is received by the request receiving unit 11 of the structured document management system 100, and the schema search request statement is transferred to the schema search processing unit 303 from here.
[0181]
The schema search processing unit 303 is for searching a schema based on a schema search request sentence while referring to a semantic network stored in the semantic network storage unit 405 and a template stored in the template storage unit 404. .
[0182]
(1) Updating the template tree
First, a template tree update processing operation at the time of document storage in the template processing unit 306 will be described.
[0183]
As described above, when the document storage unit 21 executes the add command and registers the registration target XML document in the document storage unit 5, the document storage unit 21 stores the registration target XML document on the database where the registration target XML document is stored. And the information on the document structure of the XML document to be registered.
[0184]
FIG. 33 shows a configuration example of the template processing unit 306.
[0185]
The template processing unit 306 first extracts the structure information of the XML document such as the element name and attribute name of the component from the document structure information of the XML document to be registered in the structure extraction unit 306a. Based on this and the structured document path, the template tree processing unit 306b updates the template tree representing the logical structure in the XML database stored in the template storage unit 404.
[0186]
The template tree is obtained by extracting the document structure of the XML document stored in the XML database and forming a tree according to the hierarchical structure of the XML database. Each node (each component) is assigned with a template ID and stored. The As described above, the XML document to be registered is stored in the document storage unit 21 with these object IDs added to the respective constituent elements, but the template ID is also added and stored. ing. The element IDs and attribute names of all the constituent elements constituting the document structure of the XML document to be registered are assigned with this template ID and stored on the template tree.
[0187]
For example, consider a case where a template tree as shown in FIG. 34 is stored in the template storage unit 404 before the update. In this case, the state of the XML database is the same as in FIG. At this time, the XML document 601 as shown in FIG. 35A is registered in the XML database under “/ document DB / patent DB”, and the XML document 602 as shown in FIG. Consider the case of registering under “DB / employee DB”. Here, the expression “/ document DB / patent DB” is the same as the structured document path used when expressing the position of the component in the XML database, and here, the position of the component on the template tree. It is also used to express
[0188]
The template tree stores at least a logical structure including a document structure of each XML document stored in the XML database and a storage position on the hierarchical structure of the XML database.
[0189]
Here, the template ID given to the element name and attribute name of each component is the codes TID1 to TID13 assigned to the element name (tag name) and attribute name of each component in FIGS. Are the same.
[0190]
In this case, since all elements are new elements as nodes on the template tree, the template tree is updated as shown in FIG.
[0191]
Further, when a plurality of XML documents having the same document structure or part of the same document structure are stored in storage positions represented by the same structured document path, 2 in the template tree (logical structure). Constituent elements common to two or more XML documents are aggregated into one and expressed as one constituent element. In this case, it is necessary to manage the correspondence between the template ID of the component on the template tree and the object ID of each component on the XML database. For this purpose, for example, the template ID of each component and the object ID of the component in the XML document may be recorded on the template tree, or the correspondence between the template ID and the object ID is recorded. A separate table may be provided.
[0192]
In practice, the template tree is stored in the template storage unit 404 as an XML document as shown in FIG. This is referred to herein as a template tree document.
[0193]
As shown in FIG. 37, the template tree document is, for example, an XML document hierarchized with components having “xsp: Node” as the element name at the top. As described in the template tree document, when an XML document is registered in the XML database, “document” is used for the root node (element name of the first component) of the XML document to be registered. “Element” is added to the element name of each element other than that, and “attribute” is added to the element representing the attribute as the attribute value of the type attribute of “xsp: Node”.
[0194]
In the case of creating a folder, “folder” and “rootElement” are added as type attributes as the root of the XML database. Further, among the constituent elements in the XML document to be registered, the constituent elements that are registered each time are highly likely to be essential in the document structure, so record that they are essential with the attribute “required”. (If it is essential, the attribute value of the attribute is “yes”). In addition, simple schema extraction is performed in which one or more elements appear on the same document with no limit on the number of times (maxOccurs = “*”). It is also possible to write a candidate value (“dataType”) by performing a type estimation step. This is passed if a non-candidate value comes to this element.
[0195]
Further, the actual number of components (number of object IDs) aggregated into one component on the template tree may be described as a count attribute. Note that FIG. 37 shows only the attributes of count and type.
[0196]
When an add command is executed in the document storage unit 21 to register an XML document to be registered, an index corresponding to the XML document is created as described above.
[0197]
(2) Outline of schema search processing
The client terminal 102 transmits a schema search request statement to the structured document management system 100. This schema search request statement is received by the request receiving unit 11 of the structured document management system 100, and the schema search request statement (schema query) is passed from here to the schema search processing unit 303.
[0198]
FIG. 38 shows a configuration example of the schema search processing unit 303.
[0199]
The schema search processing unit 303 includes a schema query analysis unit 321, a schema query condition processing unit 322, and a schema query output processing unit 333.
[0200]
The schema query analysis unit 321 analyzes a search request statement in which a search condition for searching a schema is described, that is, a schema query. Examples of the query description language include XQuery. FIG. 39 shows a specific example of the schema query. In addition, since the schema search needs to create data by estimating the schema and perform the search, the schema query cannot be expressed by ordinary XQuery or the like.
[0201]
The schema query starts with a component having an “xsp: query” tag, and is mainly described in a component having a tag of “xsp: rerun” (hereinafter also simply referred to as a “return clause”). And a portion (hereinafter also simply referred to as a where clause) described by the components of the tag “xsp: where”.
[0202]
Since the “xsp: query” tag at the head is present, the request reception unit 11 can determine that the query is a schema query.
[0203]
In the component having the “xsp: return” tag, a character string (keyword) corresponding to the element name or attribute name of the first component of the document structure to be extracted is described. All elements in the “xsp: return” clause are “xsp: elem”. A plurality of candidates may be described here. For example, an element name and an attribute name that are assumed to be closely related are described with a name attribute. In the schema query shown in FIG. 39, “patent” and “document” are described.
[0204]
In this case, ambiguous fluctuations other than perfect matching are also considered. This is because a schema which is not described as a “patent” schema but is defined by “Patent”, for example, is similarly searched.
[0205]
As a means for absorbing this fluctuation, the semantic network storage unit 405 stores a semantic network as shown in FIG. As shown in FIG. 41, the semantic network is a graph representing the relationship between vocabularies, and weights (similarities) between vocabularies are added on the arc. For example, the similarity of “structured document” and “XML” is “0.8”. The numerical value representing the similarity takes a value from “0” to “1”.
[0206]
FIG. 42 shows an algorithm for calculating the similarity.
[0207]
Here, a case where a vocabulary similar to “XML” is obtained while calculating the similarity will be described with reference to the flowchart shown in FIG.
[0208]
Here, a threshold value of similarity that can be determined to be similar to the vocabulary character string “XML” is, for example, “0.6”. First, the position on the semantic network of “XML” is searched (step S201). The search position weight (similarity) is set to “1.0” (step S202). Thereafter, first, the current keyword is added to the search candidate list and the fixed candidate list (step S203).
[0209]
The vocabulary “structured document” and “markup language” similar to “XML” are extracted from the semantic network shown in FIG. 41, and the similarity is “0.8”. In this case, “0.8” is obtained by multiplying the weight “1.0” of the expanded vocabulary “XML” by the weight of each extracted vocabulary. The expansion source vocabulary “XML” is deleted from the search candidate list, and these two vocabularies are added (step S205).
[0210]
Since the similarity between the two vocabularies is “0.8”, it is also added to the fixed candidate list (steps S206 to S207).
[0211]
Next, when the “structured document” on the search candidate list is used as the expansion source and the semantic network shown in FIG. 41 is expanded by one stage, the similarity of the “structure document” is similar to “0” from the expansion source. .5 ”and the expansion source weight“ 0.8 ”are multiplied to obtain“ 0.4 ”. Since the threshold is set to “0.6” now, no further development is performed. By repeating the above operations, as a result, “XML” (1.0), “Markup Language” (0.8), “SGML” (0.64), “HTML” (0.64), “ The “semi-structured document” (0.64) will remain on the confirmed candidate list.
[0212]
In the schema query shown in FIG. 39, the threshold value is described as an attribute of “xsp: elem” in order to represent the threshold value of the similarity. That is, here, the attribute name “sim” is used to describe the attribute value of the sim attribute. If a threshold value is set by this attribute value, development on the semantic network for obtaining a vocabulary having a similarity degree equal to or less than the threshold value defined here can be suppressed. The threshold may be set when the user inputs a search condition, for example. However, the threshold is not limited to this, and a default value written in advance on the schema query may be used. Further, even if not described in the schema query, a value predetermined by the schema search processing unit 303 may be used.
[0213]
When searching the schema, you may not even know the extracted part. In this case, if “<xsp: return type =“ all ”/>” is described in the schema query, the schema search processing unit 303 automatically determines the root node of the document (that is, as described above). On the template tree, since the attribute value “document” is described in the first component of one XML document, the root node can be determined by checking this) The document structure starting from the root node can be taken out (pseudo schema is created) and returned.
[0214]
Returning to the description of the schema query in FIG. 39, a component having an “xsp: where” tag describes a character string (keyword) included in the element name or attribute name of the component as a search condition. In this section, the search conditions are described while leaving the ambiguous state.
[0215]
For example, “<xsp: elementtype =“ element ”/>” when the element name or attribute name is not known, and “<xsp: element type =“ word ”/> when the element value is unknown as an attribute value. > ”. In some cases, the element name, the attribute name, the element value, or the attribute value may not be known at all. In this case, “<xsp: elem type =“ all ”/>” is described.
[0216]
That is, when a certain character string is specified by the user, if it is used as a search condition for searching a schema having the element name (or may be an attribute value), “<xsp: element type =“ element ”/ > ”And when the search condition is used to search for a schema having the character string as an element value (or attribute value),“ <xsp: elem type = “word” /> ” When a search condition for searching a schema having a column in either one of element name (or attribute name) and element value (or attribute value) is used, “<xsp: elem type =“ all ”/>” Is described.
[0217]
The name representing the schema is described by the name attribute. Here, in the schema query shown in FIG. 40, it is possible to perform a search specifying “int” and an integer type in the dataType attribute or the like. Similarly, the closeness of expansion is described by sim.
[0218]
Next, a schematic processing flow of schema search in the schema search processing unit 303 will be described with reference to a flowchart shown in FIG.
[0219]
The schema query in the schema search processing unit 303 first performs a where clause process (step S301), then performs a return clause process (step S302), and then merges the processing results (step S303). Then, a schema estimation process is performed on the result, that is, a schema is extracted (step S304), a sort process based on the scoring process of each extracted schema is performed (step S305), and finally the output format is formatted. (Step S306), and returns the result.
[0220]
Next, the schema search will be described in more detail with a specific example.
[0221]
(3) Specific examples
The client terminal 102 displays a search condition input screen for schema search as shown in FIG. On this input screen, it is assumed that the user has input, for example, a natural sentence having the content “a schema in which an author is described in an XML-related patent” as a schema to be searched.
[0222]
In the client terminal 102, the input content is converted into a schema query as shown in FIG. 45 by natural sentence analysis, for example, and transmitted to the structured document management system 100.
[0223]
In this example, the user inputs a natural sentence for schema search. However, the present invention is not limited to this. For example, (Condition 1) What character string is an element name (or attribute value), element value ( Alternatively, it is not necessary to input a natural sentence as long as the contents include whether it is included as (attribute value) or (condition 2) what kind of document structure is desired to be extracted. In addition, separate input areas for inputting the conditions 1 and 2 may be provided. Alternatively, only condition 1 may be input. When the condition 1 is input, it is sufficient that at least one character string is input, and a plurality of character strings may be input while being separated by a comma or the like.
[0224]
The character string specified as condition 1 may be an element name of an element, an attribute name, an element value, or an attribute value. You may make it input from an input area, or provide only one input area and create a schema query by predetermining that the character string input there is any one of them. May be. Also, the character string input as condition 2 may be an element name of an element or an attribute name. These may be input from separate input areas, or one input Only a region may be provided, and a character string input therein may be determined in advance as being one of these, and a schema query may be created.
[0225]
Moreover, only condition 1 may be sufficient, and only condition 2 may be sufficient.
[0226]
In the client terminal 102, a plurality of types of schema query templates that can be completed by substituting the character strings corresponding to the conditions 1 and 2 (for example, the schema query and the condition 2 when the conditions 1 and 2 are specified) Schema query when only one is specified, schema query when multiple character strings are specified in condition 2, etc.), and select one of them according to the input (specified) condition Then, a schema query may be created by substituting a character string corresponding to condition 1 or condition 2 into the blank part.
[0227]
Further, the client terminal 102 may transmit the character string or natural sentence input by the user corresponding to the above condition 1 or 2 as a search request to the structured document management system as it is. In this case, the schema query may be generated in the request receiving unit 11 of the structured document management system that has received such a search request. The same applies to the case where the request reception unit 11 creates a schema query.
[0228]
In the case of the input content shown in FIG. 44, the character strings corresponding to condition 1 are “XML” and “book”, the former is a character string included in the element value, for example, and the latter is, for example, an element name or attribute It is a character string included in the name. Further, the character string corresponding to the condition 2 is “patent”, and for example, it is determined that the character string is included in the element name, and as a result, a schema query as shown in FIG. 45 is created.
[0229]
The schema query is passed to the schema search processing unit 303 via the request reception unit 11 of the structured document management system 100. Alternatively, it is created by the request receiving unit 11 and passed to the schema search processing unit 303.
[0230]
First, the schema query analysis unit 321 analyzes the where section of the schema query (step S301 in FIG. 43). This processing operation will be described with reference to the flowchart shown in FIG.
[0231]
In the “where” section, a character string corresponding to the condition 1 describes a component of an element name (tag name) “xsp: elem” one by one. When representing a character string (for example, “book” in this case) included in the element name of the component (or one of the element name and attribute name), “type =“ element ” "" Is specified. When a character string (for example, “XML” in this case) included in the element value (or any one of the element value and the attribute value) of the constituent element is represented, “type = “Word” is designated. Also, it is included in either the element name of the component (or one of the element name and attribute name) and the element value of the component (or one of element value and attribute value) When representing a character string, “type =“ all ”” is designated for the character string.
[0232]
First, components in the where clause are taken out one by one (step S401), and it is checked whether each element is one of the above (steps S402 to S404).
[0233]
In the case of the schema query shown in FIG. 45, since the first element describes “type =“ element ”” for the character string “author” (step S402), the process proceeds to step S405. Here, a process of searching for a component having a character string of “book” and a character string of a vocabulary similar to this as an element name (matching or including the element name) is performed (structure estimation process).
[0234]
In the second element, since “type =“ word ”” is described for the character string “XML” (step S403), the process proceeds to step S406. For example, here, “XML” is used. And a component having a character string of a vocabulary similar to this as an element value (matching the element value or included in the element value) is searched (vocabulary estimation processing).
[0235]
If there is a character string described as “type =“ all ”” as a component in the where clause (step S404), the character string and the character string are added to the character string in the same manner as in steps S405 and S406. Processing for searching for a component having a similar character string as an element name or element value is performed (steps S407 and S408).
[0236]
The processes in steps S401 to S408 are repeated for all the components in the where clause.
[0237]
Here, taking the case where the character string to be processed is “author” as an example, the structure estimation processing in steps S405 and S407 will be described with reference to the flowchart shown in FIG.
[0238]
First, a synonym of “book” is extracted using a semantic network (step S411). Here, since the similarity threshold value is not specified (the sim attribute is not described), the network is expanded until it becomes equal to or less than a predetermined threshold value (here, set to “0.6”). . In the case of the semantic network shown in FIG. 41, “author” (similarity is “1.0”), “author” (similarity is “0.8” × “0.8”), “name” (similarity) The degree is “0.7”).
[0239]
Next, the element name occurrence index stored in the index storage unit 6 is searched in the same manner as in the document search described above, and each of the character string to be processed and the extracted similar word is changed to the element name. Is acquired, and further, for example, based on the description on the table or template tree as described above, the template ID corresponding to each of the acquired object IDs is acquired (step S412). .
[0240]
Then, an evaluation value (first evaluation value) is obtained for each template ID (step S413). The first evaluation value may be anything as long as it evaluates how much the component corresponding to the acquired template ID is similar to the character string (vocabulary) specified as the search condition.
[0241]
For example, when the current XML database is in a state as shown in FIG. 46, the template IDs acquired in step S412 are “TID7”, “TID15”, and “TID57”, and these evaluation values are For example, by using the vocabulary similarity included in the element name as it is, for example, the evaluation value of “TID7” is “1.0”, the evaluation value of “TID15” is “0.7”, and “TID57 The evaluation value is “0.64”. Each template ID and its evaluation value are recorded in the list L1. At this time, for each of the acquired template IDs, the object ID corresponding to the template ID and the number thereof are also recorded in the list L1.
[0242]
Next, taking the case where the character string to be processed is “XML” as an example, the vocabulary estimation processing in steps S406 and S408 will be described with reference to the flowchart shown in FIG.
[0243]
First, a similar word “XML” is extracted using a semantic network (step S421). In this case, “XML” (similarity “1.0”), “SGML” (similarity “0.72”), and “structured document” (similarity “0.81”) are obtained (step S421). .
[0244]
Next, in the same manner as in the above-described document search, the data occurrence index stored in the index storage unit 6 is searched, and each character string to be processed and each vocabulary of the extracted similar words are searched. The object ID of the constituent element included in the element value is acquired, and further, for example, based on the description on the table or template tree as described above, the template ID corresponding to each of the acquired object IDs is acquired (step S422).
[0245]
Then, an evaluation value (second evaluation value) is obtained for each template ID (step S423). This second evaluation value indicates how similar the component corresponding to the acquired template ID is to the character string (vocabulary) specified as the search condition, and the character string (vocabulary) specified as the search condition. As long as it is a component that evaluates how many of the above and similar words are included, it may be anything.
[0246]
The component corresponding to each acquired template ID may have some or all of the plurality of vocabularies as element values. In addition, a plurality of object IDs of components corresponding to the acquired template ID may be acquired from the data occurrence index.
[0247]
Here, for example, for each acquired template ID, the evaluation value is given based on which vocabulary of the plurality of vocabularies includes the element value corresponding to the component ID of the template ID. Alternatively, the number of object IDs (obtained from the data occurrence index) corresponding to each template ID may be obtained by multiplying the lexical similarity.
[0248]
For example, when the current XML database is in a state as shown in FIG. 46, in step S422, a component (template ID “TID6”) having an element name “title”, and “TID17” and “TID58” are also added. Template ID is obtained.
[0249]
The component “title” of the template ID “TID6” is searched from the vocabulary “XML” (similarity is “1.0”) and the vocabulary “SGML” (similarity is “0.72”). Therefore, for example, the similarity of these vocabularies is added to give 1 + 0.72 = 1.72 as the evaluation value. For example, if the number of object IDs searched with the vocabulary “XML” is 100 and the number of object IDs searched with the vocabulary “SGML” is 50, 1 × 100 + 0.72 × 50 = 136 It may be an evaluation value. In the following description, the calculation of the evaluation value is assumed to be the former example for simplicity of description.
[0250]
Since the component of the template ID “TID17” is searched only from the vocabulary “XML”, the similarity “1.0” of this vocabulary is given as an evaluation value.
[0251]
Since the component of the template ID “TID58” is searched only from the vocabulary “XML”, the similarity “1.0” of this vocabulary is given as an evaluation value.
[0252]
Each template ID and its evaluation value (second evaluation value) are recorded in the list L2. At this time, for each of the acquired template IDs, the object ID corresponding to the template ID and the number thereof are also recorded in the list L2.
[0253]
The following template ID is obtained from the processing of the where clause. In the parentheses, the second evaluation value is indicated by a number starting from “D”, and the first evaluation value is indicated by a number starting from “S”.
[0254]
{TID6 (D1.72), TID7 (S1.0), TID15 (S1.0), TID17 (D1.0), TID57 (S0.64), TID58 (D1.0)}
Next, the schema query analysis unit 321 analyzes the return clause of the schema query (step S302 in FIG. 43). This processing operation will be described with reference to the flowchart shown in FIG.
[0255]
In the return section, the element name and attribute name of the first component of the document structure to be extracted are described one by one in the component of the element name (tag name) “xsp: elem”. In the schema query shown in FIG. 45, “patent” is designated as the character string included in the element name.
[0256]
First, elements (components having an element name “xsp: elem”) are extracted one by one from the return clause (step S431), and a character string described in the element, for example, “patent” in this case, is processed. As a character string, structure estimation processing is performed as shown in FIG. 55 (step S432). The above steps S431 to S432 are performed for all elements described in the return clause (step S433).
[0257]
In the structure estimation process, similar words to those described above are first extracted using the semantic network.
[0258]
In this case, “patent” (similarity “1.0”) and “patent” (similarity “0.8”) are extracted.
[0259]
For example, when the current XML database is in a state as shown in FIG. 46, when a component having one of the two vocabularies as an element name is obtained from the element name occurrence index, the following three template IDs are obtained. can get.
[0260]
{TID4 (S1.0), TID55 (S0.8), TID72 (S1.0)} In FIG. 46, components (nodes) corresponding to the three template IDs are circled.
[0261]
Next, the process of step S303 in FIG. 43 is performed. That is, the component that is the head of the document structure of one XML document is extracted from the template tree from the component obtained as a result of processing the where clause and the component obtained as a result of processing the return clause. Specifically, the parent-child relationship on the template tree between the component extracted by the process of the return clause and the component extracted by the process of the where clause is checked.
[0262]
The component extracted by the process of the where clause is a component downstream of the document structure, and the component extracted by the process of the return clause is the first component of the document structure.
[0263]
For example, if the component extracted by the process of the where clause exists below the node corresponding to the component extracted by the process of the return clause, the component extracted by the process of the return clause is extracted. The candidate is registered in the output candidate list as a candidate for the first component of the document structure to be processed.
[0264]
Hereinafter, a case where the XML database is in a state as shown in FIG. 46 will be described as an example. In this case, the structure of the template tree is the same as that in FIG. However, as shown in FIG. 46, vocabularies such as “XML” and “SGML” are not included in the template tree. Also, in FIG. 46, the attributes of the constituent elements are shown surrounded by double rectangles.
[0265]
First, the template tree is searched upstream from the components on the downstream side to check the parent-child relationship.
[0266]
For example, the parent element of the constituent element of the template ID “TID6” (the constituent element in the hierarchy one level above and including the constituent element of the template ID “TID6”) is the configuration of the template ID “TID4”. Is an element. Since the constituent element of the template ID “TID4” is the constituent element extracted by the process of the return clause, the template ID “TID4” is added to the output candidate list at this time.
[0267]
Subsequently, with respect to the constituent element of the template ID “TID7”, the template ID “TID4” is also the parent element as described above. Since the template ID “TID4” has already been registered in the output candidate list, the process proceeds to the next.
[0268]
The parent element of the template ID “TID15” is a constituent element of the template ID “TID14”, but this is not a constituent element extracted by the process of the return clause, and therefore goes back further upstream. There is “TID13” in the hierarchy one level above “TID14”, “TID12” in the hierarchy one level above, and “TID1” in the hierarchy one level above. Since none of these is a component extracted by the processing of the return clause, the template ID “TID15” is excluded from the schema search.
[0269]
Similarly, the template ID “TID17” is also excluded.
[0270]
Each of the template ID “TID57” and the template ID “TID58” has a template ID “TID55” on the upstream side, and this is a component extracted by the process of the return clause, so that the template ID “TID55” is output to the output candidate list. Register with.
[0271]
At this time, “TID4” and “TID55” are registered in the output candidate list.
[0272]
Next, the template tree is searched from upstream to downstream to check the parent-child relationship.
[0273]
The template IDs extracted for the processing of the return clause were “TID4”, “TID55”, and “TID72”. Of these, “TID4” and “TID55” were already registered in the output candidate list. . Therefore, for example, the remaining “TID 72” is additionally registered in the output candidate list. Of course, in this case, “TID 72” may not be registered in the output candidate list.
[0274]
At this time, “TID4”, “TID55”, and “TID72” are registered in the output candidate list.
[0275]
Next, a component group to be extracted is extracted from the document structure starting with the previously extracted component by the schema estimation process in step S304 of FIG.
[0276]
As shown in FIG. 46, the constituent elements constituting the document structure starting with “TID4” are {TID4 (S1.0), TID5, TID6 (D1.72), TID7 (S1.0), TID8, TID9, TID10, TID11} (see FIG. 47).
[0277]
First, based on the information described in the template tree as shown in FIG. 37 (for example, the value of the attribute “required”), the document structure starting with “TID4” is constructed from these components. Select the components that are absolutely necessary to do this.
[0278]
Among the above components, those designated as essential for constructing the document structure starting with “TID4” on the template tree (that is, a configuration in which the attribute value “required” is “yes”) Elements) are “TID5”, “TID6”, “TID7”, and “TID8”, so that a document structure (schema) including these components can be obtained as one of the search results.
[0279]
FIG. 48 shows a schema document (XML document) when the document structure is described in XMLSCHEMA. <Xsd: sequence> is added to this document.
[0280]
Similarly, the constituent elements constituting the document structure starting with “TID55” are {TID55, TID56, TID57, TID58} (see FIG. 49). All of these components are designated as essential for constructing the document structure starting with “TID55” on the template tree, so that the document structure (schema) consisting of the above component group is the other search result. One can be obtained.
[0281]
FIG. 50 shows a schema document (XML document) when the document structure is described in XMLSCHEMA.
[0282]
Similarly, a group of components constituting the document structure starting with “TID72” is {TID72, TID73, TID74, TID75} (see FIG. 51). Since all these components are designated as essential for constructing the document structure starting with “TID72” on the template tree, the document structure (schema) consisting of the above-described component group is the other search result. It can be obtained as one of the following. In the template tree as shown in FIG. 37, for the constituent element of “TID75”, information defining the numerical type, that is, “dataType” is described. Numeric type schema is set.
[0283]
In this manner, when the top component of the document structure is obtained in step S303 of FIG. 43, in step S304, a group of components constituting the document structure starting with the component is extracted from the template tree. At this time, as described above, the component to be extracted may be selected based on the description of each component described in the template tree, or the document structure may be configured without selection. You may extract all the components to do.
[0284]
Further, the extracted document structure is converted into an XML document, that is, a schema document as shown in FIGS. When converting to this schema document, the attribute (for example, numeric type) of each component is described based on the information described for the component on the template tree.
[0285]
As described above, the template tree describes all the information used when searching the schema and creating the schema document as an XML document as shown in FIG.
[0286]
Next, the process proceeds to step S305 in FIG. 43, and an evaluation score (score) is calculated for each schema obtained as a search result.
[0287]
For example, when the constituent element group constituting the schema starting from the constituent element of the template ID “TID4” obtained as a search result is shown together with the first evaluation value (S) and the second evaluation value (D). , {TID4 (S1.0), TID5, TID6 (D1.72), TID7 (S1.0), TID8, TID9, TID10, TID11}. The evaluation point of this schema is the sum of the first evaluation value and the second evaluation value given to each component, and is S1.0 + S1.0 + D1.72 = 3.72.
[0288]
Here, when calculating the sum, weights may be set for the first evaluation value and the second evaluation value, respectively. In the case of the above example, the weight is calculated as “1” for each of the first evaluation value and the second evaluation value.
[0289]
Moreover, when the component group which comprises the schema which begins with the component of template ID "TID55" obtained as a search result is shown with the 1st evaluation value (S) and the 2nd evaluation value (D), For example, it is assumed that {TID55 (S0.8), TID56, TID57 (S1.0), TID58}. The evaluation score of this schema is S0.8 + S1.0 = 1.8 when calculated in the same manner as described above.
[0290]
Furthermore, when the constituent element group constituting the schema starting from the constituent element of the template ID “TID72” obtained as a search result is shown together with the first evaluation value (S) and the second evaluation value (D). , {TID72 (S1.0), TID73, TID74, TID75}. The evaluation score of this schema is “1.0” when calculated in the same manner as described above.
[0291]
Next, the process proceeds to step S306 in FIG. 43 to generate output data.
[0292]
Here, for example, in step S304, the evaluation score obtained in step S305 is written in the schema document of each schema extracted as a search result, and the schema document is collected as one XML document, for example, in FIG. Create the output data as shown. The XML document shown in FIG. 52 is for arranging and displaying schema documents in descending order of evaluation score.
[0293]
The output data (search result document) as shown in FIG. 52 created by the schema search processing unit 303 (along with a style sheet for displaying the search result document as necessary) is output from the result processing unit 12. Are transmitted to the client terminal 102.
[0294]
When the client terminal 102 receives the search result document shown in FIG. 52, the client terminal 102 displays the search result document using the style sheet sent (or predetermined) together with the search result document. The schema selected by the user is displayed using a style sheet sent together with the search result document (or predetermined). FIG. 53 shows a display example of the schema obtained as a search result. The first schema in the search result document shown in FIG. 52 (document structure starting with the component of template ID “TID4”). A display example is shown.
[0295]
In the display example shown in FIG. 53, an input area is provided so as to be an input form as it is.
[0296]
Note that the storage position (structured document path) of the XML database having the schema obtained as a search result on the hierarchical structure of the XML database is the same as the position of the schema on the template tree. When a new XML document created by inputting data from the input form shown is stored in the XML database, the structured document path may be used to specify a path for an insert command or an additional command. Therefore, the user can store the new XML document in an appropriate storage position on the XML database without wondering where to store the newly created XML document.
[0297]
In this way, when a new XML document is created using the search result of the document structure, XML documents that are similar in content (belonging to the same category) have almost the same document structure (to prevent schema overflow). In addition, since the user does not bother to specify the storage location on the XML database, XML documents that are similar in content (belonging to the same category) can be easily managed on the XML database. (For example, in FIG. 46, if a document starts with a component having the element name “patent” in FIG. 46, all of them are stored under the “patent DB” node).
[0298]
Next, on the search condition input screen for schema search, the user selects the above-mentioned (condition 1), for example, “XML-related schema”, that is, the element name, element value, or attribute value as the schema to be searched. Suppose that you enter a search condition that specifies only the character string included in. In this case, there is only a vague request at the keyword level.
[0299]
When such a search condition is input, the client terminal 102 or the request reception unit 11 of the structured document management system searches, for example, a search request statement for searching a document structure including the character string “XML” in the element value. Assume that (schema query) is created.
[0300]
This schema query is processed in the same manner as described above by the schema search processing unit 303 of the structured document management system having the XML database as shown in FIG. In the processing of the where clause, “TID6”, “TID17”, “TID6” are used as template IDs of components having element values of “XML” and a character string (for example, “SGML”) representing a vocabulary similar thereto. TID58 "is extracted by the vocabulary estimation process. Since the similarity of “XML” is “1.0” and the similarity of “SGML” is “0.64”, when these extracted components are shown together with their evaluation values, {TID6 (D1 .67), TID17 (D1.0), TID58 (D1.0)}.
[0301]
Next, the process of the return clause is performed. In this case, there is no condition specified by the user as described in the return clause. In this case, in the return clause of the schema query, for example, “<xsp: return type =“ all ”/>” is described, so the schema search processing unit 303 determines the root node of the document on the template tree. (In other words, as described above, since the attribute value “document” is described in the top component of one XML document on the template tree, the root node can be determined by checking this attribute value. The document structure starting from the root node from the template tree and including any of the components (“TID6”, “TID17”, “TID58”) extracted by processing the where clause The document structure will be extracted.
[0302]
That is, in this case, the process proceeds to step S303 in FIG. First, the component of the template ID “TID6” is traced back to the upstream to reach “TID4” (see FIG. 46). For this component, the description of the template tree as shown in FIG. 37 is checked. Then, since “<xsp: Node type =“ document ”>” is described in this component, the document structure starting with “TID4” is set as an extraction candidate. That is, “TID4” is registered in the output candidate list.
[0303]
Similarly, “TID14” and “TID5” 8 are also added to the output candidate list.
[0304]
In other words, at this point, the document structure to be extracted is
(1) {TID4, TID5, TID6, TID7, TID8, TID9, TID10, TID11}
(2) {TID14, TID15, TID16, TID17}
(3) {TID55, TID56, TID57, TID58}
There are three document structures.
[0305]
Of the components constituting the above three document structures, only the essential components are selected based on the description of the template tree, and the component group (schema) to be extracted is extracted (FIG. 43). Step S304).
[0306]
Further, an evaluation score is obtained for each schema obtained as a search result (step S305 in FIG. 43), and output data is created.
[0307]
As described above, when a schema is set in advance for the retrieved schema (when it is a schema of a document described according to a predetermined schema), a schema document describing the schema is changed. You may search from an XML database and use it as a schema for search results.
[0308]
Further, schema information may be additionally notified to the client together with the data for the search result by XQuery or the like. The result of searching with XQuery is only data, and there is a part where the structure is difficult to see, but it is possible to complement it. In addition, by describing the cumulative counts for the template elements as the result information, browsing them makes it easy to grasp the paths in the database and their frequencies at a glance.
[0309]
Further, the access authority may be set for each component on the template tree. For example, it is assumed that there are a department A and a department B, and XML documents in the respective jurisdiction ranges are stored in a predetermined area on the XML database. In this case, the department B cannot access the jurisdiction document of the department A, but the document B may be set with an access authority such as publishing if only the schema is available. By publishing the schema, for example, when application linkage in department A and department B is performed later, cost reduction can be achieved without absorbing the difference between the schemas.
[0310]
Also, when trying to store various documents in the XML database, it is often difficult to know where this data is suitable for storage, and it is often only temporarily stored in an appropriate location. In that case, the information is often buried. Under the management of the XML database, they are managed on the server side and are represented as one XML tree. Therefore, a guideline indicating where to store the document to be stored is also provided. Furthermore, the storage location does not have to be a folder and may be a partial document. Therefore, it is possible to reduce schema flooding as much as possible.
[0311]
As described above, according to the above-described embodiment, a desired schema and a position in the XML database from which the schema is extracted from an ambiguous condition whose structure and vocabulary are not determined are determined from the XML database having a hierarchical structure. It is possible to easily search with or without an explicit definition of.
[0312]
【The invention's effect】
As described above, according to the present invention, a document structure can be efficiently searched based on a vague search condition from an XML database having a hierarchical structure.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration example of a structured document management system according to an embodiment of the present invention.
FIG. 2 is a diagram showing a usage form of the structured document management system shown in FIG. 1, and shows a case where the structured document management system is operating on the back end of the WWW.
FIG. 3 is a diagram showing an example of a structured document described in XML.
4 is a diagram schematically showing the document structure of the structured document in FIG. 3;
FIG. 5 is a diagram for explaining the function of an additional command, and shows a case where the additional command is executed in the initial state of the structured document database.
6 is a view showing a processing result when an acquisition command is executed on the structured document database in the state shown in FIG.
FIG. 7 shows a case where a document object tree of one “patent” information is added to the structured document database in the state shown in FIG. 5B by executing an add command.
FIG. 8 shows a case where a document object tree of three “patent” information is added to the structured document database in the state shown in FIG. 5B by executing an add command.
FIG. 9 is a diagram showing a storage example of an element name occurrence index.
FIG. 10 is a diagram showing a storage example of a data occurrence index.
11 is a diagram showing an execution result when an acquisition command for extracting three pieces of “patent” information is executed on the structured document database in the state shown in FIG. 8. FIG.
FIG. 12 is a diagram showing an example of a schema that defines the document structure of an XML document.
13 is a diagram showing a case where a schema storage command is executed in the structured document database in the state shown in FIG. 8 and the schema shown in FIG. 12 is additionally stored (set).
FIG. 14 is a diagram showing a document object tree in which a schema is set and an attribute value indicating that the schema exists is set.
FIG. 15 is a diagram conceptually illustrating a state in which attribute values indicating that a schema exists are stored in each object file.
FIG. 16 is a diagram showing an example in which a conceptual hierarchy used in a search is expressed as a structured document as necessary.
FIG. 17 is a diagram showing an example in which a conceptual hierarchy used in a search is expressed as a structured document as necessary.
18 is a diagram showing a case where a document object tree of “concept” information shown in FIGS. 16 and 17 is added to the structured document database in the state shown in FIG. 8 by executing an add command.
19 is a diagram showing a case where a document object tree of “concept” information shown in FIGS. 16 and 17 is added to the structured document database in the state shown in FIG. 8 by executing an add command.
FIG. 20 is a diagram showing an example of a query (XML document).
FIG. 21 is a diagram showing an example of a simple search query (XML document).
FIG. 22 is a diagram showing search results (XML document) using the simple search query of FIG. 21;
FIG. 23 is a diagram showing an example of a concept search query (XML document).
24 is a flowchart for explaining the document search processing operation of the structured document management system in FIG. 1. FIG.
FIG. 25 is a diagram showing a display example of a screen as a user interface.
FIG. 26 is a diagram showing a display example of a screen as a user interface for performing a document search.
FIG. 27 is a diagram showing a query created based on information input from the screen shown in FIG.
FIG. 28 is a flowchart for explaining the document acquisition processing operation of the structured document management system of FIG. 1;
FIG. 29 is a diagram showing a display example of a structured document obtained as a result of executing a document acquisition command.
FIG. 30 is a display example of a screen as a user interface for performing a document search, for explaining a schema search processing operation;
FIG. 31 is a diagram showing an example of a schema search query.
FIG. 32 shows a display example of a screen as a user interface for acquiring a schema, and shows a display example of the acquired schema.
FIG. 33 is a diagram illustrating a configuration example of a template processing unit.
FIG. 34 is a diagram showing an example of a template tree.
FIG. 35 is a diagram showing a specific example of an XML document.
36 is a diagram showing the template tree shown in FIG. 34 after being updated.
FIG. 37 is a diagram showing a storage example of a template tree.
FIG. 38 is a diagram showing a configuration example of a schema search processing unit 303.
FIG. 39 is a diagram showing an example of a schema query.
FIG. 40 is a diagram showing another example of a schema query.
FIG. 41 is a diagram showing a specific example of a semantic network.
FIG. 42 is a flowchart for explaining processing for obtaining a similar word of a keyword specified as a search condition using a semantic network.
FIG. 43 is a flowchart for explaining the processing operation of the schema search processing unit.
FIG. 44 is a diagram showing a display example of a search condition input screen for schema search.
45 is a diagram showing an example of a schema query created based on a search condition input from the input screen shown in FIG. 44.
FIG. 46 is a diagram showing a specific example of a template tree.
FIG. 47 is a diagram showing a document structure obtained as a result of search.
48 shows an example of an XML document describing the document structure shown in FIG. 47. FIG.
FIG. 49 shows another document structure obtained as a result of the search.
50 is a diagram showing an example of an XML document describing the document structure shown in FIG. 49. FIG.
FIG. 51 is a diagram showing still another document structure obtained as a result of the search.
FIG. 52 is a diagram showing an example of output data.
FIG. 53 is a diagram showing a display example of a schema obtained as a search result.
FIG. 54 is a flowchart for explaining a processing procedure of a where clause in a schema query.
FIG. 55 is a flowchart for explaining structure estimation processing;
FIG. 56 is a flowchart for explaining vocabulary estimation processing;
FIG. 57 is a flowchart for explaining the processing procedure of a return clause in a schema query.
[Explanation of symbols]
100 ... structured document management system
303 ... Schema search processing unit
306 ... Template processing unit
306a ... Structure extraction unit
306b ... Template tree processing unit
321 ... Schema query analysis unit
322 ... Schema query condition processing unit
323 ... Schema query output processing unit
404 ... Template storage unit
405 ... Meaning network storage unit

Claims (15)

Documents stored in the same storage location on the hierarchical structure on a logical structure including each document structure of a plurality of structured documents stored in a database having a hierarchical structure and a storage location on the hierarchical structure Storage means for storing a template tree in which constituent elements common to a plurality of structured documents having the same structure or a part of the same are aggregated into one and expressed as one constituent element;
Processing means for performing processing for retrieving a desired document structure from different document structures of a plurality of structured documents stored in the database;
A document structure search method in a document structure search apparatus comprising:
A step of obtaining a similar word of a keyword input as a search condition for the processing means to search the document structure;
The processing means for searching for a constituent element including any one of the keyword and the similar word in an element name or an element value from the hierarchical structure composed of the constituent elements constituting the different document structures; When,
The processing means detects the first component of the document structure including the searched component by tracing the template tree upstream from the searched component, and from the template tree, An extraction step of extracting the document structure starting from the detected component ;
An output step in which the processing means outputs the extracted document structure as a search result;
Document structure search method including In the template tree , first attribute information indicating that the constituent element is the first constituent element is added to the first constituent element of the document structure corresponding to each of the plurality of structured documents. ,
The extraction step is based on it said first attribute information, document structure search method according to claim 1, wherein the extracting the document structure as the search result from the template tree. The template tree indicates that the constituent element is an essential constituent element with respect to the constituent elements essential to the document structure among the constituent elements constituting the document structure corresponding to each of the plurality of structured documents. Second attribute information is added,
The extraction step is based on said second attribute information, document structure search method according to claim 1, wherein the extracting the document structure comprising the essential components from the template tree. The processing means further includes a step of obtaining an evaluation value of the document structure extracted in the extraction step based on the similarity between the keyword and the element name or element value of the searched component ,
2. The document structure search method according to claim 1 , wherein the output step outputs the extracted document structure as the search result together with the evaluation value. Documents stored in the same storage location on the hierarchical structure on a logical structure including each document structure of a plurality of structured documents stored in a database having a hierarchical structure and a storage location on the hierarchical structure Storage means for storing a template tree in which constituent elements common to a plurality of structured documents having the same structure or a part of the same are aggregated into one and expressed as one constituent element;
Processing means for performing processing for retrieving a desired document structure from different document structures of a plurality of structured documents stored in the database;
A document structure search method in a document structure search apparatus comprising:
The processing means obtaining a similar word of the first keyword and the second keyword input as a search condition for searching the document structure;
The processing means includes a first name including one of the first keyword and its similar word in an element name or an element value from the hierarchical structure configured by each component configuring each of the different document structures . A first search step for searching for a component ;
A second search step in which the processing means searches for a second component that includes any one of the second keyword and its similar words in the element name from the hierarchical structure ;
When the processing means reaches the second component element by tracing the template tree upstream from the first component element, the second component element starts from the template tree. An extraction step for extracting the document structure ;
An output step in which the processing means outputs the extracted document structure as a search result;
Document structure search method including In the template tree , first attribute information indicating that the constituent element is the first constituent element is added to the first constituent element of the document structure corresponding to each of the plurality of structured documents. ,
6. The document structure search method according to claim 5 , wherein the extraction step extracts a document structure as the search result from the template tree based on the first attribute information. The template tree indicates that the constituent element is an essential constituent element with respect to the constituent elements essential to the document structure among the constituent elements constituting the document structure corresponding to each of the plurality of structured documents. Second attribute information is added,
6. The document structure search method according to claim 5 , wherein the extracting step extracts a document structure including the essential components from the template tree based on the second attribute information. The processing means includes a first similarity between the element name or element value of the first component and the first keyword, and a first similarity between the element name of the second component and the second keyword. Further comprising the step of obtaining an evaluation value of the document structure extracted in the extraction step based on the similarity of 2 ;
6. The document structure search method according to claim 5 , wherein the output step outputs the extracted document structure as the search result together with the evaluation value. A document structure search device for searching a desired document structure from different document structures of a plurality of structured documents stored in a database having a hierarchical structure,
A document structure stored in the same storage position on the hierarchical structure on a logical structure including the document structure of each of the plurality of structured documents stored in the database and the storage position on the hierarchical structure. Storage means for storing a template tree in which constituent elements common to a plurality of structured documents that are the same or partially the same are aggregated into one constituent element;
Input means for inputting at least one keyword as a search condition for searching the document structure;
Means for obtaining a similar word of the keyword input by the input means;
Search means for searching for a constituent element including any one of the keyword and the similar word in an element name or an element value from the hierarchical structure constituted by each constituent element constituting each of the different document structures;
By tracing the template tree upstream from the component searched by the search means, the first component of the document structure including the searched component is detected, and the template tree Extraction means for extracting the document structure starting from the detected component ;
Means for outputting the document structure extracted by the extraction means as a search result;
A document structure retrieval apparatus comprising: In the template tree , first attribute information indicating that the constituent element is the first constituent element is added to the first constituent element of the document structure corresponding to each of the plurality of structured documents. ,
10. The document structure search apparatus according to claim 9 , wherein the extraction unit extracts a document structure as the search result from the template tree based on the first attribute information.   The template tree indicates that the constituent element is an essential constituent element with respect to the constituent elements essential to the document structure among the constituent elements constituting the document structure corresponding to each of the plurality of structured documents. Second attribute information is added,
  10. The document structure search apparatus according to claim 9, wherein a document structure composed of the essential components is extracted from the template tree based on the second attribute information. A document structure search device for searching a desired document structure from different document structures of a plurality of structured documents stored in a database having a hierarchical structure,
A document structure stored in the same storage position on the hierarchical structure on a logical structure including the document structure of each of the plurality of structured documents stored in the database and the storage position on the hierarchical structure. Storage means for storing a template tree in which constituent elements common to a plurality of structured documents that are the same or partially the same are aggregated into one constituent element;
An input means for inputting at least one first keyword and at least one second keyword as a search condition for searching the document structure;
Means for obtaining a similar word of the first keyword input by the input means and a similar word of the second keyword;
A first component that includes either the first keyword or its similar word in an element name or an element value is searched from the hierarchical structure configured by the components that constitute each of the different document structures. A first search means for
Second search means for searching for a second component that includes any one of the second keyword and its similar word in an element name from the hierarchical structure;
When the second component is reached by tracing the template tree upstream from the first component, a document structure starting from the second component is extracted from the template tree. Extraction means;
Output means for outputting the document structure extracted by the extraction means as a search result;
A document structure retrieval apparatus comprising: In the template tree , first attribute information indicating that the constituent element is the first constituent element is added to the first constituent element of the document structure corresponding to each of the plurality of structured documents. ,
13. The document structure search apparatus according to claim 12 , wherein the extraction unit extracts a document structure as the search result from the template tree based on the first attribute information. A document structure search program for searching a desired document structure from different document structures of a plurality of structured documents stored in a database having a hierarchical structure,
The computer,
A document structure stored in the same storage position on the hierarchical structure on a logical structure including the document structure of each of the plurality of structured documents stored in the database and the storage position on the hierarchical structure. Storage means for storing a template tree in which constituent elements that are common to a plurality of structured documents that are the same or partially the same are aggregated into a single constituent element;
As a search condition for searching the document structure, the input means to enter at least one keyword,
Means for obtaining a similar word of the keyword input by the input means;
Search means for searching for a constituent element including any one of the keyword and the similar word in an element name or an element value from the hierarchical structure composed of the constituent elements constituting each of the different document structures;
By tracing the template tree upstream from the component searched by the search means, the first component of the document structure including the searched component is detected, and the template tree Extraction means for extracting the document structure starting from the detected component;
Means for outputting the document structure extracted by the extraction means as a search result;
Program to function as. A document structure search program for searching a desired document structure from different document structures of a plurality of structured documents stored in a database having a hierarchical structure,
The computer,
A document structure stored in the same storage position on the hierarchical structure on a logical structure including the document structure of each of the plurality of structured documents stored in the database and the storage position on the hierarchical structure. Storage means for storing a template tree in which constituent elements that are common to a plurality of structured documents that are the same or partially the same are aggregated into a single constituent element;
Input means for inputting at least one first keyword and at least one second keyword as a search condition for searching the document structure;
Means for obtaining a similar word of the first keyword input by the input means and a similar word of the second keyword;
A first component that includes either the first keyword or its similar word in an element name or an element value is searched from the hierarchical structure configured by the components that constitute each of the different document structures. A first search means for
A second search means for searching for a second component including, in the element name, any one of the second keyword and similar words from the hierarchical structure;
When the second component is reached by tracing the template tree upstream from the first component, a document structure starting from the second component is extracted from the template tree. Extraction means,
Output means for outputting the document structure extracted by the extraction means as a search result;
Program to function as .

Images