JPH05108456A - Hyper text system - Google Patents

Abstract

PURPOSE:To deal with a file independent of the file of a hyper text as one node by respectively recording information for managing the file independent of the node and recording data and information for managing the state of a link in the node. CONSTITUTION:Hyper text information composed of the node 120 and the link 130 is preserved in the hyper text file 110. The node 120 is the unit of information and that of a function and it is composed of a node information management area 121, a file information management area 122 and a link management area 123. The area 121 holds information for managing the node such as the type and the size of the node, and the area 122 is recorded with correspondence with the file 140 such as a file name which is made to correspond to the node. The area 123 is recorded with the state of the link in the node. The file 140 is an area holding the text of the node 120 and it is the general file independent of the file of the hyper text.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a hypertext system having a hypertext composed of nodes for recording data and links indicating the relationship between the nodes.

[0002]

2. Description of the Related Art Hypertext is a method of associating a plurality of digitized data with each other, and manages data divided into logical units in a unit called a node. It is a collection of network-like data created by expressing associations by links.

Such a hypertext is a document which is not limited by the format of a document printed on paper (so-called linear document) and which is configured by making the most of the characteristics of a computer.

The hypertext system can integrally perform document creation support, document management, document search, multimedia data management and multimedia data search.

As a conventional hypertext system,
`` Hypertext: An Introduction and Survey.IEEE Compute
r, 20, 9, 17-41. Chapel Hill, NC. 1987 ”.

For example, the Note Cars System (1985) developed at Palo Alto Research Laboratories of Xerox Co., Ltd.
(Released in March, 2002) treats document editors, graphic editors, graph editors, bitmap editors, etc. that are displayed in windows on the display of personal computers as hypertext nodes (called cards in Note Cars), and We have created an environment in which data such as papers, manuals, teaching materials, etc. can be registered, and such cards can be freely linked by links to form a network and the network can be saved as a file.

The Notecars link can be placed as a visualized pointer at any position in all cards, or can be saved as an internal attribute of the card without being displayed in the card. Moreover, the user can arbitrarily create a notebook car card or link and register it in the system. In addition, it provides a browse function that visually displays and edits the entire network configuration by filtering by card and link attributes, link direction and depth. Furthermore, it provides a cross-file link mechanism for linking from a card in an independent network in a file unit to a card in a different network. For details on this cross file link mechanism, see "Note.
Cards in a Nutshell.Proceedings of the ACM CHI + GI
Conference pp.45-52) .Toront.1987. ".

[0008]

However, in the above-mentioned conventional hypertext system, in order to handle a file that is not in hypertext as a node (corresponding to a card in Note Cars), the contents of the file are stored in the node. Had to read. in this way,
Since the information of the file is held in both the non-hypertext file and the hypertext system, the utilization efficiency of the storage area is very poor. Further, in this method, since the information in the node and the information in the file are independent, even if the content of the file is changed, the changed content is not reflected in the content of the node.

For this reason, the usage of using a hypertext system for managing files is not suitable for the conventional hypertext system.

When a file not in hypertext and a node in hypertext are associated with each other, how to handle links in the node becomes a problem. That is, the link information is valid only in the hypertext system and does not make sense in a normal file system. Therefore, it is not appropriate to record the link information in the file of the file system. Also, even if the link is just recorded in a hypertext file, the link cannot be displayed at the correct position when the saved node is displayed again.

Therefore, an object of the present invention is to provide a hypertext system capable of handling a file independent of a hypertext file as one node.

[0012]

In order to achieve the above object, according to the present invention, in a hypertext system having a hypertext composed of a node for recording data and a link indicating a relationship between the node and the node,
A file independent of the hypertext file is associated with the node, and the node has information for managing the independent file and information for managing the state of the link in the node, respectively. The feature is that it is recorded.

[0013]

In the hypertext system according to the present invention, the file independent of the hypertext file and the node forming the hypertext are managed in association with each other. At least information for managing the independent file and information for managing the state of the link in the node are recorded in the node. The information of the text of the node is not held in the hypertext file but is held in an independent file.

Therefore, according to the present invention, a file independent of a hypertext file can be treated as one node, and the required storage area can be minimized when handling the node, and , Links can be placed in nodes.

[0015]

Embodiments of the present invention will be described below with reference to the accompanying drawings.

FIG. 1 is a diagram for explaining the basic principle of the hypertext system according to the present invention.

In FIG. 1, a hypertext file (hereinafter referred to as a hypertext file) 110 stores hypertext information (hypertext structure) composed of a node 120 and a link 130.

