WO2002052443A1 - Address tags for a hierarchical data structure and method of creating and using same - Google Patents

Abstract

There is disclosed data structure, and more particularly address tokens used to address members of a hierarchical data structure. There is further disclosed a process for making the address tokens and several processes for using the address tokens in a wide variety of applications.

Description

ADDRESS TAGS FOR A fflERARCfflCA DATA STRUCTURE AND METHOD OF

CREATING AND USING SAME

TECHNICAL FIELD OF THE INVENTION

The present invention provides data structures, and more particularly address tokens used to address members of a hierarchical data structure. The present invention further provides a method for making the address tokens and several methods of using the address tokens in a wide variety of applications.

BACKGROUND OF THE INVENTION

Most large bodies of information are classified and delivered to the user as groups of data objects (or data-table records) that are related in some logical way. An advantageous approach organizes data by category/sub-category/sub-sub-category and so forth. Several features of this classification process are noteworthy: (1) the value of an organizing framework is proportional to the complexity and depth of the framework; (2) the end-user's ability to work with an organizing framework is inversely proportional to the complexity and depth of the framework; (3) understanding an object's place in the framework adds value by demonstrating contextual links to similar objects; and (4) understanding of the framework itself is enhanced by context - antecedent, sibling, and descendant relationships define the framework and should be clearly visible to users.

It is useful to think of families of related categories as a tree structure. There are two dimensions of complexity in a tree structure: (1) the number of children that can be assigned to each node and (2) the number of descendant levels available to a node. A successful hierarchical organizing scheme must allow for depth in both of these dimensions. However, often most hierarchies often are limited in size or potential size.

Delivering large amounts of hierarchical information to the end-user in a comprehensible way is a difficult proposition. The organizing logic applied by the indexer might not be clear or comfortable to the user, increasing the investment required to explain the index itself. Displaying large amounts of information obscures contextual relationships - the ideal contextual display gives the user immediate reference to the siblings of a node, the node's children, its parent, and its parent's siblings, at each antecedent level. Collapsible lists (a common method of displaying hierarchical information) break down quickly under this burden.

Navigation through families of categories must be intuitive and responsive - the user should not be distracted from content and message by the machinery of display. Using indented lists (which usually require considerable scrolling) is a technique that hinders as much as it helps. Squandering the user's attention on complicated displays that take a long time to update is certainly counterproductive. As valuable as an organizing framework may be, it is not an end in itself— the information that has been organized is what is important. Everything that intrudes upon the display of end-information is disruptive and should be minimized. This is especially important when the structure of end- information is complicated; half-screen-size category lists and pop-up windows are distracting and often degrade the user's ability to perform end-application work. In actual practice, a designer can provide simplicity of understanding and operation only at the twin costs of valuable screen real estate and significant extra programming effort.

Therefore, there is a need in the art to create organizing structures of potentially unlimited capacity that can be applied to bodies of information. The present invention addresses these needs. Summary of the Invention

The present invention provides a process for creating a database of potentially unlimited size, comprising:

(a) obtaining an existing database or data objects having a plurality of records;

(b) creating a new field in each database record; and (c) populating each new field with a token, wherein the token is a string data type of variable length.

Preferably, the existing database is selected from the group consisting of a telephone directory, an email address directory, and address book, a world wide television directory and parts thereof, a mobile commerce directory, and combinations thereof. Most preferably, the existing database is a combination of a telephone directory, email address directory and address book. Preferably, the records of the plurality of records are selected from the group consisting of telephone datum, email datum, address datum, mobile commerce datum, television programming datum, and combinations thereof. Preferably, the token data type is in a multi-dimensional subscript.

The present invention further provides a database of potentially unlimited size, comprising: (a) an existing database or data objects having a plurality of records in a first field or plurality of fields; and

(b) a second field or an additional field having tokens therein, wherein the token is a string data type of variable and potentially unlimited length.

Preferably, the existing database is selected from the group consisting of a telephone directory, an email address directory, and address book, a world wide television directory and parts thereof a mobile commerce directory, yellow page directory, web sites, classified advertisements, and combinations thereof. Most preferably, the existing database is a combination of a telephone directory, email address directory and address book. Preferably, the records of the plurality of records are selected from the group consisting of telephone datum, email datum, address datum, mobile commerce datum, television programming datum, and combinations thereof. Preferably, the token data type is in a multi-dimensional subscript.

The present invention further comprises a navigation database of unique tokens and related data, potentially unlimited in size, comprising: (a) a plurality of tokens ordered by token, wherein the token is a string data type of variable and potentially unlimited length; and

(b) related data associated with each token, wherein the related data are a text label of each token. Preferably, the related data further comprise additional information associated with the token.

Most preferably, the related data are selected from the group consisting of URLs date/time stamps, flags (indicating whether a token has children), other tokens, stand alone files, embedded data files, audio or video files, and combinations thereof. Preferably, the token optionally further comprises descendents in a hierarchical organization. The present invention further comprises a segmented database, comprising a segment of a navigation database segmented according to descendents of a token, wherein the navigation database comprises

(a) a plurality of tokens ordered by token, wherein the token is a string data type of variable and potentially unlimited length, and wherein at least one token further comprises descendents in a hierarchical organization; and

(b) related data associated with each token, wherein the related data are a text label of each token.

Preferably, the related data further comprise additional information associated with the token. Most preferably, the related data are selected from the group consisting of URLs date/time stamps, flags (indicating whether a token has children), other tokens, stand alone files, embedded data files, audio or video files, and combinations thereof.

The present invention further provides a process for segmenting a navigation database, comprising:

(a) structuring a navigation database, wherein the navigation database comprises (i) a plurality of tokens ordered by token, wherein the token is a string data type of variable and potentially unlimited length, and wherein at least one token further comprises descendents in a hierarchical organization; and (ii) related data associated with each token, wherein the related data are a text label of each token; and

(b) dividing the navigation database into a plurality of bounded files according to descendents of a token having common portions of the string of data in each token of the descendents.

Preferably, the related data further comprise additional information associated with the token. Most preferably, the related data are selected from the group consisting of URLs date/time stamps, flags (indicating whether a token has children), other tokens, stand alone files, embedded data files, audio or video files, and combinations thereof. The present invention further provides a process for adding one or a plurality of records to a navigation database, wherein a record comprises a token, text label, and related data associated with the token, comprising editing data associated with a particular token, wherein the editing function is selected from the group consisting of creating a new token, modifying an existing token, deleting a token, moving a token and its descendents, and combinations thereof. BRIEF DESCRIPTION OF THE DRAWING

Figure 1 illustrates management of IndexList that permits the display of a token. DETAILED DESCRIPTION OF THE INVENTION

The present invention is a network of related elements.

(Tree structures)

Token

Segmented Database

Scalable H-Interface Hierarchical SQLs

Navigation Database H-Browser Applications (Other databases)

(Server-based Nav) Editor Application

Hierarchical structures are treated as multidimensional string arrays; each node occupies a unique array-address, which is mapped into a 'token'. The token is a string data-type of variable length. There are no^'practical restrictions to the number of uniquely addressable tokens; a database of tokens is similarly unbounded in size. Tokens are used to segment a database into uniquely named files, each containing a hierarchical subset of data. There is no restriction to the size of the resulting 'segmented' database. It should be noted that a segmented database is required for query-based access to token information. An example is a database of telephone numbers segmented into files by area code and/or exchange (two levels of a three-level telephone number). In contrast, the token database is segmented at any level of a token (of any length).

