Techniques for processing data from a multilingual database

BACKGROUND OF THE INVENTION

p-00021. Field of the Invention

p-0003The present invention generally relates to data processing in databases and, more particularly, to providing natural language support for users running queries against a multilingual database.

p-00042. Description of the Related Art

p-0005Databases are computerized information storage and retrieval systems. A relational database management system is a computer database management system (DBMS) that uses relational techniques for storing and retrieving data. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.

p-0006Regardless of the particular architecture, a DBMS can be structured to support a variety of different types of operations for a requesting entity (e.g., an application, the operating system or an end user). Such operations can be configured to retrieve, add, modify and delete information being stored and managed by the DBMS. Standard database access methods support these operations using high-level database query languages, such as the Structured Query Language (SQL).

p-0007One type of functionality that a DBMS must support for end users is natural language support. By way of example, one framework provides natural language support for users running queries in an abstract database environment. The abstract database environment provides a requesting entity (i.e., an end-user or front-end application) with a data abstraction model that defines an abstract representation of data stored in an underlying physical storage mechanism, such as a relational database. The data abstraction model facilitates the process of query composition by allowing a user to compose abstract queries without needing to understand the schema of the physical data. The framework provides a natural language resource component that defines translation information for a given data abstraction model using one or more natural language expressions. The natural language expression(s) can be used to translate expressions occurring in a default language in an abstract query (that is composed using the given data abstraction model) into another language defined by the natural language resource component. Furthermore, query results obtained in the default language can be translated into the other language using user-defined functions that contain suitable translation information.

p-0008The foregoing framework is satisfactory to provide natural language support for single-language databases (i.e., databases having physical data that is provided in a single default language). However, databases may contain physical data provided in one or more different languages that is originated from one or more different geographic locations. In this case (i.e., when dealing with a multi-language or multilingual database), the foregoing framework is unsatisfactory.

p-0009Therefore, there is a need for an improved and more flexible technique for providing natural language support for users running queries against a multilingual database.

SUMMARY OF THE INVENTION

p-0010The present invention is generally directed to a method, system and article of manufacture for providing natural language support in a database environment and, more particularly, for providing natural language support for users running queries against a multilingual database.

p-0011One embodiment provides a computer-implemented method of providing language transformation support for a query result obtained in response to execution of a query against a multilingual database containing physical data provided in a plurality of different natural languages. The method comprises identifying one or more physical values defined by the physical data in the multilingual database for the query result associated with the executed query. At least one translation function configured to transform at least a portion of the identified physical values defined in at least one language of the plurality of different natural languages into alternative values defined in a selected language is executed, comprising: (i) identifying, from each executed translation function, a data structure mapping at least a portion of the identified physical values to translated values defined in the selected language, and (ii) retrieving the translated values in the selected language from each identified data structure, the retrieved translated values of all identified data structures defining the alternative values defined in the selected language. The method further comprises outputting the query result associated with the executed query including the alternative values defined in the selected language.

p-0012Another embodiment provides a computer-readable medium containing a program which, when executed by a processor, performs a process of providing language transformation support for a query result obtained in response to execution of a query against a multilingual database containing physical data provided in a plurality of different natural languages. The process comprises identifying one or more physical values defined by the physical data in the multilingual database for the query result associated with the executed query. At least one translation function configured to transform at least a portion of the identified physical values defined in at least one language of the plurality of different natural languages into alternative values defined in a selected language is executed, comprising: (i) identifying, from each executed translation function, a data structure mapping at least a portion of the identified physical values to translated values defined in the selected language, and (ii) retrieving the translated values in the selected language from each identified data structure, the retrieved translated values of all identified data structures defining the alternative values defined in the selected language. The process further comprises outputting the query result associated with the executed query including the alternative values defined in the selected language.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0013So that the manner in which the above recited features, advantages and objects of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.

p-0014It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.

p-0015<figref idrefs="DRAWINGS">FIG. 1</figref> is a computer system illustratively utilized in accordance with the invention;

p-0016<figref idrefs="DRAWINGS">FIG. 2</figref> is a relational view of software components in one embodiment;

p-0017<figref idrefs="DRAWINGS">FIGS. 3A-C</figref> are relational views of software components for abstract query management in one embodiment;

p-0018<figref idrefs="DRAWINGS">FIGS. 4-5</figref> are flow charts illustrating the operation of a runtime component in one embodiment;

p-0019<figref idrefs="DRAWINGS">FIG. 6</figref> is a relational view of software components in one embodiment;

p-0020<figref idrefs="DRAWINGS">FIGS. 7-9</figref> are flow charts illustrating a method of providing natural language support in a database environment in one embodiment;

p-0021<figref idrefs="DRAWINGS">FIG. 10</figref> is a flow chart illustrating a method of providing natural language support for users running queries against a database in one embodiment;

p-0022<figref idrefs="DRAWINGS">FIGS. 11-12</figref> are screenshots illustrating natural language support for users running queries against a database in one embodiment;

p-0023<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow chart illustrating a method of generating translation functions and translation mapping tables for natural language support in one embodiment;

p-0024<figref idrefs="DRAWINGS">FIG. 14</figref> is a flow chart illustrating a method of providing natural language support for query processing in one embodiment; and

p-0025<figref idrefs="DRAWINGS">FIG. 15</figref> is a flow chart illustrating a method of generating an executable query in one embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

h-0005Introduction

p-0026The present invention is generally directed to a method, system and article of manufacture for providing natural language support in a database environment and, more particularly, for providing natural language support for users running abstract queries against a multilingual database. A multilingual database is a database having physical data that is provided in one or more different languages and originated from one or more different geographic locations.

p-0027In one embodiment, an abstract query is issued from a user against an underlying multilingual database. The abstract query is specified using one or more logical fields defined by a data abstraction model abstractly describing physical data in the multilingual database. At least one logical field used for creation of the abstract query is associated with physical values defined by the physical data of the multilingual database that are defined in a plurality of different natural languages.

p-0028For execution, the abstract query is transformed into an executable query capable of being executed against the multilingual database on the basis of the data abstraction model. Thereby, a query contribution is generated in the executable query for the at least one logical field. The generated query contribution includes a function call for a translation function that is configured to transform the physical values that are associated with the at least one logical field into alternative values defined in a selected natural language (i.e., a language written by, and readable by, human-beings). The executable query is then executed against the multilingual database to obtain a corresponding result set.

p-0029As a result of executing the executable query against the multilingual database, at least a portion of the physical values that are associated with the at least one logical field are retrieved and the translation function is executed. In order to determine corresponding alternative values in the selected language for the at least one portion of the physical values, the translation function accesses associated translation information. In one embodiment, the associated translation information includes an alternative value defined in the selected natural language for each physical value that is associated with the at least one logical field. Accordingly, the alternative values for the at least one portion of the physical values can be retrieved from the translation information and included with the corresponding result set for the executable query. The result set can, thus, be output in the selected natural language to the user.

Preferred Embodiments

p-0030In the following, reference is made to embodiments of the invention. However, it should be understood that the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, in various embodiments the invention provides numerous advantages over the prior art. However, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and, unless explicitly present, are not considered elements or limitations of the appended claims.

p-0031One embodiment of the invention is implemented as a program product for use with a computer system such as, for example, computer system <b>110</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref> and described below. The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable media. Illustrative computer-readable media include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD- or DVD-ROM disks readable by a CD- or DVD-ROM drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications. The latter embodiment specifically includes information to/from the Internet and other networks. Such computer-readable media, when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.

p-0032In general, the routines executed to implement the embodiments of the invention, may be part of an operating system or a specific application, component, program, module, object, or sequence of instructions. The software of the present invention typically is comprised of a multitude of instructions that will be translated by the native computer into a machine-readable format and hence executable instructions. Also, programs are comprised of variables and data structures that either reside locally to the program or are found in memory or on storage devices. In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that any particular nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature.

An Exemplary Computing Environment

p-0033<figref idrefs="DRAWINGS">FIG. 1</figref> shows a computer <b>100</b> (which is part of a computer system <b>110</b>) that becomes a special-purpose computer according to an embodiment of the invention when configured with the features and functionality described herein. The computer <b>100</b> may represent any type of computer, computer system or other programmable electronic device, including a client computer, a server computer, a portable computer, a personal digital assistant (PDA), an embedded controller, a PC-based server, a minicomputer, a midrange computer, a mainframe computer, and other computers adapted to support the methods, apparatus, and article of manufacture of the invention.

p-0034Illustratively, the computer <b>100</b> is part of a networked system <b>110</b>. In this regard, the invention may be practiced in a distributed computing environment in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. In another embodiment, the computer <b>100</b> is a standalone device. For purposes of construing the claims, the term “computer” shall mean any computerized device having at least one processor. The computer may be a standalone device or part of a network in which case the computer may be coupled by communication means (e.g., a local area network or a wide area network) to another device (i.e., another computer).

p-0035In any case, it is understood that <figref idrefs="DRAWINGS">FIG. 1</figref> is merely one configuration for a computer system. Embodiments of the invention can apply to any comparable configuration, regardless of whether the computer <b>100</b> is a complicated multi-user apparatus, a single-user workstation, or a network appliance that does not have non-volatile storage of its own.

p-0036The computer <b>100</b> could include a number of operators and peripheral systems as shown, for example, by a mass storage interface <b>137</b> operably connected to a storage device <b>138</b>, by a video interface <b>140</b> operably connected to a display <b>142</b>, and by a network interface <b>144</b> operably connected to the plurality of networked devices <b>146</b> (which may be representative of the Internet) via a suitable network. Although storage <b>138</b> is shown as a single unit, it could be any combination of fixed and/or removable storage devices, such as fixed disc drives, floppy disc drives, tape drives, removable memory cards, or optical storage. The display <b>142</b> may be any video output device for outputting viewable information.

p-0037Computer <b>100</b> is shown comprising at least one processor <b>112</b>, which obtains instructions and data via a bus <b>114</b> from a main memory <b>116</b>. The processor <b>112</b> could be any processor adapted to support the methods of the invention. In particular, the computer processor <b>112</b> is selected to support the features of the present invention. Illustratively, the processor is a PowerPC® processor available from International Business Machines Corporation of Armonk, N.Y.

p-0038The main memory <b>116</b> is any memory sufficiently large to hold the necessary programs and data structures. Main memory <b>116</b> could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory, (e.g., programmable or Flash memories, read-only memories, etc.). In addition, memory <b>116</b> may be considered to include memory physically located elsewhere in the computer system <b>110</b>, for example, any storage capacity used as virtual memory or stored on a mass storage device (e.g., direct access storage device <b>138</b>) or on another computer coupled to the computer <b>100</b> via bus <b>114</b>. Thus, main memory <b>116</b> and storage device <b>138</b> could be part of one virtual address space spanning multiple primary and secondary storage devices.

An Exemplary Database and Query Environment

p-0039<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a relational view of software components, according to one embodiment of the invention. The software components include a database <b>130</b>, an abstract model interface <b>122</b>, a user interface <b>160</b>, a query execution unit <b>180</b> and one or more applications <b>190</b> (only one application is illustrated for simplicity).

p-0040According to one aspect, the application <b>190</b> (and more generally, any requesting entity including, at the highest level, users) issues queries, such as abstract query <b>140</b>, against data <b>132</b> in the database <b>130</b>. The queries issued by the application <b>190</b> are defined according to an application query specification <b>192</b> and may be predefined (i.e., hard coded as part of the application <b>190</b>) or generated in response to input (e.g., user input). The application query specification(s) <b>192</b> and the abstract model interface <b>122</b> are further described below with reference to <figref idrefs="DRAWINGS">FIGS. 3-5</figref>.

p-0041In one embodiment, the queries issued by the application <b>190</b> are created by users using the user interface <b>160</b>, which can be any suitable user interface configured to create/submit queries. According to one aspect, the user interface <b>160</b> is a graphical user interface. However, it should be noted that the user interface <b>160</b> is only shown by way of example; any suitable requesting entity may create and submit queries against the database <b>130</b> (e.g., the application <b>190</b>, an operating system or an end user). Accordingly, all such implementations are broadly contemplated.

p-0042In one embodiment, the requesting entity accesses a suitable database connectivity tool such as a Web application, an Open DataBase Connectivity (ODBC) driver, a Java® DataBase Connectivity (JDBC) driver or a Java® Application Programming Interface (Java® API) for creation of a query. A Web application is an application that is accessible by a Web browser and that provides some function beyond static display of information, for instance by allowing the requesting entity to query the database <b>130</b>. An ODBC driver is a driver that provides a set of standard application programming interfaces to perform database functions such as connecting to the database <b>130</b>, performing dynamic SQL functions, and committing or rolling back database transactions. A JDBC driver is a program included with a database management system to support JDBC standard access between the database <b>130</b> and Java® applications. A Java® API is a Java®-based interface that allows an application program (e.g., the requesting entity, the ODBC or the JDBC) that is written in a high-level language to use specific data or functions of an operating system or another program (e.g., the application <b>190</b>).

p-0043Accordingly, the queries issued by the application <b>190</b> can be in physical form, such as SQL and/or XML queries, which are consistent with the physical representation of the data <b>132</b> in the database <b>130</b>. Alternatively, the queries issued by the application <b>190</b> are composed using the abstract model interface <b>122</b>. Such queries are referred to herein as “abstract queries”. More specifically, abstract queries are created on the basis of logical fields defined by an underlying data abstraction model.

p-0044In the illustrated example, the abstract query <b>140</b> is created on the basis of logical fields defined by a data abstraction model <b>124</b>. In one embodiment, the abstract query <b>140</b> is created by creating a results specification and, if required, selection criteria, as explained in more detail below with reference to <figref idrefs="DRAWINGS">FIGS. 3B-C</figref>. The results specification is defined by one or more result fields specifying what data elements should be returned from the database <b>130</b>. The selection criteria is defined using one or more condition fields in corresponding query conditions that are configured to evaluate whether a given element of the data <b>132</b> should be returned. The result field(s) and the condition field(s) are defined using the logical fields of the data abstraction model <b>124</b>.

p-0045The abstract queries are transformed into a form consistent with the physical representation of the data <b>132</b> for execution. For instance, the abstract queries are transformed by a runtime component <b>126</b> into concrete (i.e., executable) queries which are executed by the query execution unit <b>180</b> against the data <b>132</b> of the database <b>130</b>.

p-0046The database <b>130</b> is representative of any collection of data regardless of the particular physical representation. By way of illustration, the database <b>130</b> may be organized according to a relational schema (accessible by SQL queries) or according to an XML schema (accessible by XML queries). However, the invention is not limited to a particular schema and contemplates extensions to schemas presently unknown. As used herein, the term “schema” generically refers to a particular arrangement of data.

p-0047In one embodiment, the database <b>130</b> is a multilingual database. In other words, the database <b>130</b> contains physical data that is provided in one or more different languages and originated from one or more different geographic locations. For instance, the database <b>130</b> is a medical database used to collect data about patients from medical institutions that are located in different countries, such as the United States of America, Mexico and Germany. Accordingly, data coming from the American medical institution(s) can be defined in English, data from the Mexican medical institution(s) in Spanish and data from the German medical institution(s) in German.

p-0048In one embodiment, the query execution unit <b>180</b> includes a natural language support (NLS) manager <b>120</b>. The NLS manager <b>120</b> provides natural language support for users running queries against the multilingual database <b>130</b>. Interaction and operation of the NLS manager <b>120</b>, the application <b>190</b> and the abstract model interface <b>122</b> to provide natural language support in query execution is explained in more detail below with reference to <figref idrefs="DRAWINGS">FIGS. 6-15</figref>.

