Processing of logic rules in sparql query engine

Abstract

To provide a computer-implemented method for processing logical rules, in particular, in a graph database.SOLUTION: A method includes: providing a graph database comprising at least one graph, each graph of the database being represented in one or more adjacency matrices (R-Matrix), each adjacency matrix representing a group of tuples of the graph comprising the same predicate; providing logic rules to reach to a head predicate; generating a virtual adjacency matrix comprising one of the one or more adjacency matrices (R-Matrix) and an entailed data matrix (E-Matrix), the virtual adjacency matrix representing the head predicate, the entailed data matrix representing a group of tuples that are computed by applying the logic rule; and receiving a query by the database using the head predicate.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to the field of computer programs and systems, and more specifically, to a method, system, and program for processing logical rules in a graph database.

Background Art

[0002] Multiple systems and programs are available on the market for the design, engineering, and manufacturing of objects. CAD is an acronym for Computer-Aided Design, and refers to software solutions for designing objects, for example. CAE is an acronym for Computer-Aided Engineering, and refers to software solutions for simulating the physical behavior of future products, for example. CAM is an acronym for Computer-Aided Manufacturing, and refers to software solutions for defining manufacturing processes and operations. In the computer-aided design systems described above, graphical user interfaces play a crucial role in the efficiency of the techniques. The techniques described above can be embedded within Product Lifecycle Management (PLM) systems. PLM, across the concept of an extended enterprise, refers to a business strategy that helps a company share product data, apply common processes, and leverage corporate knowledge for product development from conception to the end of its service life. PLM solutions offered by Dassault Systèmes (under the trademarks CATIA, ENOVIA, and DELMIA) provide an "Engineering Hub" for organizing product engineering knowledge, a "Manufacturing Hub" for managing manufacturing engineering knowledge, and an "Enterprise Hub" that enables the integration and linking of an enterprise to both the Engineering Hub and the Manufacturing Hub. Together, the system provides an open object model that links products, processes, and resources, enabling dynamic knowledge-based product creation and decision support that facilitates optimized product definition, manufacturing readiness, production, and service.

[0003] In particular, graph databases are well-suited to applications that interact with databases, such as CAD software and many creative authoring applications. These applications are often implemented using in-memory databases, i.e., purpose-built databases that rely primarily on memory for data storage, in contrast to databases that store data on disk or SSDs. Performing some reasoning on knowledge represented and / or stored in graph form, that is, inferring new facts from existing facts, is even more useful. This reasoning estimates new information by applying logical rules to the knowledge base represented as a graph by the inference engine. Furthermore, the inference process may iterate over new facts in the knowledge base, triggering additional rules in the inference engine. The inference engine was designed to handle the automated management of knowledge rules. Using knowledge rules makes the system design clearer by allowing some of the information stored in the graph to be factorized (i.e., compressed) so that it is no longer needed to be repeated. The factorized information is no longer explicitly represented in the graph, but can be derived through inference.

[0004] In the field of databases, the foundation of database theory is based on first-order logic. First-order logic constitutes relational calculus (and SQL), but without recursion. In the late 1990s, database research moved away from recursive queries due to their high performance cost. The documents Abiteboul et al., "Foundations of Databases," Addison-Wesley, 1995, Vol. 8, and Green et al., "Datalog and Recursive Query Processing," Now Publishers, 2013, describe research using Datalog as an attempt to add recursion to the positive (i.e., non-negative) part of relational calculus.

[0005] In recent years, recursive queries have become widespread in various application areas, such as data integration and exchange, information extraction, networking, and program analysis. Nevertheless, the methods described above are complex at the query level, difficult to implement, expensive in terms of performance, or require a dedicated query engine.

[0006] Within the circumstances described above, there is still a need for improved methods for handling logical rules in graph databases. [Overview of the Initiative]

[0007] Therefore, a method for computer implementation to process logical rules in a graph database is provided. The method includes the following:

[0008] - Provide a graph database containing at least one graph, where each graph in the database is represented by one or more adjacency matrices (R-matrixes), and each adjacency matrix represents a group of graph tuples containing the same predicate. - To provide logical rules that reach the head predicate. - Generate a virtual adjacency matrix containing one or more adjacency matrices (R-Matrix) and an entailed data matrix (E-Matrix), where the virtual adjacency matrix represents head predicates and the entailed data matrix represents groups of tuples computed by applying logical rules, and - Receiving queries via a database that uses head predicates.

[0009] The methods may include one or more of the following:

[0010] - The virtual adjacency matrix further includes an update processor, which is configured to update the entered data matrix when the head predicate is corrected. - A set of logic rules consists of one or more logic rules, each of which is at most a first-order logic rule. -The logical rule is expressed as a linear recursive query. - The generation of the entered data matrix includes forward chaining techniques. - The group of tuples in the graph represented by each adjacency matrix is ​​a non-inferred tuple. - The graph database is an RDF graph database, and each tuple is either an RDF triple containing a subject, predicate, and object, or an RDF quad consisting of a subject, predicate, object, and graph name. - The provided logical rule is an RDFS rule. - The provided logical rule is a default attribute rule configured to return a default value for the object or subject of at least one RDF tuple. - Receiving queries by a database using head predicates includes receiving queries by a SPARQL query engine. - Answering incoming queries using the SPARQL query engine.

