Modern Datalog: Concepts, Methods, Applications

The one feature that immediately stands out when introducing Datalog is its simplicity. Anyone who understands the basic idea of encoding information in relational facts, such as $\text{hasFather}(\text{alice},\text{bob})$, will have little difficulty in interpreting rules such as

at least after being told that variables $x,y,z$ are placeholders for arbitrary elements, and that $\leftarrow$ means if and the comma means and. Datalog programs are essentially collections of such rules, intended to be applied exhaustively to a given set of facts.¹¹1Implementations may not always literally “apply rules exhaustively” to produce their outputs, but the idea can always serve as an intuitive view of the semantics of Datalog and many of its extensions. Entailments produced by applying one rule may potentially allow us to apply other rules in new ways. A trademark feature of Datalog then is that programs may be recursive in the sense that a rule’s application may (indirectly) lead to entailments that require us to apply the same rule again. Nevertheless, it does not matter how we chose to apply rules: after finitely many steps, we will always arrive at a unique set of entailed facts – the output of the Datalog program.

Given this simple framework, it is astonishing that Datalog has been applied to solve many complex tasks, such as database query answering, source code analysis, and ontological reasoning, which typically require much more complicated programming and query languages. Versatility and simplicity together may explain why Datalog continues to be widely used and implemented even decades after its inception, with new systems coming up regularly.

Nevertheless, aspiring users of Datalog are often faced with considerable difficulties, since the landscape of Datalog languages and systems is fractured. Even basic syntax is all but uniform. Figure 1 illustrates how rule (1) would be expressed in various standards and tools.²²2Figure 1 omits the excessively verbose XML syntax of the W3C standard RIF [39]; RIF’s more readable Presentation Syntax supports rules as in L3. The traditional syntax in L1 was coined over 40 years ago for Prolog, but more recent systems have sought alignment with standards like SQL, SPARQL, or JSON that support Unicode, IRIs, and specific data structures. Moreover, Datalog is often extended with further features, such as negation, aggregation, or datatype-related functions, which tend to have even more varied syntax. Thankfully, there is still a broad agreement on the semantics of basic rules, with only very few exceptions. Nevertheless, there are important differences in terms of computational abilities and interfaces that modern tools provide, since no system is built to address all relevant uses of Datalog, so practitioners have to choose carefully.

The goal of these lecture notes is to offer an overview of contemporary Datalog – the evolved version(s) of Datalog as used in today’s applications – with its main features and usage scenarios, and some of the underlying concepts and mechanisms. Our preferred perspective will be that of a researcher or practitioner who considers using Datalog for their own purposes, as opposed to the perspective of a developer of Datalog reasoners. We therefore aim to convey an understanding of the logical language and the technical capabilities of modern systems, and of the requirements and considerations that have led to their current state. Readers may thus find guidance for their own work with Datalog and its extensions, and, ideally, some inspiration for new research and applications.

Throughout this text, we will look at some worked examples that illustrate how the theory can be put into practice. For this purpose, we will use the Web app of the rule reasoner Nemo [35], which can be accessed online at https://tools.iccl.inf.tu-dresden.de/nemo/. The Web application can execute complex Datalog programs in the browser and display the results. Alternatively, Nemo releases can also be downloaded and run locally as a command-line tool. Nemo’s user manual can be found at https://knowsys.github.io/nemo-doc/.

For a first example, consider the program about simple family relations in Listing 1. A short link to this online example is https://tud.link/ctdxps, but it is also possible to simply copy the program manually. The Web application consists of a rich Datalog editor field and several controls, as shown in Fig. 2. Most important is the “play” button in the lower left, which starts the reasoner. Once reasoning is finished, results are displayed below. By default, all derived relations are displayed. All reasoning is performed locally, without any data being sent to a server.

The workings of the example program should not be hard to follow, even without having introduced Datalog formally yet. The initial facts (L9–L11) provide some basic information on simple entities. Rules L13 and L14 derive facts about parenthood, and rules L15 and L16 define ancestor as the transitive closure of parent. Finally, L18 is asks for common ancestors of Alice and Finley. Lines with % are comments.

As a small exercise, readers are invited to try to add rules to define relations sibling and auncle (the binary relation between a niece or nephew and their aunt or uncle). Inequality != can be used to prevent anybody from becoming their own sibling. If correct, auncle(alice,finley) should be derived.

Before turning towards concrete technical questions, we should take a moment to ask ourselves what benefits we expect from a logic-based language like Datalog, and what grounds we have for deeming it superior – at least in some aspects – over obvious alternatives. Surely, whatever we are up to could also be realised by a suitable program in a modern imperative language like Python or Rust, and possibly, if our needs are more modest, by a database query language like SPARQL or SQL. In this section, we will therefore look into (hoped for) benefits and potential application areas where matching requirements arise.

After the applied perspective taken above, we are going to approach Datalog from the viewpoint that is typical in research, introducing the relevant terminology and underlying mathematical concepts. Equipped with the necessary language, we will find it easy to specify the semantics of Datalog, and we will do so in four different but equivalent ways.

In Section 2, input data was given in the form of facts in the Datalog program itself. This is practical for small, static data, but not for datasets with millions of facts or managed in external systems. Many Datalog systems therefore support data imports from other sources, typically defined by adding suitable importing directives to Datalog programs. In Nemo, data can come from files (e.g., in CSV format) or from online data services. Files in turn may be local or online (to use local files in the Web application, they first need to be added through the user interface). Next, we will scale up our earlier family example to use real data from Wikidata [70].

The free knowledge base Wikidata is a sister project of Wikipedia, and collects general knowledge the whole range of encyclopaedic topics. To use this information in Nemo, we take advantage of the Wikidata Query Service [50], which lets us retrieve real-time answers for queries in the W3C SPARQL query language [32]. Familiarity with SPARQL or Wikidata is not required here, but some general aspects should be clarified.

First, Wikidata is a multilingual knowledge base that uses language-independent identifiers (so-called QIDs) for all concepts. For example, the QID of the city of Istanbul is Q406, whereas the Reasoning Web summer school is Q105700533. To find QIDs, one can simply use the search function on wikidata.org, or follow the links found on any Wikipedia article (“Wikidata item” under “Tools”). When querying Wikidata, we will mainly use IDs, formatted as IRIs such as http://www.wikidata.org/entity/Q406. Human-readable labels are fetched separately, mainly for display.

Second, Wikidata stores data by assigning property values to items, where properties also are identified by dedicated ids. For example, on item Q406, the property head of government (P6) has the value Ekrem İmamoğlu (Q59313241). For our purposes, we will need properties P22 (father) and P25 (mother). Viewing item pages on Wikidata is the easiest way to find out what data is available and how it is encoded.

The re-designed version of our family example can be seen in Listing 2 and online under https://tud.link/wkrajt. In this version, the program finds all known common ancestors of Ada Lovelace and Moby (a non-empty set!). The actual Datalog rules in L53–L58 are similar to those in Listing 1. The main difference is that we now start with two explicit elements (L53–L54), and that we need to fetch the name of each common ancestor in the end (L57). The elements we start with are defined as program-wide parameters (L2–L2), set to the ids of our persons of interest, which we abbreviated using a prefix (L32). Parameters are useful here since we need the terms in several rules, and since it is convenient to define them at the top for easy modification. Parameters can also be set when calling Nemo from the command line, so that one Nemo program can be used for various retrieval tasks.

