Samuel's Project Blog

What do you think of that title? :) To me it sounds like one of the (many) natural next steps forward for Bioclipse sometime in future¹.

Explicit knowledge is too expensive

There are lots of things that can't be answered by a computer from data alone. Maybe the majority of what we humans perceive as knowledge is inferred from a combination of data (simple fact statements about reality) and rules that tell how facts can be combined together to allow making implicit knowledge (knowledge that is not persisted as facts anywhere, but has to be inferred from other facts and rules) become explicit.

One can easily imagine though, that storing every single piece of knowledge that could be stated, as an explicit fact, would require more storage than can probably ever be made available in this universe.

Simulations can make knowledge explicit, from first princples

It is not too hard to come up with some processes which are just too complex and involves too much variability² that it is unrealistic to try to capture every imaginable state of of that system or process in explicit facts. Instead we must seek the "first principles" that defines the process, and through simulations make explicit any knowledge we are looking for, at the time we need it (one can of course cache often accessed knowledge).

I seemingly ran into the trouble that user-defined datatypes does not work in OWL 1.X (which is seemingly what the version of Pellet used in Bioclipse does support?

It just struck me a very simple way of storing prolog code inside Bioclipse scripts, avoiding the need for a separate file containing the Prolog code. This might be very useful when using prolog as a kind of "query language" somewhat analogous to how SPARQL is used.
(Update: Prolog in fact turns out to be more powerful than SPARQL in this regard, as shown by the observation in this blog post, that SPARQL doesn't support backtracking).

The idea would be to simply store the prolog code in Bioclipse JS variable, and create a special manager method that can write such prolog query-code containing variables to a temporary file in the workspace and then just telling Prolog to "consult" that file, thereby "feeding the prolog engine" with the logic to use, from inside Bioclipse scripts.

As reported in a previous blog post, I ran into java stacksize errors when importing large amounts of data into pellet. Pellet was using just the in-memory Jena RDF store, which obviously puts limits on the amount of data it can handle.

Jena offers other options for RDF storage though, including SDB for SQL backends, and TDB for a pure Java file based storage.

I started with some initial performance testing for RDF data, between pellet an prolog, which are now both available integrated in Bioclipse.

I needed a Bioclipse manager method that could take an arbitrary number of arguments, (for a general purpose prolog method mapper). Through a useful discussion with jonalv, we figured out that there exists at least one working way of doing this, while there are a number of ways that do not work across both the Rhino/JavaScript though they work in Java alone.

A strategy for how to work with the Bioclipse/JPL/Prolog/Blipkit combination I'm setting up, is becoming clear.

The main idea with Bioclipse, as well as with having a prolog engine available in it, is for flexible and "interactive" knitting together of knowledge. One of the main questions regarding how to use a Bioclipse/JPL/Prolog/Blipkit combination, has been where to put the bulk of knowledge integration/reasoning code? There would in principle be three options for that:

1. Bioclipse (Javascript environment)
2. The Blipkit-Prolog/Bioclipse integration plugin (Java code, a.k.a. "Manager methods")
3. The prolog engine (As a prolog file)

I had the problem that in JPL (The java Prolog API) you cannot use namespaces before term (atoms or variables etc.) names, like so:

The best solution would be to have some kind of "namespace-like" support in the JS console of Bioclipse instead. One easy thing one can do is to just create a simple function that appends the long preceding URL, so a JS Example could be: