[Zope-CMF] Collective Organization Aspect

[Ken Manheimer]

[Daggone - i meant to include some contents in my reply!  (We're in
the process of moving systems, and i was displaced and misused the
unfamiliar mail tool i was using - sorry about not being more
thorough.)  Here's what i meant to send:]

On 9 May 2001, Kent Polk wrote:

> Collective Organization Aspect as Distinct Object
> http://cmf.zope.org/Members/klm/OrganizationObjects/view
> 
> I have a few half-baked ideas...
> 
> > Organization objects would keep track of associations for collections of
> > content items, including things like:
> 
> The following four items are almost a constant desire for any
> Zope-based project I have worked on. (The remainder mostly also,
> but not as high a perceived value)

This is useful and welcome info!  There's a lot of things i'd like to
push towards, it helps to get some correlation about which particular
pieces matter to others.

> [...]
> I continue to hold the position that standard search list results
> provide a fairly miserable interrogation framework. It simply isn't
> a natural way for people to discover information. Humans discover
> information by relationships (frameworks); computers by comparisons
> (searches).  The above items provide discovery frameworks that
> search results lists don't.

I agree.  Here's my take:

Searches, links, and structural organization all have their virtues
for finding information - i would not want to trade one for another.
With searches, you can find what you're seeking when you know how it
looks.  With links you can find your way to the explicitly connected
places.  But living with only links and searches is like living in an
imaginary world where every room is connected to every other by
transporters (beam me up scotty).  It lacks neighborhood, topography,
landscape.  It lacks relatively grouped regions by which you can
recognize *where you are*.  And i think it is by relative regionality
that we really get a handle on bodies of information - that we get
familiar with them.

I'm hoping that we can provide organization objects as a basis for
building regionality, of whatever sort suits people purposes.  There
are a few organizations i know i want.

> What if, instead of implementing a CMF ZWiki, the different,
> successful components of a ZWiki were made available to all CMF
> items?  A WikiNames catalogger portal_types Action? A new framework
> metadata type for CMFTopic?  Seems to me that they would need to
> work in conjunction with each other to be able to restrict Wikinames
> to the current framework though...

This is what i'm hoping to propose this for the long term.  For the
short term, we need somewhere to migrate the existing wiki content, so
there'll be a CMFWikiForNow (i think that's happening).

I'm hoping when i surface from a consulting gig pretty soon, now, i'll
have a moment to put together some proposals.

I have some other relevant notes in my CMF folder - kent, you were
part of that conversation, too:

  http://cmf.zope.org/Members/klm/ReducingImpedence

I see organization objects as being association specialists, with
different ones for, eg, linking, date ordering, path sequencing, etc -
with a particularly distinguished one that delineates the CommonName
namespace for page collections.  This CommonName namespace would have
a privileged place among organizations - i don't think we want content
links on a page to point to different places depending on the way
you're viewing it.  That would probably be ok for meta links, like
next/previous, which might vary depending on, for instance, whether
you're looking at the car mechanics or the car-show-room slide-show.

The CommonName spaces would also be federated - collection elements
may themselves be collections, with the names of encompassing
collections visible inside the containees, and not vice-versa.

It's really nice to hear you're thinking in similar directions.  I
think some of these wiki-style features for all CMF content would
provide significant benefits for dealing with that content - managing
it, finding it, and generally living with it...

Ken
klm@digicool.com