First we consider DATALOG i.e., PROLOG without structures (constructor symbols applied to arguments). This `simple-domain' language of (normalized) relational databases is also a subset of RELFUN. DATALOG clauses have identical syntax and equivalent semantics in PROLOG and RELFUN. Queries to RELFUN differ only as follows: they return the truth-value true instead of printing the answer yes; they signal failure by yielding the truth-value unknown instead of printing no.
When we stay in the relational realm of RELFUN this makes not much of a difference since true can be mapped to yes and unknown can be mapped to no. However, when proceeding to RELFUN's functional realm, queries will be able to return the third truth-value false: this is to be mapped to those of PROLOG's no answers for which the closed-world assumption is justified. In general, however, RELFUN does not make the closed-world assumption, and in the absence of explicit negative information modestly yields unknown instead of `omnisciently' answering no.
For example, given the DATALOG knowledge base
subfield(architecture,bridgebuilding). applicable(pharmacy,medicine). applicable(computerscience,bridgebuilding). applicable(computerscience,computerscience). applicable(Tool,Field) :- subfield(Field,Sub), applicable(Tool,Sub).a successful query like applicable(computerscience,architecture) returns true in RELFUN and prints yes in PROLOG; however, a failing query like applicable(computerscience,agriculture) yields unknown in RELFUN but prints no in PROLOG. As with most real-life knowledge, what we know about computer-science applications is inherently open-ended; RELFUN's unknown reply agrees to the required open-world semantics.
Later, in DATAFUN, certain relations such as subfield will be reformulated as functions (cf. subsection 3.1). This will also have consequences for `Horn' rules such as the applicable rule which still define a relation but call a subfunction, e.g., in an is-rhs: applicable(Tool,Field) :- Sub is subfield(Field), applicable(Tool,Sub). To accomodate such functional (and is-`equational') extensions in relational rules, we speak of hornish rules or, generally, hornish clauses.
Two further extensions of DATALOG, varying-arity DATALOG and higher-order DATALOG, will be treated implicitly in the corresponding full-PROLOG extensions (see subsections 2.4 and 2.5).