IL280372B2 - System and method for implementing ontologies in sql - Google Patents

Description

280372 / SYSTEM AND METHOD FOR IMPLEMENTING ONTOLOGIES IN SQL FIELD OF THE DISCLOSED TECHNIQUEThe disclosed technique relates to ontologies, in general, and to a system and method for implementing an ontology in SQL, in particular. BACKGROUND OF THE DISCLOSED TECHNIQUE Database technologies provide a wide range of models for storing, organizing, managing, and retrieving information. One of the most commonly used models is the relational database, which organizes data into tables, where the columns define data attributes, and the rows store data instances. Relationships defining logical connections between tables are created by adding a common column to two tables, typically referred to as a key. Structured Query Language (SQL) is a popular language for accessing and controlling data in a relational database, and has become an industry standard due to its simplicity and ease of use. However, the inability of relational databases to capture the inherent meaning of words limits their use as knowledge bases. The meaning inherent to a relational database is confined to the schema which defines how the data are organized. The schema is the structural blueprint of a relational database. Thus, any meaning that can be extracted from a relational database is limited to the schema defined by the database designer. Semantics is the study of the inherent meaning captured by words and phrases in human language. Communication depends on attaching semantic meaning to language based on a common understanding of words. Without consensus over the meaning of words, differences in opinions and perspectives could not be understood or resolved. In an attempt to achieve a more natural interface with humans, modern computers use semantic meaning to interpret human language. A semantic triple is the fundamental data structure in the Resource Description Framework (RDF) model codifying data as a subject-predicate-object expression. A triple-store database, also known as a knowledge base, allows for semantic queries using semantic query languages, such as SPARQL, that provide an interface for analytical query operations. Although more powerful than relational interfaces for 280372 / extracting knowledge, structure semantic queries are complicated and require special skills, beyond the conventional SQL commands. An ontology is a formalization for describing things through taxonomies, classifications and inter-relatedness. The ontology defines concepts, categories and rules for organizing raw data items into information for extracting knowledge. An ontology provides a common terminology for describing concepts and categories to facilitate communication between different platforms. Ontologies share similarities with object oriented hierarchical class structures, with the noted difference that ontologies offer greater flexibility for representing data originating from heterogeneous sources. The Web Ontology Language (OWL) is a common language for representing knowledge as an ontology, and allows for applying logical rules, such as cardinality, reasoning and inference from data codified using an RDF model. However, many databases are organized relationally, making it difficult to extract contextual and semantic knowledge from the data they already store. Moreover, querying with advanced query languages, such as SPARQL and GREMLIN, requires skills and familiarity with these languages that are beyond those of conventional database users. Thus, much of the knowledge stored inside existing databases cannot be easily accessed in a convenient manner for the typical user. US patent 9,396,283, to Miranker, entitled "System for Accessing a Relational Database using Semantic Queries" relates to integrating relational database schema into a semantic web framework. The SQL query optimizer present in the standard SQL database engine is used with a mapping process to represent the relational representation of data as RDF triples. The RDF triples are created during compilation to eliminate the problem of consistency between the relational database and the triple store. A semantic query is then translated to SQL queries that operate on the triples. US patent application publication US 2011/0202560 A1, to Bowers, entitled "Expressing and Executing Semantic Queries within a Relational Database" relates to defining semantic rules applied to executing semantic queries using relational table valued functions and common table expressions. The table valued functions are then called to execute the semantic query against a relational database. US patent application publication 2010/0241644 A1 to Jackson, entitled "Graph Queries of Information in Relational Database" relates to converting a query written 280372 / in a graph-based query language into a relational language for executing over a relational database. Multiple views of the underlying tables of the relational database are calculated to correspond to the specifications of the graph. The translated query is executed on the views to implement the graph-based query. U.S. Patent 6795825B2 to Riche, entitled "Database Querying System and Method" relates to interpreting a database query to allow querying of non-relational and relational databases using languages originally intended only for relational databases. The system represents every class of the relational schema with a corresponding virtual table. 280372 / SUMMARY It is an object of the disclosed technique to provide a novel method and system for implementing an ontology in a relational environment. In accordance with the disclosed technique, there is thus provided a method for implementing a virtual ontology over a relational database, comprising: defining a virtual ontology from multiple candidate ontologies for a relational database by: declaring a hierarchy of multiple virtual entities; for each one of the multiple virtual entities in the hierarchy, declaring a corresponding mapping associating the one virtual entity with at least a subset of at least one physical table defined by a relational schema of the relational database, thereby introducing data stored in the relational database to the virtual ontology; and storing the virtual entity in association with the corresponding mapping in a virtual ontology metadata database implemented as a relational database; and defining multiple ontology schemas, each implemented as a different relational view of the virtual ontology and capturing at least one ontology capability, wherein querying the ontology metadata database with at least a parsed portion of an intercepted first relational query targeting one of the multiple ontology schemas enables rewriting the first relational query as a second relational query, wherein executing the second relational query at the relational database enables extracting ontological knowledge from the data that is opaque with respect to the relational schema and which expresses the at least one ontology capability captured by the targeted one of the multiple ontology schemas, thereby enabling extracting the ontological knowledge within a relational framework. There is provided, in accordance with another embodiment of the disclosed technique, a system for implementing a virtual ontology over a relational database, comprising: a relational database management system (RDBMS): a relational database comprising data organized in multiple physical tables with a corresponding relational schema defining a structure for the relational database, and an RDBMS execution engine; and a computer storage unit configured to store an Ontology Data Model ("ODM"), the virtual ontology comprising: a hierarchy of multiple virtual entities, multiple corresponding mappings associating each of the multiple virtual entities with at least a subset of at least one of the multiple physical tables, thereby introducing data stored in the relational database to the virtual ontology, an ontology metadata database storing the hierarchy of multiple virtual 280372 / entities with the multiple corresponding mappings, and multiple ontology schemas, each of the multiple ontology schemas providing a different relational view of the virtual ontology and capturing at least one ontology capability, and an ODM processor configured to: intercept a first relational query targeting one of the multiple ontology schemas, and query the ontology metadata database with at least a parsed portion of the first relational query to rewrite the first relational query as a second relational query, wherein executing the second relational query at the relational database enables extracting ontological knowledge from the data that is opaque with respect to the relational schema and which expresses the ontology capability captured by the targeted one of the multiple ontology schemas, thereby enabling extracting the ontological knowledge within a relational framework. There is provided, in accordance with another embodiment of the disclosed technique, a method for extracting ontological knowledge from a relational database with a relational query, comprising: receiving a virtual ontology, comprising: a hierarchy of multiple virtual entities, multiple corresponding mappings associating each of the multiple virtual entities with at least a subset of at least one of multiple physical tables of the relational database, thereby introducing data stored in the relational database to the virtual ontology, an ontology metadata database storing the hierarchy of multiple virtual entities with the multiple corresponding mappings, and multiple ontology schemas, each providing a different relational view of the virtual ontology and capturing at least one ontology capability; submitting a first relational query targeting one of the multiple ontology schemas; querying the ontology metadata database with at least a parsed portion of the first relational query to rewrite the first relational query as a second relational query with respect to a relational schema for the relational database; and executing the second relational query at the relational database to extract ontological knowledge from the data that is opaque with respect to the relational schema, the ontological knowledge expressing the at least one ontology capability captured by the targeted one of the multiple ontology schemas, thereby extracting the ontological knowledge within a relational framework. In some embodiments, the multiple virtual entities comprise concepts and properties, wherein each the defined concept includes at least one of the properties. In some embodiments, the at least one ontology capability captured by a first one of the multiple ontology schemas comprises the defined hierarchy. 280372 / In some embodiments, the at least one ontology capability captured by a second one of the multiple ontology schemas is an inheritance capability between two of the multiple virtual entities. In some embodiments, the at least one ontology capability captured by a third one of the multiple ontology schemas is a graph traversal capability between two of the multiple virtual entities. In some embodiments, the graph traversal capability further captures transitivity from the two of the multiple virtual entities to a third one of the multiple virtual entities. In some embodiments, the at least one ontology capability further includes a reverse flow of the graph traversal capability. In some embodiments, the at least one ontology capability further comprises a logic calculation with respect to at least one of the multiple virtual entities. In some embodiments, each of the multiple ontology schemas has a corresponding logic, wherein rewriting the first relational query as the second relational query comprises applying the logic corresponding to the targeted one of the multiple ontology schemas. 280372 / BRIEF DESCRIPTION OF THE DRAWINGSThe disclosed technique will be understood and appreciated more fully from the following brief descriptions taken in conjunction with the drawings in which: Figure 1A is a schematic illustration of a computing device constructed and operative in accordance with an embodiment of the disclosed technique; Figure 1B illustrates a system for emulating an ontology data model (ODM) within a RDBMS framework, constructed and operative in accordance with another embodiment of the disclosed technique; Figures 2A-2B, taken together, illustrate a detailed view of an exemplary implementation of a virtual ontology logically overlaid on a relational schema, constructed and operative in accordance with a further embodiment of the disclosed technique; Figures 3A-3C, taken together, illustrate an intrinsic schema of the virtual ontology of Figure 2B, constructed and operative in accordance with another embodiment of the disclosed technique; Figures 4A-4C, taken together, illustrate an exhaustive schema for the virtual ontology of Figure 2B, constructed and operative in accordance with a further embodiment of the disclosed technique; Figures 5A-5D, taken together, illustrate a dereferenced schema providing a graph traversal capability over the virtual ontology of Figure 2B, constructed and operative in accordance with another embodiment of the disclosed technique; Figure 6 is a schematic illustration of a method for creating an ODM emulator overlaid on a relational database, operative in accordance with a further embodiment of the disclosed technique; Figure 7 is a schematic illustration of a method for implementing a virtual ontology over a relational database, operative in accordance with another embodiment of the disclosed technique; and Figure 8 is a schematic illustration of a method for extracting ontological knowledge from a relational database with a relational query, operative in accordance with a further embodiment of the disclosed technique. 280372 / DETAILED DESCRIPTION OF THE EMBODIMENTSThe disclosed technique overcomes the disadvantages of the prior art by providing a system and method for bridging the gap between relational information systems (RDBMS) and ontological information systems. Many organizations store their data in relational databases, and interface with the data via relational query languages, such as SQL. The advent of the Semantic Web has revealed the potential of ontological taxonomies that allow for the contextual inference of knowledge from data, knowledge which is unavailable from conventional relational schema. However, converting existing relational databases to an ontology can be costly. Moreover, retraining employees familiar with SQL syntax to use semantic languages, such as SPARQL, poses an additional hurdle. The disclosed technique addresses the demand for knowledge inference while recognizing the need to provide Semantic Web functionalities via familiar relational syntax and existing relational data storage technologies to reduce costs. To achieve this, a virtual ontology is defined and overlaid on the relational scheme of the relational database. The virtual ontology captures semantic characteristics of hierarchical taxonomy representations of data to enable the inference of contextual knowledge that would otherwise be opaque, and hence unavailable, if the data were presented exclusively under the relational schema of the RDBMS. However, the virtual ontology is implemented with relational constructs to maintain compatibility within the existing relational infrastructure. Additionally, the interfacing of the user with the virtual ontology interfaces is achieved using familiar relational query syntax, such as SQL. Thus, although the virtual ontology provides aspects of Semantic Web for extracting knowledge, the implementation remains within the confines of familiar, native relational technologies and syntax. In the description that follows, due to its ubiquitous use, the language SQL is used when referring to a relational query language for accessing the RDBMS. However, the intent is not to limit the disclosed technique to any particular version of SQL, but rather to refer to SQL as a general category of relational query languages. It is to be noted that the disclosed technique is compatible with any backend query language used to access the existing relational database system, and that customized Business Intelligence (BI) tools and applications may be substituted where appropriate. 280372 / Reference is now made to Figure 1A, which is a schematic illustration of a computing device, generally referenced 100, constructed and operative in accordance with an embodiment of the disclosed technique. Device 100 is representative of a computing device for implementing aspects of the disclosed technique, such as but not limited to, a desktop computer, a mobile phone, a tablet, a server, and the like. Device 100 includes at least one processor 102, at least one transceiver 104, at least one input/output device (I/O) 106, a random-access memory (RAM) 108, a non-volatile computer readable storage device 110 and a read only memory (ROM) 112, the latter three (3) collectively referred to herein as memory 114. Processor 102, transceiver 104, I/O 106, and memory 114 comprising RAM 108, storage device 110, and ROM 112, are electrically coupled via a common bus structure 116. At least one processor 102 includes one or more central processing units (CPUs), graphical processing units (GPUs), accelerated processing units (APUs) and the like. Transceiver 104 is operative to enable two-way communication between device 100 and additional devices or routers (not shown), such as to send and receive data and computer executable instructions, via wired means, such as electrical or optical cables and wires, and/or wireless means, such as long, medium, or short wave radio communication, including satellite communications, cellular communications, WiFi®, BlueTooth®, Zigbee, radar, lidar, infrared, microwave technologies, and the like. Transceiver 104 is operative to connect device 100 to a network, such as a local area network (LAN), a wide area network (WAN), or an external network such as the Internet. The network may be implemented in any suitable manner, such as with a client-server architecture or a peer-to-peer architecture. I/O 106 is operative to interface with the environment, such as with a human user of device 100, and includes one or more input and output interfaces, such as, but not limited to, a visual display, an electronic mouse, a keyboard, a touch-based screen, a loud speaker, a microphone, and the like. It will be appreciated that device 100 may operate without human operation and without I/O device 106. To carry out operations of the disclosed technique, processor 102 is operative to execute one or more instructions relating to data retained in memory 114. RAM 108 may include a static random access memory (SRAM). Storage device 110 may be implemented using known means, such as electronic, magnetic, optical, 280372 / electromagnetic, or semiconductor technologies, or any suitable combination thereof, and may include one or more of a portable disk, a hard disk, a digital versatile disk (DVD), a memory stick, to name but a few. ROM 112 may include one or more of a compact disc read-only memory (CD ROM), an erasable programmable read-only memory (EPROM or Flash memory). Information stored in memory 114 is not to be construed as being transitory signals, such as radio waves, electromagnetic waves, optical pulses, or electrical signals transmitted through a wire. Although Figure 1A shows device 100 as a stand-alone device, this is for illustrative purposes only. In some implementations, the components of device 1as illustrated in Figure 1A are logical or virtual representations of multiple physical components distributed over multiple devices at one or more physical locations, and that operate in a coordinated manner to carry out operations of the present invention, as is known in the art of distributed computing. Reference is now made to Figure 1B, which illustrates a system, generally referenced 120, for providing ontological capabilities inside an RDBMS framework, constructed and operative in accordance with an embodiment of the disclosed technique. System 120 includes a client 122 communicating with a knowledge base 124. Client 122 may implemented with a computing device, such as device 100, configured with a software application for interfacing with a relational database. Knowledge base 124 includes a RDBMS 128 and an ODM emulator 130. Both RDBMS 128 and ODM emulator 130 are implemented using relational constructs that are accessible using familiar relational languages, such as SQL. RDBMS 128 is a conventional relational database system, and includes a data storage device 136 for physically storing data according to a relational schema 140, and a RDBMS engine 138 for handling relational queries directed to data stored in storage device 136. The tables of a relational schema are typically related according to one or more keys, such as primary (PK) and foreign keys (FK). RDBMS engine 138 provides access to data stored in storage device 136 according to conventional techniques. On receiving a SQL query, RDBMS engine 138 processes and executes the query by performing one or more read, write, edit and delete operations, and provides the results of the query. ODM emulator 130 provides a virtual ontology layer interfacing between client 122 and RDBMS 128. ODM emulator 130 may be implemented with a computing device, such as device 100, configured with a software application for 280372 / executing program code instructions to implement the functionalities defined herein below for ODM emulator 130. ODM emulator 130 operates as an adapter that allows client 122 to extract ontological knowledge from RDBMS 128 using SQL formulated queries. ODM emulator 130 includes ontology declarations 142, relational-to-ontology mappings 144, an ontology metadata database 146 multiple ontology schemas 148, and a SQL transpiler 150. Ontology declarations 142, relational-to-ontology mappings 144, ontology metadata database 146, and ontology schemas 148 together form a virtual ontology 152. Ontology metadata database 146 is implemented as a relational database. SQL transpiler 150 converts queries targeting virtual ontology 152 for execution by RDBMS 128. An ontology author declares ontology declarations 142 and relational-to-ontology mappings 144 using an extended SQL definition language, described in greater detail below. Ontology declarations 142 define the virtual entities (e.g. concepts and properties) of the virtual ontology and their respective capabilities. For example, the capabilities may relate to concept and property hierarchies, graph traversal, inheritance, and rule inferencing, to name but a few. The ontological capabilities provided by the virtual ontology augment the capabilities provided by the relational structure of RDBMS 128. The ontology author additionally declares relational-to-ontological mappings 144 that link (i.e. "introduce") the physical data individuals stored in RDBMS 128 to the virtual entities defined for virtual ontology 152. Relational-to-ontological mappings 144 create a correspondence between the physical data stored at storage device 136, in the tables and rows as defined by relational schema 140, to the virtual entities declared in ontology declarations 142. Thus, relational-to-ontological mappings 144 link the virtual entities of virtual ontology 152 to the physical data stored in RDBS 128. ODM emulator 130 cross-references the definitions of ontology declarations 142 and relational-to-ontology mappings 144 with the definitions of relational schema 140, and stores the results in ontology metadata database 146. ODM emulator 130 creates multiple ontology schemas 148 as different relational views of virtual ontology 152. Each schema 148 captures one or more ontological capabilities that are outside the conventional relational capabilities provided by relational schema 140 of RDBMS 128. For example, one of schemas 148 may capture the hierarchy of the entities (i.e. concepts and/or properties) of 280372 / virtual ontology 152. Another one of schemas 148 may additionally capture an inheritance capability derived from the hierarchy. Yet another one of schemas 1may capture a graph traversal capability derived from the hierarchy. Since ontology schemas 148 are implemented as different relational views, the respective ontology capabilities of virtual ontology 152 are accessible via queries formulated in relational languages, such as SQL. ODM emulator 130 presents the ontology schema 148 to client 122 as different relational views for virtual ontology 152. Client 122 submits a SQL formulated query (i.e. "the first SQL query") targeting one of ontology schemas 148. Transpiler 150 intercepts the first SQL query and converts it to one or more SQL statements to produce a "second SQL query" that is executable by RDBMS 128, as detailed below. SQL transpiler 150 includes a query parser 154, a virtual-to-physical converter 156, and a virtual-to-physical interface 158. On intercepting the first SQL query (i.e. received from client 122), parser 154 parses the first SQL query to identify which of the multiple ontology schemas 148 is targeted by the first SQL query. Additionally, parser 154 parses the first SQL query to identify the referenced virtual entities (i.e. concepts and/or properties). The identity of the ontology schema is used to determine the logic for rewriting the second SQL query. The identities of the virtual entities are used to determine which physical relational tables (e.g. defined in relational schema 140) the second SQL query will subsequently reference. Virtual-to-physical converter 156 queries ontology metadata database 1to determine which of the physical relational tables and rows of relational schema 140 correspond to the parsed virtual entities of virtual ontology 152 referred to in the first SQL query. Virtual-to-physical converter 156 applies the logic corresponding to the targeted ontology schemas 148 to write the second SQL query as one or more SQL statements that reference the physical tables of RDBMS 128 determined above, such that executing the second SQL query via RDBMS 128 produces a response revealing knowledge that expresses the ontological capabilities captured by the targeted one of schemas 148. Virtual-to-physical interface 158 submits the second SQL query to RDBMS 128. RDBMS engine 138 executes the second SQL query using conventional SQL query techniques, and provides the response to SQL transpiler 150 via virtual-to-physical interface 158. ODM emulator 130 provides the response to client 122. 280372 / For example, a SQL query targeting the schema capturing just the hierarchy of virtual ontology 152 would be rewritten for execution by RDBMS 1according to a first logic. A SQL query targeting the schema that additionally captures the inheritance capability of virtual ontology 152 would be rewritten for execution by RDBMS 128 according to a second logic. A SQL query targeting the schema that additionally captures the graph traversal capability of virtual ontology 152 would be rewritten for execution by RDBMS 128 according to a third logic. In addition to applying the logic for the targeted schema, SQL transpiler 150 rewrites the SQL query received from client 122, which references entities of virtual ontology 152, to reference the physical tables and rows defined by relational schema 140. The rewritten SQL query can thus be executed by RDBMS engine 138 using conventional techniques. Importantly, the logic applied by SQL transpiler 1formulates the second SQL query such when RDBMS engine 138 executes the second SQL query at RDBMS 128, the response extracts knowledge revealing the ontological capability of the targeted schema, e.g. hierarchy, inheritance, graph traversal, and the like. This knowledge is ontological knowledge that would not be easily accessible by querying RDBMS 128 directly with respect to relational schema 140. ODM emulator 130 thus provides ontological capabilities for extracting ontological knowledge that augment the conventional relational capabilities of RDBMS 128, while remaining within a relational (i.e. SQL) framework. Client 122 interfaces with knowledge base 124 as though it were a conventional relational database. Each of ontology schemas 148 has the appearance of a relational schema and may be queried using SQL syntax. SQL transpiler 150 uses ontology metadata database 146 to map the virtual entities of virtual ontology 152, referred to in the first SQL query, to one or more corresponding relational entities of RDBMS 128. Additionally, each one of ontology schemas 1has a corresponding logic for implementing the ontological capabilities. SQL transpiler 150 applies the logic for the targeted one of schemas 148 when rewriting the second SQL query. Thus, executing the second SQL query on RDBMS 1extracts knowledge capturing the ontological capabilities of the targeted one of schemas 148. Virtual ontology 152 is superimposed over the relational schema and represents the data stored in RDBMS 128 as a graph of ontology entities exhibiting a semantic hierarchy. While capturing ontological capabilities, virtual ontology 152 is 280372 / implemented using relational constructs. The ontology author defines virtual ontology 152 in advance using an Ontology definition language (ODL), which is similar to conventional data definition languages (DDLs) with extensions for declaring entities having ontological characteristics. The entities of virtual ontology 152 do not necessarily correspond to the physical tables of the relational schema for RDBMS 128. In particular, ontology entities can also represent properties, which in RDBMS 128 appear as columns of tables. The ontology author defines one or more inference rules that the ontology entities are subject to, such as concept and property inheritance, property symmetry, transitivity, and inversion. The ontology author then maps the data items, i.e. the individuals, stored in RDBSM 128, to the entities defined for virtual ontology 152 via relational-to-ontology mappings 144 such that queries targeting virtual ontology 152 produce answers relating to data stored in RDBMS 128. The ontology author additionally uses ODL statements to define relationships between the entities defined for the ontology to connect these entities to form a graph. The relationships may be one-to-one, one-to-many or many-to-many relationships. The graph can be subsequently traversed to extract knowledge, providing yet another ontological capability. Importantly, all these ontological capabilities are implemented within the existing relational framework, and are accessible with queries formulated in SQL syntax. The ontology definition and mappings are stored in database 146. As noted, virtual ontology 152 is presented to client 122 as multiple relational views via ontology schemas 148, each capturing a different set of ontological capabilities. While the ontology schema appear as convention relational schema to client 122, each has a corresponding logic for implementing the respective ontological capabilities, described in greater detail below. The "intrinsic" ontology schema expresses the hierarchy explicit defined by the ontology author for virtual ontology 152. The "exhaustive" ontology schema additionally enables querying higher-level entities for opportunistic properties and reflections of underlying sub-entities in the hierarchy. The exhaustive ontology schema adds to the intrinsic ontology schema, any columns that may be derived from concepts in the underlying hierarchy. The "dereferenced" ontology schema further adds the capability of inferring knowledge by traversing over the ontology as a graph. Each of ontology schemas 148 are presented to client 122 as virtual relational schemas that 280372 / are queryable with SQL formulated queries, and presents a different set of virtual relational tables and rows corresponding to virtual concepts and properties of virtual ontology 152. Essentially, one can view virtual ontology 152 as a higher dimensional ontological representation of the physical data stored according to the lower-dimensional relational schema 140. The higher dimensional ontological representation provides greater connectivity, associations, and hierarchy between the data facts stored in RDBMS 128, as defined by the ontology author. Each of the ontology schema subsequently generated by SQL transpiler 152 presents a different, lower dimensional (i.e. relational) projection of the higher dimensional ontological representation. This enables client 122 to query virtual ontology 152 using a lower dimensional interface, e.g., using SQL, just as multiple 2D projections of a 3D object allow analyzing the 3D object with 2D vectors. In this manner, knowledge base 1remains in the lower dimensional relational world, both in terms of the physical storage of the data, as well as the user interfacing via SQL, while providing knowledge extraction capabilities characteristic of higher dimensional ontologies. Client 122 queries knowledge base 124 by submitting a SQL query with respect to one of schemas 148. Thus, the SQL query received from client 122 may reference a virtual entity of virtual ontology 152 that does not have a corresponding physical table or column in RDBMS 128. Consequently, RDBMS engine 138 of RDBMS 128 may not be able to directly execute the SQL query received from client 122. SQL transpiler 150 intercepts the SQL query received from client 122 and rewrites the query for relational schema of RDBMS 128 such that it may be executed by RDBMS engine 138. Query parser 154 parses the query from client 122 to identify the referenced virtual entities of virtual ontology 152 and the targeted schema 148. Virtual-to-physical converter 156 queries ontology metadata database 146 with the identified virtual entities to determine the corresponding physical tables and rows of relational schema 140. Virtual-to-physical converter 156 applies the logic corresponding to the targeted schema 148, i.e. by performing a reasoning procedure that applies relational-to-ontology mappings 144 and inferencing rules and relationships defined by the ontology author and corresponding to the targeted schema 148 such that the converted query captures the respective ontological capabilities. Consequently, executing the rewritten query by RDBMS engine 138 280372 / extracts ontological knowledge. Since both the original query and the converted query are formulated in SQL, the conversion performed by SQL transpiler 150 is a SQL to SQL conversion from virtual ontology 152 to the relational schema 140 of RDBMS 128. SQL transpiler 150 submits the converted query to RDBMS engine 1via virtual-to-physical interface 158. RDBMS engine 138 executes the converted query and provides the results to SQL transpiler 150, which presents the results to client 122. In this manner, client 122 is able to extract knowledge from RDBMS 1with a SQL formulated query, where this knowledge reflects ontological capabilities that are exclusive to virtual ontology 152. This allows users who are less familiar with advanced query languages, such as SPARQL, to extract knowledge from RDBMS 128 inherent to virtual ontology 152 without having to leave the familiar relational environment. Moreover, the ODM emulator 130 saves the cost of converting RDBMS 128 to a triple store database. In this manner, virtual ontology 152 provides client 122 with a higher-dimensional ontology model for the data that is physically stored according to the lower-dimensional relational schema. The higher-dimensional ontology enables client 122 to access knowledge from the data that would otherwise be inaccessible. The relational implementation of virtual ontology 152 maintains compatibility with the SQL environment of the existing RDBMS 128, and ensures usability by users who are less familiar with advanced semantic languages. A description for defining virtual ontology 152 now follows.

Ontology Definition Ontologies represent knowledge as concepts organized as a network of nodes. As such, ontologies have hierarchical, inheritance, and inference capabilities that bear a similarity to object oriented classes. An ontology is built from entities that are linked via relationships to form hierarchical directed graph. The structure of the ontology can subsequently be mined to infer knowledge, for example, from an inheritance hierarchy defined for two entities, or a graph connectivity reflecting a relationship between two entities. The ontology author creates virtual ontology 152 using an Ontology Definition Language (ODL), which offers a rich toolset of ontological capabilities that 280372 / are not typically provided by relational platforms. The ODL allows defining an architecture of ontology entities from which knowledge can be inferred through inheritance, symmetry, transitivity, inversion, and graph traversal, to name but a few. The ODL includes extensions to the data definition language (DDL) used to define the relational schema. The extended instruction set of the ODL is used to define ontological features, such as concepts, properties, and their characteristics. There may be any number of possible virtual ontology schemas for a given relational schema, and the ODL allows defining a malleable virtual ontology that may be adapted and modified with time, to suit evolving needs, e.g. of client 122. Since the implementation is virtual, any modifications to virtual ontology 152 incur little cost. The ODL allows the ontology author to design virtual ontology 152 within a virtual relational framework, i.e. without having to rewrite the data and store the data as triple stores. Thus, the existing RDBMS system remains unchanged, saving significant costs. Virtual ontology 152 may organize the data completely differently from relational schema 140 of RDBMS 128, and thus may include concepts, properties and relationships that do not exist in relational schema 140. The design of virtual ontology 152 is left to the discretion of the ontology author. Since the implementation is virtual, the ontology author has flexibility to adapt virtual ontology 152 over time to suit the needs of client 122 at relatively low cost. The same data stored according to relational schema 140 can be mapped to multiple ontologies each capturing different semantic world views. Virtual ontology 152 may also be defined to include only a subset of the data stored in RDBMS 128, for example to ensure security and privacy, or efficiency when only a subset of the data is needed for an application. More than a mere graph database, virtual ontology 152 allows for applying inferencing rules, such as class inheritance, property inheritance, symmetry, transitivity, inversion, property logic, property aliasing, and the like. The ODL allows the ontology author to define inferencing rules for virtual ontology 152 corresponding to those provided by web ontology languages, such as OWL 2.0. Declaring Ontology entities: Concepts and Properties To declare the entities of virtual ontology 152, the ODL provides Create_Concept and Create_Property instructions. The syntax is similar to the DDL syntax for creating tables and columns. Unlike in relational schema 140 where 280372 / properties are defined strictly as columns of tables, in ontologies, properties are ontological entities as well. Thus both concepts and properties are represented by virtual tables in the ontology schema subsequently presented to client 122. For example, the ODL statement Create_Concept Person (Person_ID int, Name string, Age int) creates three virtual tables: a virtual table representing the concept Person and virtual tables representing the properties Name and Age. In ontology schema 148, virtual tables representing properties are indicated, such as with the character "@" to distinguish properties from concepts. Thus @Name and @Age refer to virtual tables representing properties, whereas Person refers to a virtual table representing a concept. The virtual table for Person has three columns: Person_ID as a primary key (PK), Name storing a string value, and Age storing an integer. When viewing virtual ontology 152 via ontology schema 148, all three virtual tables are presented to client 122 for querying with SQL. The ODL statement: Create_Concept Company (Company_ID int, Name string, Age int) creates a virtual table for Company with three virtual columns: Company_ID as a PK, Name and Age. However, @Name and @Age already exist in the ontology as properties, defined above for Person. Therefore the corresponding virtual tables @Name and @Age additionally store the names and ages for individuals belonging to either of Person or Company. Consequently, Person and Company are now related by their shared properties, even though no formal relationship was declared between them. The tables @Name and @Age may subsequently be queried to mine for knowledge related to both Persons and Companies through their shared property Name. If the ontology author were to declare Name as a string for one concept, and as a number for another concept, an error will be triggered, since Name exists as an entity over the entire ontology. Once virtual ontology 152 has been created, to enable client 122 to query knowledge base 124 using SQL statements, SQL transpiler 150 presents virtual ontology 152 as multiple ontology schema 148. Each of ontology schema 148 is implemented with virtual relational tables, and thus may be queried with SQL. However, while the implementation is relational, each of ontology schema 1captures a different subset of the ontological capabilities of virtual ontology 152, each presenting a lower dimensional (i.e. relational) projection of the higher dimensional virtual ontology 152 to client 122. At a minimum, each ontology schema at least includes the relational schema 140 for RDBMS 128. Thus, if no virtual 280372 / ontology has been defined for knowledge base 124, client 122 may query knowledge base with respect to relational schema 140 for RDBMS 128. In this case, SQL transpiler 150 passes the query directly to RDBMS engine 138. From the perspective of client 122, each ontology schema 148 appears as a relational schema that is queryable with SQL. However, each ontology schema includes additional virtual tables and columns that are not included in relational schema 140 and which capture one or more ontological capabilities, such as inference through inheritance, symmetry, transitivity, inversion, capabilities, and the like. The most fundamental of ontology schema 148 is the intrinsic schema. The intrinsic schema includes any tables and columns defined in the original relational schema for RDBMS 128, and additionally, virtual tables and columns corresponding to the ontology entities explicitly defined by the ontology author. To present virtual ontology 152 according to the intrinsic schema, SQL transpiler 1presents to client 122 the relational schema and any virtual tables declared by the ODL statements defining virtual ontology 152. The virtual columns for the virtual tables of the intrinsic schema correspond to properties declared explicitly in the ODL statements as well as inherited properties. The exhaustive schema of ontology schema 148 includes the virtual tables and columns of the intrinsic schema. Additionally, virtual columns are added to the virtual tables for properties that are inferable from descendant concepts in the ontology hierarchy. Thus, the exhaustive schema additionally captures knowledge inferred from the concept hierarchy. The dereferenced schema of ontology schema 148 additionally includes virtual tables and columns that express graph traversability over the virtual ontology. Graph traversability is implemented relationally through the use of FKs that connect the virtual tables representing two related entities. The virtual tables of the dereferenced schema include any information that could be accessed by hopping from one entity to the related entity via the FK, as though traversing a graph. By querying the virtual tables of the dereferenced schema, client 122 effectively extracts knowledge inferred via graph traversal, however the implementation is done entirely with SQL formulated queries and relational tables. The dereferenced schema is described in greater detail below with respect to the graph traversal capability. The description describes a graph traversal capability of one degree, however it is to be 280372 / understood that the technique may similarly be applied to achieve a graph traversal of multiple degrees. Concept Inheritance Definition The ODL includes an Inherit instruction that provides an inheritance capability. The derived concept is effectively a subset of the base concept, and the relationship enables important ontology capabilities, such as abstraction (when moving from derived to base) and distinction (when moving from base to derived). Inheritance is implemented with respect to both the attributes as well as any relationships associated with the parent (i.e. base) concept. For example, in a relational schema, a Parent table is linked to a Mother table with a foreign key (FK). However, there is nothing in this relationship to enable inferring semantic meaning between Mother and Parent. Conversely, in an ontology schema, defining Mother as inheriting from Parent captures the hierarchical relationship of Mother as a subset of Parent. Thus, Create_Concept Mother Inherits Parent creates a virtual table Mother that automatically inherits the properties from Parent. These include any attribute properties (e.g. Age, Marital status) as well as relationships to other concepts, e.g. a virtual column "Parent To" stores a FK linking a Parent to a Child. Semantically, Alice (a parent) is a Parent To Sam (a child). In a similar manner, Father may be created as inheriting from Parent, i.e. Create_Concept Father Inherits Parent. A one-to-one relationship "Spouse" may be defined between the concepts Mother and Father with the instruction, Create_Property Spouse (Mother, Father). This creates a virtual column "Spouse" in the virtual tables for Mother and Father. In the virtual table for Mother, Spouse stores the primary key (PK) of the corresponding Father as a FK. In the virtual table for Father, Spouse stores the PK of the corresponding Mother as an FK. Since all Grandmothers are also Mothers, the ODL statement Create_Concept Grandmother Inherits Mother creates a virtual table Grandmother with virtual columns for Age and Marital Status, the relationship "Parent To" tracing back to Parent, and additionally a virtual column "Spouse" inherited directly from Mother. Relationships are presented in the dereferenced schema, but not in the exhaustive or intrinsic schema. The following method is an exemplary implementation for rewriting an SQL query to capture inheritance: 280372 / - Obtain the mappings between the physical tables of RDBMS 128 and the concepts in the concept hierarchy for virtual ontology 152. In the exemplary ontology of Figures 2A-2B, each physical table is mapped to an ontology concept, however this is not required. - Apply a union across the mappings to add to the query result individuals mapped to the child concepts. - Automatically assign columns when adding a property of a child concept to a parent concept. - Include the added property in the query received from the client as a common table expression (CTE), or a sub-query.

