Data storage and retrieval system

Abstract

A user based computer system for information storage and retrieval in which information data items are stored in a persistent memory for later searching, retrieval and/or browsing and related in the memory by a frame system wherein the stored information includes primary information from outside the system and additional information derived from primary information and inherited from stored information.

Description

The present invention relates to user-based computer systems for storing and retrieving information and, in particular, to a computer system including software for causing a persistent memory to function as an information storage and retrieval system that receives primary information from outside the system, generates additional information from the primary information and stored information, and stores both the primary and additional information in a frame system in which the primary and additional information can be searched, retrieved and/or browsed.

BACKGROUND OF THE INVENTION

When personal computers first became available, many consumers thought that they would be able to put information into them and easily find and retrieve it later. Except in special cases, this promise remains unfulfilled. Computer programs today are universally designed to manage only specific types of information. Users who wish to store information in a computer and retrieve it must use computer programs specifically designed for particular information and are restricted to managing just that information. Examples of such programs often found on desktop personal computers are Intuit's Quicken (for personal financial information), Symantec's Act (for sales contact information), cooking recipe managers and “personal information managers” (PIMs) for to-do lists, telephone numbers, addresses, and so forth.

It is usually impossible to add new information elements related to the information for which the program is designed if the program has not been specifically designed to manage the additional elements. Because of this, competing programs with otherwise similar capabilities are often effectively distinguished only by the suitability for the user's task of the set of data elements that the programs manage. Using present-day database technology (and this includes the more recent object database technology), the data elements to be manipulated must be specified within the software programs that manipulate them. These specifications determine the size and format of the data being represented and the relationship between data elements. This descriptive process, despite the efforts represented by such products as Microsoft Access, is difficult for nonprogrammers. This means that most computer users are forced to try to find a program that can store and retrieve just the particular information in which they are interested.

Computer users often resign themselves to using a word processor to save collections of information in a “document.” While this is suitable for small amounts of information, the lack of an ability to display the information as anything other than a text document limits the effectiveness of this solution for larger amounts of data.

Known databases are characterized by a structure designed to receive specific categories of information. In order to enter information in non-specified categories, the structure of the database must first be modified to permit entry and storage of information in that previously unidentified category. This is not always an easy task and frequently discourages the inclusion of such information. For example, if a database is structured to record names, addresses, telephone numbers and email addresses, it cannot record birthdays unless the structure of the database is modified to redefine the table to include that category of information to the structure. The addition of a new category of information that might be applicable to only a few of the entries in a large database is frequently avoided as not worth the bother.

BRIEF DESCRIPTION OF THE INVENTION

The computer system of the present invention addresses the aforementioned problems. The present invention combines ideas drawn from research in artificial intelligence and from object-oriented technology to produce uniquely flexible methods and apparatus for a computer program to store and retrieve information. The invention enables a user to store, browse and retrieve information on a wide variety of information topics for which the program was not specifically designed.

In the present invention, an improved computer information storage and retrieval system and method are provided using three primary elements: (1) a known data structure used in a novel way; (2) a program to create additional relationship information from primary relationship information; and (3) one of the several standard searching routines known in the art. The invention permits a user to enter any information desired at any time without the necessity of altering the data structure (redefining a table). Furthermore, the data entered is related according to relationships that are known to and of importance to the user. In this way, the database is personalized in a way that maximizes information retrieval from the database. For example, with the present invention, a database primarily intended to record names, addresses, telephone numbers and email addresses can, at any time and without any changes to the database structure, add birth dates, social security numbers, birth places, type of automobile owned, etc., to one or more of the entries. There are no impediments to adding any category of information to an entry, whether for one entry only, for several entries or for all entries.

At the same time, the database structure used in the present invention makes efficient use of the storage medium in which the data is persistently stored.

The present invention uses a frame system to store data. Frame systems were first introduced by Marvin Minsky in 1975 (Minsky, Marvin (1975) “A framework for representing knowledge,” in P. Winston, ed., The Psychology of Computer Vision, McGraw-Hill, New York, pp. 211-280) in relation to work then being conducted in Artificial Intelligence (AI). Minsky defined frames in the following terms:

• • A frame is a data structure for representing a stereotyped situation, like being in a certain kind of living room or going to a child's birthday party. Attached to each frame are several kinds of information. Some of this information is about how to use the frame. Some is about what one can expect to happen next. Some is about what to do if these expectations are not confirmed.
  • We can think of a frame as a network of nodes and relations. The “top levels” of a frame are fixed, and represent things that are always true about the supposed situation. The lower levels have many terminals—“slots” that must be filled by specific instances of data. Each terminal can specify conditions its assignments must meet. (The assignments themselves are usually smaller “sub-frames.”) Simple conditions are specified by markers that might require a terminal assignment to be a person, an object of sufficient value, or a pointer to a sub-frame of a certain type. More complex conditions can specify relations among things assigned to several terminals.

Since Minsky published his work in 1975, others have expanded, modified and continued using frames to solve specific problems, to advance the quest for automated reasoning and translate one ontology into another.

The present invention uses the frame concept in a totally different way for a different purpose and with a different result. In the present invention, a frame system is used not to solve a problem, but rather to direct the storage of information in a database in an efficient manner and with multiple relationships created between data items. When primary information (data statement containing a plurality of data items) is entered into the database, the invention automatically generates one or more additional relationship statements between data items and then creates structural connections between the data items—both those already in the database and those being entered. Each data item entered is either related to previously entered data items of a category, or begins its own category, or both.

The database of the present invention can be searched using any one of the several search techniques well known in the art. For efficiency and speed, an AVL tree can be advantageously used, although, where appropriate, a simple string search might suffice. Searching a database of the present invention is independent of the frame structure used to organize and manage the data. Once the search locates data that fits the search query, the frame structure once again comes into play by being browsed to find the specific information sought. It is in the browse operation that the personalization of the data structure has its greatest benefit.

Accordingly, it is an object of the present invention to provide a computer system for storing and retrieving information having a structure that permits any category of information to be entered by the user without alteration of the database structure.

It is a further object of the present invention to provide a computer system for storing and retrieving information with the retrieval of information enhanced by generating additional data relationships from primary information.

It is still another object of the present invention to provide a method for storing and retrieving information in a computer memory that enables new categories of information to be added without restructuring the database.

These and other objects, aspects and features of the present invention will be better understood from the following detailed description of the preferred embodiments when read in conjunction with the appended drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C are schematic illustrations of various configurations of the components of the invention;

FIG. 2 is a schematic illustration of a typical relationship in a frame system between a frame, a slot and a value for the slot;

FIG. 3 is a schematic block diagram illustrating the use of symbol blocks to store data item representations;

FIG. 4 is a schematic block diagram illustrating a small threaded AVL tree with links to the symbol blocks that store the data item associated with each tree node;

FIG. 5 is a schematic block diagram illustrating the relationship between a frame and its slot structures;

FIG. 6 is a schematic block diagram illustrating the relationship between a slot and its value structures;

FIG. 7 is a schematic block diagram illustrating the relationship between a frame and its slots and an AVL tree;

FIG. 8 is a schematic block diagram illustrating the logical organization of persistent storage for the fixed-size storage segments used to store the data structures; and

FIG. 9 is an example of a client window.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The computer program of the present invention has two principal software components: the data server software (server or server component) and the display client software (client or client component). These two components can be incorporated in the same computer program or can be in separate programs which can execute on the same computer or on different computers that communicate with each other. A server component can support more than one client. These alternative configurations are shown in FIGS. 1A-1C.

Client Component Overview

The client presents an interface to the user. This user interface accepts instructions to add, retrieve, modify, or delete information items that the server component manages.

Information is presented to the user on a computer display monitor. Other displays that might be used include the display on a mobile telephone, a tablet computer, or the display on a Personal Data Assistant (PDA) device, such as a Palm Pilot or Blackberry. In an alternative embodiment, information can be presented to the user audibly by using voice-synthesis software that takes input from the client component to control speakers connected to a sound card controller in the computer.

The user controls the client by using a keyboard or a “mouse” pointing device connected to the computer executing the client software. In an alternative implementation, user input could be received by the client component as messages from a speech recognition program that processes commands spoken by the user into a microphone connected to the sound card. The speech recognition program and the sound card could be in the computer executing the client software or could be in another computer that communicates electronically with the computer executing the client software.

In another embodiment, the user can control the client by using the telephone touch tones via a telephone connection to the client computer.

Server Component Overview

The server component stores user data received from the clients in a persistent storage system such as a data file system, manages the stored contents and retrieves stored information to send to client components. Many of the new capabilities of the data management system of the present invention are a consequence of the design of the server component software.

Basic Server Data Structures

The server component manages files containing six different types of data structures:

• 1. Data Item. This is a data object that completely represents an item of user data. A data item may, for example, be used to represent a last name, a phone number, a date, a paragraph of text, a picture, a sound recording, or even a piece of executable computer code.
• 2. Symbol Block. This is a fixed-length data structure used to store data items in the computer files managed by the server. Data items that are too large to be stored in a single symbol block are stored in a collection of symbol blocks. In the preferred embodiment, a symbol block is never used to store data from more than one data item.
• 3. AVL Tree Node. This data structure is used to link the data items in a data structure known as a “threaded AVL tree.” The threaded AVL tree is used to rapidly search for data items.
• 4. Frame. One frame data structure exists for each data item stored by the server component. The terms frame and slot (used below) are taken from artificial intelligence (AI) research. Frame systems are logical reasoning programs that use the metaphor that objects are represented by frames and that binary relations between objects are represented by slots in one frame filled by another frame.
• 5. Slot. Similar to the AI metaphor, slots are used to represent a binary relationship between two data items
• 6. Value. These data structures are used to connect slots that are contained in frames, to follow the AI metaphor, to other frame data structures. The relationship of the frame, slot, and value data structures can be seen in the following example. What is to be stored is the relationship John's birthplace is Philadelphia. This is a binary relation, birthplace, between John and Philadelphia. John is represented by a frame that has a slot for birthplace. In that slot is a value that connects the slot to another frame that represents Philadelphia. These structures are shown in FIG. 2.
• 7.

Data Item

The data item structure can be understood as a “class” in the programming language in an object-oriented programming language such as C++. The Information Workbench software components treat data items as C++ objects and manipulate them by calls to the data item member functions or “methods.” The data item class software must also provide any data conversion routines that the application requires—such as a routine to produce a procedure name if the data item represents an executable procedure. An advantage of this approach is that the software of the present invention can be extended by merely altering the data item class software for new applications that manage new kinds of data items.

For a typical application, a C++ language definition for a data item class would be required to have the functionality of the member data variables and member functions shown below.

Data Members
typedef enum  {
IWD_Text,       // Text data
IWD_Integer,    // Integer numeric data
IWD_Real,       // Floating point numeric data
IWD_Date,       // Date data
IWD_Time,       // Time data
IWD_FileID,     // File identifier
IWD_InternetID, // Internet identifier
IWD JPEG,       // JPEG format picture image data
IWD MP3,        // MPC format sound data
IWD AVI,        // AVI format video clip
IWD_None        // Unknown data type
} IWDataType;
IWDataType m_type;

• • This enumerated type indicates the type of application that the data represented by the data item class might be used for:

Typedef enum  {
IWF Integer,  // Integer numeric data
IWF Real,     // Floating point numeric data
IWF DateTime, // System binary formatted Date and Time
IWF String,   // ASCII text string
IWF Unicode,  // Unicode text string
IWF Binary,   // System formatted binary block
} IWDataFormat;
IWDataFormat m format;

• • This enumerated type indicates the internal binary representation of the data represented by the data item class.int m_nsize;
  • This is the size, typically in bytes, of the memory buffer used to contain the representation of the stored data.
    char * m_pData;
  • This is a pointer to the location in memory where the representation of the data item is stored.

Member Functions

IWDataItem( );

virtual ˜IWDataItem( );

These are the C++ constructor and destructor functions for the data item class.

void SetType(const IWDataType type) m_type=type;};
inline IWDataType GetType( ) const {return m_type;};

There are member functions to store and to retrieve a value that indicates the type of data represented by the data item.

For each type of data that a data item can represent, there must be member functions to store and to retrieve that type of data in the data item. The following three functions are used to store and retrieve text character string data.

int GetBufferLength( ) const;

Returns the size of the buffer required to store the character string represented by the data item.

void GetData(char * p, int nBufSize) const;

Stores a character string representation of the data item in a buffer of size nBufSize at memory address p.

void SetData(char * p, int nBufSize);

Reads the character string representation of size nBufSize at memory address p and stores it in the data item structure.

There are member functions to remove the information contents of a data item and to determine if a data item contains no information.

bool IsEmpty( ) const;

Returns true if the data item structure contains no information, false otherwise.

void Clear( );

Removes the information content from a data item structure.

Data items will often be stored in sorted order to permit rapid searching. Therefore, there are member functions for comparing two data items to determine which follows the other in the chosen sorting order and to determine if the content of two items match each other according to some specified criteria to satisfy a data item search.

int Compare(const IWDataItem & b) const;
int Compare(const IWDataItem & a, const IWDataItem & b) const;

Returns 0 if the items match, −1 if data item represented by a precedes b in the sort order, +1 otherwise.

int Compare(const IWDataItem & a, const IWDataItem & b, int match_len) const;

Compares segments of length match_len of data items a and b, typically beginning at the start of the data representation in each, and returns 0 if the segments match, −1 if the segment of a precedes segment of b in the sort order, 1 otherwise.

In an alternative embodiment, the comparison of data items might also make use of stored information about the data types, such as their source, the time of their entry into the database, the dates during which the data was valid, or other information characterizing data. Such a comparison might indicate that two data items are equivalent only if they were valid on the same dates. In another alternative embodiment, a comparison might indicate that the two data items are equivalent if their texts are close enough to each other as measured by a technique such as counting the number of mismatched letters.

bool IsEmbeddedMatch(const IWDataItem & a, const IWDataItem & sub);

Returns true if the data represented by data item structure sub can be found somewhere within the data represented by data item a, false otherwise.

Finally, data items may contain elements for use in specific applications that identify their source, the time they were last modified, their update history, the identification of users with permission to modify them, and so forth.

Symbol Block

The symbol block structure is a fixed size structure used to store data item structures. If the data item to be stored is too large to fit in the memory allocated for data in a single symbol block, more than one symbol block is used. Each symbol block has an identifier, unique among symbol blocks, known as a “handle”. The handle of a symbol block is used to locate the block in the persistent storage managed by the server component. Data item symbol blocks contain references to other symbol blocks (the handle values) so that symbol blocks can be organized in “linked lists.” FIG. 3 shows the use of symbol blocks to store data item representations.

Also shown in FIG. 3 is a block pointer set to NONE. This is a special value that signifies that no block exists. The special value NONE, as will be seen, is used in a number of circumstances in the present invention software to signify that nothing is referenced by a link pointer.

A typical C++ definition for a class to represent a symbol is shown below:

class IWSymbol
{
public:
IWSymbol(void * data = NULL, int dsize = 0);
virtual ~IWSymbol( );
inline void setAVLID(unsigned long id) {m_pBlock->m_AVLID =
id;};
inline unsigned long getAVLID( ) {return m_pBlock->m_AVLID;};
inline void setID(unsigned long id) {m_pBlock->m_id = id;};
inline unsigned long getID( ) { return m_pBlock->m_id;};
inline void setNextLineID(unsigned long id) {m_pBlock-
>m_nextLineID = id;};
inline unsigned long getNextLineID( ) {return m_pBlock-
>m_nextLineID;};
inline void setFirstLineID(unsigned long id) {m_pBlock-
>m_firstLineID = id;};
inline unsigned long getFirstLineID( ) {return m_pBlock-
>m_firstLineID;};
void setData(void* pdata, int dsize);
inline const char* getData( ){return m_pBlock->m_pData;};
inline int getSize( ){return m_pBlock->m_size;};
static int GetSymbolDataSize( );
inline int GetBlockCount( ){return m_pBlock->m_nBlocks;};
inline void SetBlockCount(int count){m_pBlock->m_nBlocks =
count;};
inline void * getSymbolBlockPointer( ) { return m_pBlock;};
static int getSymbolBlockSize( );
protected:
static void SetSymbolDataSize(int nsize);
private:
struct tagSymbolBlock
{
unsigned long m_AVLID;
unsigned long m_id;
unsigned long m_nextLineID;
unsigned long m_firstLineID;
unsigned long m_size;
int m_nBlocks;
char m_pData[1];
} * m_pBlock;
};

Member Functions

IWSymbol(void*data=NULL, int dsize=0);
virtual ˜IWSymbol( );

The constructor allocates memory for the struct tagSymbolBlock and puts its memory address in m_pBlock. The destructor deallocates the tagSymbolBlock memory.

inline void setAVLID(unsigned long id) {m_pBlock->m_AVLID=id;};
inline unsigned long getAVLID( ) {return m_pBlock->m_AVLID;};

The symbol blocks are also linked to another of the server component data structures, the AVL tree node, mentioned above and discussed in the next section. Each AVL tree node also has an identifier, unique among AVL tree nodes, also known as a “handle,” which is used to locate the node data structure in the persistent storage managed by the server component. These member functions are used to store and retrieve the handle of the AVL tree node that this symbol block is associated with.

inline void setID(unsigned long id) {m_pBlock->m_id=id;};
inline unsigned long getID( ) {return m_pBlock->m_id;};

These member functions are used to store and retrieve the handle of the symbol block.

inline int GetBlockCount( ){return m_pBlock->m_nBlocks;};
inline void SetBlockCount(int count){m_pBlock->m_nBlocks=count;};

These member functions are used to store and retrieve the handle of the total number of symbol blocks in a set of symbol blocks that are being used to store a data item.

inline void setFirsttLineID(unsigned long id) {m_pBlock->m_firstLineID=id;};
inline unsigned long getFirstLineID( ) {return m_pBlock->m_firstLineID;};

These member functions are used to store and retrieve the handle of the first symbol block in a sequence of symbol blocks that are being used to store a data item.

inline void setNextLineID(unsigned long id) {m_pBlock->m_nextLineID=id;};
inline unsigned long getNextLineID( ) {return m_pBlock->m_nextLineID;};

These member functions are used to store and retrieve the handle of the next symbol block in a sequence of symbol blocks that are being used to store a data item.

static int GetSymbolDataSize( );

This member function returns the maximum size of the segment of a data item that can be stored in a symbol block. Data item representations that are larger than this must be divided and stored in more than segmented and stored in more than one symbol block.

void setData(void* pdata, int dsize);

This member function is used to copy a segment of a data item representation into a symbol block. The memory location of the segment being copied is given by pdata, and size of the segment to be copied is given by dsize, which cannot be greater than the size returned by GetSymbolDataSize( );

inline const char* getdata( ){return m_pBlock->m_pData;};

This member function is used to retrieve the memory address of the data item storage region in the symbol block.

inline int getsize( ){return m_pBlock->m_size;};

This member function is used to retrieve the size of the memory region actually used to store the data item currently stored in this symbol block. This will be the same value given as dsize when the function setData(void* pdata, int dsize) was called to store the data segment in the symbol block.

inline void * getSymbolBlockPointer( ) {return m_pBlock;};

This member function is used to retrieve the address of the memory region allocated for the symbol block.

AVL Tree Node

Each data item has associated with it an AVL tree node structure. Each AVL node structure contains references to other AVL node structures. The set of AVL node structures associated with data items is organized as a “threaded AVL tree.” This is an AVL tree in which each node also contains links (the handle values) of the next AVL tree node and the previous node in the data item sort order that the tree implements. FIG. 4 shows a small threaded AVL tree with links to the symbol blocks that store the data item associated with each tree node.

Each AVL tree node that is associated with a data item is also associated with a frame data structure, mentioned above and discussed in the next section. Each frame structure also has an identifier, unique among frame structures, known as a “handle,” which is used to locate the frame structure in the persistent storage managed by the server component. A C++ language definition of the AVL tree node structure is shown below:

enum cmp_t {
MIN_CMP = −1,               // less than
EQ_CMP = 0,                 // equal to
MAX_CMP = 1                 // greater than
};
// AvlNode -- Class to implement an AVL Tree for IWSymbols
//
class AvlNode
{
public:
// ----- Constructors and destructors:
AvlNode( ) : m_io(NULL),m_stored_( ) { };
AvlNode(const AvlNode &);
AvlNode(IWDataItem &);
~AvlNode(void);
// Max number of subtrees per node
enum { MAX_SUBTREES = 2 };
// Indices into a subtree array
enum dir_t { LEFT = 0, RIGHT = 1 };
// Query attributes:
// Get this node's data item contents
IWDataItem & getDataItem( );
// Query the balance factor, it will be a value between −1 .. 1
// where:
//  −1 => left subtree is taller than right subtree
//  0 => left and right subtree are equal in height
//  1 => right subtree is taller than left subtree
short Bal(void) const { return m_stored.m_Bal; }
// Get the item at the top of the left/right subtree of this
// item (the result may be NULL if there is no such item).
//
unsigned long Subtree(dir_t dir) const { return
m_stored.m_SubTreeID[dir]; }
inline int decrementSymbolReferenceCount( )
{m_stored.m_referenceCount−−; return
m_stored.m_referenceCount;};
inline void
incrementSymbolReferenceCount( ){m_stored.m_referenceCount++;};
inline unsigned long getID( ) {return m_stored.m_id;};
inline void setID(const unsigned long id) {m_stored.m_id = id;};
inline unsigned long getSymbolNameID( ) {return
m_stored.m_SymID;};
inline void setSymbolNameID(const unsigned long id) {
m_stored.m_SymID = id;};
inline unsigned long getFrameID( ) {return m_stored.m_frameID;};
inline void setFrameID(const unsigned long id)
{m_stored.m_frameID = id;};
inline int getSymbolReferenceCount( ) {return
m_stored.m_referenceCount;};
inline void setSymbolReferenceCount(const int count)
{m_stored.m_referenceCount = count;};
inline unsigned long getNextNodeID( ) {return
m_stored.m_NextNodeID;};
inline void setNextNodeID(unsigned long id)
{m_stored.m_NextNodeID = id;};
inline unsigned long getLastNodeID( ) {return
m_stored.m_LastNodeID;};
inline void setLastNodeID(unsigned long id)
{m_stored.m_LastNodeID = id;};
// Perform a comparison of the given key string against the given
// item using the given criteria (min, max, or equivalence
// comparison). Returns:
//  EQ_CMP if the keys are equivalent
//  MIN_CMP if this key is less than the item's key
//  MAX_CMP if this key is greater than item's key
cmp_t Compare(const IWDataItem & data, cmp_t cmp=EQ_CMP, int
match_len = 0,
bool wildcards = false);
bool IsEmbeddedMatch(const IWDataItem & a, const IWDataItem &
sub);
private:
// ----- Private data
struct stored_node_t
{
unsigned long m_SubTreeID[MAX_SUBTREES];   // Subtree
handles
unsigned long m_id;         // Avl node handle
unsigned long m_SymID;      // Symbol block
handle
unsigned long m_frameID;    // Frame handle
unsigned long m_NextNodeID; // Handle of
next AvlNode
unsigned long m_LastNodeID; // Previous
AvlNode handle
int m_referenceCount;       // Reference count
short m_Bal;                // node balance factor
struct stored_node_t( ) :   m_id(NONE),
m_SymID(NONE),
m_frameID(NONE),
m_NextNodeID(NONE),
m_Bal(0)
{
m_SubTreeID[LEFT] = m_SubTreeID[RIGHT] =
NONE;
}
} m_stored;
// Reset all subtrees to null and clear the balance factor
inline void Reset(void) {
m_stored.m_Bal = 0 ;
m_stored.m_SubTreeID[LEFT] =
m_stored.m_SubTreeID[RIGHT]= NONE;
}
};