p-0049It should be noted that the query execution unit <b>180</b> illustratively only includes the NLS manager <b>120</b>, for simplicity. However, the query execution unit <b>180</b> may include other components, such as a query engine, a query parser and a query optimizer. A query parser is generally configured to accept a received executable query input from a requesting entity, such as the application(s) <b>190</b>, and then parse the received executable query. The query parser may then forward the parsed executable query to the query optimizer for optimization. A query optimizer is an application program which is configured to construct a near optimal search strategy (known as an “access plan”) for a given set of search parameters, according to known characteristics of an underlying database (e.g., the database <b>130</b>), an underlying system on which the search strategy will be executed (e.g., computer system <b>110</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>), and/or optional user specified optimization goals. But not all strategies are equal and various factors may affect the choice of an optimum search strategy. However, in general such search strategies merely determine an optimized use of available hardware/software components to execute respective queries. Once an access plan is selected, the query engine may then execute the executable query according to the selected access plan.

p-0050Illustratively, the NLS manager <b>120</b> includes a natural language resource component <b>150</b> (hereinafter referred to as language resource component <b>150</b>). The language resource component <b>150</b> defines a natural language expression for user-viewable elements defined by logical fields of the data abstraction model <b>124</b>. In one embodiment, the language resource component <b>150</b> defines a natural language expression for each attribute (e.g., name) and/or corresponding value in a logical field. These natural language expressions can be different from expressions defined by the data abstraction model <b>124</b> (hereinafter referred to as “default language expressions”). Accordingly, the language resource component <b>150</b> is considered to provide translation information for the data abstraction model <b>124</b>.

p-0051More generally, the language resource component <b>150</b> includes translations for one or more of the elements (e.g., logical field names, values, etc.) defined by the data abstraction model <b>124</b> from a first natural language expression (e.g., the default language expressions) to a second natural language expression (e.g., expressions in a selected foreign language or a selected terminology). For a given data abstraction model <b>124</b>, the language resource component <b>150</b> can further be configured to describe translations from the first natural language expression into two or more other natural language expressions. Thus, in one embodiment, which instance of the data abstraction model <b>124</b> a user “sees” will depend upon which natural language expression files are loaded to define the language resource component <b>150</b>. In any case, the various natural language expressions can be different languages or different variations (i.e., terminologies) on the same language.

p-0052It is noted that particular embodiments described herein can refer to translation of selected elements of the data abstraction model <b>124</b>. For example, embodiments may be described with reference to field name translations (e.g., “gender” translated to “sex”). However, references to translations of specific data abstraction model elements are done merely for purposes of illustration and not limiting of the invention. Thus, it is broadly contemplated that any element of the data abstraction model <b>124</b> can be translated.

p-0053In one embodiment, the language resource component <b>150</b> is used for natural language support of users running an abstract query, such as the abstract query <b>140</b>, against the data <b>132</b> of the database <b>130</b>. To this end, the language resource component <b>150</b> defines one or more natural language expressions for each of a plurality of logical fields of the data abstraction model <b>124</b> which provides definitions (also referred to herein as “specifications”) for the plurality of logical fields. More specifically, the language resource component <b>150</b> can be used to determine natural language expression(s) for elements of logical fields displayed to the user for creation of the abstract query <b>140</b>. Thus, the elements of the logical fields that are available for specification of the abstract query <b>140</b> can be displayed to the user in the determined natural language expression(s). Accordingly, the user can compose the abstract query <b>140</b> using the one or more elements of the logical fields in the displayed natural language expression(s). Query creation using natural language expressions is illustrated in <figref idrefs="DRAWINGS">FIGS. 11-12</figref> which show exemplary screenshots illustrating display of elements of logical fields using exemplary Spanish expressions.

p-0054Illustratively, the NLS manager <b>120</b> further includes the application query specification <b>192</b>, one or more translation functions <b>152</b> and one or more translation mapping tables <b>154</b>. In one embodiment, each of the translation mapping tables <b>154</b> is created for one or more logical fields of the data abstraction model <b>124</b>. According to one aspect, the translation mapping tables <b>154</b> can be created on the basis of the language resource component <b>150</b>.

p-0055Each of the translation mapping tables <b>154</b> includes one or more translated values defined in one or more natural languages for each physical value of the data <b>132</b> that is associated with the one or more logical fields for which the translation mapping table <b>154</b> is created. Accordingly, the translation mapping tables <b>154</b> are considered to provide translation information for physical values defining at least a portion of the data <b>132</b> of the multilingual database <b>130</b>. Each translation function <b>152</b> is configured to identify one or more of the translation mapping tables <b>154</b> for a given logical field and to retrieve required alternative values for an underlying result set from translated values included therewith, as described in more detail below.

p-0056When executing the executable query against the database <b>130</b>, the query execution unit <b>180</b> determines physical values from the data <b>132</b> of the multilingual database <b>130</b> for a corresponding result set. In the illustrated example, the query execution unit <b>180</b> determines the physical values for one or more logical fields specified by the abstract query <b>140</b>. As noted above, the determined physical values can be defined in one or more different natural languages, thereby resulting in a multilingual query result. However, in order to return a natural language result set <b>172</b> in a selected language to the application <b>190</b>, the query execution unit <b>180</b> executes the translation function(s) <b>152</b> on the determined physical values.

p-0057The executed translation function(s) <b>154</b> accesses the translation mapping table(s) <b>154</b> to determine alternative values in the selected language for the determined physical values. In one embodiment, the selected language uses natural language expressions which are considered to be more meaningful to users and, thus, more user-friendly. More specifically, the alternative values can be adapted to a role of a given user or a preferred language used by the user. The retrieved alternative values are included with the natural language result set <b>172</b>. Accordingly, in one embodiment the natural language result set <b>172</b> only includes data that is defined in the selected language. The natural language result set <b>172</b> is then output to the application <b>190</b>. Query execution and generation of the natural language result set <b>172</b> in a selected language is described in more detail below with reference to <figref idrefs="DRAWINGS">FIGS. 13-15</figref>.

Logical/Runtime View of Environment

p-0058Referring now to <figref idrefs="DRAWINGS">FIG. 3A</figref>, a relational view illustrating operation and interaction of the application(s) <b>190</b> and the data abstract model interface <b>122</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> is shown. The abstract model interface <b>122</b> illustratively provides an interface to the data abstraction model <b>124</b> and the runtime component <b>126</b> of <figref idrefs="DRAWINGS">FIGS. 2-3A</figref>.

p-0059The data abstraction model <b>124</b> defines logical fields corresponding to physical entities of data in the database <b>130</b>, thereby providing a logical representation of the data. In a relational database environment having a multiplicity of database tables, a specific logical representation having specific logical fields can be provided for each database table. In this case, all specific logical representations together constitute the data abstraction model <b>124</b>. The physical entities of the data are arranged in the database <b>130</b> according to a physical representation of the data. By way of illustration, two physical representations are shown, an XML data representation <b>214</b>₁and a relational data representation <b>214</b>₂. However, the physical representation <b>214</b>_Nindicates that any other physical representation, known or unknown, is contemplated.

p-0060In one embodiment, a different single data abstraction model is provided for each separate physical representation <b>214</b>_{1, 2, . . . , N}, as explained above for the case of a relational database environment. In an alternative embodiment, a single data abstraction model <b>124</b> contains field specifications (with associated access methods) for two or more physical representations <b>214</b>_{1, 2, . . . , N}.

p-0061Using a logical representation of the data, the application query specification <b>192</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> specifies one or more logical fields to compose the abstract query <b>140</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. A requesting entity (e.g., the application <b>190</b>) issues the abstract query <b>140</b> as defined by the application query specification <b>192</b>. In one embodiment, the abstract query <b>140</b> may include both criteria used for data selection and an explicit specification of result fields to be returned based on the data selection criteria. An example of the selection criteria and the result field specification of the abstract query <b>140</b> is shown in <figref idrefs="DRAWINGS">FIGS. 3B-C</figref>. Accordingly, the abstract query <b>140</b> illustratively includes selection criteria <b>304</b> and a results specification <b>306</b>.

p-0062The abstract query <b>140</b> is generally referred to herein as an “abstract query” because the query is composed according to abstract (i.e., logical) fields rather than by direct reference to the underlying physical data entities in the database <b>130</b>. As a result, abstract queries may be defined that are independent of the particular underlying physical data representation used. For execution, the abstract query <b>140</b> is transformed into a concrete query consistent with the underlying physical representation of the data using the data abstraction model <b>124</b>.

p-0063In general, the data abstraction model <b>124</b> exposes information as a set of logical fields that may be used within an abstract query to specify criteria for data selection and specify the form of result data returned from a query operation. The logical fields are defined independently of the underlying physical representation being used in the database <b>130</b>, thereby allowing abstract queries to be formed that are loosely coupled to the underlying physical representation.

p-0064Referring now to <figref idrefs="DRAWINGS">FIG. 3B</figref>, a relational view illustrating interaction of the abstract query <b>140</b> and the data abstraction model <b>124</b> is shown. In one embodiment, the data abstraction model <b>124</b> comprises a plurality of field specifications <b>308</b>₁, <b>308</b>₂, <b>308</b>₃, <b>308</b>₄, <b>308</b>₅, <b>308</b>₆and <b>308</b>₇(seven shown by way of example), collectively referred to as the field specifications <b>308</b> (also referred to hereinafter as “field definitions”). Specifically, a field specification is provided for each logical field available for composition of an abstract query. Each field specification may contain one or more attributes. Illustratively, the field specifications <b>308</b> include a logical field name attribute <b>320</b>₁, <b>320</b>₂, <b>320</b>₃, <b>320</b>₄, <b>320</b>₅, <b>320</b>₆and <b>320</b>₇(collectively, field name <b>320</b>) and an associated access method attribute <b>322</b>₁, <b>322</b>₂, <b>322</b>₃, <b>322</b>₄, <b>322</b>₅, <b>322</b>₆and <b>322</b>₇(collectively, access methods <b>322</b>). Each attribute may have a value. For example, logical field name attribute <b>320</b>₁has the value “FirstName” and access method attribute <b>322</b>₁has the value “Simple”. Furthermore, each attribute may include one or more associated abstract properties. Each abstract property describes a characteristic of a data structure and has an associated value. In the context of the invention, a data structure refers to a part of the underlying physical representation that is defined by one or more physical entities of the data corresponding to the logical fields. In particular, an abstract property may represent data location metadata abstractly describing a location of a physical data entity corresponding to the data structure, like a name of a database table or a name of a column in a database table. Illustratively, the access method attribute <b>322</b>₁includes data location metadata “Table” and “Column”. Furthermore, data location metadata “Table” has the value “contact” and data location metadata “Column” has the value “f_name”. Accordingly, assuming an underlying relational database schema in the present example, the values of data location metadata “Table” and “Column” point to a table “contact” having a column “f_name”.

p-0065In one embodiment, each field specification <b>308</b> may contain a definition of one or more value constraints that define allowable values for the respective logical field. By way of example, the field specifications <b>308</b>₆and <b>308</b>₇include exemplary list definitions.

p-0066Illustratively, the field specification <b>308</b>₆includes a list definition <b>325</b> that enumerates allowable values for associated marital status data. By way of example, the list definition <b>325</b> defines “Single”, “Married”, “Divorced”, “Widowed” and “Unknown” as allowable values for data that is associated with the “MaritalStatus” field <b>308</b>₆. The field specification <b>308</b>₇illustratively includes a list definition <b>346</b> that enumerates allowable values for associated gender data. By way of example, the list definition <b>346</b> defines “Male”, “Female” and “Unknown” as allowable values for data that is associated with the “Gender” field <b>308</b>₇.

p-0067It should be noted that the illustrated list definitions are merely illustrative for value constraint definitions and not limiting of the invention. For instance, in one embodiment a given field specification may include a limitation definition that defines an allowable range of values for associated data. By way of example, assume a logical field having associated Hemoglobin values and a limitation definition that defines “0” as minimum allowable value and “100” as maximum allowable value for data that is associated with the field. In another embodiment, a given field specification may include a classification definition that defines value classes for values of associated data. For instance, assume a logical field having associated age values and a classification definition that defines four different value classes “Class 1” to “Class 4”. By way of example, age values from “0” to “12” can be associated with “Class 1” that can be referred to as the “Child” class. Age values from “13” to “17” are can be associated with “Class 2” that can be referred to as the “Adolescent” class, age values from “18” to “64” with “Class 3” that can be referred to as the “Adult” class, and age values from “65” to “120” with “Class 4” that can be referred to as the “Senior” class. Accordingly, any possible value constraint definitions are broadly contemplated.

p-0068Furthermore, the illustrated value constraint definitions can be adapted to user- and/or application-specific requirements. By way of example, for execution of a given query a user may define an upper and a lower limit of normal for the limitation definition of the Hemoglobin values. More specifically, the user may input corresponding upper and/or lower limits of normal lying within the defined minimum and maximum allowable values prior to query execution to customize the limitation definition. For instance, assume that the user defines for the Hemoglobin values a lower limit of normal as “15” and an upper limit as “25”. Thus, all Hemoglobin values of a corresponding query result returned in execution of the given query lying inside the lower and upper limits of normal could be considered as “normal” values. Values below the lower limit of normal could be considered as “low” and values above the upper limit of normal could be considered as “high”. Accordingly, all such possible implementations are broadly contemplated.

p-0069In one embodiment, the field specification <b>308</b> of each logical field may contain an attribute indicating whether data in the database <b>130</b> that is associated with the logical field can be defined in one or more different natural languages. By way of example, the field specification <b>308</b>₇includes an exemplary “Field Language” attribute <b>348</b>. Illustratively, the “Field Language” attribute <b>348</b> has the value “Multilingual” in order to indicate that different physical values defining data in the “gender” column of the “contact” table (cp. access method <b>322</b>₇) in the database <b>130</b> can be defined in different natural languages.

p-0070However, it should be noted that provision of an attribute indicating whether data associated with a given logical field can be defined in one or more different natural languages in the database <b>130</b> is merely optional. For instance, assume that in the given example physical values in the “m_status” column of the “contact” table (cp. access method <b>322</b>₆) in the database <b>130</b> that are associated with the “MaritalStatus” field <b>308</b>₆may also be defined in more than one natural language. However, the field specification <b>308</b>₆does not include a “Field Language” attribute. Accordingly, all such different implementations are broadly contemplated.

p-0071In one embodiment, groups (i.e. two or more) of logical fields may be part of categories. Accordingly, the data abstraction model <b>124</b> includes a plurality of category specifications <b>310</b>₁and <b>310</b>₂(two shown by way of example), collectively referred to as the category specifications. In one embodiment, a category specification is provided for each logical grouping of two or more logical fields. For example, logical fields <b>308</b>_1-3and <b>308</b>_4-7are part of the category specifications <b>310</b>₁and <b>310</b>₂, respectively. A category specification is also referred to herein simply as a “category”. The categories are distinguished according to a category name, e.g., category names <b>330</b>₁and <b>330</b>₂(collectively, category name(s) <b>330</b>). In the present illustration, the logical fields <b>308</b>_1-3are part of the “Name and Address” category and logical fields <b>308</b>_4-7are part of the “Birth, Age and Gender” category.