For example, given the following concept hierarchy for a virtual ontology: Concepts- Concept A inherits Thing , Concept B inherits A , Concept C inherits B , and the following mapping to the relational schema: Tables- Table T1mapped to A , Table T2 mapped to B , Table T3 mapped to C . On receiving a query from client 122: SELECT * from Intrinsic.A WHERE…(rule) SQL transpiler 150 performs a reasoning procedure on the query by applying the ODL ontology definition statements and mappings, and rewrites the query as the following CTE query: With (Intrinsic _A AS SELECT * from T UNION ALL SELECT * from T UNION ALL SELECT * from T3) SELECT * FROM Intrinsic _A WHERE…(rule) Sub-Query: SELECT * FROM t ( SELECT * from T UNION ALL SELECT * from T UNION ALL SELECT * from T3) ) as Intrinsic _A WHERE…(rule) This adds individuals stored in T2 and T3 to the query results for concept A, reflecting the inheritance hierarchy between the concepts B and C corresponding to T2 and T3, and concept A. If client 122 submits the following query: 280372 / SELECT * from Intrinsic .BWHERE …(rule) SQL transpiler 150 rewrites the query similar to the query above with the noted exception that individuals from table T1 are not included. This is because B is lower down in the hierarchical scheme and already inherits from A, and thus already includes the individuals of T1 mapped to A. The rewritten query is as follows: With (Intrinsic _B AS SELECT * from T UNION ALL SELECT * from T3) SELECT * FROM Intrinsic _B WHERE…(rule) Sub-Query: SELECT * FROM t ( SELECT * from T UNION ALL SELECT * from T3) ) as Intrinsic _B WHERE…(rule) Implementing Concept Inheritance: The following ODL statements define a Company concept, and additionally an Employee and Adult inheriting from Person, where Employee includes a relationship "works_in" to Company: CREATE CONCEPT Company(cid string, name string) CREATE MAPPING companies() AS SELECT "ABC" AS cid, "ABC Inc." AS name CREATE_CONCEPT Person(pid string PRIMARY KEY, name string, age int); CREATE_CONCEPT Employee(works_in string REFERENCES Company(cid)) INHERITS Person; CREATE_CONCEPT Adult() FROM Person WHERE age>18; CREATE_MAPPING people() INTO Person AS SELECT "1" AS pid, "john" AS name, 16 AS age; CREATE_MAPPING employees() INTO Employee AS SELECT "2" AS pid, "eric" AS name, 29 AS age, "ABC" AS works_in; The individuals of Employee are added explicitly via the CREATE MAPPING statement, whereas the individuals of Adult are determined explicitly with a WHERE statement. Each concept is presented as a virtual table in each of the intrinsic, exhaustive, and dereferenced schema, either as common table expressions, or as subqueries. 280372 / For the intrinsic schema, inference through inheritance is implemented with the UNION operator on all the mappings relating to the designated concept. Thus, the following SQL query targeting the intrinsic schema: SELECT * FROM intrinsic.Person is rewritten by SQL transpiler 150 as: WITH Person AS ( SELECT "1" AS pid, "john" AS name, 16 AS age UNION ALL SELECT "2" AS pid, "eric" AS name, 29 AS age ) SELECT * FROM Person Executing these SQL instruction on the physical database allows client 122 to extract knowledge inferable through inheritance.

