Abstract:
The present invention advances the prior art of the content menu, an end-user database interface which organizes relational data according to the data and data relations from in the database. It does this by disclosing how to deploy the Binary Attribute Relation or BAR as meta-query data, and by disclosing how Binary Attribute Data Relations or BADR are derived from the BAR query, a primitive retrieval operation. All three new concepts: the BAR, the BADR, and the BAR query, are compact in a mathematical sense, as they represent each of their respective subject material in the most fundamental or primitive way, not matter whether it is a unit of meta-query data, data relations, or the query statement on which they are derived. These developments advance the art of the content menu, most notably with the art of its authoring system, by adding new flexibility to its functionality, as in the case of its runtime list menus, by making the authoring system more well integrated and easier to maintain, and by laying the foundation for extending its capabilities to handle other types of data models and data structures.

Description:
[0001]      
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 References Cited 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 6,301,583 
                 Oct. 9, 2001 
                 Zellweger 
               
               
                 6,279,005 
                 Aug. 9, 2001 
                 Zellweger 
               
               
                 6,243,700 
                 Jun. 5, 2001 
                 Zellweger 
               
               
                 6,131,100 
                 Oct. 10, 2000 
                 Zellweger 
               
               
                 6,131,098 
                 Oct. 10, 2000 
                 Zellweger 
               
               
                 6,061,692 
                 May 9, 2000 
                 Thomas, et al. 
               
               
                 5,664,173 
                 Sep. 2, 1997 
                 Fast 
               
               
                 5,630,125 
                 May 13, 1997 
                 Zellweger 
               
               
                   
               
             
          
         
       
     
       REFERENCES 
       [0000]    
       
         Abiteboul, Serge, Richard Hull, and Victor Vianu,  Foundations of Databases . Reading, Mass.: Addison-Wesley Publishing Company, 1994, p. 37. 
         Atzeni, Paulo, Stefano Ceri, Stafano Paraboschi and Riccardo Torlone.  Database Systems, Concepts, Languages, and Architectures . Berkshire, England: McGraw-Hill Publishing Company, 2000, pp. 21-22. 
         Biggs, Norman. Discrete Mathematics. Oxford, England: Oxford University Press, 1996, p. 194. 
         Burgin, Mark. “Theory of Names Sets as a Foundational Basis for Mathematics” in Diez, A., J. Echevarria, A. Ibarra (eds.) “Structures in Mathematical Theories, Reports of the International Symposium.” Universidas del Pais Vasco: Sep. 25-29, 1990, p 417. 
         Codd, E. F. A Relational Model of Data for Large Shared Data Banks.  Communications of the ACM,  13(6), 1970, pp. 377-387. 
         Codd, E. F, Extending the Database Relational Model to Capture More Meaning,  ACM Transactions on Database Systems,  4(4), 1979, pp. 397-434. 
         Date, C. J.  An Introduction to Database Systems . Eighth Edition. Boston, Mass.: Addison-Wesley, 2004, p. 274. 
         Date, C. J.  Logic and Databases, the Roots of Relational Theory . Victoria, BC Canada: Trafford Publishing, 2007, p. 377. 
         Knuth, D. The Art of Computer Programming, v. 2: Seminumerical Algorithms, Boston, Mass.: Addison-Wesley, 1997, p. 348. 
         Newell, Allen and Herbert Simon, “Computer Science as Empirical Inquiry: Symbols and Search,  Communications of the ACM , March 1976, 19, 3, pp. 113-126. 
         Zellweger, Paul. A Database Taxonomy Based On Data-Driven Knowledge Modeling. (IEEE) KIMAS&#39;05 Waltham, Mass., pp. 469-474. 
       
     
       BACKGROUND 
       [0013]    In 2000, Zellweger (U.S. Pat. No. 6,131,098) introduced a novel way to navigate over database content using a content menu, a database interface which organizes data and data relations found in the database. These data relations takes the form of an open hierarchical data structure (OHDS), a list of nested lists, first described by Zellweger (U.S. Pat. No. 5,630,125) in 1997. The OHDS is similar to the “[LEFT child-RIGHT sibling]” data structure described by Knuth, but Zellweger&#39;s implementation of it goes well beyond the simple functionality of memory management tool. Having its own dedicated GUI, and a comprehensive tool set for managing data-topic lists, the OHDS manages menu data for the content menu, by enabling menu developers to add menu topics either by hand, by automated mapping algorithms that extract data and data relations from the database, or by both methods. 
         [0014]    Over the past decade, the construction of the OHDS served as a conceptual framework for improving the techniques used to support the content menu. The mapping algorithm used to build the OHDS is recursive. Each recursive call extracts a list of data-topics from a database and then adds it to a leaf node in the OHDS. This construction pattern is similar to the tree-growing methodology described by Biggs which mimics the depth-first search, by systematically branching out from each leaf node at the bottom of the structure. By carefully observing these operations, the OHDS provided an opportunity for seeing how runtime data-topic lists could be added to the content menu, along with numerous other improvements, including U.S. Pat. No. 6,234,700 and U.S. Pat. No. 6,301,583. 
         [0015]    Early on Zellweger was able to show how to automatically generate a network of data-topic lists for the OHDS using a dedicated interactive menu (U.S. Pat. No. 6,131,100) and specialized software (U.S. Pat. No. 6,279,005). In U.S. Pat. No. 6,131,100, a newly disclosed GUI enables a menu developer to navigate over a target database and to create a series of “logical” relationships between database attributes which could be represented by a symbolic expression. Program logic disclosed by U.S. Pat. No. 6,279,005 shows how to parse this expression to capture meta-query data, which could then be used to extract lists of data-topics from a target database. Improvements to these advances include U.S. Pat. No. 6,131,098 which parses the symbolic expression and then stores this meta-query data in its own structure, thereby enabling the same meta-query data to be used either to generate a OHDS for the compiled menu data files or to a create list menu in the content menu at runtime. 
         [0016]    The current disclosure introduces a number of new improvements over all this prior art by now focusing on how different types of data relations, identified here as Binary Attribute Data Relations or BADR, contribute to the construction of the OHDS. At the core of this new invention are two fundamental areas of discovery: 1.) a primitive retrieval operation, identified here as the BAR query, which extracts these data relations for the OHDS; and 2.) the ability to classify them according to how they contribute to the construction of the OHDS. 
         [0017]    At this point in this disclosure, it is important to point out how these two discoveries relate to each other. They are, in fact, so closely intertwined with each other, in compact “mathematical” sense, that one discovery could not be made independent of the other. The BAR query, a primitive retrieval operation, lends itself to the OHDS construction; and the construction of the OHDS reveals the nature of data in the relational database and how its data relations or BADR can be enumerated and classified within four distinct, primitive types. 
         [0018]    Clearly, these four different types of data relations or BADR occur routinely in everyday programming, and they could be extracted from a database using less efficient program logic, but they could never be discovered, let alone classified in such a systematic or unified manner, without the BAR query, and without the knowledge of their role in the construction of the OHDS. Therefore, the primary focus of the current invention is to identify these primitive data relations, using the BAR query as a scientific instrument to differentiate one type of data relation from another, when building the OHDS. 
         [0019]    The BAR query is an application of Burgin&#39;s theory of named sets (BNS), a mathematical primitive which is more fundamental than set theory. BNS assumes that all systems are composed of components or subsystems which are logically related by “rules.” In the case of the relational database, the primitive SQL SELECT or BAR query enforces the “rules” between these two attributes (or subsystems), which exposes, in an exact and precise manner, four different types of data relations. 
         [0020]    More specifically, the BAR query highlights a division of labor between input and output and the two different mechanical operations each one represents. An input condition relies on “patterning matching” and output on a “naming” function which distinguishes one pool of output data from another. These two different mechanical operations form the underlying basis for cycling through a chain of interrelated attribute pairs recursively to build the OHDS. 
         [0021]    The primitive data relations introduced by this disclosure occur at the data level between two attributes or fields in a database. As indicated above, they could only be derived from a well-defined, carefully crafted retrieval operation, the BAR query, at the core of the inventor&#39;s recursive mapping algorithm which builds the OHDS. The inventor identifies the logical relationship created by the BAR query between its input and output a binary attribute relation or BAR. The data relations derived from this retrieval operation are identified as binary attribute data relations or BADRs. And, the primitive retrieval operation that exposes them, as mentioned above, is the BAR query. 
         [0022]    With these new concepts in place, this disclosure is now able to identify four basic types of data relations which exist in the relational model. But before proceeding to this disclosure it is important to point out why these data relations have gone completely unnoticed until now. One reason for their obscurity is that the BAR query is a new art, and the data mapping from one attribute to another, using this new art, can appear to be completely unpredictable and arbitrary. 
         [0023]    For example, in a BAR query an input condition, such COLOR=red, represents a single data value associated with the source attribute COLOR. However, hidden under layers of abstraction in the database there may be multiple instances of red at various record or tuple locations. At this high level of abstraction, the source code of the BAR query treats this new input data value as an instance of one. Output from this operation can be one or many, depending upon the number of red locations at lower levels of abstraction, and the number of unique data values associated with the destination attribute. This means that the data mapping between source and destination attributes, or input and output, can take the form of “one-to-one” or “one-to-many,” regardless of the database table declaration or the samples of data considered. 
         [0024]    This arbitrary nature makes these primitive data relations difficult to “see” and to “identify,” particularly through the mathematical lens which dominates today&#39;s theoretical basis for the relational model—set theory—because it has no way of modeling it. One prominent database researcher, CJ Date, has suggested that the relational model is most likely governed by a “new [branch of] mathematics” p. 377, but he does not say anything further on the matter, leaving the details about its structure and operations as an open question for the database research community. But from the perspective of the content menu, all of these data relations play an essential role in the construction of the OHDS, regardless of whether they take the form of “one-to-one” or “one-to-many” relationships. What does makes a difference is whether the BAR query output contains data-topics which are relevant to the end-user or whether this output furnishes links to something which eventually does. Therefore, without the OHDS and the algorithms which support them, the discovery of binary attribute data relations could not have been made. 
         [0025]    A careful analysis of the BAR query and the construction of the OHDS afforded other discoveries as well, including a more precise view of the nature of relational data, namely that it has two aspects: a mechanical-value and a constructed-type, which the inventor identifies by the concept of a meta-symbols. Pattern matching can only occur on symbols which were encoded by mechanical values, a sequence of on/off bits. And constructed-types refer to pools of data symbols accessed by a label or name. This new view of relational data—and all physical symbols on a computer for that matter—sheds new light on today&#39;s understanding of retrieval operations, as all of these operations can now be generalized in an abstract fashion, regardless of the data model or data structure. 
         [0026]    Therefore, all retrieval operations, including the relational query SQL SELECT, can and should be viewed as an interface to an algorithm which has input and output. More importantly, each one of these channels aligns itself with the phenomenon of meta-symbols: with input values deployed for searchers, and output for extracting data from a pool of values which has a name and which is a constructed-type. At the data level, this input and output functionality gives shape and form to the BADR discovered by the inventor, first by showing how they contribute to the construction of the OHDS, with relevant constructed-types providing sibling lists and their corresponding mechanical-values providing the linkage to a leaf node, and then by characterizing these attributes as a source and destination, which implies a logical mapping between these two channels. 
         [0027]    This input and output view of retrieval operations is consistent with the more general concept of query mapping which refers to input and output schema mapping (Abiteboul et al.). However, at this new, deeper view, the mapping refers to query channels and the data and the data relations they expose. This takes us well beyond today&#39;s theoretical understanding of database queries, relational data, and even the notion of physical symbols according to Simon and Newell, as all of these various concepts have never been studied together from the perspective of data relations. 
         [0028]    These two refinements (input and output attributes, and query mapping at the combined attribute and data levels) help clarify and articulate data relations in the relational database. Until now, this area has been unexplored by the research community. By focusing on the data mapping derived from a BAR query and the fact that this output can be either one or arbitrarily many, these primitive data relations start to emerge and unfold when the fully formed OHDS is taken into consideration. And so, this data mapping is purely a constructed artifact which could exist only within the framework of this carefully constructed query, making the discovery of this primitive data mapping the subject for this new art, with the BAR query the predicate and the content menu its object. 
         [0029]    The discovery of binary attribute data relations or BADRs provides an entirely fresh view of the data and data relations in a database, one that lays the foundation for a more tightly integrated program logic that improves upon the prior art in a number of significant ways. First, with the BAR query as the focal point of extracting menu data from an external source, the recursive algorithm that populates the OHDS is now more compact and efficient; it is also considerably easier to maintain. Second, now that the nature of relational data is better understood and more precise, in terms of retrieval operations, improvements could be made to the format of meta-query data and to the way it is collected and stored. Third, by viewing the query operation as having distinct input and output channels, one could separate the BAR query from the algorithms that build the OHDS, thereby enabling the same software component, a primitive query operation, to generate menu data for runtime list menus as well. 
         [0030]    Finally, the discoveries of the BAR and the BADR pave the way for identifying the rules that govern attribute and data relations, and that make pairing two attributes possible. By clarifying these rules, new insights about the nature of data relations can be made. One such insight which can be attributed to the discoveries presented here is that semantic relations at the data relations level, as expressed by BAR query, fall into two broad categories, contextual information and conceptual linkage. Another insight focuses on how different pairs of attributes can create different types of data relations which contribute to the construction of the OHDS. 
         [0031]    What makes this disclosure so exceptional is the fact that the concept of a binary attribute relation or BAR challenges a longstanding position in the literature that advises against considering such types of semantic relations. In 1978, Codd, the inventor of the relational database, argued against extending any semantic analysis within a relational table at the attribute level, because he considered the relational table to be semantically “atomic” p. 413. At best, he was ambivalent about even considering such ideas, as he did not see any point to such speculation, at least from the perspective of a representational primitive in database design. Since then, no one has been able to show how attributes within the same table could form any relevant semantic relationships that could challenge Codd&#39;s strongly worded position. Database researchers have not even considered the possibility that a semantic relationship could exist between two attributes, or that two attributes could form an algebraic relationship that could express their underlying data relations, two specific topics which the present disclosure addresses in a concrete and pragmatic way, with the content menu. 
         [0032]    Therefore, this disclosure breaks new ground by providing hard evidence, from the perspective of the inventor&#39;s content menu, that the BAR is both useful and meaningful. At the attribute or naming level, the input and output functions of the BAR query frame these terms in a type of algebra for meta-query data. At the data level, the BAR query extracts BADRs which provide essential building blocks for constructing the OHDS and conceptualizing its data-topic content as a “database taxonomy”. At this level of abstraction, the attribute, and its underlying data, can now be viewed as a resource which can either describe something, such as the attribute SIZE which can refer to small or medium data-topics, or which can eventually link to an attribute that provides such descriptions, thereby providing to means to classify attributes—and their data—operationally as either conceptual or operational. 
         [0033]    At the data level, this classification is essential in showing how binary attribute data relations or BADR characterize semantic relations, as either contextual information, when two data-symbols both describe something, such as, “Boston” and “Massachusetts,” or as conceptual linkage, when they eventually link to data symbols that do. And so, in the construction of the OHD, all operational data is stripped out, in order to only display data-symbols which serves as topics which can inform end-users about what they can expect to find in the database. Thus, one can see how these two semantic functions complement one another, and how the concepts of the BAR query and the BADR are mutually dependent upon each other, in a seamless and well-integrated way, for the discovery of their respective identities. 
       SUMMARY 
       [0034]    In accordance with one embodiment of the present invention, notably the relational database, this disclosure shows how to improve the technical capabilities and efficiency of the authoring system responsible for the previous art of content menu. These improvements, in turn, lay the foundation for alternative embodiments of the authoring system which can generalize the discoveries disclosed here to extract lists of data from other data models and even data structures. 
     
    
     
       DRAWINGS 
       Brief Description of the Figures 
         [0035]      FIG. 1  depicts the prior art of a content menu, a database interface that organizes database content into a menu system identified as a “database taxonomy.” 
           [0036]      FIG. 2  depicts the client server network apparatus of the present invention. 
           [0037]      FIG. 3  depicts the three software components of the prior content menu: an authoring system that generates menu data files, the menu data files, and a client browser that displays these files in a content menu. 
           [0038]      FIGS. 4   a  through  4   c  depict the target database that will be used to demonstrate this new art. 
           [0039]      FIG. 5  depicts the prior art of the open hierarchical data structure (OHDS) that organizes menu data for the content menu according to data and data relations found in a database. 
           [0040]      FIG. 6  depicts the OHDS storage format for the prior art. 
           [0041]      FIGS. 7   a  through  7   c  depict the prior art of the developers GUI and the software processes used to capture meta-query data which is then used to extract data and data relations from an external database for the content menu. 
           [0042]      FIGS. 8   a  through  8   c  depict the new meta-query data format introduced by this new art based on the concepts of the Binary Attribute Relations (BAR). 
           [0043]      FIG. 9  depicts the client server network apparatus of the present invention, showing the new software components introduced by this disclosure. 
           [0044]      FIGS. 10   a  through  10   c  depicts the flow charts and program control of the algorithms responsible for exposing binary attribute data relations (BADR) in a target database according to the new teaching on BARs. 
           [0045]      FIG. 11  is an example of the source code for a BAR query. 
           [0046]      FIGS. 12   a  through  12   d  graphically depict the four different types of data and data relations found in BADRs. 
       
    
    
     DRAWINGS 
     Reference Numerals 
       [0000]    
       
           5 —content menu 
           6 —list menu 
           15 —server computer 
           18 —client computer 
           22 —authoring system 
           24 —menu data file 
           26 —browser software 
           35 —external database 
           68 —open hierarchical data structure (OHDS) 
           111 —menu developers&#39; interface 
           120 —binary attribute relation (BAR) notation 
           140 —meta-query storage format 
           160 —recursive algorithm 
           210 —BAR query 
           250 —binary attribute data relation (BADR) 
       
     
       DETAILED DESCRIPTION 
       [0062]    An embodiment of the end-user database interface—that is identified as content menu  5 —is depicted graphically in  FIG. 1 . The graphical user interface (GUI)  5  consists of one or more nested topic list menus  6  that display the data and data relations in a database as a list of nested data-topic lists that take the form of a database taxonomy. Each list menu  6 , such as  9 , consists of a list menu header  10 , the topic selected by the end-user in a previous list menu  8 , and one or more related topic items in the scrolling display area  11  in  9 . The relationship between menu header  10  and list  11  of related data-topics is significant, because it represents a primitive data relation  12 , one of the four Binary Attribute Data Relations or BADR (contextual information), which occurs naturally in a database structure. 
         [0063]    In fact, data relation  12  could be derived from any type of data model, data structure, file format (including both fixed and variable length fields), and even RDF files, as all of the physical symbols in these data storage devices are composed of the same meta-symbols: a mechanical value and constructed types. 
         [0064]    List  11  of data-topics in list menu  9  of GUI  5  represents a “one-to-many” relationship with regards to the selected item in list menu  8 . The data mapping between the item selected in  8  and the list of data-topics in  11  is central to this disclosure because it characterizes the BADR, a new concept that is introduced by this invention and that will be described in detail shortly. 
         [0065]    In content menu  5 , each time an item in list menu  11  is selected by an end-user, this technology generates a new data-topic list menu  6  that narrows or refines the selected data-topic according to data relations in the database and its underlying logic. At the end of each menu path, content menu  5  displays an information object window that furnishes information drawn from the database. The linkage between this menu path and the information object window is based on a primary key or a unique identifier associated with each database record. 
         [0066]    Alternative embodiments of content menu  5  include graphical interfaces that represent nested data-topic lists in a tree-view interface and or in nested hypertext lists. Embellishments to the preferred and to the alternative embodiments of these navigation structures include graphic icons and sound clips as topic entries. 
         [0067]    The client server network apparatus of the present invention is depicted in  FIG. 2 . A client computer  17  is electronically linked to a server  15 . This network linkage  16  includes any combination of physical cabling and wireless connections. Server  15  is responsible for providing the menu data for the content menu interface  5  displayed on monitor  18  of client  17 . Client  17  has communications software that enables it to request menu data from server  15 . An end-user on client  17  employs an input device like keyboard  19  on  17  to make selections and or to input text in order to use and navigate the content menu. 
         [0068]    Alternative input devices on client  17  include touch-screens, pointing devices like a mouse, voice-activated systems, and other types of sensory input devices that would enable an end-user to make selections in a content menu. The monitor  18  of client  17  displays the content menu visually as a graphic image; alternative output devices include “talking software” systems that would enable an end-user to receive auditory descriptions of the content menu. 
         [0069]    Alternative embodiments to the network configuration of the present invention include a stand-alone computer configuration where the menu data associated with the content menu resides on a local data storage device. Alternative embodiments to the stand-alone computer or to the client computer  17  also include any computing device, regardless of its size or sensory interaction, that communicates with an end-user by presenting information actually requested by that end-user. 
         [0070]    The major software components of the prior art of the content menu  5  are graphically depicted in  FIG. 3 . One component of this prior art is an authoring system  22  that generates menu data files  24  for content menu  5 . Menu data files  24  are processed by browser software  26  on client  17  to create content menu  5 . 
         [0071]    In the prior art, authoring system  22  builds and maintains an open hierarchical data structure (OHDS) which organizes menu data into a single data structure. OHDS  68  will be presented shortly in  FIG. 5 . Authoring system  22  employs structure  68  to generate a series of compiled files  24  for content menu  5 , where each menu data file  24  represents a network segment of structure  68 . The maximum size of each file  24  can be set by the developer in  22 , enabling the developer to control the file size and thereby optimize network and server performance. Client browser software  26  requests a menu data file  24  over the network and parses its contents to generate one or more list menus  7  for content menu  5 . 
         [0072]    In the new art, authoring system  22  contains software tools and graphical interfaces that enable menu developers to select and to capture meta-query data from an external database system based on binary attribute relations, the subject of this new art. Other capabilities and features associated with this new art, which will be presented shortly, include the ability to store and retrieve meta-query data in a predefined data structure on server  15  in order to create runtime list menus  11  in  5  on demand. 
         [0073]    In the preferred embodiment of the present invention authoring, system  22  resides on server  15  and it maintains menu data files  24  and its meta-query data on there as well. In an alternative embodiment of the present invention, say on a stand-alone system where both the target database and the browser software  26  reside on the same computer, authoring system  22  can reside on the same machine. Or it can maintain menu data files  24  and meta-query data files on this same computer or on any other computer in the network. In other words, authoring system  22 , menu data files  24 , meta-query data, and the target database files can reside anywhere in a connected network. 
         [0074]    To demonstrate the present disclosure, as well as to refer to the prior art on which these improvements are based, a relational database application that manages an inventory of books will be used as an example. Target database application  35  includes three different tables or entities: Books  40 , Authors  50 , and Publishers  60 . Each row or entry in Books  40  depicted in  FIG. 4   a , such as  47 , represents a book in this inventory or, in relational database terms, an instance of an entity. Each book in table  40  has data that corresponds to a Book_Title  44 , an identification number or BID  42 , and a Book_Language  45 . Other descriptive information about each book—in accordance with the relational model—is contained in the Authors  50  and Publishers  60  tables which have a one-to-many relation to Books  40 . 
         [0075]    At this point in the discussion, it is important to note that each relational table, such as Book  40 , Author  50 , and Publisher  60 , is a two-dimensional logical structure consisting of columns or fields and rows or records. In relational database terms, these dimensions are characterized by attributes and tuples. The terms attributes, fields, and columns all identify the vertical dimension of this structure, and they all can be used interchangeably without altering their meaning. The same is true for the terms that can describe the horizontal dimension of this structure, namely rows, records, and tuples. 
         [0076]    In the relational model, columns or attributes refer to data values that can describe the entity, like Author  52  in  50 , by the author&#39;s name. Data values in other attributes serve as value-based links between tables, such as BID  42 , a primary key, and AID  43  or PID  46  in  40  that are foreign keys. These keys, both primary and foreign, give this model its value-based navigation capabilities described by Atzeni et al. that enable rows in one table to link to rows in another table. 
         [0077]    In this new art, the functional distinction between attributes that manage data describing the entity versus attributes managing link data is fundamental. Attributes that are declared as primary and foreign keys in the schema, or employed in that manner, are identified in this new art as operational attributes or  48 . A primary key or  48   a  represents a unique data value for each tuple or row in the table. It also provides a means to link to descriptive attribute data associated with the each tuple and row. On the other hand, a foreign key  48   b  represents a link to a primary key that can be found in another table. Therefore,  48   a  and  48   b  complement one another by establishing a value-based linkage between two two tables. All other attributes in the table structure, by default, are considered conceptual attributes; that is, these attributes manage data that describes something about an entity. This distinction between operational attributes  48  and conceptual attributes  49  in a table will be made throughout this disclosure. 
         [0078]    In Codd&#39;s seminal  1970  ACM paper that introduced the relational model, he addressed this distinction between attributes, but only in a very general way. This teaching stresses this distinction, by showing in very concrete ways how pairing two attributes together plays an essential role in exposing semantic relations at the data level, which the inventor identifies as BADRs. The final series of figures in this teaching,  FIGS. 12   a  through  12   d , will show how data from two conceptual attributes  49  form a distinctive type of BADR that this teaching identifies as contextual information. In the meantime, this distinction between conceptual and operational attributes and their pools of data will be raised throughout this disclosure. 
         [0079]    Lastly, rows or, in relational terms, tuples also play a vital role in the teaching of this new art. The row dimension of the entity structure, such as  47  in  40 ,  56  in  50 , or  66  in  60 , serves as a fundamental way for a data value in one attribute to relate to a data value in another, particularly from the perspective of retrieval operations. In fact, the central teaching concerning the binary attribute data relation relies extensively on this dimension, and on the pairing of two attributes, to expose this data relation. Prior to this disclosure, no one had considered how these two dimensions—attributes and tuples—in the relational database table interacted. Therefore, by considering the simplest case, namely two attributes in a BAR and the tuples or rows that form a bridge between them, the inventor is able to identify and classify the data relations that are responsible for construction of the OHDS and for the database taxonomy displayed in content menu  5 . 
         [0080]    A graphic representation of the prior art of the open hierarchical data structure or OHDS  68  (a. k. a. the K2Structure) is depicted in  FIG. 5 . As mentioned in the Background section, OHDS  68  manages menu data for content menu  5 , and its organization is similar to the LEFT child-RIGHT sibling structure described by Knuth. However, in order to build and maintain OHDS  68 , authoring system  22  manages dedicated interactive, graphical user interface that enables developers to add and modify topics by hand. Other tools in authoring system  22  populate structure  68  automatically by mapping data and data relations in a target database, such as  35 , directly to leaf nodes in  68 . Lastly, the fact that any branch or leaf node in  68  can have more than one parent distinguishes this structure markedly from the one described by Knuth. 
         [0081]    Flow in structure  68  starts at root node  70  and continues downward through one or more branch nodes, like  71  or  72 , to a leaf node like  89  or  92  that links to an information object. Each node in structure  68  can have two different pointers that directly correspond to each list menu  6  in  5 . A sibling pointer on a node, such as on node  73 , establishes the basis for a list of data-topics that directly corresponds to a list of menu items, like  11  in  9  when sibling pointer on  93  is taken into consideration. Each node in  68  also has a child pointer that gives this structure its distinctive hierarchical flow. In content menu  5 , this edge establishes the downward linkage and flow from list menu  8  to its successor list menu  9  or from list menu  9  to an information object window based on value A associated with node  93 . At the end of each path in structure  68 , any leaf node can link to the same information object, like  92  and  94 . 
         [0082]    Database structure  104  managed by authoring system  22 , depicted in  FIG. 6 , stores menu data associated with content menu  5  according to the hierarchical organization depicted by  68 . Data associated with each node in  68  are stored in attributes such as TOPIC  106  and NODE  105 . Each row in  104 , like  110 , represents a specific node in  68 , such as the root node  70 . Alternative embodiments of storing menu data associated with structure  68  include predetermined file formats, as well as other types of database architectures or file and directory structures. 
         [0083]    Lastly, database structure  104  provides the framework for compiling menu data into one or more menu data files  24  for the content menu  5 . An alternative embodiment of such compiled data files  24  includes the new art disclosed in this teaching, which shows how to generate a list menu  6  at runtime using meta-query data that will be presented shortly in more detail with the description of  FIGS. 10   b  and  10   c.    
         [0084]    An overview of the prior art of the developer&#39;s graphical user interface  111  and the program flow of meta-query data is displayed in  FIGS. 7   a  through  7   c . These figures show how this interface captures meta-query data associated with target database  35 , and how this prior art stores and uses meta-query in authoring system  22  to create structure  68  in  104 . 
         [0085]    The first figure of this series,  FIG. 7   a  displays the menu interface  111  employed by a menu developer to capture meta-query data. In  111 , the developer selects an item in each scrolling list menu, like Display Column  112 , to identify and capture meta-query data from external database  35 . These selections constitute the meta-query data that is then applied to the mapping algorithms which extract data and data relations from target database  35 . For instance, the selections made in  111  would be responsible for furnishing meta-query data that is responsible for displaying publishers&#39; names in scrolling list  11  in list menu  6  of  5  that would refer to data values in Pub Name  62  of Publishers  60 . 
         [0086]    It is important to note that interface  111  requires the developer to select the names of two attributes, a display column  112  and a link column  113 , each time the developer connects to a table data source. The display column  112  serves as a source for the data-topic values are displayed in a list menu  6  of content menu  5 . The second attribute, link column  113 , associates link values with each data-topic in  112 . Both the display column  112  and link column  113  selections serves as meta-query data used by authoring system  22  to generate structure  68  and runtime list menus  7  in content menu  5 . 
         [0087]    Interface  111  also captures other types of meta-query data. This includes built-in functions, keywords, and schema labels in field  114  which can control how output data is formatted and displayed, and any conditional clauses in field  115  which can add more precision to a selection condition. 
         [0088]    The flow of program control from interface  111  to structure  68  in  104  is displayed in  FIGS. 7   b  and  7   c . Program flow  116  in  FIG. 7   b  starts with interface  111  and culminates with authoring system  22  depositing meta-query data in structure  118  from the coded expression  117 . Program flow  119  in  FIG. 7   c  starts with program logic in authoring system  22  that accesses meta-query data in  118  to extract data and data relations from target database  35  that it will use to populate structure  68  in database structure  104 . 
         [0089]      FIGS. 8   a  through  8   c  depict the notation for the Binary Attribute Relation (BAR), its correspondence to a database entity, and how it is stored and managed on computer  15  by authoring system  22  as meta-query data in  118 . It should be noted that in this new teaching on meta-query data the BAR represents a pair of attributes that function as input and output channels in a BAR query. From this perspective, the BAR notation also represents a compact way to consider a unit of meta-query that can be stored with other units of meta-query data. Mapping algorithms that extract data and data relations from  35  employ this meta-query data to build the BAR query; please refer to  FIG. 11  for the details. 
         [0090]    In both the BAR and the BAR query, the pair of input and output attributes represent a logical relationship which is based on the fact that both attributes have something structurally in common. In the relational database, that commonality is defined by the tuple or row. In other data sources, such as other data models, data structures and data files, that commonality can be rows, records or any other types of structural elements which would allow two attributes, columns or fields to overlap structurally with one another. Yet, no matter what the technical setting, there is another, more striking commonality, namely retrieval operations. 
         [0091]    Because all retrieval operations employ pattern matching on mechanical values associated with an input channel, and some type of designation for output, such as an attribute name or label or a field location or identifier which distinguishes one pool of data from another, such retrieval operations can easily be abstracted and generalized, giving rise to the BAR query as a primitive retrieval method. In other words, the BAR query is composed of an input clause, an output clause, and a variety of interchangeable keywords, logical symbols, structural references to data systems, and syntax which could be represented, in an abstract way, by any query or retrieval language, effectively enabling this simple concept to be generalized and considered a universal data access method. 
         [0092]    In the relational database, the BAR query employs pattern matching on mechanical values managed by the input attribute to locate all relevant tuples. When there are redundant values at the intersection of the input attribute and its tuple instances, this retrieval operation returns multiple tuples. Using a single data value as a test condition on the input attribute—one can observe output data values which span across multiple tuples. In this setting, the mapping between this new input value and its output yields a one-to-many pattern. In other settings, a single input value returns a single tuple, and the mapping yields a one-to-one pattern. By exploiting the mechanical features of physical symbols, and by applying this knowledge to retrieval operations, the BAR query is able to capture the arbitrary nature of such data relations because its functions are mathematically and logically aligned with the structure of the relational table, in a precise and accurate manner. 
         [0093]    The first figure in this series,  FIG. 8   a  depicts the formula for a Binary Attribute Relation or BAR  120 . The left and right parenthesis define a logical relation that binds the two elements. In this case, these two elements represent variables: an input attribute A i    122  and an output attribute A o    124 . Each variable in this formula stands in for an attribute label or heading that was declared in the database schema. 
         [0094]    Operationally, these two elements represent two attribute labels which are applied to a BAR query as an input attribute and as an output attribute. In the Structured Query Language (SQL) SELECT demonstration of this invention, which will be presented shortly in detail in  FIG. 11 , these two attribute labels represent the primary components of a BAR query. Input attribute  122  is applied to the formation of an input clause, such as “WHERE A i =v” (where v is a data value in A i ) and  124  specifies an output channel or A o . 
         [0095]    In other embodiments of this retrieval function, the input attribute  122  is a field name or numeric identifier for a field or column in a series of fields and columns. Input attribute  122  specifies the subject for a test condition in a non-relational database or data structure or file, with the logical concept of equality representing the predicate and a test condition value being the object. In these alternative embodiments, input  122  can refer to a location or structural element in the target data system, in which case the BAR query refers to an input-output interface to an algorithm or computer program that does pattern matching on  122  and returns output data values based on  124 . 
         [0096]    The next figure in this series,  FIG. 8   b , depicts a BAR formula  130  using variables for an attribute label or field name in a database schema, like  44  for  122  or  43  for  124 , preceded by entity or object label  132 . In BAR formula  130 , the entity name prefix  132  corresponds to the name or label that would be used to access an entity or object. For instance, Book  40  of  35  in  FIG. 4   a  would be an example of such an entity label, which, in this example, is a schema label for a relational table. When the an entity label applied to BAR  120  on the left below, it takes the form of BAR  130  on the right, 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 (Language, Title) 
                 (Book.Language, Book.Title). 
               
               
                   
                   
               
             
          
         
       
     
         [0097]    The last figure of this series,  FIG. 8   c , graphically presents an outline of storage structure  118  that manages the meta-query data. This new meta-query storage art introduces a new format  140  which is based on BAR  120  (and  130 ) and on the source code of the BAR query in  FIG. 11 . Program control in authoring system  22  enables a content menu developer to navigate over target database  35  using a graphical menu interface  111  to create BAR  130  by selecting items in scrolling regions  112  and  113 . Interface  111  now captures BAR  130 , along with any related meta-query in  114  and  115 , and stores them in structure  118 . Each BAR  130 , and its related meta-query data  142 , is stored in a predefined sequence: an initial entry  141 , one or more successor entries like  144 , and a final entry like  146 , which can be accessed by various means including an sequential index. 
         [0098]    An alternative embodiment of structure  118  depicted in  FIG. 8   c  stores a single attribute for each unit of meta-query data, by telescoping a chain of interrelated BAR pair. This technique eliminates redundant meta-query data is identified as the “Short-Form” of BAR  120 , which employs its own specially-designed algorithms to reconstruct a chain of interrelated BARs. 
         [0099]    In the next diagram,  FIG. 9  presents a graphical image of the client server apparatus of the new art, along with the software components that support these new capabilities. On server  15  this includes session controller  155  that managers the individual sessions associated with each client  17 . In turn, each client  17  has a cookie  150 , software that maintains information on the individual end-user navigation on the content menu  5 , including a session ID that distinguishes one client session from another. The software cookie  150  maintains persistent data on the session, such as the start-time stamp, the current list menu  6  in  5 , as well as other parameters and metrics related to the end-users activities on  5 . Browser software  26  on  17  is responsible for furnishing some of these parameters, and session controller  155  on server  15  maintains others. 
         [0100]    On client  17 , browser software  26  in this new art is capable of generating a list menu  6  for content menu  5  deploying two different types of menu data files  24 : compiled and runtime files. Both types of files  24  include menu data for one or more list menus  6  in a content menu  5 . The compiled menu data file  24  is generated during a production run using OHDS  68  in structure  104  to generate one or more data file  24 . These files can be built anywhere, and they can be stored on server  15  or on another computer that is accessed by server  15 . 
         [0101]    The compiled menu data file  24  has the advantage over runtime  24  of conserving network resources, at the expense of delivering static and possibly out of date data. It is built prior to any formal request for menu data made by browser software  26  on  17 . In contrast, a runtime menu data file  24  is generated on demand, when a request for specific list menu data is made by browser software  26  on  17 . The runtime  24  contains “live” data. 
         [0102]    In the next series of figures,  FIGS. 10   a  through  10   c  depict the program control that builds a BAR query, at runtime, for the algorithm that extracts data and data relations from target database  35 . Program control in the authoring system  26  establishes and maintains a connection to  35  in order for the developer to use interface  111  and for the program control in authoring system  22  to retrieve data from  35 . 
         [0103]    In this new art,  FIGS. 10   a  and  10   b  represent the program control for creating the two different types of menu data files  24 : runtime and compiled. In both instances, the algorithms which generate these two different menu data files use the same meta-query data, even though one list menu  6  in content menu  5  may display “live” or runtime data-topics, and another  6  in  5  displays data-topics which were “static” or stored in a menu data file  24  which was compiled at an earlier date. The last figure in this series,  FIG. 10   c , shows how the BAR query is constructed and executed, and how the results are returned to the calling program. 
         [0104]    The first figure in this program control series,  FIG. 10   a  depicts program logic  160  that builds OHDS  68  in  104  that provides the framework for generating compiled menu data files  24 . Authoring system  22  builds  68  in  104  on demand or at scheduled production time. After system  22  builds  68  in  104 , another software system in  22  traverses  68  in  104  to generate and to compile one or more menu data files  24 , according to a prescribed optimal file size configured by the developer. Each compiled file in  24  contains at least one list of nested data-topic lists that describe instances of the entity in database  35 . 
         [0105]    Authoring system  22  calls ‘BuildK2’  160  and starts the recursion by passing a node value in  104 , like node  70 , an index into BAR structure  118 , and cmd, a conditional command string that eliminates any unwanted values, such as the NULL value. At  162 , routine  160  initializes local program variables. Next, program control, at  163 , calls fetchBADR that can be found in  FIG. 10C  to extract a list of data from  35 . 
         [0106]    Each time routine  160  calls fetchBADR  200  at  163 , program logic at  164  and  166  checks on the type of data returned by  200 . If these data values represent operational data, that are used to link two tables or that can identify a tuple, then the results are treated differently from conceptual data, which are used as data-topics in  5 . This operational data is used as value-based links, which are used to reach conceptual data or to link to a tuple for displaying an information window. This distinction between conceptual and operational data is generalized across the input and output in a BAR to classify data relations or BADR found in the database by the way they are used by the database and by mapping algorithms in authoring system  22  in building an OHDS  68 . 
         [0107]    When routine  160  determines at  164  that fetchBADR returns a dataList that represents operational data associated with attribute  48 , it next tests, at  165 , if these values represents primary key  48   a  functionally, which would signify the final BAR index. If so, routine  160  calls AddLeafNodes to add a sibling list of leaf nodes to structure  68  in  104 . Otherwise, the operational data in dataList refers to data values that eventually link to conceptual data. In this case, routine  160  calls FilterOA at  167  to cycle through this operational data in order to eventually reach conceptual data that can be used as data-topics in content menu  5 . 
         [0108]    When fetchBADR returns a dataList that represents conceptual data, or list of data-topics that functions that way, routine  160  calls AddSiblingList at  169  to create a sibling list in  68 . Next,  160  updates local variables and makes a recursive call to itself at  172 . Upon returning,  160  checks if the current node or n in  68  has a sibling, and if it does,  160  updates the cmd string to include the new input condition based on the current n, and then calls itself to continue its depth-first tree-growing pursuit of OHDS  68 . 
         [0109]    In the next figure in this series,  FIG. 10   b  displays program control  180  that is used to generate a runtime list menu  6  in content menu  5 . Session controller  155  on server  15  calls runTime routine  180  and passes the sessionID associated with the cookie software  150  on client  17  along with the request made by the browser software  26  on client  17  that includes the BARindex or vector in  118  and the selection conditions. At  182 , routine  180  initializes the program control variables including the input and output clauses which are applied to the BAR query. At  184 , routine  180  calls fetchBADR  200 , displayed in  FIG. 10C , to build the source code for a BAR query and execute it. 
         [0110]    At  186 , program control in  180  determines how to employ the dataList returned by fetchBADR. In this regard, routine  180  either sends dataList back to the calling software browser  26  on  17  to create the next list menu  6  in  5  or it treats this data as representing operational data. As mentioned in the last figure, operational data links to data that describe an entity or it signifies a primary key that can be used to create a window object which displays information about the string of data-topics selected by the end-user. At  188 , if this operational data represents a primary key  48   a , then routine  180  calls infoWindow at  190  to build and return a window object to the browser  26  based on that primary key. Otherwise, routine  180  cycles through the operation data lists by calling filterOutOA at  192  till it reaches conceptual data. 
         [0111]    The essence of new program control in  160  and of the new meta-query format  140  is presented in  FIG. 10   c . Here, the fetchBADR routine  200  builds the source code for the BAR query; executes the BAR query against  35 ; and returns the results to routine  160 . These results are used either to build OHDS  68  in  140  in order to compile a series of menu data file  24 , or they are used by routine  180  to create a runtime menu data file  24 . 
         [0112]    At the start, routine  200  initializes local program variables at  202 . Next, at  204 , routine  200  builds the command string and executes the retrieval operation against target database  35 . And, finally, at  206 , routine  200  parses through the results of this retrieval operation and reformats them for the calling procedure. 
         [0113]    The actual source code string for the BAR query that routine  200  creates is treated in an abstract manner at  204  as having an “output clause” and an “input clause” along with the keywords, SELECT and WHERE, which underscore the syntax of the query which performs the data extraction. In this example, the data extraction is executed by a relational engine, and the SQL syntax is used to demonstrate a BAR query. In alternative embodiments of the invention, the keywords, syntax, and even its input and output clauses may be entirely different. For instance, routine  200  could generate query source code for a hierarchical database, or even an algorithm build to extract data from a field-oriented file based on sequence or fixed locations. In these alternative embodiments, routine  200  essentially generates code for a predefined access method, executes it, and returns the results to the calling routine. 
         [0114]    Finally,  FIG. 11  presents an example of one type of BAR query source code that could be constructed by a routine like  200 . This particular source code, depicted here in SQL, the universal data manipulation language associated with the relational database, represents a primitive query operation which pairs a single new data value with a attribute along with any prior selection conditions in  214 . 
         [0115]    The first time that routine  200  is called this source code exemplifies the theoretical simplicity of the BAR and the BAR query. However, with each new recursive call, each new input attribute/value pair, or “A n =v n ”, is concatenated with the prior input conditions in order to extract the logically correct subset of BADRs that exist between the two attributes in the current BAR. Therefore, one can and should differentiate a simple BAR, as truly having a single input attribute or “A i =v” where A i  is that attribute and v is a data value that can be found in A i , from an operational BAR. An operational BAR, where like the one presented at  210  in  FIG. 11 , the source code has a single, new input attribute/value pair, “Book_Language=“English” which is concatenated to input_clause  214 , which includes one or more previous input attribute/value pairs representing each level of recursion to recreate the proper logical context, e.g., “((Book_Language=‘English’) AND (A 2 =v 2 ) AND (A 1 =v 1 ))”. 
         [0116]    The source code in  210  shows the components of the preferred embodiment of a BAR query in a SQL SELECT, and just how easily this can be generalized across other query languages. Source code  210  is composed of keywords  212 , symbols  214 , and a syntax (a prescribed sequence of keywords and symbols) that designates an input clause  225  and an output clause  220 . In this regard, it is important to note that in spite of its universal status SQL still has multiple dialects that can impede portability; but with a BAR query implementation, i.e., by simplifying the query language elements to input and output, even these subtle, yet annoying language differences can be avoided completely. 
         [0117]    After seeing the simplicity of these BAR query components, it should be noted, once again, that alternative embodiments of routine  200  can generate source code for any retrieval service which can be used to extract data values from a target data system. That is because all of these data systems essentially use labels, names, numbers, and even structural locations to differentiate one pool of data from another. And because such a retrieval operation, including an interface to an algorithm, essentially treats one pool of data as input and another as output. Therefore, the SQL SELECT statement in  FIG. 11  presents just one example of how to create a BADR or mathematical relationship between one pool of data and another. 
         [0118]    And now, in the last series of figures,  FIGS. 12   a  through  12   d  depict the four different types of data relations that can be expressed by a BAR query, such as  210  in SQL. These different types of data relations represent the complete set of binary attribute data relations or BADR  250  derived from a BAR query. In each instance, a data value v specifies a condition on an input attribute in BAR  120  or A i . To fully expose BADR  250 , this data value represents an existing value in the input attribute, such as the data value that can found at intersection of  45  and  47  in  40 . This input condition, A i =v, regardless of the possibility of deeper logical context, is responsible for creating the one-to-one or one-to-many relationship with the output data returned by BAR query, where both input attribute  122  and output attribute  124  are drawn from the same entity. 
         [0119]    The relationship between v and its output data is logically (and some might say mathematically) based. Throughout this disclosure, this logical relationship is the binary attribute data relation or BADR  250  represented in the  FIGS. 12   a  through  12   d . The discovery of this data relationship was made possible by observing the construction of OHDS  68 , which has been shown to use two different types of data: conceptual and operational data values, as evidenced by program control  188  in  180 . 
         [0120]    This new art advances the understanding of meta-query in two crucial ways: 1.) by focusing on pairs of attributes that serve as input and output in a primitive BAR query, and 2.) by treating all relational data as capable of serving as a link to other data within the same tuple or row structure. This new view of linking data in one attribute to another by way of their commonality, namely tuples and rows, was and is unconventional. 
         [0121]    Other unconventional approaches to relational data employed by the inventor exploit the fact that retrieval operations use pattern matching on mechanical values and output declarations based on constructed types, which effectively means that retrieval operations on all entities—regardless of the data model—operate on all physical symbols in the same manner, at a meta-level. Therefore, the inventor asserts that relational data, and all symbolic data in an entity for that matter, is composed of two meta-symbols: a mechanical value and a constructed type, and this highly original view of relational data enables the same attribute to work equally effectively as input or output in BAR query. It also enables the inventor to view the relationship between data and its attribute declaration in a strictly pragmatic manner, allowing him to ask how attributes and data contribute to what the end-user sees in the content menu. 
         [0122]    From this new perspective,  FIGS. 12   a  through  12   d  show all the different ways that conceptual and operational attributes—and their respective conceptual and operational data—can be paired together, thus creating an opportunity for classifying BADR  250  according to these pairings. Table 1, listed below, summarizes all these possible combinations of attribute types as meta-query data that can occur in BAR notation  120 . This table employs the following intuitive notation: C for conceptual attribute  49  and O for operational attribute  48 . 
         [0123]    Early in this specification, the disclosure made a point of differentiating one type of attribute from the other based on how each attribute in the schema was declared. Once again, we are reminded that conceptual attributes  49  typically manage data values that can be used to describe an entity, and operational attributes  48  typically manage data that serve as links between entities, giving the relational model its distinctive value-based approach as described by Atzeni et al. 
         [0124]    The first entry in Table 1, (C, C), designates a special type of data relation  250  that the inventor identifies here as Contextual Information, where—from the content menu end-users perspective—one data-topic selection leads to another list of data-topics according to some, yet to be determined underlying logic that governs the formation of the relational table and other types of entities. Sometimes this logic is self-evident, for example, when the cities of Amherst and Concord follow the state of Massachusetts. At other times, this logic only makes sense from the perspective of the database application and the end-users&#39; expectations, say when “January” or “February” follows the selection of “New England” in a sales tracking application. 
         [0125]    The other designations in Table  1 , namely (C, O), (O, C), and (O, O), all refer to the ways that the relational model creates links to Contextual Information. Therefore, it is identified here as Conceptual Linkage. These types of BARs represent data relations that either link to another table, (C, O), or link from another table, (O, C), or represent pairs of keys in a table, (o, O), that represent many-to-many relations. 
         [0000]    
       
         
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 BAR 
                 Represents 
               
               
                   
               
             
             
               
                 (C, C) 
                 Contextual Information 
               
               
                 (C, O) 
                 Conceptual Linkage 
               
               
                 (O, C) 
                 Conceptual Linkage 
               
               
                 (O, O) 
                 Conceptual Linkage 
               
               
                   
               
             
          
         
       
     
         [0126]    With this classification of binary attribute relations in place, the next step entails looking to see how these relations correspond to the formation of binary attribute data relations  250 , and they contribute to the formation of a content menu. 
         [0127]    The first figure in this series,  FIG. 12   a  represents conceptual-to-conceptual attribute pairing or (C, C). As mentioned earlier, this type of BAR—at the data level—depicts contextual information and a specific type of BADR  250  identified here as  252 . BADR  252  is a fundamental building block of the database taxonomy, because it furnishes the lists of data-topics that end-users see in content menu  5 . In this instance, the data and data relation created here are drawn from two conceptual attributes that manage data values that can be used to describe an entity. 
         [0128]    From the end-users&#39; perspective, the content menu displays this relationship between two conceptual data-topics to help them move closer to the information they seek. Data values extracted from an output attribute serve as data-topics in list  11  of menu  9 ; the input data value serves as a link to a prior list. Operationally, each end-user selection in content menu  5  formulates a new condition for the data-topic display in the next list menu  6 . The selected data-topic is applied to next BAR  120  as input v to  122 . From content menu  5 , the relationship between the data-topics in one list menu  6  and the next  6  is both operational and semantic, or—in more practical terms—it is both useful in creating a context for the end-user. 
         [0129]    In the example displayed in  FIG. 12   a , the list of book titles that follows after selecting “English” from the previous list highlights the semantic relation between these two lists, which is identified here as contextual information. When progressing from the list of languages to a list of relevant book titles, the flow is natural, making the process of looking up a book in a content menu  5  intuitive. Clearly, the BAR query that exposed this BADR  252 , and the recursive algorithm that established the links between one list of data-topics and the next, enables content menu end-users to view database content in a powerful, new format that is innovative, yet familiar because it is similar to an index which can be found in the back of a book. 
         [0130]    Other combinations of attribute pairings include conceptual and operational attributes, such as (C, O), (O, C), and (O, O), that essentially serve up BADRs  250  which eventually link to other conceptual data or a primary key  48   a  in a final table destination. Examples of these types of attribute pairs can be found in  FIGS. 12   b  through  12   d.    
         [0131]    For instance,  FIG. 12   b  depicts a relationship between a conceptual attribute and an operational attribute or (C, O). This conceptual-to-operational data relation is depicted at the data level by BADR  254 . In this example, ‘German’, a data value from attribute  45  in  40 , a conceptual attribute  49 , maps to ‘1023’, operational data from  43  in  40 , a foreign key  48   b . A BADR  254  could also map to a primary key  48   a , such as BID  42  in  40 . In either instance, the conceptual data binds with operational data to establish a value-based linkage between two attributes within the same entity to characterizes BADR  254  as a building block in a network of data and data relations which spans from one entity or table to another. 
         [0132]    In  FIG. 12   c , the conceptual and operational attribute pairing is reversed, i.e., (O, C), to create another type of BADR  250 , an operation-to-conceptual data relation  256 . Once again, the operational attribute in this pairing can represent either a primary key  48   a  or a foreign key  48   b , depending upon on how this building block is employed in creating a network of data relations. In the example depicted in the figure, the operational attribute happens to depict conceptual linkage involving a foreign key  48   b ,  46  in  40 , and the conceptual attribute  44  in  40 . 
         [0133]    And, finally, the consequences of an operation-to-operation BAR, or (O, O), are depicted in  FIG. 12   d . This type of BADR  250  represents a pair of operational attributes within the same entity. This figure represents the pairing of two foreign keys  48   b . It characterizes a particular type of entity found in the relational model, a many-to-many table. Alternatives to this pairing include a primary key with a foreign key and a foreign key with a primary key. 
       GLOSSARY 
       [0134]    BAR query—a primitive retrieval operation in a recursive algorithm which initially starts out with a single input and output channel, and which adds a new condition with each new iteration. In the preferred embodiment of the present invention, the relational database, each channel represents a table attribute or field. In alternative embodiments of the BAR query, say a predefined query language interface, such as program control or a program interface on a data system, the input and output channels can be represented by a symbol or an expression.
 
