other formats (Re: [Dev] 4Suite RDF and ZOD)

Michael R. Bernstein webmaven at lvcm.com
Sat Nov 2 22:13:07 PST 2002

On Sat, 2002-11-02 at 12:48, David McCusker wrote:
> I'm trying to get my toes wet on this mailing list, but I'm not sure
> exactly where to start.  Forgive my random choice for a first reply.

Hi David!

> Daniel Krech wrote:
> > I am excited to see OSAF take on the RDF-based PIM and the non-web UI
> > parts of the Redfoot vision; And would like to collaborate to see that
> > part of the vision be fulfilled. 
> The phrase "RDF-based PIM" makes it sound like RDF is somehow pervasive
> in the architecture so it cannot be replaced with something else. I didn't
> get the idea this was the long term desire.  Other ways of writing content
> persistently might join Morgan's RDF prototype.
> [snip]
> To the extent the discussion focuses exclusively on RDF, I find it hard
> to think about alternatives when descriptions of them here might meet with
> early rejection from not fitting current expectations.
> It seems rather clear all the interfaces to storage will be Python based,
> using a object database style of interaction between app code and
> storage backend.  But this need not dictate the storage technology, at
> least not very precisely.  RDF could easily have peers.

John Anderson has emphasized on this list that Chandler will be
developed using a 'Model-View-Controller' methodology. This should make
alternative storages feasible, at least.

> Note I'm not advocating folks use anything related to what I've done in
> the past. I'm just interested in discussing the input parameters to choice
> of storage technology, rather than assuming a choice as given.
> Do folks want to talk about storage at a more primitive and abstract
> level of problem statements and requirements for persistence?  I can
> throw out strawman guesses and analysis of Chandler needs, but this
> might seem rude if it's not welcome.  Do folks want to hear this kind of
> stuff on the list?

I for one, would find such a discussion very valuable, even if it ended
up reaffirming the choice of an RDF centered design. A similar
discussion on XUL vs. wxWindows for the UI was very informative as to
how wxWindows was chosen. My own strawman guesses about how RDF would be
persisted in the ZODB resulted in Eikeon adding a ZODB storage backend
to RDFLib. :-)

But, so far, we haven't really heard from Morgen as to whether any of
our guesses are on the right track.

> I gather the design list focuses more on the 'what' and the dev list
> focuses more on the 'how' (and perhaps on the 'why' at a tech level).
> Choosing a specific storage technology sounds a bit like a 'what'
> decision, if the choice affects external interaction with Chandler,
> since it makes the storage technique a user visible feature.

It was not my impression that the end user is supposed to be aware of
the storage details at all. On the contrary, the Vista prototype relies
heavily on 'virtual' views that are divorced from the storage model.

> I'd be interested in discussion of what must be represented persistently
> without diving right into a particular encoding, since it brings a lot
> of technology specific policy (the RDF way to do things) to the table
> when folks might productively discuss Chandler needs in isolation.
> A description of how Chandler stores content at the 'how' level can go
> down deeper than "use RDF" to a description of graphs and how nodes of
> data relate to one another.

Sounds good to me.

Michael Bernstein.

More information about the Dev mailing list