For the exhaustive schema, the properties for all of the descendants are added recursively to the virtual tables for each concept. Starting from the topmost node in the hierarchy "Thing", any properties of concepts derived from Thing 270 are added to Thing. For each derived concept from Thing 270, properties derived from those concepts are added, until there are no more derived concepts. Thus, properties are added to higher hierarchical concepts from lower derived concepts.

The following query targeting the exhaustive schema: SELECT * FROM exahustive.Person is rewritten by SQL transpiler 150 as: WITH Person AS ( SELECT "1" AS pid, "john" AS name, 16 AS agem, NULL as works_in UNION ALL SELECT "2" AS pid, "eric" AS name, 29 AS age, "ABC" AS works_in ) SELECT * FROM Person The "works_in" property is NULL padded to the "people" mapping, since all Person descendant properties should be exposed in the exhaustive schema. Executing the above SQL instruction on the physical database allows client 122 to additionally extract knowledge from the concept hierarchy, e.g. to learn about properties declared only for lower ordered entities, from higher-ordered entities.. 280372 / For the dereferenced schema, columns representing all possible graph traversals from a concept are presented as well. Since SQL transpiler 150 generates the rewritten SQL query in real time, the relevant implementation is transpiled only when a relationship property is explicitly requested. For a Company To add columns accessible via graph traversal, SQL transpiler 150 uses a LEFT JOIN SQL instruction. Thus, the following SQL query targeting the dereferenced schema: SELECT name, `works_in.company_name` FROM dereferenced.Person is rewritten by SQL transpiler 150 as: WITH Person AS ( SELECT name, c.company_name AS `works_in.company_name` FROM ( SELECT "1" AS pid, "john" AS name, 16 AS agem, NULL as works_in UNION ALL SELECT "2" AS pid, "eric" AS name, 29 AS age, "ABC" AS works_in ) p LEFT JOIN ( SELECT "ABC" AS cid, "ABC Inc." AS NAME ) c ON p.works_in = c.cid ) SELECT name, `works_in.company_name` FROM Person Executing these SQL instructions on the physical database allows client 122 to additionally extract knowledge by traversing the relationships of the ontology as branches on a graph.

