JP4357827B2 - Peer-to-peer document sharing network system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a document sharing system in a peer-to-peer network.
[0002]
[Prior art]
In LANs built at offices, it has been common to build client-server networks. In the case of a client / server system, a computer connected to a network is divided between a client and a server. In such a system, a computer connected to a network has a graphical user interface (GUI), a client that issues various requests and job requests in accordance with user operation inputs, and a server that quickly responds to request requests from clients. And divided. In many cases, a personal computer connected to a network serves as a client, and an expensive and high-performance dedicated server machine equipped with a mass storage device and a high-performance CPU serves as a server. On the other hand, recently, a peer-to-peer network (hereinafter referred to as P2P type) in which a computer connected to a network is not divided into a client and a server has been attracting attention due to an improvement in CPU performance of a personal computer connected to the network and an increase in disk capacity. Yes.
[0003]
In the P2P type, all computers function as clients and servers. It is suitable for sharing files and printers over a small LAN because it does not require a dedicated server and costs less. On the other hand, since a load is applied to the computer sharing the file, it is not suitable for constructing a large-scale network. However, technologies such as Napstar (Non-Patent Document 1) and Gnutella (Non-Patent Document 2) that directly exchange files between users also appear.
[0004]
Napstar and Gnutella have established a protocol for exchanging files on the Internet, and P2P network engine installed in the computer exchanges information according to this protocol, so that the user finds the partner who holds the desired file. , You can refer to or duplicate it.
[0005]
[Non-Patent Document 1]
Masao Kawauchi, Keiichi Koyanagi “New Century of P2P Internet”
Telecommunications Association; ISBN: 4885490197; May 2002
[Non-Patent Document 2]
Kyohei Yamamura, “Let's Go with Gnutella!-Monster Software“ Gnutella ”Revolutionizing the Internet World” Bestsellers; ISBN: 4584165262; January 2001
[0006]
[Problems to be solved by the invention]
In Napstar and Gnutella, all requests and searches for desired information are performed on file names. That is, only a file having a file name including a search character string is searched. Therefore, for example, there is a restriction that information retrieval cannot be performed in a full-text retrieval form.
[0007]
The present invention has been made in consideration of such problems, and provides an easy-to-use peer-to-peer file sharing system that can search information not only on file names but also on the contents of files. Is an issue.
[0008]
[Means for Solving the Problems]
  The first invention for solving the problem is:
  A document sharing network system in which a plurality of node computers cooperate in an equal relationship, and each node computer connected to this system isdocumentsAs a data set that is a combination of real file data and metadata that describes the real file data for each specified item.With storage device to hold,This type is provided corresponding to a type called a metadata type that classifies documents according to the items included in the metadata.A type plug-in that references metadata, a network engine that exchanges information with other node computers using a peer-to-peer network protocol, and a data set that uses the network engine and the type plug-inSearchA search engine to run,Accept search condition inputA graphical user interface for displaying search results by the search engine;In addition,
  As for the metadata type, a new item called a unique metadata type is added to an item defined in the basic parent type without the parent type itself or as a basic metadata type. One of the metadata types with a defined parent type,
The type plug-in refers to only the items included in the unique metadata type of each corresponding metadata type, and the other items are processed by calling the type plug-in of the parent metadata type. Refers to each item of metadata of the target dataset, and returns a test result to see if there is a part that matches the specified search condition,
With the above configuration,The peer-to-peer document sharing network system can extract a corresponding data set by comparing specified search conditions with metadata of each data set and present it as a search result.
[0009]
By managing the shared stored documents in the form of a data set and referring to the metadata at the time of search, it is possible to search for a shared document using a search term other than a file name in a peer-to-peer document sharing system.
[0010]
The data set, which is a unit for managing information in the system according to the first invention, is composed of real file data (real data) and metadata. The actual data is the content of the shared document itself. On the other hand, metadata is a collection of names (item names, tags, etc.) and values (item values) of some items defined for actual data. Therefore, the “document type” for classifying the shared document into the equivalence class is determined depending on whether the item names included in the metadata match. This is called a “metadata type”. A user can define a new document type as needed, and can refer to metadata by a type plug-in corresponding to the defined document type (metadata type). By adopting such a management system, shared documents can be managed flexibly and easily even if the environment changes and the properties of documents to be accumulated change.
[0011]
  A second invention for solving the problem is a document sharing network system in which a plurality of node computers cooperate in an equal relationship,
