Efficient shacl into SQL compiler

Abstract

A computer-implemented method that validates SHACL graphs on RDF graphs within a relational database system. SHACL graphs include shape-target pairs, where the shape represents a constraint a node must satisfy, and the target specifies which node to validate. RDF graphs consist of RDF terms, represented as nodes (subject, predicate, object) using IRIs, literals, or blank node identifiers. Each node is associated with a unique identifier, and relationships are stored in a relational database. The method compiles SHACL graphs into SQL expressions by converting them into negation normal form, applying negations to atomic constraints, and translating these into SQL using a lookup table. Validation is performed by executing SQL expressions on the database, ensuring each node satisfies the SHACL constraints.

Description

[0001] Efficient SHACL into SQL compiler

[0002] Field of Invention

[0003] The field of the invention relates to a computer-implemented method for validating one or more Shapes Constraint Language, SHACL, graphs.

[0004] Background

[0005] The current state of the art involves the use of the Shapes Constraint Language (SHACL) for expressing constraints on graph data. SHACL is a powerful language that allows for the specification of complex constraints, which are essential for ensuring data integrity and consistency in graph databases. These constraints can range from simple property checks to intricate conditions involving multiple nodes and relationships within the graph. The ability to define such detailed constraints is crucial for applications that rely on accurate and reliable data representation.

[0006] Despite its capabilities, the complexity of SHACL constraints poses significant challenges in terms of validation efficiency. As the complexity of the constraints increases, so does the computational effort required to validate them against graph data. This can lead to performance bottlenecks, especially in large-scale graph databases where the volume of data and the number of constraints are substantial. Efficient validation mechanisms are therefore critical to maintaining the performance and scalability of systems utilizing SHACL.

[0007] One of the primary disadvantages of the current state of the art is the inefficiency in validating complex SHACL constraints. The existing methods often require substantial computational resources and time, which can hinder the performance of applications relying on real-time data processing. This inefficiency can lead to delays and increased costs, making it difficult for organizations to leverage the full potential of SHACL in their data management processes.

[0008] Summary

[0009] It is therefore an objective of the present invention to provide a solution that enhances the efficiency of validating complex SHACL constraints on graph data, thereby improving performance and scalability in graph database applications.

[0010] According to a first aspect, a computer-implemented method is provided for validating Resource Description Framework (RDF) graphs against SHACL graphs, using relational database system technology. A computer-implemented method may be understood as a series of steps executed by a computer to achieve a specific outcome. SHACL graphs are used to define constraints on RDF data, while RDF graphs represent data in a structured format using nodes and relationships. It may be provided that the SHACL graphs comprise at least one shape-target parameter pair comprising a shape parameter representative for a constraint that a node of the RDF graph must satisfy and a target parameter representative for which node in the RDF graph should be validated against the shape parameter of said SHACL graph. A shape-target parameter pair is a combination of a constraint and a target node for validation. One advantage of this arrangement is that it allows precise targeting of nodes for validation, ensuring that only relevant data is processed, which optimizes the use of processing power and reduces unnecessary computations.

[0011] The method comprises representing the one or more RDF graphs in a relational database scheme by identifying, for each of the plurality of RDF terms, one or more nodes, wherein the nodes are at least one of a subject, predicate, and an object, wherein the subject and object are represented by at least one of an Internationalized Resource Identifier (IRI), a literal, or a blank node identifier, and the predicate is represented by a literal. Representing RDF graphs in a relational database scheme involves mapping RDF terms to database structures. This arrangement provides the advantage of leveraging relational database efficiencies, such as indexing and query optimization, which enhances storage capacity and retrieval speed. The method further comprises associating each node of the identified plurality of nodes with a unique node identifier and storing a relationship between the associated unique identifier and each node such that the RDF graphs are represented in a relational database scheme. A unique node identifier is a distinct reference for each node. This arrangement ensures efficient data retrieval and manipulation, as unique identifiers facilitate quick access and reduce ambiguity, improving processing power utilization. Compiling the one or more SHACL graphs into SQL expressions by converting the SHACL graph into a negation normal form (NNF) by applying negations only to atomic constraint components of the at least one shape-target parameter pair, and translating each atomic or negated atomic constraint into a SQL expression using a look-up table. SQL expressions are database queries that perform operations on data. This arrangement allows for efficient execution of constraints as SQL queries, and allows for optimizing processing power by minimizing the complexity of operations performed on the database. Further, the method comprises validating that a RDF graph conforms to a SHACL graph by executing the SQL expressions on the relational database scheme and identifying that each node satisfies the constraints defined by the at least one shape-target parameter pair of the SHACL graph. Validation ensures that data adheres to specified constraints. This arrangement provides the advantage of realtime validation, ensuring data integrity and consistency while more efficiently utilizing processing resources and maintaining system performance.

[0012] Preferably, the step of associating each node of the plurality of nodes with a unique identifier and storing the relationship between the associated unique identifier and each node, comprises at least one of

[0013] - storing all nodes that are IRIs as a first value attribute and relating it to the respective unique node identifier;

[0014] - storing all nodes that are blanks as a second value attribute and relating it to the respective unique node identifier;

[0015] - storing all nodes that are literals as a third value attribute and relating it to the respective unique node identifier;

[0016] - storing all the unique node identifiers as a fourth value attribute;

[0017] - storing a relationship between the first value attribute, the second value attribute and the third value attribute. This arrangement allows for efficient categorization and retrieval of nodes based on their type, enhancing data organization and access speed. By structuring data in this manner, the system can optimize storage capacity and improve processing efficiency, as each node type is distinctly managed and easily accessible.

[0018] Preferably, a node in an RDF graph meets the constraints if it satisfies all the conditions specified by the SHACL shapes, wherein the conditions to meet the constraints comprise at least one of a shape conformance, a property constraint, a logical condition, a cardinality constraint, a comparison constraint. This arrangement ensures comprehensive validation by covering various aspects of data integrity and consistency. By addressing multiple types of constraints, the system can effectively ensure that the data adheres to the specified requirements, thereby enhancing the reliability and accuracy of the data processing and storage.

[0019] Preferably, compiling the one or more SHACL graphs into SQL expressions comprises mapping atomic constrains, like sh:lessThan or sh:equals, to SQL comparisons or joins respectively; translating SHACL logical operators sh:and, sh:or and sh:not to SQL INTERSECT, UNION and NOT EXISTS operations, respectively; translating SHACL constraints involving counts, such as sh:minCount and sh:maxCount into GROUP BY and HAVING SQL aggregations, respectively. This arrangement allows for efficient translation of SHACL constraints into SQL, leveraging the relational database's capabilities to perform complex operations. By utilizing SQL's querying and aggregation features, the system can optimize processing power and ensure accurate and efficient validation of constraints.

[0020] Preferably, the method further comprises outputting one or more indications that the graph conforms to all the constraints. This arrangement provides clear feedback on the validation process, ensuring that users are informed about the compliance status of the graph data. By delivering precise indications, the system enhances user confidence in data integrity and facilitates efficient decision-making based on validated information

[0021] Preferably, the method further comprises outputting one or more violations, wherein a violation is a node that does not meet the constraints. This arrangement allows for the identification and reporting of non-compliant nodes, enabling users to address data issues promptly. By highlighting violations, the system enhances data quality management and supports corrective actions to ensure data integrity.

[0022] According to a further aspect a computer program product is provided comprising a computerexecutable program of instructions for performing, when executed on a computer, the steps of the method of as described above.

[0023] Brief description of the figures

[0024] Figure 1 shows execution time in milliseconds for the synthetic and benchmark experiments.

[0025] From top to bottom, these figures are referred to as (a), (b), (c) and (d).

[0026] Figure 2 shows Execution time in milliseconds for a slice of the DBLP database consisting of 8.5 million triples, Logarithmic scale.

[0027] Description

[0028] The Shapes Constraint Language (SHACL) is a W3C recommended language for expressing integrity constraints on RDF graphs [37,29,45]. In this setting, a “shape” is a possibly complex condition on nodes in a graph; intuitively, a shape specifies what the “neighbourhood” of a node in the graph should look like. A SHACL document, called a shapes graph, contains various shape definitions, along with target expressions that specify simple node-selecting queries. An RDF graph G conforms to a shapes graph S if for every shape-target pair (o,r) in S, all nodes in G selected by r satisfy o in G. The task of checking whether a graph conforms to a shapes graph (and reporting the violations, if any) is called validation.

[0029] The inventors’ insight is that validating an RDF graph is strikingly similar to querying a database. Indeed, looking for violations to a shape-target pair entails computing the set diflference QI - Q2 between two queries: QI finds all nodes selected by the target, and Q2 finds all nodes satisfying the shape. An observation in this respect is that SHACL is a rich logical language. Its expressive power certainly includes set diflference, through the logic primitives sh:and, sh:not. Moreover, target expressions correspond themselves to simple shapes. Hence, the diflference QI - Q2 above can itself be seen as a shape. Furthermore, finding the violations to all shape-target pairs listed in the shapes graph, boils down to finding the set union (logical primitive sh:or) of the violations of all these pairs. The inventors are led to conclude that validation is equivalent to shape querying: finding all nodes satisfying some (possibly complex) shape. Of course, querying graph data, in particular RDF graphs, is what SPARQL engines are all about. The inventors’ insights are that shape queries correspond closely to analytical queries in relational databases, than they are to SPARQL queries. Analytical queries are complex, ad-hoc queries for decision support. They are usually non-monotonic, and, expressed in SQL, they involve not only joins (typically along starshaped schemas) but also aggregations, and nested subqueries, often negated (NOT EXISTS in SQL). Queries of this nature are exemplified in the widely used TPC-H benchmark

[0057] . When analysing various features by which SHACL can express shapes, and viewing them from the perspective of SQL query constructions, the inventors have had the insight that such an analysis corresponds closely to analytical querying: for example, in group joins and count aggregation, qualified min- and max-count conditions in SHACL amount to group joins [42,22,26]: grouping combined with subqueries and HAVING conditions on the results of aggregate functions (in this case, count aggregations).

[0030] MIN and MAX aggregation arise in evaluating sh:lessThan constraints.

[0031] Set difference is a non-monotonic operator which is involved in the evaluation of various SHACL constraints, including sh:closed constraints; disjointness (sh:disjoint); and negated equality (sh:not sh:equals). Further non-monotonic constraints in SHACL require complex nested NOT-EXISTS subqueries, notably equality (sh:equals), and the constraint sh:uniqueLang. One may argue that aggregations and nested subqueries, possibly negated, can be expressed in SPARQL equally well as in SQL

[0032] . Nevertheless, the performance of SPARQL engines has typically been tuned towards monotonic queries, notably, basic graph patterns and path queries. Indeed, SPARQL engines, using index data structures geared to graph data and multiway join algorithms, can outperform relational systems in this area

[0033] . In contrast, progress in relational database query processing, query plan selection, and query optimization, has been building up for more than fifty years. Especially in the past twenty years, advances in hardware gave rise to breakthroughs in single-node, main-memory SQL engines for analytical querying. Breakthrough techniques included columnar storage and vectorization, as seen in the seminal systems C-Store and MonetDB [56,13,12], later followed by the technique of query compilation [35,36,38].

[0032] The inventors have also tested if the research hypothesis can be tested “straight out of the box”. Thereto, the inventors have devised a translation method from SHACL shapes Q into SQL select- statements Q'. The translation is correct in the sense that, for any RDF graph G, the result of Q' on a relational database representation of G consists precisely of all nodes in G that satisfy Q. Validation of an entire shapes graph can then be done by looking for violations, as already discussed above. The relational representation of RDF graphs that the inventors assume for the translation is standard

[0023] and not optimized in any way. The inventors have taken care to obtain a translation that is also efficient. Since SQL is meant to be a declarative language, the notion of “efficient” or “less efficient” SQL expressions is a bit of an oxymoron. Indeed, through query plan selection and optimization, query compilers are ideally supposed to pick a good execution plan regardless of how the query was formulated. Yet, in practice, it makes sense to generate SQL expressions from which the query optimizer is likely to pick a good plan. The inventors achieve this by converting SHACL shapes in negation normal form by pushing all negations (sh:not) through until they apply to atomic constraint components. The inventors generate a concise SQL expression for each atomic or negated atomic constraint component. Notably, NOT EXISTS subqueries are only needed in that step; SQL expressions for more complex shapes can now be built up using join, grouping and aggregation, filtering, union and set difference operators. With this translation in hand, all the inventors need to answer the “out of the box” question is a standalone main-memory SQL engine good at processing analytical queries, much like the inventors have standalone main- memory SHACL validators

[0053] . The inventors have chosen DuckDB

[0047] for this purpose, as it is very easy to use and install. The experimental results show that, when validating moderate numbers of target nodes in large graphs, SQL performs equally well as a specialized SHACL engine. When validating a substantial proportion of nodes, shape querying using SQL becomes orders of magnitude more efficient. The inventors also compare with Trav-SHACL, which is a recent approach to SHACL processing through SPARQL rather than through SQL

[0027] . Shape querying is also motivated by new applications of shapes, going beyond validation. Shape fragments

[0021] and knowledge-graph subsets

[0039] take shape querying one step further: they retrieve not just all nodes satisfying some shape, but also the “neighborhoods” of these nodes. The neighborhoods depend on the shape. In this way, shapes can be used as a view mechanism. Delva et al.

[0021] use a SHACL2SPARQL-like translation as an aid to generate even more complex SPARQL queries that return the neighborhoods. They provide little detail concerning their translation, its efficiency, or comparison to other systems.

[0033] Views defined by shapes may also have application in access control. In current approaches [59,51], the credentials of a user are checked by validating a SHACL shapes graph against RDF data containing information about this user. In case of conformance, the user is granted access to a data source according to one of the standard access control levels (e.g., read, write, etc.). However, shapes could also be used to specify, in a more fine-grained manner, a subgraph of the source to SHACL has been defined with an RDF syntax. As in many research works around SHACL, however [17,7,16,40,3,4,5,6], the inventors use here a logical syntax instead. The inventors follow the most complete proposal

[0021] which covers the entire SHACL core, with some slight alterations. Assuming three infinite pairwise-disjoint sets I, L and B of IRIs, literals and blank nodes respectively. The inventors call the union of these sets N = I U L U B the set of RDF terms. Literals generally have three attributes

[0049] : a value, a datatype and a language tag. For the purposes of SHACL, the inventors also need to assume a strict partial order < on N as an abstraction of comparisons between RDF terms.

[0034] An RDF triple (s,p,o) is an element of (I U B x I x N). The inventors refer to the elements of the triple as the subject, predicate and object respectively. An RDF graph G is a finite set of RDF triples. The inventors refer to the RDF terms occurring in the subject or object positions of an RDF graph as nodes.

[0035] SHACL shapes can make use of regular path expressions, called property paths, also known from SPARQL. Efficient regular path queries require specialized techniques [8] going beyond SQL, even recursive SQL

[0019] , In the present paper the inventors omit them from the inventors’ treatment. The inventors thus arrive at the syntax for shape expression cp as given by the following grammar:

[0036]

[0037] with p G I; s G I U B; c G N; n is a natural number; m is either a natural number or the symbol

[0038] and P c j finite. Here E represents a limited form of a path expression. SHACL supports testing whether nodes satisfy certain properties. The inventors abstract this with the test(t) feature where t represents a well-defined nodetest. Examples of node tests are shmodeKind, testing whether a node is an IRI, blank node or literal; or sh: languagein, testing whether a node has one of the specified language tags. The specific allowed tests are discussed in Section 5. The inventors will sometimes use shape expressions of the form SE.cp to denote #1^-^.

[0039] Generally, a shape has an associated shape name and possibly a target declaration. The inventors formalize this notion of a shape as a shape definition, which is a triple (s,cp,r) where s G I UB; cp is a shape expression; and r is a target declaration. The latter are specific shapes of one of the four forms: hasValue(c), Sp. T, Sp-. T, and Srdftype. has Value(c). These four forms correspond to the target declarations sh:targetNode c, sh: target SubjectsOf p, sh:targetObjectsOf p, and sh:targetClass c respectively. When no target declaration is desired, one can use the shape expression_,T. Finally, the inventors formalize a SHACL shapes graph as a schema. A schema is a finite set of shape definitions where no two definitions have the same shape name. In this work, the inventors only consider nonrecursive schemas.

[0040] The inventors now define when a node a conforms to a shape cp in graph G, within the context of a schema H, denoted by H, G,a |= cp. First, the evaluation of a path expression E, written as follows. Let p ∈ I: ⟦p⟧G= {(a, b) | (a, p, b) ∈ G} and ⟦p⁻⟧G= {(a,b) | (b, a) ∈ p G}. Then, the semantics of shape expressions are given in Table 1.

[0041] The following notations are used:

[0042] - def(s, H) denotes the shape expression defining shape name s in H. When s does not have a definition in H, def(s, H) = T (which is the behaviour of real SHACL).

[0043] - The inventors use the notation

[0044]

[0045] - When X is a set, the inventors use the notation JtX to denote the cardinality of X.

[0046] Table 1. Conditions for conformance of a node to a shape.

[0047] if:

[0048]

[0049] test(t) a satisfies t

[0050] hasShape(s) H. G, a f= deft, H )

[0051] jn < i{b € [AT’(a) | H. G*.& |= } < m if m # •

[0052] n < {6 e (Ej°(a) | H, G, b |= <•} otherwise

[0053] W-1every b <= [ ]‘ ’ (a 1 satisfies H. G.b

[0054] e«(F,p) the sets (Fls(a) and are equal

[0055] disj(F,p) the sets (Fj°(a) and (p|°(a) are disjoint

[0056] closed P) for all triple ia,j>, b) e G we have p t=

[0057] lesanan(E,p) b < c for all b e ( / ?]''’(« ' -and c € (pjs(a)

[0058] It s'l anE^ E,;>) b < c for all b t= ) and c € (p]e(a)

[0059] vnifueLang (E) for every t» c e pS]° (°)» &an<lchavedifferent language tags.

[0060] In general, it is easy to see that if a shape expression does not refer to other shapes, the inventors do not need to include the schema as part of the conformance definition: in that case G,a |= cp is well defined.

[0061] Finally, the inventors can define when a graph conforms to a schema. An RDF graph G conforms to a shape schema H if for every shape definition (s, cp, r) G H and for every a G N such that H, G,a |= r the inventors have H, G,a |= cp.

[0062] Since the inventors focus on nonrecursive schemas, the inventors can, for the purposes of conformance, abstract away the hasShape(s) construct from the shape expression grammar because the inventors can always expand the shape expression with the definition of that shape name, resulting in a semantically equivalent shape expression. The inventors define the expansion of a shape expression cp in context of a schema H as the shape expression \p which replaces every shape name s occurring in the construct hasShape(s) in cp with def(s, H) resulting in the expression cp'.

[0063] The inventors inductively apply this principle to cp' until the inventors end up with a shape expression that does not refer to any other shape definitions. As mentioned before, the inventors leverage the negation normal form

[0050] of a shape expression to acquire an efficient translation. The negation normal form of a shape expression cp is the shape expression cp' in which the inventors push every negation of a subshape through. The inventors define the negation normal form by giving the rewrite rules that need to be performed on cp to obtain cp':

[0064] - ’(cp 1 A q>2) becomes_,( l V-,(p2;

[0065] ~ ’(cp 1 V q>2) becomes_,( l A-,(p2;

[0066] _,_,(p becomes cp;

[0067] “VE.cp becomes BE.-’cp;

[0068] when

[0069]

[0070] becomes # 0 E-Vv#m+i-E’-cA

[0071] when

[0072]

[0073] becomes

[0074]

[0075] when m = * and" 7^ ^^n E.ip becomes #01-£-£.

[0076] The inventors translation covers all the SHACL-core features formalized in the previous section. The only technical limitation is that the inventors only support datatype comparisons for numerical values and strings. For example, the inventors do not support sh:minlnclusive tests on literals that represent dates.

[0077] In order give this translation, the inventors first need to describe the relational database schema that represents the underlying RDF data. The relational schema described here tries to be very close to the definition of the RDF data model. The inventors adopt a standard “pooling” technique which associates a unique identifier to all RDF nodes, which is then used in the central Triples relation. The full schema is given by the following relations:

[0078] • IRIs(Node: int64, Value: string). This relation stores all nodes that are IRIs. The Value attribute stores the IRI as a string and relates it with a unique node identifier given by the Node attribute.

[0079] • Blanks(Node: int64, Alias: string). Similarly to the IRI table, the inventors keep track of blank nodes by associating an identifier with them.

[0080] • Literals(Node: int64, Value: string, Type: string, Lang: string). Again, similar to the IRIs table, the inventors keep track of the literals used in the graph. Furthermore, it relates node identifiers to the value that they represent, the type that they are designated and the language tag that may be present. The language tag field is not NULL precisely when the datatype attribute value is rdflangString, as expected.

[0081] • Nodes(Node: int64). This relation stores all node identifiers. • Triples(Subject: int64, Predicate: string, Object: int64). This is the central relation of the inventors schema. The Subject and Object attributes refer to the node identifier used in the Node attribute of one of the previous three relations. The inventors do not need to use node identifiers in the predicate column, since property names cannot be treated as nodes in SHACL.

[0082] • Numerics(Node: int64, Value: double). The primary purpose of this relation is to have quick access to a numeric (double) value associated with literals that represent numerics. The Node column is a subset of the Node column in the Literals table. This relation is used to support some of the node-tests that check for numeric constraints, like sh:lessThan of sh:minExclusive.

[0083] In general, given an RDF graph G and a shape expression cp that does not refer to other shapes, the inventors’ translation gives us a unary SQL query Q(pthat retrieves all nodes in G that satisfy cp. In the case of shapes that do refer to other shapes in context of a schema H, the inventors can also translate the shape using the same techniques, by first expanding the shape expression with respect to H.

[0084] The inventors will now give the translation for shape expressions in negation normal form. For now, the inventors leave out the details for supporting inverse properties. When p is inverse, it is necessary to swap the operations relating to the Subject and Object columns of the Triples relation. For shape expressions cp of the form q> 1 A cp2, query Q(pis ( QV1) INTERSECT ( Q(p2)• For shape expressions cp of the form cpl V cp2, query Q(pis ( Q<pi UNION ( Q(p2)• Next, for the counting shapes of the form #™p. i. the inventors consider four cases. First, when n > 0, m #=*, and m #= n, query Q(pis

[0085] SELECT Subject AS Node FROM Triples, (Q(ψ)) AS Q(Node)

[0086] WHERE Predicate = p AND Object = Q.Node

[0087] GROUP BY Subject

[0088] HAVING C0UIT(«) >« n ABD C001T(*) <- m

[0089] When n = m, the inventors replace the last line with HAVING COUNT(*) = n; when m = * (and thus n > 0), the inventors replace it with HAVING COUNT(*) >= n. When n = 0 (and thus m #=*), the inventors instead have the query:

[0090] SELECT Node FROM Nodes WHERE Node NOT IN (Q#⁰_.*)

[0091] Indeed, the inventors cannot simply use HAVING COUNT(*) >= 0 in this case (compare the infamous “count bug”

[0028] .) Lastly, when the subshape \p is simply T, the inventors can leave out the subquery: (Q('| / )) AS Q(Node).

[0092] Next, for the case where cp is of the form Vp.rp the inventors have the query:

[0093]

[0094] The remaining non-test shapes are listed in Table 2. Before discussing the test shapes, the inventors will list the allowed node-tests in SHACL. These are: nodeKind(X) with X e {i,b,l} representing the test whether a node is an IRI, blank node or literal; datatype(d) with d e l checking whether anode has a certain datatype, e.g., xsd:integer; minlncl(n), minExcl(n), maxlncl(n), maxExcl(n) which represent the value range constraint components of SHACL

[0037] ; minLength(n), maxLength(n) which state that the string representation of literals must have a minimal, maximal length; pattem(p,f) state that the string representation of literals must satisfy some regular expression p (with flags f); and finally languagein(L) which states that the literal must have one of the language tags from the set L.

[0095] The test shapes are listed in Table 3 with the exception of numeric and string length constraints. For the numeric length constraints, like minExcl(n) the inventors get the following query: SELECT Node FROM Numerics WHERE Value > n. It is clear what queries the inventors get for every one of its variations; the inventors simply need to change the > operator: minlncl(n) (inclusive, >=), maxExcl(n) (max exclusive <), maxlncl(n) (max inclusive <=). When combinations of these tests are used, the inventors can simply add boolean combinations in the where-clause, for example minIncl(n)AmaxExcl(m) becomes: SELECT Node FROM Numerics WHERE Value <= n AND Value > m.

[0096] Similar techniques are applied to the string length tests minLength(n) and maxLength(n).

[0097] Table 2: Translation of shape expressions to unary SQL queries. The inventors omit the case where cp is T.

[0098]

[0099] StlCT!*!• Fl®!«!••

[0100] WERE IOT EXISTS (

[0101] (( ®LECT Object

[0102] FROM Triples SELECT Node FROM lodes WHERE Predicate • p WHERE EXISTS ((

[0103] UD Subject ■ lode SELECT • ER® Triples ) HCWT ( VHERE Predicate ■ p StBCT Object AID Object IOT M ( FROM Triples SELECT Object From Triples WHERE Predicate • < WHERE Subject - Node eq [}>. <{) AID Subject ■ lode l© Predicate • ff )

[0104] » OTIOI (( ) DNIOB (

[0105] ®LBCT Object SELECT • FROM Triples PRIM Triples WHERE Predicate « ® WHERE Predicate • « AID Object IOT IN ( ABD Subject ■ Bode SELECT Object From Triples ) H®PT C WHERE Subject - Node SELECT Object Al© Predicate « p ))) FROM Triples

[0106] WiERE Predicate » p

[0107] ABD Subject • lode )))

[0108] SELECT Subject AS Node SELECT Node FROM lodes FROM Triples AS Ti

[0109] WHERE Hods NOT H ( WHERE Predicate « p

[0110] SELECT • FROM Triples AID Subject • Object

[0111] WHQE Subject • Node AID IOT EXISTS (

[0112]

[0113] SELECT Node

[0114] F1(M Iod«» WER1 (

[0115] SELECT MAX(I. Value)

[0116] FROM Triples AS T, SELECT Ti. Subject IS Node

[0117] FROM Triples AS Ti,

[0118] Numerics AS I Triples AS T2,

[0119] WHERE T. Predicate ■ p

[0120] UD T. Subject ■ Bodes. lode Numerics IS 11,

[0121] lu»«ric» IS 12

[0122] fewllan(p, ) AID T. Object - I. ode

[0123] WHERE Ti. Predicate » p

[0124] ) < (

[0125] SELECT MIN(B. Value) ABD T2. Predicate » f

[0126] AID Ti. Object - Nl. Noda

[0127] FROM Triples AS T, ABD T2. Object - N2. Node Numerics AS N

[0128] WHERE T. Predicate • ® ABD II. Value >- N2. alue AID T. Subject ■ Bodes. lode

[0129] AID T. Object - B. Node )

[0130] SELECT Node FROM Bodes SELECT Subject AS Node

[0131] WHERE IOT EXISTS ( FROM Triples AS Ti,

[0132] SELECT L. Laug Trippies AS T2,

[0133] FROM Triples AS T, Literals AS Li,

[0134] Literals AS L Literals AS L2

[0135] tmifweXanj (p) WHERE T. Predicate - p WHERE Ti. Subject ■ 12. Subject

[0136] AID T. Subject • Bodes. Bode ABD Ti. Predicate ■ p

[0137] AID T. Object - L. Node HD T2. Predicate • p

[0138] AID L. Lang IOT BULL AID Ti. Object - Li. Node GROUP BY L. Lang ABD T2. Object - L2. Node HAVIIG COUBTC*) > 1 ) AID Ll.taag <> 12. Lang

[0139] The inventors implemented the translation from SHACL to SQL in Python, using the popular library RDFLib. The inventors’ implementation can translate real SHACL shapes graphs into SQL queries that retrieve all nodes satisfying a shape expression, or all violations of a shape definition. It supports all features discussed in the previous section. To load RDF graphs into a DuckDB database, the inventors also wrote a simple translation tool. DuckDB automatically creates min-max indexes for all table columns.

[0140] The inventors validated the correctness of the inventors’ implementation by running it against the SHACL core test suite. The inventors’ implementation passed 70 percent of the core tests. The non-passed tests either have to do with property paths, or with tests on datatypes as already mentioned in the paragraphs relating to the translation.

[0141] The inventors compare the inventors’ SQL approach to two other SHACL engines: the Apache Jena SHACL validator, as a representative of a dedicated SHACL engine, and Trav-SHACL, as a representative of the SHACL-to- SPARQL approach

[0058] , The inventors’ experiments measure the execution time of validating a shape against a graph. For the SQL approach, the inventors measure the query execution time of DuckDB. For Apache Jena the inventors first parse the shape schema and load the data into a TDB Table 3. Translation of shape expressions to SQL for the has Value and test features. In this table, cte I, Ci e L. The inventors omit nodeKind(b) and nodeKind(l).

[0142]

[0143] database, the inventors then measure the execution time of the ShaclValidator.validate function. For Trav-SHACL, the inventors first setup a Jena Fuseki SPARQL endpoint which exposes the data, and parse the shape schema. The inventors then measure the execution time of the Shape Schema. validate function.

[0144] Other validation engines were also considered. PySHACL requires the graph to be loaded in main memory, and ran out of memory for most of the datasets. The inventors also observed that TopQuadrant’s engine performs very similarly to Jena, so the inventors omit TopQuadrant from the presentation of the results to avoid clutter.

[0145] The inventors used an 8 core AMD EPYC 2.595GHz processor with 16GB DDR4 RAM and 400GB SSD to run all experiments.

[0146] Synthetic shapes and data. As a starting point, the inventors formulated 10 SHACL shapes, shown in Table 4. These shapes were purposely invented to explore a variety of SHACL features. For each shape, the inventors generate suitable synthetic data. For datasets of 5 million triples, the inventors obtain the timings represented in Figure 1 (a), logarithmic scale. Some of the shapes are not supported by Trav-SHACL. The inventors can see that DuckDB is an order of magnitude faster on most shapes, except, curiously, Shape 7.

[0147] Table 4. The 10 synthetic shape definitions. All shapes target nodes of type ‘human’, except for shape 7, which targets all objects of the ‘email’ property.

[0148] Name Expression

[0149] Shape

[0150] Shape

[0151] Shape

[0152]

[0153] Shape 4 ^iisj(colkague, friend)

[0154] Shape 5 ctosed(propertpf, property^, property )

[0155] Shape 6 3phone. T V 3ematLT

[0156] Shape 7 #|ejnaiF. T

[0157] Shape X eqtpv'iperfy!. )

[0158] Shape 9 w»t^Me£a»j(^rstNa«)

[0159] Shape 10 lessThan,(staM¥ork, endlForfc)

[0160] To show that the results of this synthetic experiment scale, the inventors generated datasets of 20 million triples and ran the same experiments with DuckDB and Jena SHACL (not with Trav-SHACL, due to memory limitations). These results can be found in Figure 1 (b), also logarithmic scale.

[0161] Remark 1. In Figure 1, the inventors see that for the synthetic experiments shape 7, Jena outperforms DuckDB. The inventors reused the dataset for shape 6 to also test shape 7. However, this dataset has very few targets for shape 7. DuckDB retrieves many conforming nodes but subtracts these from the small list of targets. It still does this in 1 second, but Jena just looks at the very few targets. The inventors already noted in the Tyrol experiments that small target sizes skew the comparison. When rerunning the experiments on a more balanced dataset, the quirk disappears. The additional balanced dataset can be found in the supplementary material.

[0162] Tyrol benchmark. The inventors also ran a selection of shapes from the SHACL benchmark by Schaflfenrath et al.

[0052] , They define 57 shapes over the “Tyrolean Knowledge Graph” which consists of 30 million triples. The inventors selected a random 10 million triple slice of this graph, and selected 10 of the 57 shapes that had the most targets in the inventors’ slice. The inventors then ran SQL approach and Jena on this slice. The inventors had to leave out Trav-SHACL, since its current implementation is still rather limited and does not support the features used in the selected shapes.

[0163] The performance results are shown in Figure 1 (c). The benchmark shapes are ordered left to right from most to fewest number of targets. The inventors can see that Jena SHACL outperforms the SQL approach for half of the shapes. This can be explained by the fact that the last five shapes have significantly less target nodes to check, compared to the first five shapes. Jena SHACL is a specialized SHACL engine, and can quickly retrieve these targets and perform the validation. However, if the inventors adjust the shapes such that they target all subjects of rdftype, which lies closer to shape querying, Jena loses this advantage. This is illustrated in Figure 1 (d). The inventors report that DuckDB ran out of memory for ‘ SportsActivity Shape’. This may be due to the large number of constraints used by this shape.

[0164] One major difference between the synthetic data and the benchmark data is that in the synthetic experiments almost all the data needs to be checked to decide conformance. Here, only small parts of the data needs to be checked for some shapes. This explains why the execution times are generally lower.

[0165] DBLP data DBLP published their database as a large RDF graph containing 400 million triples

[0018] , This RDF graph contains information about publications and their authors. The inventors created three analytical shapes for this dataset:

[0166] PersonShape: the shape expression #lp. T A with p representing

[0167] primary aililiati. >n and <i affiliation. It fa run against all nodm of type ‘Person’

[0168] (which represent authors).

[0169] 'IteamplayerShape: the shape expression 3a-.* a. T, with a representing ‘authored by’, again run against all authors.

[0170] PublicattonShape: of a less analytical nature, this fa the shape expression 3dblp:author®dBy.3rdf:type.hasPUue(dblp: Person), run against all nodes

[0171] of type ‘Publication’.

[0172] The inventors run these shapes on purpose against large sets of targets (all authors, or all publications) to get information on shape querying performance. The inventors used a slice of the DBLP database that contains all publications together with their author information for the years 2022 and 2023. This results in an RDF graph of 8.5 million triples. The results are given in Figure 2. Again, DuckDB significantly outperforms Jena SHACL, also on PublicationShape. References:

[0173] 1. Abbas, A., Genev'es, P., Roisin, C., Laya'ida, N.: Selectivity estimation for SPARQL triple patterns with shape expressions. In: Mikkonen, T., et al. (eds.) Proceedings 18th International Conference on Web Engineering. Lecture Notes in Computer Science, vol. 10845, pp. 195-209. Springer (2018)

[0174] 2. Ahlstrpm Jakobsen, K., Andersen, A., Hose, K., Bach Pedersen, T.: Optimizing RDF data cubes for efficient processing of analytical queries. In: Hartig, O., Sequeda, J., et al. (eds.) Proceedings 6th International Workshop on Consuming Linked Data. CEUR Workshop Proceedings, vol. 1426 (2015)

[0175] 3. Ahmetaj, S., David, R., Ortiz, M., Polleres, A., Shehu, B., Sirnkus, M.: Reasoning about explanations for non-validation in SHACL. In: Bienvenu, M., Lakemeyer, G., et al. (eds.) Proceedings 18th International Conference on Principles of Knowledge Representation and Reasoning, pp. 12-21. IJCAI Organization (2021)

[0176] 4. Ahmetaj, S., David, R., Polleres, A., Simkus, M.: Reparing SHACL constraint violations using answer set programming. In: Sattler, U., et al. (eds.) Proceedings 21st International Semantic Web Conference. Lecture Notes in Computer Science, vol. 13489, pp. 375-391. Springer (2022) 5. Ahmetaj, S., Lo' hnert, B., Ortiz, M., Simkus, M.: Magic shapes for SHACL validation. Proceedings of the VLDB Endowment 15(10), 2284—2296 (2022)

[0177] 6. Ahmetaj, S., Ortiz, M., Oudshoorn, A., Simkus, M.: Reconciling SHACL and ontologies: Semantics and validation via rewriting. In: Gal, K., Now'c, A., et al. (eds.) Proceedings 26th European Conference on Artificial Intelligence. Frontiers in Artificial Intelligence and Applications, vol. 372, pp. 27-35. IOS Press (2023)

[0178] 7. Andre^sel, M., Corman, J., Ortiz, M., Reutter, J., Savkovic, O., Simkus, M.: Stable model semantics for recursive SHACL. In: Huang, Y., King, I., Liu, T. Y., van Steen, M. (eds.) Proceedings WWW’20. pp. 1570-1580. ACM (2020)

[0179] 8. Arroyuelo, D., Hogan, A., Navarro, G., Rojas-Ledesma, J.: Time- and spaceefficient regular path queries. In: Proceedings 38th International Conference on Data Engineering, pp.

[0180] 3091-3105. IEEE (2022)

[0181] 9. Bahadur Thapa, R., Giese, M.: Optimizing SPARQL queries with SHACL. In: Payne, T., Presutti, V., Qi, G., et al. (eds.) Proceedings 22nd International Semantic Web Conference. Lecture Notes in Computer Science, vol. 14265, pp. 41-60. Springer (2023)

[0182] 10. Bogaerts, B., Jakubowski, M.: Fixpoint semantics for recursive SHACL. In: Formisano, A., Liu, Y, et al. (eds.) Proceedings 37th International Conference on Logic Programming (Technical Communications). Electronic Proceedings in Theoretical Computer Science, vol. 345, pp. 41^-7 (2021)

[0183] 11. Boncz, P., Erling, O., Pham, M. D.: Advances in large-scale RDF data management. In: Auer, S., Bryl, V., Tramp, S. (eds.) Linked Open Data, Lecture Notes in Computer Science, vol. 8661, pp. 21-44. Springer (2014) 12. Boncz, P., Kersten, M., Manegold, S.: Breaking the memory wall in MonetDB.

[0184] Communications of the ACM 51(12), 77-85 (2008)

[0185] 13. Boncz, P., Zukowski, M., Nes, N.: MonetDB / XlOO: Hyper-pipelining query execution. In: Proceedings 2nd Biennial Conference on Innovative Data Systems Research, pp. 225-237. www.cidrdb.org (2005)

[0186] 14. Boneva, I., Gayo, J., Prud’hommeaux, E.: Semantics and validation of shape schemas for RDF. In: d’ Amato, C., Fernandez, M., Tamma, V., et al. (eds.) Proceedings 16th International Semantic Web Conference. Lecture Notes in Computer Science, vol. 10587, pp. 104-120. Springer (2017)

[0187] 15. Chmurovic, A., Simkus, M.: Well-founded semantics for recursive SHACL. In: Alviano, M., Pieris, A. (eds.) Datalog 2.02022: Fourth International Workshop on the Resurgence of Datalog in Academia and Industry. CEUR Workshop Proceedings, vol. 3203, pp. 2-13 (2022) 16. Corman, J., Florenzano, F., Reutter, J., Savkovic, O.: Validating SHACL constraints over a SPARQL endpoint. In: Ghidini et al.

[0030] , pp. 145-163

[0188] 17. Corman, J., Reutter, J., Savkovic, O.: Semantics and validation of recursive SHACL. In: Vrandecic, D., et al. (eds.) Proceedings 17th International Semantic Web Conference. Lecture Notes in Computer Science, vol. 11136, pp. 318- 336. Springer (2018), extended version, technical report KRDB 18-01, https:

[0189] / / www.inf.unibz.it / krdb / tech-reports /

[0190] 18. DBLP data in RDF. http: / / dblp.org / rdf /

[0191] 19. De Leo, D., Boncz, P: Extending SQL for computing shortest paths. In: Boncz, P., Larriba-Pey, J. (eds.) Proceedings 5th International Workshop on Graph Datamanagement Experiences & Systems, pp. 10:1-10:8. ACM (2017)

[0192] 20. Dedecker, R., Slabbinck, W, Wright, J., et al.: What’s in a Pod? A knowledge graph interpretation for the Solid ecosystem. In: Saleem, M., et al. (eds.) Proceedings 6th Workshop on Storing, Querying and Benchmarking Knowledge Graphs. CEUR

[0193] Workshop Proceedings, vol. 3279, pp. 81-96 (2022)

[0194] 21. Delva, T., Dimou, A., Jakubowski, M., Van den Bussche, J.: Data provenance for SHACL. In: Stoyanovich, J., Teubner, J., et al. (eds.) Proceedings 26th International Conference on Extending Database Technology, pp. 285-297. OpenProceedings.org (2023)

[0195] 22. Eich, M., Fender, P, Moerkotte, G.: Efficient generation of query plans containing group-by, join, and groupjoin. The VLDB Journal 27(5), 617-641 (2018)

[0196] 23. Erling, O.: Implementing a SPARQL-compliant RDF triple store using a SQL- ORDBMS. https: / / vos.openlinksw.com / owiki / wiki / VOS / VOSRDFWP, retrieved 8 April 2024 24. Erling, O.: Virtuoso, a hybrid RDBMS / graph column store. IEEE Data Engineering Bulletin 35(1), 3-8 (2012) 25. Erling, O., Mikhailov, L: RDF support in the Virtuoso RDBMS. In: Auer, S., Bizer, C., Mu ller, C., Zhdanova, A. (eds.) Proceedings 1st Conference on Social Semantic Web. Lecture Notes in Informatics, vol. P-113, pp. 59-68. GI (2007)

[0197] 26. Fent, P, Neumann, T.: A practical approach to groupjoin and nested aggregates.

[0198] Proceedings of the VLDB Endowment 14(11), 2383-2396 (2021)

[0199] 27. Figuera, M., Rohde, P, Vidal, M. E.: Trav-SHACL: Efficiently validating networks of SHACL constraints. In: Leskovec, J., et al. (eds.) Proceedings WWW’21. pp. 3337-3348. ACM (2021)

[0200] 28. Ganski, R., Wong, H.: Optimization of nested SQL queries revisited. SIGMOD Record 16(3), 23-33 (1987)

[0201] 29. Gayo, J., Prud’hommeaux, E., Boneva, I., Kontokostas, D.: Validating RDF data. Synthesis Lectures on the Semantic Web: Theory and Technology 16 (2018)

[0202] 30. Ghidini, C., Hartig, O., Maleshkova, M., Sva'tck, V, et al. (eds.): Proceedings 18th International Semantic Web Conference, Lecture Notes in Computer Science, vol. 11778. Springer (2019)

[0203] 31. Gray, J., et al.: Data cube: A relational aggregation operator generalizing groupby, crosstab, and sub totals. Data Mining and Knowledge Discovery 1(1), 29-53 (1007)

[0204] 32. Harris, S., Seaborne, A.: SPARQL 1.1 query language. W3C Recommendation (Mar 2013) 33. Hogan, A., Riveros, C., Rojas, C., Soto, A.: A worst-case optimal join algorithm for SPARQL. In: Ghidini et al.

[0030] , pp. 258-275

[0205] 34. Ibragimov, D., Hose, K., Bach Pedersen, T., Zim'anyi, E.: Processing aggregate queries in a federation of SPARQL endpoints. In: Gandon, F., Sabou, M., Sack, H., et al. (eds.) Proceedings 12th European Semantic Web Conference. Lecture Notes in Computer Science, vol. 9088, pp. 269-285. Springer (2015)

[0206] 35. Kemper, A., Neumann, T.: HyPer: A hybrid OLTP& OLAP main memory database system based on virtual memory snapshots. In: Proceedings 27th International Conference on Data Engineering, pp. 195-206. IEEE Computer Society (2011)

[0207] 36. Kersten, T., Leis, V, et al.: Everything you always wanted to know about compiled and vectorized queries but were afraid to ask. Proceedings of the VLDB Endowment 11(13), 2209-2222 (2018)

[0208] 37. Knublauch, H., Kontokostas, D.: Shapes constraint language (SHACL). W3C Recommendation (Jul 2017)

[0209] 38. Kohn, A., Leis, V, Neumann, T.: Tidy tuples and flying start: Fast compilation and fast execution of relational queries in Umbra. The VLDB Journal 30(5), 883-905 (2021)

[0210] 39. Labra Gayo, J.: Creating knowledge graph subsets using shape expressions. arXiv:2110.11709 (Oct 2021) 40. Leinberger, M., Seifer, P., et al.: Deciding SHACL shape containment through description logics reasoning. In: Pan, J., et al. (eds.) Proceedings 19th International Semantic Web Conference. Lecture Notes in Computer Science, vol. 12506, pp. 366-383. Springer (2020)

[0211] 41. Lieber, S., Dimou, A., Verborgh, R.: Statistics about data shape use in RDF. In: Taylor, K., et al. (eds.) Proceedings of the ISWC 2020 Demos and Industry Tracks: From Novel Ideas to Industrial Practice, vol. 2721. CEUR Workshop Proceedings (2020)

[0212] 42. Moerkotte, G., Neumann, T.: Accelerating queries with group-by and join by groupjoin. Proceedings of the VLDB Endowment 4, 843-851 (2011)

[0213] 43. Morfonios, K., et al.: ROLAP implementations of the data cube. ACM Computing Surveys 39(4), 12:1-12:53 (2007)

[0214] 44. Neumann, T., Weikum, G.: The RDF-3X engoine for scalable management of RDF data. The VLDB Journal 19(1), 91-113 (2010)

[0215] 45. Pareti, P, Konstantinidis, G.: A review of SHACL: From data validation to schema reasoning for RDF graphs. In: Sirnkus, M., Varzinczak, I. (eds.) Reasoning Web:" Declarative Artificial Intelligence. Lecture Notes in Computer Science, vol. 13100, pp. 115-144. Springer (2022)

[0216] 46. Pareti, P, Konstantinidis, G., Mogavero, F.: Satisfiability and containment of recursive SHACL. Journal of Web Semantics 74, 100721 (2022)

[0217] 47. Raasveld, M., Mu'hleisen, H.: DuckDB: An embeddable analytical database. In:

[0218] Proceedings 2019 International Conference on Management of Data. pp. 1981- 1984. ACM (2019) 48. Rabbani, K., Lissandrini, M., Hose, K.: Optimizing SPARQL queries using shape statistics. In: Velegrakis, Y., Zeinalipour-Yazti, D., et al. (eds.) Proceedings 24th International Conference on Extending Database Technology, pp. 505-510. Open- Proceedings.org (2021)

[0219] 49. RDF 1.1 primer. W3C Working Group Note (Jun 2014)

[0220] 50. Robinson, J., Voronkov, A. (eds.): Handbook of Automated Reasoning. Elsevier and MIT Press (2001)

[0221] 51. Rohde, P, et al.: SHACL-ACL: Access control with SHACL. In: Pesquita, C., SkafMolli, H., et al. (eds.) The Semantic Web: ESWC Satellite Events. Lecture Notes in Computer Science, vol. 13998, pp. 22-26 (2023)

[0222] 52. Schaffenrath, R., Proksch, D., Kopp, M., Albasini, L, Panasiuk, O., Fensel, A.: Benchmark for performance evaluation of shacl implementations in graph databases. In: V, G. B., Kliegr, T., Soylu, A., et al. (eds.) Proceedings 4th International Joint Conference on Rules and Reasoning. Lecture Notes in Computer Science, vol. 12173, pp. 82-96. Springer (2020)

[0223] 53. SHACL test suite and implementation report. W3C Document (Jan 2024)

[0224] 54. Shacl2sparql. https: / / github.com / rdfshapes / shacl-sparql 55. ShEx—shape expressions, https: / / shex.io (Apr 2024)

[0225] 56. Stonebraker, M., et al.: C-Store: A column-oriented DBMS. In: Bo¨hm, K., Jensen, C., et al. (eds.) Proceedings 31th International Conference on Very Large Data

[0226] Bases, pp. 553-564. ACM (2005)

[0227] 57. TPC benchmark H decision support standard specification revision 3.0.1. Transaction Processing Performance Council (1993-2022)

[0228] 58. Trav-shacl implementation. https: / / github.com / SDM-TIB / Trav-SHACL

[0229] 59. Werbrouck, J., et al.: Pattern-based access control in a decentralised collaboration environment. In: Poveda-Villalo´n, M., Roxin, A., et al. (eds.) Proceedings 8th Linked Data in Architecture and Construction Workshop. CEUR Workshop Proceedings, vol. 2636, pp. 118-131

Claims

CLAIMS1. A computer-implemented method for validating one or more Shapes Constraint Language, SHACL, graphs on one or more Resource Description Framework, RDF, graphs in a relational database system,wherein the SHACL graphs comprise at least one shape-target parameter pair comprising a shape parameter representative for a constraint that a node of the RDF graph must satisfy and a target parameter representative for which node in the RDF graph should be validated against the shape parameter of said SHACL graph; andwherein the RDF graphs comprises a plurality of RDF terms;the method comprising:- representing the one or more RDF graphs in a relational database scheme by identifying, for each of the plurality of RDF terms, one or more nodes, wherein the nodes are at least one of a subject, predicate and an object, wherein the subject and object are represented by at least one of an Internationalized Resource Identifier, IRI, a literal, or a blank node identifier and the predicate is represented by a literal;- associating each node of the identified plurality of nodes with a unique node identifier; - storing a relationship between the associated unique identifier and each node such that the RDF graphs a represented in a relational database scheme;- compiling the one or more SHACL graphs into SQL expressions by converting the SHACL graph into a negation normal form, NNF, by applying negations only to atomic constraint components of the at least one shape-target parameter pair, and translating each atomic or negated atomic constraint into a SQL expression using a look-up table; and- validating that a RDF graph conforms to a SHACL graph by executing the SQL expressions on the relational database scheme and identifying that each node satisfies the constraints defined by the at least one shape-target parameter pair of the SHACL graph.

2. The computer-implemented method of claim 1, wherein the step of associating each node of the plurality of nodes with a unique identifier and storing the relationship between the associated unique identifier and each node, comprises at least one of- storing all nodes that are IRIs as a first value attribute and relating it to the respective unique node identifier;- storing all nodes that are blanks as a second value attribute and relating it to the respective unique node identifier;- storing all nodes that are literals as a third value attribute and relating it to the respectiveunique node identifier;- storing all the unique node identifiers as a fourth value attribute;- storing a relationship between the first value attribute, the second value attribute and the third value attribute.

3. The computer-implemented method according to any one of the previous claims, wherein a node in an RDF graph meets the constraints if it satisfies all the conditions specified by the SHACL shapes, wherein the conditions to meet the constraints comprise at least one of a shape conformance, a property constraint, a logical condition, a cardinality constraint, a comparison constrain.

4. The computer-implemented method according to any one of the previous claims, wherein compiling the one or more SHACL graphs into SQL expressions comprises mapping atomic constrains sh:lessThan and sh:equals to SQL comparisons or joins respectively; translating SHACL logical operators sh:and, sh:or and sh:not to SQL INTERSECT, UNION and NOT EXISTS operations, respectively; translating SHACL constraints involving counts, such as sh:minCount and sh:maxCount into GROUP BY and HAVING SQL aggregations, respectively.

5. The computer-implemented method according to any one of the previous claims, outputting one or more indications that the graph conforms to all the constraints.

6. The computer-implemented method according to any one of the previous claims, outputting one or more violations, wherein a violation is a node that does not meet the constraints.

7. A computer program product comprising a computer-executable program of instructions for performing, when executed on a computer, the steps of the method of any one of the previous claims.

Images