Property Inheritance Definition Just as concepts capture inheritance, so do properties. Property inheritance enables abstraction/distinction capability over relationships, as opposed to concepts. Any defined property characteristics (e.g. inversion, transitivity, etc.) are automatically inherited by the derived properties. As a formal inference rule, property inheritance is defined as: Derived P roperty x, y → B asePropertyx, y The disclosed technique implements this ontology capability by declaring properties via the ODL. For example, the ODL statement Create_Property @Name as String creates a property Name storing values of type string. Additional properties may be declared to inherit from @Name, e.g. Create_Property @Person_Name Inherits Name and Create_Property @Company_Name Inherits Name create child properties Person_Name and Company_Name that are semantically related to the 280372 / property @Name through inheritance. Subsequently, knowledge learned about @Person_Name and @Company_Name is inferable for @Name via the exhaustive schema. Similarly, declaring the concepts Person and Company with: Create_Concept Person (Person_ID, Person_Name, Age) and Create_Concept Company (Company_ID, Company_Name, Age) relates these concepts through a shared ancestor, e.g. the parent property @Name. The following ODL statements declare a property entity Name, and two concepts, Person and Company, each including a property inheriting from Name, e.g. First_Name and Company_Name, respectively:: Create_Property Name(name); Create_Concept Person(Person_ID, Age, First_Name Inherits Name) Create_Concept Company(Company_ID, Company_Name Inherits Name) Executing the statement: SELECT entity_id, name from @name, returns all the names of both people and companies. The following demonstrates different options for introducing properties and the property inheritance : Create_Property name string; Create_Property first_name string INHERITS name; Create_Concept Person(pid string, first_name string, last_name INHERITS name, age int); Create_Mapping people() INTO Person AS SELECT "1" as pid, "john" AS first_name, "Doe" AS last_name, 30 AS age; The property "name" is introduced explicitly, as well as "first_name" which inherits from "name" and therefore has the same SQL data type. The property "last_name" inheriting from "name" is introduced within the CREATE CONCEPT statement. The following statement is now executable: SELECT pid, name, age FROM Person. Property inheritance is implemented by the transpiler by incorporating column aliasing within SELECT statement. Since the 3D world of ontologies is being mapped to the 2D world of the relational model, a collision might exist in the intrinsic/exhaustive schemas, which would need to be resolved before executing on RDBMS 128. In the example above, "Person" effectively has two "name" properties (both "first_name" and "last_name" as "name"). The ontology author may determine to resolve this with the following options: 280372 /

