changed:
-
the urges underlying TurningAnswersIntoStories have driven many of my
interests and efforts in software development, including my work on
`mailing list software`_, `wiki refinements`_, `issue tracking software`_,
and so on.  my experience with these things has lead me to some principles
which inform my aims with TAIS.

.. _`issue tracking software`: http://collector.zope.org
.. _`mailing list software`:
   http://myriadicity.net:18080/myriadicity.net/Sundry/mailman_ip7.pdf
.. _`wiki refinements`: http://zwiki.org/WikiStructuringIdeas

.. contents::

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

disorganized content management enables capturing and presenting vast
amounts of knowledge, to the point that increasing bulk impedes, rather
than promotes, discovery of specific things you are seeking, and the broad
comprehension the comes of understanding the organization of your topic.
conversely, there are many ways to organize any collection of details,
reflecting various stories in which each detail is involved.  limiting the
use of a detail to one single organization precludes its illumination of
the other relevant stories, and precludes expressing crucial relationships
between stories that the detail's shared involvement implies.

my aim is to provide for connecting details within multiple contexts, and
contexts within multiple contexts, to provide the means to navigate and
operate on the details oriented according in relationship to one another.

see TAISOrienting 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.  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
<#reduce-impedance-of-disparate-specialized-content-types>`_.

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 (TAISOrienting) 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.

.. _`Business Unusual: How "Event-Awareness" May Breathe Life Into the Catalog`:
   http://www.cs.cornell.edu/lagoze/papers/lagozelc.pdf
.. _`strawman document`:
   http://www.ilrt.bris.ac.uk/discovery/harmony/docs/abc/abc_draft.html
.. _`data model`:
   http://metadata.net/harmony/ABCV2.htm