p-0072The access methods <b>322</b> generally associate (i.e., map) the logical field names to data in the database (e.g., database <b>130</b>). Any number of access methods is contemplated depending upon the number of different types of logical fields to be supported. In one embodiment, access methods for simple fields, filtered fields and composed fields are provided. The field specifications <b>308</b>₁, <b>308</b>₂and <b>308</b>₅exemplify simple field access methods <b>322</b>₁, <b>322</b>₂, and <b>322</b>₅, respectively. Simple fields are mapped directly to a particular entity in the underlying physical representation (e.g., a field mapped to a given database table and column). By way of illustration, as described above, the simple field access method <b>322</b>₁shown in <figref idrefs="DRAWINGS">FIG. 3B</figref> maps the logical field name <b>320</b>₁(“FirstName”) to a column named “f_name” in a table named “contact”. The field specification <b>308</b>₃exemplifies a filtered field access method <b>322</b>₃. Filtered fields identify an associated physical entity and provide filters used to define a particular subset of items within the physical representation. An example is provided in <figref idrefs="DRAWINGS">FIG. 3B</figref> in which the filtered field access method <b>322</b>₃maps the logical field name <b>320</b>₃(“AnyTownLastName”) to a physical entity in a column named “I_name” in a table named “contact” and defines a filter for individuals in the city of “Anytown”. Another example of a filtered field is a New York ZIP code field that maps to the physical representation of ZIP codes and restricts the data only to those ZIP codes defined for the state of New York. The field specification <b>308</b>₄exemplifies a composed field access method <b>322</b>₄. Composed access methods compute a logical field from one or more physical fields using an expression supplied as part of the access method definition. In this way, information which does not exist in the underlying physical data representation may be computed. In the example illustrated in <figref idrefs="DRAWINGS">FIG. 3B</figref> the composed field access method <b>322</b>₄maps the logical field name <b>320</b>₄“AgeInDecades” to “AgeInYears/10”. Another example is a sales tax field that is composed by multiplying a sales price field by a sales tax rate.

p-0073It is contemplated that the formats for any given data type (e.g., dates, decimal numbers, etc.) of the underlying data may vary. Accordingly, in one embodiment, the field specifications <b>308</b> include a type attribute which reflects the format of the underlying data. However, in another embodiment, the data format of the field specifications <b>308</b> is different from the associated underlying physical data, in which case a conversion of the underlying physical data into the format of the logical field is required.

p-0074By way of example, the field specifications <b>308</b> of the data abstraction model <b>124</b> shown in <figref idrefs="DRAWINGS">FIGS. 3B-C</figref> are representative of logical fields mapped to data represented in the relational data representation <b>214</b>₂shown in <figref idrefs="DRAWINGS">FIG. 3A</figref>. However, other instances of the data abstraction model <b>124</b> map logical fields to other physical representations, such as XML.

p-0075An illustrative abstract query corresponding to the abstract query <b>140</b> shown in <figref idrefs="DRAWINGS">FIG. 3B</figref> is shown in Table I below. By way of illustration, the illustrative abstract query is defined using XML. However, any other language may be used to advantage.