The node 120 is a unit of information or a unit of function, and is composed of three areas: a node information management area 121, a file information management area 122, and a link management area 123.

The node information management area 121 is an area for holding information for managing the node such as the type, size, display position, title, property, edit date and time of the node. The file information management area 122 stores the file 14
This is an area for recording the correspondence with 0, and is an area for holding the file name associated with the node and the editing date and time of the associated file. The link management area 123 is an area for recording the state of the links in the node, and is an area for holding a list of links and the positions of the links.

The link 130 is an area for connecting two nodes (an area for recording the relationship between the nodes), the identifier of the source node 131 (reference source node), and the destination. And the identifier of the destination node 132 (reference destination node).

The text information of the node 120 is not recorded in the hypertext file 110.

The file 140 is an area holding the text of the node 120, and is a normal file independent of the hypertext file.

FIG. 2 is a functional block diagram showing an embodiment of a hypertext system for implementing the principle of the present invention shown in FIG.

In the figure, the display device 210 is composed of a CRT and is for displaying hypertext. The input device 220 includes a keyboard for inputting commands and data and a mouse for specifying an area and selecting a node, and is used by a user to input commands and data.

The node 230 is the node 120 shown in FIG.
1, the link 240 corresponds to the node 130 shown in FIG. 1, and the file 250 corresponds to the file 140 shown in FIG.

The node management table 260 is stored in the node 23.
0 is assigned an identifier to manage that node,
It has a table composed of an identifier of the node 230 and a pointer to the node.

The link management table 270 has the link 24
It manages the link by adding an identifier to 0,
It has a table composed of an identifier of the link 240 and a pointer to the link.

The edit control device 280 controls the entire system. At the same time, the following processing is also performed. (1) Registration, update, and deletion of predetermined information in the node 230, link 240, node management table 260, and link management table 270. (2) Open and close hypertext files. (3) Opening and closing files independent of hypertext files. (4) Correspondence between files and nodes independent of hypertext files. (5) Opening and closing nodes. (6) Linking between nodes.

In this embodiment, a node associated with a file is defined as a file node. Next, the details of the file node will be described.

FIG. 3 shows an example of the structure of the file node. The example shown in this figure shows the configuration of the node 230 shown in FIG. The node information management area 231 includes a node type 311, a title 312, a display area 313, and a node edit date / time 314. The file information management area 232 includes a file name 321 and a file change date / time 322. The link management area 233 includes a link identifier 331 and a link position 332.

Here, the node (file node) 230
The entries provided in the respective areas will be described.

The node type 311 stores data indicating the node type divided by the type of information handled by the node.
The data for identifying the node type is a string. The title 312 stores data indicating the title of the node, and the data is a string. The display area 313 stores data indicating the display position (X, Y coordinate values) when the node is displayed on the display screen and data indicating the size (Width, Height) of the node. In the node edit date / time 314, the date / time when the node, the text, the title, the size, the display position, and the like are edited and the edited information are recorded.

In the file name 321, the name of the file associated with the node is recorded as a string. The file change date / time 322 stores data indicating the date / time when the content of the file or the attribute of the file was changed. The data is
This is data for confirming whether the correspondence between the file and the node is established when the node is opened, that is, whether the content of the file when the node is closed and the content of the actual file match.

The link identifier 331 stores a list of link identifiers attached to the file nodes.
The link identifier is a number. The link position 332 stores a list of position data indicating where each link is placed on the node. Link position 332
If the file node is a node that handles text, the number of characters from the beginning is recorded as position information. If the file node handles graphic information, the two-dimensional position on the node is recorded. (X, Y coordinate values) is recorded as position information.

Next, FIG. 4 shows an example of a node configuration of a node (corresponding to a so-called conventional node; hereinafter referred to as a conventional node) in which the body of the node is also stored in the hypertext file.

As shown in this figure, the node 400 corresponding to the conventional type node has a node information management area 410,
It is composed of a content pointer 420 and a link management area 430.

The node information management area 410 is used for the node 23.
Similar to the configuration of 0, node type 411, title 41
2, a display area 413, and a node edit date / time 414. A pointer to the area for storing the body is recorded in the content pointer 420,
In the link management area 430, only a list of link identifiers is recorded.

As described above, the area for recording the text of the node is different between the file node and the conventional node. That is, in the case of a file node, since the node body is stored in a file independent of the hypertext, the file node is provided with an area (file information management area 232) for identifying the file. On the other hand, the conventional node does not have the area but has an area (content pointer 420) for holding a pointer to the area for storing the text.

