WO2009063925A1 - 文書管理・検索システムおよび文書の管理・検索方法 - Google Patents

文書管理・検索システムおよび文書の管理・検索方法 Download PDF

Info

Publication number
WO2009063925A1
WO2009063925A1 PCT/JP2008/070630 JP2008070630W WO2009063925A1 WO 2009063925 A1 WO2009063925 A1 WO 2009063925A1 JP 2008070630 W JP2008070630 W JP 2008070630W WO 2009063925 A1 WO2009063925 A1 WO 2009063925A1
Authority
WO
WIPO (PCT)
Prior art keywords
tag
document
index
word
key
Prior art date
Application number
PCT/JP2008/070630
Other languages
English (en)
French (fr)
Inventor
Yukitaka Kusumura
Toshiyuki Kamiya
Original Assignee
Nec Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nec Corporation filed Critical Nec Corporation
Priority to US12/741,302 priority Critical patent/US9454597B2/en
Priority to JP2009541163A priority patent/JP5376163B2/ja
Publication of WO2009063925A1 publication Critical patent/WO2009063925A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G06F16/313—Selection or weighting of terms for indexing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/3331—Query processing
    • G06F16/334—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/81—Indexing, e.g. XML tags; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/83—Querying
    • G06F16/835—Query processing

Definitions

  • the present invention relates to a technique for adding a tag to a partial character string in a document and managing and retrieving document information based on the tag.
  • the present invention relates to a technology that enables a phrase including a tag to be used as a processing request (query) for information retrieval.
  • Figure 2 shows an example of a tagged document.
  • “text” refers to data including at least a document number that is a unique identifier and a character string (main text) to be searched.
  • a “tag” is data added to one or more words in a document.
  • a tag example and a tag “person name” for “Taro Yamada j” from the 7th to 10th characters are shown.
  • a character string representing a tag such as “company name” or “person name” is called a tag name.
  • word refers to a partial character string of the text created based on some standard such as morphological analysis or N-gram (character string is divided into N characters).
  • Document management and search system that performs document management and search for text with such tags added.
  • the search system uses a function to add or delete tags to partial character strings in documents and phrases using tags.
  • a document search function Searching a document by a phrase using a tag means a function of inputting a continuous character string including a character string including a tag name and outputting a document set including the phrase.
  • “[company name] [person name]” is a phrase that uses tags.
  • the character string enclosed by “[J and“] ” is regarded as the tag name. If this phrase is taken as a search query, any word with the tag “company name”, “no”, or any word with the “person name” tag will appear in succession. Statement It means to return the book.
  • the tagged documents are expressed in a hierarchical structure description format such as XML (Extensible Markup Language), and A method using a search device XMLDB (XMLData Base) is known (for example, refer to Japanese Unexamined Patent Application Publication No. 2005-18811, hereinafter referred to as Patent Document 1).
  • XML Extensible Markup Language
  • Patent Document 1 Japanese Unexamined Patent Application Publication No. 2005-18811, hereinafter referred to as Patent Document 1
  • FIGS. Fig. 3 shows an example of expressing a document with a tag in XML
  • Fig. 4 shows a part of the document as a tree structure based on the inclusion relationship of tags
  • Fig. 5 manages hierarchical information.
  • the table to do is shown.
  • the ellipse node means a tag
  • the rectangular leaf node means text
  • the edge between them means that there is a containment relationship between those tags or text.
  • information called the path hierarchy is described under each node.
  • the path hierarchy is information indicating the position of each node in the document.
  • the path hierarchy is a number describing the position of a node with a delimiter (“.”).
  • the “Person Name” node in Figure 4 has a path hierarchy of “1. 1. 3”, which is 1 below the first node (the “Documents” node) as seen from the root.
  • the third node under the "th" node (the "body” node).
  • These hierarchical information are managed in a table as shown in Fig. 5. However, this table shows a logical relationship and is actually often expressed in multiple tables.
  • node ID, document number, text, tag name, and path hierarchy information are managed for the nodes in the document set.
  • Node ID is a unique identifier for all nodes in the document set.
  • the document number is an ID that indicates the document that contains the node.
  • a text is a character string included in a leaf node.
  • NULL shall be input for nodes that are not leaf nodes.
  • the tag name is the tag name of each node.
  • # t e x t is input to the leaf node.
  • the path hierarchy means the path hierarchy of each node. A method for searching for such information will be described by taking the operation of the search device disclosed in Patent Document 1 as an example.
  • This search device first decomposes a query into a plurality of search conditions. This query is broken down into three parts: A: the company name tag, B: the word “no” is included, and C: the person name tag. Next, this search device refers to the table shown in Fig. 5 based on each condition, and lists the nodes whose tag name is "company name” (A list) and the text " A list of nodes with “” (referred to as B list) and a list of nodes with tag name “name” (referred to as “C list”) are obtained.
  • this search device compares the nodes in the A list, B list, and C list, retrieves the combination of nodes with the same document number, extracts the “company name” node in the A list, and “in” in the B list. ”Node,“ person name ”in the C list Retrieve the nodes whose positional relationship is continuous in the same order as the query. This positional relationship is determined by comparing the path hierarchy. In the case of this query, the “company name” node, “no” node, and “person name” node are sibling nodes, and this search device creates a search result from nodes that satisfy the following three conditions.
  • Condition 1 The path hierarchy of the “company name” node, the path hierarchy of the “no” node, and the path hierarchy of the “person name” node match except for the number at the end;
  • Figure 6 shows an example of changing the path hierarchy by adding tags.
  • Figure 6 shows an example of adding a person name tag to a document.
  • the document structure before addition is shown on the left, and the document structure after addition and the update range of its path hierarchy are shown on the right.
  • the update range on the right indicates that the path hierarchy of the nodes in the range indicated by the dotted line needs to be updated.
  • the path hierarchy expresses the position of the node using the hierarchical structure of the entire document, so even if a part of the document is changed, it needs to be changed significantly.
  • the second problem is that the search takes a long time when the search query is a phrase consisting of only common words and high-frequency tag names. This is a general When searching with words or tags with high frequency, a large number of nodes are found when searching for nodes with individual conditions, so it is necessary to check the document numbers and positional relationships for a large number of nodes.
  • the problem is that the search speed decreases. For example, in the query “[company name] [person name]”, the query will be broken down into a company name tag, the word “no” included, and a person name tag. A list of nodes that meet each condition is retrieved. However, since each condition is too general, a large number of nodes are discovered, and a large amount of time is required to examine the positional relationship.
  • the document management / retrieval system using XM LDB indexes up to the hierarchical structure of the document, so it takes time to update (add or delete) tags and search. Therefore, as another method for realizing phrase search using tags, it is conceivable to use a transposed index that is used in full-text search indexes without using the hierarchical structure as indexes.
  • Figure 7 shows an example of an inverted index.
  • the number (frequency) of documents containing the word by inputting a word as a key, the number (frequency) of documents containing the word, the document number of the document containing the word, A list (hereinafter referred to as the document list) of the appearance positions of the words (entrance position, expressed by the number of characters from the front of the document) can be obtained.
  • the inverted index of the tag shown in (b) is used in addition to the normal inverted index shown in (a).
  • (B) is the same as the case of a word.
  • a tag document list For a tag with a tag name, the number (frequency) of documents that contain the tag, the document number that contains the tag, and the appearance position of the tag in the document. You can obtain a list (hereinafter referred to as a tag document list) of information (start position and end position, expressed by the number of characters from the front of the document).
  • Ne X tword index As a technique for reducing the length of the document list and speeding up the phrase search for a search query consisting of common words (HE Will iams, J. Zobel and D. Bahle, “Fast Phrase Querying with Combined Indexes”, ACM Transactions on Information Systems, 22 (4), pp. 573-594, 2004, hereinafter referred to as Non-Patent Document 1).
  • the N tex t o rd d index has a data structure in which a document list of common words with high frequency is divided based on the next word (assuming horizontal writing and this is called “right”).
  • N extword index a set of words (N extword) appearing to the right of a word is stored as a key. Furthermore, from the pair of the key word and one N e X tword, 2 You can refer to a document list for a set of documents in which two words appear next to each other.
  • Figure 9 shows an example of an index.
  • “Yamada” and “Company” are registered as N extwords of the word “no”, and for each, a document list of documents containing “No Yamada” and a document containing “Company” This means that the document list is registered.
  • the key consisting of two words (or conditions) is expressed as “A ⁇ B” (for example, “No ⁇ Yamada”, etc.), and A is the primary key and B is the secondary key. I will call it.
  • Non-Patent Document 1 uses this N e for high-frequency words.
  • the search speed is improved by using X two ⁇ d index.
  • the search system is: Search on. First, the normal transposed index is referenced for low-frequency words, and a document list corresponding to “abc industry” is obtained. Next, high frequency For N words, refer to the N extword index, and obtain the document list from “No ⁇ Yamada” and the reference. Furthermore, these two document lists are compared, and a set of documents with the same document and the same appearance position as the query is output. In this way, according to the Ne X t wo rd index, the document list can be read using the adjacency relationship between two words as a key, so the search speed can be improved.
  • FIG. 10 is a diagram for explaining that the tag update process takes time in a search system using the Nex two rd index.
  • a b c industry Yamada the range that needs to be updated when adding or deleting tags is shown.
  • FIG. 10 as shown in (a), for the string “abe industry Yamada”, the tag “noun” and “company name” for the abe industry, and “particle” for “no”. The tag [person name] is added to Yamada.
  • the eight dotted arrows in (a) represent the adjacent keys created in the Ne X tword index.
  • “A b c industry” in Figure 10 is assumed to be infrequent and stored in the normal inverted index.
  • the Ne x two rd index does not assume that a tag will be added, and if it is simply applied to a tagged document, there will be many places to be updated. There is a problem that it takes time. Note that this is because if a tag is used as a secondary key, references to a tag are dispersed. Disclosure of the invention:
  • the search device described in Patent Document 1 assumes not only a phrase search but also a query with a hierarchical tag structure (such as returning a document with the structure of “Z document body company name”). In order to have a hierarchical index, it took time to update the index.
  • the search device described in Patent Document 1 is based on the idea that a phrase is decomposed into individual word conditions and then searched according to individual conditions. If the pattern is simple, a large amount of information must be read out, and the search takes time.
  • Non-Patent Document 1 can reduce the amount of the document list that is read based on the adjacency relationship between two words. Since the adjacency relationship between words and tags was complicated, the tag update took time.
  • the present invention resolves such a problem, and in searching for a phrase including a tag, an efficient search for a query including a general phrase and a high-frequency tag, and an efficient update of the tag, It aims to provide a compatible document management ⁇ search system and document management ⁇ search method.
  • the document management / retrieval system originated from the present invention includes a word index storage unit for storing the appearance position of each word in the document set, and a tag indicating the attribute of the word added to the word.
  • the set of words appearing on the right and left of each tag is stored for the set, and each tag and the word appearing on the right, or the combination of each tag and the word appearing on the left are used as keys.
  • a tag LR index storage unit that stores the appearance position of each tag in the document set, and a phrase consisting of tags and words as input as a search query.
  • adjacent words and left and right of the tag in the phrase Refer to the tag LR index storage using the relationship of The document search part that returns a list of identifiers of documents that contain messages, and the query that adds or deletes tags to / from substrings in a specific document is interpreted, and the contents stored in the tag LR index storage part are updated.
  • a tag updating unit for updating the index in the word index storage unit when one or more documents are given.
  • an arbitrary character string is used as a key, and a high-speed tag value determination unit that enables high-speed reference to a set of tag names that may be attached to the character string is provided.
  • the document search unit stores the high-speed tag value determination unit and the tag LR index when a phrase with consecutive tags is input as a search query. It is desirable to include a means to execute a query by referring to the section and narrowing down to words that may contain a specific tag name.
  • a bit string storage unit that stores a bit string that represents a set of documents each containing the word and tag, with the high-frequency word and tag name as keys, and the document index creation unit stores bit strings when creating an index from the document.
  • the tag updating unit includes means for updating the bit string in the bit string storage unit based on the added / deleted tag when updating the tag, and the document search unit At the time of search, the bit string storage unit is referred to based on the high-frequency words and tag names included in the query in advance, and a set of document numbers including all the high-frequency words and tag names in the query is obtained. It is also possible to include means for narrowing down the document set and reading the position of the phrase in the document set.
  • a tag NLR index storage unit that stores each tag name as a key and a tag appearance position in the document set and the left and right words for the tag set, and the tag NLR index storage unit for the tag LR index It is also possible to provide conversion means for converting to index in the storage unit and management means for changing the index storage method based on the appearance frequency of the tag.
  • the document management / retrieval method of the present invention creates a document index that stores the appearance position of each word contained in a set of words included in the document when one or more documents are given. Add tags to steps and substrings in a specific document When a query to be added or deleted is given, the tag update step that stores the tag appearance position using the tag name as a key, and within this tag update step, the tag is input to the right and left of the tag.
  • a tag that memorizes the words that appear and also stores each tag and the word that appears on the right, or the position of each tag in the document set that uses the combination of each tag and the word that appears on the left as a key
  • multiple LR storage steps are used to interpret the search query and use the relationship between the adjacent words in the phrase and the left and right Create keys, and based on these keys, based on the keys stored in the document index creation step, based on the key locations stored in the tag update step. It includes a document search step of referring to the appearance positions of each tag and returning a list of identifiers of documents including the phrase by integrating them.
  • the document search step includes the step of updating the data representing the relationship between the tag name and the character string, and the document search step uses the fast tag value determination step when a search query is input for a phrase in which the tag name is continuous. It is desirable to include a step of reading the appearance position of the tag by narrowing down to only words that may contain the tag name.
  • the document index step includes a bit string storage step for storing a bit string representing a set of documents each including the word and the tag, using the frequent word and the tag name as a key.
  • the tag update step is added when the tag is updated.
  • the document search step includes the step of updating the bit string in the bit string storage unit based on the deleted tag, and the document search step stores the high-frequency word included in the search query and the tag name as a key in the bit string storage step.
  • the tag update step includes a tag NLR index step that stores each tag name in the document set as a key and a tag appearance position and the left and right words in the document set.
  • the tag update step and document search step Appearance position with tag as key
  • the tag NLR is selected based on the reference selection step and the tag frequency based on whether the tag is stored in the tag NLR index step or the tag LR update step. It can also include an index conversion step that deletes the data created in the index step and creates it in the tag LR index step.
  • the present invention can also be implemented as a computer program. That is, when one or more documents are given, a document index creation process for storing the appearance position of each word included in the set of words included in the document and a partial character in a specific document
  • a document index creation process for storing the appearance position of each word included in the set of words included in the document and a partial character in a specific document
  • a tag update process that stores the appearance position of the tag using the tag name as a key
  • a tag for the input tag within this tag update process The words appearing on the right and left of the tag are stored, and the position of each tag in the document set using the combination of each tag and the word appearing on the right, or the combination of each tag and the word appearing on the left as a key Tag LR storage processing, and when a phrase consisting of tags and words is given as a search query, the search query is interpreted and the adjacent words and tags in the phrase Create multiple keys using the left-right relationship of the words, based on the keys stored in the document indentation creation
  • Tag name when adding a tag in high-speed tag value judgment processing and tag update processing that can refer to a set of tag names that may be attached to the character string at high speed using an arbitrary character string as a key
  • tag update processing that can refer to a set of tag names that may be attached to the character string at high speed using an arbitrary character string as a key
  • a bit string storage process for storing a bit string representing a set of documents including the word and tag, using a high-frequency word and a tag name as a key in document index processing;
  • the update process when updating the tag, the process of updating the bit string stored in the bit string storage process based on the deleted tag and the high-frequency word and tag included in the search query in the document search process Refers to the bit string stored in the bit string storage process using the name as a key, obtains data representing a set of documents that contain all the high-frequency words and tag names in the query, and narrows down the document set based on that data. It is also possible to have the computer execute the process of reading the appearance positions of words and tags.
  • each tag name is used as a key for a set of tags, and the tag NLR index process that stores the appearance position of the tag in the document set and the left and right words is executed by the computer.
  • the tag is stored in the tag NLR index process.
  • the data created by the tag NLR index process can be deleted and the index conversion process created by the tag LR index process can be executed by the computer.
  • the present invention it is possible to refer to an index using a tag and a right or left word as a key for adjacent words and tags included in a query phrase at the time of search, and the amount of a document list to be read can be reduced. Search processing can be performed at high speed.
  • updating the tag it is possible to update the tag only by adding two updates to the tag LR index storage unit, and it is possible to update the tag at high speed only by performing a small amount of update.
  • FIG. 1 is a block diagram showing a first preferred embodiment of the present invention.
  • FIG. 2 shows an example of a tagged document.
  • FIG. 3 is a diagram showing an example in which a document with a tag is expressed in XML.
  • Fig. 4 is a diagram showing the path hierarchy used in XMLDB.
  • Figure 5 shows the logical structure of the index used in XMLDB.
  • Figure 6 shows the range that needs to be updated when adding tags in XM LDB.
  • FIG. 7 is a diagram showing an example of transposition indentus.
  • FIG. 8 is a diagram showing an example of the data structure of the N nex t w rd index.
  • FIG. 9 is a diagram showing an example of the N e Xt w rd index.
  • Fig. 10 is a diagram showing the range that needs to be updated when adding / deleting tags in a search system that uses the NeXtword index.
  • FIG. 11 is a diagram showing an example of transposition indentations assumed in the first embodiment of the present invention.
  • FIG. 12 is a diagram illustrating an example of data in the tag LR index storage unit.
  • FIG. 13 is a block diagram showing a second preferred embodiment of the present invention.
  • FIG. 14 is a block diagram illustrating a configuration example of the high-speed tag value determination unit.
  • FIG. 15 shows an example of a tag value table.
  • FIG. 16 shows an example of a list of inquiry tasks.
  • FIG. 17 shows an example of a document list column.
  • Figure 18 is a flowchart of the search process.
  • FIG. 19 is a diagram showing an example of a key string.
  • FIG. 20 is a flowchart of processing for creating a list of inquiry tasks.
  • Figure 21 is a flowchart of the query task execution process.
  • Figure 22 shows a flowchart of the document list integration process.
  • Fig. 23 is a diagram for explaining the positional relation check process, and shows four cases in the inquiry for each key.
  • Fig. 24 is a flowchart of the positional relationship check process.
  • Figure 25 illustrates the tag update process
  • FIG. 26 shows an example of a list of words, document numbers, and appearance positions.
  • FIG. 27 shows an example of a key string.
  • FIG. 28 is a block diagram showing a third preferred embodiment of the present invention.
  • FIG. 29 is a diagram illustrating an example of data stored in the bit string storage unit.
  • FIG. 30 is a block diagram showing a fourth preferred embodiment of the present invention.
  • FIG. 31 shows an example of the tag LR document list.
  • FIG. 32 shows an example of the management table.
  • Figure 33 shows a flowchart of processing when the index type is NLR.
  • Figure 34 is a flowchart of the Indettas optimization process. Best Mode for Carrying Out the Invention:
  • FIG. 1 is a block diagram showing a first preferred embodiment of the present invention, and shows a configuration example of a document management / retrieval system.
  • This document management / retrieval system includes a word index storage unit 13 that stores the appearance position of each word in the document set, and a set of tags that are added to the word and indicate the attribute of the word. For each tag, it stores a set of words that appear on the right and left of each tag, and also uses a combination of each tag and the word that appears on the right, or a combination of each tag and the word that appears on the left.
  • the tag LR index storage unit 14 stores the appearance position of each tag in the document set, and the search query is input as a phrase consisting of a tag and a word.
  • a document search unit 15 that returns a list of identifiers of documents that contain the phrase by referring to the tag LR index storage unit 14 using the left-right relationship between the word and the tag, and a partial character in a specific document
  • Tag LR index storage section 1 4 Update tag contents update section 1 2 and word index storage section when one or more documents are given 1 3 is provided with a document index creation unit 1 1 for updating the index in 3.
  • the word index storage unit 13 stores the transposed index (N) for the word.
  • An inverted index means data that can be referred to a set of document numbers and positions of occurrence of documents in a document set using the word as a key.
  • Fig. 11 shows an example of the inverted index assumed in this embodiment.
  • the word “Yamada” is used as a key
  • the word “Yamada” appears twice in the document set, appears once in the document with the document number 3 3 3 3
  • the appearance position is 7 characters from the front. Eye It also indicates that it appears twice in the document with the document number 3 46 and the appearance position is the 4th and 20th characters from the front.
  • the word index storage unit 13 receives a set of data consisting of the word, the document number of the document containing the word, the appearance position in the document, and the like. The word index storage unit 13 stores this data as a document list using each word as a key. Further, when the word index storage unit 13 receives a query composed of at least one word from the query execution means 1 5 2, it returns a document list of the word.
  • the tag LR index storage unit 14 stores a tag LR index including a tag L index (T L) and a tag R index (T R) as a transposition index for the tag and its left and right words.
  • the tag L index stores a set of words that appear to the left of a tag when the tag appears, and a tag document list that uses the tag and the word that appears to the left as keys.
  • the tag R index stores a set of words that existed on the right side when a tag appears, and a tag document list that uses the tag and the word that appears on the right side as keys.
  • the tag document list can be extracted under the condition that a word exists on the right and left side of a certain tag.
  • Figure 12 shows an example of a tag LR index.
  • Tag L index 'Each data in the tag R index is expressed as a reference (pointer) to the tag document list.
  • the tag document list corresponding to "[person name] ⁇ " is the pointer "# 1 2 5 6" This pattern occurs 1 9 8 5 9 times in all documents, and the [person name] tag is added to the 7th to 10th characters from the front in the document with the document number 3 3 3 It shows that.
  • Tag LR index storage unit 1 4 receives data including instruction type, tag name, document number, start position, end position, left word, and right word from tag update unit 1 2 and internal tag LR index Update.
  • the instruction type is information that identifies at least one of the two types of addition and deletion.
  • the tag name is the name of the tag to be added or deleted Indicates the front.
  • the document number is the document number of the document for which the tag is added or deleted.
  • the start position and end position are the positions in the document where tags are added or deleted.
  • the word on the left is the word that appears to the left of the start position.
  • the word on the right is the word that appears to the right of the starting position.
  • the tag LR index storage unit 14 receives an inquiry from the document search unit 15 including a reference destination and a reference key.
  • the reference destination is data indicating either the tag L index or the tag R index.
  • the reference key is specified by “tag name” card “tag name ⁇ word”.
  • Tag LR index storage unit 14 receives an inquiry using the reference destination and reference key as input, and when the reference key is “tag name”, it refers to the tag L index tag R index in the reference destination based on the tag name. Return the list of the right word list and the right word list. If the reference key is “tag name ⁇ word”, refer to the tag L index tag R index in the reference destination based on the key “tag name ⁇ word” and return the corresponding tag document list. .
  • the document index creation unit 1 1 is executed by an external program or user, and when a set of one or more documents is given, all the words included in the document are extracted and at least the word and Then, the document number of the document, the appearance position indicating the number of characters from the top of the body of the document and the appearance position are input to the word index storage unit 13.
  • the tag update unit 12 is executed by an external program or user, and receives a command statement related to tag addition / deletion, and updates the index in the tag LR index storage unit 14 according to the command statement.
  • the command statement related to tag addition / deletion is information consisting of command type, tag name, document number, start position, end position, target word string, left word, right word, and force.
  • the document search unit 15 is executed by an external program or user and receives a phrase (search query) composed of one or more tags or words. Based on this input, the document search unit 1 5 makes an inquiry to the word index storage unit 1 3, tag LR index storage unit 1 4, and high-speed tag value determination unit 1 6, and searches at least a list of document numbers. Output as a result.
  • the index can be referred to by using the bidirectionality of the index stored in the tag LR index storage unit 14 to reduce the amount of document list to be read without having the tag name as a secondary key. Therefore, the search process can be performed at high speed.
  • the tag is updated, only updates are made to two locations in the tag LR index storage unit 14, and tag addition and deletion can be performed at a high speed with a small amount of update.
  • FIG. 13 is a block diagram showing a second preferred embodiment of the present invention, and shows a configuration example of a document management / retrieval system.
  • This document management / retrieval system has a list of tag names that may be added to arbitrary character strings, and enables a high-speed reference to the list of tag names that may be added to character strings.
  • the difference from the first embodiment is that a high-speed tag value determination unit 16 is provided.
  • Figure 13 shows the details of the document search unit 15. In other words, the document search unit 15 interprets the search query and decomposes it into a plurality of conditions, and the word index storage unit 1 3 based on the plurality of conditions interpreted by the query interpretation unit 1 5 1.
  • Tag document Document list integration means 1 5 3 for comparing the lists with each other and integrating them into a document list of only documents having the same document number and the same phrase as the search query.
  • FIG. 14 is a block diagram illustrating a configuration example of the high-speed tag value determination unit 16.
  • the high-speed tag value determination unit 16 includes therein a tag value table 1 61, an update unit 1 6 2, and a determination unit 1 6 3.
  • the tag value table 1 ⁇ 61 is a table that stores the relationship between the tag and the word string to which the tag is added.
  • the update means 1 6 2 is called by the tag update unit 1 2, and the tag name, the target word string (one or more words to be tagged), and the instruction type (addition or deletion) )) Is input, and the relation information in the tag value table 1 61 is updated.
  • Judgment means 1 6 3 is called by inquiry execution means 1 5 2, inputs a word string, may refer to tag value table 1 6 1, and may be added to the word string Returns a list of tag names at high speed.
  • FIG. 15 shows an example of the tag value table 1 6 1.
  • Tag value table 1 6 1 As a character string (2 grams) that separates words into two characters and appended to the 2 grams It is possible to use the one that stores the relationship between the list of possible tag names (tag name string).
  • This tag value table 1 61 can be implemented as a program in memory. In the example shown in Fig. 15, for example, a [person name] tag or a [place name] tag may be attached to a character string containing “Yamada”. In this example, the original one-letter word (such as “no”) is stored as one character in the tag value table.
  • the update means 1 6 2 divides the target word string input by the tag update unit 1 2 every 2 grams, and the tag value table 1 6 1 for each 2 grams. And update the corresponding tag name string.
  • the judgment means 1 6 3 may divide the character string input by the inquiry execution means 1 5 2 every 2 grams and refer to the tag value table 1 6 1 and add it to the character string. Returns a list of tag names with.
  • the query interpretation means 1 5 1, query execution means 1 5 2, and document list integration means 1 5 3 in the document search unit 15 will be described.
  • the query interpretation means 1 5 1 is executed by an external program or user, receives a search query, and outputs a query task list to the inquiry execution means 1 5 2.
  • An inquiry task is data consisting of a reference destination, a reference key, and a position number.
  • the reference destination means an index to be referred to at the time of inquiry.
  • the transposed index (N) in the word index storage unit 13 or the tag L index (TL) and tag R in the tag LR index storage unit 14 are used. Either index (TR) or.
  • the reference key is a key for retrieving a document list from the index. If the reference destination is N, one word is used.
  • the reference destination is TL or TR, “[tag name] — word” or It is a set of primary key and secondary key expressed by a character string such as “[tag name] ⁇ [tag name]”.
  • the secondary key since the secondary key does not have an index that becomes a tag name, it is not possible to simply obtain a tag document list with “[tag name] ⁇ [tag name]” as a key. Not considered at this point.
  • the position number indicates the position of the reference key in the query, and is created from the position number in the key string.
  • Figure 16 shows an example of a list of inquiry tasks: “[company name] [person name]” This is based on the query.
  • a query task with a location number of 1 and a reference destination of TR or tag R index and a reference destination of “[company name] ⁇ ”, and a location number of 3 and reference destination is TL or Two inquiry tasks have been created, one with a tag index and one with a reference destination of “[person name] —”.
  • the inquiry execution means 1 5 2 is called by the document search unit 15 and takes a list of inquiry tasks as an input.
  • the inquiry execution means 1 5 2 refers to the word index storage unit 1 3, the high-speed tag value determination unit 1 6, and the tag LR index storage unit 1 4, based on the list of inquiry tasks, and the document list
  • the column is output to the document list integration means 1 5 3.
  • Figure 17 shows an example of a document list column.
  • the document list column is information that associates each document list with an inquiry task for a set of document lists / tag document lists obtained from the word index storage unit 13 and the tag LR index storage unit 14. is there.
  • the position number of each inquiry task, the reference key, and the document list obtained by the inquiry are related.
  • the document list integration means 1 5 3 is called by the document search unit 15 and takes the document list column as input and outputs a document list in which these are combined into a result list.
  • the processing in this embodiment mainly has three processes: a search process, a tag update process, and a document index process. Below, these are demonstrated in order.
  • Figure 18 shows the processing flow of the search process.
  • the search process starts when a user or an external program inputs a search query to the document search unit 15.
  • the document search unit 15 uses the query interpretation means 15 1 to create a key column from the input search query (S 11).
  • This processing is performed using some dictionary or rule such as morphological analysis or N-gram. For example, as the syntax of the search query, the tag is enclosed in “mouth” and “]”, and the tag name or “tag name: a character string to which the tag is attached” is described. If the part is defined as being written in natural language, this processing is performed as follows.
  • Query interpretation means 1 5 1 first takes out the part surrounded by “[” and ⁇ for the search query, tag name, or Take out the tag name and the character string to which the tag is added. Next, the query interpretation means 1 5 1 performs morphological analysis and creates a key string after dividing the input phrase into words.
  • the key string is a word key string and a tag key string.
  • a word key represents one word in a phrase.
  • the tag key represents one tag name in the phrase.
  • the word key and tag key are stored together with the position number indicating the number of each word tag after the top when the phrase is divided into words and tags.
  • Figure 19 shows an example of a key string.
  • a key column created based on the phrase “[company name: a b c industry] [person name] president]” is shown.
  • This query includes the string "abe industry” with the [company name] tag, the string “no”, any string with the [person name] tag, the string "president”, and
  • the word “abc industry” and the tag [company name] are in position 1, and the word “no” is in position 2.
  • “1” written at other positions means that there is no condition at that position.
  • the query interpretation means 15 1 creates a list (task list) of inquiry tasks based on the key column (S 1 2).
  • the step S 1 2 is defined as an arbitrary process for creating an inquiry task based on the following conditions. '[Condition 1] For each tag key in the key column, create at least one query task with that tag as the primary key.
  • FIG. 20 shows a flowchart of an example of an algorithm for realizing the process of creating a list of inquiry tasks (step S 1 2 in FIG. 18).
  • the query interpreting means 15 1 creates a query task to the tag LR index storage unit 14 when there are words on the left and right of each tag key in the key string (S 1 2 1).
  • Query interpretation means 1 5 1 examines the key sequence in order from the left (from position 1), and checks whether there is a word key to the right of the tag key. If it exists, change the reference to "TR" Create a query task with the reference key as the tag name of the tag key—the word to the right and the position as the position number of the tag key, and add it to the task list. If there is no word key to the right of the tag key, check whether there is a word key to the left of the tag key. If it exists, create a query task with the reference destination as “TL”, the reference key as “tag name of that tag key ⁇ the word to the left”, and the position as “position number of that tag key”. to add.
  • the query interpretation means 15 1 creates a query task in which the tags are concatenated for the tag key for which the query task has not yet been created (S 1 2 2).
  • Query interpretation means 1 5 1 checks the key sequence from the left (from position 1) in order, and if a query task with the tag key as the primary key has not yet been created, a tag key exists to the right of the tag key. Find out. If it exists, create a query task with the reference destination as "TR”, the reference key as "tag name of that tag key-> tag name of right tag key", and the position as "position number of that tag key”. Add to list. If there is no word key to the right of the tag key, check whether there is a word key to the left of the tag key. If it exists, create a query task with the reference destination as "TL”, the reference key as "tag name of that tag key-> tag name of the left tag key”, and the position as "position number of that tag key”. Add to task list.
  • the query interpretation means 1 5 1 creates a query task for a word key for which a query task has not yet been created (S 1 2 3).
  • Query interpretation means 1 5 1 examines the key sequence from the left (from position 1) in order, and if a query task with the word key as the primary key or secondary key has not yet been created, refer to “NJ, Reference” Create a query task with the key as “the word” and the position as “the word position” and add it to the task list.
  • the algorithm shown in the flowchart of Fig. 20 is an algorithm that prioritizes reference to the right direction (R index), but an algorithm that prioritizes left direction is also conceivable.
  • R index right direction
  • an algorithm may be considered that reads the frequency of the head of the document list based on both references and selects the smaller one.
  • FIG. 21 shows a flowchart of an example of an algorithm that implements this process. This process is performed for each inquiry task created in step S12.
  • the inquiry execution means 1 5 2 searches the word index storage unit 1 3 with the reference key of the inquiry task, reads the corresponding document list, It is held together with the position information (S 1 3 1).
  • the inquiry execution means 1 5 2 checks whether the secondary key in the reference key of the inquiry task is a word or a tag. . If it is a word, the tag LR index storage unit 14 is inquired of the reference destination and the reference key “tag name ⁇ word”, and the corresponding tag document list is read (S 1 3 2). When the secondary key in the inquiry task reference key is a tag, the inquiry execution means 1 5 2 reads the tag document list using the tag LR index storage unit 1 4 and the high-speed tag value determination unit 1 6 (S 1 3 3).
  • step S 1 3 3 The process of step S 1 3 3 will be described in more detail.
  • Query execution means 1 5 2 first queries the tag LR index storage unit 1 4 for the reference destination and the “primary key tag name”, and lists the left word in the L index index and R index list of the right word Get (S 1 3 3 1).
  • the query execution means 1 5 2 inputs each word in the right word list to the high-speed tag value determination unit 16 and acquires a tag name string. Then, it is checked whether the tag name of the secondary key is included in the tag name column. If not, the word is deleted from the list of words on the left of the read right word (S 1 3 3 2).
  • the query execution means 1 5 2 stores the tag LR index using the primary key tag name and each word in the word list on the right as the secondary key. An inquiry is made to part 14 and the set of tag document lists obtained is added to form one tag document list.
  • step S 1 3 multiple inquiry tasks are executed, but the order may be arbitrary. Furthermore, the document number list DL is stored from the result of a certain inquiry task, and when the document list tag document list is read in the subsequent inquiry task, the entry position / start position where the document number is not included in the DL. It is also possible to speed up the processing by not reading the end position.
  • step S 1 3 3 2 is not performed, but in step S 1 3 3 3, the list of all right words is conditional on only the primary key tag name.
  • step S 1 3 3 is referred to the transposition index using only the primary key.
  • the process of reading the list may be replaced with.
  • the document list integration means 1 5 3 has the same document number and the appearance of words and tags.
  • the document number of the document whose position is equal to the key column is taken out (S 1 4).
  • Figure 22 shows a flowchart of an example of an algorithm that implements this process.
  • the document list stored in the word index storage unit 13 and the tag document list stored in the tag LR index storage unit 14 are based on the document number and the appearance position Z start position, respectively. It is assumed that they are sorted into
  • the document list integration means 1 5 3 prepares M integer pointers corresponding to each document list and creates all initial values as 1 (S 1 4 1).
  • the document list integration means 1 5 3 extracts the set of the start position, end position and document number of the entry position and the document number at the pointer position from each document list tag document list (S 1 4 2).
  • the document list integration means 1 5 3 determines whether or not all the M document numbers obtained in step S 1 4 2 are equal (S 1 4 3), and each appearance position is the key column position number. It is determined whether the adjacency is correct (S 1 4 4), and if those conditions are satisfied, it is determined that the document has been hit, and the document number is added to the output result list (S 1 4 5).
  • FIG. 23 is a diagram for explaining the algorithm of step S 1 4 4.
  • the key sequence is examined in order from the left, and the appearance position Z start position in the document obtained using each key as the primary key is compared with the end position obtained from the one key to the left. I will check if it is.
  • the method of evaluation depends on how the query is made for the i-th key.
  • Figure 23 shows these four cases. In order to express each case, the example of the key column and the primary key used for the query in the key column are dotted ellipses, from the primary key to the secondary key. Key references are represented by dotted arrows.
  • Case A is a case where there is no query using the i-th key as the primary key.
  • the word key is used as the secondary key.
  • Case B is a case in which only the tag key exists for the i-th and the primary key is a query. Therefore, it is necessary to check the position for the query whose primary key is a tag (in this example, “B ⁇ A”).
  • Case C is the case where only the word key exists for the i-th and the query is made using the word key as the primary key. Therefore, it is necessary to check the position for an inquiry using only this word key.
  • Case D is the case where there is an i-th word key and tag key, and a query is made with each as the primary key. Therefore, it is necessary to check the positional relationship for each of these inquiries. Therefore, in this algorithm, the position is checked for each of these cases.
  • FIG. 24 is a flowchart for explaining the algorithm of step S 1 44.
  • the document list integration means 1 5 3 first initializes two variables i to 1 and P to 1 (S 1 4 4 0 1).
  • the key sequence is examined in order from the left, and variable i represents the position of the currently examined key in the key sequence.
  • the variable P represents the start position of the position of the i-th key predicted from the left key in the document.
  • the document list integration means 1 5 3 asks what question It is determined whether or not the meeting has been performed (S 14402). This determination process is performed by checking the primary key in the reference key of the inquiry task whose position number is i and checking whether it is a tag key or a word key. In case A, the position check is not performed. If P is not the initial value (_ 1), the next (i + 1st) key position check is prepared, and the character length of the word key is added to P ( S 14403).
  • a position check is performed on the i-th tag key (S 14 404).
  • the position check for the tag key refers to the process of determining whether the following conditions T 1 and T 2 are satisfied.
  • Condition T1 When there are multiple inquiries using the tag key as the primary key, the start positions and end positions obtained by each inquiry must match.
  • Condition T2 P is _ 1 (tag key is first), or P is equal to the start position obtained with the tag key as the primary key (adjacent to the appearance position obtained with the left key) thing.
  • a position check is performed on the i-th word key (S 14 406).
  • the position check for the word key refers to a process for determining whether or not the following condition W is satisfied.
  • Condition W P is _ 1 (word key is first), or P is equal to the appearance position obtained with the word key as the primary key (adjacent to the appearance position obtained with the left key) That). If this is satisfied, it is considered that they match, and the appearance position obtained based on the word key + the character length of the word key is substituted for P (S 14407). Otherwise, it is determined that they do not match, and the processing of S144 is finished.
  • a position check is performed on the i-th word key and tag key (S 14408).
  • the position check for the word key and tag key refers to the process of determining whether all of the following conditions TW are satisfied in addition to the conditions Tl, Condition ⁇ 2, and Condition W.
  • step S 1 4 4 1 the document list integration means 1 5 3 adds 1 to i and checks whether i exceeds the length of the key string (S 1 4 4 1 2). It is judged that all the positional relationships are correct, and the processing of S 1 4 4 is finished. Otherwise, return to step S 1 4 4 0 2.
  • the document search unit 15 outputs the result list obtained by the document list integration unit 15 3 (S 15).
  • the document index creation process begins when one or more documents are entered by an external program or user.
  • the document index creation unit 1 1 When one or more documents are input, the document index creation unit 1 1 reads the text of the document for each input document, and uses the morphological analysis program or N-gram creation program to convert the text into words. Create a word string by separating each. Next, the document index creation unit 11 checks the word string in order from the front, and counts the number of characters from the front of the document for each word as the appearance position. Furthermore, the document index creation unit 11 gives each word, document number, and appearance position to the word index storage unit 13.
  • FIG. 25 illustrates the tag update process.
  • the tag update process starts when an instruction for adding / deleting tags is input by an external program or user and the tag update unit 12 is called.
  • Tag addition * Deletion statements related to deletion are the command type (addition / deletion), tag name, document number, start position, end position, target character string (to be tagged), and to the left of the tag It consists of a word and the word to the right of the tag.
  • the tag update unit 1 2 refers to the L index in the tag LR index storage unit 1 4 based on the tag name and the left word to be tagged.
  • the tag document list is updated according to the instruction type in the document list (S 2 1). If the command type is append, the document number, tag start position, and tag end position are added to the corresponding tag document list. If the instruction type is delete, read the corresponding tag document list, find the part where the sentence number, start position, and end position match, and delete that part. Similarly, refer to the R index in the tag LR index storage unit 14 based on the tag name and the right word to be tagged, and add / delete the document number, tag start position, and tag end position ( S 2 2).
  • the tag update unit 12 calls the update unit 16 2 in the high-speed tag value determination unit 16 and inputs the instruction type, the tag name, and the target character string to be tagged (S 2 3).
  • the tag value table 16 1 is implemented by implementing the table shown in FIG.
  • the update means 1 6 2 divides the tagged character string into 2 grams, and refers to the tag value table 1 6 1 for each 2 grams and is input. Whether the tag name is included in the tag name column. If the tag name is not included in the tag name column, the tag name is added to the tag name column. If the instruction type is checked and deleted, nothing is done. Note that when the high-speed tag value determination unit 16 is not used as in the first embodiment, the processing of S 23 is not performed.
  • the document index creation process will be described. For example, when the document 3 3 3 shown in FIG. 2 is input to the document index creation unit 1 1, the document index creation unit 1 1 delimits words in the text and lists the word, document number, and appearance position. create. A part of this list is shown in Figure 26. Next, the document index creation unit 11 inputs this list into the word index storage unit 13. The word index storage unit 13 creates an inverted index based on the list shown in FIG. Some examples of this inverted index are shown in Fig. 11.
  • the tag update unit 1 2 makes an inquiry to the L index in the tag LR index storage unit 14 with the key “[person name] ⁇ ”, and enters the document number 3 3 3 in the corresponding tag document list. , Add start position 7 and end position 1 0.
  • the R index in the tag R index storage section 1 4 is queried with the key [[person name] ⁇ president], and the corresponding tag document list is document number 3 3 3, start position 7, end position 1 0. Is added.
  • the data in the tag LR index storage unit 14 created as a result is shown in FIG.
  • the tag update unit 1 2 updates the tag name [person name] in the command statement, the character string “Taro Yamada”, and the command type “ADD” in the high-speed tag value determination unit 16 Enter 1 6 2
  • Update means 1 6 2 separates the character string “Taro Yamada” into two characters, and creates character strings “Yamada”, “Tada”, and “Taro”.
  • the update means 1 6 2 refers to the tag value table 1 6 1, refers to the tag name column with “Yamada”, “Tada” and “Taro” as keys, and does not include “person name” If so, add “person name”.
  • An example of the tag value table 16 1 created as a result of this is shown in FIG. The following is an example of deletion.
  • the tag update unit 1 2 makes an inquiry to the L index in the tag LR index storage unit 14 with the key “[person name] ⁇ ”, reads the corresponding tag document list, and reads document number 3 3 3. Delete the start position 7 and end position 1 0.
  • the tag updater 1 2 also uses the tag name [person name] in the statement and “Taro Yamada”
  • the character string and the instruction type “RM” are input to the update means 1 6 2 in the high-speed tag value judgment unit 16. In this case, since the instruction type is “RM” (deletion), the update means 1 6 2 does nothing.
  • the document search unit 15 operates as follows.
  • Query interpreting means 1 5 1 first interprets this query and converts it into the key string shown in FIG. 27 (S 1 1).
  • the query interpretation means 15 1 performs the process of step S 1 2 1 based on this key string, and creates the inquiry task shown in FIG. 16 (S 1 2).
  • the inquiry execution means 1 5 2 inquires these two tasks to the tag LR index storage unit 14 and creates a document list string as shown in FIG.
  • the document list integration means 1 5 3 creates a result list representing a document set in which the document numbers match and each word tag is as phrase based on the document list sequence. This process is performed as follows.
  • Document list integration means 1 5 3 reads the tag document list shown in Fig. 1 7 in order from the beginning.
  • Document number 3 3 3 from the inquiry “[company name] —no”, start position 1, end position 5 From the inquiry “[person name] ⁇ no”, data of document number 3 3 3, start position 7 and end position 1 0 is read (S 1 4 2).
  • the document list integration means 1 5 3 confirms that the document numbers match between these data (S 1 4 3), and proceeds to the processing of step S 1 4 4.
  • step S 1 4 4 the document list integration means 1 5 3 checks the key sequence in order from the front.
  • the first in the key column is the tag key [company name], and there is an inquiry task with [company name] as the primary key. Therefore, in step S 1 4 4 0 2, it is determined as case B, and S 1 4 4 0 Perform step 4.
  • the tag key is single and P is one of the initial values
  • the document list integration means 1 5 3 reads the key string 2.
  • the document list integration means 1 53 reads the third key string.
  • the third person in the key column is [person name], and there is a corresponding inquiry task.
  • the tag key [person name] in the key column number 3 is determined as case B in step S144 ⁇ 2,
  • the document list integration means 153 performs this processing until the condition of S 147 is satisfied, and outputs a finally obtained result list (S 15).
  • the query interpreter 151 interprets the query (S 1 1), converts it into a single column, and creates the following inquiry task (S 12).
  • the inquiry execution means 152 inquires the tag LR index storage unit 14 for each inquiry task in the process of step S 13. Of these, the inquiry task for the reference “TL”, reference key “[person name] ⁇ [particle]”, and position “3” will be described.
  • the system reads “no” and “recent” as the left word list shown in Figure 13 with [person name] as the primary key (S 1 33 1).
  • the inquiry execution means 1 52 inquires the high-speed tag value determination unit 16 for each word, and deletes words that are not likely to contain particles. For example, if the tag value table in the high-speed tag value determination unit 16 is as shown in FIG. 15, the word “recent” does not include a particle, and is deleted (S 1 332).
  • the inquiry execution means 1 52 uses the remaining word “no” to “ The tag document list is read out from the tag L index based on the reference “name” ⁇ “no” (S 1 3 3 3). Subsequent steps S 1 4 and S 15 are the same as those in the above example, and thus description thereof is omitted.
  • search processing can be performed at high speed, and tag addition / deletion can be performed at high speed with a small amount of updates.
  • tag value judgment unit 16 that makes it possible to refer to a set of tag names that may be attached to a character string at high speed using an arbitrary character string as a key. Because the tag document list can be read out only for the words that may have the tag of B added to the set of words that appear to the right of A for the tag AB, the query with adjacent tags The phrase can be referred to at high speed.
  • FIG. 28 is a block diagram showing a third preferred embodiment of the present invention, and shows a configuration example of a document management / retrieval system.
  • This document management / retrieval system further includes a bit string storage unit 17 in the configuration of the second embodiment of the present invention.
  • the bit string storage unit 17 stores the relationship between a word or tag name and a bit string that indicates which document contains the tag name for each word or tag name. This bit string has the same length as the document set, and each bit corresponds to each document and indicates whether the key is included in each document (1) or not (0).
  • FIG. 29 shows an example of data stored in the bit string storage unit 17.
  • the Nth bit corresponds to the document number N.
  • the word “ha” is included in documents with document numbers 1, 2, 3, 4, 6, etc.
  • the tag [person name] means that it is included in the documents with document numbers 1, 2, 4, 5, and so on.
  • Fig. 29 shows the logical relationship of data managed by the bit string storage unit 17 and the actual data storage format can be any.
  • the bit string storage unit 17 receives the word and the document number from the document index creation unit 11 and updates the bit string using the input word as a key.
  • the bit string storage unit 17 receives the tag name, document number, and instruction type from the tag update unit 12 and updates the bit string corresponding to the tag name.
  • the bit string storage unit 17 is called by the inquiry execution means, receives a word or tag name as an input, and internally corresponds to the key. If one exists, the corresponding bit string is returned.
  • the search process is performed as follows.
  • the document search unit 1 5 interprets the query in step S 1 1 of the search process P 1 0, and then stores each word / tag name contained in the key string as a bit string Queries part 17 and retrieves each bit string.
  • the document search unit 15 performs an AND operation on the obtained plurality of bit strings to create a bit string BL that represents a set including all the keys in the key string.
  • the document search unit 15 performs the process of S 12 2 to create a set of inquiry tasks, and then in S 1 3 makes an inquiry to the document list / tag document list of each inquiry task.
  • step S 24 is a process of updating the bit string by inputting the tag name, document number, and instruction type to the bit string storage unit 17.
  • step S 2 4 the bit string storage unit 1 7 first checks the instruction type, and if the instruction type is added, reads the corresponding bit string using the tag name as a key and updates the bit of the document number to “1”. To do. If the instruction type is delete, do nothing.
  • Step S 31 is performed.
  • Step S 3 1 is a process in which the document index creation unit 11 inputs a word and a document number into the bit string storage unit 17.
  • the bit string storage unit 17 reads the corresponding bit string using the word as a key, and updates the bit of the document number to “1”.
  • step S 3 1 is performed only on a specific word, and may be accepted. For example, prepare a dictionary HD of frequently used words in advance, and use step S It is conceivable to compare the word with HD before performing the processing of 3 1 and perform S 3 1 only if the word is included in the HD.
  • the query interpretation means 1 1 performs the process of S 1 1 and uses the keys [company name], “no”, and [person name].
  • the inquiry execution means 15 2 refers to the data (FIG. 29) stored in the bit string storage unit 17, reads the bit string corresponding to each key, and performs an AND operation. As a result, a bit string “1 1 0 0 1 0 1 0 0 0 0 1 0 0” is obtained.
  • the inquiry execution means 1 5 2 reads only the part applicable to this document set when reading the document list / tag document list in step S 1 3.
  • the subsequent processing is the same as the document update process in the first and second embodiments.
  • the query execution means reads a bit string by referring to the bit string storage unit based on the word tag name included in the query in advance at the time of search, and examines it by an AND operation. Since documents containing tag names can be found at high speed, the load on the document list can be reduced, and searches can be performed even faster.
  • FIG. 30 is a block diagram showing a fourth preferred embodiment of the present invention.
  • This document management / retrieval system includes a tag management unit 19 for managing tags.
  • a tag management unit 19 for managing tags.
  • a tag LR index storage unit 14 and a set of tags in a document set Tag NLR index storage unit 1 8 that stores the appearance position of the tag and the left and right words, and conversion means 2 0 that converts the index in tag NLR index storage unit 1 8 into the index in tag LR index storage unit 1 4
  • Management means 21 for changing the way the index is held based on the tag statistical information.
  • the tag management unit 19 When the tag management unit 19 receives an inquiry from the inquiry execution unit 1 52, the tag management unit 19 passes the input data to the internal management unit 21 and sends the data output by the management unit 21 to the inquiry execution unit 1 52. return.
  • the tag management unit 1 9 is the tag update unit 1 When an update command is received from 2, the command is input to the internal management means 21.
  • the tag NLR index storage unit 18 internally has a tag LR document list with each tag name as a key for a set of tags.
  • the tag LR document list is data in which the left word and the right word are added to the data of the tag document list.
  • Figure 31 shows an example of a tag LR document list.
  • the tag [person name] appears 1 0 0 0 0 1 time in the document set, is in the 7th to 10th characters in the document with the document number 3 3 3, and The word “” indicates that the word “President” is on the right.
  • the tag L R index storage unit 14 has the same information as the tag L R index of FIG. 12 shown in the first embodiment.
  • the conversion unit 20 is called by the management unit 21 and receives the tag L R document list as an input, and outputs the L index and the R index.
  • Management means 21 has an internal management table.
  • a management table is a table that stores tag names, tag document frequencies, and index types. Of these, the index type indicates where the index of the corresponding tag is created, and the value is the tag NLR index storage unit 1 8 (NLR) or the tag LR index storage unit 1 4 It is either (LR).
  • Figure 32 shows an example of the management table. This example means that the [person name] tag appears 1 0 0 0 0 1 times in the document set, and the index is currently stored in the tag N L R index storage unit 18.
  • the management type 2 1 When the management type 2 1 receives data (command text) including the command type, tag name, document number, start position, end position, left word, and right word, the management table is referenced based on the tag name. Then, the index type corresponding to the tag name is extracted, and the statement entered in the corresponding index is input as it is.
  • the management means 2 1 receives a query with the reference key and reference destination as input, refers to the management table based on the tag name in the reference key, retrieves the index type corresponding to the tag name, and queries the corresponding index. I do.
  • the management means 21 also checks the frequency and index type of the tag in the management table at an arbitrary timing.
  • the tag NLR index Storage unit 1 Reads the tag LR document list corresponding to the tag name from the inside, creates a tag L index and a tag R index using conversion unit 2 0, and adds them to the tag LR indentus storage unit 1 4 .
  • the threshold ⁇ is an arbitrary fixed number.
  • This embodiment mainly has three processes: a search process, a tag update process, and a document index process. These processes are the tag LR index storage unit 1 in the first to third embodiments. This is equivalent to replacing the operation of 4 with the tag management unit 19. Therefore, here, only the processing in the tag management unit 19 will be described, and the tag update process for the tag management unit 19, the inquiry process for the tag management unit 19, and the index optimization process will be described. To do.
  • the tag update process starts when the tag update unit 12 inputs a command statement related to tag addition / deletion to the management unit 19. At this time, the system first refers to the management table based on the tag name and updates the frequency corresponding to the tag name. The frequency is updated as follows. If the command type of the command statement is additional, add 1 to the frequency. If the command type is delete, subtract 1 from the frequency.
  • the system refers to the management table based on the tag name and retrieves the corresponding index type.
  • the index type is LR
  • the command statement is given to the tag LR index storage unit 14 and the processes of steps S 2 1 and S 2 2 are performed.
  • the index type is N L R
  • the system performs the following process. The system reads the tag LR document list using the input tag name as a key, and if the command type is added, the document number, start position, end position, left word, right in the tag LR document list Add a word. If the command type is delete, the tag L R searches the document list for the part where the document number, start position, and end position match, and deletes that part.
  • the inquiry process for the tag management unit 19 will be described. This process is started when the inquiry execution means 15 2 makes an inquiry with the reference key and the reference destination as input to the tag management unit 19.
  • the system first refers to the management table based on the tag name, and Take out the Ndex species.
  • the index type is LR
  • the tag LR index storage unit 14 is inquired. This inquiry processing is the same as the inquiry to the tag LR index storage unit 14 in the first embodiment.
  • Figure 3 shows a flowchart of the process when the Indetas species is N L R. If the index type is NLR, the system reads the corresponding tag LR document list based on the tag name contained in the reference key in the query, and uses the conversion means 2 0 to tag L index and tag R. Create an index.
  • the system first creates an empty tag L-index and an empty R-index at a location that can be added and referred to at high speed, such as on the computer memory (S 51).
  • the system checks the tag L R index in order from the front, and performs the following processing every time it reads five data consisting of the document number, start position, end position, left word, and right word.
  • the system checks whether there is a tag document list with the key "tag name ⁇ left word" in the tag L index. If there is, the document number, start position and end position are added to the end of the tag document list. to add. If it does not exist, create a new tag document list based on the document number, start position, and end position, and register it with the key “tag name ⁇ left word”. Further, the same processing is performed for the tag R index, and the document number, start position, and end position are added to the tag R index with the key “tag name ⁇ right word” (S 52).
  • the tag document list is returned by referring to the corresponding position in the Rindettas (S 53).
  • Figure 34 shows a flowchart of the Indetus optimization process.
  • the index optimization process takes one row of data (tag name, frequency, index type) in the management table as input, and is executed at any time. For example, the execution timing may be executed for a row in the management table that is updated in the tag update process when the tag update process for the tag management unit 19 is completed. For example, it is possible to execute each line at 3 am.
  • the system checks the frequency and index type.
  • the management means 21 checks the tag NLR index storage unit 18 and reads the tag LR document list corresponding to the tag name (S 61).
  • the management means 21 uses the conversion means 20 to create a tag L index and a tag R index from this tag LR document list (S62). Furthermore, the management means 21 adds the created tag L index and tag R index to the tag LR index storage unit 14 (S63). Next, the management means 21 refers to the inside of the management table using the same tag name, and updates the index type to “LR” (S 64). Finally, the management means 21 deletes the tag LR document list and key from the tag NLR index storage unit 18 corresponding to the tag name (S65).
  • the index storage destination is changed based on the tag frequency, but other criteria include the number of left word types, the number of right word types, and tag queries. The number of times, or a number calculated by combining them can be considered.
  • the index optimization process works as follows.
  • the management means 21 first checks the frequency and index type. At this time, since the tag frequency is equal to or higher than the threshold value and the index type is “NLR”, the management means 21 makes an inquiry to the tag NLR index storage unit 18 and uses the person name in FIG. Get the list (S 6 1). Further, the management means 21 uses the conversion means 20 to create a tag L index and a tag R index from the tag LR document list, obtain the index shown in FIG. 12 (S 6 2), and use this as the tag. The data is stored in the LR index storage unit 14 (S63).
  • the management means 21 changes the index type for the person name in the management table shown in FIG. 32 to “LR” (S 64), and the tag NLR index storage unit 18 calls this tag LR document list and “person name”. Delete the key (S65).
  • the tag NLR index and the tag LR index are switched based on the tag statistical information.
  • the tag LR index is fast because it has a document list based on the left and right words, but it is redundant because it creates an index in both directions, and it has the feature of storing a large amount of data. Therefore, by using tags NLR index to reduce the index for infrequent tags that are originally short in frequency and small in the amount of document list read at the time of search, the balance between the data amount and high-speed search can be achieved. Can be taken. In other words, it is possible to avoid creating an LR index for tags whose document list is short and low in frequency, and to keep the search speed high while reducing the amount of data held as an index. Can do.
  • the present invention can be implemented as a computer program and can be distributed via a storage medium or a network.
  • a document index creation process for storing the appearance position using each word as a key for a set of words included in the document
  • tag update processing that stores the tag appearance position using the tag name as a key
  • the words appearing on the right and left of the tag are memorized, and the combination of each tag and the word appearing on the right, or the combination of each tag and the word appearing on the left is used as a key.
  • the search query is interpreted. Create multiple keys by using the left / right relationship between adjacent words in the raise and tags, and update the appearance of words and tags based on the keys stored in the document indexing process based on these keys.
  • a document search process that refers to the appearance position of each tag based on the key stored in, and then integrates them to return a list of identifiers of the document containing the phrase. It is composed of the following codes.
  • the tag name that may be added to the character string High-speed tag value determination processing that enables high-speed reference to a set, processing that updates data representing the relationship between tag names and character strings when tags are added in tag update processing, and tag names that are consecutive in document search processing
  • a search query is entered for a phrase
  • use the high-speed tag value determination process to further cause the computer to execute the process of reading the tag appearance position only for words that may contain a specific tag name. It is desirable to include code.
  • a high-frequency word and tag name are used as keys, and a bit string storage process that stores a bit string that represents a set of documents that contain the word and tag, and a tag update process that is added or deleted when the tag is updated.
  • the bit string stored in the bit string storage process is used as a key in the process of updating the bit string stored in the bit string storage process based on the tag and the document search process. Referencing and obtaining data representing a set of documents that contain all the high-frequency words and tag names in the query, narrowing down the set of documents based on that data, and further reading the appearance positions of words and tags You can include code that you want to execute.
  • a tag update step is executed by causing the computer to execute a tag NLR index process for storing a tag appearance position and left and right words in a document set using each tag name as a key for a set of tags.
  • a tag NLR index process for storing a tag appearance position and left and right words in a document set using each tag name as a key for a set of tags.
  • the reference destination is changed. It also includes code that causes the computer to execute the selected process and the index conversion process created by the tag LR index process by deleting the data created by the tag NLR index process based on the frequency related to the tag. it can.
  • the present invention is effective as a part of a system for managing and retrieving documents using tags.
  • the focus is on the part that quickly determines the list of document numbers representing the document set including the phrase based on the phrase including the tag. Therefore, in addition to the configuration of the present invention, by preparing a document database that refers to the document itself from the document number, a search engine that can read a document set with a phrase including a tag. It can be used as
  • the present invention is a technique for realizing a phrase search including a tag on the assumption that the tag is updated.
  • Applications that require this technology include the field of text mining that analyzes large document sets.
  • text mining a tag is added to a document and analysis is performed using the tag.
  • it is often not known in advance what kind of tagging is preferable for a document set. Therefore, by indexing a large number of document sets in advance, tagging using various tagging means, searching with tags and phrases containing the tags, extracting the frequency and document set, Knowledge can be efficiently extracted from a document set.
  • the present invention is useful in such a case.