[0011] Furthermore, a computer program containing instructions for performing the method is provided.

[0012] Furthermore, a computer-readable recording medium on which a computer program is stored is provided.

[0013] Furthermore, a system is provided that includes a processor coupled to memory, where the memory stores computer programs.

[0014] An example of non-limitation will be immediately explained with reference to the attached drawings. [Brief explanation of the drawing]

[0015] [Figure 1] This figure shows a flowchart illustrating an example of a method according to one aspect of the present invention. [Figure 2] This figure shows an example of reasoning according to one aspect of the present invention. [Figure 3]This figure shows an example of an RDFS entailment pattern according to one aspect of the present invention. [Figure 4] This figure shows a semantic representation of a virtual adjacency matrix according to one aspect of the present invention. [Figure 5] This figure shows an example of a forward chain technique according to one aspect of the present invention. [Figure 6] This figure shows an example of a system according to one aspect of the present invention. [Modes for carrying out the invention]

[0016] Referring to the flowchart in Figure 1, a method for computer implementation to process logical rules in a graph database is proposed. The method includes providing a graph database containing at least one graph, where each graph in the database is represented by one or more adjacency matrices (also denoted as R-matrices). Each adjacency matrix represents a group of graph tuples containing the same predicate. Furthermore, the method includes providing a logical rule that reaches a head predicate S20 and generating a virtual adjacency matrix containing one of the one or more adjacency matrices (i.e., an R-matrix) and an entailed data matrix (or E-matrix) S30. The virtual adjacency matrix represents the head predicate. The entailed data matrix represents a group of tuples computed by applying the logical rule. Furthermore, the method includes receiving a query by the database using the head predicate S40.

[0017] The method constructs an improved solution when processing logical rules in the graph space by considering an R-matrix representing a database and an E-matrix representing a group of tuples calculated by applying logical rules. In other words, the method improves the processing by separating the required information already available in the form of the adjacency matrix of the database and the information that needs to be calculated and updated in the inference process by applying logical rules. Therefore, the query engine of the database can use a virtual adjacency matrix without adding additional complexity and even without knowing the logical rules as a standard adjacency matrix for answering queries. Furthermore, the method is beneficial because it can use custom logical rules for inferring knowledge from the database in addition to well-known rules, such as RDFS (i.e., RDF Schema) rules defined based on the semantics set by the W3C (World Wide Web Consortium). The rules are given in RDF 1.1 Semantics, the W3C Recommendation of February 25, 2014 (or additionally, the draft version RDF-star). As is known per se, RDFS is a set of classes having some properties using an RDF-extensible knowledge representation data model and provides the basic elements for the description of ontologies.

[0018] Specifically, the method is to optimize the processing of logical rules expressed as linear recursive queries in a SPARQL query engine with respect to the calculation time of the processing without adding high complexity for the implementation in the query engine.

[0019] The term "database" refers to any collection of data (i.e., information) organized for retrieval and searching (e.g., a graph-oriented database). As those skilled in the art know, a graph-oriented database is an object-oriented database that uses graph theory and therefore has vertices (i.e., nodes) and edges (i.e., arcs) that allow data to be represented and stored. The graph relates data items in the store to a collection of vertices and edges, with edges representing relationships between nodes. Relationships allow data in the store to be directly linked to each other and can often be retrieved in a single operation. Unlike other database models (e.g., relational databases) that link data through implicit connections, graph databases maintain relationships between data as priority. When stored in memory, graph databases enable fast retrieval and retrieval by computers. In particular, graph databases are configured for fast retrieval, modification, and deletion of relationships in cooperation with various data processing operations. Furthermore, a graph-oriented database is also called a graph database, and the expressions "graph-oriented database" and "graph database" are synonymous.

[0020] In the example, the graph database could be an RDF graph database. An RDF graph is a traditional data model used for storing and retrieving graphs. An RDF graph is a directed, labeled graph data format. This format is widely used to represent information on the Web. The standard specification is published by the W3C and defines the RDF representation of information as a graph; see, for example, "RDF 1.1 Concepts and Abstract Syntax," W3C Recommendation February 25, 2014. The core structure of the abstract syntax used is a set of tuples, each containing a predicate. The set of RDF tuples described above is called an RDF graph. In the example, an RDF tuple may contain three or four elements, including nodes and edges. In the example, each RDF tuple (or each element of an RDF tuple) may be a triple containing a subject, predicate, and object. In the example above, the RDF graph may be visualized as a node-arc-node linked, directed, labeled graph. Alternatively, an RDF triple may be visualized as two nodes, the subject and object, connected by an arc, which is the predicate. In the example, the RDF tuple may be an RDF quad. The standard for defining RDF Quads (also known as N-Quads) is published by the W3C; see, for example, "RDF 1.1 N-Quads, A line-based syntax for RDF datasets," W3C Recommendation February 25, 2014. An RDF quad may be obtained by adding a graph name to an RDF triple. The graph name can be either empty (i.e., for default or unnamed graphs) or an IRI (e.g., a predicate). The graph name of each quad is the graph that the quad is part of in the dataset. In the following, the term RDF tuple (or tuple) refers to either an RDF triple or an RDF quad unless the use of one or the other is explicitly stated.

