[Zope-CMF] RFC: ThinkingToolKit for CMF

Jeff Archambeault jarchambeault@qwest.net
Tue, 22 Jul 2003 02:21:10 +0100


Greetings Fellow CMFers,

Please excuse the length of this message. It contains an introduction
to The Open Idea Project as well as a proposed CMF plug-in currently
under development.

The story starts at http://www.openideaproject.org/. 
<http://www.openideaproject.org/> It's a loose
amalgam of squishdot, well-modified ZWiki, and ZRTChat. It's successor
currently lives at http://www.openideaproject.org:8080/dev2, and is
CMF/Plone with some plug-ins from Gitte and The Collective.

The Open Idea Project hopes to build a distrubed application to allow
the collaborative development of ideas. The current state of
collaboration on the internet can be boiled-down to email, CVS and
weblogs. The TTK aims to provide basic "Thinking Tools" for use with
more standard collaborative tools on the Web. We use CMF to provide a 
basic but expandable set of
collaborative tools such as news, event scheduling, wikis, chat, and
many other document types. TTK will leverage CMF to give "cothinkers"
many other additional tools.

We will be concentrating on the use of open, flexable thinking tools,
with the assistance of Lucas Gonzales and The Minciu Sodas Laboratory
(http://www.ms.lt/). The framework could have many other uses.

- Tools for using existing CMF resources.

- Additional tools can be easily added.

- probably in the form of catalog queries

- A common user interface (UI) provides:

- Tree-type visualization display provides view of object relationships.

- Browsing area for object rendering.

- Dedicated editing area for the editing of the rendered object,
object metadata, and general text input.

- Tool selection display selects relationship to be created between
objects.

- Creation of arbitrary relationship-types.

In a way it would be a type of "workflow", and could be used both in
conjuction with and as a complement to portal_workflow. It could be
seen as a web annotation tool, such as those for the "Semantic Web".

Since the development in CMF has been my "job", things haven't gone as
rapidly as I would have hoped. It seems that I'm just getting the hang
of CMF, and Zope in general, even after about 3 years of use. Making
mods to squishdot is one thing, but building an application is quite
another...a life.

The current mock-up at
http://www.openideaproject.org/dev/oip_view_rev1. Everything has been
built using DTML and TinyTables so far. I suppose this could be seen as
a hack of the "Link Objects Proposal" The big issues in the way are:

- Add content objects using 1 form instead of 3. One new "Link Object"
would be created as well as the usual possibility for a Stock CMF item
to be created "at the same time". I saw the "[Zope-CMF] publish
multiple objects/ editions?" thread, and I believe thre are common issues.

- Storage of lots of "small" "Link Objects". These will just contain
metadata, and will be fairly small compared to streamed video, for
example. I'm thinking PortalBTreeFolder or ZGadfly for now, and perhaps
an external PostgreSQL db later.

Once these are solved, we'll have some usable "cothinking tools", Edward
de Bono's (www.edwarddebono.com) "Six Thinking Hats" and several of the
"CoRT" tools. These could be substituted for other tools depending on
the needed applications. These are "classic" thinking tools with years
of use in all sorts of intra-personal situations. As part of our
research, the OIP will be developing new collaborative tools more
suitable for on-line collaboration in a distributed network (ZEO?).

 From what we've seen happen with weblogs, moderation is necessary to
bring applicable content to people's attention. The same goes for wikis
- unless the wiki users have condensed the wiki text, the content takes
on a 'weblog' format of appended comments. Developing "plans" of any
sort requires some serious "mining" and editing. From what I've
experienced, Zope's Fishbowl is not a big improvement, although allowing
scripting within is a great feature/mistake.

So I've created an "OIPLink" object, gave it "id", "SchemaType",
"Parent", "Child", and 10 other possible properties. No big deal to
create and have the current UI sees it available for creation as a new
CMF Object. Everything else is in it's own skin folder, along with
other modified objects, stylesheet properties, and other DTML methods
which give the site it's non-canned-look. Because I wanted to get a
mock-up running ASAP, the list of usable SchemaTypes is contained in a
TinyTablePlus instance. Easy enough to create UI for table management,
but should be "cleaner", with SchemaType being a subclass of the OIPLink
class. They should be user-creatable and shareable, like 'SchemaTypes'
below.

A few extra "SchemaTypes" have been added, such as a "hack" for
translations of content, for PortalEvents, Journals, News Items, and
"Project Root", the later being a parent-less object that denotes the
"root" of a "Project". These OIPLinkObjects have many common properties,
such as 'parent', 'child', 'project' and 'SchemaType'. The 'translation'
link object will have an additional 'language' property.

Managing all of these 'SchemaTypes' with all of their unique properties
is another major issue. Users should be able to create their own and
publish them via the normal workflow process. Sets of default system
tools should also be available, such as any initial lateral thinking
tools the OIP will use.

A side-effect of LinkObjects is eliminating the need for a
moderation/ranking system. The environment would then be like shared
lab notebooks, where project members can follow each other's notes. The
"flow" of project members' work can also be "directed" by "moderators"
placing "childless links" in strategic locations in the relationship
tree. Project members also have the option of "disqualifying" the works
of other members they find offensive in any sense, with the use of added
SchemaTypes, like Edward de Bono's "White Hatting" such a user's object
with a child "CMF Document" with "just the facts", and a "Red Hat"
document "showing what you really _feel_ about it". Perhaps
"self-moderation" is a better term for the moderation style.

Additional SchemaTypes could be used in a more traditional moderation
system. By adding SchemaTypes for each of slashdot's moderation
categories, for example, a simple query to the catalog could generate a
simple "tally" system. These tallies could be massaged in a fairly
trivial way to give "average" rankings for contributions.

While searching for ways to express 'SchemaTypes', I doscivered things
like XML Pointer, XML Base, XML Linking, OML/CKML, and OntoWeb, another
CMF/Plone site. All just a little too much for me to handle solo, but
close enough to realize their importance.

I also discovered how simple it would be to integrate a 'SchemaType' for
simple web annotation, such as Wendy Seltzer's OpenLaw web annotation
project at http://cyber.law.harvard.edu/projects/annotate.html. Wendy
uses a unique string of text, a note, and some simple user info as
metadata. Some experimentation will be needed with dynamic
collaborative text, like wikis. I'm thinking that rendering would be
similar ti wikis. This scheme woiuld also provide for a dictionary
'layer' to documents.

I'm mindful to relate all of this to jshell's composites proposal.
Imagine an "Article" SchemaType that contained properties for
'textSource', 'photoOne', 'photoTwo', and 'photoThree'. Jeffrey's
example at
http://cmf.zope.org/rqmts/proposals/compounds/compoundproposal.txt has
"Main Story" and "Photo", the equivalents of the ShemaType properties.
"Related Links" and "Stock Quotes" would be generated by their own
methods through the rendering method for an "Article" (it's skin),
rendered in some consistant way throughout the site or other defined
sub-area. "Related Links" would be a method that returns the "Titles"
of objects of the same "Subject", and "Stock Quotes" could be a method
that looks for the names of companies in 'textSource' and generate their
stock info, otherwise it displays listing of today's active stocks. The
number of "photo" objects that are used would determine the "page
layout" of the skin, each option pre-generated. Neither piece of
"generated" content really needs to be "remembered" as being parts of
the "Article", they come as by-products of what's in the catalog.

I've been lurking long enough on this list, so it's about time that I
_think_ I have something to contribute back to the community. These are
the things I'm attempting to use CMF for. Just the knowledge of knowing
that "Yeah, CMF is designed to do something like this" is a motivating
factor for me. The Open Idea Project intends to do some interesting
things, such as becoming the internet's first "wetware distributed
network" (distributed cothinking), with it's ThinkingToolKit for
CMF/Plone. I would greatly appreciate any comments, questions,and
recomendations anyone has on any of this.

Sincerely,
Jeff Archambeault
The Open Idea Project
http://www.openideaproject.org/
jja@openideaproject.org 
<http://groups.yahoo.com/group/openideaproject/post?protectID=045166091098042031072171163140243130018098169194061027074150141050004>