A token database is used to present a tree structure. This is accomplished by associating a text label with each token. Additional data are associated with each token (including files, pointers to information, and (pointers to) other nodes). The result is a 'navigation database'. A characteristic of the segmented navigation database is that refreshable segments can be saved to and accessed in a user's local environment. (Tree structures)

Hierarchical SQLs

(Other databases)

A dedicated interface will help to explain to understand and use tree structures. Using a token mechanism to present a tree structure (instead of using the contents of hierarchically-architected data fields) creates flexible hierarchical interfaces and component footprints. That is, a token can be translated using an optional 'path statement' and one or more list(s) of variable depth (number of elements). This flexibility is required in an interface that supports variable-length tokens. The interface is enriched with sets of features to create applications. Browser applications include features that facilitate access to information associated with navigation database nodes. A critical characteristic of browsing an unbounded database of navigation information is efficiency. This is delivered by browser-managed local caches of navigation database segments. Browsers are flexible in display mechanisms and operate without regard to communications protocol. Thus the same navigation information is accessible to wired and wireless computer devices, digital telephones, digital televisions, etc. Moreover, editor applications include features that create and modify tokens and populate navigation database fields with data and pointers.

(Tree structures)

Segmented Database Scalable H-Interface Hierarchical SQLs

Navigation Database H-Browser Applications (Other databases)

SERVER-BASED Editor Application The navigation database associates tree-structure nodes with information. These links are created and maintained using the Editor applications). Associating nodes with 'executable' files produces menus of functions and procedures that can be downloaded to user devices as required. In one example, device manufacturers associate navigation nodes with device commands or 'macros'; new features and alternate menu schemes are published whenever necessary. Browsers (based on the token- driven interface and characteristics of the segmented navigation database) are used to traverse the structure of a body of information before accessing end-data or content. When structure and links would otherwise be delivered as content, server-based navigation reduces calls to content-servers and overall communications volume. 'Server-based navigation' refers to a method of access to information and applies equally to structured databases and unbounded bodies of information like the aggregate contents of the Web. Excluded from this discussion are servers and interfaces dedicated to presenting end-content (e.g., Web servers/Internet Explorer or proprietary database servers/user interfaces).

(Tree structures)

A token mechanism is preferred in order to enable generic hierarchical SQL queries. These are simple SQL statements that access data according to relationships (siblings/children/descendants of a node). Tokens are appended to records in pre-existing databases by adding a field to database records. This creates the ability to superimpose an organizing structure on a database without regard to its design or architecture, and without altering any native data. Appending more than one token to (imposing more than one organizing framework on) the records in a database creates a simple and extremely powerful drill-down data access mechanism. A browser application requests information (sets of database records) by transmitting a token to a native database server, which then executes a hierarchical SQL access. Using Hierarchical Indexes

In instances where hierarchical categorization is useful, it becomes an essential property of the information object. It has the advantage of utilizing the end-user's in-built tools (logic, pattern recognition, and the like) to economize communication, avoiding the extravagance of long descriptions when the user can figure them out for himself. For example, consider two end-information objects: the encyclopaedia descriptions of boy and chimp. Examination of these objects will provide a large number of potential connections but require the user to figure them out for himself. It is much more efficient to tell the user what the objects have in common, and help him remember the commonality while he explores detail. One hierarchical structure that could lead to the selection of boy and chimp

(among others) looks like this:

Sun / Mercury / Earth / Jupiter

Plants / Animals / Bacteria / Viruses

Land / Water / Air Invertebrate / Vertebrate

2-legs / 4-legs

There is a clear benefit in explaining how the user received a list including boy and chimp (and other 2-legged, vertebrate, land-dwelling animals that are found in this part of the solar system). In this way the hierarchical description actually becomes part of the information object - without it, the user does not know the whole story:

Earth / Animals / Land / Vertebrate / 2-legs // BOY

Earth / Animals / Land / Vertebrate / 2-legs // CHIMP

Earth / Animals / Land / Vertebrate / 2-legs // ETC.

There are other ways to organize an encyclopedia — alphabetical order, cross-referencing, hypertext links, to name a few - but none is able to deliver groups of information objects that are related in complicated or detailed ways.

The Hierarchical Display

There are several methods of delivering information about the category structure that groups the objects. The list shown above is vastly preferable to saying nothing at all, but fails to even suggest the real richness of the structure. Compare it to the following:

Table 1

The difference between this tabular method (Table 1) and the path method is that the tabular method also indicates the siblings of each ancestor node of the tree structure. The user now has access to a much broader picture of the organizing framework, as well as a depiction of the hierarchical path. The amount of data transferred to the user is still modest, yet he ends up with a lot more information — he is able to use his own resources to identify and evaluate the various relationships.

Three observations can be applied to this structure. First, each list element has its own discrete family of descendants. Second, each element (except the ends of each family line) can have 4 children. Third, the structure can be treated as a multi-dimensional array. If the structure is treated as an array, this array has a capacity of 1,365 nodes (l+4+4²+4³+4⁴+4⁵). This surprising observation leads directly to another: a modest increase in the ability to display a tree structure can be expensive (i.e., the amount of memory devoted to storing the additional nodes). In practice, when one begins populating elements with words like 'Earth' and 'Animals' one quickly reaches the system-imposed size limit of a simple text array. Even so, the idea of working with an array of words is very attractive. It is an elegant way to present hierarchical information to an end-user: display the tree structure in a series of standard listbox objects that can be populated using algorithms to generate lists of related items by manipulating array-element addresses. Underneath the Tree Structure

Consider how array data is stored when it is not being used by some application. Each array element has a 5-integer address and a text string. A file of array elements might look like the following:

Table 2

Note that this list of 15 records includes addresses and text labels for every visible item of the original list; it does not include a large number of other possibilities that would certainly appear in a real tree structure. These are then arranged in address order (ascending) and patterns can begin to be seen. The nature of the patterns provides algorithms for identifying the ancestor and descendant nodes of any address. An address can be mapped, stored, and manipulated as a 5-character string (as opposed to a group of 5 integers). It impacts on storage - 5 integers require 10 bytes, as opposed to 5 text characters (5 bytes), per record. Thus, any text character (not only a numeral) can be used as an address element - which provides a capacious and powerful addressing scheme. If one uses the characters 'A' through 'Z', for example, each element can have as many as 25 children. It is much easier to sort the list of addresses if they are string values.

Locating specific records in sorted lists is a trivial programming issue. If algorithms are designed to work on character-based address tokens, then it is no longer necessary to manage the tree structure as a (size-restricted) multi-dimensional array - a simple list will suffice. System-imposed limits on string arrays still apply, but mapping and using multiple arrays is simplified to an easily managed issue.

Therefore, the present invention applies this logic to very large hierarchical structures. Definitions

Unless otherwise specified, or unless required by the context in which they are used, the terms defined below shall have the meanings shown throughout this description. Application A computer program that solves some particular problem. Applications may use a DBMS to store and manipulate information relevant to such application. Array An ordered arrangement of data elements. A vector is a one dimensional array, a matrix is a two-dimensional array. Most programming languages have the ability to store and manipulate arrays in one or more dimensions. Multidimensional arrays are used extensively in scientific simulation and mathematical processing.

