A Brief Introduction To Rewindable Desktops, Part II.

["Bowie J. Poag" <bpoag comcast net>]

Contexts, Timeframes and Tesseractors: A Brief Introduction To Rewindable
Desktops, Part II.
----------------------------------------------------------------------------
----------------
by Bowie J. Poag bpoag comcast net
01/06/03


Table of Contents:

I.   Preface
II.  Introduction
III. Elastic Contexts
IV.  Construction Methodology
V.   Construction Summary












    Preface: The Purpose Of This Document
    -------------------------------------

    The purpose of this series of documents is to introduce, and explain how
to build a functioning rewindable desktop. Later, in Part III, we'll get
into why you'd want to build one in the first place. For now, its all
theory, lacking even a single scrap of code to demonstrate a
proof-of-concept model. However, that's not to say it can't be done. Below,
you will find (as best as I'm able to describe) the blueprints of how a
rewindable desktop can be made. Its surely not the only way, but its the
best way I know how to do it after much thought.



    Introduction: A Spoonful Of Memories In A Cup Of Time
    -----------------------------------------------------

    Sit down, fix yourself a cup of coffee, and have a look at your
surroundings for a moment. Some of you may be sitting in a chair outside,
others confined to their beds, many more sitting at their desks waiting
impatiently for a nugget of truth to leap forward from this document.  Think
for a moment about the true substance of what you see. All of the things you
see can be found within catalog of things you have seen before in life.  You
recognize them for that very reason. By having seen these things before, the
process of recognition is complete.

    The things we see around us, the sights, the sounds, the smells, the
emotions we experience make up the fabric of our existence.  Without the
capability to remember, we lose our notion of time.  We lose our knowledge,
our sense of context, and perhaps even our own identity. Memory is what
allows us to distinguish old experiences from new experiences. Given our
reliance upon past and present, memory becomes critical.  So critical, that
we cannot even _posess_ the notion of time without first introducing the
notion of memory. The two are inescapably linked, each owing its existence
to the other.

    Simply put, the breadth and depth of our memory is function of how
varied our experiences are, and the amount of time we have in which to store
and view them.





    Elastic Contexts: A Solution To The Problem Of Temporal Referencing
    -------------------------------------------------------------------

    When dealing with memories, whether human or machine, the most important
thing to remember is context. Context, context, context! The only
realistically plausible way to extend our ability to grasp (and work with)
our memories is to expand upon our current notion of context, and how
context changes with time. Dreams that may come, ballistic missile treaties,
and bowling balls all share one thing in common---they are objects to which
we as people can link references to. Even things which have yet to happen
can be addressed in this matter---by the act of simply considering them, we
in essence create a symbolic link to that idea.  We create a context.

    In the physical world, all things great and small possess a seemingly
infinite array of contexts.. Billions upon billions of ways in which any
object can be referenced. Everything physical possesses a context of some
sort, from the light of a candle extinguished thousand years ago to a shadow
on the door of a cottage on the shore of a dark Scottish lake. Some contexts
are sturdy and somewhat everlasting, while other contexts fall in and out of
existence depending upon circumstance;  All objects, regardless of their
place in time, can be referred to in this manner. Whether referenced as a
group, individually, or by association, contexts are the strings which bind
different objects together.

    By nature of their design, a "context" is a heavily elastic structure.
At one point in time, one context may be more of a direct and sensible
reference---and over time, this same context will become a less and less
useful method of addressing the object.

    Case in point:  In the latter part of the 19th century (and to some
degree, the early 20th) what you and I call a "car" used to be referred to
as a "Henry's horseless carriage". As the object has traveled through time,
new contexts have been established, while older contexts have fallen out of
favor, stretched thin with age.   Over the past 100 years, the object has
acquired quite a few contexts.. "That thing Henry is working on" to,
"Henry's horseless carriage" to "horseless carriage", "automobile",  "car",
just to name a few major ones. As of 2003, the thickest and most robust
context for this object is "car". By 1930, the "horseless carriage" context
had thinned out considerably. Almost no one referred to it like that. While
one context grew thinner and weaker, other contexts grew stronger and more
robust. As of the time of this writing, "horseless carriage" has been
stretched almost imperceptibly thin.. "car" is what we most often refer to
the object as.   And more than likely, in the future, the elasticity of the
"automobile" moniker will be stretched just as thin as "horseless carriage",
replaced with a newer one we have no way of predicting.

    Contexts are strengthened by repeated references. The reason the
"horseless carriage" context fell out of favor is because fewer and fewer
people referenced it as such. If people a hundred years ago continued the
practice of referring to cars as "horseless carriages", the context would
have been solidified-- its binding would be thick, robust, and the most
obvious way of referring to the object. While still marginally elastic, this
one particular context would remain the best route between A and B, so to
speak. However, as we all know, time was cruel to this particular context.
It has been replaced with the more robust and contemporary context, "car".
Our once familiar context has long since passed the point of deprecation,
traveling well into the land of total obsolescence. However, its important
to note one curious little thing:    No matter how deprecated, no matter how
obsolete --- the context still exists. It can be stretched incredibly thin,
but it will never disintegrate, snap, or lose its ability to reference the
object.  By our discussing the "horseless carriage" context here in this
document, we have actually done a little to strengthen it. Anyway, enough
with the abstract.  Lets look at the blueprints.



    Construction Methodology: How To Build A Rewindable Desktop
    -----------------------------------------------------------

    Here are some proposed structures, in order of ascending size.

    Context Pool - A grouping of temporal references within a timeframe that
form connections between events.
Tesseractor - A device used to index regions within a polychronic buffer and
reconstruct the display
Timeframe - A specific region within a polychronic buffer where events and
their contexts are described.
Polychronic Buffer - A circular time structure which contains all
referencable events known to the machine.
Desktop - Duh. The thing the user looks at and corresponds with.

    Polychronic Buffer : A polychronic buffer can be thought of as a
circular data stream, a ring of data which is constantly renewed as time
goes on. That being said, it has a zero point, and a circumference equal to
the linear storage capacity of the machine in which it sits. For example,
suppose a machine with a rewindable desktop has a linear storage length of
437 hours. The sum total of that 437 hour ring of data is called the
"polychronic buffer".

    Timeframes : The polychronic buffer is broken down into things called
timeframes, much the same way as a clock is broken down into hours. The
width of each timeframe should be adjustable, depending upon how granular
the system wants it to be, in order to keeps track of changes that occur. At
the beginning of each timeframe, a system-wide snapshot is taken in order to
avoid having contexts which overlap into multiple timeframes. As time goes
on, obsolete timeframes are dumped off the tail end, and new timeframes are
created at the head end. They shift through the polychronic buffer on a
continual basis as new actions are committed by the user.

    Tesseractor : A tesseractor is a device used to traverse and reference
specific points within a timeframe, and build a display for the user. The
tesseractor itself must be constructed in such a way that given any fixed
point in time, it can index all the relevant contexts that were active at
that point. A tesseractor must be built with flexibility in mind, and in
such a way as to allow the user to see accurate representation of what he or
she was doing at any given point in the timeframe.  Depending upon the
complexity and size of the system, the tesseractor's functional size may be
tiny or enormously large. There is no all-inclusive, one-size-fits-all
solution for temporal indexing, as far as I know. Think of a tesseractor as
the magnetic head on a reel-to-reel tape. The wider the tape (polychronic
buffer complexity), the wider the head (tesseractor) is going to be. As the
name implies, a tesseractor is a four-dimensional cube. Tesseractor movement
is analogous to indexing a ranged block of data within a three dimensional
array, where distance traversed is equal to the amount of time elapsed.

    Context Pool : As mentioned earlier, a context can be thought of as a
flexible elastic string that connects an object to an object, an object to
an action, or an action to an action. At the end of each timeframe's
recording, all active contexts are ended. Whichever actions or objects were
live at the time are continued at the beginning of the next timeframe's
recording, in order to allow a consistent path of traversal for the
tesseractor. Bridging contexts over multiple timeframes will allow the
tesseractor to "drill down" it's line of parentage, in order to reconstruct
events which may have been lost with time. For situations that require a
comparably low degree of recording granularity, the context pool will
probably be fairly shallow. The richer the context pool, however, the more
accurate a depiction the tesseractor will be able to build for the user.

    Desktop : Duh. The end product constructed by the tesseractor. In
real-time situations, the tesseractor is merely indexing the present, as
opposed to indexing events elsewhere within the polychronic buffer.



    Construction Summary: Understanding The System From 10,000 Feet
    ---------------------------------------------------------------

    So, in summary, here's what we've got going:

    A ring of event recordings called a "polychronic buffer", is broken down
into segments called "timeframes".  A virtual magnetic tapehead called a
"tesseractor" moves around within a timeframe, and can reconstruct what a
desktop looked like at any given point in time by reassembling elastic
threads of association made by the system, called "contexts".....or:

    Contexts connect events or objects. These events/objects sit within a
context pool, which sits within a timeframe, which sits within a polychronic
buffer, traversed merrily by a tesseractor which builds the display for the
user.



(End of Part II)