RDF and ePortfolios

Just needed to get this down before I forget... RDF & semantic web technologies generally have been nipping at the heels of several information retrieval projects for a while now. Every six months or so I check out and build the latest jena to see if we could actually build some of our IR systems using it, and it's always the same story: I start off really enthusiastically, but slowly start hitting walls that mean it's just not possible. This time around it was accessing native text and spatial indexes in my jena database backend. But.... We've been struggling for a long time now with OSPI and the SAKAI ePortfolio module and suddenly I can see an application for RDF and defined ontologies, and users being able to extend the data model in ways they want. It seems to me that jena-db could be exactly the right backend for a real usable ePortfolio system... Not sure where we'd get started building a beast like that tho.

LOTRO

A note for all mmorpg friends....

Currently playing on Laurelin (UK RP Server) with the following :

Whilat (There at the launch of three mmorpg's now... cool or what) elf loremaster
Draff - Human Hunter
Suwen - Elf Champion
Mirathanor - Elf Bard

And wondering if I dare upload screenies of me at the foot of wethertop to flickr ;) Guild name is "Núror Muinaréva" (Without the accents... I guess the text must all be US7ASCII) msg me ingame for invites :)

Random thoughts - JZKit3

After a morning trying to fit the SQI square peg into the SRW round hole, I'm having some thoughts about re-organising the search plugins and the aggregator service in JZKit3. It seems with the way the world is today, with alerters and users creating their own data feeds (The horrible, if cool pipes demo, which could be so much more, if only it worked). The problem we have with JZKit right now is that some of the plugins require oodles of configuration (JDBC/Relational Database Plugin) wheras others require nothing more than a url (Z3950 URL, SRW/SRU, etc). To create a simple search portal app thats easily installed, users don't want to have the grief of learning about relational database plugin config. We thought we cracked that nut in jzkit2 by having the plugins register their own config mechanisms, but the config woes persist. So, how about, after thinking harder about how we can work with SQI, we split the plugins into two classes, those that are URL configurable and those that aren't. The ones that arent need to be exposed as an SRW/SRU/Z3950 service in their own right, and are then aggregated by the simpler plugins. This *vastly* simplifies the config (Still have all the query rewrite stuff to deal with, but at least it cuts out the big problem, which is database config). This also fits with rewriting the jdbc plugin to use hibernate map based objects instead of our home-grown persistence layer. Sounds like a good direction for jzkit3.