[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