Mulgara

h1. RLog

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":http://www.w3.org/TR/swbp-n-aryRelations/, 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.

h3. A Note on URIs

RDF uses URIs as the basic syntactic element, which can be unwieldy in examples. "QNames":http://en.wikipedia.org/wiki/QName 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:

<pre>

In QName form, this is abbreviated to:

<pre>

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.

----

h1. Basic Elements

h3. Atoms

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:

|| rdf     || !http://www.w3.org/1999/02/22-rdf-syntax-ns# ||

|| rdfs    || !http://www.w3.org/2000/01/rdf-schema#       ||

|| owl     || !http://www.w3.org/2002/07/owl#              ||

|| xsd     || !http://www.w3.org/2001/XMLSchema#           ||

|| mulgara || !http://mulgara.org/mulgara#                 ||

|| krule   || !http://mulgara.org/owl/krule/#              ||

|| foaf    || !http://xmlns.com/foaf/0.1/                  ||

|| skos    || !http://www.w3.org/2004/02/skos/core#        ||

|| dc      || !http://purl.org/dc/elements/1.1/            ||

Prefixes can be added using the *@prefix* instruction.

h3. Variables

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._

----

h1. Predicates

h3. 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:

<pre>

  Bar(foo)

</pre>

This is expressed in RDF using the special predicate _rdf:type_:

<pre>

  foo  rdf:type  Bar .

</pre>

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

h3. Binary Predicates

Binary predicates indicate a relationship between two resources:

<pre>

  friend(fred,barney)

</pre>

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

<pre>

  fred  friend  barney .

</pre>

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

----

h1. Statements

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

h3. Axioms

Axioms are a statement of fact. They consist of a single predicate followed by a dot.

The general form of an axiom is:

<pre>

_Examples_

The following states that _:fred_ is a _foaf:Person_:

<pre>

  foaf:Person(fred).

</pre>

This statement says that _:fred_ has the friend _:barney_:

<pre>

  :friend(:fred, :barney).

</pre>

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.

h3. Rules

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

<pre>

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:

<pre>

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.

_Examples_

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

<pre>

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

</pre>

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.

<pre>

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

</pre>

*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:

<pre>

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

  :Man(:fred).

</pre>

This will continue looping until system resources are exhausted.

h3. Checks

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:

<pre>

_Examples:_

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

<pre>

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

</pre>

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":

<pre>

  :- owl:Nothing(X).

</pre>

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

----

h1. Comments

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

<pre>

_Examples:_

<pre>

  -- This is full line comment

</pre>

The following adds a comment to a rule:

<pre>

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

</pre>

----

h1. Directives

h3. @prefix

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:

<pre>

_Examples:_

<pre>

<pre>

  @prefix owl11: <http://www.w3.org/2006/12/owl11#> .

</pre>

<pre>

<pre>

  @prefix : <http://www.w3.org/2006/12/owl11#> .

</pre>

h3. @import

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:

<pre>

Examples:

<pre>

<pre>

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

</pre>

<pre>

<pre>

  @import <second.dl> .

</pre>

----

h1. Example Programs

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

<pre>

@prefix : <http://xmlns.com/foaf/0.1/> .

@prefix family: <http://family.com/data/> .

:Person(family:fred).

:Person(family:peter).

:Person(family:tom).

family:hasBrother(family:peter,family:fred).

family:hasFather(family:tom,family:peter).

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

</pre>

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

<pre>

@prefix : <http://xmlns.com/foaf/0.1/> .

@prefix family: <http://family.com/data/> .

:Person(family:peter).

:Person(family:tom).

family:hasParent(family:tom,family:peter).

family:hasChild(family:tom,family:peter).

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

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

</pre>

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:

<pre>

  create <test:data>;

  apply <file:///tmp/program.rlog> to <test:data>;

  select $s $p $o from <test:data> where $s $p $o;

</pre>

All 3 of these commands are in TQL, though the final command can be replaced with the equivalent SPARQL:

<pre>

  select $s $p $o from <test:data> where { $s $p $o }

</pre>