Project

General

Profile

Actions

RLog » History » Revision 2

« Previous | Revision 2/5 (diff) | Next »
Paula Gearon, 03/24/2009 09:38 PM
Added example programs


= 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 [http://www.w3.org/TR/swbp-n-aryRelations/ 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. [http://en.wikipedia.org/wiki/QName 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:BR {{{ http://www.w3.org/1999/02/22-rdf-syntax-ns#type }}}BR
In QName form, this is abbreviated to:BR {{{ rdf:type }}}

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 =

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

=== 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.''


= Predicates =

=== 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: {{{
Bar(foo)
}}}

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: {{{
friend(fred,barney)
}}}

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.


= Statements =

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

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

The general form of an axiom is:BR {{{ predicate. }}}

''Examples''
The following states that '':fred'' is a ''foaf:Person'': {{{
foaf:Person(fred).
}}}

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 ===
Rules are Horn Clauses, consisting of a head followed by a body. The basic form is:BR {{{ 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:BR {{{ 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.

''Examples''
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(:fred).
}}}
This will continue looping until system resources are exhausted.

=== 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:BR {{{ :- predicate [, predicate]*. }}}

''Examples:''
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 =

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

''Examples:'' {{{
-- This is full line comment
}}}

The following adds a comment to a rule: {{{
rdf:Property(A) :- A(X,Y). -- RDFS rule #1
}}}


= Directives =

=== @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:BR {{{ @prefix string: <uri> . }}}

''Examples:''
This sets the owl11 prefix to {{{http://www.w3.org/2006/12/owl11#}}}: {{{
@prefix owl11: <http://www.w3.org/2006/12/owl11#> .
}}}

This sets the empty prefix to {{{http://example.com/example/}}}: {{{
@prefix : <http://www.w3.org/2006/12/owl11#> .
}}}

=== @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:BR {{{ @import <url> . }}}

Examples:
This imports the file {{{/tmp/rules.rl}}}: {{{
@import <file:///tmp/rules.rl> .
}}}

The following statement is in the file {{{/home/user/programs/first.dl}}}. It is used to import the file {{{/home/user/programs/second.dl}}}: {{{
@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 : <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).
}}}

This next program describes an inconsistent system. It will therefore fail: {{{
@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).
}}}

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 14 years ago · 2 revisions