Claims (27)

280372 /

1.CLAIMS 1. A method for implementing a virtual ontology over a relational database, comprising: defining a virtual ontology from multiple candidate ontologies for a relational database by: a) declaring a hierarchy of multiple virtual entities; b) for each one of said multiple virtual entities in said hierarchy, declaring a corresponding mapping associating said one virtual entity with at least a subset of at least one physical table defined by a relational schema of said relational database, thereby introducing data stored in said relational database to said virtual ontology; and c) storing said virtual entity in association with said corresponding mapping in a virtual ontology metadata database implemented as a relational database; and defining multiple ontology schemas, each implemented as a different relational view of said virtual ontology and capturing at least one ontology capability, wherein querying said ontology metadata database with at least a parsed portion of an intercepted first relational query targeting one of said multiple ontology schemas enables rewriting said first relational query as a second relational query, wherein executing said second relational query at said relational database enables extracting ontological knowledge from said data that is opaque with respect to said relational schema and which expresses said at least one ontology capability captured by said targeted one of said multiple ontology schemas, thereby enabling extracting said ontological knowledge within a relational framework.

2. The method of claim 1, wherein said multiple virtual entities comprise concepts and properties, wherein each said defined concept includes at least one of said properties.

3. The method of claim 1, wherein said at least one ontology capability captured by a first one of said multiple ontology schemas comprises said defined hierarchy. 280372 /