The link management areas are different between the two nodes. In the case of the conventional type node, since the identification data for identifying the link is recorded in the content, it is not necessary to separately record the data indicating the position of the link. Therefore, only a list of link identifiers is recorded in the link management area 430. On the other hand, in the case of the file node, since the body of the node is stored in a file independent of the hypertext file, it is necessary to record the link position separately from the body. Therefore, in the link management area 233, two lists of link identifiers and link positions are recorded.

FIG. 5 shows a display example in which a file node is linked. In the example shown in this figure, the file node “node 1” stored in the hypertext file 510 corresponds to the file 520 having the file name “file 1”. The text of the node 1 (node based on the data structure shown in FIG. 3) is the file 52.
The content of 0 is displayed, and the link 1 to the node 2 (node based on the data structure shown in FIG. 4) is attached. In FIG. 5, reference numeral 530 is a link icon, and the node 2 can be displayed by instructing the link icon 530 and performing an operation of displaying the corresponding node. Of course, the nodes 1 and 2 can be displayed at the same time. The node 1 and the node 2 are displayed in a card format as if one node is one card.

Now, paying attention to FIG. 5, node 1
The link information of the link 1 and the link icon 530 is added to the display content of the (file node), but the link information does not exist in the content of the file 520. That is, since the link information of the link 1 and the link icon 530 which are valid only in the hypertext file 510 does not affect the content of the file 520,
The contents of file 520 have not changed.

FIG. 6 shows the internal state of the hypertext in the display example shown in FIG. In this internal state, from the node management table 610, the node 1 is pointed to by the pointer corresponding to the identifier “1” of the node 1, and the node 2 is identified by the pointer corresponding to the identifier “2” of the node 2. Being pointed. Actual data is recorded in the node 1 in the data structure of the node 230 shown in FIG. 3, and actual data is recorded in the node 2 in the data structure of the node 400 shown in FIG. ..

For example, in the file name entry of the file information management area of node 1, the file name “file 1” of the file 620 associated with node 1 is recorded, and in the entry of the file modification date and time. Stores the date and time of edit of the file. In the entry of the link management area of the node 1, a link identifier “1” and a link position “32” are recorded as information about the link attached to the node 1. The link identifier number is
It corresponds to the number recorded in the link management table 640. In the entry of the content pointer of the node 2, a pointer to the text 630 (“national ...”) is recorded. Since no link is attached to the node 2, the entry of the link identifier in the link management area of the node 2 is empty.

The contents of the node 1 shown in FIG. 6 correspond to the node 1 shown in FIG. 5, and the contents of the node 2 shown in FIG. 6 correspond to the node 2 shown in FIG.

On the other hand, from the link management table 640,
The link 1 is pointed to by the pointer corresponding to the identifier “1” of the link 1. In the link 1, the identifier of the node 1 that is the source node and the identifier of the node 2 that is the destination node are recorded. The number “1” of the link management table 640 corresponds to the number “1” of the link identifier in the link management area of the node 1.

Next, the process of associating a file independent of the hypertext file with a node will be described.

When a node is newly created, the above-mentioned independent file is designated to determine the correspondence between the node and the file. Further, it is also possible to change the corresponding file after once determining the correspondence between the node and the file.
When associating a node with a file, one node is associated with one file. The processing procedure for determining the correspondence between such nodes and files will be described with reference to the flowchart shown in FIG.

As shown in FIG. 7, the user inputs the name of the file to be associated with the newly created node (this becomes the file node) (step 701). The edit control device 280 checks whether or not a file having the input file name (a file independent of the hypertext file) exists (step 702). If the file exists, the contents of the file are read into the file node (step 703). The name of the file determined to correspond to the file node and the date and time of the last edit of the file are recorded in the file management area of the file node (step 704). On the other hand, if the file does not exist in step 702, abnormal processing is performed (step 7).
05). An example of the abnormal processing method is to output an error message indicating "create a file" and terminate the processing.

Next, the processing procedure for opening the file node will be described with reference to the flowchart of FIG.

As shown in FIG. 8, the editing control device 280
Opens the hypertext file and reads the management information of the file node (step 80
1) Based on the management information, it is determined whether or not a file corresponding to the node exists (step 80).
2). If the file exists, the file is opened and the information corresponding to the text of the node is read into the file node (step 803). Then, the file node is displayed based on the read management information of the node and the information corresponding to the text of the node (step 804). On the other hand, if the file does not exist in step 802, the node (this becomes the file node) is associated with the file (step 805), and thereafter,
Go to step 804. In this case, the associated file is opened and the file node is displayed based on the information corresponding to the text of the node read from the file and the management information of the node read in step 801.