Member Functions

Av1Node( ): m_io(NULL),m_stored( ) { };

Constructs a new Av1Node instantiation that has no links to other structures.

Av1Node(const Av1Node & av1);

Constructs a new Av1Node instantiation that is a copy of the node av1.

Av1Node(IWDataItem & data);

Constructs a new Av1Node instantiation that has no links to other Av1Node structures, but that is linked to symbol blocks storing a representation of the data item data.

˜Av1Node(void);

This is the destructor for an Av1Node.

short Bal(void) const {return m_stored.m_Bal;}

This member function returns node's balance factor, which is the difference in height between the left and right sub-trees.

unsigned long Subtree(dir_t dir) const {return m_stored.m_SubTreeID[dir];}

This member function returns handle of the node on the left or right sub-tree specified by the argument dir.

IWDataItem & getDataItem( );

This member function returns a reference to the data item structure, if any, associated with this tree node.

inline int getSymbolReferenceCount( ) {return
m_stored.m_referenceCount;};
inline void setSymbolReferenceCount(const int count)
{m_stored.m_referenceCount = count;};
inline int decrementSymbolReferenceCount( )
{m_stored.m_referenceCount−−;
return m_stored.m_referenceCount;};
inline void
incrementSymbolReferenceCount( ){m_stored.m_referenceCount++;};

These member functions are used to store, to retrieve, to increment, and to decrement the value of m_reference Count, the number of frame structures and slot structures that are associated with the data item that corresponds to this tree node.

inline unsigned long getID( ) {return m_stored.m_id;};
inline void setID(const unsigned long id) {m_stored.m_id=id;};

These member functions are used to store and retrieve the handle of this node.

inline unsigned long getSymbolNameID( ) {return m_stored.m_SymID;};
inline void setSymbolNameID(const unsigned long id) {m_stored.m_SymID=id;};

These member functions are used to store and retrieve the handle of the first symbol block in the set of linked symbol blocks used to store the representation of the data item associated with this node.

inline unsigned long getFrameID( ) {return m_stored.m_frameID;};
inline void setFrameID(const unsigned long id) {m_stored.m_frameID=id;};

These member functions are used to store and retrieve the handle of the frame data structure associated with this node.

inline unsigned long getNextNodeID( ) {return m_stored.m_NextNodeID;};
inline void setNextNodeID(unsigned long id) {m_stored.m_NextNodeID=id;};

These member functions are used to store and retrieve the handle of the node that follows this in the order in which the data items are sorted,

inline unsigned long getLastNodeID( ) {return m_stored.m_LastNodeID;};
inline void setLastNodeID(unsigned long id) {m_stored.m_LastNodeID=id;};

These member functions are used to store and retrieve the handle of the node that precedes this in the order in which the data items are sorted,

cmp_t Compare(const IWDataItem & data, int match_len=0);

This member function is used to determine if the data item represented by data should precede, be at the same place, or follow in the sort order the data item associated with this node. The return value is an enumerated type that indicates which of the three possible outcomes the comparison found. The match_len, when non-zero, causes the comparison to use only a segment of the represented data in the comparison test. This usage corresponds to the usage of the match_len parameter in the data item member function Compare(const IWDataItem & a, const IWDataItem & b, int match_len) described previously.

In some cases, the result of the Compare function can be computed correctly without having retrieved the all the symbol blocks for a data item. Consequently, in some implementations, speed may be improved if the comparison procedure is executed to determine if a non-matching result is already certain after retrieval of each symbol block of a multi-block data item.

bool IsEmbeddedMatch(const IWDataItem & a, const IWDataItem & sub);

This member function is used to determine if the data item represented by is included in the data item associated with this node. This usage corresponds to the usage of data item member function IsEmbeddedMatch described previously.

Frame

Each data item has associated with it a frame structure. As mentioned previously, each frame structure also has an identifier, unique among frame structures, known as a “handle,” which is used to locate the frame structure in the persistent storage managed by the server component. Each frame structure also has one or more slot structures associated with it. Slot structures have been mentioned previously and will be described in more detail below. Slot structures also have handles that are unique among slot structures. The slot structures for a frame are joined in a linked list. Each frame structure has stored in it the number of its slots and the handle values of the first slot and last slot in its linked list of slots. This relationship between a frame and its slots is shown in FIG. 5. In addition, the ordering scheme for the slots in the linked list is a property of the frame. Each frame structure contains a value that specifies the ordering scheme for that frame's slots.

Although the slots are shown linked in a linked-list structure in FIG. 5, some applications may have very large numbers of slots and it may be desirable to link them in an alternative data structure, such as an AVL tree, to improve searching or sorting performance. In the case where the slots are linked in a tree structure, the frame structure would have a parameter that is the stored value of the handle of the route node of the frame's slot tree. The slot structures themselves would also have to be extended to include the necessary additional tree parameters.

The data members of a C++ definition for a frame class are shown below. IWDataOrder is an enumerated type whose elements correspond to sorting orders, the different ways that the application permits data items to be ordered—such as ascending alphabetical order, descending alphabetical order, numerical order, and so forth. The data item member function Compare is used to determine the relative order of two data items according to a particular sorting order.

Data Members
unsigned long	m_id;	// Handle of this Frame
unsigned long	m_SymbolTreeId;	// Handle of Symbol Tree node
naming this frame
unsigned long	m_slotFirst;	// Handle of the first slot of this
frame's slots
unsigned long	m_slotLast;	// Handle of the last slot of this
frame's slots
unsigned int	m_slotCount;	// Number of this frame's slots
IWDataOrder	m_slotOrder;	// Order scheme for the slots

Slot

Each slot structure may have one or more value structures associated with it. Value structures have been mentioned previously and will be described in more detail below. Value structures also have handles that are unique among value structures. The relationship between a slot and its value structures is shown in FIG. 6. The value structures for a slot are joined in a linked list. Each slot structure has stored in it the number of values it has and the handle values of the first value and last value in its linked list of value structures. Slots may also have no values, however. In this case, the value count is zero and the first and last value structure handles are set to NONE. The ordering scheme for the values in the linked list is a property of the slot and each slot structure has a parameter that specifies the ordering scheme for that slot's values.

Although the slot values are shown in FIG. 6 in a linked list, as mentioned for the slots in a frame, some applications may require the use of tree or other structures to efficiently manage large numbers of slot values. In these cases, the slot structure would be extended by the addition of a value tree root handle and the value structures would be extended by the addition of the necessary tree link parameters.

Slot structures are part of the mechanism used to characterize the relationship between data items. Slot structures may themselves also be associated with data items, depending on the slot's type. To see how slots are used to characterize relationships between data items, consider the example relationship mentioned previously: John's birthplace is Philadelphia.

For this case, the server creates three data item structures : John, birthplace, and Philadelphia. The relationship is represented by creating two frames, one linked to the data item for John and the other linked to the data item for Philadelphia, and giving the John frame a slot linked to the data item for birthplace. As the next section will describe, the slot will be given a value structure that links it to the frame for Philadelphia.

Slot Type

To use this same mechanism to characterize the relation Philadelphia is the birthplace of John, slots are given a “type” to specify the kind of relation they are being used to represent. The slot type employed for the relation John's birthplace is Philadelphia is called an “instance is” slot and the slot type used for the relation Philadelphia is the birthplace of John is called an “instance of” type slot. Both of these slot types always have associated data items, in this case, the data item for birthplace. John is a person is a relation that is represented using a slot type without an associated data item. The slot type used is called an “is a type of” slot. The slot types used by the server component to represent relationships are shown in Table 1.

TABLE 1
List of slot types.
		Data
	Slot	item	Example of relation the slot
	Types	associated	type is used to represent
	Instance	Yes	John's phone number is 555-
	is		1212
	Instances	Yes	John's friends are Karen and
	are		Tom
	Instance	Yes	Tom is a friend of John's
	of
	Transitive	Yes	Allen knows Tom.
	Commutative	Yes	Tom's spouse is Karen
	Pair	Yes	Tom's wife is Karen
			Karen's husband is Tom
	Type is	No	Phone number entries include
			555-1212
	Is a	No	555-1212 is a phone number
	type of
	Is an	No	John has a phone number
	attribute of

The first four slot types shown in Table 1 are used to represent a relation between a pair of data items that is named by a third data item associated with the slot. The instance is and instances are slot types have similar roles and are only different to signal client programs to present the relation to the user so that the number of the verb agrees with the number of the subject in an English language sentence. Additional slot types can be defined to improve data presentation in non-English applications. The instance of type is used to represent a relation between a pair of data items that can be derived from an instance is relation by exchanging the roles of the two items. Where John's phone number is 555-1212 is represented with an instance is slot associated with the data item phone number, 555-1212 is the phone number of John is represented using an instance of slot associated with the data item phone number. Commutative slot types are similar to instance is and instance of slot types, but are used when the binary relation being presented is necessarily true if the two data items are exchanged. As shown in the Table 1, if Tom's spouse is Karen, then Karen's spouse is Tom and this relationship can be represented by using a commutative type slot associated with a data item for spouse. Paired slot types are like commutative, except that the second relationship has a different name. For example, “wife” and “husband” are a pair of relationships that might be represented by paired type slots. The usefulness of paired type slots is that a look-up table can be used to derive the data item for the slot for the relationship that has the subject and the object reversed. The role of transitive slot type is again similar to the role of the pair slot type and differs only to signal client programs to present the relation to the user without using the verb “is” so that the data item of the slot appears as a transitive verb. Transitive slots, like pair type slots, generally use a different slot data item in the relation that exchanges the subject and the object (e.g.: knows and is known by). Again, the client or a look-up table can be used to find the data item for the slot for the reverse relationship.

