SWI-Prolog for the semantic web

For anyone interested, I did my Masters thesis on SWI-prolog as a Semantic querying tool, integrating it with the Eclipse RCP platform (Bioclipse.net in particular), and compared its querying performance with Java based Jena SPARQL parser for some typical tasks in cheminformatics.

The title was "SWI-Prolog as a Semantic Web Tool for semantic querying in Bioclipse: Integration and performance benchmarking", and it is available for download here: https://www.researchgate.net/publication/50313589_SWI-Prolog...

In this particular task, SWI-Prolog totally knocked out Jena, and it was also more amenable to some heuristic optimiziations, where we the running time really became infinitesimal in comparison to other tools.

There is also a really interesting Biomedical toolkit for SWI-prolog, which if IIRC uses or integrates with the semantic capabilities (for ontologies etc), although it was a while since I looked at it, so might recall wrong:

* BlipKit - Biomedical Logic Programming : http://www.blipkit.org

Read through the paper quickly, seems like a nice representation and solution of the problem. I have a couple of questions if you wouldn't mind.

You say this in the paper:

> It is an interesting observation that writing the Prolog query on the simpler form (Figure 18) made it amenable to heuristic optimization by sorting the values searched for, while this was not possible in the longer Prolog program

I'm afraid I didn't read carefully and will go back, but could you clarify this a bit? I didn't understand about the longer vs. the shorter prolog code. Would this optimization be required always get better performance than Jena or Pellet?

And then this:

> Additionally, a drawback of SWI-Prolog speci?cally, against Jena and Pellet, is that since it is not written in Java, it is not as portable (i.e. the same code can not easily be executed) to di?erent platforms such as Mac, Windows, Linux etc. Instead the source code has to be compiled separately for each platform. This also has the result that the SWI-Prolog Bioclipse integration plugin will not be as portable as Bioclipse itself.

Really, though, Bioclipse is dependent on the portabilty of Eclipse which probably doesn't support any more platforms than SWI Prolog (and most probably fewer than SWI Prolog), so I wouldn't really see that as a limitation. I would think you could provide the binaries in the distribution itself.

I'm pretty sure philosophers invented metadata, even though they did not give it that name. The question how to distinguish between the properties an object has and what properties we attach to it, is sort of central in epistemology. Higher category theorists sometimes distinguish between stuff, structure and property http://nlab.mathforge.org/nlab/show/stuff,+structure,+proper..., which makes the definition of forgetful functors more precise. Conversly attaching structure or properties are (not nescessarily unique) adjoint functors to those forgetful ones. In mathematics this comes up for example if you consider the category of abelian groups from which there is both a forgetful functor to the category of groups and to the category of sets, but the general idea should be applicable to metadata attached to text aswell.

It is not at all fast.

I don't even think it's computationally possible for SPARQL to be fast.