[ Previous: The Client API | Up: Development ]


The Nabu project is an attempt to bring the Semantic Web and instant messaging together, making the increasing amount of information exchanged via instant messaging accessible using semantic web technology.

An ontology was developed to describe instant messaging conversations. Using the RDF standard to represent the data and the promising SPARQL query language for user queries, Nabu integrates well in existing semantic web infrastructures. To make better use of the stored information, users can attach metadata to their logs.

A privacy model was developed to control the accessibility of RDF data, an area where no proven implementations or standards yet exist. Working on resource-level, it is possible to control accessibility per resource. Although it has limitations when you need more fine-grained control and hide certain properties only, it works well for Nabu.

The concepts were implemented as an extension for the Jive XMPP server. Thus a proof-of-concept implementation is available and can be used by interested people to integrate instant messaging and semantic web. In the DFKI KM working group, it is already used in the EPOS project. The user observation functionality was successfully integrated into the context elicitation and tested.

Nabu is still a prototype. To make it suitable for wide-spread use, more effort and feedback is needed. The main issues are:

  • The user-nabu communication is currently text-based. This is flexible because it can be used on every platform and in every client, but is neither convenient nor user-friendly. Graphical frontends would be desirable, preferably integrated in client software (via plugins). Other options are a web frontend or the integration in frameworks for desktop search.
  • Evaluation is needed to find out whether the chosen privacy model meets the user requirements. This needs experience from daily use of "real users", as different usage patterns need different privacy models. At the moment, there is always one policy active at a time. The advantage is that it is easy to manage and clear which policy is used for the current chat. It would also be possible to specify a policy for specific chats, e.g. "everything I write in MUC room #workgroup should be readable by the whole workgroup". While this is more powerful, it has the disadvantage is that the user could forget about the channel-specific setting and share information with more people than intended. A third option would be to always use restrictive privacy settings when logging (i.e. only participants can read messages). Users would manually share the log afterwards by marking the conversation in their client plugin and assigning a less restrictive policy. This usage pattern is already supported, the user must just leave the default policy active, and assign other custom policies to logged messages.
  • On the implementation side, the time needed for query execution could become critical on servers with many users that store chat information over a long time. The scalability of the used approach (working on the whole graph, removing the invisible information from the graph when querying) is limited, and caching CBDs and models will help only up to a certain graph size, user number and query frequency.
  • Currently Nabu is only accessible via the XMPP protocol. To make access easier, it should be possible to query the archive using HTTP(S) requests. On the other hand, every additional way to access the archive is an additional security risk. Besides the usual vulnerabilities web servers have, the interface must manage user authentication, something we get for free when using the Jabber protocol.

[ Previous: The Client API | Up: Development ]

Last modified 17 years ago Last modified on 07/31/05 00:21:05