The is a type of slot type is used to indicate that one data item represents something that is a member of a set represented by another data item, as in Denver is a city. The type is slot type is used to represent the opposite relationship, where a set represented by one data item includes something represented by another data item, as in cities include Denver. The is an attribute of slot type is used to represent the relation between a data item that names a binary relationship and the data item that corresponds to one of two objects participating in the relationship. For example, the is an attribute of slot type would be used to represent the relation age is an attribute of Tom.

Finally, all slots that the server component manages are joined in a single linked list. As mentioned previously, slots are associated with data attributes and it is often useful to be able to determine what attribute descriptions are in use. This linked list is used to locate all the slots managed by the server to retrieve the set of all attributes. In applications where it is useful to be able to quickly access all of the stored slot data structures, the slots can be organized in a tree or other structure, rather than a linked list, so the set of the attribute descriptions in use can be quickly retrieved.

The relationship between slots and their values is shown in FIG. 7.

The slot types represent forms of information recognizable by the system from which other forms (slot types) of the information can be derived.

The data members from a C++ definition for a slot class are shown below:

The IWDataOrder type is an enumerated type whose elements correspond to the different ways that the application permits data items to be ordered, such as ascending alphabetical order, descending alphabetical order, numerical order, and so forth. The data item member function Compare is used to determine the relative order of two data items according to a particular sort order. The IWSlotType type is an enumerated type that has an element corresponding to each of different slot implemented in the server component.

Data Members
unsigned long	m_id;	// Slot's Handle
unsigned long	m_SymbolTreeID;	// Handle of symbol tree object
for this slot
IWSlotType m_type;	// Slot type
unsigned long	m_slotNext;	// Handle of next slot in the frame's
slot list
unsigned long	m_valueFirst;	// Handle of the first value in the
slot's value list
unsigned long	m_valueLast;	// Handle of the last value in the
slot's value list
unsigned long	m_valueCount;	// Count of values
unsigned long	m_slotFlink;	// Handle of the next slot on the
linked list
unsigned long	m_slotBlink;	// Handle of the previous slot on the
linked list unsigned long	m_parentFrameID;	// Handle of the slot's
parent frame
IWDataOrder m_valueOrder; // Storage order scheme for this slot's values

Value

Value structures are used to link slots to the frame associated with the second data item participating in the slot's binary relationship. This relationship is shown in FIG. 8. Each value structure contains the handle of a single frame structure. As mentioned previously, each value structure also has an identifier, unique among value structures, known as a “handle,” which is used to locate the value structure in the persistent storage managed by the server component.

The data members from a C++ definition for a value class are described below:

Data Members

unsigned long m_id;

This member is the handle of the value structure.

unsigned long m_parentSlotID;

This member is the handle of the value structure's parent slot.

unsigned long m_nextValueID;

This member is the handle of next value structure in the parent slot's value list.

unsigned long m_frameID;

This member is the handle of the frame associated with this value structure.

Storing Data

An important role of the server component is to manage the storage and retrieval of the data structures used to represent data items and data item relationships in a persistent medium. Typically the data structures are stored in the computer's file system on a disk drive. Alternative storage scenarios include storage in a battery-powered memory system, storage on magnetic tape, and storage on optical disks or CD-ROM. In some applications, the data may be supplied to the user in a read-only format, such as CD-ROM, and the server manages only the retrieval of data structures.

If the server component is implemented on a computer with a file system for persistent storage, the server component would typically employ the computer's file system software to read and write the data structures to persistent files.

Generally, the computer and associated file system cannot be guaranteed never to sustain a power, software, hardware, network or other failure that would cause transactions in progress to terminate abruptly. To prevent this from leaving the server database corrupted to an extent that the correct data structures cannot be retrieved, the server must employ techniques to guarantee the standard “ACID” database properties. The ACID acronym denotes the properties of

Atomicity

Consistency

Isolation

Durability

File Interface

In a typical application, the server component uses the computer's file system software to store and retrieve the five types of structures: symbol blocks, AVL nodes, frames, slots, and values. Each of these data structures has a fixed size so they can be efficiently stored in five different files, or in five different sections of a compound file in fixed-size segments. Each of the data structures has an identifying handle, which can be the index number of its segment in the storage file. If it is convenient, several different structure types can also be combined in a single file or single section of a compound file if the storage segment size is set large enough to hold the largest of the structures sharing the file.

In many applications using the server, the same data structures will often be stored and retrieved several times in a short time interval. To improve the server's performance in this situation, “caching” software is employed, which maintains a copy in memory of data structures that have been recently stored in or retrieved from the persistent storage system. The cache system stores data structures in memory blocks indexed by the structures' identification handles.

Inserting Data

To understand the data storage functions of the server component, it is useful to begin with the method for simply storing three data items that represent a binary relation, such as John's age is 30. The data insertion procedure for the relation will result in storage of a set of data structures linked in the relationship shown in FIG. 7. A client component or some other program will send the server three data structures called “insertion structures” containing the information necessary to construct the three data items for John, age, and 30 and the frame structures, slot structure, and value structure that represent the relationship between the data items.

An insertion structure must contain the information of a data item structure and additional information specifying what role the data item it represents plays in the relation representation being constructed. The additional information must include the type of slot to construct if the insertion structure describes a slot. The additional information for slot and value insertions may also include the position the new slot or value will take in the slot linked-list of a frame or the value linked-list of a slot structure.

In the preferred embodiment, insertion structures are implemented as a C++ language class derived from the data item class. Thus the insertion item class has all the information of the data item class and the additional information given by the insertion item class data members shown in Table 2.

TABLE 2
Insertion item class data members.
Member
Name	Type	Description
m_slotType;	IWSlotType	Slot type indicator. This
		must have a value that signifies
		one of the slot types, such as
		instance is, implemented in the
		server component
m_siblingID;	unsigned	Handle of sibling item to
	long	insert next to
m_parentID;	unsigned	Handle of parent item
	long
m_bBefore;	bool	True if item precedes
		sibling
m_srcItemID;	unsigned	Temporary item handle
	long	supplied by source

In the preferred embodiment of the server component, the insertion items are delivered as arguments to a subroutine. Which insertion item refers to the frame, slot or value to be created is understood from subroutine's argument order.

The very first step to inserting data is to notify the cache system that an atomic transaction is beginning.

Then, starting with the insertion item for what will become the frame for John in the relation John's age is 30, the first step is to determine if the data item is already stored in the symbol blocks of the database. This is accomplished by using an AVL tree search algorithm to search the symbol blocks pointed to by the AVL tree node structures stored in persistent storage.

Step 1. Retrieve the AVL Tree Root Node.

The AVL tree search begins by reading the handle of the root node of the database's AVL tree from a designated fixed location in the database's persistent storage. The root AVL node structure is then retrieved from persistent storage. The symbol block designated by the symbol block handle, m_SymID mentioned previously, from the retrieved node is then retrieved.

Step 2. Retrieve the Data Item from the Symbol Blocks Designated by the Current AVL Tree Node.

If the data item corresponding to the retrieved AVL node occupies more than a single symbol block, the symbol block's m_nBlocks data member will be greater than 1 and the m_nextLineID data member will be an actual handle rather than the special designated value NONE. The program continues to retrieve stored symbol blocks designated by the previously retrieved symbol block's m_nextLineID data member until the number of symbol blocks retrieved is the number in the m_nBlocks data member of the first block. The data stored in storage regions of the symbol blocks is concatenated in memory to construct the data item structure stored in the set of symbol blocks.

Step 3. Compare the Retrieved Data Item with the Data Item being Searched for.

The data item Compare member function is used to compare the retrieved data item with the data item being searched for.

If the two match, the data item has been located in persistent storage and the search is finished. The AVL tree node for the data item that has been located contains the handle of the frame for the data item. Because the frame already exists, a new frame will not be created. The next step in data insertion for this example is constructing the slot information for the slot associated with the data item for age.

Step 4. If No Match, Retrieve a Sub-Tree Node that Becomes the Current Node.

If the data items do not match, the AVL tree node from the left or right branch of the current node is retrieved. The choice of left or right sub-tree is determined by the result of the comparison. The data item being searched for either precedes or follows the retrieved data item in the AVL tree's sorting order. The return value of the Compare function indicates which is the case. The left or right sub-tree node is selected, depending on whether the tree is ordered left-to-right or right-to-left. The sub-tree node handles are in the AVL node data structure. The appropriate node is retrieved and becomes the current node. The steps above are repeated, starting from Step 2, until the data item is found or until there is no sub-tree node to be retrieved after a comparison. This is indicated by the presence of special value NONE as the sub-tree node handle.

Frame Creation

If the data item has not been located in the persistent storage, a frame for it does not exist and a new frame must be created. This process begins with the construction of an AVL tree node for the data item and storage of the data item in symbol blocks.

Persistent Storage Structure

The logical organization of persistent storage for the fixed-size storage segments used to store the data structures managed by the invention is shown schematically in FIG. 8.

A special segment in persistent storage is used to store two numbers:

• 1. The handle, or index number, of the last persistent storage segment in use.
• 2. The handle of an unused segment that exists in the persistent storage before the last used segment, if one exists. Free segments before the last used segment are members of a linked list. Each segment contains the handle of the next segment on the list. The last segment on the list has the special value NONE for the handle of the next segment. If there are no free segments before the last used segment, the free-segment handle stored in the special segment is set to the value NONE.

When segments are freed, they are usually added to the free-segment linked list and the total number of persistent storage segments used for storage is not reduced.

When a storage segment is needed, the first free segment, if any, on the free-segment list is used. The free segment handle in the special segment is then set to point to the next free segment on the free-segment linked list. The handle of this segment is retrieved from the newly assigned segment. If there are no free segments on the free-segment list, the next segment after the last-used segment is used. The last-used segment handle in the special segment is then increased by 1.

Frame and AVL Tree Node Handles

The first step in frame creation is to get a handle for the new frame and the AVL Tree node associated with it. This is done by having the cache system take a frame handle from the frame persistent storage free list or, if that is empty, increase the persistent storage size and take the handle of an added storage segment. A new tree node handle is taken from the AVL node persistent storage free list or, if that is empty, the persistent storage size is similarly extended and the handle of an added storage segment is used

Data Item Storage

To store a new data item in symbol blocks, the first step is to determine the amount of memory occupied by the data item structure. This size is compared to the size of the data storage region in a symbol block structure to determine m_nBlocks, the number of symbol blocks needed to store the data item. Handles for free symbol blocks are removed by the caching system from the symbol persistent storage free list or, if that is empty, the persistent storage size is extended and the handles of the added segments are used for the required new symbol blocks.

The set of symbol structures to be used to store the data item is constructed in memory. The m_id handle values of the symbol block structures are set to the handle values acquired from persistent storage. The data item structure is divided into segments that fit into a symbol block. One symbol block is chosen as the first block. The data item segments are copied into the symbol block storage regions, starting with the first block. Each time a data segment is copied into a symbol block, the m_size value for the symbol block is set to the size of the segment copied into the block. The m_AVLID value of the first block is set to the new AVL node handle that has been acquired. The m_firstLineID values of all the blocks are set to the handle of the first symbol block. Another block is selected as the second block. The m_nextLineID value of the first block is set to the handle of the second block and the second data item segment is copied into the data region of the second block. This process is repeated until all the data segments have been copied into symbol block structures. The segments are copied into the symbol block structures in memory. The m_nextLineID value for the last symbol block is set to NONE. Each of the symbol block structures in memory is now sent to the cache software to be transacted to the to the persistent storage segment identified by the blocks m_id handle.

