TAIS Principles

Early notes about my Turning Answers Into Stories rationale

the goals underlying [pendref] Turning Answers Into Stories have driven many of my interests and efforts in software development, including my work on mailing list softwarewiki refinementsissue tracking software, and so on. my experience with these things has lead me to some principles which inform my aims with TAIS.

extensive orientation

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

online communications enable conveying vast amounts of information. without organization, the increasing bulk increasingly obscures, rather than promotes, discovery of specific things you are seeking. intelligent search indexing provides the means to locate specific things that you are seeking, but there are no provisions for situating details so the various contexts in which they belong can be conveyed. every detail belongs in many contexts

my aim is to enable connecting details within all of the contexts where they belong, such that those contexts that are relevant to the person doing the searcher can be discovered and navigated, to discover the details in context. (of course, contexts are, themselves, details, to be organized in context.)

see TAIS Orienting for more.

reduce impedance of disparate specialized content types

i've implemented substantial systems that have different content types (Mailman, Collector / Tracker, ZWiki "parenting", Emacs allout) and have been thwarted when i wanted to enjoy their respective strengths in combination. their features are separate, and combination is difficult or impossible, when they could offer great strengths in concert.

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.

provide for various organization methodologies

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

TAIS recognizes that hierarchical, networked, and layered composition methodologies each have respective advantages and disadvantages, and provides for using them each, and combining them, as needed.

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 providing for continuous change.

my initial target, once an initial platform is established, could be 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 in my allout outliner 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.