4. The method of claim 1, wherein said at least one ontology capability captured by a second one of said multiple ontology schemas is an inheritance capability between two of said multiple virtual entities.

5. The method of claim 1, wherein said at least one ontology capability captured by a third one of said multiple ontology schemas is a graph traversal capability between two of said multiple virtual entities.

6. The method of claim 5, and wherein said graph traversal capability further captures transitivity from said two of said multiple virtual entities to a third one of said multiple virtual entities.

7. The method of claim 5, and wherein said at least one ontology capability further includes a reverse flow of said graph traversal capability.

8. The method of claim 1, wherein said at least one ontology capability further comprises a logic calculation with respect to at least one of said multiple virtual entities.

9. The method of claim 1, wherein each of said multiple ontology schemas has a corresponding logic, wherein rewriting said first relational query as said second relational query comprises applying said logic corresponding to said targeted one of said multiple ontology schemas.

10. A system for implementing a virtual ontology over a relational database, comprising: a relational database management system (RDBMS), comprising: an RDBMS comprising: a relational database comprising data organized in multiple physical tables with a corresponding relational schema defining a structure for said relational database, and an RDBMS execution engine; and an ODM computer comprising: an ODM storage unit configured to store a virtual ontology, said virtual ontology comprising: a hierarchy of multiple virtual entities, 280372 / multiple corresponding mappings associating each of said multiple virtual entities with at least a subset of at least one of said multiple physical tables, thereby introducing data stored in said relational database to said virtual ontology, an ontology metadata database storing said hierarchy of multiple virtual entities with said multiple corresponding mappings, and multiple ontology schemas, each one of said multiple ontology schemas providing a different relational view of said virtual ontology and capturing at least one ontology capability, and an ODM processor configured to: intercept a first relational query targeting one of said ontology schemas, and query said ontology metadata database with at least a parsed portion of said first relational query to rewrite said first relational query as a second relational query, wherein executing said second relational query at said relational database enables extracting ontological knowledge from said data that is opaque with respect to said relational schema and which expresses said ontology capability captured by said targeted one of said multiple ontology schemas, thereby enabling extracting said ontological knowledge within a relational framework.