The last edited date and time of the file recorded in the file node is compared with the last edited date and time of the file. If the last edited date and time of the file is newer than that recorded in the file node, a link is displayed. The user may also be notified that the location may have changed.

Next, the processing procedure for closing the file node will be described with reference to the flowchart shown in FIG.

As shown in FIG. 9, the editing control device 280
Writes node information (node and link) to the hypertext file (step 901), and then determines whether the text of the file node has been changed (step 902). In this determination, since the file node is displayed in a window format, it is determined whether or not the text of the file node is changed depending on whether or not the content displayed in the window is changed.

When the text of the file node is changed in step 902, the text of the changed file node is written to the file associated with the node (step 903), and then the file node is displayed. Erase from device 210 (step 904).

On the other hand, if the text of the file node is not changed in step 902, the process proceeds to step 904.

Next, the link is information that is valid only within the hypertext system, and writing it to a normal file does not make sense. Therefore, in this system, the link information is recorded in the hypertext file. That is, the position of the link in the file node and the identification information of the link are recorded in the link management area in the file node. A processing procedure for attaching such a link will be described with reference to the flowchart shown in FIG.

As shown in FIG. 10, the editing control device 280
Requests the user to specify a point to attach a link (step 1001). The user who responds to this will specify the point. Next, the user is requested to specify the node to be linked (step 1002). The user who responds to this will specify the node. When the information is input by the user in this manner, the edit control device 280 determines the position of the link in the file node, the link information (relationship between nodes), and the hypertext file based on the input information. (Step 1003). That is, the data indicating the position of the link is recorded in the link management area of the file node (see the link management area of the node 1 shown in FIG. 6), and the link information is recorded in the link (see the link 1 shown in FIG. 6). Record. And to manage that link,
The identifier of the link and the pointer to the link are recorded in the link management table in association with each other. When the recording process of the link position and link information in the file node is completed in this way, the link is displayed in the file node (step 1004).

As described above, according to this embodiment, there are the following merits. (A) A file that is not hypertext can be treated as a node in hypertext. (B) It is possible to reduce the storage area required for realizing the above (a). (C) In order to realize the above (a), no extra information for handling as hypertext is added to the file side. (D) In the situation of the above (c), the node corresponding to the file can be linked to another node in the same manner as a normal node.

[0059]

As described above, according to the present invention, a node associated with a file independent of a hypertext file has information for managing the independent file and a link in the node. Since information for managing the state of is recorded respectively, it is possible to handle a file that is not a hypertext as a node in hypertext, and to link from that node to another node.

Since the node text is saved in a file independent of the hypertext file, it is not necessary to copy the necessary contents in the node as in the conventional case, and the storage area can be reduced. ..

[Brief description of drawings]

FIG. 1 is a diagram for explaining the basic principle of a hypertext system according to the present invention.

FIG. 2 is a functional block diagram showing an embodiment of a hypertext system according to the present invention.

FIG. 3 is a configuration diagram showing a configuration of a node in a format in which a text of a node is stored in a file independent of a hypertext file in the present embodiment.

FIG. 4 is a configuration diagram showing a configuration of a node in a format in which the text of the node is stored in a hypertext file according to this embodiment.

FIG. 5 is a diagram showing a display example in which a link is added to a file node in the present embodiment.

6 is a diagram showing an internal state of a hypertext in the display example shown in FIG.

FIG. 7 is a flowchart showing a processing procedure for associating a node with a file in this embodiment.

FIG. 8 is a flowchart showing a processing procedure for opening a file node in this embodiment.

FIG. 9 is a flowchart showing a processing procedure for closing a file node in this embodiment.

FIG. 10 is a flowchart showing a processing procedure for adding a link in the present embodiment.

[Explanation of symbols]

110 ... node, 120, 230 ... node, 121, 2
31 ... Node information management area, 122, 232 ... File information management area, 123, 233 ... Link management area, 13
0, 240 ... Link, 131, 241 ... Source node,
132, 242 ... Destination node, 210 ...
Display device, 220 ... Input device, 140, 250 ... File, 260 ... Node management table, 270 ... Link management table, 280 ... Editing control device.

Claims (1)

[Claims] 1. A hypertext system having a hypertext composed of a node for recording data and a link indicating a relation between the node and the node, wherein a file independent of the hypertext file is associated with the node. The hypertext system is characterized in that information for managing the independent file and information for managing the state of the link in the node are respectively recorded in the node.