[0021] An RDF graph database may have billions of tuples. For example, the Uniprot dataset is a resource of protein sequences and functional information.

[0022] By "logical rules" (sometimes referred to equivalently as "inference rules" or "knowledge rules"), a deductive mechanism is meant that states a conclusion (referred to equivalently as the "head" of the rule) that is true when the premise (referred to equivalently as the "body" of the rule) is true. The head of a logical rule is a predicate sometimes referred to equivalently as a "head predicate". In other words, the head predicate defines the output of interest of the corresponding query of the database. By "processing logical rules in a graph database", the application of logical rules to the graph stored in the database is meant in order to infer new information.

[0023] Referring to FIG. 1, in step S10, the method includes providing a graph database that includes at least one graph. By "providing a graph database", it means obtaining a graph database. Therefore, the computer system can perform read and / or write and / or execution operations on the obtained graph database. Obtaining a graph database can be retrieving the graph database from remote memory or local memory, persistent memory or non-persistent memory. Each graph of the database is represented by one or more adjacency matrices (also referred to as R-matrices). An adjacency matrix is a square matrix used to represent a finite graph. The elements of the matrix indicate whether a pair of vertices is adjacent or not in the graph. Thus, each adjacency matrix represents a group of tuples of a graph that contain the same predicate.

[0024] In the example, the above groups of graph tuples represented by each adjacency matrix can be non-inferred tuples, or (as they are equivalently called) ground tuples. Ground tuples are tuples that explicitly exist (i.e., are stored) in the database. In other words, each R-matrix (adjacency matrix) represents a group of graph tuples in the provided graph database that are not obtained by database inference (i.e., deducement). The groups of tuples in each R-matrix contain (i.e., share) the same predicates. In other words, the groups of tuples group (i.e., partition) the provided graph database according to the graph predicates. The above partitioning is beneficial in graph databases, for example in RDF graph databases, because it results in low predicate variation and is particularly compatible with standard graph representations based on vertical partitioning (see, for example, Abadi et al., "Scalable semantic web data management using vertical partitioning," Proceedings of the 33rd International Conference on Very Large Databases, 2007, pp. 411-422). Still referring to Figure 1, in step S20, the method further includes providing a logical rule that reaches the head predicate. By "providing a logical rule," it means, for example, that the user sets the logical rule or that the logical rule is taken from a library (e.g., a W3C recommendation). By "the logical rule reaches the head predicate," it means that the logical rule infers information in the state of application to the provided graph database, i.e., that the new graph deduces the information of the head predicate, i.e., the head of the provided logical rule. In other words, applying logical rules to graph data deduces (i.e., infers) new information about the type of head predicate.Furthermore, head predicates are sometimes referred to as "distinguished query predicates," and are the output of the corresponding query that the head predicate is of interest.

[0025] In the example, the provided logic rules may consist of one or more sets of logic rules, each of which is at most a first-order logic rule. In other words, each provided logic rule may be rewritten as one or more sets of first-order logic rules.

[0026] In the example, the provided logical rule is expressed as a linearly recursive query, meaning the head predicate appears only once in the body of the provided logical rule.

[0027] In the example, the provided logical rule is an RDFS rule. For example, the provided rule is an RDFS9 rule in W3C semantics, which may be defined as follows: Type(z,y) ← Type(z,x),SubClassOf(x,y) The conclusion "Type(z,y)" (i.e., z is of type y) is read as true if the premises "Type(z,x)" (i.e., z is of type x) and "SubClass0f(x,y)" (i.e., class x is a subclass of y) are true. In notation, the comma "," signifies logical AND. The rule is linearly recursive because "Type" is at the beginning of the rule and in the body of the rule.

[0028] In the example, the provided logical rule could be an evaluation of a class with default attributes or a security rule. In particular, the provided logical rule could be a default attribute rule configured to return a default value for the object or subject of at least one RDF tuple. The processing of logical rules expressed as linearly recursive queries in the SPARQL query engine according to the present invention is not limited to RDFS rules as a result.