p-0076<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE I</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ABSTRACT QUERY EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>001  </entry></row><row><entry /><entry>002  <!--Query string representation: (AgeInYears > “55”--></entry></row><row><entry /><entry>003  <QueryAbstraction></entry></row><row><entry /><entry>004   <Selection></entry></row><row><entry /><entry>005   <Condition field=“AgeInYears” operator=“GT” value=“55”</entry></row><row><entry /><entry>006             internalID=“1”/></entry></row><row><entry /><entry>007   </Selection></entry></row><row><entry /><entry>008   <Results></entry></row><row><entry /><entry>009    <Field name=“FirstName”/></entry></row><row><entry /><entry>010    <Field name=“AnyTownLastName”/></entry></row><row><entry /><entry>011    <Field name=“Street”/></entry></row><row><entry /><entry>012   </Results></entry></row><row><entry /><entry>013  </QueryAbstraction></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0077Illustratively, the abstract query shown in Table I includes a selection specification (lines 004-007) containing selection criteria and a results specification (lines 008-012). In one embodiment, a selection criterion consists of a field name (for a logical field), a comparison operator (=, >, <, etc) and a value expression (what is the field being compared to). In one embodiment, the results specification is a list of abstract fields that are to be returned as a result of query execution. A results specification in the abstract query may consist of a field name and sort criteria.

p-0078In one embodiment, the abstract query shown in Table I is constructed by an application (e.g., application <b>190</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>). Furthermore, a language resource component (e.g., language resource component <b>150</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) is provided which is associated with the data abstraction model <b>124</b>. The language resource component can be adapted, for instance, to translate elements (e.g., logical field names, values, etc.) of the data abstraction model <b>124</b> into the Russian language. Thus, the application may construct the abstract query using the translation of each element in the Russian language. An associated NLS manager (e. g., NLS manager <b>120</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) can generate an internal representation of the abstract query in a default or untranslated form, i.e., without using the Russian language translations. Thus, the internal representation can be used and accessed by the runtime component <b>126</b> for processing.

p-0079In one embodiment, the language resource component associated with the data abstraction model <b>124</b> (or at least a file defining a portion of the language resource component) is specified within the data abstraction model <b>124</b> itself. Accordingly, the data abstraction model <b>124</b> shown in <figref idrefs="DRAWINGS">FIGS. 3B-C</figref> includes a language resource specification <b>312</b>₁. The language resource specification <b>312</b>₁includes a reference to a particular language resource component (e.g., language resource component <b>150</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>, or a portion thereof) which is associated with the data abstraction model <b>124</b>. Illustratively, the language resource specification <b>312</b>₁includes a language resource file definition <b>340</b>₁having an abstract attribute <b>342</b>₁“File”. By way of example, the language resource file definition <b>340</b>₁indicates a corresponding language resource file name “ABC-XLIFF”. Additional aspects of an illustrative “ABC-XLIFF” language resource file are described below.

p-0080An illustrative Data Abstraction Model (DAM) corresponding to the data abstraction model <b>124</b> shown in <figref idrefs="DRAWINGS">FIGS. 3B-C</figref> is shown in Table II below. By way of illustration, the illustrative data abstraction model is defined using XML. However, any other language may be used to advantage.

p-0081<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE II</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>DATA ABSTRACTION MODEL EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>001  </entry></row><row><entry>002  <DataAbstraction></entry></row><row><entry>003  <Category name=“Name and Address”></entry></row><row><entry>004   <Field queryable=“Yes” name=“FirstName” displayable=“Yes”></entry></row><row><entry>005     <AccessMethod></entry></row><row><entry>006      <Simple columnName=“f_name”</entry></row><row><entry>        tableName=“contact”></Simple></entry></row><row><entry>007      </AccessMethod></entry></row><row><entry>008   </Field></entry></row><row><entry>009   <Field queryable=“Yes” name=“LastName” displayable=“Yes”></entry></row><row><entry>010    <AccessMethod></entry></row><row><entry>011      <Simple columnName=“l_name”</entry></row><row><entry>        tableName=“contact”></Simple></entry></row><row><entry>012    </AccessMethod></entry></row><row><entry>013   </Field></entry></row><row><entry>014   <Field queryable=“Yes” name=“AnyTownLastName”</entry></row><row><entry>     displayable=“Yes”></entry></row><row><entry>015    <AccessMethod></entry></row><row><entry>016      <Filter columnName=“l_name” tableName=“contact”</entry></row><row><entry>017      Filter=”contact.city=Anytown”> </Filter></entry></row><row><entry>018    </AccessMethod></entry></row><row><entry>019   </Field></entry></row><row><entry>020  </Category></entry></row><row><entry>021  <Category name=“Birth, Age and Gender”></entry></row><row><entry>022   <Field queryable=“Yes” name=“AgeInDecades”</entry></row><row><entry>     displayable=“Yes”></entry></row><row><entry>023    <AccessMethod></entry></row><row><entry>024      <Composed</entry></row><row><entry>025        Expression=”field:AgeInYears/10”> </Composed></entry></row><row><entry>026     </AccessMethod></entry></row><row><entry>027   </Field></entry></row><row><entry>028   <Field queryable=“Yes” name=“AgeInYears”</entry></row><row><entry>     displayable=“Yes”></entry></row><row><entry>029     <AccessMethod></entry></row><row><entry>030      <Simple columnName=“age”</entry></row><row><entry>        tableName=“contact”></Simple></entry></row><row><entry>031     </AccessMethod></entry></row><row><entry>032   </Field></entry></row><row><entry>033   <Field queryable=“Yes” name=“MaritalStatus”</entry></row><row><entry>     displayable=“Yes”></entry></row><row><entry>034     <AccessMethod></entry></row><row><entry>035      <Simple columnName=“m_status”</entry></row><row><entry>        tableName=“contact”></Simple></entry></row><row><entry>036     </AccessMethod></entry></row><row><entry>037       <List></entry></row><row><entry>038         <Value val=“Single” /></entry></row><row><entry>039         <Value val=“Married” /></entry></row><row><entry>040         <Value val=“Divorced” /></entry></row><row><entry>041         <Value val=“Widowed” /></entry></row><row><entry>042         <Value val=“Unknown” /></entry></row><row><entry>043       </List></entry></row><row><entry>044   </Field></entry></row><row><entry>045   <Field queryable=“Yes” name=“Gender” displayable=“Yes”</entry></row><row><entry>046       multilingual = “Yes”></entry></row><row><entry>047     <AccessMethod></entry></row><row><entry>048      <Simple columnName=“gender”</entry></row><row><entry>        tableName=“contact”></Simple></entry></row><row><entry>049     </AccessMethod></entry></row><row><entry>050       <List></entry></row><row><entry>051         <Value val=“Female” /></entry></row><row><entry>052         <Value val=“Male” /></entry></row><row><entry>053         <Value val=“Unknown” /></entry></row><row><entry>054       </List></entry></row><row><entry>055   </Field></entry></row><row><entry>056   </Category></entry></row><row><entry>057   <LanguageResource file=“ABC-XLIFF.xml”></entry></row><row><entry>058  </DataAbstraction></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0082By way of example, note that lines 004-008 correspond to the first field specification <b>308</b>₁of the DAM <b>124</b> shown in <figref idrefs="DRAWINGS">FIGS. 3B-C</figref> and lines 009-013 correspond to the second field specification <b>308</b>₂. The other field specifications of <figref idrefs="DRAWINGS">FIGS. 3B-C</figref> are shown in headlines 014-019, 022-027, 028-032, 033-044 and 045-055. Note that line 046 defines a “multilingual” attribute (“multilingual=“Yes”) that corresponds to the “Multilingual” attribute <b>348</b> shown in <figref idrefs="DRAWINGS">FIGS. 3B-C</figref>. Furthermore, note that line 057 corresponds to the language resource file definition <b>340</b>₁of the DAM shown in <figref idrefs="DRAWINGS">FIGS. 3B-C</figref>. More specifically, line <b>057</b> includes a reference to an exemplary “ABC-XLIFF.xml” language resource file. In one embodiment, the ABC-XLIFF.xml file defines a default file containing default natural language expressions for a plurality of elements of the data abstraction model <b>124</b>. One or more additional language resource files may then be loaded and applied to the default file to define a particular view of the data abstraction model <b>124</b>. Determination of an appropriate language resource file and loading of one or more language resource files associated with a data abstraction model can be performed using conventional techniques applied to the data abstraction model. Examples of determination and loading are explained in more detail below with reference to <figref idrefs="DRAWINGS">FIGS. 6-10</figref>.

p-0083As was noted above, the abstract query of Table I can be transformed into a concrete query for query execution. An exemplary method for transforming an abstract query into a concrete query is described below with reference to <figref idrefs="DRAWINGS">FIGS. 4-5</figref>.

Transforming an Abstract Query into a Concrete Query

p-0084Referring now to <figref idrefs="DRAWINGS">FIG. 4</figref>, an illustrative runtime method <b>400</b> exemplifying one embodiment of the operation of the runtime component <b>126</b> of <figref idrefs="DRAWINGS">FIGS. 2-3</figref> in conjunction with the data abstraction model <b>124</b> of <figref idrefs="DRAWINGS">FIGS. 2-3</figref> is shown. The method <b>400</b> is entered at step <b>402</b> when the runtime component <b>126</b> receives as input an abstract query (such as the abstract query shown in Table I). At step <b>404</b>, the runtime component <b>126</b> reads and parses the abstract query and locates individual selection criteria and desired result fields. At step <b>406</b>, the runtime component <b>126</b> enters a loop (comprising steps <b>406</b>, <b>408</b>, <b>410</b> and <b>412</b>) for processing each query selection criteria statement present in the abstract query, thereby building a data selection portion of a concrete query. In one embodiment, a selection criterion consists of a field name (for a logical field), a comparison operator (=, >, <, etc) and a value expression (what is the field being compared to). At step <b>408</b>, the runtime component <b>126</b> uses the field name from a selection criterion of the abstract query to look up the definition of the field in the data abstraction model <b>124</b>. As noted above, the field definition includes a definition of the access method used to access the physical data associated with the field. The runtime component <b>126</b> then builds (step <b>410</b>) a concrete query contribution for the logical field being processed. As defined herein, a concrete query contribution is a portion of a concrete query that is used to perform data selection based on the current logical field. A concrete query is a query represented in languages like SQL and XML Query and is consistent with the data of a given physical data repository (e.g., a relational database or XML repository). Accordingly, the concrete query is used to locate and retrieve data from the physical data repository, represented by the database <b>130</b> shown in <figref idrefs="DRAWINGS">FIG. 3A</figref>. The concrete query contribution generated for the current field is then added to a concrete query statement. The method <b>400</b> then returns to step <b>406</b> to begin processing for the next field of the abstract query. Accordingly, the process entered at step <b>406</b> is iterated for each data selection field in the abstract query, thereby contributing additional content to the eventual query to be performed.

p-0085After building the data selection portion of the concrete query, the runtime component <b>126</b> identifies the information to be returned as a result of query execution. As described above, in one embodiment, the abstract query defines a list of abstract fields that are to be returned as a result of query execution, referred to herein as a results specification. A results specification in the abstract query may consist of a field name and sort criteria. Accordingly, the method <b>400</b> enters a loop at step <b>414</b> (defined by steps <b>414</b>, <b>416</b>, <b>418</b> and <b>420</b>) to add result field definitions to the concrete query being generated. At step <b>416</b>, the runtime component <b>126</b> looks up a result field name (from the results specification of the abstract query) in the data abstraction model <b>124</b> and then retrieves a result field definition from the data abstraction model <b>124</b> to identify the physical location of data to be returned for the current logical result field. The runtime component <b>126</b> then builds (at step <b>418</b>) a concrete query contribution (of the concrete query that identifies physical location of data to be returned) for the logical result field. At step <b>420</b>, the concrete query contribution is then added to the concrete query statement. Once each of the result specifications in the abstract query has been processed, the concrete query is executed at step <b>422</b>.

p-0086One embodiment of a method <b>500</b> for building a concrete query contribution for a logical field according to steps <b>410</b> and <b>418</b> of <figref idrefs="DRAWINGS">FIG. 4</figref> is described with reference to <figref idrefs="DRAWINGS">FIG. 5</figref>. At step <b>502</b>, the method <b>500</b> queries whether the access method associated with the current logical field is a simple access method. If so, the concrete query contribution is built (step <b>504</b>) based on physical data location information and processing then continues according to method <b>400</b> described above. Otherwise, processing continues to step <b>506</b> to query whether the access method associated with the current logical field is a filtered access method. If so, the concrete query contribution is built (step <b>508</b>) based on physical data location information for some physical data entity. At step <b>510</b>, the concrete query contribution is extended with additional logic (filter selection) used to subset data associated with the physical data entity. Processing then continues according to method <b>400</b> described above.

p-0087If the access method is not a filtered access method, processing proceeds from step <b>506</b> to step <b>512</b> where the method <b>500</b> queries whether the access method is a composed access method. If the access method is a composed access method, the physical data location for each sub-field reference in the composed field expression is located and retrieved at step <b>514</b>. At step <b>516</b>, the physical field location information of the composed field expression is substituted for the logical field references of the composed field expression, whereby the concrete query contribution is generated. Processing then continues according to method <b>400</b> described above.

p-0088If the access method is not a composed access method, processing proceeds from step <b>512</b> to step <b>518</b>. Step <b>518</b> is representative of any other access methods types contemplated as embodiments of the present invention. However, it should be understood that embodiments are contemplated in which less than all the available access methods are implemented. For example, in a particular embodiment only simple access methods are used. In another embodiment, only simple access methods and filtered access methods are used.

Natural Language Support in Creation of Abstract Queries

p-0089Referring now to <figref idrefs="DRAWINGS">FIG. 6</figref>, a relational view illustrating natural language support for a data abstraction model in accordance with an associated language resource component in one embodiment is shown. More specifically, <figref idrefs="DRAWINGS">FIG. 6</figref> shows a data abstraction model “ABC-DAM” <b>610</b> (e.g., data abstraction model <b>124</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) and two different views of the data abstraction model <b>610</b>. In general, a view of the data abstraction model <b>610</b> defines how the data abstraction model <b>610</b> is presented to a user. For example, the view may reflect group security settings for a specific group of users. Accordingly, using different views of the data abstraction model <b>610</b> according to group security settings, users can be authorized to access information in the data abstraction model <b>610</b> based on a corresponding security level assigned to their respective user group. For simplicity, only two views are shown, i.e., a “RESEARCH-VIEW” <b>630</b> and a “SOCIAL-VIEW” <b>640</b>. By way of example, the “RESEARCH-VIEW” <b>630</b> defines a view of the data abstraction model <b>610</b> for users in a research group and the “SOCIAL-VIEW” <b>640</b> defines a view for users in a social service group.

p-0090Illustratively, the data abstraction model <b>610</b> is associated with a language resource component “ABC-XLIFF” <b>620</b>. The views <b>630</b> and <b>640</b> are associated with language resource components “RESEARCH-XLIFF” <b>635</b> and “SOCIAL-XLIFF” <b>645</b>, respectively. In one embodiment, the language resource components <b>620</b>, <b>635</b> and <b>645</b> are XLIFF resources. XLIFF (XML Localization Interchange File Format) is an XML based open format designed to capture localizable information (i.e., resources) and to operate with translation tools. Accordingly, the language resource components <b>620</b>, <b>635</b> and <b>645</b> can be implemented by XLIFF language resource files (referred to herein as language resource files).

p-0091In one embodiment, the language resource file <b>620</b> is a default language resource file that includes default natural language expressions for each logical field defined by the data abstraction model <b>610</b>. In other words, the default language resource file includes all natural language expressions as defined in the data abstraction model <b>610</b>. However, it should be noted that provision of the default language resource file is optional. Instead of using the default language resource file, all default natural language expressions can be determined directly from the data abstraction model <b>610</b>. Accordingly, in one embodiment, the language resource file <b>620</b> includes natural language expressions which describe translations of each logical field of the data abstraction model <b>610</b> into another language or a variation on the same language.

p-0092The language resource files <b>635</b> and <b>645</b> include translations of increasing specificity to replace relatively less specific translations of the language resource file <b>620</b>. Each of the language resource files <b>635</b> and <b>645</b> can be used in combination with the language resource file <b>620</b> to translate natural language expressions in the data abstraction model <b>610</b> according to the views <b>630</b> and <b>640</b>, respectively. Thus, by applying the view <b>630</b> and the language resource file <b>635</b> (in combination with the language resource file <b>620</b>) to the data abstraction model <b>610</b>, an effective data abstraction model “RESEARCH GROUP EFFECTIVE DAM” <b>655</b> can be created for a research group user using the “RESEARCH-VIEW” <b>630</b>. An effective data abstraction model is an in-memory representation of a default data abstraction model (e. g., “ABC-DAM” <b>610</b>) as modified by applying a view thereto and/or by aggregating multiple data abstraction models into a single larger data abstraction model. The effective data abstraction model <b>655</b> can be displayed in a user interface <b>650</b>. Thus, the user interface <b>650</b> is displayed in accordance with the natural language expressions defined by the language resource files <b>620</b> and <b>635</b>. Accordingly, for a social service group user using the “SOCIAL-VIEW” <b>640</b>, an effective data abstraction model “SOCIAL SERVICE GROUP EFFECTIVE DAM” <b>665</b> can be created and displayed in a user interface <b>660</b>. Thus, the user interface <b>660</b> is displayed in accordance with the natural language expressions defined by the language resource files <b>620</b> and <b>645</b>. The data abstraction model <b>610</b>, the views <b>630</b> and <b>640</b>, the associated language resource files <b>620</b>, <b>635</b> and <b>645</b>, the effective data abstraction models <b>655</b> and <b>665</b> and the user interfaces <b>650</b> and <b>660</b> are explained in more detail below with respect to Tables III-X.

p-0093As an example of the data abstraction model “ABC-DAM” <b>610</b>, the exemplary data abstraction model “ABC-DAM.xml” shown in Table III below is illustrated. For simplicity, elements of the “ABC-DAM.xml” data abstraction model are represented in a shorthand format. Persons skilled in the art will readily recognize corresponding XML representations. Further, for brevity, only parts that are relevant for the following explanations are shown. It is noted that this manner of presentation applies to other tables described below as well.

p-0094<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE III</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>DATA ABSTRACTION MODEL EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>001  ABC-DAM.xml</entry></row><row><entry /><entry>002   +---> Demographic: Patient demographic information</entry></row><row><entry /><entry>003    +--> Gender</entry></row><row><entry /><entry>004       +-->Value: = ”Female”</entry></row><row><entry /><entry>005       +-->Value: = ”Male”</entry></row><row><entry /><entry>006       +-->Value: = “Unknown”</entry></row><row><entry /><entry>007     +--> Name</entry></row><row><entry /><entry>008     +--> SSN: This is the patient's social security number</entry></row><row><entry /><entry>009   +---> Diagnosis: Patient diagnostic information</entry></row><row><entry /><entry>010    +--> Disease</entry></row><row><entry /><entry>011       +--> Name</entry></row><row><entry /><entry>012  +--->Language Resource</entry></row><row><entry /><entry>013    +--> ABC-XLIFF.xml</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0095As can be seen from lines 002 and 009, the exemplary data abstraction model includes two categories, i.e., “Demographic” and “Diagnosis”. By way of example, the “Demographic” category includes definitions for a “Gender” (lines 003-006), “Name” (line 007) and “SSN” (line 008) logical field. Assume now that the “Gender” field refers to a “gender” column in a table of an underlying database (e.g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>). Furthermore, as can be seen from lines 004-006 of Table III, the definition of the “Gender” field includes a list of allowed physical values in a default language, here English. More specifically, the allowed physical values for the “Gender” field are defined by default language expressions “Female”, “Male” and “Unknown”. It should further be noted that the “Diagnosis” category also includes a “Name” field (line 011). Furthermore, as can be seen from line 013, the exemplary data abstraction model of Table III is associated with the language resource file “ABC-XLIFF.xml”. An exemplary language resource file exemplifying the language resource file “ABC-XLIFF” <b>620</b> is shown in Table IV below.

p-0096<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE IV</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ABC-XLIFF FILE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>001  ABC-XLIFF.xml</entry></row><row><entry>002   “Demographic.Gender:name” = “Gender”</entry></row><row><entry>003   “Demographic.Gender:val-Female” = “Female”</entry></row><row><entry>004   “Demographic.Gender:val-Male” = “Male”</entry></row><row><entry>005   “Demographic.Gender:val-Unknown” = “Unknown”</entry></row><row><entry>006   “Demographic.Name:name” = “Name”</entry></row><row><entry>007   “Demographic.SSN:description” = “This is the patient's social</entry></row><row><entry>     security number”</entry></row><row><entry>008   “Demographic.SSN:name” = “SSN”</entry></row><row><entry>009   “Demographic:description” = “Patient demographic information”</entry></row><row><entry>010   “Demographic:name” = “Demographic”</entry></row><row><entry>011   “Diagnosis.Disease.Name:name” = “Name”</entry></row><row><entry>012   “Diagnosis.Disease:name” = “Disease”</entry></row><row><entry>013   “Diagnosis:description” = “Patient diagnostic information”</entry></row><row><entry>014   “Diagnosis:name” = “Diagnosis”</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0097The exemplary XLIFF language resource file of Table IV illustratively includes default natural language expressions for each attribute included in a logical field of the exemplary data abstraction model of Table Ill. More specifically, the exemplary XLIFF language resource file includes, on the left hand side of each line, a definition for an element (e.g., a logical field name or value) of the data abstraction model and, on the right hand side of each line, an associated value. In other words, the XLIFF language resource file of Table IV includes definition/value mappings for the data abstraction model of Table III. However, as already mentioned above, it should be noted that all information included in the exemplary default language resource file of Table IV is included in and can, thus, be retrieved from, the exemplary data abstraction model of Table III.

p-0098As an example of the “RESEARCH-VIEW” <b>630</b>, an exemplary view of the data abstraction model of Table III for users of a research group is shown in Table V below. Further, for brevity, only parts that are relevant for the following explanations are shown.

p-0099<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE V</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>RESEARCH-VIEW EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>001  RESEARCH-VIEW.xml</entry></row><row><entry /><entry>002   +---> Exclude</entry></row><row><entry /><entry>003        +--> Field: SSN</entry></row><row><entry /><entry>004  +---> Language Resource</entry></row><row><entry /><entry>005    +--> RESEARCH-XLIFF.xml</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0100By way of example, it is assumed that researchers should be prevented from seeing Social Security numbers (SSN) for security reasons. Accordingly, as can be seen from line 002, the view of Table V includes an “Exclude” attribute to exclude the logical field “SSN” (line 003) from the presentation of the data abstraction model <b>610</b> for display. In other words, the exemplary RESEARCH-VIEW is configured to implement group security settings for users of the RESEARCH group. Furthermore, as can be seen from line 005, the exemplary view of Table V is associated with the language resource file “RESEARCH-XLIFF.xml”. An exemplary language resource file exemplifying the language resource file “RESEARCH-XLIFF” <b>635</b> is shown in Table VI below.

p-0101<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE VI</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>RESEARCH-XLIFF FILE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>001  RESEARCH-XLIFF.xml</entry></row><row><entry /><entry>002   “Demographic.Name:name” = “Subject name”</entry></row><row><entry /><entry>003   “Demographic:description” = “Demographic”</entry></row><row><entry /><entry>004   “Diagnosis.Disease.Name:name” = “Syndrome name”</entry></row><row><entry /><entry>005   “Diagnosis:description” = “Diagnostic information”</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0102As can be seen from lines 002-005, natural language expressions for different definitions of the data abstraction model of Table III are provided, which replace corresponding natural language expressions of the language resource file of Table IV. In other words, it is assumed that researchers would prefer to view the data abstraction model of Table III according to a more technical terminology. Therefore, the natural language expressions shown in Table VI are intended to change the corresponding natural language expressions of Table IV according to a more technical terminology.

p-0103By applying the view of Table V and the language resource file of Table VI (in combination with the language resource file of Table IV) to the data abstraction model of Table III, an effective data abstraction model as illustrated in Table VII below can be generated for users of the research group and displayed in the user interface <b>650</b>. The exemplary effective data abstraction model illustrated in Table VII is an example for the effective data abstraction model <b>655</b>. For simplicity, only relevant displayed information is illustrated in Table VII.

p-0104<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE VII</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>RESEARCH GROUP EFFECTIVE DAM EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>001  +---> Demographic: Demographic</entry></row><row><entry /><entry>002   +--> Gender</entry></row><row><entry /><entry>003      +-->Value: = ”Female”</entry></row><row><entry /><entry>004      +-->Value: = ”Male”</entry></row><row><entry /><entry>005      +-->Value: = ”Unknown”</entry></row><row><entry /><entry>006    +--> Subject name</entry></row><row><entry /><entry>007  +---> Diagnosis: Diagnostic information</entry></row><row><entry /><entry>008   +--> Disease</entry></row><row><entry /><entry>009      +--> Syndrome name</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0105As can be seen from Table VII, the SSN information of the data abstraction model of Table III has been excluded from display. Furthermore, lines 001, 006, 007 and 009 are displayed according to the natural language expressions of the language resource file of Table VI.

p-0106As an example of the “SOCIAL-VIEW” <b>640</b>, an exemplary view of the data abstraction model of Table III for users of a social service group is shown in Table VIII below. Further, for brevity, only parts that are relevant for the following explanations are shown.

p-0107<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE VIII</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>SOCIAL-VIEW EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>001  SOCIAL-VIEW.xml</entry></row><row><entry /><entry>002   +---> IncludeAll</entry></row><row><entry /><entry>003   +---> Language Resource</entry></row><row><entry /><entry>004    +--> SOCIAL-XLIFF.xml</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0108By way of example, it is assumed that social service group users would need to access all information included in the “ABC-DAM” <b>610</b>. Accordingly, as can be seen from line 002, the view of Table VIII includes an “IncludeAll” attribute to include all logical fields of the data abstraction model <b>610</b> for display. Furthermore, as can be seen from line 004, the exemplary view of Table VIII is associated with the language resource file “SOCIAL-XLIFF.xml”. An exemplary language resource file exemplifying the language resource file “SOCIAL-XLIFF” <b>645</b> is shown in Table IX below.

p-0109<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE IX</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>SOCIAL-XLIFF FILE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>001  SOCIAL-XLIFF.xml</entry></row><row><entry /><entry>002   “Demographic.Gender:val-Female” = “Girl”</entry></row><row><entry /><entry>003   “Demographic.Gender:val-Male” = “Boy”</entry></row><row><entry /><entry>004   “Demographic.Gender:val-Unknown” = “Unlisted”</entry></row><row><entry /><entry>005   “Demographic.Name:name” = “Patient name”</entry></row><row><entry /><entry>006   “Diagnosis.Disease.Name:name” = “Sickness name”</entry></row><row><entry /><entry>007   “Diagnosis:name” = “Likely Illness”</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0110As can be seen from lines 002-007, natural language expressions for different definitions of the data abstraction model of Table III are provided, which replace corresponding natural language expressions of the language resource file of Table IV. More specifically, it is assumed that social service group users would need to view the data abstraction model of Table III according to a less technical terminology. Therefore, the natural language expressions shown in Table IX are intended to change the corresponding natural language expressions of Table IV accordingly.

p-0111According to the view of Table VIII and the language resource file of Table IX (in combination with the language resource file of Table IV), the effective data abstraction model of Table X below can be generated for users of the social service group and displayed in the user interface <b>660</b>. The exemplary data abstraction model of Table X is an example for the effective data abstraction model <b>665</b>. For simplicity, only relevant displayed information is illustrated in Table X.

p-0112<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE X</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>SOCIAL SERVICE GROUP EFFECTIVE DAM EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>001  +---> Demographic: Patient demographic information</entry></row><row><entry /><entry>002   +--> Gender</entry></row><row><entry /><entry>003      +-->Value: = ”Girl”</entry></row><row><entry /><entry>004      +-->Value: = ”Boy”</entry></row><row><entry /><entry>005      +-->Value: = ”Unlisted”</entry></row><row><entry /><entry>006    +--> Patient name</entry></row><row><entry /><entry>007    +--> SSN: This is the patient's social security number</entry></row><row><entry /><entry>008  +---> Likely illness: Patient diagnostic information</entry></row><row><entry /><entry>009   +--> Disease</entry></row><row><entry /><entry>010      +--> Sickness name</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0113As can be seen from Table X, all information of the data abstraction model of Table III has been included for display. Furthermore, lines 003-006, 008 and 010 are displayed according to the natural language expressions of the language resource file of Table IX.

p-0114Referring now to <figref idrefs="DRAWINGS">FIG. 7</figref>, a method <b>700</b> for providing natural language support for users running queries (e.g., abstract query <b>140</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) against a database (e.g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) is illustrated. In one embodiment, the method <b>700</b> is performed by the NLS manager <b>120</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. Method <b>700</b> starts at step <b>710</b>.

p-0115At step <b>720</b>, a data abstraction model (e. g., data abstraction model <b>610</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>) including a plurality of logical fields abstractly describing physical data residing in the database is retrieved. Each logical field includes one or more attributes. For each attribute, a corresponding definition that uniquely identifies the attribute can be determined from the data abstraction model. At step <b>730</b>, each definition in the data abstraction model is determined and, at step <b>740</b>, a corresponding definition/value mapping is generated in a language resource component (e.g., natural language resource component <b>150</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>).

p-0116By way of example, for the attribute “Name” in line 007 of the exemplary “ABC-DAM” of Table III, a definition “Demographic.Name:name” is determined. For the attribute “Name” in line 011, a definition “Diagnosis.Disease.Name:name” is determined. Both definitions are mapped to the natural language expression or value “Name” according to lines 007 and 011 of the exemplary “ABC-DAM” of Table III. Furthermore, both definition/value mappings are generated in the exemplary “ABC-XLIFF” language resource file of Table IV (lines 006 and 011, respectively).

p-0117The method <b>700</b> performs a loop consisting of steps <b>730</b> and <b>740</b> until a corresponding definition/value mapping has been generated in the language resource component for each definition in the data abstraction model. Thus, the language resource component defines a natural language expression for each of the plurality of logical fields. Subsequently, method <b>700</b> proceeds with step <b>750</b>.

p-0118At step <b>750</b>, the data abstraction model is associated with the generated language resource component. For instance, a language resource file definition is included in the data abstraction model, e. g., language resource file definition “ABC-XLIFF.xml” in line 013 of the exemplary “ABC-DAM” of Table III. Method <b>700</b> then exits at step <b>760</b>.

p-0119Referring now to <figref idrefs="DRAWINGS">FIG. 8</figref>, a method <b>800</b> illustrating determination of a language mapping table having suitable natural language expressions to be used for a given user is shown. The mapping table is determined from corresponding language resource components (e. g., language resource components <b>620</b>, <b>635</b> and <b>645</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>). By way of example, the method <b>800</b> is explained with reference to language resource files. In one embodiment, the method <b>800</b> is performed by the NLS manager <b>120</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. Method <b>800</b> starts at step <b>805</b>.

p-0120At step <b>810</b>, an ordered list of the language resource files for a given data abstraction model is determined. Determination of the ordered list is described in more detail below with reference to <figref idrefs="DRAWINGS">FIG. 9</figref>.

p-0121At step <b>820</b>, a determination is made as to whether a corresponding language mapping table for the user already exists. If the corresponding language mapping table already exists, it is assigned to the user in step <b>830</b>. Method <b>800</b> then exits at step <b>875</b>. If the corresponding language mapping table does not exist, processing continues at step <b>840</b>.

p-0122At step <b>840</b>, a user locale is determined. The user locale defines settings concerning, for example, country, language and a language variant used by the user. For instance, the locale may define the user as a researcher of a research group who uses the English language in the United States. In one embodiment, the locale is determined according to user input including suitable parameters for determination of all required language resource files using a user interface. In another embodiment, the locale is determined according to local user settings on his/her workstation.

p-0123At step <b>850</b>, all required language resource files are determined for the user based on the determined user locale. For purposes of illustration, it will be assumed that the language resource files of Tables IV and VI are determined for the researcher.

p-0124At step <b>860</b>, using the determined language resource files, a language mapping table is generated for the user. To this end, in one embodiment all definition/value mappings of the least specific language resource file are included in the language mapping table. For instance, all definition/value mappings of the language resource file of Table IV are initially included in the language mapping table. Subsequently, definition/value mappings of more specific language resource files are used to replace the less specific definition/value mappings of less specific language resource files. This process is performed until all definition/value mappings in the most specific language resource file have been processed. For instance, in the given example, the less specific definition/value mappings from the language resource file of Table IV are replaced by more specific definition/value mappings of the language resource file of Table VI. Accordingly, for the researcher of the research group, the exemplary language mapping table according to Table XI below can be generated.

p-0125<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XI</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MAPPING TABLE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>001  RESEARCH-MAPPING.xml</entry></row><row><entry /><entry>002   “Demographic.Gender:name” = “Gender”</entry></row><row><entry /><entry>003   “Demographic.Gender:val-Female” = “Female”</entry></row><row><entry /><entry>004   “Demographic.Gender:val-Male” = “Male”</entry></row><row><entry /><entry>005   “Demographic.Gender:val-Unknown” = “Unknown”</entry></row><row><entry /><entry>006   “Demographic.Name:name” = “Subject name”</entry></row><row><entry /><entry>007   “Demographic.SSN:description” = “This is the</entry></row><row><entry /><entry>     patient's social security number”</entry></row><row><entry /><entry>008   “Demographic.SSN:name” = “SSN”</entry></row><row><entry /><entry>009   “Demographic:description” = “Demographic”</entry></row><row><entry /><entry>010   “Demographic:name” = “Demographic”</entry></row><row><entry /><entry>011   “Diagnosis.Disease.Name:name” = “Syndrome name”</entry></row><row><entry /><entry>012   “Diagnosis.Disease:name” = “Disease”</entry></row><row><entry /><entry>013   “Diagnosis:description” = “Diagnostic information”</entry></row><row><entry /><entry>014   “Diagnosis:name” = “Diagnosis”</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0126As can be seen from Table XI, the exemplary language mapping table represents a combination of the language resource files of Tables IV and VI. The loading and processing of language resource files using locales for file or resource names for generation of a language mapping table is well-known in the art (e.g., by a Java® language runtime implementation of resource bundles) and will, therefore, not be described in more detail.

p-0127At step <b>870</b>, the generated language mapping table is persistently stored in memory for use by all users having the same user locale. For instance, the language mapping table of Table XI is persistently stored for all users of the research group. Thus, each time a research group user loads the effective data abstraction model of the research group, the language mapping table can be used for translation purposes. Processing then continues at step <b>830</b> as described above.

p-0128Referring now to <figref idrefs="DRAWINGS">FIG. 9</figref>, a method <b>900</b> illustrating the determination of the ordered list of the language resource files for a given data abstraction model (e. g., data abstraction model <b>610</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>) according to step <b>810</b> of <figref idrefs="DRAWINGS">FIG. 8</figref> is shown. In one embodiment, the ordered list is determined for all users of a given group having common group security settings. Method <b>900</b> starts at step <b>910</b>.

p-0129At step <b>910</b>, a language resource file definition is determined from the data abstraction model. For instance, the language resource file definition “ABC-XLIFF.xml” can be determined from the exemplary data abstraction model of Table III (line 013). At step <b>920</b>, the determined language resource file definition is added on top of the ordered list of language resource files. At step <b>930</b>, it is determined whether other data abstraction models exist. If one or more other data abstraction models exist, a next data abstraction model is selected and processing returns to step <b>910</b>. Accordingly, steps <b>910</b> to <b>930</b> form a loop which is executed until all data abstraction models have been processed. By way of example, assume that another data abstraction model “DEF-DAM” having a language resource file definition “DEF-XLIFF.xml” exists. Accordingly, the language resource file definition “DEF-XLIFF.xml” is placed on top of the ordered list before the language resource file definition “ABC-XLIFF.xml”. When it is determined, at step <b>930</b>, that no more data abstraction models exist, processing continues at step <b>940</b>.

p-0130At step <b>940</b>, it is determined whether one or more views on one or more data abstraction models, which have been processed in the loop formed of steps <b>910</b> to <b>930</b>, exist. If no view exists, processing continues at step <b>820</b> of <figref idrefs="DRAWINGS">FIG. 8</figref>. If, however, one or more views exist, a language resource file definition from a first view is determined at step <b>950</b>. For instance, the language resource file definition “RESEARCH-XLIFF.xml” can be determined from the exemplary view of Table V (line 005). At step <b>960</b>, the determined language resource file definition is added at the end of the ordered list. At step <b>970</b>, it is determined whether other views exist. If one or more other views exist, a next view is selected and processing returns to step <b>950</b>. Accordingly, steps <b>950</b> to <b>970</b> form a loop which is executed until all views have been processed.

p-0131In one embodiment, step <b>970</b> includes determining whether other views exist for a given group of users. For instance, it is determined whether other views exist for the research group users. In the given example no additional views for research group users can be determined, but a view for social service group users can be determined. By way of example, the “SOCIAL-VIEW” of Table VIII includes the language resource file definition “SOCIAL-XLIFF.xml” (line 004). However, in the given example it is assumed that the views of the research group and the social service group have different group security settings and are mutually exclusive. Therefore, the language resource file definition “SOCIAL-XLIFF.xml” is not processed. However, if the views of the research group and the social service group had been construed with common group security settings, the language resource file definition “SOCIAL-XLIFF.xml” would have been placed at the end of the ordered list behind the language resource file definition “RESEARCH-XLIFF.xml”. When it is determined, at step <b>970</b>, that no more views exist, processing continues at step <b>820</b> of <figref idrefs="DRAWINGS">FIG. 8</figref>.

p-0132In one embodiment, the loop formed of steps <b>950</b> to <b>970</b> is performed for views of different specificity levels. In other words, after processing a first view at a lowest specificity level, views of higher specificity levels up to views having the highest specificity level can be processed before a next view at the lowest specificity level is processed. It should be noted that identical processing can be performed for the data abstraction models by the loop formed of steps <b>910</b> to <b>930</b>.

p-0133For instance, assume that a view for a Russian research group having a language resource file definition “RESEARCH-XLIFF_RU.xml” exists. Assume further that a view for a Russian research group of a region BB exists, which requires a more specific terminology and which has a language resource file definition “RESEARCH-XLIFF_RU_BB.xml”. Accordingly, the language resource file definition “RESEARCH-XLIFF_RU.xml” would be processed after the language resource file definition “RESEARCH-XLIFF.xml”, and the language resource file definition “RESEARCH-XLIFF_RU_BB.xml” would be processed at the end. Accordingly, the language resource file definition “RESEARCH-XLIFF_RU_BB.xml” would be placed at the end of the ordered list. The following Table XII exemplifies an ordered list according to the above example.

p-0134<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XII</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ORDERED LIST EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>001  DEF-XLIFF.xml</entry></row><row><entry /><entry>002  DEF-XLIFF_RU.xml</entry></row><row><entry /><entry>003  DEF-XLIFF_RU_BB.xml</entry></row><row><entry /><entry>004    ABC-XLIFF.xml</entry></row><row><entry /><entry>005    ABC-XLIFF_RU.xml</entry></row><row><entry /><entry>006    ABC-XLIFF_RU_BB.xml</entry></row><row><entry /><entry>007    RESEARCH-XLIFF.xml</entry></row><row><entry /><entry>008    RESEARCH-XLIFF_RU.xml</entry></row><row><entry /><entry>009    RESEARCH-XLIFF_RU_BB.xml</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0135It should be noted that Table XII includes language resource file definitions for the data abstraction models “DEF-DAM” (lines 001-003) and “ABC-DAM” (lines 004-006) with specificity levels that correspond to the specificity levels of the “RESEARCH-VIEW” of Table V as explained above. In other words, it is assumed that a general Russian translation (lines 002 and 005) and a more specific Russian translation for a region BB (lines 003 and 006) are also provided for each of the data abstraction models “DEF-DAM” and “ABC-DAM”.

p-0136Referring now to <figref idrefs="DRAWINGS">FIG. 10</figref>, one embodiment of a method <b>1000</b> of providing natural language support for users running queries (e.g., abstract query <b>140</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) against a database (e.g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) is illustrated. At least a portion of the steps of method <b>1000</b> can be performed by the NLS manager <b>120</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. Method <b>1000</b> starts at step <b>1010</b>.

p-0137At step <b>1020</b>, an abstract query (e. g., abstract query <b>140</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) including one or more logical fields, each corresponding to a logical field specification of a data abstraction model (e. g., data abstraction model <b>124</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> or data abstraction model <b>610</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>) abstractly describing physical data residing in a database (e. g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) is retrieved. At step <b>1030</b>, the data abstraction model is determined. This determination can be performed by a database application (e. g., application <b>190</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) that is configured to access the data abstraction model and has corresponding knowledge of which data abstraction model(s) to use. Furthermore, based on security settings for users and user and group information for a corresponding user, applicable views can be determined by the application. At step <b>1040</b>, it is determined, from the data abstraction model, whether an associated language resource component (e. g., language resource file <b>620</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>) exists. If no associated language resource component exists, the method <b>1000</b> exits at step <b>1090</b>. If, however, an associated language resource component exists, processing continues at step <b>1050</b>.

p-0138At step <b>1050</b>, a corresponding language mapping table is determined for the user. Determination of the language mapping table is performed, in one embodiment, according to the method <b>800</b> of <figref idrefs="DRAWINGS">FIG. 8</figref>. The method <b>1000</b> then enters a loop consisting of steps <b>1060</b> and <b>1070</b>. The loop is performed for each attribute of each logical field of the abstract query to determine a natural language expression for the logical field(s) of the abstract query. More specifically, for each attribute of each logical field, a corresponding definition is determined at step <b>1060</b>. Then, at step <b>1070</b>, a corresponding definition/value mapping is looked up in the language mapping table. When all attributes have been processed, processing continues at step <b>1080</b>.

p-0139At step <b>1080</b>, the abstract query is displayed in the determined natural language expression. More specifically, each attribute in the abstract query is replaced by a determined value from a corresponding definition/value mapping from the language mapping table for display. Method <b>1000</b> then exits at step <b>1090</b>.

Natural Language Support with Respect to Foreign Languages

p-0140Referring now to <figref idrefs="DRAWINGS">FIG. 11</figref>, an exemplary screenshot <b>1200</b> illustrating a graphical user interface (GUI) screen <b>1100</b> displayed by a suitable user interface (e.g., user interface <b>160</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) for query creation is shown. Illustratively, the GUI screen <b>1100</b> displays a panel <b>1110</b> for creation of an abstract query (e.g., abstract query <b>140</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) against an underlying database (e.g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>).

p-0141As was noted above, in one embodiment a language resource component (e.g., language resource component <b>150</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) for a given data abstraction model (e.g., data abstraction model <b>124</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) can be defined by a language resource file. The language resource file may include default natural language expressions for use in representing attributes of the data abstraction model to the user. In one embodiment, the default natural language expressions can be translated into any foreign languages or variants on a same language such as alternative terminology required by users or groups of users that access the data abstraction model. Furthermore, in one embodiment a given language resource component can be used to translate basic constructs of the underlying database and corresponding user interfaces that are suitable for query creation into a given foreign language, not just user application data. For example, field names used for comparison, comparison operators or database attributes can be automatically translated into the foreign language.

p-0142In one embodiment, a suitable language resource file(s) that is used to translate the data abstraction model or a given view is retrieved at startup/load time. At user login time, user-specific settings for the user are retrieved, such as from a user locale, and which translated resources are used for representing the data abstraction model is determined.

p-0143For instance, assume that an underlying user locale defines that a given user of the underlying database uses the Spanish language in the United States. Assume further that a given language resource component is configured to translate all basic constructs of the underlying database and corresponding user interfaces for query creation into the Spanish language. Furthermore, a suitable language resource file translates all attributes of an underlying data abstraction model into the Spanish language. By way of example, assume that the underlying data abstraction model is the exemplary data abstraction model of Table III above. Accordingly, all information shown in the panel <b>1110</b> is displayed in the Spanish language.

p-0144It should be noted that the panel <b>1110</b> illustratively includes a display area <b>1120</b> that is configured for specification of a query condition for the abstract query. By way of example, the display area <b>1120</b> is used to specify a query condition on the “Gender” field of the underlying data abstraction model. Assume now that a translation in the Spanish language is retrieved for all attributes of all logical fields of the exemplary data abstraction model of Table III above in the exemplary language resource file “SPANISH-XLIFF.xml” shown in Table XII below. For simplicity, elements of the “SPANISH-XLIFF.xml” language resource file are represented in a shorthand format. Persons skilled in the art will readily recognize corresponding XML representations. Further, for brevity, only parts that are relevant for the following explanations are shown, i.e., parts relating to the “Gender” field of the exemplary data abstraction model of Table III above.

p-0145<tables id="TABLE-US-00013" num="00013"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XIII</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>SPANISH-XLIFF FILE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>001  SPANISH-XLIFF.xml</entry></row><row><entry /><entry>002   “Demographic.Gender:name” = “Género”</entry></row><row><entry /><entry>003   “Demographic.Gender:val-Female” = “Hembra”</entry></row><row><entry /><entry>004   “Demographic.Gender:val-Male” = “Varón”</entry></row><row><entry /><entry>005   “Demographic.Gender:val-Unknown” = “Desconocido”</entry></row><row><entry /><entry>006   “Demographic.Name:name” = “Apellido”</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0146The exemplary XLIFF language resource file of Table XIII illustratively includes Spanish expressions for each attribute included in the “Gender” field and the “Name” field of the exemplary data abstraction model of Table III. More specifically, the exemplary XLIFF language resource file includes in lines 002-005, on the left hand side of each line, a definition for an element (e.g., a logical field name or value) of the “Gender” field and, on the right hand side of each line, an associated Spanish expression. Similarly, in line 006 a definition for the logical field name of the “Name” field is associated with a corresponding Spanish expression.

p-0147In the given example, using the exemplary “SPANISH-XLIFF.xml” file of Table XIII, the display area <b>1120</b> displays an indication <b>1130</b> of the logical field name “Gender” (line 003 of Table III) using the Spanish expression “Género” (line 002 of Table XIII). Furthermore, indications of all alternative values associated with allowed physical values for the “Gender” field according to lines 004-006 of Table III are displayed in the display area <b>1120</b>. Accordingly, an indication <b>1140</b> of the value “Female” (line 004 of Table III) using the Spanish expression “Hembra” (line 003 of Table XIII), an indication <b>1150</b> of the value “Male” (line 005 of Table III) using the Spanish expression “Varón” (line 004 of Table XIII) and an indication <b>1160</b> of the value “Unknown” (line 006 of Table III) using the Spanish expression “Desconocido” (line 005of Table XIII) are displayed.

p-0148In the display area <b>1120</b>, the indications <b>1140</b>, <b>1150</b> and <b>1160</b> are each associated with a corresponding user-selectable checkbox <b>1145</b>, <b>1155</b> and <b>1165</b>. Illustratively, the checkbox <b>1155</b> associated with the indication <b>1150</b> “Varón” is selected. Furthermore, a comparison operator “=iguales” is selected from a list <b>1170</b> of user-selectable operators for definition of the query condition. By activating a pushbutton <b>1180</b> “Actualización”, the user requests creation of the query condition.

p-0149Referring now to <figref idrefs="DRAWINGS">FIG. 12</figref>, the GUI screen <b>1100</b> of <figref idrefs="DRAWINGS">FIG. 11</figref> is shown after user-activation of the pus<b>0</b>hbutton <b>1180</b> “Actualización”. Accordingly, the query condition is created and a summary <b>1210</b> thereof is shown in a display area <b>1220</b> of the panel <b>1110</b>.

p-0150After specification of all query conditions and selection of required result fields, creation of the abstract query is completed. Assume now that the illustrative abstract query shown in Table XIV below is created using the GUI screen <b>1100</b> of <figref idrefs="DRAWINGS">FIGS. 11-12</figref>. By way of illustration, the illustrative abstract query is defined using XML. However, any other language may be used to advantage.

p-0151<tables id="TABLE-US-00014" num="00014"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XIV</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ABSTRACT QUERY EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>001   </entry></row><row><entry /><entry>002   <QueryAbstraction></entry></row><row><entry /><entry>003    <Selection></entry></row><row><entry /><entry>004     <Condition relOperator=“AND” fieldType=“char”</entry></row><row><entry /><entry>005        field=“Gender” operator=“EQ”> <Value</entry></row><row><entry /><entry>          val=“Male”/></entry></row><row><entry /><entry>006       </Condition></entry></row><row><entry /><entry>007    </Selection></entry></row><row><entry /><entry>008    <Results></entry></row><row><entry /><entry>009      <Field name=“Name”/></entry></row><row><entry /><entry>010      <Field name=“Gender”/></entry></row><row><entry /><entry>011    </Results></entry></row><row><entry /><entry>012   </QueryAbstraction></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0152Illustratively, the abstract query shown in Table XIV includes in lines 003-007 a selection specification containing the query condition that was created using the exemplary GUI screen <b>1100</b> of <figref idrefs="DRAWINGS">FIGS. 11-12</figref> and in lines 00-011a results specification. By way of example, the results specification in lines 00-011requests name and gender information for patients in a hospital and refers to the “Name” field (line 007of Table III) and the “Gender” field (line 003of Table III) of the exemplary data abstraction model of Table III above.

p-0153It should be noted that all attributes in the exemplary abstract query of Table XIV are defined in the English language, i.e., the default language of the data abstraction model, although the abstract query shown in Table XIV was created using the GUI screen <b>1100</b> of <figref idrefs="DRAWINGS">FIGS. 11-12</figref> that uses the Spanish language. In fact, in one embodiment abstract queries are only generated in the default language that is defined by the underlying data abstraction model to allow transformation of the abstract query into an executable query using the data abstraction model. As the default language of the exemplary data abstraction model of Table III is English, the exemplary abstract query of Table XIV is generated in English. This allows normalization of generated abstract queries and further allows database administrators, security officers and suitable security monitoring equipment to monitor the generated abstract queries regarding data security.

p-0154If the exemplary abstract query of Table XIV is transformed into an executable query that is executed against an underlying database (e.g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>), corresponding physical values are retrieved from the database. In one embodiment, where the underlying database is a multilingual database, the retrieved physical values are defined in different natural languages (e.g., English, Spanish and/or German). In order to output a corresponding result set on the basis of the retrieved physical values in a selected language (e.g., natural language result set <b>172</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) such as the language of the user (i.e., in the given example Spanish), further processing is required as described by way of example below with reference to <figref idrefs="DRAWINGS">FIGS. 13-15</figref>.

Natural Language Support for Multilingual Databases

p-0155Referring now to <figref idrefs="DRAWINGS">FIG. 13</figref>, one embodiment of a method <b>1300</b> for generating translation mapping tables (e.g., translation mapping tables <b>154</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) and translation functions (e.g., translation functions <b>152</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) for natural language support in multilingual databases is illustrated. The translation mapping tables and translation functions are generated for logical fields (e.g., logical fields <b>308</b> of <figref idrefs="DRAWINGS">FIGS. 3B-C</figref>) of one or more underlying data abstraction models (e.g., data abstraction model <b>124</b> of <figref idrefs="DRAWINGS">FIGS. 3B-C</figref>). The underlying data abstraction model(s) abstractly describes physical data (e.g., data <b>132</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) stored in one or more associated multilingual databases (e.g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>). In one embodiment, the method <b>1300</b> is performed by the NLS manager <b>120</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0156Method <b>1300</b> starts at step <b>1310</b>. At step <b>1320</b>, the underlying data abstraction model(s) which provides definitions for a plurality of logical fields is retrieved. For instance, assume that the exemplary data abstraction model of Table II is retrieved. As was noted above, the exemplary data abstraction model of Table II includes a plurality of logical fields including, besides others, a “MaritalStatus” (lines 033-044 of Table II) and a “Gender” (lines 045-055 of Table II) field.

p-0157At step <b>1330</b>, at least one logical field having associated translation information is identified from the underlying data abstraction model(s). In one embodiment, the at least one logical field is identified on the basis of an attribute included with the definition of the logical field that is configured to indicate that the logical field has associated translation information. For instance, as noted above the at least one logical field may include a “multilingual” attribute that is set to “Yes”. However, it should be noted that other implementations are possible. By way of example, metadata that is associated with the underlying data abstraction model(s) may indicate logical fields having associated translation information. In this case, the at least one logical field can be identified on the basis of the associated metadata. Accordingly, all such implementations are broadly contemplated.

p-0158In the given example, the “Gender” (lines 045-055 of Table II) field of the exemplary data abstraction model of Table II is identified at step <b>1330</b>. As noted above, the “Gender” field includes a “multilingual” attribute (“multilingual=“Yes”) according to line 046 of Table II.

p-0159At step <b>1335</b>, the associated translation information is retrieved. In one embodiment, retrieving the associated translation information includes retrieving one or more natural language resource components (e.g., language resource component <b>150</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) having the associated translation information. For instance, the associated translation information can be included with corresponding XLIFF language resource files as described above. In one embodiment, the associated translation information of the at least one logical field is identified on the basis of an attribute included with the definition of the logical field. For instance, the at least one logical field may include an attribute indicating a location of the associated translation information in an underlying computer system (e.g., computer system <b>110</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>). However, it should be noted that other implementations are possible. By way of example, metadata that is associated with the underlying data abstraction model(s) may indicate the location of the associated translation information. In this case, the associated translation information of at least one logical field can be identified on the basis of the associated metadata. Accordingly, all such implementations are broadly contemplated. Processing then proceeds with step <b>1350</b>.

p-0160In one embodiment, a separate XLIFF language resource file is provided with respect to each natural language that is used to define physical values in the underlying multilingual database. Furthermore, a given XLIFF language resource file may include translation information for a plurality of logical fields. The translation information that is associated with a given logical field can be identified from a corresponding XLIFF language resource file using one or more suitable attributes of the given field, such as the field name. In one embodiment, each XLIFF language resource file includes a translated value for each allowable value defined for each of the plurality of logical fields by the underlying data abstraction model(s) and/or each physical value included with the underlying multilingual database that is associated with one of the plurality of logical fields. All such implementations are broadly contemplated.

p-0161Assume that in the given example three XLIFF language resource files each having translation information for the “Gender” field are retrieved. Assume further that the retrieved XLIFF language resource files respectively include English, Spanish and German translations for allowable values of the “Gender” field. An exemplary XLIFF language resource file for the “Gender” field is illustrated by way of example in Table XV below. Assume now that the exemplary language resource file “LanguageConfiguration_es.xml” shown in Table XV below includes the Spanish translation information. For simplicity, elements of the exemplary “LanguageConfiguration_es.xml” language resource file are represented in a shorthand format. Persons skilled in the art will readily recognize corresponding XML representations. Further, for brevity, only parts that are relevant for the following explanations are shown, as explained in more detail below. It is noted that this manner of presentation applies to other tables described below as well.

p-0162<tables id="TABLE-US-00015" num="00015"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XV</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>SPANISH XLIFF FILE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>001  LanguageConfiguration_es.xml</entry></row><row><entry>002   “Birth, Age and Gender.Gender:val-Female” = “Hembra”</entry></row><row><entry>003   “Birth, Age and Gender.Gender:val-Male” = “Varón”</entry></row><row><entry>004   “Birth, Age and Gender.Gender:val-Unknown” = “Desconocido”</entry></row><row><entry>005   “Birth, Age and Gender.MaritalStatus:val-Single” = “Solo”</entry></row><row><entry>006   “Birth, Age and Gender.MaritalStatus:val-Married” = “Casado”</entry></row><row><entry>007   “Birth, Age and Gender.MaritalStatus:val-Divorced” =</entry></row><row><entry>     “Divorciado”</entry></row><row><entry>008   “Birth, Age and Gender.MaritalStatus:val-Widowed” = “Viuda”</entry></row><row><entry>009   “Birth, Age and Gender.MaritalStatus:Unknown” =</entry></row><row><entry>     “Desconocido”</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0163The exemplary XLIFF language resource file of Table XV illustratively includes Spanish expressions for allowable values defined in the “Gender” field of the exemplary data abstraction model of Table II. The exemplary XLIFF language resource file of Table XV further includes Spanish expressions for allowable values defined in the “MaritalStatus” field of the exemplary data abstraction model of Table II. However, in one embodiment the exemplary XLIFF language resource file may include translation information for multiple different logical fields. For instance, translation information for an “Age” field of the underlying data abstraction model(s) that is suitable to translate age classes such as “Child”, “Adolescent”, “Adult” and “Senior” into the Spanish language could be included with the exemplary XLIFF language resource file. All such implementations are broadly contemplated.

p-0164It should be noted that the Spanish translations included with the exemplary XLIFF language resource file of Table XV are provided with respect to default language expressions represented in the English language, such as “Male”, “Female” etc. In one embodiment, these default language expressions are derived from the underlying data abstraction model(s). In other words, as in the given example the default language expressions shown in the exemplary data abstraction model of Table II above are provided in English, the default language expressions in the exemplary XLIFF language resource file are also defined in English. However, the default language expressions used in the underlying data abstraction model(s) may depend on various factors such as the geographic location of a user of the underlying data abstraction model(s). In other words, for a German user residing in Germany, the default language expressions in the underlying data abstraction model(s) can be provided in the German language. Furthermore, the default language expressions used in the XLIFF language resource file may differ from the default language expressions used in the underlying data abstraction model(s). For instance, while the default language expressions can be provided in English as illustrated in the exemplary data abstraction model of Table II above, the default language expressions used in the XLIFF language resource file can be provided in German for a German user residing in Germany. All such implementations are broadly contemplated.

p-0165In the given example, English translation information is included with the exemplary language resource file “LanguageConfiguration_en.xml” shown in Table XVI below. For brevity, the English translation information is also provided with respect to the default language expressions shown in Table XV above which are defined in English.

p-0166<tables id="TABLE-US-00016" num="00016"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XVI</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ENGLISH XLIFF FILE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>001  LanguageConfiguration_en.xml</entry></row><row><entry>002   “Birth, Age and Gender.Gender:val-Female” = “Female”</entry></row><row><entry>003   “Birth, Age and Gender.Gender:val-Male” = “Male”</entry></row><row><entry>004   “Birth, Age and Gender.Gender:val-Unknown” = “Unknown”</entry></row><row><entry>005   “Birth, Age and Gender.MaritalStatus:val-Single” = “Single”</entry></row><row><entry>006   “Birth, Age and Gender.MaritalStatus:val-Married” = “Married”</entry></row><row><entry>007   “Birth, Age and Gender.MaritalStatus:val-Divorced” =</entry></row><row><entry>     “Divorced”</entry></row><row><entry>008   “Birth, Age and Gender.MaritalStatus:val-Widowed” =</entry></row><row><entry>     “Widowed”</entry></row><row><entry>009   “Birth, Age and Gender.MaritalStatus:Unknown” =“ Unknown”</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0167Finally, the German translation information mentioned above is included in the given example with the exemplary language resource file “LanguageConfiguration_de.xml” shown in Table XVII below. For brevity, the German translation information is also provided for the default language expressions defined in the English language as shown in Table XV above.

p-0168<tables id="TABLE-US-00017" num="00017"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XVII</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>GERMAN XLIFF FILE EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="217pt" align="left" /><colspec colname="2" colwidth="0pt" align="left" /><tbody valign="top"><row><entry>001  LanguageConfiguration_de.xml</entry><entry /></row><row><entry>002   “Birth, Age and Gender.Gender:val-Female” = “Weiblich”</entry></row><row><entry>003   “Birth, Age and Gender.Gender:val-Male” = “Männlich”</entry></row><row><entry>004   “Birth, Age and Gender.Gender:val-Unknown” = “Unbekannt”</entry></row><row><entry>005   “Birth, Age and Gender.MaritalStatus:val-Single” = “Ledig”</entry></row><row><entry>006   “Birth, Age and Gender.MaritalStatus:val-Married” =</entry></row><row><entry>     “Verheiratet”</entry></row><row><entry>007   “Birth, Age and Gender.MaritalStatus:val-Divorced” =</entry></row><row><entry>     “Geschieden”</entry></row><row><entry>008   “Birth, Age and Gender.MaritalStatus:val-Widowed” =</entry></row><row><entry>     “Verwitwet”</entry></row><row><entry>009   “Birth, Age and Gender.MaritalStatus:Unknown” =“ Unbekannt”</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0169In one embodiment, step <b>1340</b> is performed instead of steps <b>1330</b> and <b>1335</b>. At step <b>1340</b>, one or more natural language resource components (e.g., natural language resource component <b>150</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) having translation information for one or more identified logical fields of the underlying data abstraction model(s) are retrieved. For instance, all XLIFF language resource files associated with the underlying data abstraction model(s) are retrieved. On the basis of the retrieved natural language resource component(s), the logical fields having associated translation information can be identified. Processing then proceeds with step <b>1350</b>.

p-0170For instance, assume that in the given example the exemplary XLIFF files of Tables XV-XVII are retrieved. On the basis of the exemplary XLIFF files of Tables XV-XVII, it can be determined that the “Gender” field (lines 045-055 of Table II) has associated translation information included with lines 002-004 of Tables XV-XVII. Furthermore, the “MaritalStatus” field (lines 033-044 of Table II) has associated translation information included with lines 005-009 of Tables XV-XVII.

p-0171As noted above, in one embodiment step <b>1340</b> is performed instead of steps <b>1330</b> and <b>1335</b>. In this case, step <b>1340</b> is performed to retrieve translation information for all logical fields of the underlying data abstraction model(s) which have associated translation information. However, step <b>1340</b> can alternatively be performed asynchronously, i.e., in parallel to steps <b>1330</b> and <b>1335</b>. In this case, step <b>1340</b> is performed to retrieve translation information for all logical fields that do not include suitable attributes indicating that the fields have associated translation information. Steps <b>1330</b> and <b>1335</b> are in this embodiment performed to retrieve the logical fields having such attributes, as described above. For instance, as noted above the “MaritalStatus” field (lines 033-044 of the exemplary data abstraction model of Table II) illustratively does not include a “Multilingual” attribute while the “Gender” field does include such an attribute. Accordingly, the “Gender” field is identified using steps <b>1330</b> and <b>1335</b> and the “MaritalStatus” field using step <b>1340</b>, as described above. Still alternatively, step <b>1340</b> can be performed after execution of steps <b>1330</b> and <b>1335</b>. In this case, step <b>1340</b> can be used to confirm whether all logical fields of the underlying data abstraction model(s) that have associated translation information were correctly identified. All such different implementations are broadly contemplated.

p-0172In one embodiment, the XLIFF language resource files are retrieved from storage (e.g., storage <b>138</b> of <figref idrefs="DRAWINGS">FIG. 1</figref>). However, at least a portion of the retrieved XLIFF language resource files can be generated when required, e.g., at startup time of a corresponding database session. For instance, when the user initially opens the GUI screen <b>1100</b> of <figref idrefs="DRAWINGS">FIG. 11</figref> for query creation, a database session is initiated and the at least one portion of the XLIFF language resource files is generated. To this end, the underlying multilingual database is parsed to identify all natural language expressions of physical values included with the multilingual database. For instance, assume that in the given example the underlying multilingual database includes a “contact” table that is abstractly described by the exemplary data abstraction model of Table II. Assume further that the “contact” table has information about patients of hospitals in the United States, Mexico and Germany. An exemplary “contact” table is illustrated in Table XVIII below.

p-0173<tables id="TABLE-US-00018" num="00018"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XVIII</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>CONTACT TABLE EXAMPLE</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="49pt" align="left" /><colspec colname="4" colwidth="49pt" align="left" /><tbody valign="top"><row><entry /><entry>I_name</entry><entry>encoding</entry><entry>gender</entry><entry>m_status</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="49pt" align="left" /><colspec colname="5" colwidth="49pt" align="left" /><tbody valign="top"><row><entry>001</entry><entry /><entry /><entry /><entry /></row><row><entry>002</entry><entry>Miller</entry><entry>en</entry><entry>Male</entry><entry>Married</entry></row><row><entry>003</entry><entry>Péron</entry><entry>es</entry><entry>Hembra</entry><entry>Casado</entry></row><row><entry>004</entry><entry>Schneider</entry><entry>de</entry><entry>Männlich</entry><entry>Verwitwet</entry></row><row><entry>005</entry><entry>Gonzalez</entry><entry>es</entry><entry>Varon</entry><entry>Solo</entry></row><row><entry>006</entry><entry>Meier</entry><entry>de</entry><entry>Weiblich</entry><entry>Ledig</entry></row><row><entry>007</entry><entry>Sanchez</entry><entry>es</entry><entry>Desconocido</entry><entry>Desconocido</entry></row><row><entry>008</entry><entry>Stewart</entry><entry>en</entry><entry>Male</entry><entry>Single</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0174As can be seen from line 001 of Table XVIII, the exemplary “contact” table includes last names (“I_name”), gender (“gender”) and marital status (“m_status”) information of the patients. In lines 002-008 data records related to different patients are illustrated. The exemplary “contact” table further includes an “encoding” column (line 001) that is suitable to identify the hospital where a given patient is treated. Illustratively, the “encoding” column includes the value “en” (lines 002 and 008) for patients of the American hospital, “es” (lines 003, 005 and 007) for patients of the Mexican hospital and “de” (lines 004 and 006) for patients of the German hospital. However, note that the “encoding” column is merely provided for purposes of illustration and not limiting of the invention. Instead, other information such as a source system identifier, a clinic or hospital number and/or a geographic location could be used in real life applications instead of the “encoding” information to indicate where a given data record is coming from. All such different implementations are broadly contemplated.

p-0175Note that the “gender” and “m_status” columns of the exemplary “contact” table of Table XVIII include physical values that are defined in different natural languages. Accordingly, in one embodiment these physical values can be retrieved and included as translated values with corresponding default language expressions into a corresponding XLIFF language resource file. By way of example, the corresponding default language expressions can be retrieved from a list definition of allowable values for an associated logical field in the underlying data abstraction model. For instance, using suitable machine translation services or other translation facilities, it can be determined that the “gender” value “Hembra” in line 003 of Table XVIII is the Spanish translation of the allowable value “Female” of the “Gender” field in line <b>051</b> of Table II. Thus, the data record in line 002 of Table XV can be created. However, other implementations for creation of the XLIFF language resource files are also possible. For instance, only suitable machine translation services can be used to provide a translation for the “Hembra” value in the exemplary XLIFF language resource file. All such different implementations are broadly contemplated.

p-0176At step <b>1350</b>, a loop consisting of steps <b>1350</b> to <b>1380</b> is entered for each identified logical field of the underlying data abstraction model(s) that has associated translation information. As in the given example only the “Gender” and “MaritalStatus” fields have associated translation information, assume now that the loop consisting of steps <b>1350</b> to <b>1380</b> is initially entered for the “Gender” field.

p-0177At step <b>1360</b>, an empty translation mapping table is created for the identified logical field. Then, at step <b>1370</b> mapping table contributions are created for the logical field in the empty translation mapping table using the retrieved translation information. More specifically, translated values for allowable values of the logical field and/or physical values that are retrieved from the underlying multilingual database for the logical field are included with the empty translation mapping table, whereby a translation mapping table is created for the logical field.

p-0178In the given example, assume that an empty “Gender-Info” table is created at step <b>1360</b> for the “Gender” field (lines 045-055 of Table II). Then, at step <b>1370</b> all translated values related to the “Gender” field are retrieved from the exemplary XLIFF files of Tables XV-XVII. The retrieved translated values are included with the empty “Gender-Info” table. Thus, a translation mapping table having translated values for physical values of the “gender” column in the exemplary “contact” table of Table XVIII above is created. An exemplary “Gender-Info” table is illustrated in Table XIX below.

p-0179<tables id="TABLE-US-00019" num="00019"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XIX</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>GENDER-INFO TABLE EXAMPLE</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="77pt" align="center" /><colspec colname="3" colwidth="77pt" align="left" /><tbody valign="top"><row><entry /><entry>ID</entry><entry>encoding</entry><entry>alternative_value</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="14pt" align="center" /><colspec colname="3" colwidth="77pt" align="center" /><colspec colname="4" colwidth="77pt" align="left" /><tbody valign="top"><row><entry>001</entry><entry /><entry /><entry /></row><row><entry>002</entry><entry>0</entry><entry>en</entry><entry>Unknown</entry></row><row><entry>003</entry><entry>1</entry><entry>en</entry><entry>Male</entry></row><row><entry>004</entry><entry>2</entry><entry>en</entry><entry>Female</entry></row><row><entry>005</entry><entry>0</entry><entry>es</entry><entry>Desconocido</entry></row><row><entry>006</entry><entry>1</entry><entry>es</entry><entry>Varón</entry></row><row><entry>007</entry><entry>2</entry><entry>es</entry><entry>Hembra</entry></row><row><entry>008</entry><entry>0</entry><entry>de</entry><entry>Unbekannt</entry></row><row><entry>009</entry><entry>1</entry><entry>de</entry><entry>Männlich</entry></row><row><entry>010</entry><entry>2</entry><entry>de</entry><entry>Weiblich</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0180As can be seen from of Table XIX, an “alternative_value” column (line 001) includes for the “Gender” field in lines 002-004 translated values in the English language, in lines 005-007 in the Spanish language and in lines 008-010 in the German language. Note by way of example that the translated values in the Spanish language in lines 005-007 correspond to the translated values in lines 002-004 of the exemplary Spanish XLIFF language resource file of Table XV.

p-0181At step <b>1380</b>, a translation function is created for the logical field. In the given example, a translation function is created at step <b>1380</b> for the “Gender” field (lines 045-055 of Table II). An exemplary illustrative translation function associated with the “Gender” field is shown in Table XX below.

p-0182<tables id="TABLE-US-00020" num="00020"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XX</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>TRANSLATION FUNCTION EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>001  translateGender (input desiredUserLocale, input EncodingValue,</entry></row><row><entry>002      input ColumnValue) {</entry></row><row><entry>003    select target_language.alternative_value</entry></row><row><entry>004    from Gender-Info source_language</entry></row><row><entry>005     left join Gender-Info target_language</entry></row><row><entry>006     on source_language.id=target_language.id</entry></row><row><entry>007    where</entry></row><row><entry>008     source_language.encoding=EncodingValue and</entry></row><row><entry>009     source_language.value=ColumnValue and</entry></row><row><entry>010     target_language.encoding=desiredUserLocale</entry></row><row><entry>011    return results.alternative_value</entry></row><row><entry>012  }</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0183Illustratively, the exemplary translation function shown in Table XX is invoked using the function name “translateGender” in line 001. However, the exemplary translation function shown in Table XX itself does not include translation information. Instead, the exemplary translation function shown in Table XX retrieves required translation information from an associated translation mapping table. More specifically, the exemplary translation function of Table XX illustratively defines a SQL query in lines 003-010 that queries the exemplary “Gender-Info” table of Table XIX (lines 004-005 of Table XX). The exemplary “Gender-Info” table of Table XIX is queried for a given physical value (“source_language.value=ColumnValue” in lines 001 and 009) defined in a given natural language (“source_language.encoding=EncodingValue” in lines 001 and 008) to retrieve from the translated values a required alternative_value (“target_language.alternative_value” in line 003) in a selected language (“target_language.encoding=desiredUserLocale” in lines 001 and 010). The retrieved alternative_value is returned as output (“return results.alternative_value” in line 011).

p-0184Processing then returns to step <b>1350</b>, where the loop consisting of steps <b>1350</b>-<b>1380</b> is performed for a next identified logical field. Assume now that in the given example the loop is subsequently performed for the “MaritalStatus” field. Thus, a translation mapping table having translated values for physical values of the “m_status” column in the exemplary “contact” table of Table XVIII above is created at steps <b>1360</b> and <b>1370</b>. An exemplary “MaritalStatus-Info” table is illustrated in Table XXI below.

p-0185<tables id="TABLE-US-00021" num="00021"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XXI</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MARITALSTATUS-INFO TABLE EXAMPLE</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="77pt" align="center" /><colspec colname="3" colwidth="63pt" align="left" /><tbody valign="top"><row><entry /><entry>ID</entry><entry>encoding</entry><entry>value</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="63pt" align="center" /><colspec colname="2" colwidth="14pt" align="center" /><colspec colname="3" colwidth="77pt" align="center" /><colspec colname="4" colwidth="63pt" align="left" /><tbody valign="top"><row><entry>001</entry><entry /><entry /><entry /></row><row><entry>002</entry><entry>0</entry><entry>en</entry><entry>Unknown</entry></row><row><entry>003</entry><entry>1</entry><entry>en</entry><entry>Single</entry></row><row><entry>004</entry><entry>2</entry><entry>en</entry><entry>Married</entry></row><row><entry>005</entry><entry>3</entry><entry>en</entry><entry>Divorced</entry></row><row><entry>006</entry><entry>4</entry><entry>en</entry><entry>Widowed</entry></row><row><entry>007</entry><entry>0</entry><entry>es</entry><entry>Desconocido</entry></row><row><entry>008</entry><entry>1</entry><entry>es</entry><entry>Solo</entry></row><row><entry>009</entry><entry>2</entry><entry>es</entry><entry>Casado</entry></row><row><entry>010</entry><entry>3</entry><entry>es</entry><entry>Divorciado</entry></row><row><entry>011</entry><entry>4</entry><entry>es</entry><entry>Viuda</entry></row><row><entry>012</entry><entry>0</entry><entry>de</entry><entry>Unbekannt</entry></row><row><entry>013</entry><entry>1</entry><entry>de</entry><entry>Ledig</entry></row><row><entry>014</entry><entry>2</entry><entry>de</entry><entry>Verheiratet</entry></row><row><entry>015</entry><entry>3</entry><entry>de</entry><entry>Geschieden</entry></row><row><entry>016</entry><entry>4</entry><entry>de</entry><entry>Verwitwet</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0186As can be seen from Table XXI, lines 002-006 include translated values in the English language, lines 007-011 in the Spanish language and lines 012-016 in the German language. Note by way of example that the translated values in the Spanish language in lines 007-011 correspond to the translated values in lines 005-009 of the exemplary Spanish XLIFF language resource file of Table XV.

p-0187Assume further that an associated translation function is then created for the “MaritalStatus” field at step <b>1380</b>. An exemplary illustrative translation function associated with the “MaritalStatus” field is shown in Table XXII below.

p-0188<tables id="TABLE-US-00022" num="00022"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XXII</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>TRANSLATION FUNCTION EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>001  translateMaritalStatus (input desiredUserLocale,</entry></row><row><entry /><entry>   input EncodingValue,</entry></row><row><entry /><entry>002      input ColumnValue) {</entry></row><row><entry /><entry>003    select target_language.alternative_value</entry></row><row><entry /><entry>004    from MaritalStatus-Info source_language</entry></row><row><entry /><entry>005     left join MaritalStatus-Info target_language</entry></row><row><entry /><entry>006     on source_language.id=target_language.id</entry></row><row><entry /><entry>007    where</entry></row><row><entry /><entry>008     source_language.encoding=EncodingValue and</entry></row><row><entry /><entry>009     source_language.value=ColumnValue and</entry></row><row><entry /><entry>010     target_language.encoding=desiredUserLocale</entry></row><row><entry /><entry>011    return results.alternative_value</entry></row><row><entry /><entry>012  }</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0189Note that the exemplary translation function shown in Table XXII accesses the exemplary “MaritalStatus-Info” table of Table XXI (lines 004-005). However, the exemplary translation function shown in Table XXII is otherwise similar to the exemplary translation function shown in Table XX above and, thus, not explained in more detail for brevity.

p-0190When the loop consisting of steps <b>1350</b>-<b>1380</b> was performed for each identified logical field, processing exits at step <b>1390</b>. In the given example, as only the “Gender” and “MaritalStatus” fields were identified, processing exits at step <b>1390</b> after creation of the exemplary translation function of Table XXII above.

p-0191It should be noted that in the illustrated example two separate translation mapping tables (i.e., the “Gender-Info” table of Table XX and the “MaritalStatus-Info” table of Table XXII) were created. However, in one embodiment only a single translation mapping table is created for all identified logical fields. For instance, in the given example the “Gender-Info” and “MaritalStatus-Info” tables can be combined into a single “Translation-Info” table. In this case, a single translation function accessing the single “Translation-Info” table can be provided for all identified logical fields. However, if a single translation mapping table is used, each mapping table contribution having a translated value in a given language needs to be identified with a unique identifier. By way of example, in the given example the identifier “1” of the translated value “Single” in line 003 of Table XXI needs to be modified to another value such as, e.g., “11” to avoid confusion with the translated value “Male” in line 003 of Table XIX having also the identifier “1”.

Natural Language Support in Query Execution

p-0192Referring now to <figref idrefs="DRAWINGS">FIG. 14</figref>, one embodiment of a method <b>1400</b> of providing natural language support for users running queries against a multilingual database (e.g., database <b>130</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) is illustrated. At least a portion of the steps of method <b>1400</b> can be performed by the runtime component <b>126</b> and/or the NLS manager <b>120</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. Method <b>1400</b> starts at step <b>1410</b>.

p-0193At step <b>1420</b>, an abstract query (e.g., abstract query <b>140</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) including one or more result and/or query condition fields, each corresponding to a logical field of an underlying data abstraction model (e.g., data abstraction model <b>124</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>), is received. In one embodiment, at least one result field included with the abstract query has associated translation information. By way of example, assume that the exemplary abstract query of Table XXIII below is received at step <b>1420</b>. For simplicity, the exemplary abstract query shown in Table XXIII is defined in natural language.

p-0194<tables id="TABLE-US-00023" num="00023"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XXIII</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ABSTRACT QUERY EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>001   FIND</entry></row><row><entry /><entry>002    LastName, Gender, MaritalStatus</entry></row><row><entry /><entry>003   WHERE</entry></row><row><entry /><entry>004    MaritalStatus = ’Single’</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0195The exemplary abstract query of Table XXIII includes three result fields (line 002) and is configured to retrieve last names (“LastName” in line 002), gender information (“Gender” in line 002) and marital status information (“MaritalStatus” in line 002) for patients from the multilingual database. The exemplary abstract query of Table XXIII further includes a query condition (line 004) that restricts returned data to data of patients having the marital status “Single”. It should be noted that the exemplary abstract query shown in Table XXIII includes the result and query condition fields “Marital Status” (lines 002-004) and the result field “Gender” (line 002) which refer to the “Marital Status” and “Gender” fields of the exemplary data abstraction model of Table II (lines 033-044 and 045-055 of Table II, respectively) and have associated translation information, as described above with reference to Tables XIX and XXI.

p-0196Assume now that the exemplary abstract query of Table XXIII is issued by a user using the user interface <b>160</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>. Assume further that the user is an English speaking user, i.e., a user having a user locale that defines as encoding value “en”. Accordingly, a corresponding query result (e.g., natural language result set <b>172</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) should be presented to the user in the English language.

p-0197At step <b>1430</b>, an executable query is generated on the basis of the received abstract query. One embodiment of generating an executable query on the basis of an abstract query including at least one result field having associated translation information is described in more detail below with reference to <figref idrefs="DRAWINGS">FIG. 15</figref>.

p-0198Assume now that in the given example the exemplary executable query of Table XXIV below is generated on the basis of the exemplary abstract query of Table XXIII. By way of illustration, the illustrative executable query is defined using SQL. However, any other language such as XML may be used to advantage.

p-0199<tables id="TABLE-US-00024" num="00024"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XXIV</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>EXECUTABLE QUERY EXAMPLE</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>001  SELECT DISTINCT</entry></row><row><entry>002    “t1”.“I_name” AS “LastName”,</entry></row><row><entry>003    “functions”.“translateGender”(‘en’, “t1”.“encoding”,</entry></row><row><entry>     “t1”.“gender”)</entry></row><row><entry>004         AS “Gender”,</entry></row><row><entry>005    “functions”.“translateMaritalStatus”(‘en’, “t1”.“encoding”,</entry></row><row><entry>     “t1”.“m_status”)</entry></row><row><entry>006         AS “MaritalStatus”</entry></row><row><entry>007  FROM</entry></row><row><entry>008    “contact” “t1”</entry></row><row><entry>009  WHERE</entry></row><row><entry>010    “functions”.“translateMaritalStatus”(‘en’, “t1”.“encoding”,</entry></row><row><entry>     “t1”.“m_status”)</entry></row><row><entry>011         = ‘Single’</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0200Illustratively, the exemplary executable query of Table XXIV includes a results specification in lines 001-006 requesting data from a “I_name” column (line 002), a “gender” column (lines 003-004) and a “m_status” column (lines 005-006) of the exemplary database table “contact” of Table XVIII (line 008). Furthermore, according to the query condition in lines 010-011 of Table XXIV, only data for patients having a marital status of “Single” should be returned for the query.

p-0201It should be noted that in the exemplary executable query of Table XXIV the “Gender” result field (lines 003-004 of Table XXIV) includes a function call (“functions”.“translateGender”) for the exemplary translation function “TranslateGender” of Table XX above. Furthermore, the “MaritalStatus” result and condition fields (lines 005-006 and 010-011 of Table XXIV) include a function call for the exemplary translation function “TranslateMaritalStatus” of Table XXII above.

p-0202At step <b>1440</b>, the executable query is executed against the underlying multilingual database to retrieve data for a corresponding result set. To this end, the executable query is executed to retrieve physical values defined in one or more different natural languages from the multilingual database. In the given example, the exemplary executable query of Table XXIV is executed against the exemplary “contact” table of Table XVIII.

p-0203In one embodiment, user-specific settings associated with the user issuing the query are identified when executing the executable query or prior to query execution. From the identified user-specific settings, the selected language of the user can be identified. For instance, the user-specific settings may define a role of the user; a language setting of the user, a view of the multilingual database defined for the user and/or other user-specific parameters. In the given example, the language setting can be configured to allow identification of the selected language of the user.

p-0204At step <b>1450</b>, each translation function is executed on data retrieved for result and/or condition fields having corresponding function calls. In other words, in the given example the exemplary translation function “TranslateGender” of Table XX above is executed for all gender information retrieved from the “gender” column of the exemplary “contact” table of Table XVIII. Furthermore, the exemplary translation function “TranslateMaritalStatus” of Table XXII above is executed for all marital status information retrieved from the “m_status” column of the exemplary “contact” table of Table XVIII.

p-0205At step <b>1460</b>, at least one data structure mapping at least a portion of the identified physical values to translated values defined in a selected language is identified from the executed translation function(s). In the given example, the exemplary “Gender-Info” table of Table XIX is identified from the exemplary translation function “TranslateGender” of Table XX. Furthermore, the exemplary “MaritalStatus-Info” table of Table XXI is identified from the exemplary translation function “TranslateMaritalStatus” of Table XXII.

p-0206The identified data structure(s) is (are) accessed to retrieve the translated values related to the identified physical values in the selected language. The retrieved translated values of all identified data structures define the alternative values defined in the selected language. More specifically, in the given example all physical values retrieved from the “gender” column of the exemplary “contact” table of Table XVIII for patients having the marital status “Single” are translated into alternative values in the English language using the exemplary “Gender-Info” table of Table XIX, as explained in more detail below with reference to Table XXV. Furthermore, all physical values retrieved from the “m_status” column of the exemplary “contact” table of Table XVIII are translated into alternative values in the English language using the exemplary “MaritalStatus-Info” table of Table XXI.

p-0207At step <b>1470</b>, a corresponding result set (e. g., natural language result set <b>172</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) having the retrieved alternative values in the selected language is returned. Assume that in the given example the exemplary result set of Table XXV below, which is defined in the English language according to the user locale “en” of the user, is returned to the user.

p-0208<tables id="TABLE-US-00025" num="00025"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE XXV</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>RESULT SET EXAMPLE</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="49pt" align="left" /><colspec colname="4" colwidth="63pt" align="left" /><tbody valign="top"><row><entry>001</entry><entry>LastName</entry><entry>Gender</entry><entry>MaritalStatus</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>002</entry><entry>Gonzalez</entry><entry>Male</entry><entry>Single</entry></row><row><entry>003</entry><entry>Meier</entry><entry>Female</entry><entry>Single</entry></row><row><entry>004</entry><entry>Stewart</entry><entry>Male</entry><entry>Single</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0209As can be seen from Table XXV, the exemplary result set includes three data records in lines 002-004 having last names (“LastName”), gender (“Gender”) and marital status (“MaritalStatus”) information. The data records in lines 002-004 correspond to the data records in lines 00, 006and 008of the exemplary “contact” table of Table XVIII above.

p-0210Note that the gender and marital status information is only presented in the English language. For instance, when the data record in lines 005of the exemplary “contact” table of Table XVIII is accessed at query execution runtime to determine whether this data record should be included with the exemplary result set of Table XXV, it is initially determined whether this data record satisfies the query condition in lines 01-011of Table XXIV. To this end, the marital status value “Solo” and the encoding value “es” are retrieved from line 005of the exemplary “contact” table of Table XVIII and input together with the user locale “en” to the exemplary translation function “TranslateMaritalStatus” of Table XXII. As noted above, the exemplary translation function “TranslateMaritalStatus” of Table XXII accesses the exemplary “MaritalStatus-Info” table of Table XXI and then retrieves the identifier “1” from line 008of Table XXI using the marital status value “Solo” and the encoding value “es”. Then, using the identifier “1” and the user locale “en”, the exemplary translation function “TranslateMaritalStatus” of Table XXII identifies as alternative value the translated value “Single” from line 003of Table XXI. Similarly, each alternative value presented in the exemplary result set of Table XXV is retrieved.

p-0211At step <b>1470</b>, the corresponding result set having at least a portion of the physical values retrieved from the multilingual database translated into the selected language is output. In the given example, the exemplary result set of Table XXV is output to the user. Processing then exits at step <b>1480</b>.

p-0212Referring now to <figref idrefs="DRAWINGS">FIG. 15</figref>, one embodiment of a method <b>1500</b> for generating an executable query from an abstract query (e.g., abstract query <b>140</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>) according to step <b>1430</b> of <figref idrefs="DRAWINGS">FIG. 14</figref> is illustrated. At least a portion of the steps of method <b>1500</b> can be performed by the runtime component <b>126</b> and/or the NLS manager <b>120</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0213Method <b>1500</b> starts at step <b>1510</b>, where the abstract query is transformed into an executable query. In one embodiment, the abstract query is transformed into the executable query according to method <b>400</b> of <figref idrefs="DRAWINGS">FIG. 4</figref> and method <b>500</b> of <figref idrefs="DRAWINGS">FIG. 5</figref> as described above.

p-0214At step <b>1520</b>, each result and/or query condition field in the abstract query that has associated translation information is identified as described above with reference to <figref idrefs="DRAWINGS">FIG. 13</figref>. In the given example, the fields “Gender” and “MaritalStatus” are identified. Furthermore, each query contribution of an identified field is retrieved from the executable query.

p-0215At step <b>1530</b>, each retrieved query contribution from the executable query is associated with a function call for a corresponding translation function. For instance, in the given example the “Gender” field contribution in the executable query is associated with a function call for the exemplary “TranslateGender” translation function of Table XX and the “MaritalStatus” field contribution in the executable query is associated with a function call for the exemplary translation function “TranslateMaritalStatus” of Table XXII. In one embodiment, each required translation function can be identified on the basis of corresponding logical field names of the identified fields.

p-0216At step <b>1540</b>, input parameters required for each associated function call are determined. For instance, in the given example the input parameters ‘en’, “t1”.“encoding” and “t1”.“gender” are determined for the function call for the exemplary “TranslateGender” translation function of Table XX. The input parameters ‘en’, “t1”.“encoding” and “t1”.“m_status” are determined for the function call for the exemplary “TranslateMaritalStatus” translation function of Table XXII.

p-0217At step <b>1550</b>, the determined parameters are included with the associated function calls in the executable query. Thereby, the exemplary executable query of Table XXIV above is generated in the given example. Processing then continues at step <b>1440</b> of <figref idrefs="DRAWINGS">FIG. 14</figref>.

p-0218Note that the method <b>1500</b> of <figref idrefs="DRAWINGS">FIG. 15</figref> is merely described by way of example to illustrate one embodiment of a method for generating an executable query from an abstract query according to step <b>1430</b> of <figref idrefs="DRAWINGS">FIG. 14</figref>. However, other implementations are possible. For instance, in one embodiment steps <b>1520</b> to <b>1550</b> can be implemented as integral part of the method <b>400</b> of <figref idrefs="DRAWINGS">FIG. 4</figref> or the method <b>500</b> of <figref idrefs="DRAWINGS">FIG. 5</figref>. Accordingly, all such different implementations are broadly contemplated.

p-0219It should be noted that any reference herein to particular values, definitions, programming languages and examples is merely for purposes of illustration. Accordingly, the invention is not limited by any particular illustrations and examples. Furthermore, while the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.