Client A client is the requesting program or user in a client/server relationship. Data item An instance of a particular data type. For example, the number 1 is an instance of the datatype "integer."

Data type A name for a set of possible values that may be represented in a computer's memory, along with a set of operations on those values. For example, the data type "integer" allows for the representation of positive counting numbers (1,2,3,...), negative numbers (-1,-2,-3,...) and zero(0), and provides for arithmetic operations such as addition and multiplication. Each DBMS product supports a predefined set of data types.

Database A collection of related information or data. Many databases are abstract representations of information pertinent to an enterprise, such as the design of integrated circuits.

Database A component of a computer system that provides support for the storage and

Management System management of databases. Graph/Tree/tree In the context of database systems, the term "graph" (or "graph structure") structure refers generally to a data structure that can be represented as a collection of interconnected nodes. As described below, a Web site can conveniently be represented as a graph in which each node of the graph corresponds to a content object of the Web site, and in which each interconnection between two nodes represents a link within the Web site. A "tree" is a specific type of graph structure in which exactly one path exists from a main or "root" node to each additional node of the structure. The terms "parent" and "child" are commonly used to refer to the interrelationships of nodes within a tree structure (or other hierarchical graph structure). For additional information on graph and tree data structures, see Alfred V. Aho et al, Data Structures and Algorithms, Addison- Wesley, 1982.

Hyperlink A navigational link from one document to another, or from one portion (or component) of a document to another. Hypertext system A computer-based informational system in which documents (and possibly other types of data entities) are linked together via hyperlinks to form a user- navigable "web." Although the term "text" appears within "hypertext", the documents and hyperlinks of a hypertext system may (and typically do) include other forms of media.

Internet The Internet is a collection of interconnected public and private computer networks that are linked together by a set of standard protocols (such as, TCP/IP, HTTP, FTP) to form a global, distributed network.

List An ordered collection of zero or more data items, possibly containing some duplicate values.

Query An instruction (command) to a DBMS that tells the DBMS to perform a desired action. Typical actions include the retrieval of data from the database and making changes to the data stored in the database.

Query language A computer language for expressing data retrieval questions and modification operations on a database. The query language defines the set of commands that are accepted by the DBMS, including the syntax and the actions or meaning associated with the syntax. A query is thus a particular instruction or sentence in the query language.

Record A record is a memory resident aggregate data type supported by many programining environments. Each such programming environment provides a way to declare a description for each type of record used by an application (including the names and types of the constituent data types making up the record), a way to allocate new instances of each record type, and, often, a way to dispose of (recycle) records when no longer needed by the application.

Segmented database Hierarchical descendents of a particular node. This can lead to a potentially infinite number of bounded files. Server In general, a server is a computer program that provides services to other computer programs in the same or other computers. The computer that a server program runs in is also frequently referred to as a server (though it may contain a number of server and client programs). In the client/server programming model, a server is a program that awaits and fulfills requests from client programs in the same or other computers. A given application in a computer may function as a client with requests for services from other programs and a server of requests from other programs. Specific to the Web, a

Web server is the computer program (housed in a computer) that serves requested HTML pages or files.

Set An unordered collection of zero or more unique data items, none of which can be null. Structured data Data that model the complex structure of real-world objects and events, including (in general) multiple links from one component to another and cycles. Structured data may conveniently be represented using a directed graph data structure.

Structured query The industry-standard query language for relational DBMS, as defined by the language (SQL) American National Standards Institute's standard ANSI X3.135-1986. The use of the word "structured" in the context of SQL is completely unrelated to the use of the same word in "structured data".

Table Each table is described by the database schema and consists of a set of "rows", each of which contains values for each column of the table.

Token A string data type of variable length. URL A unique address that fully specifies the location of a content object on the

Internet. The general format of a URL is protocol://machine- address/path/filename. The term URL is also used to refer to the corresponding content object itself.

Web site As used herein, "web site" refers generally to a database or other collection of interlinked hypertextual documents ("web documents") and associated data entities, which is accessible via a computer network, and which forms part of a larger, distributed informational system. Depending upon its context, the term may also refer to the associated hardware and/or software server components used to provide access to such documents. When used herein with initial capitalization (i.e., "Web site"), the term refers more specifically to a web site of the World Wide Web. In general, a Web site corresponds to a particular

Internet domain name, and includes the content of or associated with a particular organization. Other types of web sites may include, for example, a hypertextual database of a corporate "intranet" (i.e., an internal network that uses standard Internet protocols), or a site of a hypertext system that uses document retrieval protocols other than those of the World Wide Web.

WWW (World Wide A distributed, global hypertext system, based on a standard set of protocols Web, Web) and conventions (such as HTTP and HTML), which uses the Internet as a transport mechanism. A software program that allows users to request and view Web documents is commonly referred to as a "Web browser", and a program which responds to such requests by returning ("serving") Web documents is commonly referred to as a "Web server". Hierarchies. Tree Structures and Tokens

Nodes in a hierarchy (tree structure) participate in three types of relationships with other nodes: a node is descended from one parent; a node is part of a particular group of nodes - itself and its siblings constitute all the children of its parent (put another way, the group of all nodes having the same parent); and a node can have an indefinite number of children, ranging from none at all to some system-imposed limit. New-node addressing is influenced by these relationships: the portion of the identity contributed by the parent is common to all siblings; the new node's identity must be different from all its siblings; a node must be created before it can have children; describing the relationships this way establishes rules for addressing, and suggests some shortcuts that can make the addressing process more efficient.

A tree structure can be represented as a multi-dimensional array. The maximum size of the tree structure is now constrained by the operating system. Array elements are addressed using numbers, limiting the range of addressable nodes, and data stored in the hierarchical array is textual, requiring a string-defined array. A string array is limited in the amount of text it can contain. An array element address can be translated to text characters (allowing a one-byte character to represent any integer from 0 to 255).

The inventive process, for example, translates the integers 0 to 63 into ANSI characters 64 through 127 - ANSI(64)='@', ANSI(65)='A', ANSI(66)='B\ and so on. Any contiguous group of discrete characters may be used, provided that it not include any special character reserved for wildcard text-string comparisons. The inventive process operates on hierarchical systems composed of multiple levels. For example, an 8-level tree structure is an arbitrary decision - it provides more than enough capacity for most applications. All principles, user interfaces and algorithms/procedures apply to character ranges other than ANSI(64) through ANSI(127) and tree structure depths other than 8.

Looking at a token, it can be described as having three parts - the ancestral part, the sibling part, and the descendant part (children, grandchildren, etc.) that together form a string of characters.

The end of the string of characters is the point where there are no further descendants. Expressed in token terms (where the zero-value character is '@'), the end of the line is the furthest-downstream (rightmost) non-zero character. The resulting address tokens are manipulated as text objects. Element examination and replacement using low-level functions: LEFT$( ), MID$( ), RIGHT$( ), wildcard character string comparisons (searches), and algorithms are devised that use token manipulation and simple string arrays to create an effect identical to movement through a complex multi-dimensional array. For example, tokens are added to application data objects (a field populated with formatted character strings), replacing complicated category-coding schemes and allowing direct hierarchical manipulation of data.

