Log in
Forgot your password?
History for OrganizationObjectsProposal
??changed:- Organization Objects Culprit: Ken Manheimer This is a proposal for a new framework in the CMF that provides for tracking various kinds of content relationships in an extensible, comprehensive way. It is designed to be extensible with new relationships, and useful with any applicable content types, without requiring any changes to the content type implementations. *I've sketched out the motives for Organization Objects in MotivatingOrganizationObjects and the LinkObjects proposal fills in some other details.* Context The CMF offers an extremely good basis for reuse of content types, principally because the only behavior directly coded in the content type implementation is that which is entirely specific to the type. Behaviors having to do with interactions with other objects, and with general services, are realized in the infrastructure. This means that: - Content type developers need only pay attention to the concerns specific to their type. - General changes to/extension of content behaviors can be accomplished without change of all the existing object types. Problem The information managed by a content management system is not only in the specifics of each content item - it is also in the relationships of the items, the "spaces between the content". (Some examples of these relationships are relative modification time, forward and reverse linking info, lineage/provenance - ie, "from which bit of content was another bit of content created?", relative ranking, and so forth.) Without access to this kind of relationship information, CMF portals can only provide for navigation based on folder containment, explicit URL links, or by catalog searches. - Folder containment is an extremely limited and rigid organizing mechanism. - Living with only links and searches is like living in an imaginary world where every room is connected to every other by transporters - it lacks a basis for regionality, neighborhood. In other words, it lacks progressively grouped regions by which you can realize "where you are". The challenge is to provide for tracking of organizational information in a general way that applies across content types, providing for consistent implementation of relationships as they are discovered to be useful. Forces Digital Creations has had some success using its web sites to organize efforts like its community-facing development processes, using wikis, trackers, maillists, and other structured content. However, we've also hit up against hard limits in these content types: - These specialized content types do not lend themselves, by any measure, to integration with eachother. We cannot use wiki pages for tracker message elements, or vice versa. We cannot automatically integrate mailling list messages in either of the other two, without a lot of effort. - We cannot even federate those types with themselves, in a comprehensive way, in order to scale beyond individual collections. Furthermore, if we were to invest effort to integrating these particular content implementions, it would not be applicable beyond the specific combination. It would not generalize. (Thus, we're keen on pursuing this direction, rather than going the route described in my "WikiNG", http://www.zope.org/Wikis/DevSite/Proposals/WikiNG proposal.) The inherent reusability of the CMF's content architecture *would* lend itself to this cross-germination and scaling - provided we could offer the functionality in a comprehensive way, not specific to any particular content type, and extensible to incorporate useful relationships as they are recognized. Solution Provide an extensible, general service for: - Retaining relationship details about content objects as the objects are edited - Reporting that information so it can be used unified with other reports - Used as structures specific to that kind of organization. This would entail: Event-based Tracking of Changes -- Notification about major content-object lifecycle changes - creation, modification (of content, security, or attribute), and deletion - is automatically propagated to organization objects that have registered interest. Optionally, notification interest is qualified for attention to particular content subsets. This generalizes what the manage_after* methods do to propagate object changes to the catalog. With this more generic version, new organizations can be implmented without any change to the content objects. It is up to the organization objects to register for notification with the event channel. This event notification mechanism might be implemented as some kind of generic infrastructure service in the "NewReligion", http://www.zope.org/Members/michel/Components/Components/NewReligion model, or with a general event channel, as tres has sketched in his <a href="http://cmf.zope.org/rqmts/proposals/events_tool">events tool proposal</a>. Catalog-style Query Interfaces -- Organization objects present query interfaces returning result sets that can be unified (via union and intersection) with result sets from other organization services, and also with result sets from the catalog. These interfaces would be patterned after whatever is done for "catalog drop-in indexes", http://www.zope.org/Wikis/DevSite/Proposals/DropInIndexes - in fact, they may *be* drop-in indexes. I dunno. Specialized-Result-Structure Interfaces -- Organization object services also can, when appropriate, present organization-specific query interfaces. These interfaces take result sets and return organization-specific structures, representing an ordering of the result objects according to the organization. For instance, an organization object that tracks object modification-time would take a result set (perhaps from a generic catalog search) and return something sorted according to change time. Such an organization object interface would take qualifiers determining whether to return results in ascending or descending order, whether to consider the last-modification date or the creation date, and so forth. An organization object responsible for tracking lineage relationships would have an interface to yield a quite different structure - a hierarchy indicating the lineage relationships between the subjects, with special cues instead of repeated sub-elements in order to elide nesting cycles. This interface would take, for example, arguments determining whether it should nest indirectly contained objects or present them as being disconnected. The Specialized-Result-Structure Interfaces section examples are significant - i would like to pursue several wiki features as the initial target of this project, including: - RecentChanges - Lineage (See also a related in-progress proposal, for CommonNameSpaces .) - Backlinks and Forward links for general CMF content. Resulting Context - A comprehensive, extensible framework for implementing tracking and reporting of organizational relationships. (This could be seen as providing relational database capabilities across content types, for targeted relationships, at the application level.) - Inherent susceptibility of any type of content to organization tracking, without special tailoring of the content object. - Ability to consolidate searches according to organization with other organizational searches and with catalog searches. - Easy access to specialized relationship information. Thus, we could for instance present incoming (backlinks) links and lineage info with every view of a page. The kinds of relationships i'm talking about are things like: - relative timing of content change events (provenance, revision, publication, origination of new content, security/licensing changes, etc) (For some interesting ideas about the primacy of event-oriented cataloging, see http://www.ilrt.bris.ac.uk/discovery/harmony/docs/abc/abc_draft.html and http://lcweb.loc.gov/catdir/bibcontrol/lagoze_paper.htm .) - Lineage/threading - ZWiki "lineage" and news/email threading are related, and perhaps similarly essential, features. [40 more lines...]