WO2002052443A1 - Etiquettes d'adresse pour une structure de donnees hierarchique et procede de creation et d'utilisation correspondant - Google Patents

Etiquettes d'adresse pour une structure de donnees hierarchique et procede de creation et d'utilisation correspondant Download PDF

Info

Publication number
WO2002052443A1
WO2002052443A1 PCT/NL2000/000954 NL0000954W WO02052443A1 WO 2002052443 A1 WO2002052443 A1 WO 2002052443A1 NL 0000954 W NL0000954 W NL 0000954W WO 02052443 A1 WO02052443 A1 WO 02052443A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
database
data
tokens
related data
Prior art date
Application number
PCT/NL2000/000954
Other languages
English (en)
Original Assignee
Hip Foundaton N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hip Foundaton N.V. filed Critical Hip Foundaton N.V.
Priority to PCT/NL2000/000954 priority Critical patent/WO2002052443A1/fr
Publication of WO2002052443A1 publication Critical patent/WO2002052443A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9027—Trees

Definitions

  • 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.
  • the present invention provides a process for creating a database of potentially unlimited size, comprising:
  • 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.
  • the existing database is a combination of a telephone directory, email address directory and address book.
  • 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.
  • 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
  • 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.
  • the existing database is a combination of a telephone directory, email address directory and address book.
  • 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.
  • 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
  • related data associated with each token wherein the related data are a text label of each token.
  • the related data further comprise additional information associated with the token.
  • 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 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
  • the related data further comprise additional information associated with the token.
  • 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:
  • 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
  • the related data further comprise additional information associated with the token.
  • 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.
  • Figure 1 illustrates management of IndexList that permits the display of a token.
  • the present invention is a network of related elements.
  • 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.
  • a dedicated interface will help to explain to understand and use tree structures.
  • Using a token mechanism to present a tree structure 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.
  • editor applications include features that create and modify tokens and populate navigation database fields with data and pointers.
  • 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).
  • 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
  • Hierarchical categorization 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
  • each list element has its own discrete family of descendants.
  • each element (except the ends of each family line) can have 4 children.
  • 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 2 +4 3 +4 4 +4 5 ).
  • 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).
  • 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).
  • the system-imposed size limit of a simple text array when one begins populating elements with words like 'Earth' and 'Animals' one quickly reaches the system-imposed size limit of a simple text array.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • standard protocols such as, TCP/IP, HTTP, FTP
  • 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.
  • 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.
  • 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).
  • 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.
  • Web server is the computer program (housed in a computer) that serves requested HTML pages or files.
  • 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.
  • SQL American National Standards Institute's standard ANSI X3.135-1986.
  • 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”.
  • Tables 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
  • URL 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 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.
  • Web site refers more specifically to a web site of the World Wide Web. In general, a Web site corresponds to a particular
  • Internet domain name 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.
  • a corporate "intranet” i.e., an internal network that uses standard Internet protocols
  • 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
  • conventions such as HTTP and HTML
  • Web World Wide A distributed, global hypertext system, based on a standard set of protocols Web, Web
  • Web server a program which responds to such requests by returning ("serving") Web documents.
  • Hierarchies Tree Structures and Tokens
  • Nodes in a hierarchy 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 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.
  • the end of the string of characters is the point where there are no further descendants.
  • 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
  • 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.
  • 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.
  • 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.
  • IndexFiles navigation information loaded from storage
  • IndexLists active memory
  • 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.
  • 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.
  • 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@).
  • 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 )
  • 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)
  • a similarly configured 3-list interface maps to the same token:
  • the single-list interface maps thus:
  • 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.
  • 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.
  • the xSet( ) subroutine steps through a target token, modifying the contents and values of browser's listboxes, as necessary.
  • 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
  • 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.
  • 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
  • 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
  • the PathPhrase is displayed in a textbox or can be output to a reporting/printing procedure of the end- application.
  • 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:
  • 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
  • Locating groups of data objects can be as simple as the following partial SQL statements indicate:
  • WHERE AddressFieldl 'ABC@@@@@' produces records addressed 'ABC@@@@'.
  • 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.
  • 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.
  • 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 5 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:
  • IndexFile Determine the number of records in IndexFile; DIMENSION IndexList(NumberOfRecords, 2) AS STRING; REM Populate the root IndexList entry;
  • FIND IndexList(p, 0) ParentAddress. REM Add current information to parent node's childlist
  • IndexList ⁇ , 2) IndexList(p, 2) + token + ';' + TextLabel + ';';
  • IndexList( ) 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.
  • 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).
  • the subroutine xSet is called and the value of the new token to be displayed (NewAddress) is provided.
  • the browser's Tag property is set equal to NewAddress (including, as noted above, the appropriate IndexList identifier as the leading token-character).
  • 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.
  • 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).
  • 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.
  • 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
  • Listbox(n).RowSource ParentCL END IF REM If NewTag is included in the population oflistbox(n) then populate the listbox's Value property.
  • 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.
  • 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.
  • 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.
  • 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
  • IndexList is sorted by token, the group of younger siblings and their descendants is identified as all tokens that are greater than 'B@@@@' .
  • the nodes to delete are identified using the template 'B????'.
  • 'CBA@@' 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:
  • 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.
  • 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.
  • SubTag LEFT$(LEFT$(token, Position) + "@@@@@@@@@”,)
  • FIND IndexLisfName(n. 0)
  • SubTag PathPhrase PathPhrase + ' - ' + ⁇ ndexList(n, 1)
  • the PathStatement object is associated with an underlying token.
  • a user event a mouse chck on the object, for example
  • This routine accepts the PathStatement' s underlying token as its NewTag value.
  • 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.
  • the user 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.
  • 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.
  • 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.
  • 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 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention a trait à une structure de données, et plus particulièrement à des jetons d'adresse utilisés pour adresser des membres d'une structure de données hiérarchique. Cette invention concerne également un procédé d'élaboration de jetons d'adresse, ainsi que plusieurs procédés d'utilisation desdits jetons dans une grande variété d'applications.
PCT/NL2000/000954 2000-12-22 2000-12-22 Etiquettes d'adresse pour une structure de donnees hierarchique et procede de creation et d'utilisation correspondant WO2002052443A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/NL2000/000954 WO2002052443A1 (fr) 2000-12-22 2000-12-22 Etiquettes d'adresse pour une structure de donnees hierarchique et procede de creation et d'utilisation correspondant

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/NL2000/000954 WO2002052443A1 (fr) 2000-12-22 2000-12-22 Etiquettes d'adresse pour une structure de donnees hierarchique et procede de creation et d'utilisation correspondant

Publications (1)

Publication Number Publication Date
WO2002052443A1 true WO2002052443A1 (fr) 2002-07-04

Family

ID=19760731

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NL2000/000954 WO2002052443A1 (fr) 2000-12-22 2000-12-22 Etiquettes d'adresse pour une structure de donnees hierarchique et procede de creation et d'utilisation correspondant

Country Status (1)

Country Link
WO (1) WO2002052443A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014145884A2 (fr) * 2013-03-15 2014-09-18 Locus Analytics, Llc Étiquetage syntaxique dans un contexte spécifique au domaine
US9245299B2 (en) 2013-03-15 2016-01-26 Locus Lp Segmentation and stratification of composite portfolios of investment securities
US10515123B2 (en) 2013-03-15 2019-12-24 Locus Lp Weighted analysis of stratified data entities in a database system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0286110A2 (fr) * 1987-04-09 1988-10-12 Crowninshield Software Système de génération et d'interrogation de base de données par éditeur utilisant une table des matières
EP0977134A2 (fr) * 1998-07-27 2000-02-02 Hewlett-Packard Company Procédé pour l'organisation automatique de données
WO2000014654A1 (fr) * 1998-09-04 2000-03-16 Balaena Limited Base de donnees et methodes de memorisation et d'extraction de donnees
US6052693A (en) * 1996-07-02 2000-04-18 Harlequin Group Plc System for assembling large databases through information extracted from text sources

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0286110A2 (fr) * 1987-04-09 1988-10-12 Crowninshield Software Système de génération et d'interrogation de base de données par éditeur utilisant une table des matières
US6052693A (en) * 1996-07-02 2000-04-18 Harlequin Group Plc System for assembling large databases through information extracted from text sources
EP0977134A2 (fr) * 1998-07-27 2000-02-02 Hewlett-Packard Company Procédé pour l'organisation automatique de données
WO2000014654A1 (fr) * 1998-09-04 2000-03-16 Balaena Limited Base de donnees et methodes de memorisation et d'extraction de donnees

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014145884A2 (fr) * 2013-03-15 2014-09-18 Locus Analytics, Llc Étiquetage syntaxique dans un contexte spécifique au domaine
WO2014145884A3 (fr) * 2013-03-15 2014-10-30 Locus Analytics, Llc Étiquetage syntaxique dans un contexte spécifique au domaine
US9245299B2 (en) 2013-03-15 2016-01-26 Locus Lp Segmentation and stratification of composite portfolios of investment securities
US9361358B2 (en) 2013-03-15 2016-06-07 Locus Lp Syntactic loci and fields in a functional information system
US9471664B2 (en) 2013-03-15 2016-10-18 Locus Lp Syntactic tagging in a domain-specific context
US9646075B2 (en) 2013-03-15 2017-05-09 Locus Lp Segmentation and stratification of data entities in a database system
US9910910B2 (en) 2013-03-15 2018-03-06 Locus Lp Syntactic graph modeling in a functional information system
US10204151B2 (en) 2013-03-15 2019-02-12 Locus Lp Syntactic tagging in a domain-specific context
US10515123B2 (en) 2013-03-15 2019-12-24 Locus Lp Weighted analysis of stratified data entities in a database system

Similar Documents

Publication Publication Date Title
US7428705B2 (en) Web map tool
US8117226B2 (en) System and method for virtual folder sharing including utilization of static and dynamic lists
EP0774722B1 (fr) Système de recouvrement d'informations
JP3836928B2 (ja) データベース処理方法
US6131098A (en) Method and apparatus for a database management system content menu
US6434546B1 (en) System and method for transferring attribute values between search queries in an information retrieval system
KR100446183B1 (ko) 데이터베이스 시스템
US7512586B2 (en) System and method for filtering and organizing items based on common elements
US7526483B2 (en) System and method for virtual folder sharing including utilization of static and dynamic lists
US7685136B2 (en) Method, system and program product for managing document summary information
US20010003455A1 (en) Method, system and graphic user interface for entering and editing filter conditions for filtering a database
US20080319954A1 (en) Index for data retrieval and data structuring
US7209928B2 (en) Information organization and navigation by user-generated associative overlays
JP2000090076A (ja) ドキュメント管理方法およびドキュメント管理システム
EP1342177A1 (fr) Proc d de structuration et de recherche d'information
JPH07319917A (ja) 文書データべース管理装置および文書データべースシステム
JP2011181106A (ja) Ｘｍｌデータ記憶、クエリー再書込、ビジュアライゼーション、マッピング、および参照のための方法および装置
Hirata et al. Object-based navigation: An intuitive navigation style for content-oriented integration environment
WO2003048917A1 (fr) Exploration d'informations assistee fondee sur un localisateur
JP2004302981A (ja) 電子データ管理システム
WO2002052443A1 (fr) Etiquettes d'adresse pour une structure de donnees hierarchique et procede de creation et d'utilisation correspondant
WO2004063941A1 (fr) Procede et dispositif pour acceder a une base de donnees
EP1014283A1 (fr) Système et méthode basées d'intranet pour catalogage et publication
JPH11282882A (ja) 文書管理方法
JP2004126770A (ja) 構造化文書検索方法、構造化文書検索システム及び構造化文書データベース管理装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP