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. Figure 1

Description

Efcient SHACL intoSQL compiler Field of Invention The eld of the invention relates to a computer-implemented method for validating one or more Shapes Constraint Language, SHACL, graphs. Background The current state ofthe art involves the use ofthe Shapes Constraint Language (SHACL) for expressing constraints on graph data. SHACL is a powerful language that allows for the specication ofcomplex 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 dene such detailed constraints is crucial for applications that rely on accurate and reliable data representation. Despite its capabilities, the complexity ofSHACL constraints poses signicant challenges in terms of validation eiciency. 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. Eicient validation mechanisms are therefore critical to maintaining the performance and scalability of systems utilizing SHACL. One of the primary disadvantages of the current state of the art is the inefciency 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 ineiciency can lead to delays and increased costs, making it difcult for organizations to leverage the full potential ofSHACL in their data management processes. my It is therefore an objective of the present invention to provide a solution that enhances the efciency of validating complex SHACL constraints on graph data, thereby improving performance and scalability in graph database applications. According to a rst aspect, a computer-implemented method is provided for validating Resource Description Framework (RDF) graphs againstSHACL graphs, using relational database system technology.Acomputer-implemented methodmay be understood as a series of steps executed by a computer to achieve a specic outcome. SHACL graphs are used to dene constraints onRDF data, whileRDF graphs represent data in a structured format using nodes and relationships. Itmay 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 theRDF graph must satisfy and a target parameter representative for which node in theRDF graph should be validated against the shape parameter of saidSHACL 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 ofnodes for validation, ensuring that only relevant data is processed, which optimizes the use ofprocessing power and reduces unnecessary computations. The method comprises representing the one ormore RDF graphs in a relational database scheme by identifying, for each of the plurality ofRDF 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 ofan Internationalized Resource Identier (IRI), a literal, or a blank node identier, and the predicate is represented by a literal. RepresentingRDF graphs in a relational database scheme involves mappingRDF terms to database structures. This arrangement provides the advantage of leveraging relational database eiciencies, such as indexing and query optimization, which enhances storage capacity and retrieval speed. The method further comprises associating each node of the identied plurality ofnodes with a unique node identier and storing a relationship between the associated unique identier and each node such that theRDF graphs are represented in a relational database scheme.Aunique node identier is a distinct reference for each node. This arrangement ensures efcient data retrieval and manipulation, as unique identiers 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 efcient 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 aRDF graph conforms to aSHACL graph by executing the SQL expressions on the relational database scheme and identifying that each node satises the constraints dened by the at least one shape-target parameter pair of the SHACL graph. Validation ensures that data adheres to specied constraints. This arrangement provides the advantage ofreal- time validation, ensuring data integrity and consistency while more efciently utilizing processing resources and maintaining system performance. Preferably, the step of associating each node of the plurality ofnodes with a unique identier and storing the relationship between the associated unique identier and each node, comprises at least one of - storing all nodes that are IRIs as a rst value attribute and relating it to the respective unique node identier; - storing all nodes that are blanks as a second value attribute and relating it to the respective unique node identier; - storing all nodes that are literals as a third value attribute and relating it to the respective unique node identier; - storing all the unique node identiers as a fourth value attribute; - storing a relationship between the rst value attribute, the second value attribute and the third value attribute. This arrangement allows for efcient categorization and retrieval ofnodes 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 efciency, as each node type is distinctly managed and easily accessible. Preferably, a node in anRDF graph meets the constraints if it satises all the conditions specied by theSHACL 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 specied requirements, thereby enhancing the reliability and accuracy of the data processing and storage. Preferably, compiling the one or more SHACL graphs into SQL expressions comprises mapping atomic constrains, like shzlessThan or sh:equals, to SQL comparisons orjoins respectively; translating SHACL logical operators sh:and, sh:or and sh:not to SQLINTERSECT, UNION and NOTEXISTS operations; respectively; translating SHACL constraints involving counts; such as sh:minCount and sh:maxCount intoGROUPBY andHAVING SQL aggregations, respectively. This arrangement allows for efcient translation ofSHACL 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 efcient validation of constraints. 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 condence in data integrity and facilitates eicient decision-making based on validated information 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 identication and reporting ofnon-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. According to a further aspect a computer program product is provided comprising a computer- executable program of instructions for performing, when executed on a computer, the steps of the method of as described above. Brief description of the gures Figure 1 shows execution time in milliseconds for the synthetic and benchmark experiments. From top to bottom, these gures are referred to as (a), (b), (c) and (d). Figure 2 shows Execution time in milliseconds for a slice of theDBLP database consisting of 8.5 million triples, Logarithmic scale. Description The Shapes Constraint Language (SHACL) isaW3C recommended language for expressing integrity constraints onRDF graphs [37,29,45]. In this setting, a shape is a possibly complex condition on nodes in a graph; intuitively; a shape species what the neighbourhood of a node in the graph should look like.ASHACL document, called a shapes graph, contains various shape denitions, along with target expressions that specify simple node-selecting queries.AnRDF graph G conforms to a shapes graph S if for every shapetarget pair (6,15) in S, all nodes inG selected by r satisfy 6 in G. The task ofchecking whether a graph conforms to a shapes graph (and reporting the violations, if any) is called validation. The inventors insight is that validating anRDF graph is strikingly similar to querying a database. Indeed, looking for violations to a shapetarget pair entails computing the set difference Q1 Q2 between two queries: Q1 nds all nodes selected by the target, and Q2 nds all nodes satisfying the shape. An observation in this respect is thatSHACL is a rich logical language. Its expressive power certainly includes set difference, through the logic primitives sh:and, sh:not. Moreover, target expressions correspond themselves to simple shapes. Hence, the difference Q1 Q2 above can itselfbe seen as a shape. Furthermore, nding the violations to all shapetarget pairs listed in the shapes graph, boils down to nding 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: nding all nodes satisfying some (possibly complex) shape. Ofcourse, querying graph data, in particularRDF graphs, is whatSPARQL 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 star- shaped schemas) but also aggregations, and nested subqueries, often negated (NOTEXISTS in SQL). Queries of this nature are exemplied in the widely usedTPC-H benchmark

[57] . When analysing various features by which SHACL can express shapes, and viewing them from the perspective ofSQL query constructions, the inventors have had the insight that such an analysis corresponds closely to analytical querying: for example, in groupjoins and count aggregation, qualied min- and max-count conditions inSHACL amount to group joins [42,22,26]: grouping combined with subqueries andHAVING conditions on the results of aggregate functions (in this case, count aggregations). MIN andMAX aggregation arise in evaluating shzlessThan constraints. Set difference is a non-monotonic operator which is involved in the evaluation ofvarious SHACL constraints; including shzclosed constraints; disjointness (shzdisjoint), and negated equality (sh:not sh:equals). Further non-monotonic constraints in SHACL require complex nestedNOTEXISTS 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

[32] . Nevertheless, the performance ofSPARQL 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

[33] . In contrast, progress in relational database query processing, query plan selection, and query optimization, has been building up for more than fty 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 andMonetDB [56,13,12], later followed by the technique ofquery compilation [35,36,38]. 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 fromSHACL shapesQ into SQL select-statements Q'. The translation is correct in the sense that, for anyRDF graph G; the result of Q' on a relational database representation ofG consists precisely of all nodes inG that satisfy Q. Validation of an entire shapes graph can then be done by looking for violations, as already discussed above. The relational representation ofRDF graphs that the inventors assume for the translation is standard

[23] 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 ofhow 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;NOTEXISTS subqueries are only needed in that step; SQL expressions for more complex shapes can now be built up using join, grouping and aggregation, ltering, 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-memorySQL engine good at processing analytical queries, much like the inventors have standalone main-memorySHACL validators

[53] . The inventors have chosen DuckDB

[47] 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 specializedSHACL engine. When validating a substantial proportion of nodes, shape querying usingSQL becomes orders ofmagnitude more efficient. The inventors also compare with Trav-SHACL, which is a recent approach to SHACL processing through SPARQL rather than through SQL

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

[21] and knowledge-graph subsets

[39] take shape querying one step further: they retrieve notjust all nodes satisfying some shape, but also the neighborhoods ofthese nodes. The neighborhoods depend on the shape. In this way, shapes can be used as a view mechanism. Delva et al.

[21] use a SHACL2SPARQL-like translation as an aid to generate even more complexSPARQL queries that return the neighborhoods. They provide little detail concerning their translation, its efficiency; or comparison to other systems. Views dened by shapes may also have application in access control. In current approaches [59,51], the credentials of a user are checked by validating aSHACL shapes graph againstRDF data containing information about this user. In case ofconformance, 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 ne-grained manner, a subgraph of the source to SHACL has been dened with anRDF 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

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

[49] : a value, a datatype and a language tag. For the purposes of SHACL, the inventors also need to assume a strict partial order< onN as an abstraction of comparisons betweenRDF terms. AnRDF triple (s,p,o) is an element of (I U B X I X N). The inventors refer to the elements ofthe triple as the subject, predicate and object respectively.AnRDF graphG is a nite set ofRDF triples. The inventors refer to the RDF terms occurring in the subject or object positions ofanRDF graph as nodes. SHACL shapes canmake use ofregular path expressions, called property paths, also known from SPARQL. Efficient regular path queries require specialized techniques [8] going beyond SQL, even recursive SQL

[19] . In the present paper the inventors omitthem from the inventors treatment. The inventors thus arrive at the syntax for shape expression (p as given by the following grammar: E === P | p F ::= id | E 9° === T I hasShape(8) l hasValue(C) I soA P | soV «>| "P |#rw |mw«um | disj(Fp) | closed(P> | lessThan(E,p) | lessThanEq(E,p) | uniqueLang(E) | test(t) with p I; s I U B; c N; n is a natural number,m is either a natural number orthe symbol *, and P Q I nite. Here E represents a limited form ofa path expression. SHACL supports testing whether nodes satisfy certain properties. The inventors abstract this with the test(t) feature where t represents a well-dened nodetest. Examples ofnode tests are sh:nodeKind; testing whether anode is an IRI, blank node or literal, or shzlanguagein, testing whether a node has one ofthe specied language tags. The specic allowed tests are discussed in Section 5. The inventors will sometimes use shape expressions ofthe form ElE.(p to denote #ÎECP. Generally, a shape has an associated shape name and possibly a target declaration. The inventors formalize this notion ofa shape as a shape denition, Which is atriple (s,(p,r) Where s I UB, (p is a shape expression; and r is a target declaration. The latter are specic shapes ofone ofthe four forms: hasValue(c), ElpT, Elp.T, and Elrdfztype.hasValue(c).These four forms correspond to the target declarations shztargetNode c, shztargetSubjectsOfp, shztargetObjectsOfp, and shztargetClass c respectively.When no target declaration is desired, one can use the shape expression T. Finally, the inventors formalize aSHACL shapes graph as a schema.A schema is a nite set ofshape denitions where no two denitions have the same shape name. In this work; the inventors only consider nonrecursive schemas. The inventors now dene when a node a conforms to a shape (p in graph G; within the context ofa schema H; denoted by H; G,a |= (p. First, the evaluation ofa 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 ofshape expressions are given in Table 1. The following notations are used: def(s, H) denotes the shape expression dening shape name s in H.When s does not have a denition in H; def(s,H) = T (which is the behaviour ofreal SHACL). a c: The inventors use the notation [E] (a) to dende the set {b | (=b) [El]} WhenX is a set, the inventors use the notation iiX to denote the cardinality ofX. Table l. Conditions for conformance ofa node to a shape. <p H,0,0 |: <p if: hasValue(c) a= c test(t) 0 satises t hasShape(s) H,6,0 |: def(sH) # nsu{belEl°(a)|H.Gbt=w}5m innee " ' n 5 [E]°(a) | H.G,b i: eb} otherwise VEA!) every b e [E]°(a) satises H,G,b |=w eq(F,p) the sets [F](a) and lp]°(a) are equal disj(F.p) the sets [F]G(a) and |p]G(a) are disjoint closed(P) for all triples (ap b) G we have p P lessThan(E,p) b < (: for all b [E]G(a) and c [p]a(a) lessThanEq(EP) b $ 0 for all b |E]a(a) und c [p]°(a) uniqueLang(E) for every b ;é c [E]°(a) b and c have different language tags. In general, it is easy to see that ifa shape expression does not refer to other shapes, the inventors do not need to include the schema as part ofthe conformance denition: in that case G,a |= (p is well dened. Finally, the inventors can dene When a graph conforms to a schema.AnRDF graphG conforms to a shape schemaH iffor every shape denition (s, (p, r) H and for every a N such that H,G,a |= r the inventors have H,G,a |= (p. Since the inventors focus on nonrecursive schemas, the inventors can, forthe 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 denition ofthat shape name, resulting in a semantically equivalent shape expression. The inventors dene the expansion ofa shape expression (p in context ofa schemaH as the shape expression \| / Which replaces every shape name s occurring in the construct hasShape(s) in (p with def(s, H) resulting in the expression (p'. The inventors inductively apply this principle to (p' until the inventors end up with a shape expression that does not refer to any other shape denitions. As mentioned before, the inventors leverage the negation normal form

[50] ofa shape expression to acquire an efficient translation. The negation normal form ofa shape expression (p is the shape expression (p' in Which the inventors push every negation ofa subshape through. The inventors dene the negation normal form by giving the rewrite rules that need to be performed on (p to obtain (p'z - n((pl A (p2) becomes «pl V _(pZ; - ((pl V (p2) becomes «pl A _(pZ; - __(p becomes (p; - VE.(p becomes EIB.(p, - whenm = * and n# 0: #ËE- becomes # (Ti1580 V#ÎnHEW - whenm = * and = 0: #ÄHE'SO becomes #Ïn+1E'SÛ, and - whenm = * and # 07 "#ZLE-w becomes fig13¢. 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:minInclusive tests on literals that represent dates. In order give this translation, the inventors rst 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 denition ofthe RDF datamodel. The inventors adopt a standard pooling technique which associates a unique identier to allRDF nodes, which is then used in the central Triples relation. The full schema is given by the following relations: . IRIs(N0de: 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 identier given by the Node attribute. . Blanks(Node: int64, Alias: string). Similarly to the IRI table, the inventors keep track of blank nodes by associating an identier with them. ° Literals(N0de: int64, Value: string, Type: string, Lang: string). Again, similar to the IRIs table, the inventors keep track ofthe literals used in the graph. Furthermore, it relates node identiers to the value that they represent, the type thatthey are designated and the language tag thatmay be present. The language tag eld is notNULL preciselywhen the datatype attribute value is rdf:langString; as expected. ° Nodes(N0de: int64). This relation stores all node identiers. ° 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 identier used in the Node attribute ofone ofthe previous three relations. The inventors do not need to use node identiers in the predicate column, since property names cannot be treated as nodes in SHACL. ° Numerics(N0de: int64, Value: double). The primary purpose ofthis relation is to have quick access to anumeric (double) value associated with literals that represent numerics. The Node column is a subset ofthe Node column in the Literals table. This relation is used to support some ofthe node-tests that check for numeric constraints, like sh:lessThan of sh:minExclusive. In general, given anRDF graphG and a shape expression (p that does not refer to other shapes, the inventors translation gives us a unary SQL query Q,p that retrieves all nodes inG that satisfy (p. In the case ofshapes that do refer to other shapes in context ofa schemaH, the inventors can also translate the shape using the same techniques, by rst expanding the shape expression with respect to H. 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 ofthe Triples relation. For shape expressions (p ofthe form (pl A (p2; query Q,p is (Q ) INTERSECT( Qqû ). For shape expressions (p ofthe form (pl V (p2; query Q,p is ( Q) UNION ( Q<p2 ). Next, for the counting shapes ofthe form #Ëp. il), the inventors consider four cases. First, when n > 0,m $*, andm $ 11, query Q <p is select subject as node from triples, (om)) q(node) where predicate a p ahd object : q.!íodo group by having count)>= n AND CUUNTOI) <= m When n = m, the inventors replace the last line withHAVING COUNT(*) = 11; whenm = * (and thus n > 0), the inventors replace it withHAVING COUNT(*) >= n.When n = 0 (and thus m =*), the inventors instead have the query: SELECT Node FROM Nodesum Node NOT IN (Q#.'+1P°")) Indeed, the inventors cannot simply useHAVING COUNT(*) >= 0 in this case (compare the infamous count bug

[28] .) Lastly, when the subshape \| / is simply T, the inventors can leave out the subquery: (Q(\| / )) AS Q(Node). Next, for the case Where (p is ofthe form Vp.\| / the inventors have the query: SELECT Node FROM Nodes wma HOT EXISTS ( SELECT * FROM Triples. (Qs) AS QUIode) HEERE Predicate - p AND Subject - Node AND Object NOT IN Q ) 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) withX {i,b,l} representing the test whether a node is an IRI, blank node or literal, datatype(d) with d I checking whether anode has a certain datatype, e.g., xsdzinteger, minlncl(n), minExcl(n), maxlncl(n), maxExcl(n) which represent the value range constraint components ofSHACL

[37] ; 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 ags f); and nally languagein(L) which states that the literal must have one ofthe language tags from the set L. The test shapes are listed in Table 3 with the exception ofnumeric and string length constraints. For the numeric length constraints, like minExcl(n) the inventors get the following query: SELECTNodeFROM NumericsWHERE Value > n. It is clearwhat queries the inventors get for every one of its variations; the inventors simply need to change the > operator: minIncl(n) (inclusive; >=); maxExcl(n) (max exclusive <); maxIncl(n) (max inclusive <=).When combinations ofthese tests are used, the inventors can simply add boolean combinations in the where-clause, for example minlncl(n)AmaxExcl(m) becomes: SELECTNodeFROMNumerics WHERE Value <= nAND Value > m. Similartechniques are applied to the string length tests minLength(n) and maxLength(n). Table 2: Translation ofshape expressions to unary SQL queries. The inventors omit the case where (p is T. $P Qsc Q-up SELECT T1 Subject AS Node FR Triples AS T1, disj (P. q) :äcäogâÿ mîîïírîjîîtrî T2.Subject < ......) 3332231222315; AND T1.0bject - T2.0bject SELECT Subject AS NUDE SELECT Node FROM Triples disj(id,p) FROM Nodes WHERE Predicate = p EXCEPT ( Qd-ai(id.p) ) AND Subject = Object SELECT Node FROM Nodes HHERE NOT EXISTS ( (( SELECT Object FROM Triples SELECT Node FROM Nodes HHERE Predicate = p HEERE EXISTS (( AND Subject - Node sum e FROM Triples ) EXCEPT ( HHERE Predicate - p SELECT Object AND Object NOT IN ( FROM Triples SELECT Object From Triples HHERE Predicate = q HHERE Subject = Node q) AND Subject - Node AND Predicate = q ) )) UNION (( ) mon ( SELECT Object sam * FROM Triples FROM Triples WHERE Predicate = q HHERE Predicate - q AND Object NOT IN ( AND Subject - Node SELECT Object From Triples ) BGB?! ( HHERE Subject = Node SEM-12T Object AND Predicate = p ))) FROM Triples HHERE Predicate = p AND Subject - Node ))) SELECT Subject AS Node SELECT Node FROM Nodes FROM Triples AS T1 wma Node NOT IN ( HEERE Predicate - p SELECT t FROM Triples AND Subject = Object HBERE Subject = Node AND NOT EXISTS ( d ) AND Predicate = p P SELECT e ) OR EXISTS ( FROM Triples AS T2 SELECT = FROM Triples HHERE Predicate = p HEERE Predi t _ m T2.Subject - T1.Subject um nun:; 03. ) AND T2.0bject <> T1.0bject ) SELECT Subjects AS Node SELECT Node PRM Triples ed(P) FROM Nodes "HERE EXCEPT ( Qdogd(p) ) Predicate NOT IN (P) ) SELECT Node FROM Nodes HEERE ( 315315112531?) SELECT T1.Subject AS Node p PROM Triples as T1 , Numerics AS N Tri les As T2 wnm:-: T.Predicate - p N p 1 AS N; AND T.Subject - Nodes.Node Nazis AS m [ Th . ess an(pq) ) :le T.Ubject N.Node um: T1.Predicate _ p satecr NIN(N.Value) "D pudica ' " PREM Tri l AS T AND T1.0bject = N1.Node Numeriîsoîs N ' um T2.0bject - N2.Node HEERE T.Predicate _ q AND N1.Value >I N2.Value AND T.Subject = Nodes.Node AND T.0bject I H.Node) SELECT Node FROM Nodes SELECT Subject AS Node HEERE NOT EXISTS ( FR Triples AS T1, ssuzcr Lung Tripples AS T2, FROM Triples AS T, Literals AS Li, _ Literals AS L Literals AS L2 mw914111901) uma T.Predicate - p wma T1.Subject - T2.Subject AND T.Subject = Nodes.Node AND T1.Predicate = p AND T.Object = L.Node AND T2.Predicate = p AHD !..ng NOT NULL AND T1.0bject I L1.Node GROUP BY L.Lang AHD T2.0bject = L2.Nod.e HAVING couru-) > 1 ) AND 1.1.ng <> 1.2.ng 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 ofa shape denition. It supports all features discussed in the previous section. To loadRDF graphs into a DuckDB database, the inventors also wrote a simple translation tool. DuckDB automatically creates min-max indexes for all table columns. The inventors validated the correctness ofthe inventors implementation by running it against the SHACL core test suite. The inventors implementation passed 70 percent ofthe core tests. The non-passed tests eitherhave to do with property paths, or with tests on datatypes as already mentioned in the paragraphs relating to the translation. The inventors compare the inventors SQL approach to two otherSHACL engines: theApache Jena SHACL validator, as a representative ofa dedicated SHACL engine, and Trav-SHACL, as a representative ofthe SHACL-to-SPARQL approach

[58] . The inventors experiments measure the execution time ofvalidating a shape against a graph. For the SQL approach, the inventors measure the query execution time ofDuckDB. ForApache Jena the inventors rst parse the shape schema and load the data into aTDB Table 3. Translation ofshape expressions to SQL forthe hasValue and test features. In this table, ci I, cl L. The inventors omit nodeKind(b) and nodeKind(l). P Q9 Qv SELmT Node FROM Literals UNION SELECT Node SELECT Node FROM Blanks hasValue(a) FROM nus UNION WHERE Value = a SKIRT Node FROM IRIS HEERE Value <> q SKIRT Node FROM IRIs SELECT Node UNION FROM Literals SELECT Node FROM Blanks hasValue(CI) HEERE Valud . Ci-value UNION AND Type = q.datatype SELECT Node FROM Literals AND Lang = a.!anguage HHERE Value <> q.va1ue OR Type <> «datatype OR. Lang <> c,.language hasValue(b) QT QT SELECT Node FROM Blanks nodeKind(i) SELECT Node FROM nus UNION SE Node FROM Literals SKLWT Node FROM IRIS UNION SELECT Node datatype) FROM Literals SE Node FROM Blanks HEERE D t t - d UNION " ° "" SELECT Node mon Literals HEERE Datatype <> d SELT Node FROM Blanks SELECT Node FROM Literals UNION HEERE regex(Va1ue,p,f) SELET Node FROM Literals patternmf) UNION wms NOT regex(Value,p, f) SELECT Node FROM IRIS UNION HEERE regex(Value,p,f) SELECT Node FROM IRIS ERE NOT regex(Value,p,f) SEW Node FROM IRIS UNION . SELECT Node FROM Literals SELECT "°°° mn mn languagein(L) HEERE L IN (L) UNION S SELECT Node mon Literals HEERE Language NOT IN (L) OR Language IS NULL database, the inventors then measure the execution time ofthe ShaclValidator.validate mction. ForTrav-SHACL, the inventors rst setup a Jena Fuseki SPARQL endpoint which exposes the data, and parse the shape schema. The inventors then measure the execution time ofthe ShapeSchema.validate function. Other validation engines were also considered. PySHACL requires the graph to be loaded in main memory, and ran out ofmemory formost ofthe datasets. The inventors also observed that TopQuadrants engine performs very similarly to Jena, so the inventors omit TopQuadrant from the presentation ofthe results to avoid clutter. The inventors used an 8 coreAMD EPYC 2.595GHz processor with 16GB DDR4RAM and 400GB SSD to run all experiments. 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 ofSHACL 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 ofthe shapes are not supported by Trav-SHACL. The inventors can see thatDuckDB is an order of magnitude faster on most shapes, except, curiously, Shape 7. Table 4. The 10 synthetic shape denitions. All shapes target nodes oftype human, except for shape 7, which targets all objects ofthe email property. W Shape 2 #;manageng / T Shape 3 3friend.3ceoOf.hasValue(companyl) Shape 4 =disj(colleagueJend) Shape 5 closed(property1 propertyQ,property?) Shape 6 3phonc.T V 3email.T Shape 7 #àemail'.T Shape 8 eq(propertyl . lamperti / 2) Shape 9 uniqueLang(rstNanæ) Shape 10 lessThan(startWork. endWork) To show that the results ofthis synthetic experiment scale, the inventors generated datasets of20 million triples and ran the same experiments withDuckDB and JenaSHACL (not with Trav- SHACL, due to memory limitations). These results can be found in Figure 1 (b), also logarithmic scale. Remark 1. In Figure 1, the inventors see that for the synthetic experiments shape 7, Jena outperforrns 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 oftargets. It still does this in 1 second, but Jenajust 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 amore balanced dataset, the quirk disappears. The additional balanced dataset can be found in the supplementary material. Tyrol benchmark. The inventors also ran a selection ofshapes from the SHACL benchmark by Schaffenrath et al.

[52] . They dene 57 shapes over the Tyrolean Knowledge Graph which consists of30 million triples. The inventors selected arandom 10 million triple slice ofthis graph, and selected 10 ofthe 57 shapes that had the most targets in the inventors slice. The inventors then ran SQL approach and Jenaon 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. The performance results are shown in Figure 1 (c). The benchmark shapes are ordered left to right from most to fewestnumber oftargets. The inventors can see that JenaSHACL outperforms the SQL approach for halfofthe shapes. This can be explained by the fact that the last ve shapes have signicantly less target nodes to check, compared to the rst ve shapes. Jena SHACL is a specialized SHACL engine, and can quickly retrieve these targets and perform the validation. However, ifthe inventors adjust the shapes such that they target all subjects ofrdf:type, which lies closer to shape querying, Jena loses this advantage. This is illustrated in Figure l (d). The inventors report thatDuckDB ran out ofmemory for SportsActivityShape. Thismay be due to the large number ofconstraints used by this shape. 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 ofthe data needs to be checked for some shapes. This explainswhy the execution times are generally lower. DBLP dataDBLP published their database as a large RDF graph containing 400 million triples

[18] . ThisRDF graph contains information about publications and their authors. The inventors created three analytical shapes for this dataset: PersonShape: the shape expression #}pfl' A disj (p,a). with p representing primary afliation and a afliation. It is run against all nodes oftype Person' (which represent authors). TeamplayerShape: the shape expression 30.#§a.T, with a representing au- thored by, again run against all authors. PublicationShape: of a less analytical nature, this is the shape expression EldblpzauthoredByElrdf:type.hasValue(db1p:Person), run against all nodes of type Publication'. The inventors run these shapes on purpose against large sets oftargets (all authors, or all publications) to get information on shape querying performance. The inventors used a slice ofthe DBLP database that contains all publications togetherwith their author information forthe years 2022 and 2023. This results in anRDF graph of 8.5 million triples. The results are given in Figure 2. Again, DuckDB signicantly outperforms Jena SHACL, also on PublicationShape. References: 1. Abbas, A., Geneves, P., Roisin, C., Laya"1da, N.: Selectivity estimation forSPARQL triple patterns with shape expressions. In: Mikkonen, T., et al. (eds.) Proceedings 18th International Conference onWeb Engineering. Lecture Notes in Computer Science, vol. 10845, pp. 195209. Springer (2018) 2. Ahlstrom Jakobsen, K., Andersen, A., Hose, K., Bach Pedersen, T.: OptimizingRDF 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) 3. Ahmetaj, S., David, R., Ortiz, M., Polleres, A., Shehu, B., Simkus, M.: Reasoning about explanations for non-validation in SHACL. In: Bienvenu, M., Lakemeyer, G., et al. (eds.) Proceedings 18th International Conference on Principles ofKnowledge Representation and Reasoning. pp. 1221. IJCAI Organization (2021) 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. 375391. Springer (2022) 5. Ahmetaj, S., Lo"hnert, B., Ortiz, M., Simkus, M.: Magic shapes forSHACL validation. Proceedings of theVLDB Endowment 15(10), 22842296 (2022) 6. Ahmetaj, S., Ortiz, M., Oudshoorn, A., Simkus, M.: Reconciling SHACL and ontologies: Semantics and validation via rewriting. In: Gal, K., Nowe, A., et al. (eds.) Proceedings 26th European Conference on Articial Intelligence. Frontiers in Articial Intelligence and Applications, vol. 372, pp. 2735. IOS Press (2023) 7. Andresel, 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.) ProceedingsWWW20. pp. 15701580. ACM (2020) 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. 30913105. IEEE (2022) 9. Bahadur Thapa, R., Giese, M.: Optimizing SPARQL queries with SHACL. In: Payne; T., Presutti, V., Qi, G., et al. (eds.) Proceedings 22nd International SemanticWeb Conference. Lecture Notes in Computer Science, vol. 14265, pp. 4160. Springer (2023) 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. 4147 (2021) 11. Boncz, P., Erling, O., Pham, M.D.: Advances in large-scaleRDF data management. In: Auer, S., Bryl, V., Tramp, S. (eds.) Linked Open Data, Lecture Notes in Computer Science, vol. 8661, pp. 2144. Springer (2014) 12. Boncz, P., Kersten, M., Manegold, S.: Breaking the memory wall in MonetDB. Communications of theACM 51(12), 7785 (2008) 13. Boncz, P., Zukowski, M., Nes, N.: MonetDB / X100: Hyper-pipelining query execution. In: Proceedings 2nd Biennial Conference on Innovative Data Systems Research. pp. 225237. www.cidrdb.org (2005) 14. Boneva, I., Gayo, J., Prudhommeaux, E.: Semantics and validation of shape schemas for RDF. In: dAmato, C., Fernandez, M., Tamma, V., et al. (eds.) Proceedings 16th International SemanticWeb Conference. Lecture Notes in Computer Science, vol. 10587, pp. 104120. Springer (2017) 15. Chmurovic, A., Simkus, M.: Well-founded semantics for recursive SHACL. In: Alviano, M., Pieris, A. (eds.) Datalog 2.0 2022: Fourth International Workshop on the Resurgence of Datalog inAcademia and Industry. CEUR Workshop Proceedings, vol. 3203, pp. 213 (2022) 16. Corman, J., Florenzano, F., Reutter, J., Savkovic, O.: Validating SHACL constraints over a SPARQL endpoint. In: Ghidini et al.

[30] , pp. 145163 17. Corman, J., Reutter, J., Savkovic, O.: Semantics and validation ofrecursive SHACL. In: Vrandecic, D., et al. (eds.) Proceedings 17th International SemanticWeb Conference. Lecture Notes in Computer Science, vol. 11136, pp. 318 336. Springer (2018), extended version, technical report KRDB18-01, https: / / www.inf.unibz.it / krdb / tech-reports / 18. DBLP data in RDF. http: / / dblp.org / rdf / 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:110:8. ACM (2017) 20. Dedecker, R., Slabbinck, W., Wright, J., et al.: Whats in a Pod?Aknowledge graph interpretation for the Solid ecosystem. In: Saleem, M., et al. (eds.) Proceedings 6th Workshop on Storing, Querying and Benchmarking Knowledge Graphs. CEUR Workshop Proceedings, vol. 3279, pp. 8196 (2022) 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. 285297. OpenProceedings.org (2023) 22. Eich, M., Fender, P, Moerkotte, G.: Efficient generation ofquery plans containing group- by, join, and groupjoin. TheVLDB Journal 27(5), 617641 (2018) 23. Erling, O.: Implementing a SPARQL-compliantRDF 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), 38 (2012) 25. Erling, O., Mikhailov, I.: RDF support in the VirtuosoRDBMS. In: Auer, S., Bizer, C., Muller, C., Zhdanova, A. (eds.) Proceedings 1st Conference on Social Semantic Web. Lecture Notes in Informatics, vol. P-113, pp. 5968. GI (2007) 26. Fent, P, Neumann, T.:A practical approach to groupjoin and nested aggregates. Proceedings of theVLDB Endowment 14(11), 23832396 (2021) 27. Figuera, M., Rohde, P, Vidal, M.E.: Trav-SHACL: Efficiently validating networks of SHACL constraints. In: Leskovec, J., et al. (eds.) ProceedingsWWW21. pp. 33373348. ACM (2021) 28. Ganski, R., Wong, H.: Optimization of nested SQL queries revisited. SIGMOD Record 16(3), 2333 (1987) 29. Gayo, J., Prudhommeaux, E., Boneva, I., Kontokostas, D.: ValidatingRDF data. Synthesis Lectures on the SemanticWeb: Theory and Technology 16 (2018) 30. Ghidini, C., Hartig, O., Maleshkova, M., Svatek, V., et al. (eds.): Proceedings 18th International SemanticWeb Conference, Lecture Notes in Computer Science, vol. 11778. Springer (2019) 31. Gray, J., et al.: Data cube:A relational aggregation operator generalizing groupby, cross- tab, and sub totals. DataMining and Knowledge Discovery 1(1), 2953 (1007) 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.

[30] , pp. 258275 34. Ibragimov, D., Hose, K., Bach Pedersen, T., Zimanyi, E.: Processing aggregate queries in a federation ofSPARQL endpoints. In: Gandon, F., Sabou, M., Sack, H., et al. (eds.) Proceedings 12th European SemanticWeb Conference. Lecture Notes in Computer Science, vol. 9088, pp. 269 285. Springer (2015) 35. Kemper, A., Neumann, T.: HyPer:A hybridOLTP&OLAPmain memory database system based on virtual memory snapshots. In: Proceedings 27th International Conference on Data Engineering. pp. 195206. IEEE Computer Society (2011) 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 theVLDB Endowment 11(13), 2209 2222 (2018) 37. Knublauch, H., Kontokostas, D.: Shapes constraint language (SHACL).W3C Recommendation (Jul 2017) 38. Kohn, A., Leis, V., Neumann, T.: Tidy tuples and ying start: Fast compilation and fast execution ofrelational queries in Umbra. TheVLDB Joumal 30(5); 883905 (2021) 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 SemanticWeb Conference. Lecture Notes in Computer Science, vol. 12506, pp. 366383. Springer (2020) 41. Lieber, S., Dimou, A., Verborgh, R.: Statistics about data shape use in RDF. In: Taylor, K., et al. (eds.) Proceedings oftheISWC 2020 Demos and Industry Tracks: From Novel Ideas to Industrial Practice. vol. 2721. CEUR Workshop Proceedings (2020) 42. Moerkotte, G., Neumann, T.: Accelerating queries with group-by and join by groupjoin. Proceedings of theVLDB Endowment 4, 843851 (2011) 43. Morfonios, K., et al.: ROLAP implementations of the data cube.ACM Computing Surveys 39(4), 12:112:53 (2007) 44. Neumann, T., Weikum, G.: The RDF-3X engoine for scalable management ofRDF data. TheVLDB Journal 19(1); 91113 (2010) 45. Pareti, P, Konstantinidis, G.:Areview ofSHACL: From data validation to schema reasoning forRDF graphs. In: Simkus, M., Varzinczak, I. (eds.) Reasoning Web: Declarative Articial Intelligence. Lecture Notes in Computer Science, vol. 13100, pp. 115144. Springer (2022) 46. Pareti, P, Konstantinidis, G., Mogavero, F.: Satisability and containment ofrecursive SHACL. Journal ofWeb Semantics 74, 100721 (2022) 47. Raasveld, M., Mu"hleisen, H.: DuckDB: An embeddable analytical database. In: Proceedings 2019 International Conference onManagement of Data. pp. 1981 1984.ACM (2019) 48. Rabbani, K., Lissandrini, M., Hose, K.: Optimizing SPARQL queries using shape statistics. In: Velegrakis, Y., ZeinalipourYazti, D., et al. (eds.) Proceedings 24th International Conference on Extending Database Technology. pp. 505510. Open- Proceedings.org (2021) 49. RDF 1.1 primer.W3C Working Group Note (Jun 2014) 50. Robinson, J., Voronkov, A. (eds.): Handbook ofAutomated Reasoning. Elsevier andMIT Press (2001) 51. Rohde, P, et al.: SHACL-ACL: Access control with SHACL. In: Pesquita, C., Skanolli, H., et al. (eds.) The SemanticWeb: ESWC Satellite Events. Lecture Notes in Computer Science, vol. 13998, pp. 2226 (2023) 52. Schaffenrath, R., Proksch, D., Kopp, M., Albasini, I., 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. 8296. Springer (2020) 53. SHACL test suite and implementation report.W3C Document (Jan 2024) 54. Shacl2sparql. https: / / github.com / rdfshapes / shacl-sparql 55. ShExshape expressions. https: / / shex.io (Apr 2024) 56. Stonebraker, M., et al.: C-Store:Acolumn-orientedDBMS. In: Bo"hm, K., Jensen, C., et al. (eds.) Proceedings 31th International Conference on Very Large Data Bases. pp. 553564. ACM (2005) 57. TPC benchmarkH decision support standard specication revision 3.0.1. Transaction Processing Performance Council (19932022) 58. Trav-shacl implementation. https: / / github.com / SDM-TIB / Trav-SHACL 59. Werbrouck, J., et al.: Pattern-based access control in a decentralised collaboration environment. In: Poveda-Villalon, M., Roxin, A., et al. (eds.) Proceedings 8th Linked Data in Architecture and Construction Workshop. CEUR Workshop Proceedings, vol. 2636, pp. 118131 (2020)

Claims

1. A computer-implemented method for validating one or more SHACL- graphs (Shapes Constraint Language) on one or more RDF graphs (Resource Description Framework) in a relational database system, where the SHACL graphs include at least one shape-target parameter pair that a includes shape parameter that is representative of a constraint to which a node of the The RDF chart must satisfy and a target parameter that is representative of which node in the The RDF graph must be validated against the shape parameter of the said SHACL graph; and where the RDF graphs comprise multiple RDF terms; the working method comprising: - representing one or more RDF graphs in a relational database schema by identifying one or more nodes for each of the multiple RDF terms, where the nodes are at least one of the following: a subject, a predicate and an object, where the subject and object are represented by at least one of the following two: an Internationalized Resource Identifier, IRI, a literal or empty node identifier and the predicate is represented by a literal; - associating each node of the identified multiple nodes with a unique node identifier; - store a relationship between the associated unique identifier and each node such that that the RDF graphs are displayed in a relational database schema; - compile one or more SHACL charts into SQL expressions by the SHACL- to convert the graph into a normal negation form,NNF, by applying negations only to atomic constraint components of the at least one shape-target parameter pair, and each atomic to translate the ignored atomic constraint into an SQL expression using a lookup table; and - validating that an RDF chart matches a SHACL chart by the SQL- to execute expressions on the relational database schema and identify that each node satisfies the constraints defined by the at least one form-target parameter pair of the SHACL chart.

2. The computer-implemented method of conclusion 1, whereby the step of associating of each node of the multiple nodes with a unique identification code and storing of the relationship between the associated unique identifier and each node, at least one of the following steps includes: - 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 the relate to the respective unique node identifier; - storing all nodes that are literals as third-value attributes and relate to the respective unique node identifier; - storing all 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 in accordance with one of the preceding conclusions, whereby A node in an RDF graph satisfies the constraints if it satisfies all conditions specified by the SHACL forms, whereby the conditions to the restrictions to meet at least one of a form conformity, a property restriction, a include a logical condition, a cardinality constraint, and a comparison constraint.

4. The computer-implemented method in accordance with one of the preceding conclusions, whereby compiling one or more SHACL charts in SQL expressions mapping atomic constraints shzlessThan and shzequals to SQL comparisons or joints, respectively includes; translating SHACL logic operators shzand, shzor and shznot into respectively SQL INTERSECT, UNION, and NOT EXISTS operations; translating SHACL constraints where counts play a role, such as sh:minC0unt and sh:maxCount to GROUP respectively BY- andHAVING SQL aggregations.

5. The computer-implemented method in accordance with one of the preceding conclusions, whereby one or more indications are executed that the graph satisfies all constraints.

6. The computer-implemented method in accordance with one of the preceding conclusions, whereby one or more violations are performed, where a violation is a node that does not comply meets the limitations.

7. A computer program that is a computer-executable program of instructions involves, when executed on a computer, the steps of the procedure according to one of the to implement the preceding conclusions. 1 / 2 FIG.1

Images