Abstract:
A computer system and method is to manage business data and logic in a uniformed manner. It is based on the theory of total recursive functions. As a result, it is a monolith consolidating the multiple-component architecture of traditional technologies in the fields of programming language and database management. Secondly, the properties of the theory of total recursive functions are uniquely demonstrated by a set of built-in operators of the system. Therefore, it offers novel approaches to many challenges in the fields of artificial intelligence and knowledge management facing the traditional technologies.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    This invention is related to the fields of programming languages and database management systems for arbitrary computing applications including database applications, artificial intelligent applications, knowledge-based reasoning applications, and web-based applications. 
         [0003]    2. Description of the Prior Art 
         [0004]    Many database applications were written in programming languages in the 1960s and 1970s, and are still in operation. The use of database management system (DBMS) came to database application software in and around the 1970s. It significantly improves the productivity in software development and maintenance. The data models, i.e., the mathematical roots of DBMSs, square off programming languages by three essential characteristics: 1) a data model offers set-oriented operations to update and query data, 2) a program always terminates at arbitrary input, i.e. computer stops, and 3) a data model is declarative, i.e., it allows programmers to specify what a program is in terms of business requirements, but don&#39;t necessarily specify how it will be implemented. 
         [0005]    The traditional data models, i.e., the relational data model and the hierarchical data model, cannot express all desired business data. Hierarchical data, for example, can be folded into a relation, but its containment relationships cannot be captured by the relational data model with the expressive power of the relational algebra (Reference: A. V. Aho and J. D. Ullman, “Universality of Data Retrieval Languages”, Conference Record of the Sixth Annual ACM Symposium on Principles of Programming Languages, San Antonio, Taxes, January, 1979, page 110-120). Another example would be relationships among the vertices in a directed graph, (e.g., is there a path from A to B?), which cannot be captured in both the relational data model and the hierarchical data model. As a result, database applications continuously require intense, though relieved, development and maintenance work, which could be avoided if a more expressive data model were realized and leveraged. 
         [0006]    The EP (Enterprise-Participant) data model is semantically equivalent to a class of total recursive functions (Reference: K. H. Xu, J. Zhang, S. Gao, R. R. McKeown, “Let a Data Model be a Class of Total Recursive Functions”, the International Conference on Theoretical and Mathematical Foundations of Computer Science—TMFCS, 2010, page 15-22). The equivalence says that programmers are not allowed to construct an application program that may not terminate on an input. At the same time, it says mathematically that any meaningful application programs, i.e., those with the semantics falling into the class of total recursive functions, can be expressed in the EP data model. 
         [0007]    The EP data model is a data model because it possesses the three above-mentioned essential characteristics. To demonstrate the significance of the EP data model being both a data model and the first language semantically equivalent to a class of total recursive functions, an objective view was suggested on easiness (References: K. H. Xu, J. Zhang, S. Gao, “Assessing Easiness with Froglingo”, the Second International Conference on the Application of Digital Information and Web Technologies, 2009, page 847-849, and K. H. Xu, J. Zhang, S. Gao, “An Assessment on the Easiness of Computer Languages”, the Journal of Information Technology Review, May, 2010, page 67-71). This view contends that: 1) a data model is easier to use than a programming language in the development and maintenance of those applications expressible in the data model, 2) if one data model is more expressive than another data model, the former is easier than the latter in the development and maintenance of the applications where a programming language is involved, and 3) a programming language, by incorporating with a total-recursive-equivalent data model, is the easiest to use in software development and maintenance. Froglingo, a programming language comprising the EP (Enterprise Participant) data model, was therefore concluded to be the easiest programming language. 
         [0008]    Calling Froglingo the easiest programming language to use implies that Froglingo is a monolith that consolidates the multiple software components of traditional software architecture (Reference: K. H. Xu, J. Zhang, S. Gao, “Froglingo, A Monolithic Alternative to DBMS, Programming Language, Web Server, and File System”, the Fifth International Conference on Evaluation of Novel Approaches to Software Engineering, 2010). Secondly, it implies that Froglingo is a novel approach to many challenges facing traditional technologies in the fields of artificial intelligence and knowledge management (Reference: K. H. Xu, J. Zhang, S. Gao, “Approximating Knowledge of Cooking in Higher-order Functions, a Case Study of Froglingo”, the Workshop Proceedings of the Eighteenth International Conference on Case-Based Reasoning—ICCBR, 2010, page 219-228). 
         [0009]    The U.S. Pat. No. 5,995,958 “System and Method for Storing and Managing Functions” issued to Kevin H. Xu and in the U.S. Pat. No. 6,643,638 “System and Method for Storing and Computing Data and Functions” have already been granted for the inventions related to the technologies in Froglingo. However, there are some new developments from the latest research. This patent application is filed to cover the new inventions out of the development. 
       SUMMARY OF THE INVENTION 
       [0010]    This invention is related to the previous ones in U.S. Pat. Nos. 6,643,638 and 5,995,958. Specifically the core components of the invention has been altered, and two built-in operators have been introduced. They were developed through a knowledge management project (Reference: K. H. Xu, J. Zhang, S. Gao, “Approximating Knowledge of Cooking in Higher-order Functions, a Case Study of Froglingo”, the Workshop Proceedings of the Eighteenth International Conference on Case-Based Reasoning—ICCBR, 2010, page 219-228). They are anticipated to be useful in knowledge management and artificial intelligence. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]      FIG. 1  shows a sample knowledge representation in Froglingo, where arbitrary data is modeled uniformly without a necessity of user-defined data types. 
           [0012]      FIG. 2  shows a sample query in Froglingo that utilizes one of the newly invented built-in operators. 
           [0013]      FIG. 3  shows the system architecture of a Froglingo system. 
           [0014]      FIG. 4  shows the rules of forming valid db-terms—input expressions. 
           [0015]      FIG. 5  gives a few examples of valid db-terms. 
           [0016]      FIG. 6  shows a graphical presentation of a Froglingo database for a school administration. Note that the graphical presentation is not in the syntax of Froglingo, but to demonstrate the physical implementation of the data structure embedded in Froglingo, and a logical view for database design. 
           [0017]      FIG. 7  shows the Froglingo expressions equivalent to the database in  FIG. 6 . Note that the logical view in  FIG. 6  is presented syntactically in the Froglingo expressions. 
           [0018]      FIG. 8  shows the Froglingo expressions equivalent to the database in  FIG. 1 . Similar to  FIG. 6  and  FIG. 7 ,  FIG. 1  gives a logical view of the database in a diagram while  FIG. 8  gives the syntactical presentation of the database. 
           [0019]      FIG. 9  shows the Froglingo computing rules. 
           [0020]      FIG. 10  shows the computing methods of the two newly invented built-in operators. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     System Architecture 
       [0021]    A preferred embodiment of the invention is Data Server  10  which comprises Receptionist  30 , Database and Process  50 , and Speaker  100 . 
         [0022]    Receptionist  30  is a unit that receives requests from users or other computing systems through Channel  20 . Receptionist  30  knows the formats of the requests; and converts the requests into the format acceptable by the Database and Process  50 . It knows the identities of the senders and informs Speaker  100  the identities. 
         [0023]    Speaker  100  in  FIG. 1  takes db-terms from channel  90  and responds clients with the outputs  110  converted from the db-terms in the formats the clients need. 
         [0024]    There are two primary sub units in Data Process  50 . One is Database  70  storing and presenting a set of fixed functions and dynamic data. The second sub unit is Computing Rules  60  which converts db-terms from Channel  40  to their outputs  90  according to the db-terms and the states of Database  70 . 
       Labels 
       [0025]    As a preferred embodiment of the invention, a label is a sequence of alpha-numerical characters excluding special characters such as the space ‘ ’, the tab ‘\t’, and the return key ‘\n’. The labels comprise the following two types: 
         [0026]    (1) Constants. Like in other programming languages, integers such as 3, real numbers such as 3.14, and strings such as “a string” are constants. The labels Undefined, True, and False are special constants. Froglingo has a set of built-in operators as constants comprising {= and (=. 
         [0027]    (2). Identifiers. An identifier is a sequence of alpha-numeric characters that is not a constant. Here are a few examples: Salsa, Italian, college.edu in  FIG. 1 ,  FIG. 5  and  FIG. 6 . 
       Three Link Types 
       [0028]    Database  70  is a system with permanent storage  80  which exhibits both the fixed functions and the dynamic data in a uniformed data structure. As a preferred embodiment of the invention, the data structure is a finite set of nodes connected by the three types of connections (or links): up-down links, solid arrows, and dash arrows.  FIG. 1  and  FIG. 6  give some examples of this data structure. 
         [0029]    The first type of links are up-down links, physical references (such as one-way pointers or two-way pointers), each of which connects two nodes together at its two ends as a preferred embodiment of the invention. A link is called the upper link of a node if the link is above the node and is connected with the node; and a link is called the lower link of a node if the link is below the node and connected with the node. A node at the down side of a link is called the down-side node of the link; and a node at the up-side of a link is called the up-side node of the link. Given the node at one side of a link, the node at the other side can be located through the link. For example, all the links with the orientation of up and down in  FIG. 1  and  FIG. 6  including the link  140  are up-down links. Given the link  140 , the node  131  is the up-side node of the link  140 ; the node  132  is the down-side node of the link  140 . 
         [0030]    The second type of links are dash arrows, physical references (such as one-way pointers or two-way pointers), each of which connects two nodes together at its two ends as a preferred embodiment of the invention. The node at the tail of a dash arrow is called the tail node of the dash arrow; and the node at the head of the arrow is called the head node of the dash arrow. Given the node at one end of an arrow, the node at the other end can be located through the arrow. For example, all the arrows in dash line in  FIG. 1  and  FIG. 6  including the arrow  160  are dash arrows 
         [0031]    The third type of links are solid arrows, physical references (such as one-way pointers or two-way pointers) that connects two nodes together at its two ends as a preferred embodiment of the invention. The node at the tail of a solid arrow is called the tail node of the solid arrow; and the node at the head of the arrow is called the head node of the solid arrow. Given the node at one end of an arrow, the node at the other end can be located through the arrow. For example, all the solid arrows including the arrow  151  are solid arrows. 
       Nodes and Database Constraints 
       [0032]    A node represents a dividable data or function. It is an end of a link, either an up-down link, a solid arrow link, or a dash arrow link. (The nodes in  FIG. 1  and  FIG. 6  are represented either as circles such as Circle  133 , or an identifier with or without a tag such as Node  131  without a tag and Node  132  with Tag  150 ) A node imposes the following constraints on the connected links: 
         [0033]    (1). Each end of a link is a node. 
         [0034]    (2). A node must not have more than one upper link of the first link type. If there is no upper link, the node is called a root. For example, the labels flour in  FIG. 1  and college.edu in  FIG. 6  are roots. Given an up-down link, the up-side node is called the superior of the down-side node; and the down-side node is called a subordinate of the up-side node. For example, Node  132  is a subordinate of Node  131 ; and Node  131  is the superior of the Node  132 . 
         [0035]    (3). A node must not have more than one dash arrow of the second like type pointing away from it. Given a dash arrow, the head node is called the parent of the tail node; and the tail node is called a child of the parent. For example, Node  133  is a child of Node  131 ; and Node  131  is the parent of Node  133 . 
         [0036]    (4). A node may have zero or more than one subordinate(s). If there is no subordinate, a node may have a tag. A node that has a tag is called a leaf node. For example, Nodes  132  is a leaf node having the tag value 123456789 (called Tag  150  in the invention specification). 
         [0037]    (5). A node may have a label. For example, the labels of Nodes  131  and  132  are John and SSN respectively. A root shall always have a label. A non-root node without label must have a dash arrow pointing away from it. For example, the Node  131  has the label John. Node  133  has the dash arrow  160  pointing away from it. 
         [0038]    (6). Starting from a node, one would never travel back to the same node by taking the links belonging to one of the three link types. Further, the nodes and the links with a single type of the connections (or links) in Database  70  form a structure of trees. For example, all the nodes and the up-down links in  FIG. 1  and  FIG. 6  form trees; all the nodes and the dash arrows in  FIG. 1  and  FIG. 6  form directed trees; and all the nodes and the solid arrows in  FIG. 1  and  FIG. 6  form directed trees. 
         [0039]    (7). Two subordinates under a single superior shall not be convertible, i.e., semantically equal, as more discussion will be done about it late in this invention description. 
       Tags 
       [0040]    A leaf node may have another db-term with a lesser font size spelled out under its label, or a solid arrow pointing away from it. In other words, a leaf node can be assigned with a tag in one of the two following forms: 
         [0041]    (1). When the given node has a solid array pointing away from it, its tag is the node connected by the head of the solid arrow. For example Node  135  has Node  134  as its tag because the solid arrow  150  is between the two nodes. 
         [0042]    (2). When the given node doesn&#39;t have a solid arrow pointing away from it, its tag is spelled with a lesser font size right below the label of the node in  FIG. 1  and  FIG. 6 . For example, Node  132  has the integer 123456789 as the tag. 
         [0043]    As a matter of fact, the tag of a leaf node represents the assignment relationship between the leaf node as the assignee and the tag as the assigner. Therefore, the two forms described above are just two alternative ways of describing assignments. 
       db-Terms 
       [0044]    The scanner of Receptionist  30  may accept requests (input expressions) in different formats through Channel  20 . But the parser of Receptionist  30  converts all the formats into the uniformed one as a preferred embodiment of this invention. This format, called db-terms, is defined in  FIG. 4 . Rule  120 , Rule  121 , and Rule  122  in  FIG. 4  say that any label is a db-term. The examples are such as college.edu, 12.4, and “a string” in  FIG. 5 . Rule  123  says that a combination of two db-terms is also a db-term. The parentheses in db-terms are the delimiters for grouping sub db-terms, and they don&#39;t have to be written if there is no ambiguity. The examples are (college.edu CS), (college.edu CS CS101 (college.edu Admin (SSD John))), ( 123  College), and (any garbage). Rule  124  says that a binary operation (M op N) with a built-in binary operator op is a db-term. The examples are SSD.gov John birth&gt;‘6/1/1980’, and spicy parmesan chicken (=Salsa in  FIG. 5 . Rule  125  says that an assignment M:=N is a db-term, where M is the assignee and N the assigner. A example is SSD.gov John birth:=‘6/1/1999’ in  FIG. 6 .  FIG. 7  and  FIG. 8  give the db-terms representing the data depicted in the diagrams of  FIG. 1  and  FIG. 6 . 
       Node Names 
       [0045]    Each node in Database  70  has a distinguished name. Given a node in Database  70 , its name is formed in the following methods: 
         [0046]    (1). If a node is a root, its name is the label of the node itself. For example, the name of Node  136  is SSD.gov. 
         [0047]    (2). If a non-root node has a label L and its superior&#39;s name is S, then the name of the non-root node is the db-term (S L). For example, Node  131  has the name SSD.gov John. 
         [0048]    (3) If a node has a parent named as P and its superior&#39;s name is S, then the name of the non-root node is the db-term (S P). For example, Node  133  in  FIG. 5  has the name (college.edu admin (SSD.gov John)). 
         [0049]    (4) If a node with named N has a tag named as T, then the relationship between N and T is represented as an assignment where the N is the assignee and T is the assigner. For example,  FIG. 4  displays the assignments: SSD.gov John birth:=‘6/1/90’, college.edu admin (SSD.gov John) enroll:=‘9/1/08’, and college.edu admin (SSD.gov John) Major:=college.edu CS. 
       Values of db-Terms 
       [0050]    For each db-term from Channel  40 , Database and Process  50  will reference Database  70 , and compute the value of the db-term. The computation (or called reduction) process from a db-term to its value is another preferred embodiment of this invention. The value of a db-term is a normal form. 
         [0051]    Given a database, a normal form is one of the followings. 
         [0052]    (1). A constant is a normal form. 
         [0053]    (2). The name of a non-leaf node is a normal form. 
         [0054]    Given a database, the Database Process  50  has the following reduction rules: 
         [0055]    (1). If a db-term is a constant, the db-term is returned as its value. 
         [0056]    (2). If a db-term is a non-leaf db-term, the db-term itself is returned as its value. 
         [0057]    (3). If a db-term has a tag, the value of the given db-term is the value of its tag. 
         [0058]    (4). Given a db-term (M N), M and N are evaluated first with the return values M′ and N′. If (M′ N′) is a db-term in the database, the value of (M N) is (M′ N′). Otherwise, the value of (M N) is Undefined. 
         [0059]    (5). Applying a constant to an arbitrary db-term returns Undefined. For example, True college.edu==Undefined, 12.3 John==Undefined. 
         [0060]    When a db-term M can be reduced to another db-term N by a finite number of reduction steps, M is said to be equal to N (or denoted as M==N); or M and N are convertible. With  FIG. 6  as a database, there are following equations: 
         [0061]    SSD.gov John birth==‘6/1/90’; 
         [0062]    College.edu admin (SSD.gov John) Major CS100==college.edu CS CS100. 
       Built-In Operators 
       [0063]    (1). The built-in operator {=, called “has-a-derivable-sub-term”, takes two db-terms M and N as its parameters. If M is a sub-term of N, then N {=M is defined to be True. For example, the expressions: SSD.gov John {=John is evaluated to be True with the database in  FIG. 6 . The expression: meat chicken seasoning cheese (sauce Salsa) baked Italian {=sauce Salsa is evaluated to be True. 
         [0064]    (3). The Built-in operator (=, called “has-a-sub-term”, takes two db-terms M and N as its parameters. If N is a sub-term of M, and there is another db-term Q such that M==Q, then Q (=N is defined to be True. For example, the expression: college.edu CS (=John is evaluated to be true in  FIG. 6 . The expression: spicy parmesan chicken (=Salsa is evaluated to be true in  FIG. 1 . 
       CONCLUSION 
       [0065]    Accordingly, readers see two unique built-in operators are available when business data is organized in the EP data model. The two built-in operators, along with other built-in operators covered under the U.S. Pat. Nos. 6,643,638 and 5,995,958, are anticipated to be very useful in the field of artificial intelligence and knowledge management. A previous experiment has demonstrated it (Reference: K. H. Xu, J. Zhang, S. Gao, “Approximating Knowledge of Cooking in Higher-order Functions, a Case Study of Froglingo”, the Workshop Proceedings of the Eighteenth International Conference on Case-Based Reasoning—ICCBR, 2010, page 219-228). Since the EP data model is semantically equivalent to a class of total recursive functions—the complete semantics for arbitrary and meaningful software applications, the built-in operators are uniquely available to Froglingo and universally applicable to arbitrary business software applications. 
         [0066]    Although the description above contains many specifications, these should not be constrained as limiting the scope of the invention but as merely providing illustrations of some of the presently preferred embodiments of this invention. Thus the scope of the invention should be determined by the appended claims and their legal equivalents, rather than by the examples given.