The import of information from Wikidata is defined in L38–L50. We declare two imported predicates, wdParent and wdLabel. Both have arity two, which is derived from the number of variables selected in the SPARQL queries. The imports each declare an endpoint (the URL of the query service) and a query (as multi-line string enclosed in """). The second query uses a Wikidata-specific way of fetching labels based on a virtual service [50].

Semantically, these statements mean that the two predicates represent the complete result of the two queries. However, Nemo does not actually run the queries as stated, but evaluates such imported predicates on demand. Therefore, instead of downloading all (>1.8M) parent-relations, only those needed for applications of rules L53–L55 are fetched. To do this, Nemo will augment the query with bindings provided from partial matches of the respective rule body. This is also important for rule L57, since it is not practically feasible to download all labels through the query service (at the time of this writing, there are 634,823,210 labels in Wikidata). Nevertheless, Nemo ensures that the computed outputs are not affected by the internal choice of query strategy. In particular, if one were to return imported predicates as output, then all data would have to be fetched.

A general consideration when using SPARQL and Datalog in combination is that SPARQL itself is fairly powerful, so that one may have a choice of performing some operations in import queries instead of using Datalog rules. In fact, the program in Listing 2 can equivalently be expressed in a single SPARQL query of just a few lines. However, this query reliably runs into a timeout on Wikidata’s query service, whereas the Datalog-driven query approach completes in under a minute. Another reason for using Datalog instead of SPARQL is that this allows us to combine data from different sources, as shown in a later hands-on in Section 9.

As an exercise, readers can try to extend the program by fetching additional information, such as the date of birth (P569) for every ancestor before it is returned. As a bigger variation, one can create a program that fetches all of a person’s blood relatives (ancestors and all of their descendants). Try it on Johann Sebastian Bach (Q1339).

Pure Datalog is too limited for many purposes, and many further features have therefore been considered for extending it. This comes at a risk: the elegant semantic characterisations discussed in Section 4.2 may fail, and in the worst case declarativity and all the associated benefits (Section 3.1) may be lost.

As the previous example shows, the neatly aligned semantic views may easily diverge or cease to make sense when extending Datalog, and the result of previously correct computation procedures may depend on irrelevant details such as rule order. A major goal in designing Datalog-like rule languages has often been to prevent such breakdowns, or at least to give up as little declarativity as possible. There are exceptions, and some authors have argued that a fully operational semantics (as in “the semantics is what the algorithm does”) is acceptable in exchange for the greater freedom of expression that this gives to programmers (e.g., [21]).

For negation (and also aggregation; see Section 8), there is a widely accepted well-behaved case that illustrates how a careful extension of Datalog might work. Let us first define the syntax.

Cases like Example 28 indicate that it is problematic to combine recursion with negation as failure (the idea that the absence of a fact may be assumed once all attempts to prove it have failed). A possible solution is to require that rules can be organised in “layers” where negation may only refer to facts that were computed in lower layers, and it is ensured that these facts are never affected by the higher rules. We can achieve that by assigning numbers to head predicates.

A common way to find a stratification is to express the constraints of Definition 31 in a graph that has predicate names as vertices and edges labelled $\ge$ or $>$ based on their co-occurrence in rules. Stratification is possible if this graph has no cycle through an $>$-edge, and a suitable level mapping can in this case be obtained from a topological order of the strongly connected components of the graph. A stratification can be used to compute the output of Datalog programs by processing rules layer by layer. For the next definition, recall that $P(𝒟)$ denotes the output database returned by $P$ on input $𝒟$.

By stratification, negated atoms in $P[i]$ can only refer to predicates whose ultimate value has been computed for the intermediate database ${𝒟}^i$, and absence of an atom can safely be taken as a guarantee that it is really false. Implementing this semantics is not harder than implementing pure Datalog: all it needs is an iterated computation of Datalog outputs and a slightly extended check to find matching rules.

The semantics of Definition 32 can also be characterised by a suitable model theory. However, we now have to restrict to a special subset of all Herbrand models, the so-called stable models, which are also used in answer set programming [45, 23]. It turns out that a stratified Datalog^¬ program has a unique stable model – also known as the perfect model –, which contains exactly the output facts obtained as per Definition 32. A corresponding second-order characterisation that encodes the definition of stable model is conceivable but likely not very enlightening.

We lose the elegant proof-theoretic characterisation of Section 4.2.3. In the context of Prolog, negation as failure can be supported by so-called SLDNF resolution, which constructs tree-like computational schemes [4]. However, negated atoms in this case are proven by a sub-procedure that fails to find a proof for their non-negated version. It seems that such a “failure to prove” cannot be certified elegantly in a closed form. Nemo offers proof-tree like explanations for such inferences by allowing users to inspect all non-negated atoms that were derived for the predicate in question. Depending on the goal of explanation, other approaches might be possible, e.g., counterfactual analyses that explain how the input could have been changed to derive the missing fact, which is closely related to the concept of abduction [29]. Further approaches have been developed for database query results in the context of Why-Not provenance [15], but none seems to offer a solution that is as elegant and versatile as proof trees for pure Datalog.

Real applications often involve many concrete forms of data, such as numbers, strings, calendar dates, or geographic coordinates. The abstract Datalog framework introduced so far can already handle such dates by simply considering them as special kinds of constants, but such an untyped approach does not offer any means to inspect or create new data values. For example, we might want to check if a string starts with the letter A, or create a number that is the sum of two other numbers. In this section, we explain how such features are commonly added to Datalog, and what this means for a logic-based view.

In databases, aggregation is a computation that maps groups of tuples (database rows) to single values. The simplest example is COUNT, which counts the tuples per group. Other common aggregates include SUM, MIN, and MAX. Aggregation functions are supported in many Datalog engines, but some additional complications need to be taken care of.

Let us consider a weakly typed setting with a single domain $\mathrm{\Delta }$ of database elements. To apply aggregation on a relational database model, the following details must be specified:

• $\mathrm{■}$

  an input relation (set of tuples) $R\subseteq {\mathrm{\Delta }}^n$ of arity $n$,

• $\mathrm{■}$

  two disjoint lists of positions, $G$ (“group by”) and $A$ (“aggregate”), from the set $\{1,\mathrm{\dots },n\}$, and

• $\mathrm{■}$

  an aggregation function $f:2^{{\mathrm{\Delta }}^{|A|}}\to \mathrm{\Delta }$, which maps from $|A|$-ary relations to individual domain elements.

In practice, aggregate functions are often defined over arbitrary arities $|A|$. This may be obvious (e.g., for COUNT) or it may require some additional specification (e.g., SUM might sum up all values in all tuples or only the values in the first column). The result of aggregation is then defined as follows:

Therefore, the grouping function $g$ assigns a set of $A$-tuples to every $G$-tuple, and this set is then aggregated into a single domain value to obtain output tuples. Note that we do not require that all positions of $R$ occur in $G$ or $A$: positions that do not occur, would simply be projected away. This is particularly significant since Definition 38 is based on sets, so that grouped tuples $g(𝒔)$ may not contain duplicates. We further discuss this aspect in the next section with the help of concrete examples.

Using our knowledge of negation and aggregation, we can turn the analysis of CO${}_{\text{2}}$ emissions from Example 39 into a program over real data. Suitable emission figures are researched and published by Carbon Majors (https://carbonmajors.org/Downloads) in the text-based CSV format. Unfortunately, this data contains merely the names of companies (and other organisations), but does not specify which country they have their headquarters in. To get this information, we need to integrate the data with content from Wikidata.

The hands-on therefore illustrates two further capabilities of Datalog: data integration and distributed query answering. Data integration is difficult since it is hard to make connections between elements of different data sources. For example, the Carbon Majors refers to an organisation named Chevron of type Investor-owned Company, but Wikidata knows eleven entities of that name, including a painting by Peter Wells and a genus of moss-dwelling animals, but no company. However, there are over 1000 entities that contain Chevron in their name, including companies, such as Chevron Corporation, Chevron U.S.A Inc., and Chevron Engineering Ltd. Obviously, it can be hard or impossible to match such elements in a fully automated way.

This is a known challenge, and unique identifiers have been established in many domains to refer to entities unambiguously. Well known IDs include ISBN numbers for books and ORCIDs for academic researchers. Overall, Wikidata knows over 9,500 distinct identifiers that items can be connected to. For companies and other legal organisations, the Legal Entity Identifier (LEI) is relevant, and this identifier is contained in the Carbon Majors data in many cases, but not in all.

Our data processing strategy therefore is as follows. First, we look for Wikidata entities with a LEI as specified by Carbon Majors. Second, for the cases where no match was found, we match organisation names with the names of businesses in Wikidata (only exact matches). To increase confidence, we only use matches that are unique. Third, we query Wikidata for country information about the matched organisations, and finally we compute the aggregated emission values per country. These four stages form natural levels in a stratification.

The complete Nemo program can be seen in Listing 3 and at https://tud.link/r44q79. We aggregate the data for year 2023 (L77). To fit a single page, some (otherwise unnecessary) abbreviations are used. In particular, the string concatenation function CONCAT is used in many places. A longer string that we use in all SPARQL queries is defined in L78.

The relevant data sources are declared in the imports on L86–L108. A new feature here is the CSV import (L86), which fetches an online file.¹⁸¹⁸18The URL from which we import here holds an unmodified copy of the file found at https://carbonmajors.org/evoke/391/get_cm_file?type=Basic&file=emissions_low_granularity.csv. Using the original URL instead only works in Nemo command line, since most browsers will block Nemo Web from loading this file due to a server misconfiguration at Carbon Majors. CSV is a string-based format that does not include type information, hence we specify how each column should be interpreted (L89); this also informs Nemo about the arity ($5$) of the imported predicate cmData.

The SPARQL imports use similar queries as in the hands-on in Section 5. Relevant new Wikidata properties are P17 (country) and P1278 (Legal Entity Identifier). The query for wdBusiness, which we use to find business by their name, includes some extra conditions to restrict to items classified as business (Q4830453) on Wikidata.

The rules in L110–L121 implement the processing stages outlined above. They should mostly be easy to understand, but there are some features that we have not explained before. First, some of the rules are using Nemo’s negation operator, written as ~. Second, several rules use anonymous variables, indicated by an underscore _. This common abbreviation from logic programming is used to indicate distinct variables that occur only once in a rule, so each underscore denotes a different variable. Finally, we use functions STRLANG (L112) and STR (L119). These are related to a new type of data that we have not encountered yet: the language-tagged string. These are pairs of string and language identifiers, such as "Germany"@en or "Allemagne"@fr. All labels in Wikidata have this form, so in L112 we use STRLANG to construct a language-tagged string (with tag en) to query wdBusiness. Conversely, we use STR to extract plain strings (this function can also be used to turn other values into string representations). It is very common in data integration that datatypes do not match and need to be converted with suitable functions.

As a final remark, note how we use negation and aggregation in rule L120 to sum up all emissions from organisations for which no country could be found. This is an important measure to see how much has still been missed, so as to avoid drawing premature conclusions from the remaining outputs. In general, Datalog makes it convenient to compute details about unexpected or mismatched cases. In data analysis, errors and mismatches can occur easily, and it is often difficult to judge if final results are correct or not. Diligent analysts will therefore double check all outputs, e.g., by computing additional views.

As an exercise to the reader, the program in Listing 3 can be modified and improved in several ways. One option is to further weigh annual emissions by the country’s size, measured in terms of its inhabitants (the Wikidata property for population is P1082). Another option is to compute and analyse cases where the matching with Wikidata has failed, and to think of ways of covering these cases. With very little information to go by on the CSV side, it might be necessary to consider manual mappings for some of the remaining organisations. Since Wikidata, like Wikipedia, can be edited, it is also possible to complete or correct LEI information there to improve the matching.

Facts in Datalog might assume two truth values – true or false –, but many other systems of truth values have been studied. For example, facts in fuzzy logic may have a fuzzy degree of truth, expressed as a real number between $0$ (“false”) and $1$ (“true”). In databases, the influential work of Green et al. popularised the idea that database query results, too, might be qualified by a “provenance” value [30]. Such provenances might express degrees of truth (confidence, probability, degree of membership, etc.), but also many other concepts such as quantity (how often a fact was obtained), access restrictions (who is allowed to see the fact), explanations (how was a fact was derived).

The key to such approaches is to generalise not just the possible truth values but also the boolean algebra that is used to combine values. Green et al. proposed to focus on generalisations of conjunction and disjunction, with the resulting algebraic structure being that of a commutative semiring.¹⁹¹⁹19A commutative semiring is an algebraic structure $(K,\oplus ,\otimes ,0,1)$ over a set $K$ two binary operations $\oplus$ and $\otimes$ on $K$ and two distinguished elements $0,1\in K$ (the neutral elements for $\oplus$ and $\otimes$, respectively). One further requires that $\oplus$ and $\otimes$ are commutative, that $\otimes$ distributes over $\oplus$, and that all products with $0$ yield $0$ [30]. The same two operations are also required for generalising Datalog. Conjunctions are obviously needed to compute the truth value of rule bodies: every match of a rule may now receive a certain value, computed by combining the values of its individual atoms. Disjunctions come into play when a fact is inferred in multiple ways: the values of each inference are disjunctively combined to obtain a single overall value. Therefore, when applying rules in such a setting, we are not merely adding new inferences, but also updating the values of previous inferences. Green et al. propose a corresponding generalisation of Datalog, which additionally requires that the underlying semiring supports fixed points to which iterated computations can converge [30].

This leads to a very powerful generalisation of Datalog, and some research has been conducted to determine which algebraic properties are relevant to obtain a meaningful semantics and efficient algorithms. However, as of 2025, systems based on this idea seem to be elusive. Khamis et al. propose Datalog^∘, which is based on certain pre-semirings, and report practical experiments on “an unreleased commercial system” [38]. The most advanced actually available implementation of a similar principle seems to be Flix, which introduces programmer-defined lattice structures that act as a (special type of) semiring [48]. Lattice values in Flix are syntactically represented as special parameters, but their built-in semantics is similar to truth-value generalisations.

Other generalisations of truth values can also be found in many works that are not based on semiring provenance, e.g., related to reasoning with probabilities or validity times. A notable practical systems of that type is ProbLog, which can be used as a reasoner for Datalog over facts that are “weighted” by probabilities [25]. Approaches for temporal and stream reasoning often annotate facts with sets of time points (or intervals) where they are valid, with examples including LARS [5] and DatalogMTL [71], for which a Python-based reasoner has been presented recently [72].

This chapter has given an overview of Datalog and some of its most common functional extensions, including stratified negation, datatypes, aggregation, and generalised truth values. All of these extensions have in common that major mathematical principles and fundamental usage patterns remain the same – the result is still a “Datalog-like language”. This is in contrast with many other languages that also contain Datalog as a special case, and could therefore rightfully be called extensions of Datalog. Answer Set Programming (ASP), e.g., generalises Datalog, too, but the application areas and ways in which ASP is used in practice are significantly different [23]. Following the definition of the semantics in Section 4.2.2, first-order logic entailment reasoning could also be regarded as a generalisation of Datalog query answering, and theorem provers could be applied to this language. Again, however, the target applications and usage patterns are completely different from those of Datalog systems.

Nevertheless, there are also Datalog-like feature extensions that have not been discussed here. One that has been intensively researched is the extension of Datalog rules with existentially quantified variables in rule heads, leading to what is called existential rules or tuple-generating dependencies. Datalog’s operational semantics ($T_P$ operator, Section 4.2.1) can be extended to this setting by creating new placeholder elements to satisfy existential restrictions [20, 51, 42]. Motivations for existential rules stem from the theory of data integration and ontology-based query answering [55]. Nemo supports existentially quantified variables in heads (distinguished by exclamation marks, as in !X).

Another extension in some Datalog engines is support for abstract relations with special built-in semantics. Most prominent are equivalence relations, which are relevant in several applications. In general, one can always axiomatise the properties of equivalence (reflexivity, symmetry, transitivity) with Datalog rules, but this is not efficient in comparison to using data structures specifically designed for storing equivalence classes. Soufflé therefore allows binary relations to be declared equivalences, and RDFox supports special handling of a built-in equality (different from identity). Dedicated treatment can also be given to other special types of relations, but this is closer to an optimisation technique than to an actual language extension.

Some other topics have deliberately been omitted from this chapter. One is the notable history of Datalog, from early trends in databases and expert systems, to the renaissance in the wake of ontological reasoning and declarative data analysis. An extended review is given by Maier et al. [49]. Another omission are classical and recent reasoning and implementation approaches. Decades-old methods like semi-naive evaluation and magic sets [2] are still relevant, but Datalog systems have also taken advantage of more recent developments, such as column-based database layouts [66], compiler-optimised reasoning pipelines [36], and worst-case optimal joins [35]. Algorithmic advances have been made, e.g., in the context of efficient incremental updates [54].

Besides such practical questions, there is also relevant foundational work in relation to Datalog. A classical topic is expressive power, i.e., the question which queries can be expressed at all (without considering efficiency). Datalog programs characterise polynomial functions from input to output database (see Theorem 19), but not all such functions can be expressed in Datalog. To truly capture PTime, Datalog can be extended with input negation and a totally ordered database domain [2]. Recent works have also shed light on the expressivity with respect to monotonic (homomorphism-closed) PTime queries [62]. Existential rules, on the other hand, can express any Turing recognisable query, and the fragment for which the standard bottom-up algorithm is guaranteed to terminate still captured the decidable queries [8]. Another foundational topic is the semantic analysis of Datalog programs. For example, it is undecidable if a Datalog program is equivalent to one without recursion (a property known as boundedness) [33]. Likewise, equivalence and containment of Datalog programs is undecidable, but several broad fragments have been identified where decidability can be recovered, albeit at very high complexities [9].

After all, the broad relevance and popularity of Datalog is making it impossible to give a comprehensive overview of even the most important works and ideas in the area. Nevertheless, this text has hopefully succeeded in conveying an impression of the distinctive modelling and usage patterns that have emerged for modern Datalog applications. Many meaningful advances are still to be made in research and in practice. Contributions are welcome.