AVL Tree Node Storage

To store an AVL tree node, the node structure is first constructed in memory. The node's handle m_id is set to the new AVL node handle that has been acquired. The node's frame handle m_frameID is set to the newly acquired frame handle and the node's symbol block handle m_SymID is set to the handle of the first symbol block used to store the data item. The node's reference count m_referenceCount is set to 1 for the frame being created.

Five parameters are determined by the node's position in the AVL tree that is stored in persistent storage. These are the left and right sub-tree handles, the next node and previous node handles for the thread that runs through the tree, and the balance factor for the node, which is the difference in height between the left and right sub-trees. These five parameters are determined by the AVL tree node insertion procedure. The well-known procedure is to search the tree for the data item being inserted and then to proceed up the tree along the search path just traveled, adjusting the node balance factors and the tree handle and thread handle values. In this procedure, the tree is searched by retrieving AVL nodes and their data items from persistent storage. The data item Compare function is used to determine if the retrieved items precede or follow the new data item in the tree sorting order.

When the insertion procedure has determined the five tree parameters for the new node, their values are set in the memory copy of the node and the node is copied to the cache system for transaction to the segment that corresponds to its handle in persistent storage. Other nodes that have been retrieved and adjusted according to the insertion procedure are also sent to the cache system for transaction back to persistent storage

Frame Item Storage

The frame item structure is first constructed in memory. The frame's handle value m_id is set to the newly acquired handle. The frame's AVL tree node handle m_SymbolTreeID is set to the handle of the new AVL node. Initially, the frame has no slots, so its slot count m_slotCount is set to 0 and first and last slot handles, m_slotFirst and m_slotLast, are set to the special value NONE. If the insertion instructions for this frame include a slot order, then the slot order parameter m_slotOrder is set appropriately. When the frame structure's values have been set, the structure is copied to the cache system for transaction to the persistent storage segment designated by its m_id handle.

Slot Item Storage

The first step in slot construction is to acquire a new persistent storage handle for a slot structure. If the slot is type being constructed has an associated data item, then if the data item and its AVL node are not already in persistent storage, they must be created and inserted in persistent storage. The procedure for this is the same as the procedure described above for a frame's data item and AVL node, except that the AVL node's m_frameID parameter is set to NONE.

If the data item has been previously put into persistent storage, then searching the stored AVL tree will locate it. The AVL node for the data item is then retrieved from persistent storage and its m_referenceCount value is increased by 1. The AVL node structure is then copied back to its segment in persistent storage.

The slot item structure is first constructed in memory. The slot's handle value m_id is set to the newly acquired slot persistent storage handle. The slot's type parameter m_type is set to the slot type taken from the slot insertion structure. If the slot is associated with a data item, the slot's AVL tree node handle m_SymbolTreeID is set to the handle of the data item's AVL node. The slot's parent frame handle value m_parentFrameID is set to the handle of the slot's parent frame.

To insert the slot in the parent frame, the parent frame structure is retrieved from persistent storage. If the frame has no slots, then its m_slotFirst and m_slotLast values are set to the handle of the slot being created. If the frame has slots and the insertion item parameter m_siblingID for the slot being created is not NONE, then the new slot is to be placed in a particular position in the frame's slot list. This is accomplished by retrieving the frame's slot structures from persistent storage, beginning with the slot with handle given by the frame's m_slotFirst parameter. The next slot in the list is the slot with handle given by the just-retrieved slot's m_slotNext parameter. Slots are retrieved until the slot having the handle specified by the insertion structure's m_siblingID parameter is retrieved. If the insertion item parameter m_bBefore is true, the slot being created precedes the slot with handle m_siblingID, otherwise, it follows it. If the created slot precedes, its m_slotNext parameter is set to the value of m_siblingID and if there was a previously retrieved slot, its m_slotNext parameter is set to the handle of the slot being created. If there was no previously retrieved slot, the new slot is the frame's first slot and the frame's m_slotFirst parameter is set to the handle of the new slot.

If the insertion item parameter m_bBefore is false, the slot being created follows the slot with handle m_siblingID. The m_slotNext parameter of the m_siblingID slot is set to the handle of the newly created slot. If the created slot is last, its m_slotNext parameter is set to NONE and the frame's m_slotLast parameter is set to the handle of the newly created slot.

If the insertion structure's m_siblingID parameter is NONE, then the new slot is inserted in the frame's linked list of slots according to the frame's default sort order, which is designated by the frame's m_slotOrder parameter. In this case the insertion procedure is to retrieve the frame's slots from persistent storage, retrieve the associated data items, if any, and use the data item Compare member function to determine the correct position for the new slot in the frame's link list of slots.

To conclude the insertion of a slot into a frame, the frame's slot count m_slotCount is increased by 1 and then the frame and any slot structures that have been retrieved and modified are copied to the cache system for eventual transaction back to their respective segments in persistent storage.

Initially, the new slot has no values, so its value count m_valueCount is set to 0 and first and last value handles, m_valueFirst and m_valueLast, are set to the special value NONE. If the insertion instructions for this slot include a value order, then the value order parameter m_valueOrder is set appropriately. The final step in slot creation is to set the links to insert the slot in the database's linked list of all slots. This is done by first retrieving from the cache system the first slot handle from slot list-head segment in persistent storage. If no slots exist in persistent storage, this parameter will be NONE. If the parameter is not NONE, it is a slot handle and the slot it designates is retrieved from persistent storage. The m_slotBlink parameter of the newly created slot is set to NONE and the m_slotFlink parameter of the new slot is set to the value that was stored in the slot list-head. The slot list-head segment of persistent storage is set by the cache system to the handle of the newly created slot. The slot structure that was designated by the slot list-head has its m_slotBlink parameter set to the handle of the newly created slot and is then copied to the cache system for transaction into its segment in persistent storage.

When creation of the new slot structure in memory is finished, the structure is copied to the cache system for transaction into the persistent storage segment designated by its m_id handle.

Value Item Storage

The first step in value construction is to acquire a new persistent storage handle for a value structure. Each value structure is associated with a frame. The frame is a frame for the value's data item. If a frame for the value's data item already exists, it is located by searching the AVL tree and taking the m_frameID value from the data item's AVL node as the frame's handle.

If the data item has not been previously put into persistent storage, then it is sent to the cache system storage, a new AVL node is created and sent to the cache and a frame is created as described above in the section on frame item storage.

The value item structure is first constructed in memory. The value structure's handle m_id is set to the newly acquired persistent storage handle. The value's parent slot handle value m_parentSlotID is set to the handle of the value's parent slot.

The procedure to insert a value in a parent slot is similar to the procedure used to insert a slot in a parent frame. The parent slot structure is first retrieved. If the slot has no values, then its m_valueFirst and m_valueLast parameters are set to the handle of the value being created. If the slot has values and the insertion item parameter m_siblingID for the value being created is not NONE, then the new value is placed in particular position in the slot's value list. This is accomplished by retrieving the slot's value structures from persistent storage, beginning with the value with handle given by the slot's m_valueFirst parameter. The next value in the list is the value with handle given by the just-retrieved value's m_valueNext parameter. Values are retrieved until the value structure having the handle specified by the insertion structure's m_siblingID parameter is retrieved. If the insertion item parameter m_bBefore is true, the value being created precedes the value with handle m_siblingID, otherwise, it follows it. If the created value precedes, its m_valueNext parameter is set to m_siblingID and if there was a previously retrieved value, its m_valueNext parameter is set to the handle of the value being created. If there was no previously retrieved value, the new value is the slot's first value and the slot's m_valueFirst parameter is set to the handle of the new value.

If the insertion item parameter m_bBefore is false, the value being created follows the value with handle m_siblingID. The m_valueNext parameter of the m_siblingID value is set to the handle of the newly created value. If the created value is last, its m_valueNext parameter is set to NONE and the slot's m_valueLast parameter is set to the handle of the newly created value.

If the insertion structure's m_siblingID parameter is NONE, then the new value is inserted in the slot's linked list of values according to the slot's default sort order, which is designated by the slot's m_valueOrder parameter. In this case, the insertion procedure is to retrieve the slot's values from persistent storage, retrieve the associated frame, and then the data item designated by the frame. The data item Compare member function is then used to determine the correct position for the new value in the slot's linked list of values.

To conclude the insertion of a value into a slot, the slot's value count m_valueCount is increased by 1 and then the slot and any value structures that have been retrieved and modified are copied to the cache. The creation of the new value structure in memory is now finished and the structure is copied to the cache segment designated by its m_id handle.

This completes the construction of the set of frame, slot, AVL node, and symbol block structures to store the example relation John's age is 30. If no additional data were to be stored to service this client request, cache software system would be instructed to commit the created and altered structures to persistent storage. As will be described below the server must typically store several relations to service a data insertion request, however. When this is the case all the storage modifications necessary to service the request are typically committed at once rather than relation by relation.

Insertion into Known Slots and Frames

The foregoing section has described the creation of a new frame, slot, and value combination. When a new slot is to be added to a known frame, the frame handle is provided to the server by the client component. Similarly, when a new value is to be added to a known slot, the slot's handle is provided for the server in the insertion item structure by the client component.

Inserting Implications

When a new representation of a relation is stored, the server component also stores representations of what are called “implied” relations. Implied relations are deduced from the original relation that is being inserted.

For example, if the originally inserted relation is John's Birthplace is Philadelphia, then the following are implied relations:

• • Philadelphia is the birthplace of John
  • Birthplace is an attribute of John
  • Philadelphia is a Birthplace
  • Birthplace entries include Philadelphia

Representations of these relations are stored by the server in response to the instruction to add the relation John's Birthplace is Philadelphia.

The server uses the slot insertion item's slot type to determine what implied relations will be created and stored. Table 3 shows the frame, slot, and value structure combinations that the server recognizes, generates and stores for the primary relation and its implications for different slot types. The numbers 1, 2, and 3 in the table indicate which data item is associated with the frame, slot, or value structure created for the relation when the server is given insertion items describing a frame data item (1), a slot data item (2) and slot type, and a value data item (3). The first combination for each slot type is the representation of the primary information (relation) from the insertion item set delivered to the server. The combinations that follow are the implications that are also created and stored.

Some entries indicate the use of a fourth data item (4). The fourth data item is used for the slot when the primary relation is represented by a Transitive or Pair type slot. An example is the primary relation Jane's husband is Bill, which can be presented with a pair type slot having the implication Bill's wife is Jane. Depending on the application, the auxiliary data item for wife can be delivered to the server by the client component or the server can use a previously loaded lookup-table of data item pairs to generate the fourth data item for the wife slot. The situation is similar for Transitive slots, such as would be used for Jack knows biology. The reverse relation, Biology is known by Jack requires a data item for is known by, which can received from the client component or generated by the server from a predefined lookup table.

The last row in the table indicates that the implication of a relation such as Age is an attribute of Tom is the relation Tom's age is unknown. The server component represents the age is unknown relation by a slot, for age, that has no value items attached to it.

TABLE 3
Server actions to store implied relations.
	Frame		Slot	Value
Insertion Slot	Data		Data	Data
Type	Item	Slot Type	Item	Item
Instance is	1	Instance is	2	3
Instances are		Instances are
	3	Instance of	2	1
	2	Type is	None	3
	3	Is a type of	None	2
	2	Is an attribute of	None	1
