alt="Image"/>
Rules for Queries 2 and 3 can be written in XSB as follows:
Query 5 can be implemented using the aggregate construct findall in XSB, which returns all answers to a query as a list via the last argument:
The same query can also be implemented using the table aggregation construct in XSB as follows:
The special tabling directive in the first line works as follows: whenever an answer acc for q4 is generated, XSB calls cnt(acc, _, NewAcc), removes acc from the table, and adds NewAcc. For the first answer found, the first argument in the call to cnt would be 0, as indicated by the tabling directive. So q5_2 returns the number of facts found for q4.
1.8.3 LogicBlox
LogicBlox [Aref et al. 2015] is a commercial system unifying the programming model for enterprise software development that combines transactions with analytics by using a flavor of Datalog called LogiQL. LogiQL is a strongly typed, extended form of Datalog that allows coding of entire enterprise applications, including business logic, workflows, user interfaces, statistical modeling, and optimization tasks. LogicBlox evaluates LogiQL rules in a bottom-up fashion.
In terms of the language, in addition to pure Datalog, LogiQL has functional predicates that map keys to values, and various aggregation operators. In LogiQL, the arguments of each EDB predicate need to be typed. For our queries, these types can be specified as follows:
In the specification above, person is a functional predicate (shown by the bracket notation), mapping person IDs to names. Using these specifications, Query 1 can be answered with the following rules:
Apart from the use of the functional predicates shown above, Queries 2–4 can be implemented similarly to XSB:
Query 5 can be specified using the aggregation construct in LogiQL as follows.
1.8.4 Datomic
Datomic [Anderson et al. 2016] is a distributed NoSQL database, which uses Datalog as its rule and query language. Since the system is closed-source and no academic paper has been published by the implementation team, one can only rely on the documentation for its details. Datalog evaluation in Datomic is performed bottomup, and indexing directives can be specified.
The syntax of a Datalog rule in Datomic is quite distinct from that used in the logic programming literature. It is akin to the RDF query language SPARQL [Prud’hommeaux et al. 2008]. Datomic operates on object-like predicates. For example, for our EDB predicate dissertation, rather than representing it as a predicate with arguments, each dissertation is considered an object with an identifier and arguments that can be accessed as fields. Therefore, all EDB predicates are represented by binary predicates written in infix form, and they use square brackets. For example, a dissertation’s candidate ID can be thought of as a predicate :dissertation/cid whose form in the body is [?d :dissertation/cid ?c], where variables are preceded by ?. In contrast, IDB predicates are written in prefix notation and use round parentheses, as seen in the rules below.
A rule is written as a list whose first element is the conclusion of the rule and the rest of the elements in the list are the body. For example, a new predicate author whose arguments are the dissertation ID and the candidate ID can be defined via the following rule:
Once a new predicate is defined, it can be used in the body of a rule to define more predicates, as shown in the definition of the advisor relationship below.
Queries use a similar syntax, where a list of variables appears after the keyword :find and the body is given after the :where keyword. Therefore, Query 1 can be defined as follows (the three dots after the arguments to :find will return a collection):
In this fashion, Queries 2–4 can be written in Datomic as follows:
Aggregates are handled in Datomic by applying aggregate functions to variables. For instance, Query 5 is written as follows:
1.8.5 Flora-2 and Ergo
Flora-2 [Kifer 2015, Yang et al. 2003] is a knowledge-representation and reasoning system that supports Datalog as a subset of its various reasoning paradigms, such as the ones described in Section 1.4. The bouquet of these extensions is unique to Flora-2 and many were pioneered by that system. The list of these advanced features includes well-founded negation (Section 1.4.1), aggregation (Section 1.4.3), object-oriented extensions based on F-logic and defeasible reasoning (Section 1.4.6), HiLog (Section 1.4.7), logical updates (Section 1.4.8), certain styles of functional programming, explicit logical quantifiers, and more. Flora-2 uses XSB as an underlying inference engine. In particular, it relies on XSB’s top-down evaluation strategy, but also brings in new elements such as dynamic reordering of subgoals. Ergo is a commercial variant of Flora-2 offered by Coherent Knowledge, LLC. It includes additional language extensions and optimizations as well as development tools and connectors to various external data sources (for example, SPARQL endpoints, tabular data and JSON). Our running example of the fragment of the Genealogy Database, expressed in Flora-2, is shown below. To illustrate the object-oriented features of this system, we modify the database schema to use frame-based rather than predicate-based representation. (If we used predicate representation then Flora-2 rules would be similar to XSB’s with minor syntactic differences.)
These declarations specify the types of the attributes for classes Dissertation and Person