[0029] Returning to Figure 1, in step S30, the method generates (calculates) a virtual adjacency matrix that includes one or more adjacency matrices and an entailed data matrix or an entailed data matrix in which the E-matrix represents the head predicates. By "representing the head predicates," the E-matrix is ​​meant to compute the conclusion of the given logical rule, i.e., the head predicates. In other words, each E-matrix is ​​computed in correspondence with the conclusion of the logical rule. The E-matrix represents a group of tuples computed by applying the logical rule. In other words, the E-matrix represents the result of inference in the graph database by applying the given logical rule to infer new information, i.e., new tuples other than the grand tuples. The virtual adjacency matrix represents the adjacency matrix for the identified query predicates, i.e., the output of interest.

[0030] In the example, generating an entered data matrix may involve a forward chaining technique. As is known by itself, "forward chaining"—or equivalently a bottom-up approach or semi-naive algorithm—is a technique for deriving new tuples from uninferred tuples. Forward chaining can be performed by any known method. What has just been said improves the facility and response time of the method implementation.

[0031] In an example of generating an entailed data matrix, the method might involve materializing the query results in an E-matrix of head predicates. In the above example, generating an entailed data matrix is ​​sometimes compared to computing a materialized view in a relational database. As is known, a "materialized view" is a database object containing the results of a query. The query can be any query that uses head predicates.

[0032] In the example, the virtual adjacency matrix may further include an update processor. The update processor is configured to update the entered data matrix when the head predicate is modified, meaning that "modifying the head predicate" refers to the case of modification of the corresponding query for the head predicate. The above modification of the head predicate is a result of modification of the predicate in the body of the rule, i.e., the head predicate is not modified directly (it results in modification of the R-matrix). The above modification is similar to modifying the EDB (i.e., extended database predicate) corresponding to the source table in the database from which the materialized view is computed for an SQL database. In the example, the virtual adjacency matrix update processor updates the E-matrix of the virtual adjacency matrix when the head predicate changes.

[0033] Returning to Figure 1, in step S40, the method further includes receiving the query by the database using head predicates. In the example where the graph database is an RDF graph database, the received query may be a SPARQL query. SPARQL is a query language for RDF data that can express queries across a variety of data sources, whether the data is stored natively as RDF or viewed as RDF through middleware. SPARQL includes the ability to query the required graph pattern and optional graph patterns, along with conjunctions and disjunctions. Furthermore, SPARQL also supports creating values ​​by aggregation, subqueries, negation, and representation, extensible value testing, and constraining queries by the source RDF graph. The result of a SPARQL query may be a result set or an RDF graph. For example, receiving a query by a database using head predicates is equivalent to receiving a query by a SPARQL query engine. The received query may be any of the standard SPARQL queries.

[0034] In the example, the method may further involve the SPARQL query engine answering the received query.

[0035] The method is implemented on a computer. What has been stated means that the steps of the method (or substantially all of them) are performed by at least one computer, or any similar system. Thus, the steps of the method are performed by the computer, possibly fully automatically or semi-automatically. In the example, at least some of the triggers for the steps of the method may occur through user-computer interaction. The required level of user-computer interaction may depend on the expected level of automation and be balanced with the need to implement the user's desires. In the example, the levels mentioned may be user-defined and / or predefined.

[0036] A typical computer implementation of a method is to perform the method using a system adapted for the purpose described above. The system may include a processor coupled with memory and a graphical user interface (GUI), where memory stores computer programs containing instructions for performing the method. Furthermore, memory may also store a database. Memory is any hardware adapted to the storage described above, and may include several physically distinct parts (e.g., one for the program and possibly one for the database).

[0037] Figure 6 shows an example of a system, where the system is a client computer system, such as a user's workstation.

[0038] The client computer in this example includes a central processing unit (CPU) 1010 connected to an internal communication bus 1000, and random access memory (RAM) 1070 further connected to the bus. Furthermore, the client computer is provided having a graphics processing unit (GPU) 1110 associated with video random access memory 1100 connected to the bus. The video RAM 1100 is also known to those skilled in the art as a frame buffer. A mass storage device controller 1020 manages access to mass memory devices, such as a hard drive 1030. Mass memory devices suitable for tangibly embodying computer program instructions and data include, for example, semiconductor memory devices such as EPROMs, EEPROMs, and flash memory devices, and all forms of non-volatile memory, including magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and CD-ROM disks 1040. Any of the foregoing may be complemented or incorporated by specially designed application-specific integrated circuits (ASICs). A network adapter 1050 manages access to the network 1060. Furthermore, the client computer may also include haptic devices 1090, such as a cursor control device, a keyboard, or equivalent. The cursor control device is used in the client computer to allow the user to selectively place the cursor at any desired position on the display 1080. In addition, the cursor control device allows the user to select various commands and input control signals. The cursor control device includes some signal generating devices to input control signals to the system. Typically, the cursor control device is a mouse, and the mouse buttons may be used to generate signals. Alternatively, or in addition, the client computer system may include a sensitive pad and / or a sensitive screen.

[0039] A computer program includes instructions that can be executed by a computer, and the instructions may include means for causing the system to perform a method. A program may be recordable on any data recording medium, including the system's memory. A program may be implemented, for example, in a digital electronic circuit, or in computer hardware, firmware, software, or a combination thereof. A program may be implemented as a device, for example, as a tangible product embodied in a machine-readable storage device for execution by a programmable processor. A method step may be performed by a programmable processor executing a program of instructions that perform the function of the method by manipulating input data and generating an output. Thus, a processor may be programmable and coupled to receive data and instructions from a data storage system, at least one input device, and at least one output device, and to transmit data and instructions. An application program may be implemented in a high-level procedural programming language or an object-oriented programming language, or, if desired, in assembly language or machine language. In any case, the language may be a compiled language or an interpreted language. A program may be a full installation program or an update program. The application of a program to a system always boils down to instructions for performing a method.

[0040] Regarding the method, an example of implementing the example described above will be immediately described in this specification.

[0041] An example of an implementation of the present invention is processing logical rules expressed as linearly recursive queries in a SPARQL query engine. It should be understood that the logical rules are not limited to RDFS (RDF Schema) rules (for example, the "default attribute" rule described below).

[0042] Furthermore, an example of implementation relates to SPARQL queries. As mentioned earlier, SPARQL is a W3C recommendation for querying RDF, a graph matching language built on top of the triple pattern of RDF triples. The W3C specification defines the syntax and semantics of the SPARQL query language for RDF. SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF through middleware. SPARQL includes the ability to query required and optional graph patterns, along with conjunctions and disjunctions. In addition, SPARQL also supports creating values ​​by aggregation, subqueries, negation, and representation, extensible value testing, and constraining queries by source RDF graphs. The result of a SPARQL query can be a result set or an RDF graph.

[0043] Further implementation examples relate to using logical rules to infer knowledge in a database, that is, to deduce new facts from existing facts. Inference can be performed using RDFS inference, as shown in Figure 2. In Figure 2, RDFS rule 210 states that class Man215 (referring to a set of resources) is a subclass (subset) of class Person225 (referring to another set of resources), while RDF triple 220 states that Fabian235 is Man240 (in terms of type). It is not necessary to use RDFS rule 210 to say that Fabian235 is both Man240 and Person225, because this fact can be derived (inferred) from the fact that Fabian235 is Man240 and the fact that Man240 is a subclass of Person225, and therefore Fabian235 is Person225. In this way, inference and RDFS rules eliminate repetition in the database. The above rules can be considered first-order predicate logic rules.

[0044] The RDFS Entailment pattern is shown in Figure 3 according to the RDFS9 rule of W3C semantics. The rule states that if the premises xxx rdfs:subClassOf yyy (i.e., xxx is a subclass of yyy) and zzz rdf:type xxx (i.e., zzz is of type xxx) are true, then the conclusion zzz rdf:type yyy (i.e., zzz is of type yyy) is therefore true. RDFS9 can be expressed as linear recursion. Type(z,y) ← Type(z,x),SubClassOf(x,y) The conclusion "Type(z,y)" (i.e., z is of type y) is read as true if the premises "Type(z,x)" (i.e., z is of type x) and "SubClass0f(x,y)" (i.e., class x is a subclass of y) are true. In notation, the comma "," signifies logical AND. The rule is linearly recursive because "Type" is at the beginning of the rule and in the body of the rule.

[0045] An example of a "default attribute" will be given immediately.

[0046] Consider the following RDF dataset (Example A). @prefix rdf:<http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#> . @prefix rdfs:<http: / / www.w3.org / 2000 / 01 / rdf-schema#> . @prefix ex:<http: / / www.example.org#> . @prefix er:<https: / / www.3ds.com / er / > . er:ProductAbstract a rdfs:Class. er:VPMReference a rdfs:Class. er:DomainSpecificRef a rdfs:Class. er:VPMReference rdfs:subClassOf er:ProductAbstract. er:DomainSpecificRef rdfs:subClassOf er:VPMReference. ex:attr10 rdfs:domain er:ProductAbstract. ex:attr10 rdfs:subPropertyOf er:Attribute. ex:attr10 er:defaultValue "attr10DefaultValue". ex:instance1 a er:DomainSpecificRef. ex:instance1 ex:attr11 "specificValue4". Furthermore, using a query engine that is aware of RDFS and the "default attribute" logical rule, as a SPARQL query, select ?attr ?value where { ex:instance1 ?attr ?value. ?attr rdfs:subPropertyOf er:Attribute. } The SPARQL query returns the following result: <http: / / www.example.org#attr10> "attr10DefaultValue" <http: / / www.example.org#attr11> "specificValue4" The value of attr10 is to be fetched in the ProductAbstract class. In addition to the RDFS rules, the implementation may have the following "default attribute" rule, which is a prerequisite for the RDFS rules. er:Attribute.# a constant DefaultAttr(A,v) <- SubProperty(A,er:Attribute),DefaultValue(A,v) . A(i,v) <- DefaultAttr(A,v),Domain(A,p),Type(i,P). Therefore, applying the default attribute rule, matching A to http: / / www.example.org#attr10> and i to ex:instance1, gives the output "attr10DefaultValue" as v. In particular, the RDFS rule is further applied to the Type (as in "RDF 1.1 Concepts and Abstract Syntax"). The predicate DefaultAttr may not be materialized, in which case the rule may be rewritten as follows: A(i,v) <- SubProperty(A,er:Attribute),DefaultValue(A,v),Domain(A,p),Type(i,P) . Implementations may consider only linear recursion rules, i.e., the recursive predicate appears only once in the rule body. As those skilled in the art know, linear recursive queries for relational calculus may use Datalog. Several known approaches to handling linear recursive queries are immediately described.

[0047] The bottom-up approach sometimes uses a semi-naive algorithm to derive a new tuple from a grand tuple. While this approach is easy to implement in a query engine, it doesn't minimize the derivation of tuples that aren't needed when answering queries. Because it involves unnecessary work, it adds cost to the output. In the example above, the database tuple (i.e., the grand tuple) with the predicate "link" is: link(a,b), link(b,c), link(c,c), link(c,d) The query is defined as follows: r1 reachable(X,Y) :- link(X,Y) r2 reachable(X,Y) :- reachable(X,Z), link(Z,Y) query(Y) :- reachable(b,Y) The identified query predicate (i.e., head predicate, or output of interest) is a reachable table. The output is constrained to a constant b, indicating that the query is only interested in tuples reachable to node b. Limiting the output set affects the relative overhead of using a bottom-up versus top-down evaluation technique. The semi-naive computation is performed three times, as depicted in Figure 5.

[0048] The bottom-up approach is easy to implement, but it has performance issues due to the excessive computation required.

[0049] The top-down approach aims to derive only the tuples corresponding to the query by starting the evaluation from the query itself and pushing selection criteria (i.e., constants) from the query into rules. Top-down evaluation is a proof tree search for the query. A typical method of the approach described above is called QSQ (Query / SubQuery).

[0050] The top-down approach is efficient because it derives only the tuple corresponding to the query, but it is complex and requires a dedicated query engine.

[0051] In the literature, the bottom-up approach is also called forward chaining, and the top-down approach is also called backward chaining. The terms forward chaining and backward chaining are commonly used in reference to RDF inference engines.

[0052] Standard linear recursive query processing methods have several drawbacks. While processing can employ simple strategies similar to the bottom-up approach described above, these are inefficient and derive too many tuples. Alternatively, processing can employ complex strategies similar to the top-down approach, adding complexity to the query engine (or requiring a dedicated query engine). The added complexity of the top-down approach during query execution can limit its usability and hinder its use in interactive applications.

[0053] A common solution in SQL databases is to use materialized views. A materialized view is a database object that contains the results of a query. Materialized views can be used to improve the performance of Datalog programs that frequently perform complex queries. If a materialized view is an EDB (i.e., an Extended Database Predicate) corresponding to the source tables in the database, calculated from changes, then the materialized view needs to be maintained to reflect those changes. Therefore, efficient maintenance of materialized views is a crucial aspect of underpinning performance benefits. However, materialized views in conventional technologies are specific to the tabular approach, and there are no materialized views in the representation of data as a graph.

[0054] Known RDF entailment engine implementations follow similar patterns to the bottom-up and top-down approaches described above. The term "entailment engine" here refers to the RDFS entailment inference engine. As stated in "RDF 1.1 Semantics, W3C Recommendation," model theory for RDF and RDFS includes some entailments that should be generated by the RDF inference engine. Existing systems generate these in several ways, but the most common approach employs a production rule system that generates the required entailments either through forward chaining from asserted facts or backward chaining from queries given to the system.

[0055] Both approaches described above have advantages and disadvantages. A pure forward-chaining system applies the entailment rules from model theory exhaustively to asserted facts to generate an RDF closure (deductive closure) of the facts. Enthusiastic evaluation of the deductive closure (as performed by systems such as Sesame) has the effect of reducing the processing cost of evaluating the query. Entailments returned by the query (in addition to any ground facts) are generated earlier in time and can reduce the time it takes to evaluate the query in some cases. What has been described above is advantageous for interactive applications where fast response times are critical. The disadvantage of these approaches is that the RDF closure may contain many entailments that are several times the size of the asserted facts and only occasionally match the query.

[0056] Conversely, a pure backward chaining system evaluates the entailments matched by the query during query processing time. This reduces the cost of storing entailments because only what is needed is generated, at the cost of more expensive query processing. However, backward chaining systems that evaluate entailments may suffer a time penalty that makes them unsuitable for use in interactive applications. While the cost of repeated queries can be reduced by caching the generated entailments, a significant cost to query time still exists.

