Exploring pathway data

I’ve added a document on
exploring pathway data to blipdoc. I’ll highlight some of the salient points on this blog at a later date.

blip and swi-prolog 5.8.x

The SWI stable release series has now reached 5.8.x (http://www.swi-prolog.org/download/stable). Blipkit installation was previously broken for the 5.8.x series (and the later 5.7.x releases) due to changes in how SWI handles the user and system modules, but this has now been fixed. You should be able to grab the latest from svn and just type


./configure
make
sudo make install


Thea paper accepted for OWLED2009

Provisional version of the paper up on:

(new) Thea website

(pending reivisions)

ICLP 2009

My invited talk from ICLP-2009 is available from slideshare:

experiences-with-logic-programming-in-bioinformatics

Unfortunately I didn’t get to go into detail in some sections, particularly Thea.

Overall I had an excellent time, good to meet many LP luminaries and users.

Towards portability with Thea2

The Thea OWL package is currently SWI-specific. It would be nice to use this with other prologs, particularly to take advantage of tabling in combination with DLP programs generated from OWL.

I’m impressed by the prolog-commons effort, particularly the convergence we are seeing between Yap and Prolog. Currently the core parts of Thea work with Yap, although there are some annoyances (Yap is unfamiliar with the useful debug/3). Unfortunately the excellent semweb package is still SWI-specific, so you will need to convert your ontology to axioms in prolog syntax first. OWL-XML should in principle be possible, as Yap-6 includes the SWI sgml package, although this appears not be working yet.

For other prologs the lack of a standard module system is the main hindrance. I have added a simple translator to the Thea2 makefile that will strip module declarations generating mostly ISO conformant prolog that can be used with GNU Prolog and XSB. Again, this is just for the core parts. XSB does include the sgml package so parsing OWL-XML is possible with some difficutly, although there are some annoyances such as incompatibilities in the load_structure/3 predicate.

I’m encouraged to hear that these 4 open source prologs are converging on a standard module system, so we should have better compatbility in the future. Converging on a FLI may be too much to ask, so it would be useful to have prolog implementations of xml and rdf parsing to use as fallbacks if the C libs are not present or usable.

readline in XSB

The lack of readline support in XSB used to drive me mad. This deficit has been noted by others.

There is in fact a simple solution. Perhaps this is obvious, but I only just discovered it, and I couldn’t find it on a google for xsb readline so I’ve included it here:

* Install rlwrap
* Add something like the following to your .profile: alias xsb="rlwrap -C $HOME/XSB/bin/xsb"

Suddenly interactive programming with XSB becomes ten times easier..

Blip at ICLP2009

I will be at ICLP delivering a talk on blipkit and my experiences – positive and negative – applying logical programming to biological applications. Looking forward to meeting many of the key LP players!

Cheers
Chris

intervaldb now on github

intervaldb has moved from blipkit svn to githib.

intervaldb is an SWI-Prolog wrapper for the nested containment list (NCList) C library distributed as part of PyGR. Query time is O(n+logN) where N is the size of the database and n is the size of the result set. It is primarily intended for indexing genomic data, but can be used for any kind of intervals, e.g. temporal data

See: http://bioinformatics.oxfordjournals.org/cgi/reprint/btl647v1

Translating between logic programs and OWL/SWRL

Using the Thea2 library, it’ possible to translate certain OWL-DL ontologies into logic programs, and then query over them using LP systems such as Yap or XSB. Only the DLP subset is translated, and care must be taken to avoid common pitfalls.

It’s now also possible to do the reverse translation for a similar subset of LP programs. For example, if we have a file uncle.pl, with contents:
uncle_of(U,C) :- brother_of(U,P),parent_of(P,C).


We can do a simple syntactic translation to SWRL from the command line as follows:
swipl -g "[owl2_io],convert_axioms('uncle.pl',pl_swrl, 'uncle.swrl',owl, [])"


This yields the rather voluminous SWRL ontology:


<swrl:Imp>
<swrl:body>
<swrl:AtomList>
<rdf:first>
<swrl:IndividualPropertyAtom>
<swrl:argument1 rdf:resource="#v1"/>
<swrl:argument2 rdf:resource="#v3"/>
<swrl:propertyPredicate rdf:resource="http://example.org#brother_of"/>
</swrl:IndividualPropertyAtom>
</rdf:first>
<rdf:rest>
<swrl:AtomList>
<rdf:first>
<swrl:IndividualPropertyAtom>
<swrl:argument1 rdf:resource="#v3"/>
<swrl:argument2 rdf:resource="#v2"/>
<swrl:propertyPredicate rdf:resource="http://example.org#parent_of"/>
</swrl:IndividualPropertyAtom>
</rdf:first>
<rdf:rest rdf:resource="&rdf;nil"/>
</swrl:AtomList>
</rdf:rest>
</swrl:AtomList>
</swrl:body>
<swrl:head>
<swrl:AtomList>
<rdf:first>
<swrl:IndividualPropertyAtom>
<swrl:argument1 rdf:resource="#v1"/>
<swrl:argument2 rdf:resource="#v2"/>
<swrl:propertyPredicate rdf:resource="http://example.org#uncle_of"/>
</swrl:IndividualPropertyAtom>
</rdf:first>
<rdf:rest rdf:resource="&rdf;nil"/>
</swrl:AtomList>
</swrl:head>
</swrl:Imp>


Personally I prefer authoring rules in prolog syntax in emacs and then converting via Thea, but YMMV.

We can also translate the SWRL into a property chain axiom subPropertyOf(propertyChain([uncle_of,brother_of]),uncle_of), eliminating the rule altogether:


swipl -g "[owl2_io],convert_axioms('uncle.pl',pl_swrl_owl, 'uncle.owl',owl, [])"


If you look at the results in Protege4 you will see:


brother_of o parent_of ➞ uncle_of


Other patterns also recognized include domain/ranges, transitivity, invereProperties, etc

These kind of syntactic translations are useful for interoperability. The benefits of writing ontology fragments as rules becomes more apparent if we consider the following program processual_part_of.pl:


% if part_of holds for a process, the specific
% relation is processual_part_of
processual_part_of(P,W) :- part_of(P,W),process(W). %
% if part_of holds for an object, the specific
% relation is spatial_part_of
static_part_of(P,W) :- part_of(P,W),object(W). %
part_of(p1,p2).
part_of(ob1,ob2).
process(p1).
process(p2).
object(ob1).
object(ob2).


The two rules in this program can distinguish two relations based on the domain of the relation. For example, we can ask


?- processual_part_of(X,Y).


And get back the answers p1-p2, but not ob1-ob2.

This is a fairly trivial program. Yet it’s not immediately obvious how to code this in OWL. There is a way but it is rather ingenious/baroque, involving the creation of two fake properties and some self-restrictions and property chains.

Fortunately, Thea2 will help us with this too.


swipl -g "[owl2_io],convert_axioms('testfiles/processual_part_of.pl',pl_swrl_owl,'ppo.owl',owl,[])"


Here I show the results in Thea/owlpl syntax:


subClassOf('_d:process', hasSelf('_d:process_p')).
subClassOf('_d:object', hasSelf('_d:object_p')).
subPropertyOf(propertyChain(['_d:part_of', '_d:process_p']), '_d:processual_part_of').
subPropertyOf(propertyChain(['_d:part_of', '_d:object_p']), '_d:static_part_of').
propertyAssertion('_d:part_of', p1, p2).
propertyAssertion('_d:part_of', ob1, ob2).
classAssertion('_d:process', p1).
classAssertion('_d:process', p2).
classAssertion('_d:object', ob1).
classAssertion('_d:object', ob2).


here all the nasty ‘fake property’ stuff is taken care of for us behind the scenes.

We can demonstrate it works with the following sparql query via Pellet2:


SELECT * WHERE {?x <http://x.org#processual_part_of> ?y}


which yields:


Query Results (1 answers):
x | y
=======
p1 | p2

Of course, there are many prolog programs that cannot be translated to OWL, and many OWL ontologies for which logic programs cannot be created. Each paradigm has its own strengths and weaknesses. Greater interoperability between the two can only help.

Robot Scientist

This story received a bit of coverage last month:
http://news.bbc.co.uk/2/hi/science/nature/7979113.stm [BBC]

There are more details in the Science publication, “the automation of science”:

The system generates scientific hypotheses about gene functions, then devises and carries out experiments to test these hypotheses. The system appears to be written in Prolog, with the hypothesis generation using Inductive/Abductive Logic Programming, in particular the ProGol system.

More details can be found on the group’s website.