OrganizationObjects

I am contemplating developing a general resource for holding information about various kinds of associations between content objects. The goal is to complement general content with reusable organization and process features, across applications. The intended upshot is that, rather than having to choose between a wiki and a weblog and a maillist archive and an issue tracker, these applications are actually just particular perspectives on content that is associated with the organizational and procedural features of any and all of these modalities.

Background / Purpose

My work efforts have generally come to focus on collaboration-structuring applications - list management (mailman), issue tracking (tracker), 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
• 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