[0057] Typical query engines employ a hybrid approach where some entry rules—usually those that generate fewer entry rules—are evaluated using forward-chaining rules as new facts are asserted. Meanwhile, entry rules with higher storage costs and lower evaluation costs are evaluated as needed in query time, using a combination of backward chaining and query rewriting. The hybrid approach has several drawbacks. While the hybrid strategy combining forward chaining, backward chaining, and query rewriting allows SPARQL query engines to evaluate RDFS rules fairly efficiently, it is a custom strategy specifically for RDFS rules that cannot be directly applied to more general rules, such as the "default attribute" or "reachable" rules mentioned above.

[0058] An example of an implementation of the present invention may be envisioned when inspired by a materialized view approach used in SQL query engines, instead of adding extra complexity to a SPARQL query engine similar to the Query / SubQuery strategy known in the art, see the previously cited document Green et al., "Datalog and recursive query processing," Now Publishers, 2013. However, materialized views are tabular objects and do not exist in the graph paradigms of SPARQL and RDF. An example implementation represents an RDF graph using vertical partitioning where each predicate is an adjacency matrix. Thereafter, in the same spirit as for views for tabular data, the implementation defines a virtual adjacency matrix that represents the adjacency matrices of the identified query predicates (i.e., the outputs of interest).

[0059] For example, the following default attribute rules DefaultAttr(A,v) <- SubProperty(A,er:Attribute),DefaultValue(A,v) . A(i,v) <- DefaultAttr(A,v),Domain(A,p),Type(i,P) . In addition to "concrete" adjacency matrices such as subPropertyOf and DefaultValue, there is also a virtual adjacency matrix for A, depending on the implementation. The virtual adjacency matrix works as if all triples were derived as in the semi-naive approach, and the contents of the matrix can answer the aforementioned rules, including RDFS rules, "default attribute", and "reachable" rules.

[0060] An example of implementation will be immediately given for the "default attribute" example mentioned above.

[0061] In RDF triples, the subject (S), predicate (P), and / or object (O) can each be variables in the query. What has just been said means that a SPARQL query must answer one of eight different triple patterns possible in SPARQL. The eight triple patterns above include (S,P,O), (S,?P,O), (S,P,?O), (S,?P,?O), (?S,P,O), (?S,?P,O), (?S,P,?O), and (?S,?P,?O), where the symbol ? precedes the variable in the pattern. The variable is the output of the SPARQL query, used as an intermediate result (e.g., handling joins), or helps to form the query but has no particular use. In some examples, SPARQL may build more complex queries (commonly called Basic Graph Patterns or BGPs) by joining sets of triple patterns.

[0062] In implementation examples, the query engine may use the above eight patterns as basic building blocks. The RDF graph may be represented as a set of adjacency matrices, i.e., one adjacency matrix for each predicate. Then, answering triple patterns may be viewed as pattern matching of one or more adjacency matrices, each representing a predicate. Given the “default attribute” rule defined as follows, DefaultAttr(A,v) <- SubProperty(A,er:Attribute),DefaultValue(A,v) . A(i,v) <- DefaultAttr(A,v),Domain(A,p),Type(i,P) The following predicates exist: DefaultAttr, SubProperty, DefaultValue, A, Domain, and Type, where Domain means rdf:domain, Type means rdf:type, and SubProperty means rdfs:subProperty. The identified query predicate, i.e., the output of interest, is predicate A in the rule. In example A above, the identified query predicate may be translated as ex:attr10 in RDF.

[0063] Therefore, the goal of the implementation example is to be able to efficiently answer the following patterns: ex:instance1 ex:attr10 ?v The output "attr10DefaultValue" (see Example A) is thanks to the "default attribute" rule. The pattern ex:instance1 ex:attr10 ?v is the pattern (S,P,?O) applied to the adjacency matrix P=ex:attr10 where subject S is set to ex:instance1 (i.e., restrained).

[0064] The predicate ex:attr10 may have a ground triple (i.e., a triple that is not inferred). According to implementation examples, the predicate's ground triple may form its own adjacency matrix, the so-called "raw data matrix" (or R-matrix). In comparison to SQL databases, the R-matrix is ​​part of the EDB (Extensional Database predicates), i.e., the source tables of the database.

[0065] The SQL database requires a materialized view of the rule's results. The results of the above rule are updated when the EDB (of the SQL database) changes. An example implementation defines an "entailmented data matrix" (or E-matrix) as an adjacency matrix for the predicate ex:attr10, which is made for all triples that are the result of applying the "default attribute" rule. The example implementation builds the E-matrix using the forward chaining technique. The forward chaining technique, as is known by itself, applies rules from model theory exhaustively to asserted facts (of the database) to generate an RDF closure (deductive closure) of the facts.

