Re: [Dithaka-devel] RDF concept in Dithaka

[Thomas F. <tfo...@us...>]

Hi

On Fri, 2006-11-24 at 09:20 +0200, pieter van zyl wrote:
> > I have various thoughts, I guess.  I think simplifying the discussion
> > stuff would probably be useful, so yup it's likely that doesn't need
> > resources.  I think the resource stuff does have some benefit - so the
> > choice would be 1) either lose the benefit or 2) try get the benefit
> > with some other mechanism, like tagging.  And again, the original
> > thinking was to add collaboration to a project with hopefully minimal
> > effect on existing classes.  Must be many ways to do that.  
> Yes, in the end I see dithaka as a library with an API that can be used
> by a project to add collaboration. 
>
> I just feel(I might be wrong) with RDF it is tightly coupled and the
> project using the resource and RDF concept(dithaka) needs to be aware of
> this.

In my view, using the RDF concepts makes the coupling looser, and more
dynamic. It does add some complexity, perhaps, because there is an extra
level of indirection, but this is unavoidable in a metadata framework.
In my view, a metadata framework is the only way to allow easy
"retrofitting" of Dithaka collaboration features into an existing
codebase. Does this mean that Dithaka should continue to use the
Reosurce concept internally? Not necessarily. I'm not against
simplifying the internals of Dithaka, but there are some things we could
potentially lose. e.g. with the Resource stuff, a message can be in
response to another (predicate = reply), but it could also be tagged as
referring to a point in a completely separate message (predicate =
refer), as contradicting another message (predicate = contradict), etc.
There is simply no way that we can statically determine all these
relationships. Granted, we don't use any of these relationships
currently, but the possibility is there for us to do so, and would be
lost if we adopted a more static structure. I'm not saying that we
should not simplify things, only that we need to consider the
consequences.

If we do make the internal model more static, we need to do so very
carefully, because by doing so we're effectively splitting our current
model (currently the internal model is the same as the external/api
one). We'll then be using the more static internal model for
collaboration features that we provide in Dithaka as standard (e.g.
forums, mailing lists), but we'll be using the metadata framework for
any additional collaboration features that people may need, and as the
integration layer to existing code.

An alternative could be to keep using the resource stuff internally, but
to create simple wrappers that hide the internal RDF structures,
exposing only the more static relationships and behaving the way one
would expect normal forum objects to behave. Thoughts?

> Also, talking to Andries it seems our description of dithaka might be
> incorrect? 
> 
> Are people downloading and using dithaka as a forum api or are they
> actively using the resource concept to link complex data?

Yes, the description is not 100% complete, as it does not mention the
RDF stuff at all. Is the following better?
"Dithaka is a dynamic collaboration framework written in Java. It uses
RDF-inspired subject-predicate-object relationships to relate objects to
one another in a flexible way. This allows the framework to create
arbitrary relationships between collaboration objects.

Using the same metadata model, Dithaka can also be used to add
collaboration features to existing (or new) projects in an unobtrusive
way, by linking objects in the existing data model to the collaboration
objects provided by Dithaka.

Dithaka ships with integrated mailing list and web discussion forum
modules; every message sent to the list appears as a post in the forum,
and every post to the forum generates a message to the list."

m2c
-- 
Thomas Fogwill <tfo...@us...>