Each node computer connected to this system
  A storage device that holds a document as a data set that is a combination of real file data and metadata that describes the actual file data for each predetermined item, and an item included in the metadata, referred to as a metadata type. A type plug-in that corresponds to a type for classifying documents, and refers to the metadata of each document; a network engine for exchanging information with other node computers using a peer-to-peer network protocol; A search engine that performs a search for a dataset using a type plug-in, a graphical user interface that accepts search criteria input and displays search results from the search engine,
In addition,
  As for the metadata type, a new item called a unique metadata type is added to an item defined in the basic parent type without the parent type itself or as a basic metadata type. One of the metadata types with a defined parent type,
  The type plug-in is
Type definition information including at least item definition information that defines the type name, unique metadata type, and
Search result transmission means for returning the result processed by this type plug-in to the caller;
A unique metadata search means for referring to an item included in the unique metadata type, checking whether the value matches a search condition, and setting the result;
When the type has a parent type, the type definition information further includes identification information of the type plug-in of the parent type, and calls the type plug-in of the parent type to search conditions. And a search delegation means to the parent plug-in that passes to the type plug-in,
Refers to each item of metadata of the data set to be processed, and returns a check result whether there is a part that matches the specified search condition,
With the above configuration, the peer-to-peer document sharing network system can extract a corresponding data set by comparing the specified search condition with the metadata of each data set and present it as a search result.
[0012]
1st invention or 2nd inventionIn the peer-to-peer document sharing network system according to the above, when searching for a shared document that is stored and managed, the search engine matches the search type among the shared documents by specifying one metadata type as the search type. A data set corresponding to a metadata type whose basic type is a metadata type and a search type can be configured to be limited as a search target.
[0013]
By specifying a search type, a search type and a document of a type derived from the search type can be searched. Such a search method is reasonable from the viewpoint of document management. This is because the derived type document also contains all the basic type metadata.
[0015]
1st inventionOr the second inventionIn a system related to, it is necessary to provide all types of plug-ins, from basic types to their various development types. However, when a type plug-in is configured and realized in this way, when a new type is defined, its type Makes it easy to create new type plug-ins that support. This is because the new type plug-in knows what the type plug-in is its source and only needs to perform processing related to the newly added metadata.
[0016]
Also,The user interface provided when registering a shared document is preferably provided according to the metadata type of the newly registered document. This is because the user can register necessary information as metadata of the document without omission.
[0017]
Also,A user interface for specifying a search condition when starting a search is preferably provided according to the specified search type. This is because the user can specify as many search conditions as necessary for all items defined as metadata of the document.
[0018]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a conceptual diagram of a P2P document sharing system 1 (hereinafter, system 1) according to an embodiment of the present invention. In FIG. 1, reference numeral 10 denotes each computer connected to the network. Each computer constituting the system 1 is called a node computer or simply a node. Each node is interconnected with other nodes that know their existence. The left part of FIG. 1 shows the inside of one node computer 10. One node is provided with a search engine 11, several plug-ins 12, a network engine 13, and a file database 20 for storing and managing shared documents. The file database 20 holds the shared document in the format of the data set 21. One data set 21 includes an actual file 211 and metadata 210 describing what is described in the actual file or the properties of the actual file as a document for each predetermined item.
[0019]
First, a data set that is a unit for managing information in this system will be described. One data set includes actual file data and metadata. This situation is shown in FIG. “Metadata” is a term for “actual data”, and “data about actual data” is the original meaning. Often used as data indicating what real data means. In the system 1, the actual data is the content of the shared document itself. On the other hand, metadata is a collection of names (item names, tags) and values (item values) of some items defined for actual data. Therefore, by appropriately setting items to be included in the metadata, it is possible to know the gist of the content of the shared document and some attribute of the shared document by referring to the metadata without reading the actual data. Further, if the list of item names in the metadata of a plurality of shared documents match, it can be said that they are the same type (same type) of shared documents. That is, the metadata defines a “document type” that classifies the shared document into an equivalence class. This is called a “metadata type”.
[0020]
Furthermore, in the system 1, a new metadata type can be defined by adding several new item names to a single metadata type.
In this way, a metadata type sequence can be created. FIG. 4 shows an example of such a metadata type sequence. In FIG. 4, based on the metadata described as metadata type A, new items B1, B2,... Are added to form metadata type B, and new item C1 is added to add metadata. An example in which type C is defined is shown. In this series of metadata type A → metadata type B → metadata type C, the metadata type A (B) is a basic type of the metadata type B (C) and can be called a parent type. Alternatively, it can be said that the metadata type B (C) is further developed by inheriting the metadata type A (B) and adding new items B1, B2,... (C1). In addition, it can be said that the type A is an upper type of the types B and C, and the type C is a lower type of the types A and B. Also, the items B1, B2,... (C1) newly added when defining the metadata type B (C) will be referred to as “unique metadata type B (C)” for convenience. The unique metadata type B is included in the metadata type B and the metadata types lower than the metadata type B, but is not included in the metadata type higher than the metadata type B.
[0021]
Returning to the description of FIG. The search engine 11 is provided in each node 10. The search engine 11 activated in the node 10 exchanges information with the search engine 11 operating in the other nodes using the mutually defined P2P protocol, thereby realizing P2P search processing. The actual search process is performed by the type plug-in 12 that is called one after another as necessary. The search engine 11 uses a network engine 13 to exchange information using the P2P protocol. The search engine 11 uses a graphical user interface (GUI) prepared according to a metadata type (specifically, a specific metadata type) for inputting search conditions or registering a shared document. The GUI function accepts user search requests, displays search results, and accepts file import instructions.
[0022]
The type plug-in 12 refers to the metadata of the shared document to be processed, and executes the requested processing for the document. In particular, whether or not the document is hit with respect to the search condition is processed. The type plug-in 12 is prepared corresponding to the metadata type, that is, corresponding to the document type. Details will be described later.
[0023]
The network engine 13 is a program that enables communication between nodes using a peer-to-peer network protocol (application layer protocol). The network engine 13 may use a computer program shown in Non-Patent Document 2. FIG. 2 illustrates a flow until a certain computer searches for information and obtains desired information using this network protocol.
[0024]
FIG. 2 shows a case where the node A issues a search request. The node A transmits a search request message to the node B according to a predetermined search route. When the node B receives this message, it checks whether the corresponding data exists in itself ((1)). If it is not present, it sends a search request message to C, which is the next node. This time, the node C checks whether or not the corresponding data exists ((2)). When it is confirmed that the corresponding data is held, the node C returns a response to the node B. The node B returns a response indicating that there is data corresponding to the node C to the node A ((3)). Node A sends a message requesting data to node C. Node C sends the corresponding data to node A (4). In this way, the search message and the response to the search message are exchanged like a message game, and information is searched and procured in a completely equal network without server / client distinction. In an actual protocol, there is a concept of lifetime in order to prevent divergence of search requests. A search request is generated with a lifetime value (eg, “= 5 nodes”) that is a constant integer. The lifetime is consumed every time it passes through the node, and when it reaches 0, the search request is not transferred to the next node.
[0025]
Next, referring to FIGS. 6 and 7, how the file sharing function of the system 1 actually operates will be described by way of example. The diagram on the left side of FIG. 6 shows a series of document types assumed in the explanation example. The diagram on the right side of FIG. 6 shows a peer-to-peer message route assumed in the explanation example. The explanation example shows the operation of the system 1 until the person (murata) searches and obtains a shared document including “OxΔ” in the title of the document from his computer.
[0026]
First, the user (murata) selects a proposal type document search from the GUI menu on murata's computer ((1) -1 in FIG. 7), and sets a search item. Here, “OxΔ” is designated as the title. Therefore, a proposal type data set including “◯ × Δ” in the title is searched ((1) -2 in FIG. 7). The search query is transmitted to two nodes, suzuki and tanaka, according to a predetermined message route ((2) and (3) in FIG. 7).
[0027]
The node suzuki checks whether or not the corresponding data set exists in the database 20 owned by the node suzuki, and further transfers the search query to a lower node existing in the lower message path. ((2) -1 in FIG. 7).
[0028]
Similarly, the node tanaka checks whether or not the corresponding data set exists in the database 20 owned by the node tanaka ((3) -1 in FIG. 7), and further transfers the search query to the lower node minami ( (4) in FIG. Similarly, in the node minami, it is checked whether or not the corresponding data set exists in the database 20 owned by itself ((4) -1 in FIG. 7). The corresponding data set and the metadata of the corresponding data set are returned to the node tanaka ((4) -2 in FIG. 7). Node tanaka relays the response to murata ((3) -2 in Fig. 7)
[0029]
The node murata collects responses returned in response to the search query, constructs a search result screen, and displays it to the user ((5) in FIG. 7). On the search result screen, the title, owner (existing node), and data set type of the corresponding data set are displayed in a list. The user selects a data set to be downloaded from this list. Then, a download request is transmitted directly to each node where the data set selected for download exists ((6) in FIG. 7).
[0030]
The node receiving the download request directly transfers the designated data set to the node murata ((6) -2 in FIG. 7). In this way, the shared file is searched and transferred in the peer-to-peer network.
[0031]
Next, the configuration of the system 1 that realizes the operation described with reference to FIGS. 6 and 7 will be described. Prior to the following description, three types of metadata used as specific examples in the following description are defined in FIG. FIG. 8A shows the contents of the report type metadata (M01). The report-type metadata M01 includes items of “document title”, “creator”, and “creation date”. FIG. 8B shows the content of the meeting report type metadata (M012). The conference report type is obtained by adding a set of items (M02) of “conference name”, “attendee”, and “date and time” to the metadata M01 of the report type. FIG. 8C shows the contents of the business trip report type metadata (M013). The business trip report type is obtained by adding a set of items (M03) of “business trip destination”, “accompanying person”, and “business trip date / time” to the metadata M01 of the report type. FIG. 8D is a system diagram showing the parent-child relationship of three document types: a report type, a conference report type, and a business trip report type. The actual metadata includes not only the item name but also its value and the type name of the unique metadata type (such as “report type”).
[0032]
In the following description, “(one) shared document” and “(one) data set”, “document type”, and “metadata type” are used as synonymous terms. “(One) shared document” and “document type” are terms used from the viewpoint of the user, and “(one) data set” and “metadata type” are terms used from the viewpoint of the computer system. This is because it refers to the same thing as an entity.
[0033]
12 and 13 are schematic flowcharts for explaining the entire operation of the search engine 11. FIG. 12 and FIG. 13 show one flowchart divided into two for the sake of space. Hereinafter, the operation of the search engine 11 will be schematically described with reference to this general flow.
[0034]
The search engine 11 is always activated when the node computer starts up. First, initial setting processing is performed (S01). Although the initial setting process depends on the OS of the node computer and the system implementation method, the network engine 13 is activated to always be able to communicate with other nodes using the peer-to-peer protocol, and used to execute the search process. The temporary storage area to be processed and various state flags are initialized. Since the search process can be accepted any time after the initial setting is completed, an icon for calling the search condition input screen interface is displayed on the computer screen (S05). When the user wants to perform a search, the user can display the search condition input screen at any time by clicking the icon.
[0035]
Thereafter, the search engine 11 enters an event waiting state (S09). The main events here are search icon selection, search request generation, file transfer request generation, search result reception, file transfer request response reception, search request reception, search result relay reception, and file transfer request reception. is there. In addition to this, as a function of the search engine 11, an event generated by an interactive operation such as a call of an operation screen for registration / change processing of a shared document and an instruction of registration / change processing also occurs. In the description, only operations related to search processing, which is the main function of the search engine 11, will be described.
[0036]
When the search engine 11 detects a search icon selection event, the search engine 11 first displays a GUI screen for selecting a search type (search type) (S17), and allows the user to select a search type. Next, a search condition input screen corresponding to the search type selected by the user image is displayed (S19), and the user inputs the search condition on the screen.
[0037]
FIG. 9 shows an example of a GUI screen when inputting search conditions. FIG. 9A shows a GUI screen for selecting a search type. FIGS. 9B to 9D are search condition designation screens that are displayed when a report type, a conference report type, and a business trip report type are selected as search types, respectively.
[0038]
The search request event occurs when the user presses the search button after entering the search conditions in FIGS. At this time, the search engine 11 issues a search request to the next node on the route through the network engine 13 (S10). In addition to the search conditions input by the user, the search request includes information such as the ID number of the search request, the ID of the search request source node, and the initial value of the lifetime. The search engine 11 sets a flag indicating that the request with this ID number is being searched (waiting for a response to the search request issued by itself) (S12).
[0039]
The file transfer request event occurs when the user selects a specific file from the search result list screen and presses the file transfer request button. The search engine 11 issues a file transfer request to the node having the data set through the network engine 13 (S20).
[0040]
When the response to the file transfer request issued by itself is changed, the file data is fetched (S40). This completes the series of processing.
[0041]
Next, the processing of the relay node search engine 11 will be described with reference to FIG.
[0042]
First, when a search request is received (relayed) from the previous node, the search engine 11 relays the search request to the next node on the route through the network engine 13 (S50). However, the network engine 13 no longer relays when the lifetime of the search request is zero. When relaying, the lifetime value is decreased by one and relayed. Then, the local node search process is executed (S52). The search processing result is returned to the previous (upper) node as soon as the search processing is completed (S62).
[0043]
If a search result is received from a lower node on the route, it is relayed to the upper node on the route as it is (S62).
[0044]
When a file transfer request addressed to the own node is received, a copy of the file is directly returned to the requesting node (S70).
[0045]
The flowchart of FIG. 14 explains the flow of the search process of the own node in step S52 in more detail. Hereinafter, the search process of the own node will be described with reference to FIG.
[0046]
First, one unexamined data set existing in the node is selected (S80). Next, it is checked whether the document type of the survey target data set matches the designated search type or is a lower type. If not included, the process jumps to step S88. If included, the designated search type plug-in 12 is called, search condition data is handed over to this, and the search by this plug-in 12 is executed (S84). As will be described later, the plug-in 12 has a portion that hits the search condition data in the metadata by calling another plug-in (“parent type” plug-in) inside the plug-in 12 if necessary. And the result (whether it was hit) is returned to the search engine 11. The search engine 11 temporarily records the result (S86). Then, it is checked whether or not an uninvestigated data set exists in the own node (S88). If it does not exist, all searches for the own node have been completed.
[0047]
In the flowchart of FIG. 14, the timing at which the type plug-in 12 is called from the search engine 11 has been described. The type plug-in 12 has a function of returning a result of whether or not a specific one data set hits a given search condition in the search process (S52) of the own node. FIG. 5 is a flowchart for explaining the search process by the mold plug-in 12 in step S84 in more detail. Hereinafter, the processing of the type plug-in 12 called from the search engine 11 will be described with reference to FIG.
[0048]
First, the value (unique metadata) of the item to be processed by the called type plug-in 12 is inspected to determine whether there is a portion that satisfies the search condition (S101). If it is applicable (hit), the examined data set is to be added to the search result list, and the hit is set as a return value, and the process returns to the caller (S105). If there is no hit, it is checked whether the called plug-in has a higher type (S107). If there is no higher type plug-in, the return value indicates that no hit was found in this data set. Set and return to the caller (S113). The above two cases are when the result is confirmed by this type of plug-in. If there is an upper type plug-in in step S107, the search condition data is delivered and the upper type plug-in is called (S109). In the upper plug-in, a similar determination process is performed. The return value of the upper plug-in is set as the return value of the plug-in that called it, and the process returns to the caller (S111).
[0049]
The above is the search processing operation by the type plug-in 12. In this system, starting from the unique metadata for the search type, the upper type plug-ins are called one after another until the content of the metadata hits the search condition. If each type plug-in checks only its own scope (corresponding unique metadata) and does not hit, further processing is transferred to the type plug-in of the parent type. By adopting such a system configuration, it becomes easy to realize a type plug-in corresponding to a new document type being defined, and a flexible document sharing system can be realized.
[0050]
Next, the configuration of the mold plug-in 12 that realizes the operation of the flowchart of FIG. 5 will be described with reference to FIGS. The type plug-in 12 needs to be provided corresponding to the unique metadata type in the metadata. This is because it is necessary to process the newly defined metadata part as an extension type of the basic type (parent type, higher-level type). FIG. 11 is a diagram expressing a logical configuration when a type plug-in corresponding to the specific conference report type M02 is realized as a class object. The class object P02 holds type definition information P020. In the type definition information P020, a type name (conference report type), item definition information for defining unique metadata, a type plug-in ID or type name of a parent plug-in are recorded. In addition, the class object P02 includes methods of a search result transmission unit P021, a unique metadata search unit P022, and a search delegation unit P023 to a parent plug-in.
[0051]
The unique metadata search means P022 executes the main part of the operation described in the flowchart of FIG. The search result transmission means P021 is in charge of processing for returning the result processed by this type plug-in to the caller (child type plug-in or search engine 11). The search delegation means P023 to the parent plug-in executes control to move the search process to the higher-level plug-in in step S109.
[0052]
FIG. 10 is a diagram representing a logical configuration when a type plug-in corresponding to the specific report type M01 is realized as a class object. The class object P01 holds type definition information P010. In the type definition information P010, a type name (report type), item definition information for defining unique metadata, a type plug-in ID or type name of a parent plug-in are recorded. The class object P01 includes methods of a search result transmission unit P011 and a unique metadata search unit P012. Since there is no parent type plug-in, the search delegation means P013 to the parent plug-in is not provided.
[0053]
If a method for registering / changing metadata is added as a method to the class objects P01, P02, it is possible to register / change metadata of a shared document as well as document search by P01, P02. It becomes.
[0054]
The embodiment of this system has been described in detail above. The characteristics of document retrieval by this system are summarized as follows. When searching by a certain search type, for example, a report type, a meeting report type document and a business trip report type document, which are developed types thereof, are also searched. However, in that case, since the meeting report type document and the business trip report type document are treated as the report type document, only the report type plug-in works, and the meeting report type plug-in and the business trip report type document plug-in work. Absent. That is, the meta information of the developed unique part is not involved in the search. Therefore, it is possible to hierarchically define document types from basic types to their evolved types, but the phylogenetic tree of such types does not need to be fixed from the beginning, but later if necessary. You can define new types and accumulate new types of data sets. Even in such a case, when searching for existing types, it is possible to search without trouble. In addition, when upgrading the file sharing system so that it can be searched by the new type added, it is only necessary to create a type plug-in that handles only the meta information of the developed part and distribute it to each user.
[0055]
For example, if only a report type is initially defined and several shared documents are accumulated as a report type, then a conference report type is defined and a conference report type shared document is accumulated, When searching by type, all shared documents are searched. Such a feature of the present system gives operational flexibility to a P2P file sharing system used by many users in an equal relationship. Defining meta-information suitable for the document to be stored depends on the purpose of creating the document, but the purpose of creating the document depends on the activity theme of the member who uses the file sharing system at that time, This is because the members' activity themes are not constant and change over time.
[0056]
【The invention's effect】
As described above in detail, according to the present system, it is possible to realize a P2P type file sharing system that can be searched based on meta information, instead of searching only by file name, and further, after the file sharing system is operated, storage is performed. Even if it is necessary to add the type of document to be performed, there is a remarkable effect that it can be handled easily and flexibly.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an outline of a node computer constituting a peer-to-peer network system 1 according to an embodiment of the present invention.
FIG. 2 is a diagram illustrating a peer-to-peer network protocol.
FIG. 3 is a diagram illustrating the structure of a data set.
[Fig. 4] Fig. 4 is a diagram for describing a configuration example of metadata.
FIG. 5 is a flowchart for explaining the operation of the mold plug-in 12;
FIG. 6 is a diagram for explaining a search processing operation of the system 1;
FIG. 7 is a diagram for explaining a search processing operation of the system 1;
FIG. 8 is an explanatory diagram of three types of metadata used in the description.
FIG. 9 is an example of a GUI screen for performing a search process.
FIG. 10 is a block diagram illustrating a report type plug-in.
FIG. 11 is a configuration diagram illustrating a conference report type plug-in.
FIG. 12 is a diagram illustrating a peer-to-peer network protocol.
FIG. 13 is a diagram illustrating the structure of a data set.
[Fig. 14] Fig. 14 is a diagram for describing a configuration example of metadata.
[Explanation of symbols]
1 Document sharing network system
10 node computer
11 Search engine
12 type plug-in
13 Peer-to-peer network engine
P01 Report type plug-in
P010 Report type plug-in type definition information
P011 Report-type plug-in search result transmission means
P012 Unique metadata search means of report type plug-in
P02 Meeting report type plug-in
P020 meeting report type plug-in type definition information
P021 Meeting report type plug-in search result transmission means
P022 Specific metadata search means for meeting report type plug-in
P023 Search delegation means for meeting report type plug-in to parent plug-in

Claims (5)

A document sharing network system in which a plurality of node computers cooperate in an equal relationship,
Each node computer connected to this system
The document, a storage device that holds the data set is a combination of the actual file data and metadata describing the actual file data for each item defined, and
A type plug-in that corresponds to a type called a metadata type, which is equivalent to classifying documents according to items included in the metadata, and refers to the metadata of each document ;
A network engine that exchanges information with other node computers using a peer-to-peer network protocol;
A search engine that performs a search for a dataset using the network engine and the type plug-in;
A graphical user interface that accepts search criteria input and displays search results from the search engine;
In addition,
As for the metadata type, a new item called a unique metadata type is added to an item defined in the basic parent type without the parent type itself or as a basic metadata type. One of the metadata types with a defined parent type,
The type plug-in refers to only the items included in the unique metadata type of each corresponding metadata type, and the other items are processed by calling the type plug-in of the parent metadata type. Refers to each item of metadata of the target dataset, and returns a test result to see if there is a part that matches the specified search condition,
With the above configuration, a peer-to-peer type document sharing network system that can extract a corresponding data set by comparing a specified search condition with metadata of each data set and present it as a search result. A document sharing network system in which a plurality of node computers cooperate in an equal relationship,
Each node computer connected to this system
A storage device that holds a document as a data set that is a combination of real file data and metadata describing the real file data for each predetermined item;
A type plug-in that is provided in correspondence with a type for classifying documents according to items included in the metadata, referred to as a metadata type, and refers to the metadata of each document;
A network engine that exchanges information with other node computers using a peer-to-peer network protocol;
A search engine that performs a search for a dataset using the network engine and the type plug-in;
A graphical user interface that accepts search criteria input and displays search results from the search engine;
In addition,
As for the metadata type, a new item called a unique metadata type is added to an item that is a basic metadata type that does not have a parent type, or is defined in the basic parent type. One of the metadata types with a defined parent type,
The type plug-in is
Type definition information including at least item definition information that defines the type name, unique metadata type, and
Search result transmission means for returning the result processed by this type plug-in to the caller;
A unique metadata search means for referring to an item included in the unique metadata type, checking whether the value matches a search condition, and setting the result;
When the type has a parent type, the type definition information further includes the identification information of the type plug-in of the parent type, and calls the type plug-in of the parent type to search conditions. And a search delegation means to the parent plug-in that passes to the type plug-in,
Refers to each item of metadata of the data set to be processed, and returns a test result for whether there is a part that matches the specified search condition,
With the above configuration, a peer-to-peer type document sharing network system that can extract a corresponding data set by comparing a specified search condition with metadata of each data set and present it as a search result. 3. The peer-to-peer type document sharing network system according to claim 1 or 2, wherein when searching for a document that is stored and managed, by specifying one metadata type as a search type, a search type among the shared documents. A peer-to-peer document sharing network system characterized in that a data set corresponding to a metadata type that matches the metadata type and a metadata type whose parent type is a search type can be limited as a search target. 3. The peer-to-peer document sharing network system according to claim 1, wherein a user interface provided when registering a document is provided according to a metadata type of a newly registered document. The peer-to-peer document sharing network according to claim 1 or 2, wherein a user interface for specifying a search condition when starting a search is provided according to a metadata type as a specified search type. system.

Images