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

David McCusker david at treedragon.com
Sat Nov 2 12:48:44 PST 2002

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.

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.

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.

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.

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.

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 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.

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.


More information about the Dev mailing list