RLog is a language based on logic programming, which is specifically aimed at describing RDF.

Statements in RDF are equivalent to unary and binary predicates in logic. Most relationships can be described with these simple predicate, although occasionally predicates with higher arities may be called for. These higher arities are simulated in RDF using a number of mechanisms, including blank nodes with named operators, and lists. So the restriction to unary and binary arities is appropriate when dealing with RDF.

RLog programs are built using statements that resemble Horn Clauses. Statements are built using a series of predicates, and predicates are built using the basic elements of atoms and variables. A complete program is simply a list of statements and directives.

A Note on URIs

RDF uses URIs as the basic syntactic element, which can be unwieldy in examples. QNames are a much shorter form for a URI which abbreviates an entire domain down to a short string. For instance, the type predicate in RDF has a full URI of:

In QName form, this is abbreviated to:


The following text will stick to QNames, and will often use unprefixed QNames to illustrate examples (e.g. foo).

RLog uses QNames exclusively for URIs.

Basic Elements


RLog uses QNames, numbers, and quoted strings for atoms. QNames can be used anywhere. Strings are surrounded by double quotes. Since RLog represents RDF, then numbers and strings can usually only appear in the second element of a binary predicate.

All URIs are represented as QNames. A number of prefixes are pre-defined:

Prefixes can be added using the @prefix instruction.


Variables are represented with a single upper-case letter. This restricts each statement to only allowing a maximum of 26 variables. This was considered adequate at design time, but if there is a legitimate need for more, then please contact the developers.


Unary Predicates

A unary predicate indicates the type of an object. So the following statement indicates that the object named foo is an instance of the Bar type:


This is expressed in RDF using the special predicate rdf:type:

  foo  rdf:type  Bar .

RLog enforces the RDF convention that types begin with an upper case letter.

Binary Predicates

Binary predicates indicate a relationship between two resources:


This is expressed in RDF using an "infix" notation, meaning that the predicate is in the middle:

  fred  friend  barney .

RLog enforces the RDF convention that relationships begin with a lower case letter.


Mulgara uses 3 types of statements: Axioms, Consistency-Checks (which are a kind of Axiom), and Rules.


Axioms are a statement of fact. They consist of a single predicate followed by a dot. Note the term "predicate" here is being used in its logic sense, and should not be confused with the middle element in an RDF triple (a related, but slightly different thing).

The general form of an axiom is:


The following states that :fred is a foaf:Person:


This statement says that :fred has the friend :barney:

  :friend(:fred, :barney).

Axioms can be considered as rules with the body set to "nothing" or "bottom" (to use the term from logic), meaning that nothing else is needed in order to generate the predicate in the head of the statement.


Rules are Horn Clauses, consisting of a head followed by a body. The basic form is:

  head :- body.

The head is a single predicate (this may change in a later revision).

The body is a list of comma-separated predicates.

So the general form is:

  predicate :- predicate, predicate, ... .

If the body of the rule is matched, then the head will be asserted. Matching is the process of finding existing assertions which share the atoms of all the predicates. Once a match is found, then the variables in the predicate are bound to the corresponding values in the matched assertion. These binding are then used in the assertion described in the _head' of the statement.

The following statement declares that all instances of the class transport:Car are therefore instances of the class transport:Vehicle:

  transport:Vehicle(X) :- transport:Car(X).

This next statement declares that if any two resources are related by a predicate, and that predicate is an rdfs:subPropertyOf another predicate, then those resources are also related by the second predicate.

  B(X,Y) :- A(X,Y), rdfs:subPropertyOf(A,B).

Note: all the variables appearing in the head of a statement MUST appear in the body. This prevents the creation of blank nodes. This feature may be allowed in future, but it has the side-effect of allowing infinite generation of new node. To see this, consider the following program:

  :father(X,Y) :- :Man(X).
  :Man(Y) :- :father(X,Y).

This states that all men have fathers, and that anyone who is a father is a man. Finally, the entity :fred is declared to be a man.

This will continue looping until system resources are exhausted.


Checks perform tests for consistency on the data. If a check fails, then an error is reported and the current operation is discarded. If a transaction is in progress, then it will be rolled back.

Checks are like rules without a head, meaning that the body should imply "nothing" or "bottom" (to use the logic term). Anything matching the body of a check is considered an error, so the number of matches is reported in the error.

The general form of a check is:

  :- predicate, predicate, ... .

This checks that if two things are declared to be the same, they cannot also be different:

  :- owl:sameAs(X,Y), owl:differentFrom(X,Y).

Note that this check is likely to work in conjunction with other rules, such as the ones declaring the symmetry of the owl:sameAs and owl:differentFrom predicates. Otherwise, a second check would be needed which reversed the order of X and Y in one of the predicates above.

This check tests that nothing can be declared to be "Nothing":

  :- owl:Nothing(X).

This test may seem redundant at first glance, but it is one of the fundamental tests for ontological consistency.


Comments in Mulgara are created using a pair of dashes and extend to the end of that line. The general form is:

  -- comment


  -- This is full line comment

The following adds a comment to a rule:

  rdf:Property(A) :- A(X,Y).   -- RDFS rule #1



The @prefix directive is used to create a new prefix for use in QNames. It is only applied to QNames appearing after the @prefix statement. The syntax is the same as in N3:

  @prefix ns: <IRI> .


  @prefix owl11: <> .

  @prefix : <> .


The @import directive is used to import the contents of another RLog file. A URI is provided to locate the file. If it is an absolute URL, then this is used to locate and read the file. If the URI is relative, then it is used to identify a path relative to the URL of the original file being loaded. Imports may be nested, but relative URIs are always relative to the original file, and not the most recent importing file.

The syntax is:

  @import <IRI> .


  @import <file:///tmp/rules.rl> .

  @import <second.dl> .

Example Programs

The following simple program describes 3 people and their relationships. It also describes a rule to deduce a new relationship:

@prefix : <> .
@prefix family: <> .


family:hasUncle(A,C) :- family:hasFather(A,B), family:hasBrother(B,C).

This next program describes an inconsistent system. It will therefore fail:

@prefix : <> .
@prefix family: <> .


family:hasParent(B,A) :- family:hasChild(A,B).

:- family:hasParent(A,B), family:hasParent(B,A).

Of course, real programs will by much more complete, describing the inverse relationship between hasParent and hasChild, and gender sets to describe the relationships between classes like hasParent and hasFather.

The above programs are designed to be applied to an empty graph, though they will also work on pre-existing data.

The following commands will apply a program called /tmp/program.rlog to an empty graph with the name test:data, and then display the results:

  create <test:data>;
  apply <file:///tmp/program.rlog> to <test:data>;
  select $s $p $o from <test:data> where $s $p $o;

All 3 of these commands are in TQL, though the final command can be replaced with the equivalent SPARQL:
  select $s $p $o from <test:data> where { $s $p $o }

Updated by Paula Gearon almost 12 years ago ยท 5 revisions