Instance of	1	Instance of	2	3
	3	Instance is	2	1
	2	Type is	None	1
	1	Is a type of	None	2
	2	Is an attribute of	None	3
Commutative	1	Commutative	2	3
	3	Commutative	2	1
	2	Type is	None	3
	3	Is a type of	None	2
	2	Is an attribute of	None	1
	2	Is an attribute of	None	3
Pair	1	Pair	2	3
	3	Pair	4	1
	2	Type is	None	3
	4	Type is	None	1
	4	Is an attribute of	None	3
	3	Is a type of	None	2
	2	Is an attribute of	None	1
Transitive	1	Pair	2	3
	3	Pair	4	1
	2	Type is	None	3
	4	Type is	None	1
	4	Is an attribute of	None	3
	3	Is a type of	None	2
	2	Is an attribute of	None	1
Type is	1	Type is	None	3
	3	Is a type of	None	1
Is a type of	1	Is a type of	None	3
	3	Type is	None	1
Is an attribute of	1	Is an attribute of	None	3
	3	Instance is	1	None

Inserting Inherited Information

In addition to the implications described above, when new information (a representation of a relation) is stored, the server component stores representations of what are called “inherited” relations. Inherited relations are deduced by combining the new relation and its implied relations with relations that are already stored in the server's persistent storage.

For example, suppose that the relation cheese is a dairy product has been previously stored by the server and that the new relation to be entered is Swiss cheese is a cheese. Swiss cheese inherits the is a dairy product relation from cheese so the server creates and stores the relation Swiss cheese is a dairy product.

As with implications, the server uses the slot insertion item's slot type to determine what implied relations will be created and stored. Table 4 shows the actions taken to store the inherited consequences of each of the different slot types.

TABLE 4
Server actions to store inherited relations.
Type of New Slot   Server Actions
Instance is        If the frame exists and has
Instances are      Type is slot, then the new slot and
Instance of        its value are also added to every
Transitive         frame that is linked through a
Commutative        value structure to the Type is slot.
Pair
Is a type of       Locate the frame linked to
                   the value structure and add every
                   Instance is slot with its values from
                   that frame to the new frame. For
                   each addition, also create and store
                   all the implied relationships.
Type is            Locate the frame linked to
                   the value structure and add to that
                   frame every Instance is slot of the
                   new frame with its values. For
                   each addition, also create and store
                   all the implied relationships.
Is an attribute of Create an Instance is slot
                   from the data item associated with
                   then new frame and add it to every
                   frame linked by a value structure
                   to the Is an attribute of slot. For
                   each addition, also create and store
                   all the implied relationships.

Circular References

Circular references are permitted in relations stored by the server. When the server is storing inherited is a type of and type is relations, it searches the tree formed by frames connected by these slot types to determine if the relationship to be inserted already exists. This simply prevents the server from looping forever as a consequence of requests to store two relations such as A is a B and B is an A.

Synonyms

Under certain circumstances, a user may need to repeatedly access the same frame. A “to-do list” frame is an example of a frame that might be frequently accessed. Frame synonyms provide a short-cut method of accessing a particular frame. A frame synonym is simply an alternative, usually short and easy-to-remember, name for a frame. When search text is entered that is recognized as a synonym, the actual frame name replaces the search text and an exact-match search is performed. The available or frequently used frame synonyms may be displayed in a drop-down list by the user interface for easy access. Multiple synonyms may be assigned to the same frame if desired. The use of synonyms can greatly facilitate access to frequently needed information.

Many implementations of frame synonyms are possible. The synonym list may be managed on the client, if client-specific synonyms are desired. In this case, the translation from synonym to frame name is performed by the client and the server is unaware of the existence of the synonym. Alternatively, synonyms may be placed in a so-called “synonyms are” type slot and managed by the server. In this case, the same synonyms can be made available to all users. Care must be taken in the server software not to perform synonym translation except on the initial search text provided from a client. When expanding a synonyms are slot, for example, the actual synonym should be displayed, not the name of the frame represented by the synonym.

Retrieving Information

The server provides two basic mechanisms to send information to a client: returning search results and responding to requests for frame or slot expansions.

Searches

In the present invention, the user (including accessing software) need not have knowledge of or have access to the structure of the stored data in order to begin a search. In contrast, with a relational database, the user or accessing software must know or discover what tables exist and what the names of the columns of interest in each table are before a query can be formulated. Queries not referencing the database structure correctly are rejected by the relational database system. No such prior knowledge of the content or structure of data space to be searched is required in the present invention.

Once a search returns an element from the database in the present invention, the user (including accessing software) is able to use the returned element as the starting point for further examination of the data space by following (browsing) the connecting relationships in the frame system between the returned element and related elements resident in the database. Again, this exploration is allowed without prior knowledge of what relationships may exist. By contrast, to perform further explorations after an initial query in a prior art relational database requires the formulation of yet another query, requiring the same degree of foreknowledge of the relational structure as did the first.

The server component of the present invention performs the search of the data items that have been stored in persistent storage. To initiate a search, the client sends a search command to the server with a specification of the search type and a data item that describes the search target.

Searches are performed by comparing the supplied target data item with items retrieved from the server's persistent storage. In the preferred embodiment, the server can perform the following types of comparisons between the retrieved data items and the target data item:

• 1. Find items that exactly match the target item.
• 2. Find items that match the target item for the length of the target item. Given a target item of ab, this type of search would return all the data items beginning with the character string “ab”—such as able, abcess, and abercrombie.
• 3. Find items that include the target item. Given a target item of ab, this type of search would return all the data items in which the character string “ab” appears—such as able, dabble, and crab.
• 4. Find items that match a target item that is defined using “wildcards.” If a wildcard “*” is defined such that * matches any length string of any characters, then a search for a target data item ab*c would return items such as abercrombie, but not able.

The server returns the set of frame structures associated with the matching data items in response to a search request.

Different search procedures are employed for included targets than for the other three target types.

The search for a target item that is included in another item is carried out as follows:

• • Step 1. Starting with the root node of the AVL tree, descend the right sub-tree by retrieving right sub-tree nodes until the bottom of the tree is reached. This bottom node becomes the “current node.” Note that in some implementations, this step may be replaced by simply having stored the handle of the bottom right node. The purpose of this step is to get the handle of the node at one end of the thread that runs through the threaded AVL tree. The other end of the thread could be found by descending from the tree root through left sub-trees. Since the procedure to find included items is to follow the thread from one end to the other, it can begin from either end of the thread.
  • Step 2. Retrieve the data item associated with the current node. Using the data item IsEmbeddedMatch function, test if the target data item is included in the retrieved data item. If the target data item is included, retrieve the frame whose handle is designated by the current node m_frameID. The retrieved frame item and data item are used to construct a message that is sent to the client component that requested the search. A new AVL node is then retrieved, whose handle is designated by the current node's m_NextNodeID value. This node becomes the current node and this step is repeated until the current node's m_NextNodeID is NONE.

In some embodiments, the client requesting the search will designate the handle of the AVL tree node where the search is to begin. In those cases, Step 1 of the procedure above is eliminated. Also in some embodiments, the client's search request specifies a limit on the number of data items or on the data volume that the search is to return. In these cases, the server maintains a running count of the number of data items or of the data volume and terminates the search when the client's limit is reached. The client can resume the search with another request that specifies the starting node handle for the search.

The search for a target item that is not included in another item is carried out as follows:

• • Step 1. Beginning with the root node of the AVL tree, follow the procedure described in the previous Inserting Data section. In that procedure, AVL nodes are retrieved and the data item Compare function is used to compare the retrieved item with the target item. The return value of the Compare function is used to determine which sub-tree to descend for the next AVL node retrieval. If no matching nodes are found in the tree, the search is terminated.
  • Step 2. The first matching node found is designated as the current node. If a matching node is found, it may not be the only one in the tree. To return the matching data items to the client in the tree sort-order, the AVL thread is followed from the current node by retrieving the node whose handle is given by the current node's m_LastNodeID. The data item Compare function is used to test if the retrieved node matches the target data item. If it does, the retrieved node becomes the current node. This step is repeated until the retrieved node does not match the target.
  • Step 3. Now, similar to step 2 of the included search procedure described above, the search follows the thread back from the current node, testing retrieved data items and sending matching data items with their handles back to the client. This is done by retrieving the data item associated with the current node. The data item Compare function is used to test if the retrieved data item satisfies the match criteria with the target data item. If there is a match, the frame having the handle designated by the current node's m_frameID is retrieved and the frame item and data item are used to construct a message that is sent to the client component that requested the search. A new AVL node is then retrieved, whose handle is designated by the current node's m_NextNodeID value. This node becomes the current node and this step is repeated until the current node's m_NextNodeID is NONE or until the target data item and match criteria are such that no matching node can exist following the retrieved node in the AVL tree sort order.
  • Once search results are reported, further exploration of the stored data items is conducted by browsing the frame structure to locate related data items. Thus, the frame structure is used to easily store data, the data is searched independent of the frame structure to locate target data and the frame structure is again used to locate data related to the target data.

Frame Expansion

Clients can request that the server send them information describing the slots of a frame. In response to such a request, the server retrieves the frame structure for the designated frame from persistent storage. Slots are then retrieved from persistent storage, starting with the slot with handle given by the frame's m_slotFirst value. If the slot is a type that has an associated data item, the AVL node associated with this slot, designated by the slot's m_SymbolTreeID parameter, is retrieved. Then the slot's data item is retrieved, as described previously, starting with the symbol block designated by the AVL node's m_SymID parameter. The slot information and data item are then used to construct a message describing the slot that is sent to the client component.

After the first slot is retrieved and the message dispatched to the client, the next slot handle is given by the m_slotNext parameter of the current slot. This new slot is retrieved and the associated data item, if any, is again retrieved to construct another slot description message that is dispatched to the client. This is repeated until descriptions of all of the frame's slots have been dispatched to the requesting client. As with searches, in some implementations, the client's request may include a starting slot handle or limitations on the number of items or the data volume that can be returned.

Slot Expansion

Clients can also request that the server send them information describing the values of a slot. This request is satisfied with a procedure that is very similar to that used for sending the slots of a frame. In response to the request, the server retrieves the structure for the designated slot from persistent storage. Values are then retrieved from persistent storage, starting with the value with handle given by the slot's m_valueFirst parameter. To retrieve the data item associated with the value, the frame with handle given by the value's m_frameID parameter is retrieved. The AVL node associated with that frame, designated by the frame's m_SymbolTreeID parameter, is retrieved. Then, the frame's data item is retrieved, as described previously, starting with the symbol block designated by the AVL node's m_SymID parameter. The value structure information and data item are then used to construct a message describing the value that is sent to the client component.

After the first value is retrieved and the message dispatched to the client, the next value's handle is given by the m_valueNext parameter of the current value structure. This value structure is retrieved and the associated data item is retrieved to construct another value description message that is dispatched to the client. This process is repeated until descriptions of all of the slot's values have been dispatched to the requesting client. As with frame expansions and searches, in some implementations, the client's request may include a starting value handle or limit for the number of items or the data volume that can be returned.

Deleting Information