Abstract

　単語の集合に対して、文書集合内での各単語の出現位置を単語インデックとして記憶し、また、単語に付加されたタグの集合に対して、各タグの右と左に登場した単語の集合を記憶すると共に、各タグとその右に登場する語の組み合わせ、あるいは、各タグとその左に登場する語の組み合わせをキーとして文書集合内の各タグの登場位置をタグＬＲインデックスとして記憶し、タグの検索時にクエリのフレーズに含まれる隣接した単語とタグに対し、タグとその右あるいは左の単語をキーとしてインデックスを参照し、タグ名を２次キーに持たなくとも読み込む文書リストの量を削減する。また、タグを更新する際には、タグＬＲインデックスに２箇所の更新を加えるのみでタグを更新する。

Description

文書管理 ·検索システムおよび文書の管理 ·検索方法 技術分野：
本発明は、 文書中の部分文字列にタグを付加し、 そのタグを元に文書情報を管 理および検索する技術に関する。 特に、 情報検索のための処理要求 （クエリ） と して、 タグを含むフレーズを使用可能とする技術に関する。
明 背景技術：
書
図 2はタグ付けされた文書の一例を示す。 本明細書において 「文章」 とは、 少 なくとも、 ユニークな識別子とである文書番号と、 検索の対象となる文字列 （本 文） と、 を含むデータをいう。 また、 「タグ」 とは、 ある文書中の一つ以上の単語 に対して付加されるデータをいう。 図 2の例では、 「A B C産業の山田太郎社長 は. . .」 という文字列を含む文書において、 1文字目から 5文字目までの 「a b c 産業」 に対して付加される 「企業名」 というタグの例と、 7文字目から 1 0文字 目までの 「山田太郎 j に対して、 「人名」 というタグの例を示している。 本明細書 では、 「企業名」 や 「人名」 ように、 タグを表現する文字列をタグ名と呼ぶ。 さら に、 本明細書において 「単語」 とは， 形態素解析や Nグラム （文字列を N文字ご とに区切る） など、 何らかの一定の基準で作成された本文の部分文字列をいう。 このようなタグを付加した文章に対して文書管理および検索を行う文書管理 · 検索システムには、 文書中の部分文字列に対してタグを付加あるいは削除する機 能と、 タグを用いたフレーズによる文書の検索する機能とが備えられる。 タグを 用いたフレーズによる文書の検索とは、 タグ名ゃ文字列を含む連続した文字列を 入力とし、 そのフレーズを含む文書集合を出力する機能を意味する。 例えば、 タ グを用いたフレーズとして 「[企業名] の [人名]」 が挙げられる。 なお、 この構 文では 「[J と 「]」 で囲まれた文字列をタグ名として捉える。 このとき、 このフ レーズを検索クエリとして捉えると、「企業名」というタグが付加された任意の語、 「の」 という語、 「人名」 というタグが付加された任意の語が連続して登場する文 書を返却せよ、 という意味になる。
このようなタグを用いた文書の管理 ·検索を実現する方法として、 タグ付きの 文書を XML (ExtensibleMarkup Language) などの階層的な構造の記述形式で表 現した上で、 階層的な構造文書の検索装置 XMLDB (XMLData Base) を利用 する方法が知られている （例えば特開 2005— 1881 1号公報参照、 以下特 許文献 1と記す)。
XMLの一例を図 3ないし図 5を参照して説明する。 図 3はタグを付加された 文書を XMLにより表現した例を示し、 図 4は同文書の一部をタグの包含関係を 元に木構造として表現したもの、図 5は階層的な情報を管理するための表を示す。 図 4において、楕円のノードはタグを、長方形の葉ノードはテキストを意味し、 それらの間のエッジは、 それらのタグもしくはテキストの間に包含関係が存在す ることを意味している。 さらに、 図 4では、 各ノードの下にパス階層と呼ばれる 情報を記述している。 パス階層とは、 各ノードの文書中での位置を表す情報であ る。 パス階層はノードの位置を示す数字を区切り記号 （「.」） と共に記述したもの である。 例えば、 図 4の 「人名」 ノードには 「1. 1. 3」 というパス階層が付 加されているが、 これはルートから見て 「1番目のノード （「文書」 ノード） の下 の 1番目のノード （「本文」 ノード） の下の 3番目のノード」 という意味を持つ。 これらの階層的な情報は、 図 5に示したような表で管理される。 ただし、 この 表は論理的な関係を示すものであり、実際には複数の表で表現されることが多い。 図 5に示した表では、 文書集合内のノードに対して、 ノード I D、 文書番号、 テ キスト、 タグ名、 パス階層の情報を管理している。 ノード I Dは、 文書集合内の 全ノードに対してユニークな識別子である。 文書番号とは、 そのノードが含まれ る文書を示す I Dである。 テキストとは、 葉ノードに含まれる文字列である。 た だし、 葉ノードでないノードに対しては、 「NULL」 が入力されるものとする。 タグ名とは、 各ノードのタグ名である。 ただし、 葉ノードに対しては 「# t e x t」 が入力されるものとする。 パス階層とは各ノードのパス階層を意味する。 このような情報を検索する方法について、 特許文献 1に開示された検索装置の 動作を例に説明する。
例えばクエリとして 「[企業名]の [人名]」 というフレーズが与えられた場合、 この検索装置はまず、 クエリを複数の検索条件に分解する。 このクエリの場合に は、 A：企業名というタグがあること、 B ： 「の」 という語が含まれること、 C ： 人名というタグがあること、 の 3つに分解される。 次にこの検索装置は、 各条件 を元にそれぞれ図 5に示した表を参照し、 タグ名が 「企業名」 であるノードのリ スト （Aリス トとする） と、 テキス トが 「の」 であるノードのリス ト （Bリスト とする）、 タグ名が 「人名」 であるノードのリスト （Cリストとする） を得る。 次 にこの検索装置は、 Aリスト、 Bリスト、 Cリスト内のノードを比較し、 文書番 号が等しいノードの組み合わせを取り出し、 Aリス ト内の 「企業名」 ノード、 B リスト内の 「の」 ノード、 Cリスト内の 「人名」 ノードの位置関係がクエリと同 じ順序で連続しているものを取り出す。 この位置関係の判定はパス階層を比較す ることで行われる。 このクエリの場合、 「企業名」 ノードと 「の」 ノードと 「人名」 ノードは兄弟ノードであり、 この検索装置は、 次の三つの条件を満たすノードか ら、 検索結果を作成する。
条件 1 ： 「企業名」 ノードのパス階層と、 「の」 ノードのパス階層と 「人名」 ノ ードのパス階層が、 末尾の数以外の部分で一致し；
条件 2 ： 「の」 ノードのパス階層の末尾の数 = 「企業名」 ノードのパス階層の末 尾の数 + 1であり ；
条件 3 ： 「人名」 ノードのパス階層の末尾の数 = 「の」 ノードのパス階層の末尾 の数 + 1である。
しかし、 この方法には二つの問題がある。 まず、 第一の問題は、 タグを追加し た場合にパス階層の更新が必要であり、 処理に時間がかかるということである。 図 6に、 タグの追加によるパス階層の変更の例を示す。 図 6では、 文書に人名と いうタグを追加する例について、 追加前の文書構造を左側に、 追加後の文書構造 とそのパス階層の更新範囲を右側に示す。 右側の更新範囲では、 点線で示される 範囲のノードのパス階層を更新する必要があることを示している。 このように、 パス階層はノードの位置を文書全体の階層構造を用いて表現しているため、 文書 中の一部が変更になった場合でも大幅に変更が必要となる。
第二の問題は、 一般的な語句や頻度の高いタグ名のみから成るフレーズを検索 クエリとした場合に、 検索に時間がかかるということである。 これは、 一般的な 語句や頻度の高いタグ名で検索した場合、 個々の条件でノードを検索する際に大 量のノードが発見されるため、 大量のノードに対して文書番号と位置関係を調べ る必要があり、検索速度が低下するという問題である。 例えば、 「[企業名] の [人 名]」 というクエリの場合、 クエリは、 企業名というタグがあること、 「の」 とい う語が含まれること、 人名というタグがあること、 に分解され、 それぞれの条件 に合うノードのリストが取り出される。 し力 し、 それぞれの条件は一般的過ぎる ため大量のノードが発見され、位置関係を調べるために大きな時間が必要になる。 このように、 XM L D Bを用いた文書管理 ·検索システムは文書の階層構造ま でをインデックス化するために、 タグの更新 （追加や削除） や、 検索に時間がか かってしまう。 そこで、 タグを用いたフレーズ検索を実現する別の方法として、 階層構造をィンデックス化せず、 全文検索ィンデッタスで利用される転置ィンデ ックスを用いることが考えられる。
図 7は転置インデックスの例を示す。 図 7において （a ) に示されるデータ構 造では、 ある単語をキーとして入力することで、 その単語を含む文書の数 （頻度） と、 その単語を含む文書の文書番号と、 その文書内でのその単語の登場位置 （登 場位置、 文書前方からの文字数で表現される） のリスト （以下、 文書リス トと呼 ぶ） を得ることができる。 転置インデックスを用いてタグによるフレーズ検索を 実現するには、 （a ) で示した通常の転置インデックスの他に、 （b ) に示すタグ の転置インデックスを用いる。 （b ) は、 単語の場合と同様、 あるタグ名のタグに 関して、 そのタグを含む文書の数 （頻度） と、 そのタグを含む文書番号と、 その 文書内でのタグの登場位置を示す情報 （開始位置と終了位置、 文書前方からの文 字数で表現される） のリスト （以下、 タグ文書リストと呼ぶ） を得ることができ る。
このようなインデックスを用いることにより、 タグを付加 ·削除する際は、 タ グの転置ィンデッタスの該当部分のみを追加 ·削除することで、 タグの更新を行 うことができる。
しかし、 この方法を用いた場合でも、 一般的な語句や頻度の高いタグ名のみか ら成るフレーズを検索クエリとした検索時には、 その処理時間が問題となる。 例 えば、 クエリとして 「[企業名] の [人名]」 というフレーズが与えられた場合、 このインデックスを持つ検索システムは、 特許文献 1で示される装置と同様に、 A：企業名というタグがあること、 B ： 「の」 という語が含まれること、 C :人名 というタグがあること、 に分解し、 各転置インデックスを参照する。 し力 し、 X M L D Bの場合と同様、 それぞれの条件は一般的過ぎるため、 個々の条件で非常 に長い文書リストが発見され、 位置関係を調べるのに時間がかかる。
また、 一般的な語句から成る検索クエリに対し、 文書リストの長さを削減しフ レーズ検索を高速化する手法として、 N e X t w o r dインデックスと呼ばれる 手法がある （H. E. Will iams, J. Zobel and D. Bahle, "Fast Phrase Querying with Combined Indexes", ACM Transactions on Information Systems, 22 (4)， pp. 573-594， 2004 を参照、 以下非特許文献 1と記す）。 N e x t w o r dインデ ックスは、 高い頻度を持つ一般的な語の文書リストを、 その次 （横書きを前提と し、 これを 「右」 という） に登場する単語を元に分割したデータ構造を持つ。 図 8は N e X t w o r dインデックスのデータ構造例を示す。 N e x t w o r dインデックスでは、 ある単語をキーとし、 その単語の右に登場した単語 （N e x t w o r d ) の集合を記憶し、 さらに、 キーとなった単語と一つの N e X t w o r dとの組から、 その 2つの語が隣接して登場した文書集合に対する文書リス トを参照することができる。
図 9はインデックスの一例を示す。 この例では、 「の」 という単語の N e x t w o r dとして 「山田」 と 「会社」 が登録されており、 さらにそれぞれに対して 「の 山田」 を含む文書の文書リストと、 「の会社」 含む文書の文書リストが登録されて いることを意味する。 以下の説明では、 このように 2つの単語 （あるいは条件） からなるキ一を 「A→B」 （例えば 「の→山田」 など） と表現し、 Aを 1次キー、 Bを 2次キーと呼ぶこととする。
非特許文献 1に開示された検索システムは、 高い頻度の単語に対してこの N e
X t w o Γ dインデックスを利用することで、 検索速度を向上させている。 例え ば、 検索時にクエリとして 「a b c産業の山田」 というフレーズが入力され、 「a b e産業」 が低い頻度の語、 「の」 が高い頻度の語であると仮定すると、 この検索 システムは次のように検索を行う。 まず、 低い頻度の語に対して通常の転置イン デックスを参照し、 「a b c産業」 に対応する文書リストを得る。 次に、 高い頻度 の語に対しては、 N e x t w o r dインデックスを参照し、 「の→山田」 とレヽぅ参 照から文書リス トを得る。 さらに、 これらの二つの文書リス トを比較し、 同じ文 書で、かつ、登場位置がクエリと同じである文書の集合を出力する。 このように、 Ne X t wo r dインデックスによると、 2つの語の隣接関係をキーとして文書 リストを読み込むことができるため、 検索速度を向上させることができる。
しかし、 この手法はあくまで単純なフレーズ検索のために用いられるものであ り、 タグを付加された文書を対象とした場合、 タグの更新処理に時間がかかると いう問題がある。
図 10は Ne x two r dインデックスを用いた検索システムにおいてタグの 更新処理に時間がかかることを説明する図である。ここでは、「 a b c産業の山田」 というフレーズについて、 タグを追加 ·削除する際に更新が必要な範囲を示す。 図 10において （a) に示すように、 「a b e産業の山田」 という文字列に対し て、 a b e産業に [名詞]、 [企業名] というタグが、 「の」 に対して [助詞] とい うタグが、 山田に対して [人名] というタグが付加されている。 （a) 内の 8本の 点線の矢印は、 それぞれ Ne X two r dインデックス内に作成される隣接関係 のキーを意味する。 なお、 図 10内の 「a b c産業」 は低頻度とし、 通常の転置 インデックスに格納されるものとしている。
このとき、 このうち 「の」 という語に [所属] というタグを追加することを考 える。 この場合、 新たに （b) 内の実線の矢印の関係が発生するため、 「[名詞] → [所属]」 というキー、 「[企業名] → [所属]」 というキー、 「[所属] —山田 J というキー、 「[所属] → [名詞]」 というキーに対応する部分を更新せねばならな レ、。
また、 「の」 に付加された [助詞] というタグを削除することを考える。 この場 合、 同様に （c) 内の実線の矢印の関係を削除しなければならない。 つまり 「[名 詞] → [助詞]」 というキー、 「[企業名] → [助詞]」 というキー、 「[助詞] →山 田 j というキー、 「[助詞] → [固有名詞]」 というキーに対応するについて文書リ ストを参照し、 該当部分を修正する必要がある。
このように、 Ne x two r dインデックスはタグを付加することを想定して おらず、 単純にタグ付き文書に適用すると、 更新する箇所が多く、 タグの更新に 時間がかかるという問題がある。 なお、 これは 2次キーにタグを用いると、 ある タグに関する参照が分散することが原因となっている。 発明の開示：
発明が解決しようとする課題
上述したように、 特許文献 1に記載された検索装置では、 フレーズ検索だけで なく、 階層的なタグ構造によるクエリ （「Z文書 本文 企業名」 という構造を持 つ文書を返せ、 など） も想定しており、 階層的なインデックスを持っために、 ィ ンデッタスの更新に時間がかかっていた。 また、 特許文献 1に記載された検索装 置は、 フレーズを個々の単語の条件に分解した後、 個々の条件で検索する、 とい う思想に基づいており、個々の単語の条件がすべて一般的なパターンである場合、 大量の情報を読み出さなければならず、 検索に時間がかかっていた。
非特許文献 1に記載の検索システムでは、 二つの語の隣接関係を元に読み込む 文書リストの量を削減することができるが、 タグの付加された文書を考慮してお らず、 タグの付加された文書では単語やタグ間の隣接関係が複雑するため、 タグ の更新に時間がかかっていた。
本発明は、 このような課題を角军決し、 タグを含むフレーズの検索において、 一 般的な語句と頻度の高いタグとからなるクエリに対する効率の良い検索と、 タグ の効率良い更新と、 を両立した文書管理 ·検索システムおよび文書の管理 ·検索 方法を提供することを目的とする。
課題を解決するための手段
本発明発の文書管理 ·検索システムは、 単語の集合に対して、 文書集合内での 各単語の出現位置を記憶する単語ィンデックス記憶部と、 単語に付加されてその 単語の属性を表すタグの集合に対して、 各タグの右と左に登場した単語の集合を 記憶し、 さらに各タグとその右に登場する語の組み合わせ、 あるいは、 各タグと その左に登場する語の組み合わせをキーとして文書集合内の各タグの登場位置を 記憶するタグ L Rィンデックス記憶部と、 検索クエリとしてタグと単語から成る フレーズを入力とし、 その検索クエリを解釈した上でフレーズ内の隣接する単語 とタグの左右の関係を利用してタグ L Rィンデックス記憶部を参照し、 そのフレ ーズを含む文書の識別子の一覧を返却する文書検索部と、 特定の文書中の部分文 字列に対してタグを追加 ·削除するクエリを解釈し、 タグ L Rインデックス記憶 部の記憶内容を更新するタグ更新部と、 一つ以上の文書が与えられた場合に、 単 語インデックス記憶部内のインデックスを更新する文書ィンデックス作成部とを 備えたことを特徴とする。
この構成において、 任意の文字列をキーとし、 その文字列に付加されている可 能性のあるタグ名の集合を高速に参照可能とする高速タグ値判定部を備え、 タグ 更新部は、 タグを付加する際に高速タグ値判定部内のデータを更新する手段を含 み、 文書検索部は、 タグが連続するフレーズが検索クエリとして入力された場合 に、 高速タグ値判定部とタグ L Rインデックス記憶部とを参照して、 特定のタグ 名を含む可能性のある単語に絞って問い合わせを実行する手段を含むことが望ま しい。
高頻度語とタグ名とをキーとし、 その単語およびタグをそれぞれ含む文書の集 合を表すビット列を記憶するビット列記憶部を備え、文書ィンデックス作成部は、 文書からインデックスを作成する際にビット列記憶部内のビット列を更新する手 段を含み、 タグ更新部は、 タグを更新する際に追加 ·削除されたタグを元にビッ ト列記憶部内のビット列を更新する手段を含み、 文書検索部は、 検索時に予めク エリに含まれる高頻度語およびタグ名を元にビット列記憶部を参照し、 クエリ内 の高頻度語およびタグ名がすべて含まれる文書番号の集合を得て、 その文書番号 を元に文書集合を絞り込んだ上で文書集合内にフレーズの登場位置を読み込む手 段を含むこともできる。
タグの集合に対して、 各タグ名をキーとし、 文書集合内のタグの登場位置と左 右の単語を記憶するタグ N L Rィンデックス記憶部と、 このタグ N L Rインデッ クス記憶部内のィンデッタスをタグ L Rィンデックス記憶部内のィンデックスに 変換する変換手段と、 タグの登場頻度に基づきィンデッタスの記憶方法を変更す る管理手段とを備えることもできる。
本発明の文書の管理 ·検索方法は、 一つ以上の文書が与えられた場合に、 その 文書に含まれる単語の集合に対し、 各単語をキーとして、 その登場位置を記憶す る文書ィンデックス作成ステツプと、 特定の文書中の部分文字列に対しタグを追 加 ·削除するクエリが与えられた場合に、 そのタグ名をキーとしタグの登場位置 を記憶するタグ更新ステップと、 このタグ更新ステップ内において、 入力された タグに対し、 タグの右と左に登場した単語を記憶し、 さらに各タグとその右に登 場する語の組み合わせ、 あるいは、 各タグとその左に登場する語の組み合わせを キーとして文書集合内の各タグの登場位置を記憶するタグ L R記憶ステップと、 タグと単語から成るフレーズが検索クエリとして与えられた場合に、 その検索ク ェリを解釈した上でフレーズ内の隣接する単語とタグの左右の関係を利用して複 数のキーを作成し、 これらのキーを元に文書インデックス作成ステップにおいて 記憶されたキーを元に単語の登場位置、 タグ更新ステップにおいて記憶されたキ 一を元に各タグの登場位置をそれぞれ参照し、 その上でそれらを統合することで そのフレーズを含む文書の識別子の一覧を返却する文書検索ステップとを含むこ とを特徴とする。
任意の文字列をキーとし、 その文字列に付加されている可能性のあるタグ名の 集合を高速に参照可能とする高速タグ値判定ステップを含み、 タグ更新ステップ は、 タグを付加する際にタグ名と文字列の関係を表すデータを更新するステップ を含み、 文書検索ステップは、 タグ名が連続するフレーズを検索クエリが入力さ れた場合に、 高速タグ値判定ステップを利用し、 特定のタグ名を含む可能性のあ る単語のみに絞ってタグの登場位置を読み込むステップを含むことが望ましい。 文書インデックスステップにおいて高頻度語とタグ名とをキーとし、 その単語 およびタグをそれぞれ含む文書の集合を表すビット列を記憶するビット列記憶ス テツプを含み、 タグ更新ステップは、 タグを更新する際に追カ卩 ·削除されたタグ を元にビット列記憶部内のビット列を更新するステップを含み、 文書検索ステツ プは、 検索クエリに含まれる高頻度語とタグ名とをキーとしてビット列記憶ステ ップで記憶されたビット列を参照し、 クエリ内の高頻度語およびタグ名がすべて 含まれる文書の集合を表すデータを得、 そのデータを元に文書集合を絞り込んだ 上で単語とタグの登場位置を読み込むステップを含むことができる。
タグ更新ステップは、 タグの集合に対して、 各タグ名をキーとし、 文書集合内 のタグの登場位置と左右の単語を記憶するタグ N L Rインデックスステツプを含 み、 タグ更新ステップおよび文書検索ステップは、 タグをキーとしその登場位置 を更新あるいは検索する際に、 そのタグがタグ N L Rインデックスステップで記 憶されているかタグ L R更新ステップで記憶されているかによって、 参照先を選 択するステップと、 タグに関する頻度を元に、 タグ N L Rインデックスステップ で作成されたデータを削除し、 タグ L Rインデックスステツプで作成するィンデ ックス変換ステップとを含むこともできる。
本発明はコンピュータ ·プログラムとして実施することもできる。 すなわち、 一つ以上の文書が与えられた場合に、 その文書に含まれる単語の集合に対し、 各 単語をキーとして、 その登場位置を記憶する文書インデックス作成処理と、 特定 の文書中の部分文字列に対しタグを追加 ·削除するクエリが与えられた場合に、 そのタグ名をキーとしタグの登場位置を記憶するタグ更新処理と、 このタグ更新 処理内において、入力されたタグに対し、タグの右と左に登場した単語を記憶し、 さらに各タグとその右に登場する語の組み合わせ、 あるいは、 各タグとその左に 登場する語の組み合わせをキーとして文書集合内の各タグの登場位置を記憶する タグ L R記憶処理と、 タグと単語から成るフレーズが検索クエリとして与えられ た場合に、 その検索クエリを解釈した上でフレーズ内の隣接する単語とタグの左 右の関係を利用して複数のキーを作成し、 これらのキーを元に文書ィンデッタス 作成処理において記憶されたキーを元に単語の登場位置、 タグ更新処理において 記憶されたキーを元に各タグの登場位置をそれぞれ参照し、 その上でそれらを統 合することでそのフレーズを含む文書の識別子の一覧を返却する文書検索処理と をコンピュータに実行させることを特徴とする。
任意の文字列をキーとし、 その文字列に付加されている可能性のあるタグ名の 集合を高速に参照可能とする高速タグ値判定処理と、 タグ更新処理においてタグ を付加する際にタグ名と文字列の関係を表すデータを更新する処理と、 文書検索 処理においてタグ名が連続するフレーズを検索クエリが入力された場合に、 高速 タグ値判定処理を利用し、 特定のタグ名を含む可能性のある単語のみに絞ってタ グの登場位置を読み込む処理とをさらにコンピュータに実行させることが望まし レ、。 ·
文書インデックス処理において高頻度語およびタグ名をキーとし、 その単語お よびタグを含む文書の集合を表すビット列を記憶するビット列記憶処理と、 タグ 更新処理において、 タグを更新する際に追加 ·削除されたタグを元にビット列記 憶処理で記憶されたビット列を更新する処理と、 文書検索処理において、 検索ク エリに含まれる高頻度語およびタグ名をキーとしてビット列記憶処理で記憶され たビット列を参照し、 クエリ内の高頻度語およびタグ名がすべて含まれる文書の 集合を表すデータを得、 そのデータを元に文書集合を絞り込んだ上で単語とタグ の登場位置を読み込む処理とをさらにコンピュータに実行させることもできる。 タグ更新処理内において、 タグの集合に対して、 各タグ名をキーとし、 文書集 合内のタグの登場位置と左右の単語を記憶するタグ N L Rィンデックス処理をコ ンピュータに実行させ、タグ更新ステップ内および文書検索ステップ内において、 タグをキーとしその登場位置を更新あるいは検索する際に、 そのタグがタグ N L Rインデックス処理で記憶されている力 \ タグ L R更新処理で記憶されているか によって、 参照先を選択する処理と、 タグに関する頻度を元に、 タグ N L Rイン デックス処理で作成されたデータを削除し、 タグ L Rィンデックス処理で作成す るインデックス変換処理とをコンピュータに実行させることもできる。
発明の効果
本発明によれば、 検索時にクエリのフレーズに含まれる隣接した単語とタグに 対し、 タグとその右あるいは左の単語をキーとしてインデックスを参照でき、 読 み込む文書リストの量を削減できるため、 高速に検索処理を行うことができる。 また、 タグを更新する際には、 タグ L Rインデックス記憶部に 2箇所の更新を加 えるのみでタグの更新が可能であり、 少量の更新を行うのみでタグの更新を高速 に行うことができる。 図面の簡単な説明：
図 1は本発明の望ましい第一の実施形態を示すプロック構成図である。
図 2はタグ付けされた文書の一例を示す図である。
図 3はタグが付加された文書を XM Lで表現した例を示す図である。
図 4は XM L D Bで用いられるパス階層を示す図である。
図 5は X M L D Bで用いられるインデックスの論理的構造を示す図である。 図 6は XM L D Bにおいてタグを追加する際に更新が必要な範囲を示す図であ る。
図 7は転置ィンデッタスの一例を示す図である。
図 8は N e x t w o r dインデックスのデータ構造例を示す図である。
図 9は N e X t w o r dインデックスの一例を示す図である。
図 1 0は N e X t w o r dインデックスを用いた検索システムにおいてタグを 追加 ·削除する際に更新が必要な範囲を示す図である。
図 1 1は本発明の第一の実施形態で想定する転置ィンデッタスの例を示す図で ある。
図 1 2はタグ L Rインデックス記憶部内のデータの一例を示す図である。 図 1 3は本発明の望ましい第二の実施形態を示すプロック構成図である。 図 1 4は高速タグ値判定部の構成例を示すプロック図である。
図 1 5はタグ値テーブルの一例を示す図である。
図 1 6は問い合わせタスクのリストの一例を示す図である。
. 図 1 7は文書リスト列の一例を示す図である。
図 1 8は検索プロセスの処理のフローチャートである。
図 1 9はキー列の一例を示す図である。
図 2 0は問い合わせタスクのリストを作成する処理のフローチャートである。 図 2 1は問い合わせタスクの実行処理のフローチヤ一トである。
図 2 2は文書リストの統合処理のフローチヤ一トである。
図 2 3は位置関係のチェック処理を説明する図であり、 キーごとの問い合わせ における 4つのケースを示す図である。
図 2 4は位置関係のチェック処理のフローチャートである。
図 2 5はタグの更新プロセスを説明する図である。
図 2 6は単語と文書番号と登場位置のリストの一例を示す図である。
図 2 7はキー列の一例を示す図である。
図 2 8は本発明の本発明の望ましい第三の実施形態を示すプロック構成図であ る。
図 2 9はビット列記憶部に記憶されるデータの一例を示す図である。
図 3 0は本発明の望ましい第四の実施形態を示すプロック構成図である。 図 3 1はタグ L R文書リストの一例を示す図である。
図 3 2は管理テーブルの一例を示す図である。
図 3 3はィンデックス種が N L Rである場合の処理のフローチヤ一トである。 図 3 4はィンデッタスの最適化プロセスのフローチヤ一トである。 発明を実施するための最良の形態：
本発明を実施するための最良の形態について図面を参照して詳細に説明する。
(第一の実施形態）
図 1は本発明の第一の望ましい実施形態を示すプロック構成図であり、 文書管 理 -検索システムの構成例を示す。 この文書管理 ·検索システムは、 単語の集合 に対して、 文書集合内での各単語の出現位置を記憶する単語ィンデックス記憶部 1 3と、 単語に付加されてその単語の属性を表すタグの集合に対して、 各タグの 右と左に登場した単語の集合を記憶し、 さらに各タグとその右に登場する語の組 み合わせ、 あるいは、 各タグとその左に登場する語の組み合わせをキーとして文 書集合内の各タグの登場位置を記憶するタグ L Rインデックス記憶部 1 4と、 検 索クエリとしてタグと単語から成るフレーズを入力とし、 その検索クエリを解釈 した上でフレーズ内の隣接する単語とタグの左右の関係を利用してタグ L Rイン デックス記憶部 1 4を参照し、 そのフレーズを含む文書の識別子の一覧を返却す る文書検索部 1 5と、 特定の文書中の部分文字列に対してタグを追加 ·削除する クエリを解釈し、 タグ L Rインデックス記憶部 1 4の記憶内容を更新するタグ更 新部 1 2と、 一つ以上の文書が与えられた場合に、 単語インデックス記憶部 1 3 内のインデックスを更新する文書インデックス作成部 1 1とを備える。
単語インデックス記憶部 1 3は、 単語に対する転置インデックス （Nとする） を記憶する。 転置インデックスとは、 単語をキーとし、 文書集合内でその単語が 登場する文書の文書番号とその文書内での登場位置の集合を参照できるデータを 意味する。
図 1 1は本実施形例で想定する転置インデックスの例を示す。 この例では、 「山 田」 という単語をキーとし、 「山田」 という単語が文書集合において 2回登場し、 文書番号が 3 3 3の文書において 1回登場し、 その登場位置は前方から 7文字目 であること、 また、 文書番号が 3 4 6の文書において 2回登場し、 その登場位置 は前方から 4文字目と 2 0文字目であること、 を示している。
単語ィンデックス記憶部 1 3は、 文書ィンデックス作成部 1 1力ゝら、 単語と、 その単語を含む文書の文書番号と、 その文書中での登場位置と、 から成るデータ の集合を受け取る。 単語インデックス記憶部 1 3は、 このデータを各単語をキー とした文書リストとして記憶する。 さらに単語ィンデックス記憶部 1 3は、 問い 合わせ実行手段 1 5 2から、少なくとも一つの単語から成るクエリを受け取ると、 その単語の文書リストを返却する。
タグ L Rインデックス記憶部 1 4は、 タグとその左右の語に対する転置インデ ックスとして、 タグ Lインデックス （T Lとする） とタグ Rインデックス （T R とする） から成るタグ L Rインデックスを記憶する。 タグ Lインデックスはある タグに対して、 そのタグが登場した際にその左に登場した単語の集合と、 そのタ グとその左に登場した単語をキーとするタグ文書リストを記憶する。 同様に、 タ グ Rインデックスはあるタグに対して、 そのタグが登場した際に右側に存在した 単語の集合と、 そのタグとその右に登場した単語をキーとするタグ文書リストを 記憶する。 これにより、 あるタグとその右 Z左に単語が存在するという条件でタ グ文書リストを取り出すことができる。
図 1 2はタグ L Rインデックスの例を示す。 この例では、 [人名] というタグの タグ Lインデックス内に 「の」 と 「最近」 という左の語のリストを、 タグ Rイン デックス内に 「社長」 と 「氏」 という右の語のリスト持つ。 タグ Lインデックス ' タグ Rインデックス内の各データはタグ文書リストへの参照 （ポインタ） として 表現されており、例えば「[人名]→の」に対応するタグ文書リストはポインタ 「# 1 2 5 6」 の位置にあり、 このパターンは全文書中 1 9 8 5 9回発生しており、 文書番号が 3 3 3の文書において [人名] タグが前方から 7文字目から 1 0文字 目に付加されていることを示している。
タグ L Rィンデックス記憶部 1 4は、 タグ更新部 1 2から命令種、 タグ名、 文 書番号、 開始位置、 終了位置、 左の単語、 右の単語を含むデータを受け取り、 内 部のタグ L Rインデックスを更新する。 命令種とは、 少なくとも追加 削除の 2 種類のどちらかを識別する情報である。 タグ名とは、 追加 削除されるタグの名 前を示す。 文書番号とは、 タグを追加ノ削除する対象の文書の文書番号である。 開始位置と終了位置は、 タグを追加 削除する文書内での位置である。 左の単語 は、 開始位置の左に登場する単語である。 右の単語は、 開始位置の右に登場する 単語である。
また、 タグ L Rインデックス記憶部 1 4は、 文書検索部 1 5から、 参照先と参 照キーとからなる問い合わせを受ける。 なお、 このうち参照先とはタグ Lインデ ックスかタグ Rインデックスかのどちらかを示すデータである。 参照キーは 「タ グ名」 カゝ 「タグ名→単語」 で指定される。 タグ L Rインデックス記憶部 1 4は、 参照先と参照キーを入力として問い合わせを受け、 参照キーが 「タグ名」 である 場合、 タグ名を元に参照先のタグ Lインデックス タグ Rインデックス内を参照 し、該当する左の語のリストノ右の語のリストを返却する。 また、参照キーが「タ グ名→単語」 である場合、 「タグ名→単語」 というキーを元に参照先のタグ Lイン デックス タグ Rインデックス内を参照し、該当するタグ文書リストを返却する。 文書ィンデックス作成部 1 1は外部のプログラムあるいはユーザによって実行 され、 一つ以上の文書の集合が与えられた場合に、 文書内に含まれる全単語を取 り出し各単語に対し、 少なくともその単語と、 その文書の文書番号と、 単語がそ の文書の本文内先頭から何文字目に登場するかを表す登場位置と、 を単語インデ ックス記憶部 1 3に入力する。
タグ更新部 1 2は外部のプログラムあるいはユーザによって実行され、 タグの 追加 ·削除に関する命令文を入力とし、 その命令文に従って、 タグ L Rインデッ クス記憶部 1 4内のインデックスを更新する。 タグの追加 ·削除に関する命令文 とは、 命令種、 タグ名、 文書番号、 開始位置、 終了位置、 対象単語列、 左の単語、 右の単語、 力 ら成る情報である。
文書検索部 1 5は外部のプログラムあるいはユーザによって実行され、 一つ以 上のタグあるいは単語からなるフレーズ （検索クエリ） を入力とする。 文書検索 部 1 5はこの入力を元に、 単語インデックス記憶部 1 3と、 タグ L Rインデック ス記憶部 1 4と、 高速タグ値判定部 1 6とに問い合わせを行い、 少なくとも文書 番号のリストを検索結果として出力する。
この実施形態では、 文書の検索時に、 検索クエリに含まれる隣接した単語とタ グに対し、 タグ L Rインデックス記憶部 1 4内に記憶されたインデックスの双方 向性を利用することでインデックスを参照でき、 タグ名を 2次キーに持たなくと も読み込む文書リストの量を削減できるため、 高速に検索処理を行うことができ る。 また、 タグの更新時に、 タグ L Rインデックス記憶部 1 4内の 2箇所に更新 を加えるのみであり、少量の更新でタグの追加'削除を高速に行うことができる。
(第二の実施形態）
図 1 3は本発明の第二の望ましい実施形態を示すブロック構成図であり、 文書 管理 .検索システムの構成例を示す。 この文書管理 ·検索システムは、 任意の文 字列に付加されている可能性のあるタグ名のリストを持ち、 文字列に付加される 可能性のあるタグ名のリストを高速に参照可能とする高速タグ値判定部 1 6を備 えたことが第一の実施形態と異なる。 また、 図 1 3には文書検索部 1 5の詳細を 示す。 すなわち文書検索部 1 5は、 検索クエリを解釈し複数の条件に分解するク エリ解釈手段 1 5 1と、 クエリ解釈手段 1 5 1によって解釈された複数の条件を 元に単語インデックス記憶部 1 3とタグ L Rインデックス記憶部 1 4と高速タグ 値判定部 1 6に対して問い合わせを行う問い合わせ実行手段 1 5 2と、 問い合わ せ実行手段 1 5 2において得られた一つ以上の文書リスト タグ文書リストをお 互いに比較し、 同じ文書番号を持ちかつ検索クエリと同じフレーズを持つ文書だ けの文書リストに統合する文書リスト統合手段 1 5 3と、 を有する。
図 1 4は高速タグ値判定部 1 6の構成例を示すプロック図である。 高速タグ値 判定部 1 6は、 内部に、 タグ値テーブル 1 6 1と、 更新手段 1 6 2と、 判定手段 1 6 3とを備える。 タグ値テーブル 1 ·6 1は、 タグとタグが付加される単語列と の関係を記憶したテーブルである。 更新手段 1 6 2は、 タグの更新部 1 2によつ て呼び出され、 タグ名と、 対象単語列 （タグ付けの対象となる一つ以上の単語） と、 命令種 （追加 Ζ削除のどちらか） を入力とし、 タグ値テーブル 1 6 1内の関 係情報を更新する。 判定手段 1 6 3は、 問い合わせ実行手段 1 5 2によって呼び 出され、 ある単語列を入力とし、 タグ値テーブル 1 6 1を参照した上で、 その単 語列に付加されている可能性のあるタグ名のリストを高速に返す。
図 1 5はタグ値テーブル 1 6 1の一例を示す。 タグ値テーブル 1 6 1として、 単語を 2文字ごとに区切った文字列 （2グラム） と、 その 2グラムに付加される 可能性のあるタグ名のリス ト （タグ名列） との間の関係を記憶したものを用いる ことができる。 このタグ値テーブル 1 6 1は、 メモリ上のプログラムとして実装 することができる。 図 1 5に示した例では、 例えば 「山田」 が含まれる文字列に は、 [人名] タグか [地名] タグが付カ卩される可能性があることを示している。 な お、 この例では、 元々 1文字の単語 （「の」 など） に関しては、 1文字のままタグ 値テーブル内に記憶するものとしている。
このようなタグ値テーブル 1 6 1に対して更新手段 1 6 2は、 タグ更新部 1 2 によって入力された対象単語列を 2グラムごとに区切り、 各 2グラムでタグ値テ 一ブル 1 6 1を参照し、対応するタグ名列を更新する。また、判定手段 1 6 3は、 問い合わせ実行手段 1 5 2によって入力された文字列を 2グラムごとに区切り、 タグ値テーブル 1 6 1を参照した上で、 その文字列に付加されている可能性のあ るタグ名のリストを返す。
文書検索部 1 5内のクエリ解釈手段 1 5 1、 問い合わせ実行手段 1 5 2および 文書リス ト統合手段 1 5 3について説明する。
クエリ解釈手段 1 5 1は、外部のプログラムあるいはユーザによって実行され、 検索クエリを入力とし、 問い合わせ実行手段 1 5 2に問い合わせタスクのリスト を出力する。 問い合わせタスクとは、 参照先と参照キー、 位置番号から成るデー タである。 参照先とは、 問い合わせ時に参照するインデックスを意味しており、 単語ィンデックス記憶部 1 3内の転置ィンデックス （ N ) か、 タグ L Rィンデッ クス記憶部 1 4内のタグ Lインデックス （T L ) 、 タグ Rインデックス （T R) か、 のどれかである。 参照キーは、 インデックス内から文書リストを取り出すた めのキーであり、 参照先が Nである場合は一つの単語、 参照先が T Lか T Rであ る場合は 「[タグ名] —単語」 あるいは 「[タグ名] → [タグ名]」 のような文字列 で表現される 1次キーと 2次キーのセッ トである。 なお、 本発明では 2次キーが タグ名となるインデックスを持たないため、 単純に 「[タグ名] → [タグ名]」 を キーとしたタグ文書リストを取得することはできないが、 この点はこの時点では 考慮しない。 また、 位置番号とは、 参照キーのクエリ中での位置を示しており、 キー列内の位置番号から作成される。
図 1 6は、 問い合わせタスクのリストの一例として、 「[企業名] の [人名]」 と いうクエリを元に作成されたものを示す。 この例では、 位置番号が 1であり参照 先が T Rすなわちタグ Rインデックスであり参照先が 「[企業名]→の」 である問 い合わせタスクと、 位置番号が 3であり参照先が T Lすなわちタグ Lィンデック スであり参照先が 「[人名]—の」 である問い合わせタスクとの二つの問い合わせ タスクが作成されている。
問い合わせ実行手段 1 5 2は文書検索部 1 5によって呼び出され、 問い合わせ タスクのリス トを入力とする。 問い合わせ実行手段 1 5 2は、 この問い合わせタ スクのリストを元に、単語ィンデックス記憶部 1 3と、高速タグ値判定部 1 6と、 タグ L Rインデックス記憶部 1 4と、 を参照し、 文書リスト列を文書リスト統合 手段 1 5 3に出力する。
図 1 7は文書リスト列の一例を示す。 文書リスト列とは、 単語インデックス記 憶部 1 3とタグ L Rインデックス記憶部 1 4から得られた文書リス ト ·タグ文書 リス トの集合について、 それぞれの文書リストと問い合わせタスクとを関連付け る情報である。 図 1 7に示した例では、 各問い合わせタスクの位置番号と、 参照 キーと、 問い合わせによって得られた文書リストとを関係づけている。
文書リスト統合手段 1 5 3は文書検索部 1 5によって呼び出され、 文書リスト 列を入力とし、それらを一つにまとめた文書リストを結果リストとして出力する。 次に、 この実施形態における処理の流れを説明する。 この実施形態おける処理 は主に、 検索プロセスと、 タグの更新プロセスと、 文書のインデックスプロセス の 3つのプロセスを持つ。 以下ではこれらを順に説明する。
図 1 8は検索プロセスの処理の流れを示す。 検索プロセスは、 ユーザもしくは 外部のプログラムが検索クエリを文書検索部 1 5に入力することで開始する。 文書検索部 1 5はまず、 クエリ解釈手段 1 5 1を利用し、 入力された検索クェ リからキー列を作成する （S 1 1 )。 この処理は形態素解析や Nグラムなど、 何ら かの辞書やルールを用いて行われる。 例えば、 検索クエリの構文として、 タグは 「口 と 「]」 で囲まれ、 その内部にタグ名あるいは、 「タグ名 ：タグが付カ卩される 文字列」 が記述されるもの、 タグ以外の部分は自然言語で記述されるもの、 とし て定義すると、 この処理は、次のように行われる。 クエリ解釈手段 1 5 1はまず、 検索クエリに対して 「[」 と 门」 で囲まれる部分を取り出し、 タグ名、 あるいは タグ名とタグが付加される文字列を取り出す。 次に、 クエリ解釈手段 1 5 1は形 態素解析を行い、 入力されたフレーズを単語ごとに区切った上でキー列を作成す る。 キー列は単語キーの列とタグキーの列であり、 単語キーとはフレーズ内の一 つの単語を表す。 タグキーはフレーズ内の一つのタグ名を表す。 単語キーとタグ キーはフレーズを単語 ·タグごとに区切った場合に各単語ノタグが先頭から何番 目に登場するかを表す位置番号と共に記憶される。
図 1 9はキー列の一例を示す。 ここでは、 「[企業名 ： a b c産業] の [人名] 社長]」 というフレーズを元に作成したキー列を示す。 このクエリは、 [企業名] タグが付加された 「a b e産業」 という文字列、 「の」 という文字列、 [人名] タ グが付加された任意の文字列、 「社長」 という文字列、 が連続して登場する文書を 返せ、 というクエリを意味し、 図 1 9では、 位置 1に 「a b c産業」 という単語 と [企業名] というタグが、 位置 2に 「の」 という単語が、 位置 3に [人名] と いうタグが、 位置 4に 「社長」 という単語が示される。 またそれ以外の位置に記 述されている 「一」 は、 その位置に条件が無いことを意味している。
次にクエリ解釈手段 1 5 1は、 キー列を元に、 問い合わせタスクのリスト （タ スクリスト） を作成する （S 1 2 )。 このステップ S 1 2について、 本発明では、 次の条件に基づいて問い合わせタスクを作成する任意の処理として定義する。 ' [条件 1 ] キー列内の各タグキーに対して、 そのタグを 1次キーとする問い合わ せタスクを一つ以上作成すること。
· [条件 2 ] キー列内の各単語キーに対して、 その単語がキーに含まれる問い合わ せタスクを一つ以上作成すること。
• [条件 3 ] 単語とタグが並んでいる場合は、 タグ L Rインデックス記憶部 1 4へ の問い合わせを優先的に選択して問い合わせタスクを作成すること。
図 2 0は問い合わせタスクのリストを作成する処理（図 1 8のステップ S 1 2 ) を実現するアルゴリズムの一例のフローチャートを示す。
クエリ解釈手段 1 5 1はまず、 キー列内の各タグキーの左右に単語がある場合 に、 タグ L Rインデックス記憶部 1 4への問い合わせタスクを作成する （S 1 2 1 )。 クエリ解釈手段 1 5 1は、 キー列を左から （位置 1から） 順番に調べ、 タグ キーの右に単語キーが存在しないか調べる。 存在する場合には、 参照先を 「T R」 とし、 参照キーを 「そのタグキーのタグ名—その右の単語」、 位置を 「そのタグキ 一の位置番号」 をとして問い合わせタスクを作成し、 タスクリストに追加する。 タグキーの右に単語キーが存在しない場合には、 タグキーの左に単語キーが存在 しないか調べる。 存在する場合には、 参照先を 「T L」 とし、 参照キーを 「その タグキーのタグ名→その左の単語」、位置を 「そのタグキーの位置番号」 をとして 問い合わせタスクを作成し、 タスクリストに追加する。
次にクエリ解釈手段 1 5 1は、 まだ問い合わせタスクが作成されていないタグ キーに対して、 タグを連結した問い合わせタスクを作成する （S 1 2 2 )。 クエリ 解釈手段 1 5 1はキー列を左から （位置 1から） 順番に調べ、 タグキーを 1次キ 一とする問い合わせタスクがまだ作成されていなレ、場合、 そのタグキーの右にタ グキーが存在しないか調べる。 存在する場合には、 参照先を 「T R」 とし、 参照 キーを 「そのタグキーのタグ名→右のタグキーのタグ名」、位置を 「そのタグキー の位置番号」 をとして問い合わせタスクを作成し、 タスクリストに追加する。 タ グキーの右に単語キーが存在しない場合には、 タグキーの左に単語キーが存在し ないか調べる。 存在する場合は、 参照先を 「T L」 とし、 参照キーを 「そのタグ キーのタグ名→左のタグキーのタグ名」、位置を 「そのタグキーの位置番号」 をと して問い合わせタスクを作成し、 タスクリストに追加する。
最後に、 クエリ解釈手段 1 5 1は、 まだ問い合わせタスクが作成されていない 単語キーに対して、 問い合わせタスクを作成する （S 1 2 3 )。 クエリ解釈手段 1 5 1はキー列を左から （位置 1から） 順番に調べ、 単語キーを 1次キーあるいは 2次キーとする問い合わせタスクがまだ作成されていない場合、 参照先を 「NJ、 参照キーを 「その単語」、 位置を 「その単語の位置」 をとして問い合わせタスクを 作成し、 タスクリストに追加する。
なお、 図 2 0のフローチャートで示されるアルゴリズムは右方向 （Rインデッ クス） への参照を優先するアルゴリズムになっているが、 左方向を優先したアル ゴリズムも考えられる。 また、 上記の 3つの条件を満たす上で左右どちらの参照 でも良い場合に、 両方の参照を元に文書リス トの先頭の頻度を読み込み、 少ない 方を選択する、 というアルゴリズムも考えられる。
次に、 クエリ解釈手段 1 5 1が作成した問い合わせタスクの集合を元に、 問い 合わせ実行手段 1 5 2で各インデックスに問い合わせを行う （S 1 3 )。 図 2 1に この処理を実現するアルゴリズムの一例のフローチャートを示す。 この処理はス テツプ S 1 2で作成された問い合わせタスクそれぞれに対して行われる。
問い合わせタスクの参照先が 「N」 である場合、 問い合わせ実行手段 1 5 2は その問い合わせタスクの参照キーで単語インデックス記憶部 1 3を調べ、 該当す る文書リストを読み込み、 問い合わせタスクの参照キー、 位置情報と共に保持す る （S 1 3 1 )。
また、 問い合わせタスクの参照先が 「T L」 もしくは 「T R」 である場合、 問 い合わせ実行手段 1 5 2はその問い合わせタスクの参照キー内の 2次キーが単語 であるかタグであるかを調べる。 単語である場合、 参照先と参照キー 「タグ名→ 単語」 とをタグ L Rインデックス記憶部 1 4に問い合わせ、 該当するタグ文書リ ストを読み込む（S 1 3 2 )。 問い合わせタスクの参照キー内の 2次キーがタグで ある場合、 問い合わせ実行手段 1 5 2はタグ L Rインデックス記憶部 1 4と高速 タグ値判定部 1 6を利用してタグ文書リストを読み込む （ S 1 3 3 )。
ステップ S 1 3 3の処理をさらに詳細に説明する。 問い合わせ実行手段 1 5 2 はまず、 参照先と 「1次キーのタグ名」 とをタグ L Rインデックス記憶部 1 4に 問い合わせ、 Lインデックスノ Rインデックス内の左の語のリスト 右の語のリ ストを得る （S 1 3 3 1 )。 次に問い合わせ実行手段 1 5 2は、 右の語のリストノ 左の語リスト内の各単語を高速タグ値判定部 1 6に入力し、タグ名列を取得する。 そしてタグ名列に 2次キーのタグ名が含まれるかどうかを調べ、含まれない場合、 その単語は読み込んだ右の語のリストノ左の語リストから削除する（S 1 3 3 2 )。 次に問い合わせ実行手段 1 5 2は、 1次キーのタグ名と、 右の語のリストノ左 の語リスト内の各語を 2次キーとしたものを参照キーとして利用してタグ L Rィ ンデックス記憶部 1 4に問い合わせを行い、 得られたタグ文書リス トの集合を足 し合わせたものを一つのタグ文書リス トとする。
ステップ S 1 3の処理においては、 複数の問い合わせタスクを実行するが、 そ の順番は任意で良い。 さらに、 ある問い合わせタスクの結果から文書番号のリス ト D Lを保持しておき、 それ以降の問い合わせタスクにおいて文書リスト タグ 文書リストを読み込む際に、 D L内に文書番号が含まれない登場位置/開始位置 と終了位置を読み込まないことで処理の高速化を計ることもできる。
ここでは高速タグ値判定部 1 6を利用したアルゴリズムについて説明したが、 このアルゴリズムを少し修正することで、 第一の実施形態のように高速タグ値判 定部 1 6を設けない場合にも利用することができる。 例えば、 図 2 1のフローに よって示されるアルゴリズムにおいて、 ステップ S 1 3 3 2を行わず、 ステップ S 1 3 3 3において、 1次キーのタグ名だけを条件としすべての右の語のリスト
Z左の語リストに対してタグ文書リストを読み込む、 などが考えられる。 また、 予め一つのタグ名だけをキーとしたタグ文書リストを記憶する転置ィンデックス を作成しておき、 ステップ S 1 3 3を、 1次キーだけを用いてその転置インデッ タスを参照し、 タグ文書リストを読み込む処理、 に置き換えても良い。
次に、 問い合わせ実行手段 1 5 2によって得られた M本の文書リストノタグ文 書リストから成る文書リスト列を元に、 文書リスト統合手段 1 5 3で、 文書番号 がすべて等しくかつ単語 ·タグの登場位置がキー列と等しい文書の文書番号を取 り出す （S 1 4 )。 図 2 2にこの処理を実現するアルゴリズムの一例のフローチヤ ートを示す。 なお、 このアルゴリズムは、 単語インデックス記憶部 1 3内に記憶 される文書リストと、 タグ L Rィンデックス記憶部 1 4内に記憶されるタグ文書 リストと、 がそれぞれ文書番号と登場位置 Z開始位置を元にソートされているこ とを前提とする。
文書リスト統合手段 1 5 3はまず、 各文書リストに対応する M個の整数値のポ インタを用意し、 初期値をすベて 1として作成する （S 1 4 1 )。 次に文書リスト 統合手段 1 5 3は、 各文書リストノタグ文書リストからポインタ番目にある登場 位置とその文書番号のセット 開始位置と終了位置と文書番号のセットを取り出 す （S 1 4 2 )。 次に文書リスト統合手段 1 5 3は、 ステップ S 1 4 2で得られた M個の文書番号がすべて等しいかどうか （S 1 4 3 )、 また、 それぞれの登場位置 が、 キー列の位置番号の隣接関係と正しいかどうか （S 1 4 4 ) を調べ、 それら の条件を満たす場合、 その文書がヒッ トしたと判定し、 文書番号を出力結果リス トに追加する （S 1 4 5 )。 そうでない場合、 M個のポインタのうち、 最小のもの に 1を足し （S 1 4 6 )、 そのボインタが文書リストの末尾に達したかどうかを調 ベる （S 1 4 7 )。 もし末尾に達している場合、 処理を終了する （S 1 4 8 )。 そ うでない場合、 ステップ S I 4 2に戻る。
図 2 3はステップ S 1 4 4のアルゴリズムを説明する図である。 このアルゴリ ズムでは、 キー列を左から順番に調べていき、 各キーを 1次キーとして得た文書 中の登場位置 Z開始位置と、 一つ左のキーから得た終了位置と比較し、 隣接して いるかどうかを調べていく。 ただし、 この評価の方法は i番目のキーに対してど のように問い合わせが行われたかに依存する。 そこでまず、 位置 iのキーに対し てその問い合わせ方を 4つのケースに分類する。 図 2 3はこの 4つのケースを示 し、 各ケースを表現するために、 それぞれキー列の例とそのキー列において問い 合わせに使用した 1次キーを点線の楕円で、 1次キーから 2次キーへの参照を点 線の矢印で表現している。
まず、 ケース Aは i番目のキーを 1次キーとして使用した問い合わせが存在し ないケースである。 このケースは図で示すように単語キーが 2次キーとして使用 されたケースである。 ケース Bは i番目にタグキーのみが存在し、 1次キーがタ グである問い合わせが行われたケースである。 よって、 1次キーがタグである問 い合わせ （この例では 「B→A」） に対して位置のチェックを行う必要がある。 ケ ース Cは i番目に単語キーのみが存在し、 単語キーを 1次キーとして問い合わせ が行われたケースである。 よって、 この単語キーのみを利用した問い合わせに対 して位置のチェックを行う必要がある。 ケース Dは i番目に単語キーとタグキー の両方があり、 それぞれを 1次キーとした問い合わせが行われたケースである。 よって、 これらの問い合わせに対してそれぞれ位置関係をチェックする必要があ る。 そこで本アルゴリズムでは、 これらのケースごとに位置のチェックを行って いくこととする。
図 2 4はステップ S 1 4 4のアルゴリズムを説明するフローチャートである。 ステップ S 1 4 4において文書リスト統合手段 1 5 3は、 まず、 二つの変数 i を 1に Pを一 1に初期化する （S 1 4 4 0 1 )。 なお、 本アルゴリズムはキー列を 左から順番に調べていく処理になっており、 変数 iは現在調べているキーのキー 列内での位置を表す。 また、 変数 Pは一つ左のキーから予測される位置 i番目の キーの文書内での登場位置 開始位置を表す。
次に文書リスト統合手段 1 5 3は、 キー列 i番目のキーに対してどのような問 い合わせが行われたかを判定する （S 14402)。 この判定処理は、 位置番号が i となっている問い合わせタスクの参照キーにおいて 1次キーを調べ、 それがタ グキーであるか単語キーであるかを調べることで行われる。 ケース Aの場合、 位 置チェックは行われず、 Pが初期値 （_ 1) で無ければ次の （ i + 1番目の） キ 一の位置チェックに備え、 Pに単語キーの文字長を足す （S 14403)。
ケース Bの場合、 i番目のタグキーに対する位置チェックが行われる （S 14 404)。 タグキーに対する位置チェックとは、次の条件 T 1と T 2が満たされる かどうかを判定する処理を指す。
条件 T 1 ： タグキーを 1次キーとした問い合わせが複数ある場合に、 それぞれの 問い合わせで得られた開始位置同士と終了位置同士が一致していること。
条件 T2 ： Pが _ 1である （タグキーが先頭である）、 もしくは、 Pがタグキーを 1次キーとして得られた開始位置と等しい （左のキーで得られた登場位置と隣接 している） こと。
これらが満たされる場合、 一致しているとみなし、 Pにタグキーを元に得られた 終了位置 + 1を代入する（S 14405)。そうでない場合、一致しないと判定し、 S 144の処理を終える。
ケース Cの場合、 i番目の単語キーに対する位置チェックが行われる （S 14 406)。 単語キーに対する位置チェックとは、次の条件 Wが満たされるかどうか を判定する処理を指す。
条件 W: Pが _ 1である （単語キーが先頭である）、 もしくは、 Pが単語キーを 1 次キーとして得られた登場位置と等しい （左のキーで得られた登場位置と隣接し ている） こと。 これが満たされる場合、 一致しているとみなし、 Pに単語キーを 元に得られた登場位置 +単語キーの文字長を代入する （S 14407)。 そうでな い場合、 一致しないと判定し、 S 144の処理を終える。
ケース Dの場合、 i番目の単語キーとタグキーに対する位置チェックが行われ る （S 14408)。 単語キーとタグキーに対する位置チェックとは、 条件 T l、 条件 Τ2、 条件 Wの条件に加え、 次の条件 TWがすべて満たされるかどうかを判 定する処理を指す。
条件 TW：タグキーを 1次キーとした問い合わせから得た終了位置と、 単語キー をキーとした問い合わせから得た登場位置 +単語キーの文字長と、 がー致するこ と。
これが満たされている場合、 一致しているとみなし、 Pにタグキーを元に得られ た終了位置 + 1を代入する （S 1 4 4 0 9 )。 そうでない場合、 一致しないと判定 し、 S 1 4 4の処理を終える。
さらに、 ステップ S 1 4 4 1 1において文書リスト統合手段 1 5 3は iに 1を 足し、 iがキー列の長さを超えないかを調べ （S 1 4 4 1 2 )、 もし超える場合、 すべての位置関係が正しいと判断し、 S 1 4 4の処理を終える。そうでない場合、 ステップ S 1 4 4 0 2に戻る。
最後に、 文書検索部 1 5は文書リスト統合手段 1 5 3によって得られた結果リ ストを出力する （S 1 5 )。
次に、 文書インデックスの作成プロセスについて説明する。 文書インデックス の作成プロセスは、 外部のプログラムあるいはユーザによって一つ以上の文書が 入力されることによって、 動作を開始する。
一つ以上の文書が入力されると、 文書インデックス作成部 1 1は、 入力された それぞれの文書に対して、 文書の本文を読み込み、 形態素解析プログラムや Nグ ラム作成プログラムを用いて本文を単語ごとに区切り、単語列を作成する。次に、 文書インデックス作成部 1 1は単語列を前方から順に調べ、 各単語に対して文書 先頭前方からの文字数を登場位置として数える。 さらに文書インデックス作成部 1 1は、 単語インデックス記憶部 1 3に対して各単語、 文書番号、 登場位置を与 える。
図 2 5はタグの更新プロセスを説明する図である。 タグの更新プロセスは、 外 部のプログラムあるいはユーザによってタグの追加 ·削除に関する命令文が入力 され、 タグ更新部 1 2が呼び出されることによって開始される。 タグの追加 *削 除に関する命令文とは、 命令種 （追加ノ削除）、 タグ名、 文書番号、 開始位置、 終 了位置、 タグ付けされる （されている） 対象文字列、 タグの左の単語、 タグの右 の単語、 から成る情報である。
命令文が入力されると、 タグ更新部 1 2は、 タグ名とタグ付けされる左の語を 元にタグ L Rィンデックス記憶部 1 4内の Lインデックスを参照し、 該当のタグ 文書リストを命令種に応じてタグ文書リストの更新を行う （S 2 1 )。命令種が追 加である場合、 該当のタグ文書リストに、 文書番号とタグの開始位置とタグの終 了位置とを追加する。 命令種が削除である場合、 該当するタグ文書リストを読み 込み、 文晝番号、 開始位置、 終了位置が一致する部分を探し、 その部分を削除す る。 同様に、 タグ名とタグ付けされる右の語を元にタグ L Rインデックス記憶部 1 4内の Rインデックスを参照し、 文書番号とタグの開始位置とタグの終了位置 の追加 ·削除を行う （S 2 2 )。
次にタグ更新部 1 2は、高速タグ値判定部 1 6内の更新手段 1 6 2を呼び出し、 命令種、 タグ名、 タグ付けされる対象文字列を入力する （S 2 3 )。 例えば、 タグ 値テーブル 1 6 1が図 1 5に示すテーブルをメモリ上のプログラムとして実装し たものであるとする。 この場合、 更新手段 1 6 2は、 命令種が追加である場合、 タグの付加された文字列を 2グラムに区切り、 各 2グラムに対してタグ値テープ ル 1 6 1を参照し、 入力されたタグ名がタグ名列に含まれるか否かを調べる。 も しタグ名がタグ名列に含まれない場合、 そのタグ名をタグ名列に追加する。 命令 種を調べ削除である場合、 何もしない。 なお、 第一の実施形態のように高速タグ 値判定部 1 6を用いない場合には、 S 2 3の処理を行わないものとする。
以上説明した実施形態の動作について、 具体的な例を用いてさらに詳しく説明 する。
ここではまず、 文書インデックスの作成プロセスについて説明する。 例えば、 図 2に示した文書 3 3 3が文書インデックス作成部 1 1に入力されると、 文書ィ ンデックス作成部 1 1は本文内の単語を区切り、 単語と文書番号と登場位置のリ ストを作成する。 このリス トの一部を図 2 6に示す。 次に文書インデックス作成 部 1 1は、 このリストを単語インデックス記憶部 1 3に入力する。 単語インデッ タス記憶部 1 3は図 2 6のリストを元に、 転置インデックスを作成する。 この転 置インデックスの一部の例が図 1 1に示したものである。
次に、 タグの更新プロセスについて説明する。 例えば、 図 2に示した文書 3 3 3の 7文字目から 1 0文字目の 「山田太郎」 という 2単語に、 「人名」 というタグ を付加することを考える。 このとき、 命令文として 「命令種 （タグ名、 文書番 号、 開始位置、 終了位置、 対象語、 左の語、 右の語)」 という構文を想定すると、 「A D D (" 人名"、 3 3 3、 7、 1 0、" 山田太郎"、 " の"、" 社長"）」 とレ、う命 令文が入力される。 なお、 「A D D」 は追加を意味する。
このとき、 タグ更新部 1 2は、 タグ L Rインデックス記憶部 1 4内の Lインデ ックスに 「[人名] →の」 というキーで問い合わせを行い、 該当するタグ文書リス トに、 文書番号 3 3 3、 開始位置 7、 終了位置 1 0を追記する。 さらに、 タグ Rインデックス記憶部 1 4内の Rインデックスに 「[人名]→社長」 というキーで 問い合わせを行い該当するタグ文書リス トに、 文書番号 3 3 3、 開始位置 7、 終 了位置 1 0を追記する。 この結果作成されたタグ L Rインデックス記憶部 1 4内 のデータが図 1 2に示したものである。
また、 タグ更新部 1 2は、 命令文内の [人名] というタグ名と、 「山田太郎」 と いう文字列と、 命令種 「A D D」 とを、 高速タグ値判定部 1 6内の更新手段 1 6 2に入力する。 更新手段 1 6 2は 「山田太郎」 という文字列を 2文字ごとに区切 り、 「山田」、 「田太」 および 「太郎」 という文字列を作成する。 次に更新手段 1 6 2は、 タグ値テーブル 1 6 1を参照し、 「山田」、 「田太」 および 「太郎」 をキーと するタグ名列を参照し、 「人名」 が含まれていない場合、 「人名」 を追加する。 こ の結果作成されたタグ値テーブル 1 6 1の例が図 1 5に示したものである。 次に、 削除の例を挙げる。 ここでは同様に、 図 2に示した文書 3 3 3の 7文字 目から 1 0文字目の 「山田太郎」 という 2単語に付加された 「人名」 というタグ を付加することを考える。 このとき、命令文として 「RM ("人名"、 3 3 3、 7、 1 0、" 山田太郎"、 " の"、" 社長"）」 という命令文が入力される。 なお、 「RMJ は削除を意味する。
このとき、 タグ更新部 1 2は、 タグ L Rインデックス記憶部 1 4内の Lインデ ックスに 「[人名] →の」 というキーで問い合わせを行い、 該当するタグ文書リス トを読み込み、 文書番号 3 3 3、 開始位置 7、 終了位置 1 0となっている部分を 削除する。
さらに、 タグ L Rインデックス記憶部 1 4内の Rインデックスに 「[人名] →社 長」というキーで問い合わせを行い該当するタグ文書リストに、文書番号 3 3 3、 開始位置 7、 終了位置 1 0となっている部分を削除する。
また、 タグ更新部 1 2は、 命令文内の [人名] というタグ名と 「山田太郎」 と いう文字列と命令種 「RM」 を高速タグ値判定部 1 6内の更新手段 1 6 2に入力 する。 この場合、 命令種が 「R M」 （削除） であるため、 更新手段 1 6 2は何もし ない。
次に、 検索プロセスの具体的な例を示す。 例えば、 検索クエリの構文として、 タグは 「口 と 「]」 で囲まれ、 その内部にタグ名あるいは、 「タグ名 ：タグが付カロ される文字列」が記述されるもの、タグ以外の部分は自然言語で記述されるもの、 として定義したときに、 「[企業名] の [人名]」 というクエリが投げられた場合、 文書検索部 1 5は次のように動作する。
クエリ解釈手段 1 5 1はまず、 このクエリを解釈し、 図 2 7に示したキー列に 変換する （S 1 1 )。 次にクエリ解釈手段 1 5 1は、 このキー列を元にステップ S 1 2 1の処理を行い、 図 1 6に示した問い合わせタスクを作成する （S 1 2 )。 問い合わせ実行手段 1 5 2は、 これら二つのタスクをそれぞれタグ L Rインデ ックス記憶部 1 4に問い合わせ、図 1 7に示したような文書リスト列を作成する。 文書リスト統合手段 1 5 3は、 この文書リスト列を元に、 文書番号が一致し、 各単語 タグがフレーズ通りになっている文書集合を表す結果リストを作成する。 この処理は次のように行われる。
文書リスト統合手段 1 5 3はまず、 図 1 7に示したタグ文書リストを先頭から 順に読み込み、 「[企業名] —の」 という問い合わせから文書番号 3 3 3、 開始位 置 1、 終了位置 5、 「[人名] →の」 という問い合わせから文書番号 3 3 3、 開始 位置 7、 終了位置 1 0、 というデータを読み出す （S 1 4 2 )。
文書リスト統合手段 1 5 3は、 これらのデータの間で文書番号が一致している ことを確かめ （S 1 4 3 )、 ステップ S 1 4 4の処理に進む。 ステップ S 1 4 4で 文書リスト統合手段 1 5 3は、 キー列を前方から順に調べる。 キー列の 1番目は タグキー [企業名] であり、 [企業名] を 1次キーとする問い合わせタスクが存在 するため、 ステップ S 1 4 4 0 2ではケース Bとして判定し、 S 1 4 4 0 4の処 理を行う。 ここではタグキーが単一で Pが初期値の一 1であるため、 ステップ S 1 4 4 0 5の処理を行い、 P = 6 (「[企業名] →の」 という問い合わせから得た 終了位置 5 + 1 ) とされる。
次に文書リスト統合手段 1 5 3は、 キー列 2番を読み込む。 キー列の 2番目は 「の」 であるが、 「の」 を 1次キーとする問い合わせタスクが存在しないため、 ス テツプ S 14402ではケース Aとして判定し、 Pに 「の」 の長さ 1を加え、 P = 7とする （S 14403)。
次に文書リスト統合手段 1 53は、 キー列の 3番目を読み込む。 キー列の 3番 目は [人名] であり、 該当する問い合わせタスクが存在するため、 さらに、 キー 列 3番のタグキー [人名] に対しては、 ステップ S144◦ 2でケース Bとして 判定し、 「[人名] →の」 という問い合わせから得られた開始位置 7と Pの比較を 行う （S 14404)。 現在 P= 7であるため、 [企業名] タグと 「の」 と [人名] タグが隣接しており、 文書リスト統合手段 1 53はステップ S 14405、 S 1 4410、 S 1441 1の処理を経て、 正しいと判定され、 S 145の処理を行 う。 S 145では、 文書番号 333を結果リストに加える。
文書リスト統合手段 153は、 S 147の条件を満たすまでこの処理を行い、 最終的に得られた結果リストを出力する （S 15)。
また、 別の検索クエリの例として 「[企業名] [助詞] [人名]」 というフレーズ を考える。 この例の場合、 クエリ解釈手段 151はクエリを解釈し （S 1 1)、 キ 一列に変換した上で下記の問い合わせタスクを作成する （S 12)。
•参照先 「TR」、 参照キー 「[企業名] → [助詞]」、 位置 「1」
，参照先 「TR」、 参照キー 「[助詞] → [人名]」、 位置 「2」
•参照先 「TL」、 参照キー 「[人名] → [助詞]」、 位置 「3」
問い合わせ実行手段 152は、 ステップ S 1 3の処理において、 各問い合わせ タスクをタグ LRインデックス記憶部 14に問い合わせる。 なお、 ここではこの うち、 参照先 「TL」、 参照キー 「[人名] → [助詞]」、 位置 「3」 の問い合わせ タスクについて説明する。
システムはまず、 [人名] を 1次キーとして、 図 1 3に示した左の語リストとし て、 「の」 と 「最近」 を読み込む （S 1 33 1)。 次に問い合わせ実行手段 1 52 は、 高速タグ値判定部 16にそれぞれの語を問い合わせ、 助詞が含まれる可能性 が無い語を削除する。 例えば、 高速タグ値判定部 16内のタグ値テーブルが図 1 5の通りであるとすると、 「最近」 という語に助詞は含まれないので削除する （S 1 332)。 次に問い合わせ実行手段 1 52は、 残った語 「の」 を利用して 「[人 名] → 「の」」 という参照を元にタグ Lインデックス内からタグ文書リストを読み 出す （S 1 3 3 3 )。 以降のステップ S 1 4、 S 1 5は前述の例と同様であるため 説明を省略する。
この実施形態では、 第一の実施形態と同様に、 高速に検索処理を行うことがで きるとともに、 少量の更新でタグの追加 ·削除を高速に行うことができる。 さら に、 任意の文字列をキーとし、 その文字列に付加されている可能性のあるタグ名 の集合を高速に参照可能とする高速タグ値判定部 1 6を備えたことにより、 検索 時に隣接したタグ A Bに対し、 Aの右に登場する単語の集合に対して Bのタグが 付加されている可能性のある単語に絞ってタグ文書リストを読み出すことができ るため、 タグが隣接するクエリに対しても高速にフレーズを高速に参照できる。
(第三の実施形態）
図 2 8は本発明の第三の望ましい実施形態を示すブロック構成図であり、 文書 管理.検索システムの構成例を示す。 この文書管理 ·検索システムは、 本発明の 第二の実施形態の構成に、 ビット列記憶部 1 7をさらに備える。
ビット列記憶部 1 7は、 単語あるいはタグ名と、 各単語あるいはタグ名に対し て、 そのタグ名がどの文書に含まれるかを表すビット列との関係を記憶する。 こ のビット列は文書集合と同じ長さを持ち、 各ビットが各文書に对応し、 キーが各 文書に含まれている （1 ) かそうでない （0 ) かを表す。
図 2 9はビット列記憶部 1 7内に記憶されるデータの一例を示す。 このデータ は N番目のビットが文書番号 N番に対応しており、 例えば、 「は」 という単語は文 書番号 1番、 2番、 3番、 4番、 6番 · · ·の文書に含まれ、 また、 [人名] という タグは文書番号 1番、 2番、 4番、 5番 · · ·の文書に含まれることを意味している。 なお、 図 2 9はビット列記憶部 1 7で管理されるデータの論理的な関係を表した ものであり、 実際のデータの記憶形式はどのようなものでも良いものとする。 ビット列記憶部 1 7は、 文書ィンデックス作成部 1 1から単語と文書番号を受 け取り、 入力された単語をキーとするビット列の更新を行う。 また、 ビット列記 憶部 1 7は、 タグ更新部 1 2からタグ名と文書番号と命令種とを受け取り、 この タグ名に対応するビット列を更新する。 また、 ビット列記憶部 1 7は、 問い合わ せ実行手段により呼び出され、 単語またはタグ名を入力とし、 内部に対応するキ 一が存在する場合、 対応するビット列を返却する。
このとき、 検索プロセスは次のように行われる。 文書検索部 1 5に検索クエリ が入力されると、 文書検索部 1 5は検索プロセス P 1 0のステップ S 1 1により クエリを解釈した後、 キー列に含まれる単語 ·タグ名をそれぞれビット列記憶部 1 7に問い合わせ、 それぞれのビット列を取り出す。 そして文書検索部 1 5は、 得られた複数のビット列に対し A N D演算を行うことで、 キー列内のすべてのキ 一が含まれる集合を表現したビット列 B Lを作成する。 次に文書検索部 1 5は、 S 1 2の処理を行い問い合わせタスクの集合を作成した後、 S 1 3において各問 い合わせタスクの文書リスト ·タグ文書リス トに対する問い合わせを行い、 文書 リスト Zタグ文書リストを読み込む際 （S 1 3 1、 S 1 3 2、 S 1 3 3 3 ) に、 ビット列 B Lを参照し、 文書リスト タグ文書リスト内の個々の文書番号番目の ビットが 1である場合 （対応する文書にキーがすべて含まれている場合） のみに 登場位置ノ開始位置と終了位置を読み込む。 さらに、 S 1 4においては、 S 1 4 3の処理を行わず、 S 1 4 3の条件分岐では必ず S 1 4 4へ進むものとする。 以 降の処理は第一および第二の実施形態における検索プロセスと同じである。
タグの更新プロセスは次のように行われる。 タグ更新部 1 2はステップ S 2 1 から S 2 3の処理を終えた後、 新たにビット列記憶部 1 7の更新処理としてステ ップ S 2 4を行う。 ステップ S 2 4とは、 タグ名と文書番号と命令種をビット列 記憶部 1 7に入力し、 ビット列の更新を行う処理である。 ステップ S 2 4におい てビット列記憶部 1 7はまず、 命令種を調べ、 命令種が追加である場合、 タグ名 をキーとして対応するビット列を読み出し、 文書番号番目のビットを 「1」 に更 新する。 命令種が削除である場合、 何もしない。
文書の更新プロセスは次のように行われる。 第一および第二の実施形態と同様 の文書の更新プロセスを終えた後、ステップ S 3 1を行う。ステップ S 3 1とは、 文書インデックス作成部 1 1が、 ビット列記憶部 1 7に単語と文書番号を入力す る処理である。 この処理においてビット列記憶部 1 7は、 単語をキーとして対応 するビット列を読み出し、 文書番号番目のビットを 「1」 に更新する。
なお、 ステップ S 3 1の処理は、 特定の単語のみに対して行うもの、 としても 良レ、。 例えば、 予め高い頻度を持つ単語の辞書 H Dを用意しておき、 ステップ S 3 1の処理を行う前に単語と H Dを比較し、 単語が H D内に含まれる場合のみ S 3 1を行うことが考えられる。
次に、 具体的な例を用いて本実施形態の動作を説明する。 例えば、 「[企業名] の [人名]」 というクエリが入力されたとすると、 クエリ解釈手段 1 1は、 S 1 1 の処理を行い、 [企業名]、 「の」、 [人名] というキーから成るキー列を作成する。 次に問い合わせ実行手段 1 5 2は、ビット列記憶部 1 7内に記憶されたデータ（図 2 9 ) を参照し、 それぞれのキーに対応するビット列を読み出し、 A N D演算を 行う。 この結果 「1 1 0 0 1 0 1 0 0 0 1 0 0」 というビット列を得る。 これに より、 [企業名]、 「の」、 [人名] という 3つのキーが登場する文書の集合を文書番 号 1番、 文書番号 2番、 文書番号 5番 · · ·に絞り込むことができる。 次に問い合わ せ実行手段 1 5 2は、 ステップ S 1 3において文書リスト ·タグ文書リストを読 み込む際に、 この文書集合に当てはまる部分だけを読み込む。 以降の処理は、 第 一および第二の実施形態における文書の更新プロセスと同様である。
この実施形態では、 問い合わせ実行手段において、 検索時に予めクエリに含ま れる単語 タグ名を元にビット列記憶部を参照してビット列を読み込み、 それを A N D演算によって調べることで、 クエリ内のすべての単語/タグ名が含まれる 文書を高速に発見できるため、 文書リス トの読み込み量を削減でき、 検索をさら に高速に行うことができる。
(第四の実施形態）
図 3 0は本発明の第四の望ましい実施形態を示すブロック構成図である。 この 文書管理 ·検索システムは、 タグを管理するタグ管理部 1 9を備え、 このタグ管 理部 1 9内に、 タグ L Rインデックス記憶部 1 4と、 タグの集合に対して文書集 合内のタグの登場位置と左右の単語を記憶するタグ N L Rィンデックス記憶部 1 8と、 タグ N L Rィンデックス記憶部 1 8内のィンデックスをタグ L Rィンデッ クス記憶部 1 4内のインデックスに変換する変換手段 2 0と、 タグの統計情報に 基づきインデックスの持ち方を変更する管理手段 2 1と、 を備える。
タグ管理部 1 9は、 問い合わせ実行手段 1 5 2から問い合わせを受けると、 内 部の管理手段 2 1にその入力のデータを渡し、 管理手段 2 1が出力するデータを 問い合わせ実行手段 1 5 2に返却する。 また、 タグ管理部 1 9は、 タグ更新部 1 2から更新の命令文を受けると、 内部の管理手段 2 1にその命令文に入力する。 タグ N L Rインデックス記憶部 1 8は、 内部に、 タグの集合に対して各タグ名 をキーとするタグ L R文書リストを持つ。 タグ L R文書リストとは、 タグ文書リ ストが持つデータに加えて、 左の単語と、 右の単語とを加えたデータである。 図 3 1はタグ L R文書リストの一例を示す。 この例では、 [人名] というタグが 文書集合内で 1 0 0 0 0 1回登場し、 文書番号 3 3 3の文書において 7文字目か ら 1 0文字目にあり、 その左には 「の」 という単語が、 その右には 「社長」 とい う単語があることを示している。
タグ L Rィンデックス記憶部 1 4は、 第一の実施形態で示した図 1 2のタグ L Rインデックスと同じ情報を持つ。
変換手段 2 0は、管理手段 2 1に呼び出され、タグ L R文書リストを入力とし、 Lインデックスと Rインデックスを出力する。
管理手段 2 1は、 内部に管理テーブルを持つ。 管理テーブルとは、 タグ名、 タ グの文書内の頻度、 インデックス種の関係を記憶するテーブルである。 なお、 こ のうちインデックス種とは、 該当のタグのィンデックスがどこに作成されている かを表し、 その値はタグ N L Rインデックス記憶部 1 8である （N L R) か、 タ グ L Rインデックス記憶部 1 4である （L R) かのどちらかである。
図 3 2に管理テーブルの一例を示す。 この例は、 [人名] タグが文書集合に 1 0 0 0 0 1回登場しており、 インデックスが現在タグ N L Rインデックス記憶部 1 8内に記憶されていることを意味する。
管理手段 2 1は、 命令種、 タグ名、 文書番号、 開始位置、 終了位置、 左の単語、 右の単語を含むデータ （命令文） を入力されると、 タグ名を元に管理テーブルを 参照し、 タグ名に対応するインデックス種を取り出し、 該当のインデックスに入 力された命令文をそのままを入力する。 管理手段 2 1は、 参照キーと参照先とを 入力とする問い合わせを受け、参照キー内のタグ名を元に管理テーブルを参照し、 タグ名に対応するインデックス種を取り出し、 該当のインデックスに問い合わせ を行う。 管理手段 2 1はまた、 任意のタイミングで管理テーブル内のタグの頻度 とインデックス種を調べる。 そして、 タグの頻度が閾値 αよりも大きく、 かつ、 インデックス種が 「N L R」 であるタグ名がある場合、 タグ N L Rインデックス 記憶部 1 8内からそのタグ名に対応するタグ L R文書リストを読み込み、 変換手 段 2 0を利用してタグ Lインデックスとタグ Rインデックスを作成し、 タグ L R ィンデッタス記憶部 1 4内に追加する。 なお、 閾値 αとは任意の固定的な数であ る。
次にこの実施形態における処理の流れを説明する。 この実施形態は主に、 検索 プロセスと、 タグの更新プロセスと、 文書のインデックスプロセスの 3つのプロ セスを持つが、 これらのプロセスは、 第一ないし第三の実施形態におけるタグ L Rインデックス記憶部 1 4の動作をタグ管理部 1 9に置き換えたものと等しい。 そこでここでは、 タグ管理部 1 9内の処理のみを説明することとし、 タグ管理部 1 9に対するタグの更新プロセスと、 タグ管理部 1 9に対する問い合わせプロセ スと、 インデックスの最適化プロセスとを説明する。
まず、 タグ管理部 1 9に対するタグの更新プロセスについて説明する。 タグの 更新プロセスは、 タグ更新部 1 2が、 タグの追加 ·削除に関する命令文を管理部 1 9に入力することで開始される。 このとき、 システムはまず、 タグ名を元に管 理テーブルを参照し、 タグ名に対応する頻度を更新する。 頻度の更新は次のよう に行われる。 命令文の命令種が追加である場合には頻度に 1を足し、 命令種が削 除である場合には頻度から 1を引く。
次にシステムは、 タグ名を元に管理テーブルを参照し、 該当するインデックス 種を取り出す。 インデックス種が L Rである場合、 命令文をタグ L Rインデック ス記憶部 1 4に与え、 ステップ S 2 1と S 2 2の処理を行う。 インデックス種が N L Rである場合、 システムは次のように処理を行う。 システムは、 入力された タグ名をキーとしてタグ L R文書リストを読み込んだ上で、 命令種が追加である 場合には、 タグ L R文書リストに文書番号、 開始位置、 終了位置、 左の単語、 右 の単語を追加する。 命令種が削除である場合には、 タグ L R文書リストから文書 番号、 開始位置、 終了位置が一致する部分を探し出しその部分を削除する。 次に、 タグ管理部 1 9に対する問い合わせプロセスについて説明する。 このプ ロセスは、 問い合わせ実行手段 1 5 2がタグ管理部 1 9に参照キーと参照先とを 入力とする問い合わせを行うことで開始される。
このとき、 システムはまず、 タグ名を元に管理テーブルを参照し、 該当するィ ンデックス種を取り出す。 インデックス種が L Rである場合、 タグ L Rインデッ タス記憶部 1 4に対し問い合わせが行われる。 この問い合わせ処理は、 第一の実 施形態におけるタグ L Rィンデックス記憶部 1 4に対する問い合わせと同様であ る。
図 3 はィンデッタス種が N L Rである場合の処理のフローチャートを示す。 インデックス種が N L Rである場合、 システムは、 問い合わせ内の参照キーに含 まれるタグ名を元に、 対応するタグ L R文書リス トを読み込み、 変換手段 2 0を 利用してタグ Lインデックスとタグ Rインデックスを作成する。
すなわち、 システムはまず、 コンピュータのメモリ上など高速に追加 '参照で きる位置に、空のタグ Lインデックスと空の Rインデックスを作成する（S 5 1 )。 次にシステムは、 タグ L Rインデックスを前方から順に調べ、 文書番号、 開始 位置、 終了位置、 左の語、 右の語とから成る 5つのデータを読み込むたびに、 次 の処理を行う。 システムは、 タグ Lインデックス内に 「タグ名→左の語」 という キーを持つタグ文書リストが存在するかどうか調べ、 もし存在すれば、 タグ文書 リストの末尾に文書番号と開始位置と終了位置を追加する。 もし存在しなければ 文書番号と開始位置と終了位置とを元に新たにタグ文書リストを作成し 「タグ名 →左の語」 というキーで登録する。 さらに、 タグ Rインデックスに対しても同様 の処理を行い、 タグ Rインデックスに 「タグ名→右の語」 というキーで文書番号 と開始位置と終了位置とを追加する （S 5 2 )。
この上で、 参照キーが 「タグ名」 である場合は右の単語リス ト/左の単語リス トを返却し、 参照キーが 「タグ名→単語」 である場合は該当するタグ Lインデッ クス タグ Rィンデッタス内の該当の位置を参照し、 タグ文書リストを返却する ( S 5 3 )。
図 3 4はィンデッタスの最適化プロセスのフローチヤ一トを示す。 ィンデック スの最適化プロセスは、 管理テーブル内の 1行のデータ （タグ名、 頻度、 インデ ックス種） を入力とし、 任意のタイミングで実行される。 例えば、 この実行のタ イミングとして、 タグ管理部 1 9に対するタグの更新プロセスが終わった際にタ グの更新プロセス内で更新された管理テ一ブル内の行に対して実行することや、 毎日午前 3時に全行に対してそれぞれ実行すること、 などが考えられる。 ィンデックスの最適化プ口セスが開始されると、 システムは頻度とィンデック ス種を調べる。 閾値 α以上でありかつインデックス種が 「NLR」 である場合、 管理手段 21はタグ N L Rインデックス記憶部 18を調べ、 このタグ名に対応す るタグ LR文書リストを読み込む （S 6 1)。 次に管理手段 21は、 変換手段 20 を利用してこのタグ L R文書リストからタグ Lインデックスとタグ Rインデック スを作成する （S 62)。 さらに管理手段 21は、 作成したタグ Lインデックスと タグ Rインデックスをタグ LRインデックス記憶部 14内に追加する （S 63)。 次に、 管理手段 21は同タグ名を用いて管理テーブル内を参照し、 インデックス 種を 「LR」 に更新する （S 64)。 最後に管理手段 21は、 このタグ名に対応す るタグ N L Rィンデックス記憶部 18内からこのタグ L R文書リストとキーを削 除する （S 65)。
なお、 上記のアルゴリズムでは、 タグの頻度を元にインデックスの記憶先を変 更しているが、 この判定基準は他にも、 左の語の種類数、 右の語の種類数、 タグ に対する問い合わせ回数、 あるいはそれらを組み合わせて算出される数などが考 えられる。
次に、 具体的な例を用いてこの実施形態の動作を説明する。 なお、 ここでは、 ィンデッタスの最適化プロセスについて説明する。
例えば、 図 32で示した管理テーブル内の人名タグの行に注目し、 閾値 aが 1 00000である状況を想定する。 このとき、 インデックスの最適化プロセスは 次のように動作する。 管理手段 21はまず頻度とインデックス種を調べる。 この とき、タグの頻度が閾値以上でありインデックス種が「NLR」であることから、 管理手段 21はタグ NLRインデックス記憶部 18に対して問い合わせを行い、 図 31の人名をキーとしたタグ LR文書リストを取得する （S 6 1)。 さらに管理 手段 2 1は、 変換手段 20を利用してこのタグ LR文書リストからタグ Lインデ ックスとタグ Rインデックスを作成し、 図 1 2で示したインデックスを得 （S 6 2)、 これをタグ LRインデックス記憶部 14に記憶する （S 63)。 さらに管理 手段 21は、図 32で示した管理テーブル内の人名に対するインデックス種を「L R」 に変更し （S 64)、 タグ NLRインデックス記憶部 18内からこのタグ LR 文書リス トと 「人名」 というキーを削除する （S 65)。 このように、 本実施形態では、 タグの統計情報を元に、 タグ N L Rインデック スと、 タグ L Rインデックスを切り替えて用いる。 タグ L Rインデックスは左右 の単語を元にそれぞれ文書リストを持っために高速な反面、 双方向にインデック スを作成するため冗長であり記憶するデータ量が大きくなるという特徴がある。 そこで、 元々頻度が短く、 検索時に文書リス トの読み込み量が少ない低頻度なタ グに関してはタグ N L Rインデックスを利用してィンデックスを小さくしておく ことで、データ量と検索の高速化のバランスを取ることができる。すなわち、元々 文書リストが短レ、低頻度なタグに対して L Rインデックスを作成することを避け ることができ、 インデックスとして保持するデータの量を削減しつつ、 検索の高 速性を維持することができる。
(第五の実施形態）
本発明はコンピュータ ·プログラムとして実施することができ、 また、 記憶媒 体あるいはネットワークを経由して頒布することができる。
このようなコンピュータ.プロクラムは、一つ以上の文書が与えられた場合に、 その文書に含まれる単語の集合に対し、 各単語をキーとして、 その登場位置を記 憶する文書ィンデックス作成処理と、 特定の文書中の部分文字列に対しタグを追 加 ·削除するクエリが与えられた場合に、 そのタグ名をキーとしタグの登場位置 を記憶するタグ更新処理と、 このタグ更新処理内において、 入力されたタグに対 し、 タグの右と左に登場した単語を記憶し、 さらに各タグとその右に登場する語 の組み合わせ、 あるいは、 各タグとその左に登場する語の組み合わせをキーとし て文書集合内の各タグの登場位置を記憶するタグ L R記憶処理と、 タグと単語か ら成るフレーズが検索クエリとして与えられた場合に、 その検索クエリを解釈し た上でフレーズ内の隣接する単語とタグの左右の関係を利用して複数のキーを作 成し、 これらのキーを元に文書インデックス作成処理において記憶されたキーを 元に単語の登場位置、 タグ更新処理において記憶されたキーを元に各タグの登場 位置をそれぞれ参照し、 その上でそれらを統合することでそのフレーズを含む文 書の識別子の一覧を返却する文書検索処理とをコンピュータに実行させるための コードで構成される。
任意の文字列をキーとし、 その文字列に付加されている可能性のあるタグ名の 集合を高速に参照可能とする高速タグ値判定処理と、 タグ更新処理においてタグ を付加する際にタグ名と文字列の関係を表すデータを更新する処理と、 文書検索 処理においてタグ名が連続するフレーズを検索クエリが入力された場合に、 高速 タグ値判定処理を利用し、 特定のタグ名を含む可能性のある単語のみに絞ってタ グの登場位置を読み込む処理とをさらにコンピュータに実行させるコードを含む ことが望ましい。
文書インデックス処理において高頻度語およびタグ名をキーとし、 その単語お よびタグを含む文書の集合を表すビット列を記憶するビット列記憶処理と、 タグ 更新処理において、 タグを更新する際に追加 ·削除されたタグを元にビット列記 憶処理で記憶されたビット列を更新する処理と、 文書検索処理において、 検索ク ェリに含まれる高頻度語およびタグ名をキーとしてビット列記憶処理で記憶され たビット列を参照し、 クエリ内の高頻度語およびタグ名がすべて含まれる文書の 集合を表すデータを得、 そのデータを元に文書集合を絞り込んだ上で単語とタグ の登場位置を読み込む処理とをさらにコンピュータに実行させるコードを含むこ とができる。
タグ更新処理内において、 タグの集合に対して、 各タグ名をキーとし、 文書集 合内のタグの登場位置と左右の単語を記憶するタグ N L Rインデックス処理をコ ンピュータに実行させ、タグ更新ステップ内および文書検索ステツプ内において、 タグをキーとしその登場位置を更新あるいは検索する際に、 そのタグがタグ N L Rインデックス処理で記憶されているか、 タグ L R更新処理で記憶されているか によって、 参照先を選択する処理と、 タグに関する頻度を元に、 タグ N L Rイン デックス処理で作成されたデ一タを削除し、 タグ L Rィンデックス処理で作成す るィンデックス変換処理とをコンピュータに実行させるコードを含むこともでき る。
本発明はタグを用いて文書を管理 ·検索するシステムの一部分として有効であ る。 本発明では、 タグを含むフレーズを元に、 そのフレーズを含む文書集合を表 す文書番号のリス トを高速に決定する部分に焦点を絞っている。 よって、 本発明 の構成に加え、 文書番号から、 その文書自体を参照する文書データベースを用意 することにより、 タグを含むフレーズにより、 文書集合を読み出せる検索ェンジ ンとして利用可能である。
本発明は、 タグの更新を想定した上でタグを含むフレーズ検索を実現する技術 である。 このような技術が求められるアプリケーションとしては、 大規模な文書 集合を分析するテキストマイニングの分野が挙げられる。 テキストマイニングで は、 文書にタグを付加し、 そのタグを利用して分析が行われる。 通常、 文書集合 に対してどのようなタグ付けが好ましいかどうかは事前にわからないことが多レ、。 そこで、 大量の文書集合を予めインデックス化しておき、 種々のタグ付け手段を 用いてタグ付けを行っていき、 タグやそのタグを含むフレーズで検索し、 その頻 度や文書集合を取り出すことで、 効率良く文書集合から知識を取り出すことがで きる。 本発明はこのような場合に有益である。
この出願は、 2 0 0 7年 1 1月 1 5日に出願された日本出願特願第 2 0 0 7— 2 9 6 3 8 6号を基礎とする優先権を主張し、 その開示のすべてをここに取り込 むものである。

Claims

請 求 の 範 囲
1 . 単語の集合に対して、 文書集合内での各単語の出現位置を記憶する単語ィ ンデックス記憶部と、
単語に付加されてその単語の属性を表すタグの集合に対して、 各タグの右と左 に登場した単語の集合を記憶し、 さらに各タグとその右に登場する語の組み合わ せ、 あるいは、 各タグとその左に登場する語の組み合わせをキーとして文書集合 内の各タグの登場位置を記憶するタグ L Rインデックス記憶部と、
検索クエリとしてタグと単語から成るフレーズを入力とし、 その検索クエリを 解釈した上でフレーズ内の隣接する単語とタグの左右の関係を利用して上記タグ L Rインデックス記憶部を参照し、 そのフレーズを含む文書の識別子の一覧を返 却する文書検索部と、
特定の文書中の部分文字列に対してタグを追加 ·削除するクエリを解釈し、 上 記タグ L Rィンデックス記憶部の記憶内容を更新するタグ更新部と、
一つ以上の文書が与えられた場合に、 上記単語ィンデックス記憶部内のィンデ ックスを更新する文書ィンデックス作成部と
を備えたことを特徴とする文書管理 ·検索システム。
2 . 任意の文字列をキーとし、 その文字列に付加されている可能性のあるタグ 名の集合を高速 参照可能とする高速タグ値判定部を備え、
前記タグ更新部は、 タグを付加する際に上記高速タグ値判定部内のデータを更 新する手段を含み、
前記文書検索部は、 タグが連続するフレーズが検索クエリとして入力された場 合に、 上記高速タグ値判定部と前記タグ L Rィンデックス記憶部とを参照して、 特定のタグ名を含む可能性のある単語に絞って問い合わせを実行する手段を含む ことを特徴とする請求項 1記載の文書管理 ·検索システム。
3 . 高頻度語とタグ名とをキーとし、 その単語およびタグをそれぞれ含む文書 の集合を表すビット列を記憶するビット列記憶部を備え、
前記文書ィンデックス作成部は、 文書からィンデックスを作成する際に上記ビ ット列記憶部内のビット列を更新する手段を含み、
前記タグ更新部は、 タグを更新する際に追加 ·削除されたタグを元に上記ビッ ト列記憶部内のビット列を更新する手段を含み、
前記文書検索部は、 検索時に予めクエリに含まれる高頻度語およびタグ名を元 に上記ビット列記憶部を参照し、 クエリ内の高頻度語およびタグ名がすべて含ま れる文書番号の集合を得て、 その文書番号を元に文書集合を絞り込んだ上で文書 集合内にフレーズの登場位置を読み込む手段を含む
ことを特徴とする請求項 1または 2記載の文書管理 ·検索システム。
4 . タグの集合に対して、 各タグ名をキーとし、 文書集合内のタグの登場位置 と左右の単語を記憶するタグ N L Rィンデックス記憶部と、
このタグ N L Rインデックス記憶部内のィンデックスを前記タグ L Rィンデッ クス記憶部内のィンデックスに変換する変換手段と、
タグの登場頻度に基づきィンデッタスの記憶方法を変更する管理手段と を備えたことを特徴とする請求項 1ないし 3のいずれか記載の文書管理 ·検索 システム。
5 . 一つ以上の文書が与えられた場合に、 その文書に含まれる単語の集合に対 し、 各単語をキーとして、 その登場位置を記憶する文書インデックス作成ステツ プと、
特定の文書中の部分文字列に対しタグを追加 ·削除するクエリが与えられた場 合に、 そのタグ名をキーとしタグの登場位置を記憶するタグ更新ステップと、 このタグ更新ステップ内において、 入力されたタグに対し、 タグの右と左に登 場した単語を記憶し、 さらに各タグとその右に登場する語の組み合わせ、 あるい は、 各タグとその左に登場する語の組み合わせをキーとして文書集合内の各タグ の登場位置を記憶するタグ L R記憶ステップと、
タグと単語から成るフレーズが検索クエリとして与えられた場合に、 その検索 クエリを解釈した上でフレーズ内の隣接する単語とタグの左右の関係を利用して 複数のキーを作成し、 これらのキーを元に上記文書ィンデックス作成ステツプに おいて記憶されたキーを元に単語の登場位置、 上記タグ更新ステップにおいて記 憶されたキーを元に各タグの登場位置をそれぞれ参照し、 その上でそれらを統合 することでそのフレーズを含む文書の識別子の一覧を返却する文書検索ステップ と
を含むことを特徴とする文書の管理 ·検索方法。
6 . 任意の文字列をキーとし、 その文字列に付加されている可能性のあるタグ 名の集合を高速に参照可能とする高速タグ値判定ステップを含み、
前記タグ更新ステップは、 タグを付加する際にタグ名と文字列の関係を表すデ ータを更新するステップを含み、
前記文書検索ステップは、 タグ名が連続するフレーズを検索クエリが入力され た場合に、 高速タグ値判定ステップを利用し、 特定のタグ名を含む可能性のある 単語のみに絞ってタグの登場位置を読み込むステップを含む
ことを特徴とする請求項 5記載の文書の管理 ·検索方法。
7 . 文書インデックスステップにおいて高頻度語とタグ名とをキーとし、 その 単語およびタグをそれぞれ含む文書の集合を表すビット列を記憶するビット列記 憶ステップを含み、
前記タグ更新ステップは、 タグを更新する際に追加 ·削除されたタグを元にビ ット列記憶部内のビット列を更新するステップを含み、
文書検索ステップは、 検索クエリに含まれる高頻度語とタグ名とをキーとして ビット列記憶ステップで記憶されたビット列を参照し、 クエリ内の高頻度語およ びタグ名がすべて含まれる文書の集合を表すデータを得、 そのデータを元に文書 集合を絞り込んだ上で単語とタグの登場位置を読み込むステップを含む
ことを特徴とする請求項 5または 6記載の文書の管理 ·検索方法。
8 . 前記タグ更新ステップは、 タグの集合に対して、 各タグ名をキーとし、 文 書集合内のタグの登場位置と左右の単語を記憶するタグ N L Rインデックスステ ップを含み、 前記タグ更新ステップぉよび前記文書検索ステップは、
タグをキーとしその登場位置を更新あるいは検索する際に、 そのタグが前記タ グ N L Rインデックスステツプで記憶されているか前記タグ L R更新ステップで 記憶されているかによって、 参照先を選択するステツプと、
タグに関する頻度を元に、 タグ N L Rィンデックスステップで作成されたデー タを削除し、 タグ L Rインデックスステツプで作成するインデックス変換ステツ プと
を含む
ことを特徴とする請求項 5ないし 7のいずれか記載の文書の管理 ·検索方法。
9 . 一つ以上の文書が与えられた場合に、 その文書に含まれる単語の集合に対 し、各単語をキーとして、その登場位置を記憶する文書ィンデックス作成処理と、 特定の文書中の部分文字列に対しタグを追加 ·削除するクエリが与えられた場 合に、 そのタグ名をキーとしタグの登場位置を記憶するタグ更新処理と、 このタグ更新処理内において、 入力されたタグに対し、 タグの右と左に登場し た単語を記憶し、 さらに各タグとその右に登場する語の組み合わせ、 あるいは、 各タグとその左に登場する語の組み合わせをキーとして文書集合内の各タグの登 場位置を記憶するタグ L R記憶処理と、
タグと単語から成るフレーズが検索クエリとして与えられた場合に、 その検索 クエリを解釈した上でフレーズ内の隣接する単語とタグの左右の関係を利用して 複数のキーを作成し、 これらのキーを元に上記文書ィンデックス作成処理におい て記憶されたキーを元に単語の登場位置、 上記タグ更新処理において記憶された キーを元に各タグの登場位置をそれぞれ参照し、 その上でそれらを統合すること でそのフレーズを含む文書の識別子の一覧を返却する文書検索処理と
をコンピュータに実行させるためのコンピュータ ·プログラム。
1 0 . 任意の文字列をキーとし、 その文字列に付加されている可能性のあるタ グ名の集合を高速に参照可能とする高速タグ値判定処理と、
タグ更新処理においてタグを付加する際にタグ名と文字列の関係を表すデータ を更新する処理と、
文書検索処理においてタグ名が連続するフレーズを検索クエリが入力された場 合に、 高速タグ値判定処理を利用し、 特定のタグ名を含む可能性のある単語のみ に絞ってタグの登場位置を読み込む処理と
をさらにコンピュータに実行させることを特徴とする請求項 9記載のコンビュ ータ ·プログラム。
1 1 . 文書インデックス処理において高頻度語およびタグ名をキーとし、 その 単語およびタグを含む文書の集合を表すビット列を記憶するビット列記憶処理と、 前記タグ更新処理において、 タグを更新する際に追加 ·削除されたタグを元に 上記ビット列記憶処理で記憶されたビット列を更新する処理と、
前記文書検索処理において、 検索クエリに含まれる高頻度語およびタグ名をキ 一として上記ビット列記憶処理で記憶されたビット列を参照し、 クエリ内の高頻 度語およびタグ名がすべて含まれる文書の集合を表すデータを得、 そのデータを 元に文書集合を絞り込んだ上で単語とタグの登場位置を読み込む処理と
をさらにコンピュータに実行させることを特徴とする請求項 9または 1 0記載 のコンピュータ .プログラム。
1 2 . 前記タグ更新処理内において、 タグの集合に対して、 各タグ名をキーと し、 文書集合内のタグの登場位置と左右の単語を記憶するタグ N L Rインデック ス処理をコンピュータに実行させ、
前記タグ更新ステップ内および前記文書検索ステップ内において、 タグをキー としその登場位置を更新あるいは検索する際に、 そのタグが上記タグ N L Rイン デックス処理で記憶されているか、 前記タグ L R更新処理で記憶されているかに よって、 参照先を選択する処理と、 タグに関する頻度を元に、 タグ N L Rインデ ックス処理で作成されたデータを削除し、 タグ L Rインデックス処理で作成する インデックス変換処理とをコンピュータに実行させる
ことを特徴とする請求項 9ないし 1 1のいずれか記載のコンピュータ 'プログ ラム。
PCT/JP2008/070630 2007-11-15 2008-11-06 文書管理・検索システムおよび文書の管理・検索方法 WO2009063925A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/741,302 US9454597B2 (en) 2007-11-15 2008-11-06 Document management and retrieval system and document management and retrieval method
JP2009541163A JP5376163B2 (ja) 2007-11-15 2008-11-06 文書管理・検索システムおよび文書の管理・検索方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2007296386 2007-11-15
JP2007-296386 2007-11-15

Publications (1)

Publication Number Publication Date
WO2009063925A1 true WO2009063925A1 (ja) 2009-05-22

Family

ID=40638773

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/070630 WO2009063925A1 (ja) 2007-11-15 2008-11-06 文書管理・検索システムおよび文書の管理・検索方法

Country Status (3)

Country Link
US (1) US9454597B2 (ja)
JP (1) JP5376163B2 (ja)
WO (1) WO2009063925A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012108782A (ja) * 2010-11-18 2012-06-07 Yahoo Japan Corp テキストデータ読出装置、方法及びプログラム
US9767191B2 (en) 2013-07-23 2017-09-19 International Business Machines Corporation Group based document retrieval
JP2018060424A (ja) * 2016-10-06 2018-04-12 富士通株式会社 インデックス生成プログラム、インデックス生成装置、インデックス生成方法、検索プログラム、検索装置および検索方法
WO2018096686A1 (ja) * 2016-11-28 2018-05-31 富士通株式会社 検証プログラム、検証装置、検証方法、インデックス生成プログラム、インデックス生成装置およびインデックス生成方法
JP2019185145A (ja) * 2018-04-02 2019-10-24 富士通株式会社 データ生成プログラム、データ生成方法および情報処理装置
CN111178965A (zh) * 2019-12-27 2020-05-19 聚好看科技股份有限公司 一种资源投放方法及服务器
US11386267B2 (en) 2017-05-16 2022-07-12 Fujitsu Limited Analysis method, analyzer, and computer-readable recording medium

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8266140B2 (en) * 2009-03-13 2012-09-11 International Business Machines Corporation Tagging system using internet search engine
JP2011123598A (ja) * 2009-12-09 2011-06-23 Canon Inc 原稿判別装置、原稿判別方法及びプログラム
US8745370B2 (en) * 2010-06-28 2014-06-03 Sap Ag Secure sharing of data along supply chains
US8539597B2 (en) * 2010-09-16 2013-09-17 International Business Machines Corporation Securing sensitive data for cloud computing
US9600565B2 (en) * 2010-10-15 2017-03-21 Nec Corporation Data structure, index creation device, data search device, index creation method, data search method, and computer-readable recording medium
US8983963B2 (en) * 2011-07-07 2015-03-17 Software Ag Techniques for comparing and clustering documents
WO2013038527A1 (ja) * 2011-09-14 2013-03-21 富士通株式会社 抽出方法、抽出プログラム、抽出装置、および抽出システム
US9495352B1 (en) 2011-09-24 2016-11-15 Athena Ann Smyros Natural language determiner to identify functions of a device equal to a user manual
US20130086059A1 (en) * 2011-10-03 2013-04-04 Nuance Communications, Inc. Method for Discovering Key Entities and Concepts in Data
US8589404B1 (en) * 2012-06-19 2013-11-19 Northrop Grumman Systems Corporation Semantic data integration
US9740765B2 (en) * 2012-10-08 2017-08-22 International Business Machines Corporation Building nomenclature in a set of documents while building associative document trees
US9116938B2 (en) * 2013-03-15 2015-08-25 Qualcomm Incorporated Updating index information when adding or removing documents
US11126592B2 (en) * 2014-09-02 2021-09-21 Microsoft Technology Licensing, Llc Rapid indexing of document tags
US10055301B2 (en) * 2015-06-15 2018-08-21 Open Text Sa Ulc Systems and methods for content server make disk image operation
US10606815B2 (en) * 2016-03-29 2020-03-31 International Business Machines Corporation Creation of indexes for information retrieval
CA3055172C (en) * 2017-03-03 2022-03-01 Perkinelmer Informatics, Inc. Systems and methods for searching and indexing documents comprising chemical information
US10417269B2 (en) * 2017-03-13 2019-09-17 Lexisnexis, A Division Of Reed Elsevier Inc. Systems and methods for verbatim-text mining
JP6841322B2 (ja) 2017-04-06 2021-03-10 富士通株式会社 インデックス生成プログラム、インデックス生成装置、インデックス生成方法、検索プログラム、検索装置および検索方法
WO2020257973A1 (en) * 2019-06-24 2020-12-30 Citrix Systems, Inc. Detecting hard-coded strings in source code
CN112230781B (zh) * 2019-07-15 2023-07-25 腾讯科技（深圳）有限公司 字符推荐方法、装置及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06215029A (ja) * 1992-12-10 1994-08-05 Xerox Corp テキスト検索方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6215898B1 (en) * 1997-04-15 2001-04-10 Interval Research Corporation Data processing system and method
CN1328321A (zh) * 2000-05-31 2001-12-26 松下电器产业株式会社 通过语音提供信息的装置和方法
JP3709890B2 (ja) 2000-10-25 2005-10-26 松下電器産業株式会社 文字列検索装置
JP3882729B2 (ja) * 2002-09-27 2007-02-21 富士通株式会社 情報開示プログラム
US20080077570A1 (en) * 2004-10-25 2008-03-27 Infovell, Inc. Full Text Query and Search Systems and Method of Use

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06215029A (ja) * 1992-12-10 1994-08-05 Xerox Corp テキスト検索方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUGH E. WILLIAMS ET AL.: "Fast phrase querying with combined indexes", ACM TRANSACTIONS ON INFORMATION SYSTEMS, vol. 22, no. ISS..., 2004, pages 573 - 594 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012108782A (ja) * 2010-11-18 2012-06-07 Yahoo Japan Corp テキストデータ読出装置、方法及びプログラム
US9767191B2 (en) 2013-07-23 2017-09-19 International Business Machines Corporation Group based document retrieval
JP2018060424A (ja) * 2016-10-06 2018-04-12 富士通株式会社 インデックス生成プログラム、インデックス生成装置、インデックス生成方法、検索プログラム、検索装置および検索方法
WO2018096686A1 (ja) * 2016-11-28 2018-05-31 富士通株式会社 検証プログラム、検証装置、検証方法、インデックス生成プログラム、インデックス生成装置およびインデックス生成方法
JPWO2018096686A1 (ja) * 2016-11-28 2019-08-08 富士通株式会社 検証プログラム、検証装置、検証方法、インデックス生成プログラム、インデックス生成装置およびインデックス生成方法
US11386267B2 (en) 2017-05-16 2022-07-12 Fujitsu Limited Analysis method, analyzer, and computer-readable recording medium
JP2019185145A (ja) * 2018-04-02 2019-10-24 富士通株式会社 データ生成プログラム、データ生成方法および情報処理装置
JP7006462B2 (ja) 2018-04-02 2022-01-24 富士通株式会社 データ生成プログラム、データ生成方法および情報処理装置
CN111178965A (zh) * 2019-12-27 2020-05-19 聚好看科技股份有限公司 一种资源投放方法及服务器
CN111178965B (zh) * 2019-12-27 2023-07-25 聚好看科技股份有限公司 一种资源投放方法及服务器

Also Published As

Publication number Publication date
JPWO2009063925A1 (ja) 2011-03-31
JP5376163B2 (ja) 2013-12-25
US9454597B2 (en) 2016-09-27
US20100281030A1 (en) 2010-11-04

Similar Documents

Publication Publication Date Title
WO2009063925A1 (ja) 文書管理・検索システムおよび文書の管理・検索方法
US6853992B2 (en) Structured-document search apparatus and method, recording medium storing structured-document searching program, and method of creating indexes for searching structured documents
US8171052B2 (en) Information search system, method and program
JP4647336B2 (ja) グラフベースの順位付けを使用してテキスト内の単語および概念に順位付けする方法およびシステム
US7490078B2 (en) Stream data processing system and method for avoiding duplication of data process
KR101339103B1 (ko) 의미적 자질을 이용한 문서 분류 시스템 및 그 방법
US20050021545A1 (en) Very-large-scale automatic categorizer for Web content
WO2006036487A2 (en) System and method for management of data repositories
JP2008052662A (ja) 構造化文書管理システム及びプログラム
US11977581B2 (en) System and method for searching chains of regions and associated search operators
US20230109772A1 (en) System and method for value based region searching and associated search operators
JP4237813B2 (ja) 構造化文書管理システム
US20060248037A1 (en) Annotation of inverted list text indexes using search queries
JP4108337B2 (ja) 電子ファイリングシステム及びその検索インデックス作成方法
JP5169456B2 (ja) 文書検索システム、文書検索方法および文書検索プログラム
JP4378106B2 (ja) 文書検索装置、文書検索方法及びプログラム
KR100441346B1 (ko) 엑스엠엘 문서의 저장방법 및 엑스엠엘 문서 또는 인덱스노드 탐색방법
KR20020054254A (ko) 사전구조를 이용한 한국어 형태소 분석방법
JP3842574B2 (ja) 情報抽出方法および構造化文書管理装置およびプログラム
JP5971571B2 (ja) 構造文書管理システム、構造文書管理方法及びプログラム
JP2006163723A (ja) ドキュメント検索方法
US9922115B1 (en) Composite storage
JP6476638B2 (ja) 固有用語候補抽出装置、固有用語候補抽出方法、及び固有用語候補抽出プログラム
JPH11203312A (ja) キーワード検索装置、文書検索装置、キーワード検索プログラムを記録した記録媒体及び文書検索プログラムを記録した記録媒体
GB2590343A (en) Context search for unstructured content

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08850873

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12741302

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2009541163

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08850873

Country of ref document: EP

Kind code of ref document: A1