[Activerdf] status report on new activerdf version

Eyal Oren eyal.oren at deri.org
Wed Oct 4 21:00:39 IST 2006


Hi all,

Despite the silence on the mailing list for some months, we have been very 
active here in DERI rethinking the design of ActiveRDF.  The experience 
with the first initial implementation (and the many problems encountered) 
made us aware of some fundamental problems in our design.  Instead of 
adding new features to a problematic code-base, we decided to redesign and 
rewrite ActiveRDF from scratch.

Now the time has come to inform you of our current status: things look much 
better than I thought they would around this time. Some changes and 
features:
- we have radically simplified the internal code.
- we don't cache anything anymore but completely rely on the database [1].  
- we support multi-inheritance and multi-instantiation: 
	eyal.class...[RDFS::Resource, FOAF::Person]
- you can extend these classes, such that eyal.birthday will work (if 
	defined in FOAF::Person)
- we support namespace abbreviations and put constructed classes into the 
  right namespaces
- we support (rudimentary) data federation (querying multiple sources) with 
	(configurable) single point for updates (one data source will receive all 
updates)

Currently, most of the functionality of 0.2 is already re-implemented (but 
not everything yet).  Some adapters need to still be updated to the new 
internals, but that should not take much time. And of course, as written 
above, we have added many new things.

Our goal are:
- for ActiveRDF to not add any time- or computational delays to your 
  program.  ActiveRDF is just a transparent proxy, your code determines if 
your program is fast or slow: if you do many queries, it will be slow.  If 
you do only few queries, it will be fast.
- for ActiveRDF to correctly support RDFS semantics. This is partly the 
	responsibility of the datastore (we don't do any inferencing ourselves, 
and we will never do so), but also partly ours: the proxy-objects that we 
create should behave as if they are RDF objects, not object-oriented 
objects (for example, they can have multiple types and can have multiple 
superclasses). 

I encourage you all to take a look at our new work [2].  It is definitely 
not stable yet (the Query API is still very unfinished) and I am very much 
open to any suggestions on improvements that you would like to see.  
Particularly, Demetrius already announced to work on a better Rails 
integration, something that I'm very happy with since I did not get around 
doing it yet.

I will over the course of the next days try to update as much documentation 
as possible on the wiki. Please feel free to add/edit anything that you 
think is unclear/outdated. We will make a release when we have more tests 
running and when we are more confident about our code.

 -eyal


[1] the non-caching behaviour might not be what you're looking for. In that 
case, please write an extension to resource.rb for caching predicate 
values. It should be very easy. But ActiveRDF itself will always assume the 
design principle that data can change anytime, it is nothing more than a 
transparent proxy that translates method invocations into database queries.

[2] you can either use bzr to get the development branch (bzr get 
http://eyaloren.org/activerdf) or download a snapshot from the website 
(http://activerdf.org/activerdf-snapshot.zip).


More information about the Activerdf mailing list