Tokens are disaggregated into a series of parent tokens. Determining the token of a node's parent is accomplished using string manipulation techniques. Table 3 indicates a family of tokens. Table 3

A@@@@@@@

AB m

ABC@@@@@

ABCDfi

ABCDEtf

ABCDEF@@

ABCDEFG®

ABCDEFGH

End-users should not view the tokens directly, because they have no clear meaning. They can, however, be translated into an easy-to-understand series of text-labels. The process and databases are configured to translate tokens using multiple languages — user preferences control the language selected for display. The parent's token is the template for a new-node (child) token. The uniqueness of a new-node address is defined by the number and/or addresses of its siblings.

The display of text is controlled by the computer's hardware and operating system. Since a new-node, by definition, has no children, it is a new end-of-the-line for its parent. If its parent's token is 'BBB@@@@@', then a new-node will have a unique value in the 4^th-level position and zero-values for the 5^th, 6^th, 7^th, and 8^th levels (if the database is set up with 8 levels). Therefore, creating a new child of 'BBB@@@@@' requires only that the fourth position of the parent's token (the parent's end-of-the-line) be modified. This is a very simple function — if the value to insert is represented by 'X', then the process is accomplished using the single expression: M_D$(_NSTR('BBB@@@@@', '@'),1)='X' There are several ways to determine the value of 'X'. As long as it is unique among its sibling values and it is within the allowable overall range of values, then any available value for 'X' is as good as any other. One method uses any available (not already used), allowable (within a defined range) value. Another method determines the highest value already assigned to a sibling, then adds 1 (if allowable). A third method counts the siblings, then adds 1 (if allowable). It should be noted that the third method is the simplest (in some cases it can be determined in a single step by examining the properties of the browser's sibling-level listbox object). But it only works if there are no discontinuities in the sibling- level addresses. However, deleting a node, unless it happens to be the youngest member of the sibling group, creates just such a gap. There are several potential solutions to the gap problem, and they influence the choices discussed above. A no-longer-needed node can be left in the system, with a TextLabel blank or null. The mechanism that drives the browser's display has to deal with 'blank siblings', meaning extra work and some penalty in performance. In the interest of efficiency, blanked-out entries should be reused — the mechanism that assigns new-node addresses will have to look for a blank sibling, and use it if it finds one. Even if blank entries are reusable, there is no guarantee that a user will not fill up a tree structure with them before he gets around to needing the addresses again. Alternatively, a no-longer-needed node can be physically removed - this is accomplished by identifying all younger siblings (those with higher-value addresses) and reducing each address by 1. This is a simple text manipulation procedure applied to the appropriate tokens. It should be noted, however, that the procedure can become a burden when tokens have been added to data-objects, because all affected tokens in the application database must be adjusted.

Another advantage of this token-based process is that it promotes the ability to perform a complicated editorial function: moving a node (and its descendants) to a new parent. The overhead associated with this service in a "gappy" tree structure is daunting. The decision to adopt the physical removal protocol means that, by definition, there will never be gaps in the sibling-level address scheme. Without gaps, the simplest method of creating a token for a new node (where this discussion began) can be adopted. Populating the Navigation Browser The hierarchical display is refreshed in response to two events, an internal event wherein the user clicks on a displayed node, and an external event wherein a device or application generates a token for display (e.g., the user's web browser loads an enabled web page). The display is refreshed using navigation information loaded from storage (IndexFiles) to active memory (IndexLists); both storage and memory are managed to optimize communications and the use of device resources. The segmented navigation database enables local storage of hierarchically related tokens. Since local (disk) storage capacity can exceed the amount of memory available to a browser application, both stored (cached) data and IndexList require management.

The presentation of token-based information is a two-step process, first a preparation of IndexList and second a display of a token using IndexList. IndexList is a gap-free list of unique tokens and associated data, ordered by token, and held in memory. Figure 1 illustrates management of

IndexList that permits the display of a token. With regard to Figure 1, an indexList supplies display data and other node-related information to the display machinery. A number of efficiencies are facilitated by associating additional data with each token, for example. Moreover, operation in low- memory environments is enhanced by a flag indicating whether or not a node has children (flag set by Editor).

The IndexList contains a record matching the token to be displayed. The simplest implementation queries the source navigation database whenever data is required. This mechanism is improved by copying segments of the navigation database to local storage; a large majority of data requests can be served from this cache. Local copies of navigation data are kept 'fresh' by matching the local-copy date/time stamp to that of the source-data node. While this process is described (and can be performed) here, it is more efficient to perform a freshness test at the navigation database end. This model requests the download of navigation data by transmitting a token and its date/time stamp (if a cached copy exists) to a navigation data server; unnecessary data downloads are eliminated. Navigation data is requested using any appropriate medium and protocol. While there is a clear advantage in caching as much data as possible, it is also appropriate to limit the storage allocated to such cache. Stored data is identified for purge according to the user's preference. Locally stored navigation database segments should match the source data; a simple management method uses a date/time stamp appended to each node (by Editor). Other flags can be set any time data is loaded into IndexList. Display

The present inventive process includes a token mechanism that supports display interfaces using one or more of the following components: (a) a single list of any number of items; (b) a group of such lists, or (c) a path statement. Usability of a hierarchical interface increases with the number of interface components utilized: the user's understanding of a tree-structure is enhanced by seeing the relationships among similar nodes. The token CBAB@ is most informatively displayed as a group of 5 lists (including a list of children of CBAB@).

(token (token CB@@@ (token CBA@(α . (token CBAB(i (children of

C@@@@ and siblings) and siblings) and siblings) token CBAB@) and siblings)

A 3-list interface would display the same token as follows: (token CBA@@ (token CBAB@ (children of and siblin s and siblin s token CBAB )

This less informative display is augmented by the PathStatement "Earth / Animals /", which completes the identification of the selected node, i this example the PathStatement includes the TextLabels of Tokens C@@@@ and CB@@@.

The illustrated flexibility of display is preferred for the presentation and management of deep tree-structures. Not all devices are equipped with mouse/pointer/stylus interfaces (e.g., current technology digital telephones accept only key-based input). This situation has special importance when the display uses only one list: the single-list presentation can only display a selected node. In contrast to the 3-list presentation above, the single-list interface would look like this: (token CBAB@ and siblings)

Invertebrate

Vertebrate

These degrees of freedom in display are easily illustrated; programmatic implementation is straightforward.

Presentation of the token CBABAAAAAAAWXYZ@ using a 6-list interface (that displays unselected children) maps the interface to the token as follows:

C B AB AAAAA A AW XY Z ®

Listl displays CBABAAAAAAA@ (and siblings)

List2 displays CBABAAAAAAAW®

List3 displays CBABAAAAAAAWX® List4 displays CB AB AAAAAAAWXY®

List5 displays CBABAAAAAAAWXYZ®

List6 displays the children of CBABAAAAAAAWXYZ®

A similarly configured 3-list interface maps to the same token:

C B AB AA A AAA A W XY Z ® Listl displays CBABAAAAAAAWXY® (and siblings)

List2 displays CBABAAAAAAAWXYZ®

List3 displays the children of CBABAAAAAAAWXYZ®

The single-list interface maps thus:

C B A B AAA A A A A WX YZ ® Listl displays CBABAAAAAAAWXYZ® (and siblings)

Deriving the PathStatement associated with any of these groups of lists is similarly straightforward.

Editing and Maintaining the Tree Structure

Having defined a tree structure and tokens that identify nodes in the tree structure, it is necessary to define ways in which a user edits and maintains the tree structure by moving nodes around in the tree structure, adding new nodes, etc. Nodes are added to the tree structure when they are required. This minimizes both file and list sizes, as well as data-handling processing time. The Editor Interface

The overall visual logic of browser, for example, displays sibling groups at each ancestral level, indicates the ancestral path by highlighting selected listbox items, and provides a list of children of this path for the user's selection. This is a great deal of information, much of which is not directly relevant to the editorial process. The Editor interface is delivered as an extension to the browser's interface. It includes a textbox object associated with each listbox object in the browser. Textboxes are populated with the same information as selected in the attached listboxes, and their contents can be modified. The visual logic delivered to the user is unambiguous, and the user can easily anticipate the results of the changes he intends. The Editor interface is hidden when not in use. The Editor comprises of textbox objects, each associated with a specific browser listbox object. It provides an intuitive mechanism for creating, naming, and editing index nodes. It supports a simple mechanism for deleting nodes (and their descendants) or moving families of nodes to a new parent. As the user must be prevented from performing prohibited actions, the Editor interface helps the user do what he wants while preventing him from doing harm. This is accomplished by hiding any textbox objects that are excess to the hierarchical path being displayed.

Populating the Editor

As a sub-unit of the browser, the Editor object's components have direct programmatic access to the properties of the browser's components. The Editor is populated (when it is visible or made visible to the end-user) by an xSet(token) subroutine. Briefly, the xSet( ) subroutine steps through a target token, modifying the contents and values of browser's listboxes, as necessary. If the target value is different from the currently displayed value then the following actions are taken: (1) The Value property of the appropriate textbox object is set equal to the TextLabel displayed in its linked listbox; (2) The textbox object's Visible property is set to an expression that evaluates to a true/false condition; and (3) The expression noted above functions by comparing the location of the first zero-value character in the target token to the token position being processed.

The following information is delivered to the end-user: (1) If a selection is highlighted in a browser listbox, the corresponding Editor textbox object contains the same data - permitting the user to edit the TextLabel displayed. (2) If a list of TextLabels is displayed in the browser listbox but no item is selected, the corresponding Editor textbox object is empty - permitting the user to add a new child node to the list of siblings visible in the browser. (3) If the browser's listbox is empty because no children have been assigned to its parent, the corresponding Editor textbox object is empty - permitting the user to add the first child node. (4) If the browser's listbox is empty because no parent has been selected, the corresponding Editor textbox object is hidden - preventing the user from attempting to perform a prohibited action. Reacting To Editorial Events

For the purposes of this discussion, a CommandButton object is included with each Editor textbox, providing a simple method for the end-user to initiate an editorial process according to his instructions. These processes include the following:

Editing a node TextLabel (renaming a node).

Adding a node (addressing and naming a new node).

Deleting a node (and all its descendants).

Moving a node (and its descendants). The PathStatement Interface

The browser is an elegant solution to the problem of delivering understandable and useful hierarchical information to the end-user. It also fills a more important role - logical interaction with the user. There are times, however, that the user does not need such a rich set of functions. The PathStatement object displays a hierarchical path expressed as a text-phrase, in the following format: Great Grandparent - Grandparent - Parent - Me

This method offers several advantages over a common browser function:

(1) It documents the tree structure without any additional overhead;

(2) It produces a very compact display; (3) It permits multiple occurrences of itself.

The PathStatement object is a simple textbox populated by a system function that converts a token to a clear-text descriptive phrase (PathPhrase) without graphic visual content. PathPhrases are compact and can be displayed within data records or used by other end-application processes. As part of the end-application user interface, the PathStatement provides the mechanism by which an underlying datum (the token) is edited. Multiple instances of the PathStatement can be dropped into an end-application user-interface Populating the PathStatement Object

As noted, the end-user derives his first benefit in understanding an organizing scheme from a simple statement of the hierarchical path. Constructing such a statement (PathPhrase) is based on a straightforward manipulation of the token - using the example of token 'BBB@@@@@' :

Determine l^st-level token ('B@@@@@@@')

Find token in IndexList( )

Store TextLabel ( = IndexList(n, 1)) to a string variable

Add a delimiter ' - ' Determine 2^Dd-level token ('BB@@@@@@')

And so forth ... then

Display the string variable Note that the process is complete the first time the token position contains a zero-value character. The PathPhrase is displayed in a textbox or can be output to a reporting/printing procedure of the end- application. When presented in a textbox object, the object's On-Click event can be used to display an instance of the browser delivering its display of the underlying token. The browser hosts the Editor sub-object, which is available to the end-user on demand. In this way a family of user-interface objects delivers whatever level of functionality is needed, when it's needed. But not until it's needed - information overload confuses the user and inhibits communication. Navigating the Tree Structure to Find Information

The browser is a multi-component object used as an adjunct to an end-application's user interface. The browser interface consists of a number of visually related, physically contiguous list- box objects. Functions:

(1) To display descriptions of related index nodes. (2) To capture user input.

(3) To translate the displayed hierarchical selection to an token.

The browser object can be adjusted to the end-user's language preference. The browser object can be linked to any number of IndexLists. SQL Queries

The token concept leads directly to elegant database queries. Locating groups of data objects can be as simple as the following partial SQL statements indicate:

WHERE AddressFieldl = 'ABC@@@@@' produces records addressed 'ABC@@@@@'. WHERE AddressFieldl LIRE 'ABC?@@@@' produces the first list plus the children of

'ABC@@@@@'

WHERE AddressFieldl LIKE 'ABC?????' produces the first list plus every descendant of

ΆBC@@@@@'.

The applications described above are very powerful when used with complicated hierarchical organizing frameworks. They demonstrate two methods of access to end-apphcation data: finding very specific information in a large database and finding large families of related data objects. They also demonstrate an efficient and logical drill-down query mechanism. Using the PathStatement Object

A most productive use of the Invention is based on adding information about organization (the hierarchical path in the form of a token) to individual data objects. The PathStatement is a convenient and efficient means of displaying this information in a database application's user-interface. Further, if data objects are organized using more than one hierarchical framework the PathStatement displays in multiple occurrences, extending the value (and simplicity) of the application interface. When the token is used as data (appended to an application data-object). The PathStatement object is enabled to communicate with the browser in order to replace the data-object' s token with a new one. This connection is the most efficient method of editing the data-object's token field in the end-application.

In the discussions that follow, common programming functions and procedures are used illustratively, without reference or restriction to any particular programming language. The IndexFile contains records composed of tokens and TextLabels. There is one record for each populated node of the underlying tree structure. The Run-time IndexList is a string array that contains 3 data for each IndexFile record:

IndexList(n₅ 0) contains a node's token.

IndexList(n, 1) contains a node's TextLabel.

IhdexList(n, 2) contains a list of the node's children. The Run-time IndexList is populated using the following logic:

SUB Loadfιle(I_ndexFile); OPEN IndexFile;

Determine the number of records in IndexFile; DIMENSION IndexList(NumberOfRecords, 2) AS STRING; REM Populate the root IndexList entry;

IndexList(0, 0) = '@@@@@@@@'; FOR n = 1 TO NumberOfRecords; GET RECORD n REM Populate current token and TextLabel IndexList(n, 0) = token IhdexList(n, 1) = TextLabel. REM Identify and locate parent node's IndexList entry

ParentAddress = token; MID$( ParentAddress, (TNSTR(ParentAddress, '@') -1), 1) = '@';

FIND IndexList(p, 0) = ParentAddress. REM Add current information to parent node's childlist

IndexListφ, 2) = IndexList(p, 2) + token + ';' + TextLabel + ';';

NEXT n; CLOSE IndexFile;

END SUB; As seen above, each record datum in IndexFile appears twice in IndexList( ): token and TextLabel are stored in IndexList(n, 0) and IndexList(n, 1), and the token/TextLabel pair (plus 2 delimiter characters) is stored in IndexList(p- 2). Understanding this characteristic permits the programmer to anticipate the overall size of IndexList( ). If the overall size (including an allowance for new nodes added by the user at run-time) exceeds the system-imposed capacity of a string array, IndexList( ) may be divided into as many sub-lists as necessary. This is accomplished by: adopting simple naming conventions for IndexList sub-lists; populating sub-lists with linear descendant families of hierarchical nodes; recording the value of the first node token and SubListName in a mapping table; and referring SubListName( ) in place of IhdexList( ). In practice, this is a trivial procedure and is assumed to apply whenever necessary without further reference.

Multiple fridexLists are created and populated at run-time. For the purposes of this discussion, it is assumed that separate hierarchies are named ' 1', '2', '3 ', and so forth. The easiest naming convention to apply to multiple IndexLists is to define them as '1( )', '2( )', '3( )', and so forth (where the numerals are string characters). There are a number of methods by which an array element may be located (and moved-to) based on some search criterion. As used above, 'FIND' refers to any method. Implementation of the FIND mechanism is a commonly addressed programming issue. There are a number of methods that may be used to determine the number of records in IndexFile.

The browser is the principal interface into a hierarchal index. It delivers a multi-faceted view of the elements of the index in a simple and logical way, inviting user interaction. It is composed of a set of contiguous listbox objects that are repopulated in response to two types of events: the user clicking on a browser element; or the user clicking on a PathStatement object embedded in an end- application interface. The browser is populated by a public subroutine called, for the present discussion, 'xSet'. Multiple IndexLists are created and populated at run-time. The identity of the IndexList used to populate the browser is provided as an additional numeric character concatenated to the front of the token. The browser object's Tag property contains the complete address associated with its current display (OldAddress).

In response to an event, the subroutine xSet is called and the value of the new token to be displayed (NewAddress) is provided. When the display has been completely repopulated, the browser's Tag property is set equal to NewAddress (including, as noted above, the appropriate IndexList identifier as the leading token-character).

Responsiveness to user interaction must be logical, predictable, and very rapid to avoid distracting the user from his real work: using the end-application and working with its interface. Several optimization techniques are employed in the service of responsiveness. Program flow is determined by transforming and comparing the old token to the new token. The browser listboxes require repopulation and are identified by transforming and comparing the old token to the new token - - only the necessary listboxes are repopulated. Every element in IndexList( ) includes a set of token/TexfLabel pairs associated with each of the node's children. This list, constructed by the LoadFile subroutine, is formatted to be used as the Rowsource property of the node's child listbox. No other formatting or processing is required.

In cases where the NewAddress refers to a different IndexList than the one currently displayed, the browser requires more thorough repopulation. This non-standard repopulation is forced by redefining the value of the old token. The Editor object is an adjunct to the browser. In the interest of programmatic efficiency the following routine populates both the browser and Editor (when the Editor is visible).

PUBLIC SUB xSet(NewTag)

DIMENSION OldTag AS STRING

DIMENSION SubTag AS STRING DIMENSION TextLabel AS STRING

DIMENSION ParentTag AS STRING

DIMENSION ParentCL AS STRING

DIMENSION n, nn AS INTEGER REM Determine if source IndexList has changed. If so, then modify OldTag as required to force a complete repopulation of the browser.

OldTag = NavigatorObject.Tag IF Left$(NewTag, 1) o Left$(OldTag, 1) THEN nn = !NSTR(OldTag, "@")

FOR n = 2 TO nn: M_D$(OldTag, n, 1) = LEFT$(OldTag, 1): NEXT n END IF

REM Step through NewTag, repopulating Navigator elements as necessary.

FORn= 2 TO 9

If MTD$( NewTag, n - 1, 1) o MTD$( OldTag, n - 1, 1) THEN

SubTag = M_D$(Left$(NewTag, n-1) + "@@@@@@@@", 2, 8) REM find and load the variable 'ParentCL ' using the appropriate IndexList, then populate the current listbox's Rowsource property

FIND IndexList(nn, 0) = SubTag

IF IndexList(nn,2)oParentCL THEN ParentCL=IndexList(nn,2) ELSE ParentCL=""

Listbox(n).RowSource = ParentCL END IF REM If NewTag is included in the population oflistbox(n) then populate the listbox's Value property.

If LEFT$(NewTag, n) o Left$(OldTag, n) THEN Listbox(n).Value = MID$(LEFT$(newstamp, n) + "@@@@@@@@"₅2, 8)

REM If the Editor is visible (a condition that may be determined programmatically in a number of ways) then populate the textbox's Value property with the appropriate information and adjust the object's visibility as necessary.

IF EditorObject is visible THEN TextBoxfn) = Listbox(n).Column(l)

TextBox(n).Visible = (n <= (INSTR(SubTa , "@")) + 1)

CommandButton(n)Nisible - TextBox(n)Nisible

END IF

END IF NEXT

REM Store the new-display ListFile/token string in the Navigator's Tag property

NavigatorObjectTag = NewTag

END SUB

There are various mechanisms by which hierarchical indexes are created and modified. These mechanisms can be applied, whenever necessary, by an application developer or the end-user of his work. Four editorial actions are described: (1) editing a node's TextLabel; (2) adding a new node; (3) deleting a node (and its descendants, as required); and (4) moving a family of nodes. All four editorial actions follow the same path: first, allowable editing alternatives are presented to the user; next, edited content and process instructions are received from the user; next, the IndexList is modified; and finally the IndexList is saved to IndexFile.

The IndexList is a simple string array; modifying its contents can be performed in many ways. The IndexFile is generally nothing more than a disk copy of the IndexList. Because it contains minimal information in efficient format, it can reside in a wide range of places, for a wide variety of reasons. For example, it can be stored locally on the end-user's computer using any storage device. Alternatively; it can reside on a network server - it is downloaded and copied to memory only once, eliminating unnecessary communication traffic. It can reside with equal efficacy on an Internet server and downloaded in the normal way using a modem or similar device.

Finally, there are two techniques that can be used to synchronize IndexList and IndexFile. IndexList differs from IndexFile in one important way - it includes information about the group of children associated with each hierarchical node. All changes applied to a node are recorded in two places in IndexList (at the location of the change itself and at its occurrence within the list of its parent's children). While this is not a heavy burden, the same result can be achieved by simply reloading IndexList from the updated IndexFile. Editing an existing TextLabel uses a textbox object. When the user has completed his entry, control of the process passes to the system. Control is passed in a number of ways: a CommandButton can be clicked, the TextBox's On Lost Focus property can be used, or other methods can be applied by the application programmer. The browser listbox Value property contains the token of the node whose TextLabel has changed. That address is located in IndexList using any appropriate method. The label data for that address is updated and the update is saved to IndexFile. The end-application's data objects are not affected by this process.

A new node is added to the index when the user types a TextLabel into an empty Editor textbox. A new token is constructed, and the token/TextLabel pair is added to IndexList. IndexList is re-sorted using any standard programming mechanism and saved to IndexFile. The end-application's data objects are edited in the normal way to include the new token.

A node is deleted by the user 'blanking-out' an existing TextLabel. Because any TextLabel displayed in the Editor can be 'blanked-out', the affect on descendant nodes (if any) is considered. The node to be removed is located in IndexList using the token supplied by browser. If the node has no children (ϊndexList(n, 2) = NULL) the record can be removed from IndexList. If children exist, then the user will decide to delete the node's descendants, to move them to a different parent node, or to cancel the procedure and think about it. It should be assumed that the node has been assigned to database objects which will be 'orphaned' by the procedure. The end-application designer will identify and implement the logic associated with this characteristic. A preferred method of managing index data is to avoid discontinuities in the addresses of sibling groups. Siblings of the deleted node are identified using browser's listbox Rowsource property. Tokens that require adjustment include the younger siblings of the deleted node and all their descendants. The adjustments are straightforward transformations applied to this group of tokens.

Consider the tree structure discussed earlier in this document, and assume that the nodes listed constitute the entire tree structure.

Removing the node addressed 'D@@@@' is trivial because it has no children and is also the last entry in the sorted tree structure. Removing the node addressed 'B@@@@' requires readdressing practically everything (even though 'B@@@@" has no children), because younger siblings and all of their descendants are affected by the deletion. That is, 'C@@@@' becomes the new 'B@@@@', 'CA@@@' becomes 'BA@@@', 'CB@@@' becomes 'BB@@@\ 'CBA@@' becomes

'BBA@@', and so on, until 'D@@@@' has been changed to 'C@@@@'. Several features of this process are noteworthy: (1) Because IndexList is sorted by token, the group of younger siblings and their descendants is identified as all tokens that are greater than 'B@@@@' . (2) The nodes to delete are identified using the template 'B????'. (3) In all cases, only a single component of the affected tokens is changed, and the component's position is determined by the deleted node's address — the rightmost non-zero character of 'B@@@@' is in position 1 of 5. Changes are applied at position 1 of the affected tokens.

Removing 'CBA@@' is a somewhat different proposition — younger siblings of 'CBA@@' and their descendants comprise a much smaller group. If we assume that all direct descendants of a deleted node are also deleted, then 'CBA@@', 'CBAA®', 'CBAB®', 'CBABA', and 'CBABB' go away automatically.

The nodes to delete are represented by the template 'CBA??'. Younger siblings of 'CBA@@' are read directly from browser's listbox Rowsource property. After 'CBA@@' and its descendants have been removed, the total (hypothetical) group of addresses requiring modification includes everything greater than 'CBA@@' and less than 'CC@@@'. Two addresses fit that description:

'CBB@@' and 'CBC@@'. 'CBB@@' becomes the new 'CBA@@' and 'CBC@@' becomes 'CBB@@'. IndexList is adjusted, then saved to IndexFile. The end-application's data objects should also be examined. The process, after processing orphaned data objects in some predetermined way, identifies the data objects that contain index addresses needing adjustment and applies the same transformation to their tokens.

This example includes the important assumption that deleting a node also deletes all of its direct descendants. The alternative is to move the descendants to another position in the tree structure. The only additional information required is the new parent node's address. This can be done, for example, with an interrupt message to the user prompting him to click the destination parent. The table below illustrates this process using a more complicated tree structure. The children of some node (and all their respective descendants) will become children of a new parent. This is a simple procedure if the new parent has no other children. But if elder children already exist, then a little more work is required.

The table illustrates the process of deleting 'CAB@@' and moving its descendants to the new parent 'AA@@@'. The process is accomplished using 'add node' and 'delete node' procedures in succession. The first step is to identify and reassign descendant nodes that will be orphaned by the deletion. The second step is to perform the deletion and adjust all tokens affected by the deletion. The final step is to re-sort IndexList and save it to IndexFile.

Preferably, the invention provides a process to add tokens to the data objects of some application. Some of these tokens are adjusted to their new values. The data objects in question are identified using straightforward SQL queries or sorting techniques based on the original values of the modified tokens. Appropriate new token values are inserted in the data objects, and the process of moving the nodes is complete.

The PathStatement object is dropped into an end-application interface as a textbox. The Value property of the textbox object is set equal to a public translating function that accepts a token as input and constructs a path phrase for delivery to the user. The translating function is also called to produce a path phrase for other end-application purposes (reporting, etc.). Multiple IndexLists are created and populated at run-time. The identity of the IndexList to be used by the function is passed as an additional numeric character concatenated to the front of token. The path phrase is built using an iterative process. The completed path phrase contains unwanted leading-characters (' - ') and is adjusted in the last line of the function.

FUNCTION xPand(token)

DIMENSION SubTag AS STRING DIMENSION PathPhrase AS STRING DIMENSION Position, n AS INTEGER dexListName = LEFT$(token, 1) token = RIGHT$( token, 8) LastPosition = INSTR(token, '@') n = 0 FOR Position = 1 TO LastPosition

SubTag = LEFT$(LEFT$(token, Position) + "@@@@@@@@",) FIND IndexLisfName(n. 0) = SubTag PathPhrase = PathPhrase + ' - ' + ϊndexList(n, 1)

NEXT Position xPand = MID$(PathPhrase, 4) END FUNCTION

The PathStatement object is associated with an underlying token. When the PathStatement is incorporated into an end-application interface, a user event (a mouse chck on the object, for example) calls the public routine that populates the browser. This routine accepts the PathStatement' s underlying token as its NewTag value.

The likelihood of multiple hierarchical frameworks being applied to individual database objects (and the ease with which this can be accomplished) defines several requirements: (1) the end- application interface should contain a PathStatement object for each tree structure applied to its data objects; (2) each PathStatement should refer to a single, specific IndexList; and (3) the browser is populated using the appropriate IndexList. This is a multi-process operation involving a number, of distinct interactions.

Discussed in chronological order, a simple description of the processes follows. This example assumes that only one token has been incorporated in the end-application data object. The user interacts with his application's various display and editing interfaces. When tokens have been added to the application's data objects, PathStatement objects are included in those interfaces as well. As noted earlier, the token itself is particularly unfriendly to the user, who requires as clear a statement as possible of the end-datum's place in the database's organizing framework. It is, however, the information that is stored as part of the data object. The user should be able to change an object's token as easily as he can edit the rest of the object's components.

When it becomes necessary to change an object's token the user simply mouse-clicks the PathStatement object embedded in the application's interface. This event passes the PathStatement' s underlying token to the procedure that (re) populates the browser object. The browser is made available to the user in a number of ways: it, too, can be embedded in the application interface; it can be hidden from view and made visible only when it is required; or it can reside and operate (float) outside the application interface. Whichever approach is used, the browser, now populated with its display of the application data object's token, is made visible and receives the system's focus. The user now interacts with the browser to select a new index value for the data object. The browser (like the PathStatement) works with tokens - its output is formatted for direct application to the data object. The user replaces the old token (as displayed by the PathStatement linked to the token stored as part of the application data object) with the new token (displayed by the browser). A simple way to accomplish this is to include a CommandButton object with the PathStatement. An On Click event calls a trivial procedure that replaces the data object's token. If appropriate to the logic of the application interface, the browser is bidden from the user's view until the next time it's needed.

Finally, the PathStatement (populated by a system function) contains the PathPhrase analog of the newly assigned token. The editing process is complete and the application interface is current. EXTENDED CAPABILITIES Multiple Hierarchies

The present invention provides a database architecture and interface elements to support the application of more than one hierarchical scheme to database objects. This is accomplished with minimal overhead. Every AddressField is populated with a character-based token. Every AddressField has its own dedicated PathStatement object in the application user-interface. There is an IndexFile/IndexList for each tree structure used. There is no practical limit to the number of hierarchical schemes that can be applied to a database. Querying based on additional AddressFields is a trivial programming concern. User access to ultra-large databases can benefit from the application of numerous, complicated, and effective hierarchical indexing schemes. Extended Hierarchies

The concept supports the use of very 'deep' hierarchies - that is, addresses much longer than the arbitrarily selected 8-character string. The importance of deep hierarchies is simple to envision. It is not necessary to deliver the entire index structure to a user who does not need it. Tokens, like the families they represent, are truncated before delivery to the user, limiting his access to only those application data objects whose positions in the organizing scheme are visible in the browser.

Application Embodiments

One application is an automated telephone directory service. Telephone directory databases (large proprietary databases that all contain names, addresses, phone numbers, etc.) are organized using multiple hierarchical frameworks (e.g., location, goods/services, occupation). Nodes are identified at the user-end (navigation browser) and tokens are passed to data servers that execute hierarchical queries. The inventive process and databases provide a focused list of specific data items (e.g., a list of addresses (and automatically-diallable phone numbers), for example, the Northern-Italian restaurants on 5^th Avenue in Midtown Manhattan).

Another application is for web navigation. The address of a web page is appended to each node in a navigation database segment (as required: some nodes are used to organize the tree-structure and may not be associated with a particular web page). Descriptive information (text or small multimedia files appended to the navigation database record (token)) is displayed in a viewer embedded in the navigation browser. End users request web content (pages delivered to their web browsers) using the navigation browser (without downloading intermediate web pages that contain links and site maps). Content (a site of web pages) is organized according to multiple points of view (more than one token points to a particular web page) providing more effective user access; content-delivery resources (web server requests, communication volume) are conserved.

Another application, for example, is a wireless commerce directory based upon, for example, menu-based navigation (no text input required - important for hand-held devices, esp. phones). Any menu node can point to executable multi-media files or information access functions. Display services are provided by device functions, 3rd party applications, or extensions to the navigation browser interface. The inventive databases and process provides a platform-independent bridge between providers information and their customers' devices.

Claims

1. A process for creating a database of potentially unlimited size, comprising:

(a) obtaining an existing database or data objects having a plurality of records;

(b) creating a new field in each database record; and

5 (c) populating each new field with a token, wherein the token is a string data type of variable length.

2. The process for creating a database of potentially unlimited size of claim 1 wherein the existing database is selected from the group consisting of a telephone directory, an email address directory, and address book, a world wide television directory and parts thereof, a mobile commerce 0 directory, and combinations thereof.

3. The process for creating a database of potentially unlimited size of claim 2 wherein the existing database is a combination of a telephone directory, email address directory and address book.

4. The process for creating a database of potentially unlimited size of claim 1 wherein the records of the plurality of records are selected from the group consisting of telephone datum, email 5 datum, address datum, mobile commerce datum, television programming datum, and combinations thereof.

5. The process for creating a database of potentially unlimited size of claim 1 wherein the token data type is in a multi-dimensional subscript.

6. A database of potentially unlimited size, comprising: Q (a) an existing database or data objects having a plurality of records in a first field or plurality of fields; and

(b) a second field or an additional field having tokens therein, wherein the token is a string data type of variable and potentially unlimited length.

7. The database of potentially unlimited size of claim 6 wherein the existing database is 5 selected from the group consisting of a telephone directory, an email address directory, and address book, a world wide television directory and parts thereof, a mobile commerce directory, yellow page directory, web sites, classified advertisements, and combinations thereof.

8. The database of potentially unlimited size of claim 7 wherein the existing database is a combination of a telephone directory, email address directory and address book. 0

9. The database of potentially unlimited size of claim 6 wherein the records of the plurality of records are selected from the group consisting of telephone datum, email datum, address datum, mobile commerce datum, television programming datum, and combinations thereof.

10. The database of potentially unlimited size of claim 6 wherein the token data type is in a multi-dimensional subscript. 5 11. A navigation database of unique tokens and related data, potentially unlimited in size, comprising:

(a) a plurality of tokens ordered by token, wherein the token is a string data type of variable and potentially unlimited length; and (b) related data associated with each token, wherein the related data are a text label of each token.

12. The navigation database of unique tokens and related data, potentially unlimited in size of claim 11 wherein the related data further comprise additional information associated with the token.

13. The navigation database of unique tokens and related data, potentially unlimited in size of claim 12 wherein the related data are selected from the group consisting of URLs date/time stamps, flags (indicating whether a token has children), other tokens, stand alone files, embedded data files, audio or video files, and combinations thereof.

14. The navigation database of unique tokens and related data, potentially unlimited in size of claim 11 wherein the token optionally further comprises descendents in a hierarchical organization.

15. A segmented database, comprising a segment of a navigation database segmented according to descendents of a token, wherein the navigation database comprises

(a) a plurality of tokens ordered by token, wherein the token is a string data type of variable and potentially unlimited length, and wherein at least one token further comprises descendents in a hierarchical organization; and

(b) related data associated with each token, wherein the related data are a text label of each token.

16. The segmented database of claim 15 wherein the related data further comprise additional information associated with the token.

17. The segmented database of claim 16 wherein the related data are selected from the group consisting of URLs date/time stamps, flags (indicating whether a token has children), other tokens, stand alone files, embedded data files, audio or video files, and combinations thereof.

18. A process for segmenting a navigation database, comprising:

(a) structuring a navigation database, wherein the navigation database comprises (i) a plurality of tokens ordered by token, wherein the token is a string data type of variable and potentially unlimited length, and wherein at least one token further comprises descendents in a hierarchical organization; and (ii) related data associated with each token, wherein the related data are a text label of each token; and

(b) dividing the navigation database into a plurality of bounded files according to descendents of a token having common portions of the string of data in each token of the descendents.

19. The process for segmenting a navigation database of claim 18 wherein the related data further comprise additional information associated with the token.

20. The process for segmenting a navigation database of claim 19 wherein the related data are selected from the group consisting of URLs date/time stamps, flags (indicating whether a token has children), other tokens, stand alone files, embedded data files, audio or video files, and combinations thereof.

21. A process for adding one or a plurality of records to a navigation database, wherein a record comprises a token, text label, and related data associated with the token, comprising editing data associated with a particular token, wherein the editing function is selected from the group consisting of creating a new token, modifying an existing token, deleting a token, moving a token and its descendents, and combinations thereof.