TopicSpaces is the name I have given to what I call a Subject Map Provider. A subject map is a kind of topic map but is based on the Topic Maps Reference Model. As such, a subject map can be crafted to a different ontology than that which is expressed by the XML topic maps . That is, a subject map is generally crafted using containers (called subject proxies) for property objects (subject properties). Each subject property object is a key value(s) pair that describes either identity of the subject being represented, or other properties, which include roles the subject plays in relationships with other subjects in the map. Enough background.
TopicSpaces is an open source (Java, LGPL) project that will eventually be released for others to develop. It is built on the Java Content Repository (Jackrabbit). I am just now bringing TopicSpaces up inside JAMWiki. Ryan suggested that I open the discussion here about how the marriage of TopicSpaces and JAMWiki is going. Big picture: quite well, actually. The toughest part, up front, is climbing the learning curve sorting out how JAMWiki works.
First note: Think of TopicSpaces as a kind of link farm. That is, for any topic in JAMWiki, if one considers each topic as a subject for discussion, then perhaps much more is knowable about that subject than is captured in the prose and images in the topic at the wiki itself. TopicSpaces can live as a kind of dashboard-style side bar in JAMWiki, presenting all that is knowable about the subject.
How does the TopicMap grow? By two primary means: user gestures with bookmarklets, much like , and background agents that continuously harvest the web. TopicSpaces is an agent-based plug-in architecture that supports both local agents and those that communicate from other platforms through web services. TopicSpaces will eventually also support adding semantic annotations to wiki topics, much like Semantic MediaWiki.
TopicSpaces includes an application called Tagomizer that provides social bookmarking tools; it is an extension of those tools that allows TopicSpaces to serve as a workbench where information resources are collected and linked to existing subjects within the map.
I will have more to say soon. Watch this space... Jack 19-Mar 2007 14:59 PDST
In order to gain access to some of the JAMWiki code, I had to make some methods more visible in
Everything else, thus far, seems to satisfy my needs.
Additionally, a number of changes were made to some of the JAMWiki properties files. That is because I have added new servlet filters that allow the Spring controller to detect TopicSpaces servlets. For instance, Tagomizer, the social bookmarking application, is detected by the URL http://<server>/en/Tago
In order to be able to store string content from TopicSpaces, e.g. subject descriptions and other textual information, I clone methods found, for instance, in EditServlet, and I login and create a "topicspaces" user and give it admin privileges. The tricky part is that EditServlet.save() expects an HTTPServletRequest object, which TopicSpaces does not create. A bit of experimentation has been necessary to sort out which values to substitute for those derived from the request object. I am running JAMWiki/TopicSpaces as a root servlet so the context is simply an empty string. The rest were derived from trial and error. Nevertheless, TopicSpaces can now save its textual content to JAMWiki and retrieve it at view time.
There are two kinds of things I need from JAMWiki:
For (A), I have written an interface to be applied in AnsiDataHandler.writeTopic() that says:
void topicChanged(Topic topic, int whichChange) throws Exception;
I then add a List of listeners and a fireTopicChanged(Topic, which) method. TopicSpaces has a particular class that registers itself as an ITopicChangeListener. There are reasons, hard coded into JAMWiki, that force the use of AnsiDataHandler -- try anything else and JAMWiki throws an exception when it tries to initialize search. So, from what I am presently able to figure out (though other options might allude me at this time), no matter what kind of "plugin" external database handlers are envisioned, one still needs AnsiDataHandler in the path. I can extend AnsiDataHandler and just write a revised writeTopic method, except that it calls methods in AnsiDataHandler which are all "private". Strict adherence to private methods clouds extensions to JAMWiki and renders difficult the process of writing plugins that rely on JAMWiki internals.
This allows any external entity to listen in on changes to JAMWiki.
For (B), I would like to do something similar with an interface that, I imagine, looks like:
void addTopicContent(ModelAndView next) throws Exception;
I have not built such an interface yet. I have built and regularly use that which is described in (A), which allows TopicSpaces to create SubjectProxy objects for each new topic added to JAMWiki. By injecting new content into a JAMWiki topic view, I can then modify CSS and the JSP files to paint a side bar that is a TopicSpaces view into that subject. -- Jack 23-Mar-2007 13:41 PDST
void addTopicContent(ModelAndView next, WikiPageInfo pageInfo) throws Exception;
Just a note copied from previous conversations I've had with Jack, but I'd like to make it clear that JAMWiki is first and foremost a wiki engine. The code should evolve so that it can be made easy to extend, allowing something like TopicSpaces to run on top of it or as a plugin, but barring a strong argument otherwise this kind of functionality will probably not become a core part of the core JAMWiki engine. There has been other interest in integrating a blog engine with JAMWiki, so it's clearly functionality that is important to some people, and I'd like to do everything possible to make extending JAMWiki functionality to support this kind of feature as easy as possible, but at the same time it's important to make sure that the core engine stays relatively simple.
That caveat aside, this work looks interesting, and others may want to look into what is being done. -- Ryan 19-Mar-2007 18:01 PST