11. The system of claim 10, wherein said multiple virtual entities comprise concepts and properties, wherein each said defined concept includes at least one of said properties.

12. The system of claim 10, wherein said at least one ontology capability captured by a first one of said multiple ontology schemas comprises said defined hierarchy.

13. The system of claim 10, wherein said at least one ontology capability captured by a second one of said multiple ontology schemas is an inheritance capability between two of said multiple virtual entities. 280372 /

14. The system of claim 10, wherein said at least one ontology capability captured by a third one of said multiple ontology schemas is a graph traversal capability between two of said multiple virtual ontology entities.

15. The system of claim 14, and wherein said graph traversal capability further captures transitivity from said two of said multiple virtual entities to a third one of said multiple virtual entities.

16. The system of claim 14, and wherein said at least one ontology capability further includes a reverse flow of said graph traversal capability.

17. The system of claim 10, wherein said at least one ontology capability further comprises a logic calculation with respect to at least one of said multiple virtual entities.

18. The system of claim 10, wherein each one of said multiple ontology schemas has a corresponding logic, wherein rewriting said first relational query as said second relational query comprises applying said logic corresponding to said targeted one of said multiple ontology schemas.

19. A method for extracting ontological knowledge from a relational database with a relational query, comprising: receiving a virtual ontology, comprising: a hierarchy of multiple virtual entities, multiple corresponding mappings associating each of said multiple virtual entities with at least a subset of at least one of multiple physical tables of said relational database, thereby introducing data stored in said relational database to said virtual ontology, an ontology metadata database storing said hierarchy of multiple virtual entities with said multiple corresponding mappings, and multiple ontology schemas, each providing a different relational view of said virtual ontology and capturing at least one ontology capability; submitting a first relational query targeting one of said multiple ontology schemas; 280372 / querying said ontology metadata database with at least a parsed portion of said first relational query to rewrite said first relational query as a second relational query with respect to a relational schema for said relational database; and executing said second relational query at said relational database to extract ontological knowledge from said data that is opaque with respect to said relational schema, said ontological knowledge expressing said at least one ontology capability captured by said targeted one of said multiple ontology schemas, thereby extracting said ontological knowledge within a relational framework.

20. The method of claim 19, wherein said multiple virtual entities comprise concepts and properties, wherein each said defined concept includes at least one of said properties.

21. The method of claim 19, wherein said at least one ontology capability captured by a first one of said multiple ontology schemas comprises said defined hierarchy.

22. The method of claim 19, wherein said at least one ontology capability captured by a second one of said multiple ontology schemas is an inheritance capability between two of said multiple virtual entities.

23. The method of claim 19, wherein said at least one ontology capability captured by a third one of said multiple ontology schemas is a graph traversal capability between two of said multiple virtual entities.

24. The method of claim 23, and wherein said graph traversal capability further captures transitivity from said two of said multiple virtual entities to a third one of said multiple virtual entities.

25. The method of claim 23, and wherein said at least one ontology capability further includes a reverse flow of said graph traversal capability. 280372 /

26. The method of claim 19, wherein said at least one ontology capability further comprises a logic calculation with respect to at least one of said multiple virtual entities.

27. The method of claim 19, wherein each one of said multiple ontology schemas has a corresponding logic, wherein rewriting said first relational query as said second relational query comprises applying said logic corresponding to said targeted one of said multiple ontology schemas. Agent for this Application Korakh & Co. Jonathan Rossner Patent Attorney