[0066] Applying the forward chaining technique to the example "default attribute" rule as follows: DefaultAttr(A,v) <- SubProperty(A,er:Attribute),DefaultValue(A,v), A(i,v) <- DefaultAttr(A,v),Domain(A,p),SubClassOf(i,P), An example implementation would be to execute the following SPARQL query, which is a translation of the rule above: select ?i ?attr ?v where { ?attr er:DefaultValue ?v . ?attr rdfs:subPropertyOf er:Attribute . ?attr rdfs:domain ?p . ?irdfs:subClassOf ?p. } The results of the SPARQL query are materialized in the E-matrix for each predicate ?p (and especially in ?p==ex:attr10). The query described above is too costly to use for query rewriting. The predicate of the above query, i.e., the SQL EDB. er:DefaultValue,rdfs:subPropertyOf,rdfs:domain And when rdfs:subClassOf is changed, the example implementation updates the E-matrix as a materialized view in SQL accordingly. The example implementation performs the above update using a so-called "Update Processor".

[0067] The R-matrix, E-matrix, and update processor together form a virtual adjacency matrix configured to answer eight triple patterns of SPARQL according to defined rules. A schematic diagram of the virtual adjacency matrix is ​​shown in Figure 4, where the virtual adjacency matrix 410 includes the R-matrix 420, E-matrix 430, and update processor 440 to answer eight triple patterns of SPARQL 450.

[0068] The implementation example makes maximum use of the virtual adjacency matrix, as if all triples were derived by a bottom-up approach, as in the case of a semi-naive approach, as described above. In other words, taking the sample data as described above, the following query is: select ?attr ?value where { ?attr rdfs:subPropertyOf er:Attribute. ex:instance1 ?attr ?value. } The following result is returned. <http: / / www.example.org#attr10> "attr10DefaultValue", and <http: / / www.example.org#attr11> "formValue4" The first result comes from the E-matrix of ex:attr10, and the SPARQL query engine in the implementation example only finds the pattern ex:instance1 ex:attr10 ?value of the virtual adjacency matrix of the predicate ex:attr10.

[0069] Therefore, the SPARQL query engine in the example implementation can use a virtual adjacency matrix as a standard adjacency matrix to answer queries, without knowing the "default attribute" rules and thus without adding complexity. Thus, the example implementation can infer knowledge using custom logical rules in addition to the well-known RDFS rules.

[0070] The implementation example is advantageous because it avoids adding complexity to the query engine and simplifies E-matrix updates by having inference managed independently of the query engine by the data structure. In other words, there is no need to go through the query engine layer to update the E-matrix.

[0071] While RDFS rules include recursion, the "default attribute" rule described above does not. Limiting the present invention to linear recursive rules (i.e., recursive predicates appearing only once in the rule body) avoids the high cost of updating the E-matrix in example implementations. [Explanation of Symbols]

[0072] 1000 bus 1010 CPU 1020 Mass Storage Device Controller 1030 hard drive 1040 CD-ROM 1050 Network Adapter 1060 Network 1070 RAM 1080 display 1090 Haptic Devices 1100 video RAM 1110 GPU

Claims

1. 1. A computer-implemented method for processing logical rules in a graph database, comprising: - providing a graph database (S10) comprising at least one graph, each graph of said database being represented by one or more adjacency matrices (R-matrices), each adjacency matrix representing a group of tuples of said graph containing the same predicate; - providing said logic rules leading to a head predicate (S20); - generating (S30) a virtual adjacency matrix comprising one of said one or more adjacency matrices (R-matrix) and an entailed data matrix (E-matrix), said virtual adjacency matrix representing said head predicate and said entailed data matrix representing a group of tuples calculated by applying said logic rules; - receiving a query by said database using said head predicate (S40); A method comprising:

2. 2. The method of claim 1, wherein the virtual adjacency matrix further includes an update processor, the update processor configured to update the entailed data matrix when the head predicate is modified.

3. 2. The method of claim 1, wherein the logic rules include a set of one or more logic rules, each of which is at most a first-order predicate logic rule.

4. 4. The method of claim 3, wherein the logic rules are expressed as linear recursive queries.

5. 10. The method of claim 1, wherein the generating the entailed data matrix comprises a forward chaining technique.

6. 2. The method of claim 1, wherein the group of tuples of the graph represented by each adjacency matrix are non-inferred tuples.

7. The graph database is an RDF graph database, and each tuple is - an RDF triple containing a subject, predicate, and object, or - RDF quad containing subject, predicate, object, and graph name 2. The method of claim 1, wherein:

8. 8. The method of claim 7, wherein the provided logic rules are RDFS rules.

9. 8. The method of claim 7, wherein the provided logic rule is a default attribute rule configured to return a default value for an object or subject of at least one RDF tuple.

10. 7. The method of claim 6, wherein receiving a query by the database using the head predicate comprises receiving a query by a SPARQL query engine.

11. - Answering the received query by a SPARQL query engine (S50). The method of claim 10 further comprising:

12. A computer program comprising instructions for carrying out the method according to any one of claims 1 to 11.

13. A computer-readable recording medium having the computer program according to claim 12 recorded thereon.

14. 13. A system comprising a processor coupled to a memory, the memory having stored thereon the computer program of claim 12.

Images