Items are deleted from persistent storage by sending a deletion request to the server. The deletion request specifies the type of object to be deleted—frame, slot, or value—and includes the handle of the item to be deleted. If the server component enforces inheritance consistency requirements on deletions, then the server first determines if the requested deletion operation violates those requirements.

Inheritance Inconsistency

The server's inheritance consistency checks are intended to prevent storage of inconsistent relations that would be undesirable in some applications.

An inheritance inconsistency can be created, for example, by inserting the two relations cheese is a dairy product and cheddar cheese is a cheese and then deleting the inherited relation, cheddar cheese is a dairy product, which the server will have created. The inheritance inconsistency is that the group cheese has property is a dairy product that a member of the group cheddar cheese does not share. Such an inconsistency may, of course, have no consequences for some applications. Depending on the application's requirements, the server can either proceed with the deletion or reject the request and send the client an error message. Again, depending on the application's requirements, the client component can respond to the rejected deletion request by:

• 1. Sending the server a deletion request with the additional instruction to ignore the consistency checks.
• 2. Deleting either the relation cheddar cheese is a cheese or the relation cheese is a dairy product to eliminate the inconsistency.

If the inheritance consistency requirements for the application have been satisfied, the deletion procedure can go forward according to the implication consistency requirements of the application.

Deletion Implication Consistence

In general, the goal of maintaining consistent implications when deleting items is to leave the set of stored relations such that the relations remaining after the deletion could have been created from nothing by some combination of additions alone. This is more desirable in some applications than others and the server component program can easily be modified to perform different implication deletions than those discussed here—or to do no implication deletions at all.

An example where items can be deleted to maintain consistent implications starts with the stored relation (information) Jack's age is 40. As described above, when this relation is stored, four other relations are also stored:

• • 40 is the age of Jack
  • Jack's attributes include age
  • 40 is an age
  • Age entries include 40.

Simply removing the value for 40 from the slot for age in the frame Jack would leave the following set of relations stored:

• • Jack's age is unknown
  • 40 is the age of Jack
  • Jack's attributes include age
  • 40 is an age
  • age entries include 40.

Obviously, 40 is not the age of Jack if Jack's age is unknown. A better result would be also to delete the second, fourth, and fifth relations to leave the set:

• • Jack's age is unknown
  • Jack has an age

This set of relations could have resulted from storing the relation Jack's age is unknown in an empty database.

The deletions the server makes to maintain consistent implications depend on the object—frame, slot, or value—being deleted and on the slot type of the relation that is the primary target of the deletion.

Table 5 shows the actions taken by the server in response to a request for the deletion of a value in a relation. The set of additional deletions is determined by the type of the slot in the target relation from which a value is being deleted. The numbers 1, 2, and 3 in Table 5 correspond to the frame data item, the slot data item (if any) and the value data item of the target relation. For each target slot type, Table 5 indicates that the value item in the target relation is to be deleted by showing a line through the number of the value data item (e.g.: 3). The implications of each target relation are also shown in Table 5, with lines through the numbers of the data items associated with frame, slot, or value structures that are to be deleted.

Some of the deletion rules shown Table 5 leave slots as placeholders or mnemonics, so that a client user can more easily fill in the empty values at a future time. This choice is convenient for some applications and can be modified as convenient for a particular program application.

While empty slots are maintained by the server, in a typical implementation of the server, frames without slots are deleted, along with the associated AVL node and data item, because they have no relationships with other data items.

TABLE 5
Server actions to service a request to delete a value.
	Frame		Slot	Value
Target Relation	Data	Implication	Data	Data
Slot Type	Item	Relation Slot Type	Item	Item
Instance is	1	Instance is	2
Instances are		Instances are
	3	Instance of
	2	Type is	None
	3	Is a type of	None
		Delete this slot if it
		is empty.
	2	Is an attribute of	None	1
Instance of	1	Instance of	2
	3	Instance is	2
	2	Type is	None	1
	1	Is a type of	None	2
	2	Is an attribute of	None	3
Commutative	1	Commutative	2
	3	Commutative	2
	2	Type is	None
	3	Is a type of	None
		Delete this slot if it
		is empty.
	2	Is an attribute of	None
		Delete this slot if it
		is empty.
	2	Is an attribute of	None
		Delete this slot if it
		is empty.
Pair	1	Pair	2
	3	Pair	4
	2	Type is	None
	4	Type is	None
	4	Is an attribute of	None
	3	Is a type of	None
	2	Is an attribute of	None	1
Transitive	1	Transitive	2	3
	3	Transitive	4	1
	2	Type is	None	3
	4	Type is	None
	4	Is an attribute of	None
	3	Is a type of	None	2
	2	Is an attribute of	None	1
Type is	1	Type is	None
	3	Is a type of	None
		Delete this slot if it
		is empty.
Is a type of	1	Is a type of	None
	3	Type is	None
Is an attribute of	1	Is an attribute of	None
	3	Instance is		None

Table 6 shows the actions taken by the server in response to a request for the deletion of a slot in a relation. The set of additional deletions is determined by the type of the slot in the target relation from which a slot is being deleted. The numbers 1, 2, and 3 in Table 6 correspond to the frame data item, the slot data item (if any) and the value data item of the target relation. For each target slot type, Table 6 indicates the items to be deleted by showing a line through the number of the associated data item or through the slot type name.

TABLE 6
Server actions to service a request to delete a slot.
Target	Frame		Slot	Value
Relation Slot	Data	Implication	Data	Data
Type	Item	Relation Slot Type	Item	Item
Instance is	1	Instance is
Instances are		Instances are
	3	Instance of
	2	Type is	None
	3	Is a type of	None
	2	Is an attribute	None
		of
Instance of	1	Instance of
	3	Instance is
	2	Type is	None
	1	Is a type of	None
	2	Is an attribute	None
		of
Commutative	1	Commutative
	3	Commutative
	2	Type is	None
	3	Is a type of	None
	2	Is an attribute	None
		of
	2	Is an attribute	None
		of
Pair	1	Pair
	3	Pair	4
	2	Type is	None
	4	Type is	None
	4	Is an attribute	None
		of
	3	Is a type of	None
	2	Is an attribute	None	1
		of
Transitive	1	Transitive
	3	Transitive	4
	2	Type is	None
	4	Type is	None
	4	Is an attribute	None
		of
	3	Is a type of	None
	2	Is an attribute	None
		of
Type is	1		None
	3	Is a type of	None
Is a type of	1		None
	3	Type is	None
Is an attribute	1		None
of
	3	Instance is		None

If the server is requested to delete a frame, the procedure is to delete all of the values and their implications, as described in Table 5, and the all of the slots with their implications, as described in Table 6. Since the frame then has no slots, the frame, its AVL node and its data item are deleted.

Editing Information

The server satisfies edit requests by simply first executing the deletion procedure for the item being edited and then executing an insertion procedure to insert the new data item. The deletion procedure may be rejected for failing consistency checks, discussed in the description of data deletion above, if these are implemented.

Client Communication

The server component of the present invention can be used in a network environment serving multiple clients executing on different nodes in the network. In such an environment, the server can act as a “subscription server,” maintaining a description of items that have been sent to the clients to service their requests and sending them update messages if any of the items that the clients have been sent change.

In this mode, several users can have their clients display a set of relations and any modification of those relations made by any user will be sent to all the clients for display. This way, the system of the present invention acts as a means for a group of users to share information.

The communication between the server and clients is typically implemented with network communication software. In the preferred embodiment, this communication is implemented between the client and server by using Microsoft DCOM software. An obvious alternative would be to use communication software based on the Object Management Group's CORBA software standard, or based on web service such as XML/SOAP. Other standard or non-standard software communication mechanisms can be used to provide communication between the server and its clients.

Multiple Execution Threads

The server is typically implemented as a computer program that has multiple execution threads. This permits the server to use one thread to receive client commands and a second thread to service them. The advantage of this approach is that it permits the clients to send a command to the server to terminate execution of a search or an expansion that is in progress. The server can receive the search termination command and interrupt the other thread executing it.

It is also often convenient to have the server create a separate thread to manage the delivery of information to each client. In a network environment, this decouples the clients from each other because the delivery thread for a fast client can proceed while the delivery thread for a slow client waits.

In one embodiment, the client and server are both portions of a single program that executes on a machine running the MS-DOS operating system. In this implementation, the server component of the program periodically checks for keyboard input signaling it to terminate a search that is in progress.

Transactions

As mentioned previously, to ensure the integrity of the stored data, the server breaks up interactions with the persistent storage system into atomic transactions. The natural atomic unit for this is a client command. This means that either the storage consequences of a client command are completely stored in persistent storage, with all their effects on implied relations and inheritances, or no change is made to persistent storage.

Command Interface

A typical set of commands supported by the server is shown in Table 7.

TABLE 7
Typical server commands.
Command      Description
Open         Open a database file in a file system or
             region in a persistent storage system that
             contains a set of stored data structures of the
             invention. A designator for the file or region
             to be opened must be supplied by the client.
Close        Close a database file in a file system or
             region in a persistent storage system that
             contains a set of stored data structures of the
             present invention.
Add          Insert a data item (with implications
             and inheritances) into the data in persistent
             storage.
Edit         Edit a data item in persistent storage.
             As mentioned previously, this is equivalent to
             a combination of Delete and Add. An item
             handle and a new data item must be provided
             by the client.
Delete       Delete an item (with its implications
             and inherited relations) from persistent
             storage. An item handle must be provided.
Expand       Send this client the slots from a parent
             frame or the values from a parent slot. An
             item handle for the parent must be provided
             by the client. This command also causes the
             server to send the client notification of any
             changes in the value or slot descriptions sent
             to the client.
Cancel       This command causes the server to stop
Subscription sending the client notifications of changes in
             a frame, slot, or value item.
Stop         This command directs the server to stop
Expansion    servicing an Expand command from the
             client.
Search       This command directs the server to
             search for data items that match a certain
             criteria. The server sends descriptions of the
             matching frames to the client. After the
             search is concluded, the server will continue
             to send the client notification of changes in
             the frames returned as search results. The
             client can halt these notifications with a
             Cancel Subscription command.
Stop         This command directs the server to halt
Search       a search in progress that the client has
             requested.
Disconnect   In a multiple-client environment, this
             command informs the server that a client is
             disconnecting. The server stops sending item
             updates to the client.

Compacting Persistent Storage

The server's storage system is used to store five different types of objects: symbol blocks, AVL tree nodes, frames, slots, and values. As mentioned previously, these structures can be stored in fixed length segments and unused storage region segments can be added to a linked list of free segments. It may become desirable, however, to reduce the total persistent storage region occupied by moving all of the free segments to one end, reassigning them for use in some other application. To accomplish this, data occupying segments in the region being released is moved to blocks taken from the linked list of free blocks.

The structure being moved from one storage segment to another has its handle value set to the value appropriate for the destination segment and then it can be copied to its new location. All the stored data structures that contain references to the old location must be updated as well. In addition, all of the operations to move a structure must be taken together as an atomic transaction to prevent corruption of the stored data in the event of a power, or some other, failure.

Table 8 lists by data structure type the method to locate all the references to a data structure that is being moved.

TABLE 8
Procedures to locate references to stored data structures.
Data
Structure Procedure to Locate All Stored References
Symbol    Every symbol block has a reference to the first
Block     node used to store its data item. By following the
          linked list from the first node, a block's predecessor
          in the linked list of the data item's blocks can be
          found.
          The first block is referenced by the other
          blocks for the data item. As stated above, these can
          be found by following the linked list of symbol
          blocks. A first block is also referenced by the AVL
          tree node whose handle is given by the block's
          m_SymbolTreeId parameter.
AVL       An AVL tree node is referenced by a frame
Tree      structure, a symbol block, possibly a number of slot
Node      structures, and by two other AVL tree nodes.
          The frame structure has the handle given by
          the node's m_frameID parameter.
          The symbol block has the handle given by the
          node's m_SymID parameter.
          The node is referenced by its neighbors on the
          AVL tree thread, whose handles are given by the
          node's m_NextNodeID and m_LastNodeID parameters. The
          node is referenced as a sub-tree by its AVL tree
          parent, which will be one of these two thread
          neighbors.
          Any slots associated with the node's data item
          will contain references to the node. The parent
          frames of these slots will referenced by the value
          structures of the is an attribute of slot of the frame
          with handle given by the node's m_frameID parameter.
Frame     A frame structure is referenced by the AVL
          tree node whose handle is given by the frame's
          m_SymbolTreeId parameter.
          A frame is also referenced by value structures.
          As a consequence of inserting relations as a set with
          their implications, these values are the children of
          slots whose parent frames are referenced by values
          that are the children of slots of this frame.
Slot      Slots are referenced by their parent frame,
          whose handle is given by the slot's m_parentFrameID
          parameter.
          Slots may also by referenced by a previous
          sibling slot of the parent frame. This previous
          sibling can be located by following the slot linked
          list from the first slot referenced by the parent
          frame's m_slotFirst parameter.
          Slots are also referenced by their nearest
          neighbors on the linked list of all slots. These
          neighbors' handles are given by the slot's m_slotFlink
          and m_slotBlink parameters.
Value     Values are referenced by their parent slot,
          whose handle is given by the slot's m_parentSlotID
          parameter.
          Values may also by referenced by a previous
          sibling value of the parent slot. This previous
          sibling can be located by following the value linked
          list from the first value referenced by the parent
          slot's m_valueFirst parameter.

Client Description

The number of possible user interfaces that can provide access to data that is maintained in a database of the present invention is virtually unlimited. Application-specific interfaces can be created for particular domains that reflect the peculiarities of that domain. A general-purpose interface has been constructed that provides access to the basic functions and reflects the unique structure of the database.

The general-purpose interface allows the user to enter search text to be found in the database. The search may be specified as one of three types:

Search for items that begin with <search text>

Search for items that include <search text>

Search for items that exactly match <search text>

Other search types are possible. These are simply presented to demonstrate the capability of supporting alternative matching criteria.

Matching items are displayed in a column at the left edge of the client area of the application window. The user may elect to expand one of the items to reveal its slots.

The general-purpose interface presents the information retrieved in a multi-line indented format. A sample display image of this interface is shown in FIG. 9. In this format, the frame is presented on the first line, with slots listed below and indented one level. Here is an example:

Iomega

Is a

Products are

Address is

Phone number is

If values are shown, they are listed below the slot with which they are associated and indented two levels. Here is an example:

Iomega

Is a

Products are

• • Jaz drive
  • Zip drive
  • Jaz cartridges
  • Zip cartridges

Address is

Phone number is

In the above example, the “Products are” slot is said to have been expanded.

Values can be expanded to reveal the slots of the frame to which they refer. For example:

Iomega

Is a

Products are

• • Jaz drive
    • Price is
    • Availability is
  • Zip drive
  • Jaz cartridges
  • Zip cartridges

Address is

Phone number is

These slots can in turn be expanded to reveal their values. This process can continue indefinitely, allowing the user to browse through the available information. Facilities are provided to allow the user to:

• • Enter new facts into the database
  • Delete values, slots, or entire frames from the database
  • Modify the text of a frame, slot, or value
  • Expand and contract items displayed
  • Select an item to become the new “root” item. (The root item is the leftmost item displayed.)
  • Scroll to view information which is off-screen
  • Abort retrieval if the number of items retrieved is too large
  • Export data in a format which can be later restored
  • Import data from other formats generated by other tools such as spreadsheets and relational databases
  • Export data in a format which can be read by other tools such as spreadsheets

The user interface client program may subscribe or “express interest in” information maintained by the server. The server then publishes (sends) updates to clients who have expressed interest in an item that has been changed. This allows the client to display changes to items of interest in real time as they are modified by other clients. Clients may, of course, also express a loss of interest for an item in which they were previously interested.

A unique feature of the present invention is that the action of addition, removal, and modification of slots assigned to a frame is published by the server to clients who have expressed interest in the frame. This would be analogous to a relational database informing its users in real time that a column has been added to a table. In addition, the structure of the data items allows clients to be constructed that can automatically accommodate the change.

The publish-and-subscribe capability of the system, combined with the robust capabilities for accommodating change enabled by the structure of the information, makes “groupware” applications that allow sharing of information in real time relatively easy to design and construct.

The client and the server identify information items (i.e., frames, slots, and values) using handles. The handle value is assigned by the server and is guaranteed to refer only to the designated data item.

When a client adds a new item to the database, the client sends an insertion request to the server containing a temporary handle associated with the new data item. The server responds with a message containing the temporary handle and the server-assigned handle to replace the temporary handle. Thereafter, all communication between the client and the server uses the server-supplied handle.

Of course, various changes, modifications and alterations in the teachings of the present invention may be contemplated by those skilled in the art without departing from the intended spirit and scope thereof. As such, it is intended that the present invention only be limited by the terms of the appended claims.

Claims

1. In a user-based computer system for causing a persistent memory to function as an information storage and retrieval system that receives and stores information, the combination comprising;

a computer-readable medium storing a server computer program that, when executed by a computer, manages the persistent memory to receive and store information in a frame system that can be browsed at a later time.

2. The system of claim 1 wherein the information received and stored in the persistent memory includes primary information from outside the persistent memory.

3. The system of claim 2 wherein said server computer program, when executed by a computer, derives additional information from primary information, and

the information stored in the persistent memory that can be browsed at a later time includes primary information and additional information.

4. The system of claim 3 wherein said server computer program, when executed by a computer, is capable of deriving further additional information from the primary information and information stored in the persistent memory before the primary information and wherein the information stored in the persistent memory that can be browsed at a later time includes further additional information.

5. The system of claim 2 wherein said server computer program, when executed by a computer, is capable of deriving further additional information from the primary information and information stored in the persistent memory before the primary information and wherein the information stored in the persistent memory for browsing at a later time includes further additional information.

6. The system of claim 2 wherein:

said primary information includes a plurality of data items;

the frame system includes frames, slots and values;

the data items of said primary information stored in the persistent memory for browsing at a later time are related to each other by a particular frame-slot-value relationship.

7. The system of claim 3 wherein:

said primary information includes a plurality of data items;

the frame system includes frames, slots and values;

the data items of said primary information stored in the persistent memory for browsing at a later time are related to each other by a particular frame-slot-value relationship; and

the additional information is said data items of the primary information related to each other by different frame-slot-value relationships.

8. The system of claim 4 wherein:

said primary information includes a plurality of data items;

the frame system includes frames, slots and values;

the data items of said primary information stored in the persistent memory for browsing at a later time are related to each other by a particular frame-slot-value relationship;

the additional information is said data items of the primary information related to each other by different frame-slot-value relationships; and

the further additional information is at least one data item of said primary information related by a frame-slot-value relationship to at least one data item stored in the persistent memory before the primary information.

9. The system of claim 1 wherein said server computer program, when executed by a computer, searches and identifies information in the persistent memory independently of the frame system.

10. The system of claim 3 wherein said server computer program, when executed by a computer, searches and identifies information in the persistent memory independently of the frame system.

11. The system of claim 4 wherein said server computer program, when executed by a computer, searches and identifies information in the persistent memory independently of the frame system.

12. The system of claim 9 wherein said server computer program, when executed by a computer, browses the information in the persistent memory using the frame system.

13. The system of claim 10 wherein said server computer program, when executed by a computer, browses the information in the persistent memory using the frame system.

14. The system of claim 11 wherein said server computer program, when executed by a computer, browses the information in the persistent memory using the frame system.

15. The system of claim 1, further comprising:

a computer-readable medium storing a client computer program that, when executed by a computer, provides a user interface for entering information from outside the persistent memory to the persistent memory where it is managed by said server program and for receiving information from the persistent memory and making it available to a user.

16. The system of claim 15 wherein:

said server computer program, when executed by a computer, searches and retrieves information in the persistent memory independently of the frame system: and

said client computer program, when executed by a computer, provides a user interface from which commands can be directed to said server program to search in and retrieve information from the persistent memory.

17. The system of claim 15 wherein;

said server computer program, when executed by a computer, browses the information in the persistent memory using the frame system; and

said client computer program, when executed by a computer, provides a user interface from which commands can be directed to said server program to browse information using the frame system.

18. The system of claim 16 wherein;

said server computer program, when executed by a computer, browses the information in the persistent memory using the frame system; and

said client computer program, when executed by a computer, further provides a user interface from which the information in the persistent memory can be browsed using the frame system.

19. The system of claim 1 wherein said server computer program, when executed by a computer, browses the information in the persistent memory using the frame system.

20. In a method of storing information in and retrieving information from a computer's persistent memory, the step comprising:

(a) storing primary information from outside the persistent memory in a frame system in the persistent memory for later browsing.

21. In the method of claim 20, the further step comprising:

(b) searching independently of the frame system for information in the persistent memory.

22. In the method of claim 21, after step (b), the further step comprising:

(c) browsing the information in the persistent memory using the frame system.

23. In the method of claim 22 wherein step (c) is initiated at a location within the frame system based on information located by step (b).

24. In the method of claim 20, the further steps comprising:

(b) generating additional information from the primary information; and

(c) storing the additional information in the frame system of the persistent memory for later browsing.

25. In the method of claim 24, after step (c), the further step comprising:

(d) searching independently of the frame system for information in the persistent memory.

26. In the method of claim 25, after step (d), the further step comprising:

(e) browsing the information in the persistent memory using the frame system.

27. In the method of claim 25 wherein step (e) is initiated at a location within the frame system based on information located by step (d).

28. In the method of claim 20, the further steps comprising:

(b) generating further additional information from the primary information and information previously stored in the persistent memory;

(c) storing the further additional information in the frame system of the persistent memory for later browsing.

29. In the method of claim 28, after step (c), the further step comprising:

(d) searching independently of the frame system for information in the persistent memory.

30. In the method of claim 28, after step (d), the further step comprising:

(e) browsing the information in the persistent memory using the frame system.

31. In the method of claim 30 wherein step (e) is initiated at a location within the frame system based on information located by step (d).

32. In the method of claim 20, the further steps comprising:

(b) generating additional information from the primary information;

(c) generating further additional information from the primary information and information previously stored in the persistent memory; and

(d) storing the additional information and the further additional information in the frame system of the persistent memory for later browsing.

33. In the method of claim 32, after step (d), the further step comprising:

(e) searching independently of the frame system for information in the persistent memory.

34. In the method of claim 33, after step (e), the further step comprising:

(f) browsing the information in the persistent memory using the frame system.

35. In the method of claim 35 wherein step (f) is initiated at a location within the frame system based on information located by step (e).