reduce impedance of disparate specialized content types

i've implemented substantial systems that have different content types (Mailman, Collector / Tracker, Z Wiki "parenting", Emacs allout) and have been thwarted when i wanted to enjoy their respective strengths in combination. they're separate, and isolated from one another, when they could offer great strengths in concert.

i intend to enable easy combination of disparate content type features by expressing the specialized structuring of content types, in general, as application of explicit descriptions on a generic infrastructure.

reduce impedance of after-the-fact or rigidly specified metadata

metadata, which is used to structure the aforementioned content types, is a kind of description - data about data. in my description oriented model, it is another facet of data - something to be included in an appropriate part of the data's description. rather than being relegated to a separate programmatic layer, the layering will be developed in the description medium, accessible and susceptible to processing like all parts of the implementation description.

further, the creation of descriptions can be used to structure other descriptions, making everything amenable to navigation and incorporation.

conversation vs. organization - avoid loss of "water under the bridge"

in some ways, computer-based communications enable more intricate and elaborate collaboration between people than was previously possible. they also enable more inundation - the likelihood of being deluged by information if not well organized. the challenge is to provide organizational measures which scale at a pace proportional to the increasing access.

one key measure is to leverage decentralized attention when connections are being made, so that it's possible to collect knowledge and organize as it is developed. rudimentary examples include online FAQs, issue trackers, knowledge bases, wikis, and so on. these examples are all limited in varying ways, but still useful, demonstrating some benefits of incremental, decentralized documentation - and typically, the impedence to interoperation between disparate content types mentioned above.

orientation

it is by answers in context that people get familiar with a subject, not by collections of disjointed answers, alone.

disorganized content management enables capturing and presenting vast amounts of knowledge, to the point that increasing bulk impedes, rather than promotes, discovery within the captured info. conversely, there are many ways to organize any collection of details, reflecting various stories in which each detail may be involved. limiting the use of a detail in one single organization precludes its illumination of the other relevant stories, and precludes expressing crucial relationships between stories that the detail's shared involvement signifies.

my aim is to provide for connecting details within multiple contexts, and provide the means to navigate and operate on the details oriented according to particular contexts - being able to identify and navigate contexts, as well as details, as needs be.

TAIS Orienting describes in greater depth what i mean by "orientation".

rigidity of strictly hierarchical info organization versus flexibility of layers

eg, http://esd.mit.edu/symposium/pdfs/papers/moses.pdf

in the approach i'm taking, different levels of description - data and metadata, payload and protocol, content data and content type - are not separated different types of code. they are all, themselves, expressed as layers of descriptions, themselves susceptible to examination and conditioned operation. in this way, the layers can be expressly organized for manageability (TAIS Orienting) without creating unnecessary obstacles to reuse and interoperation.

primacy of an event model

Business Unusual: How "Event-Awareness" May Breathe Life Into the Catalog

the abc harmony project strawman document and data model

movements within the library metadata community suggest that recognizing transitional events as an essential part of the data model is crucial to metadata interoperability. i am concerned with some related issues of description.

my concerns have less to do with unifying or reconciling standard models than with expressing descriptions in a way that is conducive to collaborative refinement and growth. rather than reconciling standard models, i am concerned with reconciling the model for each description.

[what follows is even worse hand waving than the rest, but for what i feel are really good reasons.]

this leads to examining what the foundational elements of description are. in my concerns, they are the specifics of the coupling between details in different contexts: how they depend on one another and how they can vary. this is related to change management, and also relates to the focus in the harmony project on transitional events. this all contributes to my focus on facilitating a daily log of project development activity as my trial implementation, as a practical example of incrementally refined descriptions.

so my initial target, once the initial platform is established, is to implement a daily projects log using items that are inherently revisable, ie have different renditions and constituents as their development progresses through time. this will enable me to maintain my daily work and distractions log (which i've been maintaining as allout outlines - a recent one covering three and a half years, with over 14,000 items) as a variety of perspectives on project and incidental entries, including but not limited to a daily perspective, a cumulative project frontier perspective, a projected activities perspective, and so on.