gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz] PEG: Requirements for RDF API


From: Tuomas Lukka
Subject: [Gzz] PEG: Requirements for RDF API
Date: Sun, 6 Apr 2003 17:34:38 +0300
User-agent: Mutt/1.4.1i

=============================================================
PEG swamp_rdf_api--tjl: 
=============================================================

:Author:   Tuomas J. Lukka
:Last-Modified: $Date: 2003/04/06 13:03:04 $
:Revision: $Revision: 1.1 $
:Status:   Incomplete

This document outlines the main issues in the Jena api
currently in use and proposes a lightweight api of our own
to replace it.

Issues
======

- Are there any APIs out there that already support our needs?

Problems with jena
==================

The most important problem with Jena appears to be that it does not
support observation.

With Gzz, we were moving towards a functional style of programming
where we could easily cache the object given by f(node) since
the node could be observed.

Jena makes this impossible because there are no change listeners.
Wrapping or extending Jena to something that would have them would
be a major task which would result in a more complicated API.

Another issue I (personally) have with Jena is that it tries
to be too object-oriented: I first thought (and liked that thought!)
that Statements and nodes were independent of the model. However,
this was not the case.

Design
======

The first, most important design decision is between implicit
and explicit observing. Gzz used explicit observing, due 
to having an object per cell. However, the tradeoffs are different
here.

The benefits of implicit observing are ease and purity of the functional
approach: in the explicit approach, forgetting a single obs somewhere will 
make the code buggy in a potentially dangerous way. However, the implicit
observing requires wrapper objects for all parts of the API.

I'm in favour of implicit observing, since we *can* wrap all parts
of the API without too much cost: if we make the API non-object-oriented,
in the sense that the individual nodes and statements are not tied 
to any model/space, we only need to wrap O(1) objects.

Additionally, we can cheaply make "derived" models, 
e.g. when implementing the model_versions--tjl stuff.









reply via email to

[Prev in Thread] Current Thread [Next in Thread]