[Nepomuk] Refactoring for Soprano 3

[Sebastian Trüg]

Hello,

Soprano 2 IMHO has a nice design. Backend, Model, and FilterModel suited my 
needs very well and were nice to use. But now it slowly reaches its limits.

With Virtuoso the introduction of transactions become very important. I tried 
to stack them on top of Model as you can see in the experimental branch[1] but 
the resulting design is flawed and cannot be any different since we need to 
stay binary compatible for KDE.

Thus, it is time for a redesign and also time for you to state your needs and 
ideas.

Attached you find a preliminary design in the form of a crude UML diagram. It 
is based on the sesame2 idea of Respository vs. RespositoryConnection.

A few words of explanation:
- Model is split into two classes Repository and RepositoryConnection.
  Each RespositoryConnection represents its own transaction object, i.e.
  can perform multiple transactions.
- A Repository can create an arbitrary number of RespositoryConnection 
  objects.
- Backend is now RepositoryFactoy (better name welcome). It is used to 
  create StorageRepositories which replace StorageModel and have settings
  like storage dir and the like.
- FilterRepository and FilterRepositoryConnection replace the current
  FilterModel.
  A FilterRepository would need to create its own connections which carry
  as a member a parent connection created by the parent Repository.

This is the basis I would like to start the discussion from.
Another issue is inference which I would like to integrate deeper into 
Soprano. The straight forward design would be to add a flags parameter to 
method like query() and listStatements() which can for example be 
EnableInference.

Please discuss.

Cheers,
Sebastian