Refactoring ActiveRDF

We should refactor ActiveRDF in order to allow us to concentrate the efforts on the parts of ActiveRDF that we really need, instead of fixing bugs in the Resource class.

• We need to use the adapters for the stores, the query interface and the Federation manager (the "low-level" functionality)
• We do not need the RDFS::Resource class and the automatic creation of types
• The low-level functions always use RDFS::Resource when Queries are returned. This should be changed to something more leightweight (maybe configurable for each Query) (see below).

RDFS::Resource usage

At the moment, all queries automatically create RDFS::Resource objects for the resources found in the RDF. It would be cool to be able to configure this, so any class that accepts an URL as an initializer parameters can be used.

Probable examples:

Query::resource_class = TaliaCore::Source

# or, for a particular query
query = Query.new
query.resource_class = TaliaCore::Source

Handling of contexts

In order to use contexts, it would probably be easiest to allow an adapter to be created with the context given as an parameter:

{{ #!ruby adapter = ConnectionPool?.add(:type => :redland, ..., :context => "ontology 1") }}}

The adapter would then work only with triples from this context, and also only add triples to this context. The advantage would be that ActiveRDF doesn't need to be explicitly aware of contexts, and there is no special case for other RDF stores that don't support contexts.

Using specific adapters

For using the context one must use the specific adapter for that context, instead of the FederationManager?. This is already possible: add and delete work directly, and query can be used by passing the query object directly to the adapter (instead of using query.execute)