BAR or binary attribute relation—a logical relationship between two pools of data in a data system, which is expressed by a primitive retrieval operation. This term can also be used to describe a logical relationship created by a retrieval algorithm between two pools of data in one or more systems that are used to manage data, including file and directory systems.
 
BADR—a binary attribute data relation is a primitive data relation derived from a BAR query. It consists of a source data value in a pool of data and one or more data values from a destination pool of data.
 
conceptual attribute—any pool of data whose values can describe a property of an entity that is modeled by a data system.
 
conceptual data—a data value which describes a property of an entity which is being modeled.
 
conceptual linkage—a logical relationship between two pools of data which occurs at the data level, where a data value in a source pool relates to one or more data values in a destination. Data associated with the source, destination or both represents data that can be used as value-based links.
 
constructed-topic—a topic in a list menu of a content menu that was supplied by a menu developer by hand.
 
constructed type—an aspect of a physical symbol on a computer which refers to its membership in a pool of data. A label or a symbolic location, including an index, can be used to distinguish one pool of data from another.
 
content menu—a graphical user interface (GUI) consisting of nested list menus, or equivalent isomorphic structures such as a tree-view, which depicts data-topics and their relations in a data system in the form of a database taxonomy.
 
contextual information—a semantic relationship which takes the form of a “IS A TYPE OF” predicate, where a data value in one pool relates to one or more data values in the second.
 
