[Design] Chandler as a Knowledge Management Tool: my musings

[Ducky Sherwood]

Piero --

I think you've got the gist of it.   There are a few words or terms that 
I'm not sure fit with how we use them internally, but we don't 
necessarily have completely consistent use internally.  (There is 
currently an effort to standardize our internal language, however: stay 
tuned.)

The things that seemed like they might be a little off are:

"The CPIA" -- You imply that CPIA is a tool, but I think a better way of 
thinking of CPIA is a as a framework that tools are built out of.  There 
is some tool that we will eventually build that will let you build CPIA 
Views, but that tool doesn't have a name yet (that I know).

I don't believe OSAF has any plans to fund implementation a ZOPE 
repository, though of course it being open source, at some point in the 
future somebody in the community could plug a ZOPE repository into Chandler.

I'm a bit fuzzy on exactly how deeply involved agents are in queries, 
but I think they are not quite as tightly coupled to queries as you 
describe.  (I'll leave that question to Stuart and Ted.)  You are 
correct, however, that queries are absolutely fundamental to our 
architecture.


Piero Giuseppe Goletto wrote:

>I have tried to map Pollard's vision into Chandler, and please believe that
>it is MORE an exercise in understanding THAN a design issue for Chandler.
>That's why some phrases are hypotetical.
>
>The USER (a person, or a member of an organization) accesses Chandler by
>entering one of the WORKSPACES he has got or he has previously defined. The
>predefined workspaces would contain a diary ("Lotus Agenda" obviously comes
>to mind) and an e-mail client ("pine", "mutt", "kmail" come to mind). The
>User can easily define more workspaces. A System Administrator can define
>standard workspaces for all Users in the same organization. 
>
>All workspaces are created and managed by a WORKSPACE MANIPULATION TOOL,
>which in the Chandler base design would be the CPIA. Through the CPIA the
>User would access to his CURRENT DOCUMENTS (whatever they are) by using
>appropriate PARCELS. I use the term "parcels" to refer to the Chandler
>Modules that directly access to document, so that for instance we have a
>PARCEL which allows user to read and post e-mail, another as address book
>and so on.  
>
>All data refer to a common REPOSITORY which engine is an XML-based DB (and
>Lucene and Sleepycat).. Or ZODB in a future (I am a Zope/Plone user). 
>
>Appropriate DATA EXTRACTION TOOLS  would use QUERY models to retrieve all
>information the User may request. For instance, Chandler would use a query
>model to retrieve all e-mail I sent to this mailing list, or for instance
>Kaitlin's email address from the SUPER ADDRESS BOOK which is Chandler's
>Contacts module.
>Those Query models would be AGENTS which RETRIEVE DATA; behind CPIA there
>would be AGENTS which INSERT/RETRIEVE/UPDATE data. 
>
>Some AGENTS would translate Chandler's internal format into the external
>format required for the application - an immediate example is a blog entry
>or a web page or index External Documents for reference in Chandler.
>
>SPECIFIC CONNECTORS allow for instance to send or receive emails.
>
>Regards,
>
>Piero Giuseppe Goletto
>
>
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Design" mailing list
>http://lists.osafoundation.org/mailman/listinfo/design
>  
>