OrganizationObjectsPrelim

*This is a preliminary stab at an Organization Objects proposal - see OrganizationObjectsProposal for the actual proposal. This document may help illuminate, so i'm keeping it around. klm, May 28, 2001, original draft Feb 15, 2001*

I propose a general facility for maintaining various kinds of associations between collections of content objects, with the associations represented in objects separate from the content containers. This would complement general content with reusable organization and process features across applications.

Goal

The goal is to make it easy to impart the features of various organizational schemes to any suitable content, and in particular, enable the same content to participate in different organizational relationships within different contexts.

For example, rather than having to choose to stick your content in either a wiki or a weblog or a maillist archive or an issue tracker, any and all of these applications will be contexts within shared content can be accessed, according to the application context's particular organizational perspectives.

Background / Purpose

My work has turned out to focus on collaboration-structuring applications - list management (mailman), issue tracking (tracker, collector), wiki (WikiForNow), and so forth. For each application, i wound up working with a new content type developed from scratch, and wound up with a content, organizational, and procedural framework that i could not reuse across applications.

I see the PTK/CMF as being an antidote to this - reusable content that i can plug into new applications. One missing piece is general provision for, as paul liked to call it, "the space between content" - general, reusable ways to express content organization. This is where the organization object comes in.

Proposal

This is a proposal of a kind of object for capturing various kinds of organizational associations between arbitrary content objects, such that any content object (and other organizations) can be involved in the organizations, and such that any content object can be involved in numerous organizations.

Compined with content management framework features like finite state machines and membership, these objects should support arbitrary content as part of calender event management, issue tracking, and other structured collaboration systems. This combination of faculties should also provide for intricately structured, conditioned navigation of content, as in training and troubleshooting systems, and adventure/exploration worlds. !

Some Representative/Central Types of Organization Objects

Organization objects would keep track of associations for collections of content items, including things like:

• Interlinking info - forward and backlinks, (and maybe change records, for forwarding of outdated references)
• Lineage/thread - contains/is-contained-by, replies/in-reply-to, sibling
• Path - next/previous, audit, and other sequences through other organizations
• Modification time - RecentChanges type info

Instead, "Events" - eg, provenance, revision, offspring, security changes, licensing/publication, etc. Then, eg recent changes can provide discrimination about type of event, and we can use the information to, eg, see the publication history of an object, the germination of other pages from it, etc.

*See http://www.ilrt.bris.ac.uk/discovery/harmony/docs/abc/abc_draft.html and http://lcweb.loc.gov/catdir/bibcontrol/lagoze_paper.htm .*

• Dependency - "depends-on" / "dependents"
• Ranking - ratings relative to other items in the collection
• Audit - traversal incidence statistics, for tracking referrers and referrals

(Cataloged DublinCore metadata already provides for organization according to standard classifications like author (creator).)

How

There are a few reasons for the content and the organization objects to be loosly coupled.

• Loose coupling serves the essential vision of organization information as a service available to any content objects - so that organizational mechanisms are reusable, with any kind of content where it may obtain.
• Multiple organizational features will probably apply to any single piece of content at the same time, with potentially redundant analysis of the change that would be better implemented once in a third-party monitoring pattern.
• Loose coupling also serves deploying content in the context of more than one organization. For instance, some technical tidbit may be relevant in reference manual, book/story manuscript, executive-presentation slide, and/or user guide perspectives. New-media wise, some discussion contribution may be visible in both weblog and wiki views on a topic - and it may pertain to multiple topics.

At the same time, organization objects do need to be maintain close tracking of changes to content.

To achieve all this, organization objects would be implemented as services which track their subject content via monitoring of actions in relevant event channel notifications. Each organization object type would have a characteristic interface signature, and be available for consultation via a Zope service discovery mechanism.

A convenient example would be tracking of the linking, modification time, and parenting/lineage relationships in current ZWiki using organization objects which watch the event channel for content changes within the wiki namespace container (currently, a folder - this sort of containment may well be delineated in other, higher-level ways as we move forward). A weblog perspective would use much of the same information, but disregard the name-linking and add sequencing for ordering siblings.

A hybrid "wikilog" could combine the sequencing and linking info for the best of both worlds. The addition of citation-linking organizational info would allow automatic linking of cited text to the citation source content, and vice versa.

So, organization objects would track changes of their target content through the event channel. Conversely, their information would be available to views on those collections - eg, a wiki or weblog view - as Zope services implementing particular organization service interfaces, via a new Zope service discovery mechanism.

This all suggests that you view content with respect to one organizational context or another. I would suggest that context is an object embodying a particular "skin" for the content, an organizational framework, and workflow policies by which the content is seen. The current context would probably be an artifact of the user's session - a changeable artifact, as the user switches views, as well as what is being viewed.

Federating Organizations - Scaling

• The subjects of the associations may themselves be organization objects, constituting a basis for federations of organizations.
• Different kinds of organizational aspects are probably unified in different ways. For instance, lineage/threading is trivaial - hierarchies federate by attaching the subhierarchy at a leaf. Modification time is less independent - but inherent sorting of times within the parties to the federation enables low-order compute strategies. Federation of classification metadata is syndication. RSS, RDF, and other syndication strategies may constitute our mechanisms for that. Etc.
• Ultimately, we need to anticipate federation across large scale ranges, as zope's client and storage replication mechanisms present opportunities for large collections of sites. We probably need to start our development concentrating on integral, well-defined collections - but once we have the outlines of an infrastructure for that, we may want to see about accomodating recursive containment of organizations, for extensively federated sites.

Raw Notes

• In principle, organization objects delineate content collections. Multiple sequence organizations may dictate different paths through some common items, one representing a slide presentation of the material and the other an in-depth manuscript. Or one constituing a weblog-style organization of items, and another being an author or topic corpus.
• In order to understand the place for these objects in the CMF implementation, we can experiment with implementing wiki and weblog-like content collections.