database—a data system composed of one or more pools of data which constitute an entity, and where one or more of such entities by supported by integrated retrieval operations.
 
data object—a pool of data in a data system. In a data system, like a relational database, each table attribute or field represents a data object.
 
data structure—a very basic data system which manages data on a computer according to some predefined arrangement of data values.
 
data-symbol—a data value drawn from a pool of data and displayed in a list menu of a content menu.
 
database taxonomy—the knowledge representation of data and data relations in a database which is accessed interactively by a content menu.
 
data-topic—any data value drawn from a pool of data in a data system which can displayed in a content menu.
 
data system—a computer software system that is used to manage a collection of data. Such systems can range in scale from the simplicity of a computer file or directory system—consisting of uniform divisions, subdivisions, and fields within those subdivisions—all the way up to the complexity of the relational database management system (RDBMS).
 
mechanical value—an aspect of a physical symbol on a computer composed of a pattern on/off bits which enable the computer to make logical comparisons between two physical symbols.
 
meta-query data—any data which is either selected or supplied by menu developers and used to construct source code for a BAR query.
 
meta-symbol—an aspect of all physical symbols on a computer which entails physical values to differentiate one symbols from another, and membership properties, which distinguish one pool of data from another, with the former representing its mechanical-value and the latter its constructed-type.
 
operational attribute—a pool of data in a data system which provides value-based linkage to an entity. In a relational database, it is a table field which has been declared as a primary or a foreign key.
 
operational data—any data value which can be used to link one entity to another within a data system. In the relational database, operational data is represented by any attribute that has been formally declared in the schema as either a primary or foreign key.
 
physical symbol—a symbol on a computer which is encoded by a series of on/off bits and which is accessible to an observer by visual or by auditory means.
 
primitive data relation—the data mapping between two pools of data in a data system which is derived from a primitive retrieval operation, and which represents a “one-to-one” relationship or a “one-to-many” relationship.
 
relational data—a data value managed by the logical structure of a relational database table.
 
value-based linkage—the type of linkage that is based on mechanical values of physical symbols.
 
       CONCLUSION 
       [0135]    This concludes the description of an embodiment of the invention. The foregoing description of the embodiment of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching, including software methods which would use memory and program logic in be less efficient manner and which would take longer to execute because they are not as mathematically precise and accurate as this teaching. Therefore, the scope of the present invention is not intended to be limited by the specific examples presented in this detailed description, but rather by the claims appended hereto.